public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: geomatsi@gmail.com (Sergey Matyukevich)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm64: sysreg: fix sparse warnings
Date: Thu, 15 Nov 2018 11:35:35 +0300	[thread overview]
Message-ID: <20181115083535.usyjcdoz2f6zmssq@bars> (raw)
In-Reply-To: <20181114222540.fgddrx4xxsne5pdq@ltop.local>

> > >>>>> 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

  reply	other threads:[~2018-11-15  8:35 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-09 20:47 [PATCH] arm64: sysreg: fix sparse warnings Sergey Matyukevich
2018-11-10  0:16 ` Will Deacon
2018-11-10 11:16   ` Sergey Matyukevich
2018-11-10 17:03     ` Will Deacon
2018-11-10 17:54       ` Luc Van Oostenryck
2018-11-12 16:32         ` Ramsay Jones
2018-11-14 22:25           ` Luc Van Oostenryck
2018-11-15  8:35             ` Sergey Matyukevich [this message]
2018-11-16 10:34               ` Luc Van Oostenryck
2018-11-16 13:54                 ` Sergey Matyukevich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181115083535.usyjcdoz2f6zmssq@bars \
    --to=geomatsi@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox