On Thu, 8 Oct 2026, Richard Biener wrote: > So the issue does look more prevalent. But! We're dealing with > sequences here, not with "basic-blocks", so mips should > probably be using emit_insn_before instead of add_insn_before?
mips16_gp_pseudo_reg currently uses emit_insn_after (set, scan), which ends in add_insn_after, and that writes BB_END of the non-BB_RTL block. I tried emit_insn_before on the first real insn instead. That works for the testcase, because add_insn_before only compares against BB_HEAD and does not touch BB_END. But a plain swap crashed 7 other tests in mips.exp: when no real insn has been emitted yet, NEXT_INSN (scan) is NULL. Keeping emit_insn_after for that case fixes it: rtx_insn *insn = (NEXT_INSN (scan) ? emit_insn_before (set, NEXT_INSN (scan)) : emit_insn_after (set, scan)); With that, the testcase passes and mips.exp shows no other changes. Should I send this as v2 instead of the emit-rtl.cc change? If the more general problem needs a bigger fix in the expander, I'd rather leave that to you or Jakub: I used Claude for this, so I can only send small changes under the AI policy. Julius
