public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Allan Sandfeld Jensen <linux@carewolf.com>
Cc: gcc@gcc.gnu.org
Subject: Re: GCC turns &~ into | due to undefined bit-shift without warning
Date: Fri, 22 Mar 2019 09:50:00 -0000	[thread overview]
Message-ID: <20190322095006.GJ7611@tucnak> (raw)
In-Reply-To: <2988296.44csPzL39Z@twilight>

On Fri, Mar 22, 2019 at 10:27:38AM +0100, Allan Sandfeld Jensen wrote:
> But getting back to the question, well GCC carry such information further, and 
> thus break code that is otherwise correct behaving on all known architectures, 
> just because the C standard hasn't decided on one of two possible results?

Of course it will, as will do any other optimizing compilers.

An optimizing compiler optimizes on the assumption that undefined behavior
does not happen.  It is not done with the intent to punish those that write
bad code, but with the intent to generate better code for valid code.

Say if the standard says that signed integer overflow is undefined behavior,
then not taking advantage of that means significant performance degradation
of e.g. many loops with signed integer IVs or signed integer computations in
it.  You can compare performance of normal code vs. one built with
additional -fwrapv.  And in that case we provide a switch that makes it well
defined behavior at the expense of making code slower.
For out of bound shifts, there is no option like
-fout-of-bound-shift={zero,masked,undefined}, it isn't worth it.

And no, out of bounds shift don't have just two possible results even in HW,
as I said, sometimes it is masked with a different mask from the bitmask
of the type, at other times the architecture has multiple different
instructions and some of them have one behavior and others have another
behavior.

	Jakub

  reply	other threads:[~2019-03-22  9:50 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
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 [this message]
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=20190322095006.GJ7611@tucnak \
    --to=jakub@redhat.com \
    --cc=gcc@gcc.gnu.org \
    --cc=linux@carewolf.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).