This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch] sext_hwi: Avoid left shift of negative value undefined behaviour
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Markus Trippelsdorf <markus at trippelsdorf dot de>
- Cc: Jeff Law <law at redhat dot com>, Mikael Morin <mikael dot morin at sfr dot fr>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 12 Aug 2015 13:09:41 +0200
- Subject: Re: [Patch] sext_hwi: Avoid left shift of negative value undefined behaviour
- Authentication-results: sourceware.org; auth=none
- References: <55C33636 dot 7020907 at sfr dot fr> <55CA51C4 dot 3050601 at redhat dot com> <CAFiYyc1pM=BT06yLY=L9EDzDCSiUHeXL0D26ic-g8bnYBmqYNA at mail dot gmail dot com> <20150812110724 dot GB403 at x4>
On Wed, Aug 12, 2015 at 1:07 PM, Markus Trippelsdorf
<markus@trippelsdorf.de> wrote:
> On 2015.08.12 at 13:01 +0200, Richard Biener wrote:
>> On Tue, Aug 11, 2015 at 9:49 PM, Jeff Law <law@redhat.com> wrote:
>> > On 08/06/2015 04:25 AM, Mikael Morin wrote:
>> >>
>> >> Hello,
>> >>
>> >> this avoids an error found with bootstrap-ubsan.
>> >> Regression tested on x86_64-unknown-linux-gnu. OK for trunk?
>> >>
>> >> Mikael
>> >>
>> >>
>> >> noub_sext.CL
>> >>
>> >>
>> >> 2015-08-05 Mikael Morin<mikael@gcc.gnu.org>
>> >>
>> >> * hwint.h (sext_hwi): Rewrite without undefined behaviour on
>> >> negative SRC.
>> >
>> > OK. Hopefully most of the time the precision is known at compile-time which
>> > would allow for optimization of the resulting code back to the
>> > pair-of-shifts form by combine.
>>
>> I think it is not. The code also lacks a comment on why we do this kind
>> of obfuscation.
>>
>> What kind of error does ubsan run into? That is, for which 'prec'?
>
> See: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67042
Ugh. Stupid C.
My fear is that with so many stmts sext_hwi isn't any longer considered for
inlining, even if prec is constant. What's the generated code for its
out-of line
copy with/without the patch?
Richard.
> --
> Markus