This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: help for arm avr bfin cris frv h8300 m68k mcore mmix pdp11 rs6000 sh vax
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Richard Guenther <richard dot guenther at gmail dot com>
- Cc: Bernd Schmidt <bernds_cb1 at t-online dot de>, Paolo Bonzini <bonzini at gnu dot org>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, richard dot earnshaw at arm dot com, hp at axis dot com, aldyh at redhat dot com, aoliva at redhat dot com, law at redhat dot com, nickc at redhat dot com, kazu at codesourcery dot com, ni1d at arrl dot net, kkojima at gcc dot gnu dot org, matt at 3am-software dot com
- Date: Fri, 13 Mar 2009 18:07:45 +0000 (UTC)
- Subject: Re: help for arm avr bfin cris frv h8300 m68k mcore mmix pdp11 rs6000 sh vax
- References: <f865508f0903130434i795ab1ck7c6d4e840951279@mail.gmail.com> <49BA5C4A.7030609@t-online.de> <84fc9c000903130716p74970b65sb071ad2ed090ee9d@mail.gmail.com>
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
joseph@codesourcery.com