Can you please check in g++.log what kind of error you get?
Incremental linking now produce LTO objects while previously it did produce final binary. I went through testcases where this makes difference and added -flinker-output=nolto-rel for them to force original behavior.

Adding -flinker-output=nolto-rel to extra-ld-options will likely make the errors go away, but I would like to know what errors you get because I don't get them on x86-64.

Honza

Sorry about that.  The actual complaints are about a missing plugin from the loader.  I've never seen anything like that before.

gcc/testsuite/gfortran/gfortran.log:/usr/bin/ld: /tmp/ccxyE8Zx.lto.o: plugin needed to handle lto object

seurer@genoa:~/gcc/build/gcc-trunk$ ld --version
GNU ld (GNU Binutils for Ubuntu) 2.26.1

I don't see this problem on a newer system that has binutils version 2.30 on it so this is probably a problem with binutils.

I tried a couple of different versions of binutils on one system where this was occurring and it happens with binutils 2.26 but doesn't with 2.27 (and later).

Do we somehow rely on plugin auto-loading now?

For the record, I'm also seeing that ("[...]/ld: /tmp/cc[...].lto.o: plugin needed to handle lto object") on x86_64-pc-linux-gnu, with binutils/ld version 2.25.51.

If I recall correctly, old binutils issue warning when plugin produce IL file which is done for incremental linking. I do not think there is a way to prevent this message from gcc side other than requiring binutils 2.27+

One way to silence the warning would be simply to add -flinker-output=nolto-rel to all the testcases (so we do not do incremental IL linking) but it will make it still harder to add testcases for incremental link IL linking if we want to support them on older binutils somehow (i.e. by disabling the tests or tolerating false warning)

I also see these failures in my builds on x86_64-linux running Fedora 25 with stock Binutils (GNU ld version 2.26.1-1.fc25
).  The ld warning is the same:

  /usr/bin/ld: /tmp/ccIHhHfL.lto.o: plugin needed to handle lto object

From comment #6 it sounds like there are at least two options for how to deal with these failures.  Is there consensus on how to proceed?  (I build on a shared machine where I'm not sure I will be able to upgrade Binutils so I would prefer some other alternative).

$ grep ^FAIL gcc/testsuite/g++/g++.log | grep lto
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 -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/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, -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, -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 -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

*** Bug 86496 has been marked as a duplicate of this bug. ***

I wonder if we can close this based on fact that it only reproduces on sufficiently old binutils and we simply can't support incremental linking on these?

Both of our (Red Hat internal) build servers have been upgraded to Fedora 29 so we don't see the failures anymore but they will still com up on systems with older Binutils.   Is it possible to add some sort of a dg-require-xxx to prevent the tests from failing when the installed version of Binutils isn't up to par?

Created attachment 45201 [details]
gcc9-pr86004.patch

Untested testsuite fix, tested both on a system with binutils 2.25 (where those tests previously failed, now UNSUPPORTED) and recent ones (where it still PASSes).

Thanks a lot for looking into this.  Indeed disabling the tests is
probably good idea, so the patch looks good to me. Somewhere we should
document minimal binutils release supporting incremental link...

Honza

Author: jakub
Date: Tue Dec 11 10:28:39 2018
New Revision: 266974

URL: https://gcc.gnu.org/viewcvs?rev=266974&root=gcc&view=rev
Log:
	PR lto/86004
	* doc/sourcebuild.texi (lto_incremental): Document new effective
	target.

	* lib/target-supports.exp (check_effective_target_lto_incremental):
	New.
	* g++.dg/lto/pr69137_0.C: Require lto_incremental effective target.
	* g++.dg/lto/pr65316_0.C: Likewise.
	* g++.dg/lto/pr85176_0.C: Likewise.
	* g++.dg/lto/pr79000_0.C: Likewise.
	* g++.dg/lto/pr66180_0.C: Likewise.
	* g++.dg/lto/pr65193_0.C: Likewise.
	* g++.dg/lto/pr69077_0.C: Likewise.
	* g++.dg/lto/pr68057_0.C: Likewise.
	* g++.dg/lto/pr66705_0.C: Likewise.
	* g++.dg/lto/pr65302_0.C: Likewise.
	* g++.dg/lto/20091002-1_0.C: Likewise.
	* g++.dg/lto/pr81940_0.C: Likewise.
	* g++.dg/lto/pr64043_0.C: Likewise.
	* g++.dg/lto/pr65549_0.C: Likewise.
	* g++.dg/lto/pr69133_0.C: Likewise.
	* gfortran.dg/lto/pr79108_0.f90: Likewise.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/doc/sourcebuild.texi
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/g++.dg/lto/20091002-1_0.C
    trunk/gcc/testsuite/g++.dg/lto/pr64043_0.C
    trunk/gcc/testsuite/g++.dg/lto/pr65193_0.C
    trunk/gcc/testsuite/g++.dg/lto/pr65302_0.C
    trunk/gcc/testsuite/g++.dg/lto/pr65316_0.C
    trunk/gcc/testsuite/g++.dg/lto/pr65549_0.C
    trunk/gcc/testsuite/g++.dg/lto/pr66180_0.C
    trunk/gcc/testsuite/g++.dg/lto/pr66705_0.C
    trunk/gcc/testsuite/g++.dg/lto/pr68057_0.C
    trunk/gcc/testsuite/g++.dg/lto/pr69077_0.C
    trunk/gcc/testsuite/g++.dg/lto/pr69133_0.C
    trunk/gcc/testsuite/g++.dg/lto/pr69137_0.C
    trunk/gcc/testsuite/g++.dg/lto/pr79000_0.C
    trunk/gcc/testsuite/g++.dg/lto/pr81940_0.C
    trunk/gcc/testsuite/g++.dg/lto/pr85176_0.C
    trunk/gcc/testsuite/gfortran.dg/lto/pr79108_0.f90
    trunk/gcc/testsuite/lib/target-supports.exp

Fixed.