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
wrote:
On Aug 13, 2015, at 3:05 AM, Richard Biener
wrote:
Ok, then guard the << >> with __GCC__ and do the expensive bit stuff
otherwise. Just to cater for o
Le 14/08/2015 09:29, Richard Biener a écrit :
On Thu, Aug 13, 2015 at 7:47 PM, Mike Stump wrote:
On Aug 13, 2015, at 3:05 AM, Richard Biener wrote:
Ok, then guard the << >> with __GCC__ and do the expensive bit stuff
otherwise. Just to cater for other host compilers doing sth unsensibly
impl
On Thu, Aug 13, 2015 at 7:47 PM, Mike Stump wrote:
> On Aug 13, 2015, at 3:05 AM, Richard Biener
> 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.
>
> Ick. The gu
On Aug 13, 2015, at 3:05 AM, Richard Biener 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.
Ick. The guard should be specific to the implementation defined semantic o
On Thu, Aug 13, 2015 at 03:52:00PM +0200, Markus Trippelsdorf wrote:
> On 2015.08.13 at 15:40 +0200, Marek Polacek wrote:
> > On Thu, Aug 13, 2015 at 01:11:53PM +0200, Richard Biener wrote:
> > > Rather ubsan should not complain about implementation defined behavior (or
> > > should separate those
On 2015.08.13 at 15:40 +0200, Marek Polacek wrote:
> On Thu, Aug 13, 2015 at 01:11:53PM +0200, Richard Biener wrote:
> > Rather ubsan should not complain about implementation defined behavior (or
> > should separate those cases out with a different switch compared to
> > undefined
> > behavior).
>
On Thu, Aug 13, 2015 at 01:11:53PM +0200, Richard Biener wrote:
> Rather ubsan should not complain about implementation defined behavior (or
> should separate those cases out with a different switch compared to undefined
> behavior).
I think ubsan doesn't complain about implementation-defined beha
On Thu, Aug 13, 2015 at 1:08 PM, Markus Trippelsdorf
wrote:
> On 2015.08.13 at 12:56 +0200, Mikael Morin wrote:
>> Le 12/08/2015 22:07, Richard Sandiford a écrit :
>> > Jeff Law writes:
>> >> On 08/12/2015 12:32 PM, Richard Biener wrote:
>> >>> On August 12, 2015 8:07:13 PM GMT+02:00, Jeff Law
On 2015.08.13 at 12:56 +0200, Mikael Morin wrote:
> Le 12/08/2015 22:07, Richard Sandiford a écrit :
> > Jeff Law writes:
> >> On 08/12/2015 12:32 PM, Richard Biener wrote:
> >>> On August 12, 2015 8:07:13 PM GMT+02:00, Jeff Law wrote:
> On 08/12/2015 11:12 AM, Richard Biener wrote:
>
>
Le 13/08/2015 12:56, Mikael Morin a écrit :
Still, implementation-defined behavior is a progress over undefined
behaviour.
Even if it's not set in stone, the good thing about
implementation-defined behaviour is that it's known to be non-random.
So it can be checked, either with autoconf, or with
Le 12/08/2015 22:07, Richard Sandiford a écrit :
Jeff Law writes:
On 08/12/2015 12:32 PM, Richard Biener wrote:
On August 12, 2015 8:07:13 PM GMT+02:00, Jeff Law wrote:
On 08/12/2015 11:12 AM, Richard Biener wrote:
Prec is almost never a constant and is heavily used from wide-int.
We are
On Wed, Aug 12, 2015 at 10:52 PM, Mike Stump wrote:
> On Aug 12, 2015, at 1:07 PM, Richard Sandiford
> wrote:
>>> I don't think the right shifts are an issue at all.
>>
>> Well, they're implementation-defined, at least in C.
>
>> The C11 wording for E1 >> E2 is "If E1 has a signed type and a neg
On Aug 12, 2015, at 1:07 PM, Richard Sandiford
wrote:
>> I don't think the right shifts are an issue at all.
>
> Well, they're implementation-defined, at least in C.
> The C11 wording for E1 >> E2 is "If E1 has a signed type and a negative
> value, the
> resulting value is implementation-defin
Jeff Law writes:
> On 08/12/2015 12:32 PM, Richard Biener wrote:
>> On August 12, 2015 8:07:13 PM GMT+02:00, Jeff Law wrote:
>>> On 08/12/2015 11:12 AM, Richard Biener wrote:
>>>
Prec is almost never a constant and is heavily used from wide-int.
We are not exploiting this unde
On Aug 12, 2015, at 11:07 AM, Jeff Law wrote:
> On 08/12/2015 11:12 AM, Richard Biener wrote:
>>
>> Prec is almost never a constant and is heavily used from wide-int.
>>
>> We are not exploiting this undefined ness in C so I object to making this so
>> much slower.
>>
>> Can we instead do what
On 08/12/2015 12:32 PM, Richard Biener wrote:
On August 12, 2015 8:07:13 PM GMT+02:00, Jeff Law wrote:
On 08/12/2015 11:12 AM, Richard Biener wrote:
Prec is almost never a constant and is heavily used from wide-int.
We are not exploiting this undefined ness in C so I object to making
this
On August 12, 2015 8:07:13 PM GMT+02:00, Jeff Law wrote:
>On 08/12/2015 11:12 AM, Richard Biener wrote:
>
>>
>> Prec is almost never a constant and is heavily used from wide-int.
>>
>> We are not exploiting this undefined ness in C so I object to making
>this so much slower.
>>
>> Can we instead d
On 08/12/2015 11:12 AM, Richard Biener wrote:
Prec is almost never a constant and is heavily used from wide-int.
We are not exploiting this undefined ness in C so I object to making this so
much slower.
Can we instead do what we do for abs_hwi and add a checking assert so we can
move the te
On August 12, 2015 7:02:04 PM GMT+02:00, Jeff Law wrote:
>On 08/12/2015 07:33 AM, Mikael Morin wrote:
>> Le 12/08/2015 13:09, Richard Biener a écrit :
>>> On Wed, Aug 12, 2015 at 1:07 PM, Markus Trippelsdorf
>>> wrote:
On 2015.08.12 at 13:01 +0200, Richard Biener wrote:
> What kind of er
On 08/12/2015 07:33 AM, Mikael Morin wrote:
Le 12/08/2015 13:09, Richard Biener a écrit :
On Wed, Aug 12, 2015 at 1:07 PM, Markus Trippelsdorf
wrote:
On 2015.08.12 at 13:01 +0200, Richard Biener wrote:
What kind of error does ubsan run into? That is, for which 'prec'?
See: https://gcc.gnu.
Le 12/08/2015 13:09, Richard Biener a écrit :
On Wed, Aug 12, 2015 at 1:07 PM, Markus Trippelsdorf
wrote:
On 2015.08.12 at 13:01 +0200, Richard Biener wrote:
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. St
On Wed, Aug 12, 2015 at 1:07 PM, Markus Trippelsdorf
wrote:
> On 2015.08.12 at 13:01 +0200, Richard Biener wrote:
>> On Tue, Aug 11, 2015 at 9:49 PM, Jeff Law wrote:
>> > On 08/06/2015 04:25 AM, Mikael Morin wrote:
>> >>
>> >> Hello,
>> >>
>> >> this avoids an error found with bootstrap-ubsan.
>>
On 2015.08.12 at 13:01 +0200, Richard Biener wrote:
> On Tue, Aug 11, 2015 at 9:49 PM, Jeff Law 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?
> >>
On Tue, Aug 11, 2015 at 9:49 PM, Jeff Law 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
>
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
* hwint.h (sext_hwi): Rewrite without undefined behaviour on
negati
Hello,
this avoids an error found with bootstrap-ubsan.
Regression tested on x86_64-unknown-linux-gnu. OK for trunk?
Mikael
2015-08-05 Mikael Morin
* hwint.h (sext_hwi): Rewrite without undefined behaviour on
negative SRC.
diff --git a/gcc/hwint.h b/gcc/hwint.h
index 379398
26 matches
Mail list logo
