From: Markus Trippelsdorf <markus@trippelsdorf.de>
To: Bernd Edlinger <bernd.edlinger@hotmail.de>
Cc: Jason Merrill <jason@redhat.com>,
Florian Weimer <fw@deneb.enyo.de>,
"gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>,
Jeff Law <law@redhat.com>
Subject: Re: [PATCH] Make -Wint-in-bool-context warn on suspicious shift ops
Date: Mon, 17 Oct 2016 17:44:00 -0000 [thread overview]
Message-ID: <20161017174429.GC303@x4> (raw)
In-Reply-To: <AM4PR0701MB2162458A7F27D68C8AF290D8E4D00@AM4PR0701MB2162.eurprd07.prod.outlook.com>
On 2016.10.17 at 17:30 +0000, Bernd Edlinger wrote:
> On 10/17/16 19:11, Markus Trippelsdorf wrote:
> >>> I'm seeing this warning a lot in valid low level C code for unsigned
> >>> integers. And I must say it look bogus in this context. Some examples:
> >
> > (All these examples are from qemu trunk.)
> >
> >>> return ((a.high & 0x7fff) == 0x7fff) && (a.low<<1);
> >>>
> >
> > typedef struct {
> > uint64_t low;
> > uint16_t high;
> > } floatx80;
> >
> > static inline int floatx80_is_any_nan(floatx80 a)
> > {
> > return ((a.high & 0x7fff) == 0x7fff) && (a.low<<1);
> > }
> >
> >> With the shift op, the result depends on integer promotion rules,
> >> and if the value is signed, it can invoke undefined behavior.
> >>
> >> But if a.low is a unsigned short for instance, a warning would be
> >> more than justified here.
> >
> >>> if ( (uint32_t) ( aSig<<( shiftCount & 31 ) ) ) {
> >>>
> >>
> >> Yes interesting, aSig is signed int, right?
> >
> > No, it is uint32_t.
> >
> >> So if the << will overflow, the code is invoking undefined behavior.
> >>
> >>
> >>> && (uint64_t) (extractFloatx80Frac(a) << 1))
> >>>
> >>
> >> What is the result type of extractFloatx80Frac() ?
> >
> > static inline uint64_t extractFloatx80Frac( floatx80 a )
> >
> >>
> >>> if ((plen < KEYLENGTH) && (key << plen))
> >>>
> >>
> >> This is from linux, yes, I have not seen that with the first
> >> version where the warning is only for signed shift ops.
> >>
> >> At first sight it looks really, like could it be that "key < plen"
> >> was meant? But yes, actually it works correctly as long
> >> as int is 32 bit, if int is 64 bits, that code would break
> >> immediately.
> >
> > u8 plen;
> > u32 key;
> >
> >> I think in the majority of code, where the author was aware of
> >> possible overflow issues and integer promotion rules, he will
> >> have used unsigned integer types, of sufficient precision.
> >
> > As I wrote above, all these warning were for unsigned integer types.
> > And all examples are perfectly valid code as far as I can see.
> >
>
> I would be fine with disabling the warning in cases where the shift
> is done in unsigned int. Note however, that the linux code is
> dependent on sizeof(int)<=sizeof(u32), but the warning would certainly
> be more helpful if it comes back at the day when int starts to be 64
> bits wide.
>
>
> How about this untested patch, does it reduce the false positive rate
> for you?
Yes, now everything is fine. Thank you.
--
Markus
next prev parent reply other threads:[~2016-10-17 17:44 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-25 9:14 Bernd Edlinger
2016-09-27 12:45 ` Jason Merrill
2016-09-27 12:58 ` Florian Weimer
2016-09-27 13:56 ` Bernd Edlinger
2016-09-27 14:34 ` Florian Weimer
2016-09-27 14:42 ` Bernd Edlinger
2016-09-27 14:51 ` Jason Merrill
2016-09-27 15:19 ` Bernd Edlinger
2016-09-28 14:44 ` Jason Merrill
2016-09-28 16:17 ` Bernd Edlinger
2016-09-29 18:10 ` Jason Merrill
2016-09-29 19:07 ` Bernd Edlinger
2016-09-29 20:08 ` Bernd Edlinger
2016-09-29 20:53 ` Jason Merrill
2016-09-30 7:05 ` Bernd Edlinger
2016-10-02 18:38 ` Jason Merrill
2016-10-08 17:40 ` Jason Merrill
2016-10-08 20:05 ` Bernd Edlinger
2016-10-09 2:42 ` Jason Merrill
2016-10-17 15:23 ` Markus Trippelsdorf
2016-10-17 16:51 ` Bernd Edlinger
2016-10-17 17:11 ` Markus Trippelsdorf
2016-10-17 17:30 ` Bernd Edlinger
2016-10-17 17:44 ` Markus Trippelsdorf [this message]
2016-10-18 17:04 ` Bernd Edlinger
2016-10-18 17:05 ` Joseph Myers
2016-10-18 18:14 ` Bernd Edlinger
2016-10-19 20:13 ` Jeff Law
2016-10-20 8:05 ` Markus Trippelsdorf
2016-10-20 14:00 ` Bernd Edlinger
2016-09-27 13:48 ` Michael Matz
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=20161017174429.GC303@x4 \
--to=markus@trippelsdorf.de \
--cc=bernd.edlinger@hotmail.de \
--cc=fw@deneb.enyo.de \
--cc=gcc-patches@gcc.gnu.org \
--cc=jason@redhat.com \
--cc=law@redhat.com \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).