https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154
--- Comment #23 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to rguent...@suse.de from comment #21)
> > /home/seurer/gcc/git/gcc-test/libgo/go/strconv/atof.go:704:1: error:
> > unrecognizable insn:
> > 704 | func parseFloatPrefix(s string, bitSize int) (float64, int, error) {
> > | ^
> > (insn 351 350 352 35 (set (reg:SF 219 [ SR.5776 ])
> > (subreg:SF (reg:DI 237 [ GOTMP.360 ]) 0))
>
> Btw, I think this is a subreg that would be reasonable to handle.
> It's exactly the kind that x86 would like to allow, (subreg:HF (reg:SI
> ..) 0).
And it is more than reasonable for backends to *not* have to handle such
constructs. Most targets have no use for such surprising things.
The expander should never create such code in the first place, it is premature
optimisation! At expand time this should be separate statements, first taking
a SI out of a DI, and then converting it to an SF.
