> On 05/08/2018 09:14 AM, Jan Hubicka wrote: > >Hi, > >with lto, incremental linking can be meaninfuly done in three ways: > > 1) read LTO file and produce non-LTO .o file > > this is current behaviour of gcc -r or ld -r with plugin > > 2) read LTO files and merge section for later LTO > > this is current behaviour of ld -r w/o plugin > > 3) read LTO files into the compiler, link them and produce > > incrementaly linked LTO object. > > > >3 makes most sense and I am maing it new default for gcc -r. For testing > >purposes > >and perhaps in order to have tool to turn LTO object into real object, we > >want > >to have 1) available as well. GCC currently have -flinker-output option that > >decides between modes that is decided by linker plugin and can be overwritten > >by user (I have forgot to document this). > > > >I am targeting for -flinker-output=rel to be incremental linking into LTO > >and adding -flinker-output=nolto-rel for 1). > > > >The main limitation of 2 and 3 is that you can not link LTO and non-LTO > >object files theger. For 2 HJ's binutils patchset has support and I think > >it can be extended to handle 3 as well. But with default binutils we want > >to warn users. This patch implements the warning (and prevents linker plugin > >to add redundat linker-ouptut options. > > This patch seems to have caused a lot of LTO tests in the G++ testsuite to > fail on bare-metal targets because of the new warning. Here's a list for > arm-none-eabi: > > 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/20091219 cp_lto_20091219_0.o-cp_lto_20091219_0.o link, -O3 > -flto > 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/pr65276 cp_lto_pr65276_0.o-cp_lto_pr65276_1.o link, -flto > -O0 -std=c++11 > 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 > > I got a similar list on the csky-elf port I'm preparing for submission, but > I didn't see any of these FAILs for csky-linux-gnu. LTO is a mysterious > black box to me, but maybe it has something to do with linking with static > vs shared libraries? Or some linker script issue? I see part 8 of this > patch series touched a whole bunch of other test cases, but not these.
I wonder what warning you get? There was PR about older binutils incorrectly complaining about object file needing a plugin when IR object file is passed after incremental link. I do not think there is a way to silence this warning from GCC side. We could use -flinker-output=nonlto-rel to avoid incremental linking in those tests but eventually we will want some test coverage :) Honza > > -Sandra
