> On Jul 7, 2026, at 8:02 AM, 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 dealt with it in pdp11.md in a different way, using a string of constraints
to express this. It seems to work but it's rather cumbersome.
I didn't really understand how the patch addresses the issue. My thought was
that we're dealing with a constraint here, so expressing it as such seemed
logical. But this patch certainly is simpler.
paul
