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: Richard Guenther <richard dot guenther at gmail dot com>
- To: "Joseph S. Myers" <joseph at codesourcery 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 19:18:53 +0100
- 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> <Pine.LNX.4.64.0903131758420.3511@digraph.polyomino.org.uk>
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.