https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63603
Tobias Burnus <burnus at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |NEW
--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #1)
> Do you use a linker plugin with LTO? That is, what's the value of
> HAVE_LTO_PLUGIN configure computes for you?
./gcc/auto-host.h:#define HAVE_LTO_PLUGIN 2
> Do you happen to run a binutils and have lto_plugin.so installed as
> auto-load?
No idea, whether it does for some reasons automatically. I have:
* An ancient binutils-2.20.51.0.2 under /usr/bin, which doesn't support plugins
* A self-built binutils-gdb trunk, configured with:
--prefix=... --with-python LDFLAGS=-L.../python/lib --enable-plugins
and built with the system GCC 4.4
* GCC 5 configured with
--prefix=... --with-plugin-ld=/local_users/.../bin/ld --enable-languages=...
> It seems that lto-plugin.c doesn't reject objects if COLLECT_GCC_OPTIONS
> contains -fno-lto (but only -fno-use-linker-plugin). Thus can you try
> if [... patch for lto-plugin/lto-plugin.c ...] fixes it for you?
Unfortunately, it doesn't. I tried linking with only -flto and with
additionally -fno-use-linker-plugin or -fuse-linker-plugin. And with and
without placing the self-compiled "ld" in the PATH.
Plus the same with and without your patch. In all case, I get the lto1 in the
output. Example:
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/data/local_users/tobiasb/gcc/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper
[...]
COLLECT_GCC_OPTIONS='-v' '-fno-use-linker-plugin' '-fno-lto' '-mtune=generic'
'-march=x86-64'
[...]/collect2 [...]
[...]
COLLECT_GCC_OPTIONS='-c' '-fmath-errno' '-fsigned-zeros' '-ftrapping-math'
'-fno-trapv' '-fno-strict-overflow' '-mtune=generic' '-march=x86-64' '-v'
'-fno-use-linker-plugin' '-mtune=generic' '-march=x86-64'
'-fltrans-output-list=/tmp/cc8XPZLu.ltrans.out' '-fwpa'
[...]/lto1 [...]
[...]
