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
next prev parent 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