[Bug c/48197] possible wrong code bug at -O0

["rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48197

--- Comment #8 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-03-19 12:34:55 UTC ---
(In reply to comment #7)
> I think the bug is in shorten_compare.
> We are called for GT_EXPR with op0 0LL and op1 (unsigned) (short) ((short) 0 ^
> (short) y)
> with long long result type. ^ above is BIT_XOR_EXPR with short type (shortened
> earlier, but that's fine, (unsigned) (short) ((short) 0 ^ (short y)) is still
> (unsigned) (short) y, i.e. sign extending y from 16 bits to 32 bits.  In the
> above the (short) cast doesn't really exist, it is simply a NOP_EXPR with
> unsigned int type of BIT_XOR_EXPR with short int type.
> get_narrower gives us 0LL (no change, unsignedp0 set to 0) and the short int
> BIT_XOR_EXPR (again, with unsignedp1 set to 0).  That is IMHO also fine,
> unsignedp1 says that the BIT_XOR_EXPR needs to be sign extended to the type.
> 
> But in the end shorten_compare says that the comparison just should be done in
> short int, which is wrong.

Ah, one of my special friends and endless source of wrong-code bugs ;)

Can we just remove this premature frontend optimization?