[PATCH] arm64: sysreg: fix sparse warnings

[PATCH] arm64: sysreg: fix sparse warnings

[Sergey Matyukevich]

Specify correct type for the constants to avoid
the following sparse complaints:

./arch/arm64/include/asm/sysreg.h:471:42: warning: constant 0xffffffffffffffff is so big it is unsigned long
./arch/arm64/include/asm/sysreg.h:512:42: warning: constant 0xffffffffffffffff is so big it is unsigned long

Signed-off-by: Sergey Matyukevich <geomatsi@gmail.com>
---
 arch/arm64/include/asm/sysreg.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index 0c909c4a932f..e025aaa35178 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -468,7 +468,7 @@
 			 SCTLR_ELx_SA     | SCTLR_ELx_I    | SCTLR_ELx_WXN | \
 			 SCTLR_ELx_DSSBS | ENDIAN_CLEAR_EL2 | SCTLR_EL2_RES0)
 
-#if (SCTLR_EL2_SET ^ SCTLR_EL2_CLEAR) != 0xffffffffffffffff
+#if (SCTLR_EL2_SET ^ SCTLR_EL2_CLEAR) != 0xffffffffffffffffULL
 #error "Inconsistent SCTLR_EL2 set/clear bits"
 #endif
 
@@ -509,7 +509,7 @@
 			 SCTLR_EL1_UMA | SCTLR_ELx_WXN     | ENDIAN_CLEAR_EL1 |\
 			 SCTLR_ELx_DSSBS | SCTLR_EL1_NTWI  | SCTLR_EL1_RES0)
 
-#if (SCTLR_EL1_SET ^ SCTLR_EL1_CLEAR) != 0xffffffffffffffff
+#if (SCTLR_EL1_SET ^ SCTLR_EL1_CLEAR) != 0xffffffffffffffffULL
 #error "Inconsistent SCTLR_EL1 set/clear bits"
 #endif
 
-- 
2.11.0

[PATCH] arm64: sysreg: fix sparse warnings

[Will Deacon]

On Fri, Nov 09, 2018 at 11:47:47PM +0300, Sergey Matyukevich wrote:
> Specify correct type for the constants to avoid
> the following sparse complaints:
> 
> ./arch/arm64/include/asm/sysreg.h:471:42: warning: constant 0xffffffffffffffff is so big it is unsigned long
> ./arch/arm64/include/asm/sysreg.h:512:42: warning: constant 0xffffffffffffffff is so big it is unsigned long
> 
> Signed-off-by: Sergey Matyukevich <geomatsi@gmail.com>
> ---
>  arch/arm64/include/asm/sysreg.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

I thought this was fixed in newer versions of sparse so that it treats
AArch64 as 64-bit? [see sparse commit 49d56b6969d2f]

Will

[PATCH] arm64: sysreg: fix sparse warnings

[Sergey Matyukevich]

On Sat, Nov 10, 2018 at 12:16:16AM +0000, Will Deacon wrote:
> On Fri, Nov 09, 2018 at 11:47:47PM +0300, Sergey Matyukevich wrote:
> > Specify correct type for the constants to avoid
> > the following sparse complaints:
> > 
> > ./arch/arm64/include/asm/sysreg.h:471:42: warning: constant 0xffffffffffffffff is so big it is unsigned long
> > ./arch/arm64/include/asm/sysreg.h:512:42: warning: constant 0xffffffffffffffff is so big it is unsigned long
> > 
> > Signed-off-by: Sergey Matyukevich <geomatsi@gmail.com>
> > ---
> >  arch/arm64/include/asm/sysreg.h | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> I thought this was fixed in newer versions of sparse so that it treats
> AArch64 as 64-bit? [see sparse commit 49d56b6969d2f]

I am using up-to-date sparse. However this warning still appears,
not sure why. Maybe sparse treats such constants as unsigned int ?

Meanwhile it looks like I chose wrong type: it is enough to use UL
instead of ULL to make sparse happy. In fact warning is clear
about it.

Regards,
Sergey

[PATCH] arm64: sysreg: fix sparse warnings

[Will Deacon]

On Sat, Nov 10, 2018 at 02:16:47PM +0300, Sergey Matyukevich wrote:
> On Sat, Nov 10, 2018 at 12:16:16AM +0000, Will Deacon wrote:
> > On Fri, Nov 09, 2018 at 11:47:47PM +0300, Sergey Matyukevich wrote:
> > > Specify correct type for the constants to avoid
> > > the following sparse complaints:
> > > 
> > > ./arch/arm64/include/asm/sysreg.h:471:42: warning: constant 0xffffffffffffffff is so big it is unsigned long
> > > ./arch/arm64/include/asm/sysreg.h:512:42: warning: constant 0xffffffffffffffff is so big it is unsigned long
> > > 
> > > Signed-off-by: Sergey Matyukevich <geomatsi@gmail.com>
> > > ---
> > >  arch/arm64/include/asm/sysreg.h | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > I thought this was fixed in newer versions of sparse so that it treats
> > AArch64 as 64-bit? [see sparse commit 49d56b6969d2f]
> 
> I am using up-to-date sparse. However this warning still appears,
> not sure why. Maybe sparse treats such constants as unsigned int ?
> 
> Meanwhile it looks like I chose wrong type: it is enough to use UL
> instead of ULL to make sparse happy. In fact warning is clear
> about it.

Ah yes, sorry. I misread the patch the first time around and thought you were
changing a UL suffix to a ULL suffix. So actually, I think this is just a
case of sparse getting confused about this constant because it's actually
going to get parsed by the pre-processor, which says:

  | It [the preprocessor parsing #if] carries out all calculations in the
  | widest integer type known to the compiler; on most machines supported by
  | GCC this is 64 bits

so I still think this is a false positive. Adding Luc in case he has any
ideas.

Will

[PATCH] arm64: sysreg: fix sparse warnings

[Luc Van Oostenryck]

On Sat, Nov 10, 2018 at 05:03:21PM +0000, Will Deacon wrote:
> On Sat, Nov 10, 2018 at 02:16:47PM +0300, Sergey Matyukevich wrote:
> > On Sat, Nov 10, 2018 at 12:16:16AM +0000, Will Deacon wrote:
> > > On Fri, Nov 09, 2018 at 11:47:47PM +0300, Sergey Matyukevich wrote:
> > > > Specify correct type for the constants to avoid
> > > > the following sparse complaints:
> > > > 
> > > > ./arch/arm64/include/asm/sysreg.h:471:42: warning: constant 0xffffffffffffffff is so big it is unsigned long
> > > > ./arch/arm64/include/asm/sysreg.h:512:42: warning: constant 0xffffffffffffffff is so big it is unsigned long
> > > > 
> > > > Signed-off-by: Sergey Matyukevich <geomatsi@gmail.com>
> > > > ---
> > > >  arch/arm64/include/asm/sysreg.h | 4 ++--
> > > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > I thought this was fixed in newer versions of sparse so that it treats
> > > AArch64 as 64-bit? [see sparse commit 49d56b6969d2f]
> > 
> > I am using up-to-date sparse. However this warning still appears,
> > not sure why. Maybe sparse treats such constants as unsigned int ?
> > 
> > Meanwhile it looks like I chose wrong type: it is enough to use UL
> > instead of ULL to make sparse happy. In fact warning is clear
> > about it.
> 
> Ah yes, sorry. I misread the patch the first time around and thought you were
> changing a UL suffix to a ULL suffix. So actually, I think this is just a
> case of sparse getting confused about this constant because it's actually
> going to get parsed by the pre-processor, which says:
> 
>   | It [the preprocessor parsing #if] carries out all calculations in the
>   | widest integer type known to the compiler; on most machines supported by
>   | GCC this is 64 bits
> 
> so I still think this is a false positive. Adding Luc in case he has any
> ideas.

Well, I think the warning is 'correct' (and the message is quite
clear about the 'possible' problem) but probably not useful enough.
In fact, some months ago, it was agreed that sparse will only issue
this warning when -Wpedantic is set but this flag is not yet handled.

I'll look at this next week.

-- Luc

[PATCH] arm64: sysreg: fix sparse warnings

[Ramsay Jones]

On 10/11/2018 17:54, Luc Van Oostenryck wrote:
> On Sat, Nov 10, 2018 at 05:03:21PM +0000, Will Deacon wrote:
>> On Sat, Nov 10, 2018 at 02:16:47PM +0300, Sergey Matyukevich wrote:
>>> On Sat, Nov 10, 2018 at 12:16:16AM +0000, Will Deacon wrote:
>>>> On Fri, Nov 09, 2018 at 11:47:47PM +0300, Sergey Matyukevich wrote:
>>>>> Specify correct type for the constants to avoid
>>>>> the following sparse complaints:
>>>>>
>>>>> ./arch/arm64/include/asm/sysreg.h:471:42: warning: constant 0xffffffffffffffff is so big it is unsigned long
>>>>> ./arch/arm64/include/asm/sysreg.h:512:42: warning: constant 0xffffffffffffffff is so big it is unsigned long
>>>>>
>>>>> Signed-off-by: Sergey Matyukevich <geomatsi@gmail.com>
>>>>> ---
>>>>>  arch/arm64/include/asm/sysreg.h | 4 ++--
>>>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>>
>>>> I thought this was fixed in newer versions of sparse so that it treats
>>>> AArch64 as 64-bit? [see sparse commit 49d56b6969d2f]
>>>
>>> I am using up-to-date sparse. However this warning still appears,
>>> not sure why. Maybe sparse treats such constants as unsigned int ?
>>>
>>> Meanwhile it looks like I chose wrong type: it is enough to use UL
>>> instead of ULL to make sparse happy. In fact warning is clear
>>> about it.
>>
>> Ah yes, sorry. I misread the patch the first time around and thought you were
>> changing a UL suffix to a ULL suffix. So actually, I think this is just a
>> case of sparse getting confused about this constant because it's actually
>> going to get parsed by the pre-processor, which says:
>>
>>   | It [the preprocessor parsing #if] carries out all calculations in the
>>   | widest integer type known to the compiler; on most machines supported by
>>   | GCC this is 64 bits
>>
>> so I still think this is a false positive. Adding Luc in case he has any
>> ideas.
> 
> Well, I think the warning is 'correct' (and the message is quite
> clear about the 'possible' problem) but probably not useful enough.

yes, the warning is correct. I think the message is quite clear, so
would be happy to hear any possible improvements! ;-)

(Also, correcting the source, in order to suppress these warnings,
should take mere seconds - for each such warning, of course).

> In fact, some months ago, it was agreed that sparse will only issue
> this warning when -Wpedantic is set but this flag is not yet handled.

I have patches, but I have been waiting for the 'official repo' issue
to get resolved. (If you remember, I was building on top of the current
official repo and continually merging to the master branch of your
github sparse.git - but I got bored of doing that!).

> I'll look at this next week.

I stopped work on my patches months ago, after doing just enough to
enable me to work on git without tearing my hair out on Linux Mint 19
(or Ubuntu 18.04, Fedora 27+ etc.). ;-)

I was working on -Wsystem-headers, so this warning (along with some
other __extension__ warnings in the system headers) do not cause me
any further issues on git. (that would not help on the kernel, of course).

[BTW, I have been building/testing/running the master branch of
git://github.com/lucvoo/sparse.git for months now, without seeing
any regressions.]

ATB,
Ramsay Jones

[PATCH] arm64: sysreg: fix sparse warnings

[Luc Van Oostenryck]

On Mon, Nov 12, 2018 at 04:32:31PM +0000, Ramsay Jones wrote:
> 
> 
> On 10/11/2018 17:54, Luc Van Oostenryck wrote:
> > On Sat, Nov 10, 2018 at 05:03:21PM +0000, Will Deacon wrote:
> >> On Sat, Nov 10, 2018 at 02:16:47PM +0300, Sergey Matyukevich wrote:
> >>> On Sat, Nov 10, 2018 at 12:16:16AM +0000, Will Deacon wrote:
> >>>> On Fri, Nov 09, 2018 at 11:47:47PM +0300, Sergey Matyukevich wrote:
> >>>>> Specify correct type for the constants to avoid
> >>>>> the following sparse complaints:
> >>>>>
> >>>>> ./arch/arm64/include/asm/sysreg.h:471:42: warning: constant 0xffffffffffffffff is so big it is unsigned long
> >>>>> ./arch/arm64/include/asm/sysreg.h:512:42: warning: constant 0xffffffffffffffff is so big it is unsigned long
> >>>>>
> >>>>> Signed-off-by: Sergey Matyukevich <geomatsi@gmail.com>
> >>>>> ---
> >>>>>  arch/arm64/include/asm/sysreg.h | 4 ++--
> >>>>>  1 file changed, 2 insertions(+), 2 deletions(-)
> >>>>
> >>>> I thought this was fixed in newer versions of sparse so that it treats
> >>>> AArch64 as 64-bit? [see sparse commit 49d56b6969d2f]
> >>>
> >>> I am using up-to-date sparse. However this warning still appears,
> >>> not sure why. Maybe sparse treats such constants as unsigned int ?
> >>>
> >>> Meanwhile it looks like I chose wrong type: it is enough to use UL
> >>> instead of ULL to make sparse happy. In fact warning is clear
> >>> about it.
> >>
> >> Ah yes, sorry. I misread the patch the first time around and thought you were
> >> changing a UL suffix to a ULL suffix. So actually, I think this is just a
> >> case of sparse getting confused about this constant because it's actually
> >> going to get parsed by the pre-processor, which says:
> >>
> >>   | It [the preprocessor parsing #if] carries out all calculations in the
> >>   | widest integer type known to the compiler; on most machines supported by
> >>   | GCC this is 64 bits
> >>
> >> so I still think this is a false positive. Adding Luc in case he has any
> >> ideas.
> > 
> > Well, I think the warning is 'correct' (and the message is quite
> > clear about the 'possible' problem) but probably not useful enough.
> 
> yes, the warning is correct. I think the message is quite clear, so
> would be happy to hear any possible improvements! ;-)

Oh, I was not talking about the message but, like Linus explained, that
since no bits are lost here (and sparse has another warning in case some
bits would be lost) and nothing is incorrect, the warning is not really
interesting.
 
> (Also, correcting the source, in order to suppress these warnings,
> should take mere seconds - for each such warning, of course).

Yes, sure, it was even the origin of the thread.
 
> > In fact, some months ago, it was agreed that sparse will only issue
> > this warning when -Wpedantic is set but this flag is not yet handled.
> 
> I have patches, but I have been waiting for the 'official repo' issue
> to get resolved. (If you remember, I was building on top of the current
> official repo and continually merging to the master branch of your
> github sparse.git - but I got bored of doing that!).

Yes, I understand. This should be solved now.

> > I'll look at this next week.
> 
> I stopped work on my patches months ago, after doing just enough to
> enable me to work on git without tearing my hair out on Linux Mint 19
> (or Ubuntu 18.04, Fedora 27+ etc.). ;-)
> 
> I was working on -Wsystem-headers, so this warning (along with some
> other __extension__ warnings in the system headers) do not cause me

Interesting. I'll be glad to review them.

> any further issues on git. (that would not help on the kernel, of course).
> 
> [BTW, I have been building/testing/running the master branch of
> git://github.com/lucvoo/sparse.git for months now, without seeing
> any regressions.]

That's always good to know. Thank you.

-- Luc 

[PATCH] arm64: sysreg: fix sparse warnings

[Sergey Matyukevich]

> > >>>>> the following sparse complaints:
> > >>>>>
> > >>>>> ./arch/arm64/include/asm/sysreg.h:471:42: warning: constant 0xffffffffffffffff is so big it is unsigned long
> > >>>>> ./arch/arm64/include/asm/sysreg.h:512:42: warning: constant 0xffffffffffffffff is so big it is unsigned long
> > >>>>>
> > >>>>> Signed-off-by: Sergey Matyukevich <geomatsi@gmail.com>
> > >>>>> ---
> > >>>>>  arch/arm64/include/asm/sysreg.h | 4 ++--
> > >>>>>  1 file changed, 2 insertions(+), 2 deletions(-)
> > >>>>
> > >>>> I thought this was fixed in newer versions of sparse so that it treats
> > >>>> AArch64 as 64-bit? [see sparse commit 49d56b6969d2f]
> > >>>
> > >>> I am using up-to-date sparse. However this warning still appears,
> > >>> not sure why. Maybe sparse treats such constants as unsigned int ?
> > >>>
> > >>> Meanwhile it looks like I chose wrong type: it is enough to use UL
> > >>> instead of ULL to make sparse happy. In fact warning is clear
> > >>> about it.
> > >>
> > >> Ah yes, sorry. I misread the patch the first time around and thought you were
> > >> changing a UL suffix to a ULL suffix. So actually, I think this is just a
> > >> case of sparse getting confused about this constant because it's actually
> > >> going to get parsed by the pre-processor, which says:
> > >>
> > >>   | It [the preprocessor parsing #if] carries out all calculations in the
> > >>   | widest integer type known to the compiler; on most machines supported by
> > >>   | GCC this is 64 bits
> > >>
> > >> so I still think this is a false positive. Adding Luc in case he has any
> > >> ideas.
> > > 
> > > Well, I think the warning is 'correct' (and the message is quite
> > > clear about the 'possible' problem) but probably not useful enough.
> > 
> > yes, the warning is correct. I think the message is quite clear, so
> > would be happy to hear any possible improvements! ;-)
> 
> Oh, I was not talking about the message but, like Linus explained, that
> since no bits are lost here (and sparse has another warning in case some
> bits would be lost) and nothing is incorrect, the warning is not really
> interesting.
>  
> > (Also, correcting the source, in order to suppress these warnings,
> > should take mere seconds - for each such warning, of course).
> 
> Yes, sure, it was even the origin of the thread.
>  
> > > In fact, some months ago, it was agreed that sparse will only issue
> > > this warning when -Wpedantic is set but this flag is not yet handled.
> > 
> > I have patches, but I have been waiting for the 'official repo' issue
> > to get resolved. (If you remember, I was building on top of the current
> > official repo and continually merging to the master branch of your
> > github sparse.git - but I got bored of doing that!).
> 
> Yes, I understand. This should be solved now.
 
Hi,

Could you please clarify what is your resolution regarding that warning.
I pulled all the changes from sparse repository on kernel.org. However
the same warning is still here when building modules with C=2 option.

Regards,
Sergey

[PATCH] arm64: sysreg: fix sparse warnings

[Luc Van Oostenryck]

> Hi,
> 
> Could you please clarify what is your resolution regarding that warning.
> I pulled all the changes from sparse repository on kernel.org. However
> the same warning is still here when building modules with C=2 option.

Hi,

Yes, the warning is still there since it's maybe not desired but
is at least legit. For the short term, I think the best is your
original patch (but using UL as the prefix). I would be glad to
ack such a patch (I tried to answer in the original thread but
I never found it although I should be subscribed to the
linux-arm-kernel mailing list).

For the slightly longer term, I'll need to see how Ramsay's
patches can also be used for kernel code.

Best regards,
-- Luc

[PATCH] arm64: sysreg: fix sparse warnings

[Sergey Matyukevich]

On Fri, Nov 16, 2018 at 11:34:00AM +0100, Luc Van Oostenryck wrote:
> > Hi,
> > 
> > Could you please clarify what is your resolution regarding that warning.
> > I pulled all the changes from sparse repository on kernel.org. However
> > the same warning is still here when building modules with C=2 option.
> 
> Hi,
> 
> Yes, the warning is still there since it's maybe not desired but
> is at least legit. For the short term, I think the best is your
> original patch (but using UL as the prefix). I would be glad to
> ack such a patch (I tried to answer in the original thread but
> I never found it although I should be subscribed to the
> linux-arm-kernel mailing list).
> 
> For the slightly longer term, I'll need to see how Ramsay's
> patches can also be used for kernel code.

Thanks for clarifiation! I will send v2. 

Regards,
Sergey