https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78660
--- Comment #13 from mpf at gcc dot gnu.org --- (In reply to Eric Botcazou from comment #12) > > Maybe the load sign-extends instead of zero-extending as specified > > initially. > > But I'm not sure that this matters here, since: > > (insn 58 57 59 3 (set (subreg:SI (reg:DI 316 [ iftmp.3_114 ]) 0) > (ne:SI (reg/f:DI 469 [ current_scope.1_1->bindings ]) > (const_int 0 [0]))) > "/althome/mips/v6/src/gcc/gcc/c/c-decl.me.c":915 501 {*sne_zero_disi} > (expr_list:REG_DEAD (reg/f:DI 469 [ current_scope.1_1->bindings ]) > (nil))) > > can put only 0 or 1 in the SUBREG, can't it? Yes, that is true but the upper 32-bits still need to be 'zero'. What happens later on is that the (subreg:SI (reg:DI 316)) is spilled, spilling only 32-bits to the stack but it gets reloaded as DImode/64-bit. The upper-32 bits are junk. I don't believe that is an LRA bug as it is doing exactly what is described by the subreg. The original zero_extend in insn 58 to DImode is therefore very important here and cannot be converted to a subreg. (I haven't got to the specific combine rule yet that is doing this substitution to see which decision is bad.)