On Tue, Jul 7, 2026 at 2:02 PM Jeffrey Law <[email protected]> wrote: > > > > 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.
I can understand wanting to wait for a cleaner solution, but that won't help users of gcc-15 and 16 that still have this wrong-code bug. I'll post a v2 shortly that also fixes a similar issue when building Python. /Mikael
