public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Stefan Kanthak <stefan.kanthak@nexgo.de>
Cc: Jeff Law <law@redhat.com>, gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] Better __ashlDI3, __ashrDI3 and __lshrDI3 functions, plus fixed __bswapsi2 function
Date: Wed, 11 Nov 2020 10:55:09 +0100	[thread overview]
Message-ID: <20201111095509.GI3788@tucnak> (raw)
In-Reply-To: <7ACCC74B62494C2AB3DB97BA1983164B@H270>

On Wed, Nov 11, 2020 at 09:33:00AM +0100, Stefan Kanthak wrote:
> Ouch: that's but not the point here; what matters is the undefined behaviour of
>       ((u) & 0x000000ff) << 24
> 
> 0x000000ff is a signed int, so (u) & 0x000000ff is signed too -- and producing
> a negative value (or overflow) from the left-shift of a signed int, i.e.
> shifting into (or beyond) the sign bit, is undefined behaviour!

Only in some language dialects.
It is caught by -fsanitize=shift.
In C++20, if the shift count is within bounds, all signed as well as
unsigned left shifts well defined.
In C99/C11 there is one extra rule:
For signed x << y, in C99/C11, the following:
     (unsigned) x >> (uprecm1 - y)
     if non-zero, is undefined.
and for C++11 to C++17 another one:
  /* For signed x << y, in C++11 and later, the following:
     x < 0 || ((unsigned) x >> (uprecm1 - y)) > 1
     is undefined.  */
So indeed, 0x80 << 24 is UB in C99/C11 and C++98, unclear in C89 and
well defined in C++11 and later.  I don't know if C2X is considering
mandating two's complement and making it well defined like C++20 did.

Guess we should fix that, though because different languages have different
rules, GCC itself except for sanitization doesn't consider it UB and only
treats shifts by negative value or shifts by bitsize or more UB.

	Jakub


  reply	other threads:[~2020-11-11  9:55 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-10 17:59 Stefan Kanthak
2020-11-10 18:08 ` Eric Botcazou
2020-11-10 19:44   ` Stefan Kanthak
2020-11-10 20:14     ` Jakub Jelinek
2020-11-10 21:09       ` Jeff Law
2020-11-10 21:17         ` Jakub Jelinek
2020-11-10 23:42           ` Jeff Law
2020-11-24  0:21         ` Jeff Law
2020-11-10 22:12       ` Jeff Law
2020-11-10 22:01     ` Jeff Law
2020-11-11  0:00     ` Andreas Schwab
2020-11-24 13:57       ` Stefan Kanthak
2020-11-24 14:34         ` Andreas Schwab
2020-11-24 15:40           ` Stefan Kanthak
2020-11-24 15:49             ` Andreas Schwab
2020-11-25 18:53             ` Jeff Law
2020-11-25 20:22               ` Stefan Kanthak
2020-11-25 20:42                 ` Jakub Jelinek
2020-11-25 21:22                   ` Stefan Kanthak
2020-11-25 22:06                     ` Jeff Law
2020-11-25 23:06                       ` Stefan Kanthak
2020-11-25 20:44                 ` Jeff Law
2020-11-10 18:09 ` Jakub Jelinek
2020-11-10 18:32   ` Jeff Law
2020-11-10 18:26 ` Jakub Jelinek
2020-11-10 23:48 ` Jeff Law
2020-11-10 23:53   ` Jakub Jelinek
2020-11-11  8:33     ` Stefan Kanthak
2020-11-11  9:55       ` Jakub Jelinek [this message]
2020-11-11 17:54         ` Joseph Myers
2020-11-23 23:01         ` Jeff Law
2020-11-30  1:06       ` Jeff Law

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=20201111095509.GI3788@tucnak \
    --to=jakub@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=law@redhat.com \
    --cc=stefan.kanthak@nexgo.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).