https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91376
--- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> --- > --- Comment #12 from Martin Liška <marxin at gcc dot gnu.org> --- > (In reply to r...@cebitec.uni-bielefeld.de from comment #11) >> > --- Comment #9 from Martin Liška <marxin at gcc dot gnu.org> --- >> > (In reply to r...@cebitec.uni-bielefeld.de from comment #8) >> [...] >> >> I don't see how nm would come into play here. >> > >> > I thought you see the failure for all tests. Then one could use nm to >> > identify >> > if LTO plugin is properly loaded. >> >> Ok, I see. >> >> >> $ gld.cmd >> >> ../../lto-wrapper -fresolution=cp_lto_pr90990_0.res -flinker-output=rel >> >> cp_lto_pr90990_0.o >> >> /vol/gcc/bin/gld-2.32.51: /var/tmp//ccKkavFd.lto.o: plugin needed to >> >> handle >> >> lto object >> >> [Leaving g++-dg-lto-pr90990-01.exe.lto_wrapper_args] >> >> [Leaving /var/tmp//ccKkavFd.lto.o] >> > >> > Can you please send me the *.o files so that I can investigate them? >> >> Sure, attached. > > When using current binutils master I see: > > $ ~/bin/binutils/bin/nm --version > GNU nm (GNU Binutils) 2.32.51.20190809 > > $ ~/bin/binutils/bin/nm --plugin > /dev/shm/objdir/lto-plugin/.libs/liblto_plugin.so.0.0.0 ccKkavFd.lto.o > U __gxx_personality_v0 > 00000000 W _ZN1AC1Ev > 00000000 W _ZN1AC2Ev > U _ZN1BixEi > 00000000 W _ZN1CclE1A > U _ZN1D5m_fn1Ev > 00000000 T _ZN1FC1ER1DRK1A > 00000000 T _ZN1FC2ER1DRK1A > > $ ~/bin/binutils/bin/nm ccKkavFd.lto.o > /home/marxin/bin/binutils/bin/nm: ccKkavFd.lto.o: plugin needed to handle lto > object > 00000001 C __gnu_lto_slim Same here... > So as seen, if the plugin is loaded, then I can't see the error message. ... however I *do* it from gld! >> >> There's no nm anywhere in sight. Besides, I find it very strange that >> >> out of hundreds if not thousends of LTO tests during this bootstrap, >> >> only a single one shows this error. If there were a fundamental >> >> problem, I'd expect a way larger number here. >> > >> > That's strange! The test-case is not special to me. >> >> So one would think. However, the fact that I'm not the only one seeing >> this particular failure suggests otherwise... > > Can you please send me links to the test-suite reports? I just grepped for the test name in an rsynced copy of the gcc-testresults archive. However, there's no need for that: you can easily reproduce the failure yourself. I've just ran a x86_64-pc-linux-gnu bootstrap with --with-as=/path/to/gas-2.32.51 --with-ld=/path/to/gld-2.32.51 and the current testcase was the only one that regressed. $ gld-2.32.51 --version GNU ld (GNU Binutils) 2.32.51.20190805
