This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: help for arm avr bfin cris frv h8300 m68k mcore mmix pdp11 rs6000 sh vax


On Fri, Mar 13, 2009 at 7:07 PM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
> On Fri, 13 Mar 2009, Richard Guenther wrote:
>
>> Hm. ?In fold-const.c we try to make sure to produce the same result
>> as the target would for constant-folding shifts. ?Thus, Paolo, I think
>> what fold-const.c does is what we should assume for
>> !SHIFT_COUNT_TRUNCATED. ?No?
>
> I think attempting the same result as the target for this undefined
> behavior is a pretty futile endeavour; I think we also optimize in places
> on the basis of it being undefined. ?We don't attempt to generate the same
> results at compile time and runtime for out of range floating-point to
> integer conversions (unspecified value according to C99 Annex F, so we
> don't need to generate the same results), which has actually attracted bug
> reports; there, some languages may place more precise requirements on what
> the results are (e.g. bug 28144).

Last time I sent a patch to remove the SHIFT_COUNT_TRUNCATED check
from fold-const.c the reason that this was rejected was that we want to
be consistend with target behavior...

> This does not of course rule out adding options in future (and associated
> tree codes) that make this defined (probably making negative shifts act
> like shifts in the opposite direction, and out-of-range shifts act like
> shifting one bit at a time, rather than using target-specific semantics)
> or causing the undefined cases to generate traps.
>
> As I understand it, SHIFT_COUNT_TRUNCATED is about the semantics of RTL,
> and has no bearing on the implemented semantics of any source language or
> of GENERIC or GIMPLE; GENERIC and GIMPLE both follow the rule that
> out-of-range shifts (or rotates?), including those by negative amounts,
> are undefined.

"Undefined" is a bad semantic for GIMPLE.  If the frontends want the middle-end
to take advantage of undefinedness it needs to translate it to a useful defined
state.

Richard.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]