public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Vincent Lefevre <vincent+gcc@vinc17.org>
To: gcc@gcc.gnu.org
Subject: Re: GCC turns &~ into | due to undefined bit-shift without warning
Date: Tue, 12 Mar 2019 15:40:00 -0000	[thread overview]
Message-ID: <20190312154013.GA9898@cventin.lip.ens-lyon.fr> (raw)
In-Reply-To: <0474f7ad-1e8d-e545-ff36-1f5c122aabfd@westcontrol.com>

On 2019-03-11 13:51:21 +0100, David Brown wrote:
> On 11/03/2019 12:24, Vincent Lefevre wrote:
> > It already does by default:
> > 
> >        -Wshift-count-negative
> >            Warn if shift count is negative. This warning is enabled
> >            by default.
> > 
> >        -Wshift-count-overflow
> >            Warn if shift count >= width of type. This warning is
> >            enabled by default.
> > 
> > Of course, if the compiler cannot guess that there will be such
> > an issue, it will not emit the warning. You certainly don't want
> > a warning for each non-trivial shift just because the compiler
> > cannot know whether the constraint on the shift count will be
> > satisfied.
> 
> While the compiler clearly can't give a warning on calculated shifts
> without massive amounts of false positives, it is able to give warnings
> when there is a shift by a compile-time known constant value that is
> invalid.  In the case of the OP's test function, inlining and constant
> propagation means that the shift value /is/ known to the compiler - it
> uses it for optimisation (in this case, it uses the undefined behaviour
> to "simplify" the calculations).
> 
> Am I right in thinking that this is because the pass that checks the
> shift sizes for warnings here comes before the relevant inlining or
> constant propagation passes?  And if so, would it be possible to change
> the ordering here?

To generate a warning, the compiler would also have to make sure
that the inlined code with an out-of-range shift is actually not
dead code. In practice, it may happen that constraints are not
satisfied on some platforms, but the reason is that on such
platforms the code will never be executed (this is code written
to take care of other platforms).

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

  reply	other threads:[~2019-03-12 15:40 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
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 [this message]
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=20190312154013.GA9898@cventin.lip.ens-lyon.fr \
    --to=vincent+gcc@vinc17.org \
    --cc=gcc@gcc.gnu.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).