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). 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. -- Joseph S. Myers jos...@codesourcery.com
