[Bug lto/63603] New: [4.9/5 Regression] Linking with -fno-lto still invokes LTO

public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed

* [Bug lto/63603] New: [4.9/5 Regression] Linking with -fno-lto still invokes LTO
@ 2014-10-20 13:58 burnus at gcc dot gnu.org
  2014-10-20 15:22 ` [Bug lto/63603] " burnus at gcc dot gnu.org
                   ` (9 more replies)
  0 siblings, 10 replies; 11+ messages in thread
From: burnus at gcc dot gnu.org @ 2014-10-20 13:58 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63603

            Bug ID: 63603
           Summary: [4.9/5 Regression] Linking with -fno-lto still invokes
                    LTO
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
          Assignee: unassigned at gcc dot gnu.org
          Reporter: burnus at gcc dot gnu.org

Running

  echo "int main() {return 0;}" >  foo.c
  gcc -flto -ffat-lto-objects -c foo.c
  gcc -v -fno-lto foo.o 2>&1|grep lto1

shows that the -fno-lto is ignored for linking as lto1 is always invoked with
GCC 4.9 and 5.

Using GCC 4.8, LTO is not automatically invoked for linking but has to be
passed manually. Hence, it works there.


^ 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 ` 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

end of thread, other threads:[~2014-10-23  6:08 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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
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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).