http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52306
Alexandre Oliva <aoliva at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Last reconfirmed| |2012-03-25 CC| |bernds at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #2 from Alexandre Oliva <aoliva at gcc dot gnu.org> 2012-03-25 13:46:43 UTC --- FWIW, the problem is AFAICT still present in mainline, but it is latent, for the testcase no longer triggers the problem that 4.6 did. The only change I could find to relevant portions of the reload code was the fix for bug 47976, but it doesn't seem to fix this particular issue. Regardless, maybe Bernd can offer some guidance since he's the reload expert ;-) In GCC 4.6 r185770, the reloads for insn 288 are: Reloads for insn # 288 Reload 0: reload_in (SI) = (post_inc:SI (reg:SI 145 [ ivtmp.76 ])) reload_out (SI) = (post_inc:SI (reg:SI 145 [ ivtmp.76 ])) ADDR_REGS, RELOAD_FOR_OPERAND_ADDRESS (opnum = 1), inc by 4 reload_in_reg: (post_inc:SI (reg:SI 145 [ ivtmp.76 ])) reload_reg_rtx: (reg:SI 9 %a1) Reload 1: reload_out (SI) = (reg/f:SI 124 [ D.1788 ]) GENERAL_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional reload_out_reg: (reg/f:SI 124 [ D.1788 ]) Reload 2: reload_in (SI) = (mem/f:SI (post_inc:SI (reg:SI 145 [ ivtmp.76 ])) [5 MEM[base: D.1889_285, offset: 0B]+0 S4 A16]) GENERAL_REGS, RELOAD_FOR_INPUT (opnum = 1), optional reload_in_reg: (mem/f:SI (post_inc:SI (reg:SI 145 [ ivtmp.76 ])) [5 MEM[base: D.1889_285, offset: 0B]+0 S4 A16]) in GCC trunk r185451, the same insn is numbered 296, and it has a single reload, for both pseudos already got REGs: Reload 0: reload_in (SI) = (mem/f:SI (post_inc:SI (reg:SI 9 %a1 [orig:110 ivtmp.82 ] [110])) [4 MEM[base: D.1990_299, offset: 0B]+0 S4 A16]) GENERAL_REGS, RELOAD_FOR_INPUT (opnum = 1), optional reload_in_reg: (mem/f:SI (post_inc:SI (reg:SI 9 %a1 [orig:110 ivtmp.82 ] [110])) [4 MEM[base: D.1990_299, offset: 0B]+0 S4 A16])