Oleg Endo <[email protected]> writes: > On Tue, 2026-07-07 at 23:46 -0600, Jeffrey Law wrote: >> >> On 7/7/2026 11:39 AM, Sam James wrote: >> > For the PR, we'd love something backportable though, and having a patch >> > which was never on trunk isn't ideal, though it is quite targeted.. >> I certainly realize the issues here with wanting something >> backportable. But this may be one we just have to live with. >> > > What's the problem with committing & backport the hacky fix now and then, > once the infra for the more ideal solution lands, revert the commit and re- > do it on master? > > At least that would give m68k compiler users access to a recent GCC 15 and > GCC 16 today.
AFAICT, this still isn't fixed in trunk, is that right? I'm more optimistic than Jeff about the patch. It seems like it should be a robust fix in practice. I think the objection is that the patch uses a condition that (at least initially) applies to pseudo registers, whereas the actual restriction is a register allocation constraint. However, it should be impossible in practice for two different pseudos to be allocated to the same register for the same instruction when one of the pseudos is auto-modified. So I think in this case, operating on pseudos is good enough. Also, I think we'd want this patch even with register filters. Register filters would only catch the problem during RA, requiring LRA to perform a complex fix-up that would involve finding a scratch register from somewhere, which in turn would probably invalidate IRA's allocation. In contrast, the C++ condition would prevent the issue up-front and allow IRA to allocate the code "normally". So FWIW, I too would be in favour of applying this patch (or a variant) and backporting it. We could then add the register constraints on top (rather than reverting), as a belt-and-braces fix. Thanks, Richard
