public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Philipp Tomsich <philipp.tomsich@vrull.eu>
Cc: Jeff Law <law@redhat.com>, Philipp Tomsich <ptomsich@gmail.com>,
	GCC Patches <gcc-patches@gcc.gnu.org>,
	Philipp Tomsich <prt@gnu.org>
Subject: Re: [PATCH v1 1/2] Simplify shifts wider than the bitwidth of types
Date: Tue, 17 Nov 2020 19:02:03 +0100	[thread overview]
Message-ID: <20201117180203.GZ3788@tucnak> (raw)
In-Reply-To: <CAAeLtUBd=dURJCFkLOkKFXPS1yYtx2ozf5RLUmGRg9J_wn03Sw@mail.gmail.com>

On Tue, Nov 17, 2020 at 06:23:51PM +0100, Philipp Tomsich wrote:
> The rules for E1 << E2 are:
>   - if E2 is negative => undefined
>   - if E1 is unsigned => E1 x 2^E2, reduced module one more than the
> maximum representable value
>   - if E1 is signed and non-negative => E1 x 2^E2, if E1 x 2^E2 is
> representable; otherwise, undefined

Those are rules about UB -fsanitize=shift-base diagnoses, and that greatly
differs between different languages and versions of those languages, and as
we don't really record what it comes from, for the GIMPLE IL everything is
well defined.
What we were talking about before is written earlier in the
"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."
sentence and is what -fsanitize=shift-exponent diagnoses.  In the GIMPLE IL
such shifts are still UB and in RTL only depending on some target macros
(i.e. undefined for some targets, wrapping with some mask or saturating on
others).

	Jakub


  reply	other threads:[~2020-11-17 18:02 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-16 18:57 Philipp Tomsich
2020-11-16 18:57 ` [PATCH v1 2/2] RISC-V: Adjust predicates for immediate shift operands Philipp Tomsich
2020-11-16 22:27   ` Jim Wilson
2020-11-16 22:45     ` Philipp Tomsich
2020-11-17 17:06       ` Jim Wilson
2020-11-16 22:38 ` [PATCH v1 1/2] Simplify shifts wider than the bitwidth of types Jim Wilson
2020-11-16 22:59   ` Philipp Tomsich
2020-11-16 23:38 ` Jeff Law
2020-11-17 11:53   ` Philipp Tomsich
2020-11-17 15:56     ` Jeff Law
2020-11-17 16:29       ` Philipp Tomsich
2020-11-17 16:46         ` Jakub Jelinek
2020-11-17 16:54           ` Jeff Law
2020-11-17 16:58             ` Jakub Jelinek
2020-11-18 23:46               ` Jeff Law
2020-11-17 17:23             ` Philipp Tomsich
2020-11-17 18:02               ` Jakub Jelinek [this message]
2020-11-17 17:14           ` Jim Wilson
2020-11-17 17:55             ` Jakub Jelinek
2020-11-17 16:35       ` Philipp Tomsich

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=20201117180203.GZ3788@tucnak \
    --to=jakub@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=law@redhat.com \
    --cc=philipp.tomsich@vrull.eu \
    --cc=prt@gnu.org \
    --cc=ptomsich@gmail.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).