On Fri, Mar 13, 2009 at 7:07 PM, Joseph S. Myers <jos...@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.
