On Tue, 23 Jun 2026, Oleg Endo wrote: > Hi all, > > On Tue, 2026-03-03 at 08:07 -0700, Jeffrey Law wrote: > > On 3/2/2026 10:11 PM, Oleg Endo wrote: > > > > > > > > > > > Please let me know what you find out and your thoughts on this. > > > Will do. It's in my gcc-17 queue :-) > > > I'd like to bring this issue up again. For reference, the PR is > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117182 > > and the discussion stopped here > https://gcc.gnu.org/pipermail/gcc-patches/2026-March/710309.html > > > According to my understanding, we came to the rough conclusion: > > - To fix it "the right way", LRA needs to validate its insn changes against > mode-switching states > > - For that some mode-switching API extension will be required > > - As of today nothing after the mode-switching pass validates insn changes > w.r.t. the implicit mode switching states. It just happens to blow up with > LRA first because it changes/inserts move insns, which are subject to mode > switching on SH.
To me this sounds like trying to move mode switching way later might be more feasible as even if you fix LRA any other pass might perform similar errorneous transforms? > So this makes it look more like a general infrastructure issue rather than > target issue to me. The failure mode is silent wrong-code in floating-point > heavy code. It shows up only at runtime, is not caught by bootstrap and is > a borderline heisenbug as it highly depends on surrounding code and > optimizations, which makes it very easy to declare "fixed" when > it isn't. > > Because of that, I firmly believe this should be addressed first before > landing the final SH LRA conversion patches. > > My concern is that the folks still building and running real software on > real SH4 hardware rarely file bugs upstream. When the toolchain miscompiles > their code, that often stays in the inner circles, the new compiler version > is declared to be "fundamentally broken", they stop updating, and drift > toward out-of-tree alternatives. So a miscompiling-but-LRA-clean backend > wouldn't show up as open PRs; it would just silently erode the remaining > user base while looking fine on the surface. > > The LRA conversion work itself is essentially ready. What's currently > missing is the fix for the mode-switching/LRA interaction, and that's beyond > what I can resource myself. Without knowing anything on the technical detail (esp. not about mode switching and its implementation), and without being able to make the promise that reload will really be gone for GCC 17 (but I hope so), in the end you'll still face the problem that without reload you either have to use LRA or have no working SH port. I'd also say that the earlier you switch to LRA the more coverage you'll get - there might be other unknown issues. But I also get what you say above, but this sounds like communicating the fact to the SH user community is what's required - there's nothing we can do here. Richard. > Jeff, since you'd put it in your gcc-17 queue, do you have a rough > plan or timeline you can share? > > Best regards, > Oleg Endo > > > -- Richard Biener <[email protected]> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Jochen Jaser, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
