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.