https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154
--- Comment #21 from rguenther at suse dot de <rguenther at suse dot de> --- On Thu, 9 Sep 2021, seurer at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154 > > --- Comment #19 from seurer at gcc dot gnu.org --- > This also prevents gcc from being built if it includes go on powerpc LE: > > libtool: compile: /home/seurer/gcc/git/build/gcc-test/./gcc/gccgo > -B/home/seurer/gcc/git/build/gcc-test/./gcc/ > -B/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/bin/ > -B/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/lib/ > -isystem > /home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/include > -isystem > /home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/sys-include > -O2 -g -I . -c -fgo-pkgpath=strconv > /home/seurer/gcc/git/gcc-test/libgo/go/strconv/atob.go > /home/seurer/gcc/git/gcc-test/libgo/go/strconv/atoc.go > /home/seurer/gcc/git/gcc-test/libgo/go/strconv/atof.go > /home/seurer/gcc/git/gcc-test/libgo/go/strconv/atoi.go > /home/seurer/gcc/git/gcc-test/libgo/go/strconv/bytealg.go > /home/seurer/gcc/git/gcc-test/libgo/go/strconv/ctoa.go > /home/seurer/gcc/git/gcc-test/libgo/go/strconv/decimal.go > /home/seurer/gcc/git/gcc-test/libgo/go/strconv/doc.go > /home/seurer/gcc/git/gcc-test/libgo/go/strconv/eisel_lemire.go > /home/seurer/gcc/git/gcc-test/libgo/go/strconv/ftoa.go > /home/seurer/gcc/git/gcc-test/libgo/go/strconv/ftoaryu.go > /home/seurer/gcc/git/gcc-test/libgo/go/strconv/isprint.go > /home/seurer/gcc/git/gcc-test/libgo/go/strconv/itoa.go > /home/seurer/gcc/git/gcc-test/libgo/go/strconv/quote.go -fPIC -o > .libs/strconv.o > /home/seurer/gcc/git/gcc-test/libgo/go/strconv/atof.go: In function > 'strconv.parseFloatPrefix': > /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).
