public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jeff Law <law@redhat.com>
To: Mikael Morin <mikael.morin@sfr.fr>,
	       Richard Biener <richard.guenther@gmail.com>,
	       Mike Stump <mikestump@comcast.net>
Cc: Richard Sandiford <rdsandiford@googlemail.com>,
	       Markus Trippelsdorf <markus@trippelsdorf.de>,
	       gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: [Patch] sext_hwi: Avoid left shift of negative value undefined behaviour
Date: Tue, 18 Aug 2015 17:51:00 -0000	[thread overview]
Message-ID: <55D36F9A.5040203@redhat.com> (raw)
In-Reply-To: <55D34F59.7020307@sfr.fr>

On 08/18/2015 09:29 AM, Mikael Morin wrote:
> Le 14/08/2015 09:29, Richard Biener a écrit :
>> On Thu, Aug 13, 2015 at 7:47 PM, Mike Stump <mikestump@comcast.net>
>> wrote:
>>> On Aug 13, 2015, at 3:05 AM, Richard Biener
>>> <richard.guenther@gmail.com> wrote:
>>>> Ok, then guard the << >> with __GCC__ and do the expensive bit stuff
>>>> otherwise.  Just to cater for other host compilers doing sth unsensibly
>>>> implementation defined.
>>>
> I haven't found __GCC__ used anywhere in the source, but I have found
> __GNUC__ both in the source and the documentation, so I have used that.
>
>>> Ick. The guard should be specific to the implementation defined
>>> semantic or undefined semantic, and then when compiling with gcc, we
>>> turn it on.  My take is that when we do this, we should add the 5 or
>>> 10 other most popular compilers to the list of how they behave so
>>> that they all do the cheap path code as well.  If the language
>>> standard were serious in this area, it would specify a header file
>>> that can define the implementation defined and undefined semantics
>>> that are interesting for portable code.  It isn’t.  If it were, we
>>> would then just use the standard defined guards.
>>
> I have used the __GNUC__ macro instead of a direct feature test or a
> list of the 10 most common compilers, to avoid the #else branch being
> dead basically everywhere.  Maybe the #else branch should just be dropped.
>
>> GCC is always used to build stage2+ so I don't see the need to handle
>> alternate host compilers.
>>
>
> Bootstrapped and regression tested on x86_64-pc-linux-gnu.
> Also bootstrapped with clang, but I don't think it means anything.
> What do you think, OK?
>
> Mikael
>
>
>
> noub_sext_2.CL
>
>
> 2015-08-18  Mikael Morin<mikael@gcc.gnu.org>
>
> 	PR other/67042
> 	* hwint.h (sext_hwi): Switch to unsigned for the left shift, and
> 	conditionalize the whole on __GNUC__.  Add fallback code
> 	depending neither on undefined nor implementation-defined behaviour.
>
I think there was some folks that wanted to see a test for whether or 
not the faster version could be used during a stage1 build with a 
non-gcc compiler.


That would presumably be some kind of autoconf test to see what happens 
when shifting into the sign bit.  But I think that'd be a hell of a test 
to write in practice.  I'm sure the simple test would work, but it's far 
more important to know what the compiler is willing to guarantee in the 
general sense, particularly the interactions with the optimizers and 
vrp-like analysis.

I'm OK with the __GNUC__ conditional.

OK for the trunk.

Thanks,
Jeff


  reply	other threads:[~2015-08-18 17:47 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-06 10:26 Mikael Morin
2015-08-11 19:49 ` Jeff Law
2015-08-12 11:01   ` Richard Biener
2015-08-12 11:07     ` Markus Trippelsdorf
2015-08-12 11:09       ` Richard Biener
2015-08-12 13:34         ` Mikael Morin
2015-08-12 17:02           ` Jeff Law
2015-08-12 17:12             ` Richard Biener
2015-08-12 18:07               ` Jeff Law
2015-08-12 18:32                 ` Richard Biener
2015-08-12 18:41                   ` Jeff Law
2015-08-12 20:07                     ` Richard Sandiford
2015-08-12 20:53                       ` Mike Stump
2015-08-13 10:11                         ` Richard Biener
2015-08-13 18:01                           ` Mike Stump
2015-08-14  7:31                             ` Richard Biener
2015-08-18 15:35                               ` Mikael Morin
2015-08-18 17:51                                 ` Jeff Law [this message]
2015-08-13 11:03                       ` Mikael Morin
2015-08-13 11:06                         ` Mikael Morin
2015-08-13 11:09                         ` Markus Trippelsdorf
2015-08-13 11:20                           ` Richard Biener
2015-08-13 13:48                             ` Marek Polacek
2015-08-13 13:55                               ` Markus Trippelsdorf
2015-08-13 13:57                                 ` Marek Polacek
2015-08-12 19:20                 ` Mike Stump

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=55D36F9A.5040203@redhat.com \
    --to=law@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=markus@trippelsdorf.de \
    --cc=mikael.morin@sfr.fr \
    --cc=mikestump@comcast.net \
    --cc=rdsandiford@googlemail.com \
    --cc=richard.guenther@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).