http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56184
Ulrich Weigand <uweigand at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |vmakarov at gcc dot gnu.org --- Comment #6 from Ulrich Weigand <uweigand at gcc dot gnu.org> 2013-02-06 19:40:30 UTC --- The problem occurs with the following insn: (insn 539 383 384 46 (set (reg:DI 355 [313]) (const_int 256 [0x100])) test.ii:128 643 {*movdi_vfp} (expr_list:REG_EQUIV (const_int 256 [0x100]) (nil))) Register 355 is recognized as always-equal to the constant 256, and insn 539 is the insn that originally sets up the equivalence. If the register doesn't get a hard reg, what ought to happen is that users of reg 355 get replaced by the constant, and the insn setting the equivalence ought to be deleted. Because the insn will get deleted anyway, it also ought to be skipped for find_reloads. To achieve that, reg_equiv_constant(355) should hold the constant, and reg_equiv_init(355) should point to the above insn. However, what actually happens in this test case is that reg_equiv_init(355) is NULL. Therefore, the insn is *not* skipped for find_reloads, which then aborts since it tries to push an output reload for an always-constant register, which is not supposed to happen. Now the register is somewhat special in that it was created by IRA via live range splitting. The original register was reg 313; and this still has reg_equiv_init(313) pointing to the above insn. However, reg_equiv_init(355) is NULL. There is a routine fix_reg_equiv_init in ira.c which appears to be intended to fix the reg_equiv_init settings of new registers created by live range splitting. However, this doesn't seem to have worked in this case ... Unfortunately I'm not really familiar with the live range splitting code; maybe Vladimir can help with this?