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: Paolo Bonzini <bonzini at gnu dot org>
- To: Richard Guenther <richard dot guenther at gmail dot com>
- Cc: Bernd Schmidt <bernds_cb1 at t-online dot de>, "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 16:07:29 +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>
> 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?
Unfortunately it is not so simple. fold-const.c is actually wrong, as
witnessed by this program
static inline int f (int s) { return 2 << s; }
int main () { printf ("%d\n", f(33)); }
which prints 4 at -O0 and 0 at -O2 on i686-pc-linux-gnu.
This might mean either that it is easier than I thought (i.e. that all
the subtleties of the targets could be ignored), but I want to play it
safe and actually take the opportunity to fix the above problem (my
current patch does fix it).
Paolo