https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120165
--- Comment #16 from Mikael Pettersson <mikpelinux at gmail dot com> --- I've been tracing what goes on inside LRA for the problematic output reload, insn 106 in #c11. lra_get_insn_recog_data (<insn 106>)->sp_offset is -4 as expected due to the push in insn 47. Before final elimination the store has an address of %ap+0x14. Due to the -4 sp_offset this SHOULD be transformed into %sp+0x18. The final elimination goes lra () [lra.cc:2661] -> lra_eliminate (true, false) [lra-eliminations.cc:1552] -> process_insn_for_elimination () [lra-eliminations.cc:1412] -> eliminate_regs_in_insn () [lra-eliminations:1073] -> lra_eliminate_regs_1 (). In lra_eliminate_regs_1 () the parameters apart from insn 106 are: subst_p = 1, update_p = 0, update_sp_offset = 0, and full_p = 0. The fact that full_p = 0 causes lra_eliminate_regs_1 () to ignore the sp_offset -4 recorded for insn 106, so the offset in the plus isn't corrected and the result is %sp+0x14. As an experiment I forced full_p = 1 in the call to lra_eliminate_regs_1 (), and that did correct this particular insn.
