On 06/18/2018 02:45 AM, Jan Hubicka wrote:
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.
[snip]
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 :)
It is exactly the warning newly added by this patch.
/scratch/sandra/arm-eabi-upstream/install/lib/gcc/arm-none-eabi/9.0.0/../../../../arm-none-eabi/bin/ld:
warning: incremental linking of LTO and non-LTO objects; using
-flinker-output=nolto-rel which will bypass whole program optimization
I built a completely fresh arm-none-eabi toolchain with a brand-new
binutils-gdb trunk checkout, so this isn't a problem with an old binutils.
-Sandra
