On Thu, Oct 13, 2011 at 7:14 AM, Richard Kenner
<ken...@vlsi1.ultra.nyu.edu> wrote:
>> Or being fooled by the 0xfffffffc masking, perhaps.
>
> No, I'm pretty sure that's NOT the case. The *whole point* of the
> routine is to deal with that masking.
>
I got
(gdb) step
make_compound_operation (x=0x7ffff139c4c8, in_code=MEM)
at /export/gnu/import/git/gcc/gcc/combine.c:7572
7572 enum rtx_code code = GET_CODE (x);
(gdb) call debug_rtx (x)
(and:DI (plus:DI (subreg:DI (mult:SI (reg/v:SI 85 [ i ])
(const_int 4 [0x4])) 0)
(subreg:DI (reg:SI 106) 0))
(const_int 4294967292 [0xfffffffc]))
and it produces
(gdb) call debug_rtx (x)
(and:DI (plus:DI (subreg:DI (mult:SI (reg/v:SI 85 [ i ])
(const_int 4 [0x4])) 0)
(subreg:DI (reg:SI 106) 0))
(const_int 4294967292 [0xfffffffc]))
at the end. make_compound_operation doesn't know how to
restore ZERO_EXTEND.
BTW, there is a small testcase at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50696
You can reproduce it on Linux/x86-64.
--
H.J.
