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

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

[burnus at gcc dot gnu.org]

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.

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

[burnus at gcc dot gnu.org]

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

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

[rguenth at gcc dot gnu.org]

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?

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

[burnus at gcc dot gnu.org]

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 [...]
[...]

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

[burnus at gcc dot gnu.org]

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.

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

[rguenther at suse dot de]

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?

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

[burnus at gcc dot gnu.org]

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.

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

[rguenther at suse dot de]

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.

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

[burnus at gcc dot gnu.org]

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

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

[burnus at gcc dot gnu.org]

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

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

[burnus at gcc dot gnu.org]

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.