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?
