On Tue, 17 Nov 2015, Paolo Bonzini wrote:
> On 17/11/2015 17:02, Joseph Myers wrote:
> > On Tue, 17 Nov 2015, Paolo Bonzini wrote:
> >
> >> * it doesn't promise that GCC will never rely on undefined behavior
> >> rules for signed left shifts
> >
> > I think we should remove the ", but this is su
On 17/11/2015 17:02, Joseph Myers wrote:
> On Tue, 17 Nov 2015, Paolo Bonzini wrote:
>
>> * it doesn't promise that GCC will never rely on undefined behavior
>> rules for signed left shifts
>
> I think we should remove the ", but this is subject to change" in
> implement-c.texi (while replacin
On 17/11/2015 17:02, Joseph Myers wrote:
> On Tue, 17 Nov 2015, Paolo Bonzini wrote:
>
>> * it doesn't promise that GCC will never rely on undefined behavior
>> rules for signed left shifts
>
> I think we should remove the ", but this is subject to change" in
> implement-c.texi (while replacin
On Tue, 17 Nov 2015, Paolo Bonzini wrote:
> * it doesn't promise that GCC will never rely on undefined behavior
> rules for signed left shifts
I think we should remove the ", but this is subject to change" in
implement-c.texi (while replacing it with noting that ubsan will still
diagnose such c
On 17/11/2015 16:27, Joseph Myers wrote:
> > Can you suggest a wording for "if the GNU C language definition changes
> > [which, no matter how unlikely, is explicitly not ruled out by the
> > manual] -fwrapv will be extended to signed shifts, and shifts of
> > negative numbers would return A*2^B
On Tue, 17 Nov 2015, Paolo Bonzini wrote:
> Can you suggest a wording for "if the GNU C language definition changes
> [which, no matter how unlikely, is explicitly not ruled out by the
> manual] -fwrapv will be extended to signed shifts, and shifts of
> negative numbers would return A*2^B whenever
On 17/11/2015 13:58, Joseph Myers wrote:
>> > GCC's -fwrapv option does not affect code generation for shifts
>> > because currently GCC does not rely on the fact that certain
>> > signed shifts trigger undefined behavior. However, the definition
>> > of signed arithmetic overflow does extend to
On Tue, 17 Nov 2015, Paolo Bonzini wrote:
> GCC's -fwrapv option does not affect code generation for shifts
> because currently GCC does not rely on the fact that certain
> signed shifts trigger undefined behavior. However, the definition
> of signed arithmetic overflow does extend to shifts; it
GCC's -fwrapv option does not affect code generation for shifts
because currently GCC does not rely on the fact that certain
signed shifts trigger undefined behavior. However, the definition
of signed arithmetic overflow does extend to shifts; it is only
code generation that is limited to addition
