>>> 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.
>
> But this is because i?86 doesn't define SHIFT_COUNT_TRUNCATED, no?
Yes, so fold-const.c is *not* modeling the target in this case.
But on the other hand, this means we can get by with documenting the
effect of a conservative truncation mask: no wrong code bugs, just
differences between optimization levels for undefined programs. I'll
check that the optimizations done based on the truncation mask are all
conservative or can be made so.
So, I'd still need the information for arm and m68k, because that
information is about the bitfield instructions. For rs6000 it would be
nice to see what they do for 64-bits (for 32-bit I know that PowerPCs
truncate to 6 bits, not 5). But for the other architectures, we can be
conservative.
Paolo
