https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86496
Bug ID: 86496
Summary: [9 regression] plugin required to handle lto object
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: seurer at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Somewhere in the range r260955-r260970 a change was made that is causing a
bunch of the LTO tests to fail. There were some build errors in that range
which makes it hard to bisect to the exact revision.
FAIL: g++.dg/lto/20091002-1 cp_lto_20091002-1_0.o-cp_lto_20091002-1_0.o link,
-fPIC -flto -Wno-return-type
FAIL: g++.dg/lto/pr64043 cp_lto_pr64043_0.o-cp_lto_pr64043_0.o link, -flto
-std=c++11
FAIL: g++.dg/lto/pr65193 cp_lto_pr65193_0.o-cp_lto_pr65193_0.o link, -fPIC -r
-nostdlib -flto -O2 -g -Wno-return-type
FAIL: g++.dg/lto/pr65302 cp_lto_pr65302_0.o-cp_lto_pr65302_1.o link, -flto -O2
-Wno-return-type
FAIL: g++.dg/lto/pr65316 cp_lto_pr65316_0.o-cp_lto_pr65316_1.o link, -flto
-std=c++11 -g2 -fno-lto-odr-type-merging -O2 -Wno-return-type
FAIL: g++.dg/lto/pr65549 cp_lto_pr65549_0.o-cp_lto_pr65549_0.o link,
-std=gnu++14 -flto -g -O2 -fno-inline -flto-partition=max -Wno-return-type
FAIL: g++.dg/lto/pr65549 cp_lto_pr65549_0.o-cp_lto_pr65549_0.o link,
-std=gnu++14 -flto -g -Wno-return-type
FAIL: g++.dg/lto/pr66180 cp_lto_pr66180_0.o-cp_lto_pr66180_1.o link, -flto
-std=c++14 -r -nostdlib
FAIL: g++.dg/lto/pr66705 cp_lto_pr66705_0.o-cp_lto_pr66705_0.o link, -O2 -flto
-flto-partition=max -fipa-pta
FAIL: g++.dg/lto/pr68057 cp_lto_pr68057_0.o-cp_lto_pr68057_1.o link, -O0 -flto
-flto-partition=none -fuse-linker-plugin
FAIL: g++.dg/lto/pr68057 cp_lto_pr68057_0.o-cp_lto_pr68057_1.o link, -O0 -flto
-fuse-linker-plugin -fno-fat-lto-objects
FAIL: g++.dg/lto/pr68057 cp_lto_pr68057_0.o-cp_lto_pr68057_1.o link, -O2 -flto
-flto-partition=none -fuse-linker-plugin -fno-fat-lto-objects
FAIL: g++.dg/lto/pr68057 cp_lto_pr68057_0.o-cp_lto_pr68057_1.o link, -O2 -flto
-fuse-linker-plugin
FAIL: g++.dg/lto/pr69077 cp_lto_pr69077_0.o-cp_lto_pr69077_1.o link, -O3 -g
-flto
FAIL: g++.dg/lto/pr69133 cp_lto_pr69133_0.o-cp_lto_pr69133_1.o link, -flto -O2
FAIL: g++.dg/lto/pr69137 cp_lto_pr69137_0.o-cp_lto_pr69137_0.o link,
-std=c++11 -g -flto
FAIL: g++.dg/lto/pr79000 cp_lto_pr79000_0.o-cp_lto_pr79000_1.o link, -flto -g
FAIL: g++.dg/lto/pr81940 cp_lto_pr81940_0.o-cp_lto_pr81940_0.o link, -O -flto
FAIL: g++.dg/lto/pr85176 cp_lto_pr85176_0.o-cp_lto_pr85176_0.o link, -flto -g1
FAIL: gfortran.dg/lto/pr79108 f_lto_pr79108_0.o-f_lto_pr79108_0.o link, -Ofast
-flto --param ggc-min-expand=0 --param ggc-min-heapsize=0
spawn -ignore SIGHUP
/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++7/../../xg++
-B/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++7/../../ cp_lto_pr64043_0.o
-fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++
-I/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/libsupc++
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/include/backward
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/testsuite/util -fmessage-length=0
-flto -std=c++11 -r -nostdlib -O2
-L/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs
-B/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs
-L/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs
-B/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libitm/
-L/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libitm/.libs
-o g++-dg-lto-pr64043-01.exe
/usr/bin/ld: /tmp/ccXKXOCe.lto.o: plugin needed to handle lto object
FAIL: g++.dg/lto/pr64043 cp_lto_pr64043_0.o-cp_lto_pr64043_0.o link, -flto
-std=c++11
ld --version
GNU ld (GNU Binutils for Ubuntu) 2.26.1
Note that with binutils 2.27 it works fine.
IIRC there is some issue with binutils for a few revisions that can trigger
this but is there something that can be done to prevent all these tests from
failing? Should gcc be dependent on certain builds of binutils?
