* [Bug lto/63603] [4.9/5 Regression] Linking with -fno-lto still invokes LTO
2014-10-20 13:58 [Bug lto/63603] New: [4.9/5 Regression] Linking with -fno-lto still invokes LTO burnus at gcc dot gnu.org
@ 2014-10-20 15:22 ` burnus at gcc dot gnu.org
2014-10-21 8:59 ` rguenth at gcc dot gnu.org
` (8 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: burnus at gcc dot gnu.org @ 2014-10-20 15:22 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63603
Tobias Burnus <burnus at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |4.9.2
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug lto/63603] [4.9/5 Regression] Linking with -fno-lto still invokes LTO
2014-10-20 13:58 [Bug lto/63603] New: [4.9/5 Regression] Linking with -fno-lto still invokes LTO burnus at gcc dot gnu.org
2014-10-20 15:22 ` [Bug lto/63603] " burnus at gcc dot gnu.org
@ 2014-10-21 8:59 ` rguenth at gcc dot gnu.org
2014-10-21 9:50 ` burnus at gcc dot gnu.org
` (7 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-10-21 8:59 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63603
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |WAITING
Last reconfirmed| |2014-10-21
CC| |rguenth at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
I'm quite sure I tested that -fno-lto works.
> gcc-4.9 -flto -ffat-lto-objects -c t.c
> gcc-4.9 t.o -fno-lto -v 2>&1 | grep lto1
<nothing>
indeed it does.
> gcc-4.9 t.o -v 2>&1 | grep lto1
/usr/lib64/gcc/x86_64-suse-linux/4.9/lto1 -quiet -dumpbase t.o -mtune=generic
-march=x86-64 -mtune=generic -march=x86-64 -auxbase t -version -fno-trapv
-fno-strict-overflow -fltrans-output-list=/tmp/ccRx0SND.ltrans.out -fwpa
-fresolution=/tmp/ccnlyyYA.res @/tmp/ccesvcXD
/usr/lib64/gcc/x86_64-suse-linux/4.9/lto1 -quiet -dumpbase ccRx0SND.ltrans0.o
-mtune=generic -march=x86-64 -mtune=generic -march=x86-64 -auxbase-strip
/tmp/ccRx0SND.ltrans0.ltrans.o -version -fno-trapv -fno-strict-overflow
-fltrans-output-list=/tmp/ccRx0SND.ltrans.out -fltrans @/tmp/ccq0naMZ -o
/tmp/cchrU6el.s
Do you use a linker plugin with LTO? That is, what's the value of
HAVE_LTO_PLUGIN
configure computes for you?
Do you happen to run a binutils and have lto_plugin.so installed as auto-load?
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
Index: lto-plugin/lto-plugin.c
===================================================================
--- lto-plugin/lto-plugin.c (revision 216464)
+++ lto-plugin/lto-plugin.c (working copy)
@@ -1071,7 +1071,8 @@ onload (struct ld_plugin_tv *tv)
for the case where it is auto-loaded by BFD. */
char *collect_gcc_options = getenv ("COLLECT_GCC_OPTIONS");
if (collect_gcc_options
- && strstr (collect_gcc_options, "'-fno-use-linker-plugin'"))
+ && (strstr (collect_gcc_options, "'-fno-use-linker-plugin'")
+ || strstr (collect_gcc_options, "'-fno-lto'")))
return LDPS_ERR;
fixes it for you?
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug lto/63603] [4.9/5 Regression] Linking with -fno-lto still invokes LTO
2014-10-20 13:58 [Bug lto/63603] New: [4.9/5 Regression] Linking with -fno-lto still invokes LTO burnus at gcc dot gnu.org
2014-10-20 15:22 ` [Bug lto/63603] " burnus at gcc dot gnu.org
2014-10-21 8:59 ` rguenth at gcc dot gnu.org
@ 2014-10-21 9:50 ` burnus at gcc dot gnu.org
2014-10-21 10:18 ` burnus at gcc dot gnu.org
` (6 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: burnus at gcc dot gnu.org @ 2014-10-21 9:50 UTC (permalink / raw)
To: gcc-bugs
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 [...]
[...]
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug lto/63603] [4.9/5 Regression] Linking with -fno-lto still invokes LTO
2014-10-20 13:58 [Bug lto/63603] New: [4.9/5 Regression] Linking with -fno-lto still invokes LTO burnus at gcc dot gnu.org
` (2 preceding siblings ...)
2014-10-21 9:50 ` burnus at gcc dot gnu.org
@ 2014-10-21 10:18 ` burnus at gcc dot gnu.org
2014-10-21 11:53 ` rguenther at suse dot de
` (5 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: burnus at gcc dot gnu.org @ 2014-10-21 10:18 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63603
--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Tobias Burnus from comment #2)
> COLLECT_GCC_OPTIONS='-v' '-fno-use-linker-plugin' '-fno-lto'
> '-mtune=generic' '-march=x86-64'
> [...]/collect2 [...]
I haven't shown it, but the collect2 arguments doesn't contain the -fno-lto,
only COLLECT_GCC_OPTIONS has it.
And in collect2.c's main(), there is a check for
else if (!strncmp (argv[i], "-fno-lto", 8))
lto_mode = LTO_MODE_NONE;
but that only operates on argv and not on COLLECT_GCC_OPTIONS.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug lto/63603] [4.9/5 Regression] Linking with -fno-lto still invokes LTO
2014-10-20 13:58 [Bug lto/63603] New: [4.9/5 Regression] Linking with -fno-lto still invokes LTO burnus at gcc dot gnu.org
` (3 preceding siblings ...)
2014-10-21 10:18 ` burnus at gcc dot gnu.org
@ 2014-10-21 11:53 ` rguenther at suse dot de
2014-10-22 8:42 ` burnus at gcc dot gnu.org
` (4 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: rguenther at suse dot de @ 2014-10-21 11:53 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63603
--- Comment #4 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 21 Oct 2014, burnus at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63603
>
> --- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> ---
> (In reply to Tobias Burnus from comment #2)
> > COLLECT_GCC_OPTIONS='-v' '-fno-use-linker-plugin' '-fno-lto'
> > '-mtune=generic' '-march=x86-64'
> > [...]/collect2 [...]
>
> I haven't shown it, but the collect2 arguments doesn't contain the -fno-lto,
> only COLLECT_GCC_OPTIONS has it.
>
> And in collect2.c's main(), there is a check for
> else if (!strncmp (argv[i], "-fno-lto", 8))
> lto_mode = LTO_MODE_NONE;
> but that only operates on argv and not on COLLECT_GCC_OPTIONS.
That means that
/* We pass any -flto flags on to the linker, which is expected
to understand them. In practice, this means it had better be collect2.
*/
/* %{e*} includes -export-dynamic; see comment in common.opt. */
#ifndef LINK_COMMAND_SPEC
#define LINK_COMMAND_SPEC "\
%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S:\
%(linker) " \
LINK_PLUGIN_SPEC \
"%{flto|flto=*:%<fcompare-debug*} \
%{flto} %{flto=*} %l " LINK_PIE_SPEC \
doesn't pass on -fno-lto as expected. Does adding %{fno-lto} after
%{flto} work?
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug lto/63603] [4.9/5 Regression] Linking with -fno-lto still invokes LTO
2014-10-20 13:58 [Bug lto/63603] New: [4.9/5 Regression] Linking with -fno-lto still invokes LTO burnus at gcc dot gnu.org
` (4 preceding siblings ...)
2014-10-21 11:53 ` rguenther at suse dot de
@ 2014-10-22 8:42 ` burnus at gcc dot gnu.org
2014-10-22 8:48 ` rguenther at suse dot de
` (3 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: burnus at gcc dot gnu.org @ 2014-10-22 8:42 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63603
--- Comment #5 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to rguenther@suse.de from comment #4)
> That means that
> /* We pass any -flto flags on to the linker, which is expected
> to understand them. In practice, this means it had better be collect2.
> #define LINK_COMMAND_SPEC "\
> "%{flto|flto=*:%<fcompare-debug*} \
> %{flto} %{flto=*} %l " LINK_PIE_SPEC \
> doesn't pass on -fno-lto as expected. Does adding %{fno-lto} after
> %{flto} work?
That seems to do the trick: I no longer see lto1 with -fno-lto (independent of
-f(no-)use-linker-plugin) - and, unsurprisingly, without -fno-lto it still
invokes lto1.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug lto/63603] [4.9/5 Regression] Linking with -fno-lto still invokes LTO
2014-10-20 13:58 [Bug lto/63603] New: [4.9/5 Regression] Linking with -fno-lto still invokes LTO burnus at gcc dot gnu.org
` (5 preceding siblings ...)
2014-10-22 8:42 ` burnus at gcc dot gnu.org
@ 2014-10-22 8:48 ` rguenther at suse dot de
2014-10-22 21:15 ` burnus at gcc dot gnu.org
` (2 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: rguenther at suse dot de @ 2014-10-22 8:48 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63603
--- Comment #6 from rguenther at suse dot de <rguenther at suse dot de> ---
On Wed, 22 Oct 2014, burnus at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63603
>
> --- Comment #5 from Tobias Burnus <burnus at gcc dot gnu.org> ---
> (In reply to rguenther@suse.de from comment #4)
> > That means that
> > /* We pass any -flto flags on to the linker, which is expected
> > to understand them. In practice, this means it had better be collect2.
>
> > #define LINK_COMMAND_SPEC "\
>
> > "%{flto|flto=*:%<fcompare-debug*} \
> > %{flto} %{flto=*} %l " LINK_PIE_SPEC \
> > doesn't pass on -fno-lto as expected. Does adding %{fno-lto} after
> > %{flto} work?
>
> That seems to do the trick: I no longer see lto1 with -fno-lto (independent of
> -f(no-)use-linker-plugin) - and, unsurprisingly, without -fno-lto it still
> invokes lto1.
Great. Patch pre-approved for trunk and 4.9 branch.
Thanks,
Richard.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug lto/63603] [4.9/5 Regression] Linking with -fno-lto still invokes LTO
2014-10-20 13:58 [Bug lto/63603] New: [4.9/5 Regression] Linking with -fno-lto still invokes LTO burnus at gcc dot gnu.org
` (6 preceding siblings ...)
2014-10-22 8:48 ` rguenther at suse dot de
@ 2014-10-22 21:15 ` burnus at gcc dot gnu.org
2014-10-22 22:10 ` burnus at gcc dot gnu.org
2014-10-23 6:58 ` burnus at gcc dot gnu.org
9 siblings, 0 replies; 11+ messages in thread
From: burnus at gcc dot gnu.org @ 2014-10-22 21:15 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63603
--- Comment #7 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Author: burnus
Date: Wed Oct 22 20:51:00 2014
New Revision: 216566
URL: https://gcc.gnu.org/viewcvs?rev=216566&root=gcc&view=rev
Log:
2014-10-22 Richard Biener <rguenther@suse.de>
Tobias Burnus <burnus@net-b.de>
PR lto/63603
* gcc.c (LINK_COMMAND_SPEC): Add %{fno-lto}.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gcc.c
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug lto/63603] [4.9/5 Regression] Linking with -fno-lto still invokes LTO
2014-10-20 13:58 [Bug lto/63603] New: [4.9/5 Regression] Linking with -fno-lto still invokes LTO burnus at gcc dot gnu.org
` (7 preceding siblings ...)
2014-10-22 21:15 ` burnus at gcc dot gnu.org
@ 2014-10-22 22:10 ` burnus at gcc dot gnu.org
2014-10-23 6:58 ` burnus at gcc dot gnu.org
9 siblings, 0 replies; 11+ messages in thread
From: burnus at gcc dot gnu.org @ 2014-10-22 22:10 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63603
--- Comment #8 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Author: burnus
Date: Wed Oct 22 21:42:48 2014
New Revision: 216568
URL: https://gcc.gnu.org/viewcvs?rev=216568&root=gcc&view=rev
Log:
2014-10-22 Richard Biener <rguenther@suse.de>
Tobias Burnus <burnus@net-b.de>
PR lto/63603
* gcc.c (LINK_COMMAND_SPEC): Add %{fno-lto}.
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/gcc.c
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug lto/63603] [4.9/5 Regression] Linking with -fno-lto still invokes LTO
2014-10-20 13:58 [Bug lto/63603] New: [4.9/5 Regression] Linking with -fno-lto still invokes LTO burnus at gcc dot gnu.org
` (8 preceding siblings ...)
2014-10-22 22:10 ` burnus at gcc dot gnu.org
@ 2014-10-23 6:58 ` burnus at gcc dot gnu.org
9 siblings, 0 replies; 11+ messages in thread
From: burnus at gcc dot gnu.org @ 2014-10-23 6:58 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63603
Tobias Burnus <burnus at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #9 from Tobias Burnus <burnus at gcc dot gnu.org> ---
FIXED on the trunk and the 4.9 branch.
^ permalink raw reply [flat|nested] 11+ messages in thread