[Bug lto/69188] ICE when linking objects at different optimization levels with LTO and profile generation enabled. (Works with 4.9.3.)

anthonyfk at gmail dot com gcc-bugzilla@gcc.gnu.org
Tue Jan 24 21:44:00 GMT 2017


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69188

anthonyfk at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #28 from anthonyfk at gmail dot com ---
The plot thickens.

Before trying a newer gcc, I ran a quick sanity check to make sure that the bug
in comment 26 was repeatable. It compiled fine! So I set the compilation of
lapack-3.6.1 up in a loop which would break on failure. After several
iterations I got a different failure:

lto1: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2761
0x54dcb9 read_cgraph_and_symbols
        /tmp/solido-build-20170120/gcc-6.3.0/gcc/lto/lto.c:2761
0xc9045a lto_main()
        /tmp/solido-build-20170120/gcc-6.3.0/gcc/lto/lto.c:3310
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
lto-wrapper: fatal error: /usr/local/solido/tools/20170120/bin/gfortran
returned 1 exit status
compilation terminated.
/usr/local/solido/tools/20170120/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:134: ../xeigtstc] Error 1

My best guess is that this is some race condition (I have 12 cores going at
once) but I can't imagine how. Regardless, I'm convinced that this is a
different issue that may have more to do with the environment than gcc. Sorry
for the noise! If I have time, I'll try to make a reduced, reproducible case as
a new bug.

Thanks again!


More information about the Gcc-bugs mailing list