------- Comment #7 from matz at gcc dot gnu dot org 2006-11-10 15:47 ------- Just from looking at various places which handle ZERO_EXTRACT this seems to by used highly inconsistent. E.g.:
rtlanal:nonzero_bits1: Doesn't look at BITS_BIG_ENDIAN or BYTES_BIG_ENDIAN at all, but does use the bitpos to generate a mask. combine.c:find_split_point: When the destination is a zero_extract, it does adjust the bitpos when BITS_BIG_ENDIAN, but it doesn't look at BYTES_BIT_ENDIAN at all. ifcvt.c:noce_emit_move_insn: Does look at both BITS_BIG_ENDIAN _and_ BYTES_BIG_ENDIAN, and only adjusts the bitpos when both are different. A comment indicates that this is required because store_bit_field() handles the bitpos even more inconsistently :-/ So ifcvt.c:noce_try_bitop (where we think the bug is) actually uses the same method as rtlanal:nonzero_bits1, so either both are wrong or both are right. >From the documentation I would be inclined to think that both are wrong. But in that case I bet there are even more places which need a carefull look :-/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29797
