https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117182
--- Comment #7 from Oleg Endo <olegendo at gcc dot gnu.org> --- I've posted the patch https://gcc.gnu.org/pipermail/gcc-patches/2026-March/709649.html but it has raised some concerns. Here's a quick summary of the points mentioned in the discussion: The core problem is that LRA changes the alternative selection of an insn without validating that the change is valid with regard to CPU/FPU-mode switching. In this particular case, an alternative of insn movsf_ie_ra is selected that does not have any FPU-mode requirement and LRA replaces it with an alternative that requires single-precision mode. The insn becomes invalid because the currently selected FPU-mode is double-precision at that point in the insn stream. It could probably be avoided by rewriting SH's FPU related move insns and making sure that changing insn alternatives will not change the FPU-mode requirement for the insn. Effectively this will restrict the mode-switching from per-alternative to per-insn. However, there could be still a possibility that LRA decides to replace the whole insn with another move insn and that would hit the same problem again. Right now it's not directly possible to determine the current CPU/FPU-mode state at a given point in the insn stream. The CPU/FPU-mode state information is not stored anywhere after mode-switching.cc has finished its job. However, the current state can be figured out by e.g. using df-analysis to find the last effective insn that modifies the FPSCR mode bits. It looks like this issue will need to be resolved also in order to do PR 64305.
