public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: "Moritz Strübe" <moritz.struebe@redheads.de>
Cc: "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>,
	       Nicolai Steinkamp <nicolai.steinkamp@redheads.de>
Subject: Re: GCC turns &~ into | due to undefined bit-shift without warning
Date: Mon, 11 Mar 2019 09:14:00 -0000	[thread overview]
Message-ID: <20190311091449.GB7611@tucnak> (raw)
In-Reply-To: <4af9e251-f4c3-a5a4-e33d-fb8750c87e36@redheads.de>

On Mon, Mar 11, 2019 at 08:49:30AM +0000, Moritz Strübe wrote:
> Considering that C11 6.5.7#3 ("If  the  value  of  the  right operand  
> is  negative  or  is greater than or equal to the width of the promoted 
> left operand, the behavior is undefined.") is not very widely known, as 
> it "normally" just works, inverting the intent is quite unexpected.
> 
> Is there any option that would have helped me with this?

You could build with -fsanitize=undefined, that would tell you at runtime you
have undefined behavior in your code (if the SingleDiff has bit ever 0x20
set).

The fact that negative or >= bit precision shifts are UB is widely known,
and even if it wouldn't, for the compiler all the UBs are just UBs, the
compiler optimizes on the assumption that UB does not happen, so when it
sees 32-bit int << (x & 32), it can assume x must be 0 at that point,
anything else is UB.

GCC has warnings for the simple cases, where one uses negative or too large
constant shift, warning in cases like you have would be a false positive for
many people, there is nothing wrong with that (if x & 32 always results in
0).

	Jakub

  reply	other threads:[~2019-03-11  9:14 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-11  8:49 Moritz Strübe
2019-03-11  9:14 ` Jakub Jelinek [this message]
2019-03-11 11:06   ` Moritz Strübe
2019-03-11 11:17     ` Jakub Jelinek
2019-03-20 14:08       ` Moritz Strübe
2019-03-20 14:26         ` Christophe Lyon
2019-03-20 15:39           ` Moritz Strübe
2019-03-20 15:49         ` Jakub Jelinek
2019-03-20 17:36         ` Andrew Haley
2019-03-21  8:17           ` Richard Biener
2019-03-21  8:25             ` Alexander Monakov
2019-03-21  8:35               ` Richard Biener
2019-03-21  8:54           ` Moritz Strübe
2019-03-21  9:52             ` Andrew Haley
2019-03-11 11:24     ` Vincent Lefevre
2019-03-11 12:51       ` David Brown
2019-03-12 15:40         ` Vincent Lefevre
2019-03-12 20:57           ` David Brown
2019-03-13  2:25             ` Vincent Lefevre
2019-03-13 10:18               ` David Brown
2019-03-26 22:51                 ` Vincent Lefevre
2019-03-21 22:20   ` Allan Sandfeld Jensen
2019-03-21 22:31     ` Jakub Jelinek
2019-03-22  9:27       ` Allan Sandfeld Jensen
2019-03-22  9:50         ` Jakub Jelinek
2019-03-22 10:02     ` Andrew Haley
2019-03-22 10:20       ` Allan Sandfeld Jensen
2019-03-22 12:28         ` David Brown
2019-03-22 12:40           ` Jakub Jelinek
2019-03-22 13:38         ` Andrew Haley
2019-03-22 14:35           ` Allan Sandfeld Jensen
2019-03-22 22:08             ` Andrew Pinski
2019-03-22 22:38               ` Andrew Pinski
2019-03-22 23:42               ` Joseph Myers

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=20190311091449.GB7611@tucnak \
    --to=jakub@redhat.com \
    --cc=gcc@gcc.gnu.org \
    --cc=moritz.struebe@redheads.de \
    --cc=nicolai.steinkamp@redheads.de \
    /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).