On 7/7/2026 4:47 AM, Mikael Pettersson wrote:
Since gcc-15 combine can produce moves from a PRE_DEC source to a
destination that uses the same register, causing wrong code on m68k.
In particular the glibc build is broken. This adjusts the m68k
backend to reject such moves:
move.l -(%a0),(%a0,%d0.l)
and instead emit:
lea (%a0,%d0.l),%a1
move.l -(%a0),(%a1)
Bootstrapped and regression tested on m68k-linux-gnu, no regressions.
Ok for trunk? And maybe gcc-16/15 after a week?
gcc/
2026-07-07 Mikael Pettersson <[email protected]>
PR rtl-optimization/123853
* config/m68k/m68k-protos.h (check_move_simode): Declare.
* config/m68k/m68k.cc (check_move_simode): New, reject moves from
a pre-dec source mem whose reg occurs in the destination address.
* config/m68k/m68k.md (*movsi_m68k): Add check_move_simode to
condition.
(*movsi_m68k2): Likewise.
I think the new dynamic register filters are going to be the way to
handle this. The core issue is those additional uses of a
auto-incremented register, which requires looking at two operands to
determine if the insn matches its constraints. This patch just papers
over the problem and it likely triggers elsewhere in the port with some
effort.
My recommendation is to wait until Pan Li's work to utilize the dynamic
register filtering lands in the RISC-V port across the board and gets a
time to shake out any additional LRA gotchas, then use it on the m68k,
h8 and pdp11 which all have the same core problem.
Jeff
