This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug rtl-optimization/29797] Miscompiles bit test / set in OpenOffice
- From: "matz at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 10 Nov 2006 15:47:33 -0000
- Subject: [Bug rtl-optimization/29797] Miscompiles bit test / set in OpenOffice
- References: <bug-29797-10053@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- 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