This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug debug/83758] ICE building gccgo on powerpc64le --with-cpu=power8
- From: "acsawdey at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 25 Jan 2018 14:35:42 +0000
- Subject: [Bug debug/83758] ICE building gccgo on powerpc64le --with-cpu=power8
- Auto-submitted: auto-generated
- References: <bug-83758-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83758
--- Comment #22 from acsawdey at gcc dot gnu.org ---
On genoa (power8, glibc 2.22 or 2.23) this compile always ICEs regardless of
how gcc was built:
/home/sawdey/src/gcc/trunk/build/./gcc/gccgo
-B/home/sawdey/src/gcc/trunk/build/./gcc/
-B/home/sawdey/install/gcc/trunk/powerpc64le-unknown-linux-gnu/bin/
-B/home/sawdey/install/gcc/trunk/powerpc64le-unknown-linux-gnu/lib/ -isystem
/home/sawdey/install/gcc/trunk/powerpc64le-unknown-linux-gnu/include -isystem
/home/sawdey/install/gcc/trunk/powerpc64le-unknown-linux-gnu/sys-include -O2
-mcpu=power8 -g -I . -c -fgo-pkgpath=cmd/go/internal/work
../../../trunk/libgo/go/cmd/go/internal/work/action.go
../../../trunk/libgo/go/cmd/go/internal/work/build.go
../../../trunk/libgo/go/cmd/go/internal/work/buildid.go
../../../trunk/libgo/go/cmd/go/internal/work/exec.go
../../../trunk/libgo/go/cmd/go/internal/work/gc.go
../../../trunk/libgo/go/cmd/go/internal/work/gccgo.go
../../../trunk/libgo/go/cmd/go/internal/work/init.go -o cmd/go/internal/work.o
I've tried:
configure --enable-languages=c,c++,go --enable-bootstrap --with-cpu=power6
configure --enable-languages=c,c++,go --disable-bootstrap --with-cpu=power4
and various combinations of the system gcc (5.4.0) and AT10 (6.4.1) without
success.
Bootstrap will succeed if you use --with-cpu=powerN where N<8 but that is just
because the above compile succeeds for that case. If you use the compiler built
that way and try the compilation above which includes -mcpu=power8, it fails.
So unless somebody does have a way to reproduce the command above succeeding
(with split-stack enabled) I feel like we can rule out the allegation that this
bug is dependent on how the compiler itself is built.