https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89019
Bug ID: 89019
Summary: LTO and gccgo cause ICE during free_lang_data
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: nikhil.benesch at gmail dot com
CC: cmang at google dot com
Target Milestone: ---
Created attachment 45515
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45515&action=edit
patch for a partial fix
Attempting to compile the following Go program
package main
type fcanary func()
with LTO enabled results in the following ICE:
go1: internal compiler error: in fld_incomplete_type_of, at tree.c:5296
0x17858e2 fld_incomplete_type_of
../../gcc/tree.c:5295
0x1786016 fld_simplified_type
../../gcc/tree.c:5374
0x1787f66 free_lang_data_in_decl
../../gcc/tree.c:5746
0x1789895 free_lang_data_in_cgraph
../../gcc/tree.c:6175
0x1789a32 free_lang_data
../../gcc/tree.c:6216
0x1789bf8 execute
../../gcc/tree.c:6288
System details:
gcc version 9.0.0 20190118 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-fsplit-stack' '-v' '-save-temps' '-flto' '-o'
'a.out' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
/home/benesch/opt/libexec/gcc/x86_64-pc-linux-gnu/9.0.0/go1 crash2.go
-quiet -dumpbase crash2.go -mtune=generic -march=x86-64 -auxbase crash2
-version -fsplit-stack -flto
-L/home/benesch/opt/lib/gcc/x86_64-pc-linux-gnu/9.0.0
-L/home/benesch/opt/lib/gcc/x86_64-pc-linux-gnu/9.0.0/../../../../lib64
-L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu
-L/home/benesch/opt/lib/gcc/x86_64-pc-linux-gnu/9.0.0/../../../../x86_64-pc-linux-gnu/lib
-L/home/benesch/opt/lib/gcc/x86_64-pc-linux-gnu/9.0.0/../../.. -o crash2.s
GNU Go (GCC) version 9.0.0 20190118 (experimental)
(x86_64-pc-linux-gnu)
compiled by GNU C version 7.3.0, GMP version 6.1.2, MPFR
version 4.0.1, MPC version 1.1.0, isl version isl-0.18-GMP
The details are rather involved. The pass that fails, free_lang_data, is only
run when compiling with LTO. This pass, as it walks the tree, makes various
assertions about the canonical type equivalence of the middle-end's expression
tree. It appears that the Go frontend is not always installing (or rather,
uninstalling) canonical types where it should, but only the free_lang_data pass
notices. It seems like this might result in subtle pointer-aliasing bugs, but
I'm not nearly familiar enough with GCC to say.
I've attached a patch that fixes the minimal reproduction I posted.
Unfortunately, in adding test coverage, I've discovered that
gcc/testsuite/go.go-torture/execute/names-1.go fails when compiled with LTO,
even with the provided patch applied. I'll post updates as I have them, but I'm
pretty out of my depth here.
