[Bug lto/41529] New: LTO configuration should detect if the target is ELF

[Bug lto/41529] New: LTO configuration should detect if the target is ELF

[dnovillo at gcc dot gnu dot org]

>From http://gcc.gnu.org/ml/gcc-patches/2009-09/msg02106.html

> You enable LTO by default if a suitable libelf is found.  But what if
> libelf is present but the target for which GCC is being configured is not
> an ELF target?  Presumably LTO will not work in that case (i.e., it
> requires the target to be an ELF target rather than producing ELF files
> separate from the normal objects for that target)?  So shouldn't LTO be
> disabled for non-ELF targets even when libelf is present?  We discussed a
> patch to do that back in May (e.g.
> <http://gcc.gnu.org/ml/gcc-patches/2009-05/msg01609.html>); what happened
> to that?  (On the whole I think a blacklist of targets that are (a)
> supported by GCC and (b) not ELF is better than trying to list all ELF
> targets.  Certainly various ELF targets are missing from the list used to
> set is_elf for --enable-gold.)


-- 
           Summary: LTO configuration should detect if the target is ELF
           Product: gcc
           Version: lto
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
        AssignedTo: dnovillo at gcc dot gnu dot org
        ReportedBy: dnovillo at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41529

[Bug lto/41529] LTO configuration should detect if the target is ELF

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
           Keywords|                            |build
   Last reconfirmed|0000-00-00 00:00:00         |2009-10-03 22:15:50
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41529

[Bug lto/41529] [4.5 Regression] LTO configuration should detect if the target is ELF

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2009-10-08 21:26 -------
I installed libelf on a i386-darwin machine at /usr/local so I could build a
cross compiler to spu-elf and test LTO on my laptop.  And now a native build of
GCC picks up libelf and we get:
checking for the correct version of libelf... yes
The following languages will be built: c,lto,c++,fortran,java,objc

So this is a regression.
I will report how it fails later on.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|LTO configuration should    |[4.5 Regression] LTO
                   |detect if the target is ELF |configuration should detect
                   |                            |if the target is ELF
   Target Milestone|---                         |4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41529

[Bug bootstrap/41529] [4.5 Regression] LTO configuration should detect if the target is ELF

[rguenth at gcc dot gnu dot org]

------- Comment #2 from rguenth at gcc dot gnu dot org  2009-10-19 10:54 -------
*** Bug 41746 has been marked as a duplicate of this bug. ***


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mckelvey at maskull dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41529

[Bug bootstrap/41529] [4.5 Regression] LTO configuration should detect if the target is ELF

[steven at gcc dot gnu dot org]

------- Comment #3 from steven at gcc dot gnu dot org  2009-10-23 19:35 -------
There is already a patch for this one.

Paolo, can you perhaps (as build system maintainer) foster-parent it that patch
into the trunk?


-- 

steven at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bonzini at gnu dot org
                URL|                            |http://gcc.gnu.org/ml/gcc-
                   |                            |patches/2009-
                   |                            |05/msg01609.html
           Keywords|                            |patch
   Last reconfirmed|2009-10-03 22:15:50         |2009-10-23 19:35:43
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41529

[Bug bootstrap/41529] [4.5 Regression] LTO configuration should detect if the target is ELF

[pinskia at gcc dot gnu dot org]

------- Comment #4 from pinskia at gcc dot gnu dot org  2009-10-23 19:37 -------
(In reply to comment #3)
> There is already a patch for this one.
> 
> Paolo, can you perhaps (as build system maintainer) foster-parent it that patch
> into the trunk?

I think the patch should be the opposite way around, disabling LTO if the
target is not elf since there are fewer non-elf targets than there are elf
targets.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41529

[Bug bootstrap/41529] [4.5 Regression] LTO configuration should detect if the target is ELF

[bonzini at gnu dot org]

------- Comment #5 from bonzini at gnu dot org  2009-10-24 09:59 -------
I agree with Andrew, but as a middle way you could put something like this in
config/elf.m4:

dnl usage: ACX_ELF_TARGET_IFELSE([if-elf], [if-not-elf])
AC_DEFUN([ACX_ELF_TARGET_IFELSE]), [
AC_REQUIRE([AC_CANONICAL_TARGET])

target_elf=no
case $target in
  ...) target_elf=yes;;
esac

AS_IF([test $target_elf = yes], [$1], [$2])
])

and use the macro in the toplevel.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41529

[Bug bootstrap/41529] LTO configuration should detect if the target is ELF

[rguenth at gcc dot gnu dot org]

------- Comment #6 from rguenth at gcc dot gnu dot org  2009-10-24 11:56 -------
I have a hard way thinking of a way this is a regression.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.5 Regression] LTO        |LTO configuration should
                   |configuration should detect |detect if the target is ELF
                   |if the target is ELF        |
   Target Milestone|4.5.0                       |---


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41529

[Bug bootstrap/41529] LTO configuration should detect if the target is ELF

[pinskia at gcc dot gnu dot org]

------- Comment #7 from pinskia at gcc dot gnu dot org  2009-10-24 14:49 -------
(In reply to comment #6)
> I have a hard way thinking of a way this is a regression.


Well it is partly a regression as if you have libelf installed in /usr/local or
/usr, configure will find it by default and if you are targetting a non elf
target, LTO will be enabled and all the LTO testsuite will just fail.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41529

[Bug bootstrap/41529] LTO configuration should detect if the target is ELF

[rguenth at gcc dot gnu dot org]

------- Comment #8 from rguenth at gcc dot gnu dot org  2010-01-02 12:01 -------
Mine.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|dnovillo at gcc dot gnu dot |rguenth at gcc dot gnu dot
                   |org                         |org
                URL|http://gcc.gnu.org/ml/gcc-  |http://gcc.gnu.org/ml/gcc-
                   |patches/2009-               |patches/2010-
                   |05/msg01609.html            |01/msg00029.html
             Status|NEW                         |ASSIGNED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41529

[Bug bootstrap/41529] LTO configuration should detect if the target is ELF

[davek at gcc dot gnu dot org]

------- Comment #9 from davek at gcc dot gnu dot org  2010-01-02 13:25 -------
(In reply to comment #7)
> (In reply to comment #6)
> > I have a hard way thinking of a way this is a regression.
> 
> 
> Well it is partly a regression as if you have libelf installed in /usr/local or
> /usr, configure will find it by default and if you are targetting a non elf
> target, LTO will be enabled and all the LTO testsuite will just fail.

ORLY?  :-) Output from "make check-gcc-c RUNTESTFLAGS=lto.exp":


Test Run By DKAdmin on Fri Jan  1 11:11:25 2010
Native configuration is i686-pc-cygwin

                === gcc tests ===

Schedule of variations:
    unix

Running target unix
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for
targe
t.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using /gnu/gcc/gcc/gcc/testsuite/config/default.exp as tool-and-target-specific
interface file.
Running /gnu/gcc/gcc/gcc/testsuite/gcc.dg/lto/lto.exp ...
FAIL: gcc.dg/lto/20081201-2 c_lto_20081201-2_0.o-c_lto_20081201-2_1.o execute
-O
3 -fwhopr
FAIL: gcc.dg/lto/20081222 c_lto_20081222_1.o assemble, -O0 -fwhopr
FAIL: gcc.dg/lto/20081222 c_lto_20081222_1.o assemble, -O2 -fwhopr
FAIL: gcc.dg/lto/20081222 c_lto_20081222_1.o assemble, -O0 -flto
FAIL: gcc.dg/lto/20081222 c_lto_20081222_1.o assemble, -O2 -flto
FAIL: gcc.dg/lto/20090914-2 c_lto_20090914-2_0.o assemble, -O0 -fwhopr
FAIL: gcc.dg/lto/20090914-2 c_lto_20090914-2_0.o assemble, -O2 -fwhopr
FAIL: gcc.dg/lto/20090914-2 c_lto_20090914-2_0.o assemble, -O0 -flto
FAIL: gcc.dg/lto/20090914-2 c_lto_20090914-2_0.o assemble, -O2 -flto

                === gcc Summary ===

# of expected passes            445
# of unexpected failures        9
# of unresolved testcases       16
# of unsupported tests          2
/gnu/gcc/obj3/gcc/xgcc  version 4.5.0 20091231 (experimental) (GCC)

make[2]: [check-parallel-gcc] Error 1 (ignored)

Do those nine failures really reflect some fundamental breakage on a non-ELF
platform?  The assemble failures all say:

/gnu/gcc/gcc/gcc/testsuite/gcc.dg/lto/20081222_1.c:14:21: error: 'EXT_x'
aliased to undefined symbol 'INT_x'
/gnu/gcc/gcc/gcc/testsuite/gcc.dg/lto/20081222_1.c:14:21: error: 'EXT_x'
aliased to undefined symbol 'INT_x'

which I thought was likely to be a problem either with the lack of symbol
visibility or perhaps a weakness in alias handling on the platform.  But most
of it seems to work.


-- 

davek at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |davek at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41529

[Bug bootstrap/41529] LTO configuration should detect if the target is ELF

[rguenth at gcc dot gnu dot org]

------- Comment #10 from rguenth at gcc dot gnu dot org  2010-01-02 13:42 -------
FAIL: gcc.dg/lto/20081201-2 c_lto_20081201-2_0.o-c_lto_20081201-2_1.o execute
-O3 -fwhopr

this means you do not get any LTO optimization (it's really the only test
that tests this ....)

So LTO is not working for you.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41529

[Bug bootstrap/41529] LTO configuration should detect if the target is ELF

[davek at gcc dot gnu dot org]

------- Comment #11 from davek at gcc dot gnu dot org  2010-01-02 13:51 -------
(In reply to comment #10)
> FAIL: gcc.dg/lto/20081201-2 c_lto_20081201-2_0.o-c_lto_20081201-2_1.o execute
> -O3 -fwhopr
> 
> this means you do not get any LTO optimization (it's really the only test
> that tests this ....)
> 
> So LTO is not working for you.

  Righto, I'll look at that one first.

  Are you aware of any structural reason why LTO can't possibly work on a
non-ELF platform? 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41529

[Bug bootstrap/41529] LTO configuration should detect if the target is ELF

[rguenther at suse dot de]

------- Comment #12 from rguenther at suse dot de  2010-01-02 13:56 -------
Subject: Re:  LTO configuration should detect if the
 target is ELF

On Sat, 2 Jan 2010, davek at gcc dot gnu dot org wrote:

> ------- Comment #11 from davek at gcc dot gnu dot org  2010-01-02 13:51 -------
> (In reply to comment #10)
> > FAIL: gcc.dg/lto/20081201-2 c_lto_20081201-2_0.o-c_lto_20081201-2_1.o execute
> > -O3 -fwhopr
> > 
> > this means you do not get any LTO optimization (it's really the only test
> > that tests this ....)
> > 
> > So LTO is not working for you.
> 
>   Righto, I'll look at that one first.
> 
>   Are you aware of any structural reason why LTO can't possibly work on a
> non-ELF platform? 

The only part that really relies on native ELF object files is
the mixing of LTO sections with regular object code as produced
by cc1 - lto1 relies on libelf to identify and read the LTO sections,
which probably does not work.

And of course the linker-plugin and symbol resolution stuff done
by it - but the linker-plugin is gold only and ELF only anyway.
The collect2 stuff should in principle work with non-ELF targets
as well if you circumvent that first problem somehow (for
example by not producing regular object code from cc1 but only
assemble the LTO sections to a ELF object file).

Richard.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41529

[Bug bootstrap/41529] LTO configuration should detect if the target is ELF

[davek at gcc dot gnu dot org]

------- Comment #13 from davek at gcc dot gnu dot org  2010-01-02 13:59 -------
(In reply to comment #12)
> The collect2 stuff should in principle work with non-ELF targets
> as well if you circumvent that first problem somehow (for
> example by not producing regular object code from cc1 but only
> assemble the LTO sections to a ELF object file).

  Hmm, that would be an alternative to extending libelf to speak a rudimentary
degree of non-ELF format.  Maybe we could extend collect2 on non-ELF to use
objcopy to extract the elf sections from any input files to temporary
pure-ELF-format objects; does that seem reasonable?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41529

[Bug bootstrap/41529] LTO configuration should detect if the target is ELF

[rguenth at gcc dot gnu dot org]

------- Comment #14 from rguenth at gcc dot gnu dot org  2010-01-02 14:13 -------
Subject: Bug 41529

Author: rguenth
Date: Sat Jan  2 14:13:37 2010
New Revision: 155565

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155565
Log:
2010-01-02  Richard Guenther  <rguenther@suse.de>

        PR lto/41529
        * configure.ac: Include config/elf.m4.  Disable LTO if not
        builting for an elf target.
        * configure: Regenerate.

        config/
        * elf.m4: New file.

Added:
    trunk/config/elf.m4
Modified:
    trunk/ChangeLog
    trunk/config/ChangeLog
    trunk/configure
    trunk/configure.ac


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41529

[Bug bootstrap/41529] LTO configuration should detect if the target is ELF

[rguenth at gcc dot gnu dot org]

------- Comment #15 from rguenth at gcc dot gnu dot org  2010-01-02 14:16 -------
Fixed.  The way to support LTO on non-ELF targets is to wrap all LTO sections
in an ELF container that is wrapped in a native section.  We then have to
have code to open a native object format section and direct libelf to parse
that section content.

The implementation difficulty is to use libelf to produce the ELF object file
and then get that included in the assembly for the native wrapper section.

Well - for 4.6 if anyone wants to work on this.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41529

[Bug bootstrap/41529] LTO configuration should detect if the target is ELF

[davek at gcc dot gnu dot org]

------- Comment #16 from davek at gcc dot gnu dot org  2010-01-02 14:33 -------
JFTR: I'll be working on this later in January.  I'll do it on the
cygwin-improvements branch for visibility.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41529

[Bug bootstrap/41529] LTO configuration should detect if the target is ELF

[joseph at codesourcery dot com]

------- Comment #17 from joseph at codesourcery dot com  2010-01-02 15:04 -------
Subject: Re:  LTO configuration should detect if the
 target is ELF

On Sat, 2 Jan 2010, rguenth at gcc dot gnu dot org wrote:

> Fixed.  The way to support LTO on non-ELF targets is to wrap all LTO sections
> in an ELF container that is wrapped in a native section.  We then have to
> have code to open a native object format section and direct libelf to parse
> that section content.

I don't really see the point of the ELF container if you also have code to 
parse a native object format.  Either add a separate COFF etc. (or 
BFD-using if you so wish) implementation of the set of interfaces that 
lto-elf.c provides, using hooks (or proper C++ classes) to select which 
implementation is used, or switch the targets to use ELF completely with a 
postlinker converting to executables in another format (like on 
arm-symbianelf).  The former (lto-coff.c, lto-macho.c etc. or lto-bfd.c) 
should be a lot less work (the latter requires an ABI to define how all 
the features of the other object format are represented in ELF).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41529

[Bug bootstrap/41529] LTO configuration should detect if the target is ELF

[davek at gcc dot gnu dot org]

------- Comment #18 from davek at gcc dot gnu dot org  2010-01-02 15:20 -------
(In reply to comment #17)

> I don't really see the point of the ELF container if you also have code to 
> parse a native object format.  Either add a separate COFF etc. (or 
> BFD-using if you so wish) implementation of the set of interfaces that 
> lto-elf.c provides, 

  Thanks Joseph!  That's probably much cleaner.  (Did I mention I didn't study
the code yet?  I only just started testing this stuff for the first time before
christmas.)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41529

[Bug bootstrap/41529] LTO configuration should detect if the target is ELF

[davek at gcc dot gnu dot org]

------- Comment #19 from davek at gcc dot gnu dot org  2010-01-17 15:08 -------
Created an attachment (id=19635)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19635&action=view)
lto for cygwin, and probably other coff targets

FTR.  Well, that turned out to be quite easy.  Needs some support in binutils
to allow us to override the default section alignment for object files, but
that's trivial, and I'll send it to the binutils list shortly.

Sigh, most of this is almost-safe-enough-for-stage-3.  Oh well.

Should I reopen this bug, assign it to myself, retarget it to 4.6 and add the
words "or COFF" to the summary?

Results from this patch:

Running /gnu/gcc/gcc/gcc/testsuite/gcc.dg/lto/lto.exp ...
FAIL: gcc.dg/lto/20081222 c_lto_20081222_1.o assemble, -O0 -fwhopr
FAIL: gcc.dg/lto/20081222 c_lto_20081222_1.o assemble, -O2 -fwhopr
FAIL: gcc.dg/lto/20081222 c_lto_20081222_1.o assemble, -O0 -flto
FAIL: gcc.dg/lto/20081222 c_lto_20081222_1.o assemble, -O2 -flto
FAIL: gcc.dg/lto/20090914-2 c_lto_20090914-2_0.o assemble, -O0 -fwhopr
FAIL: gcc.dg/lto/20090914-2 c_lto_20090914-2_0.o assemble, -O2 -fwhopr
FAIL: gcc.dg/lto/20090914-2 c_lto_20090914-2_0.o assemble, -O0 -flto
FAIL: gcc.dg/lto/20090914-2 c_lto_20090914-2_0.o assemble, -O2 -flto

                === gcc Summary ===

# of expected passes            462
# of unexpected failures        8
# of unresolved testcases       16
# of unsupported tests          2
/gnu/gcc/obj-lto/gcc/xgcc  version 4.5.0 20100116 (experimental) (GCC)

... i.e. the only tests that still fail are one that uses visibility and one
that has an ELF-specific .section directive in an asm, all the rest work and in
particular the "gcc.dg/lto/20081201-2 c_lto_20081201-2_0.o-c_lto_20081201-2_1.o
execute -O3 -fwhopr" test succeeds which indicates real LTO is taking place :-)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41529

[Bug bootstrap/41529] LTO configuration should detect if the target is ELF

[rguenther at suse dot de]

------- Comment #20 from rguenther at suse dot de  2010-01-17 15:48 -------
Subject: Re:  LTO configuration should detect if the
 target is ELF

On Sun, 17 Jan 2010, davek at gcc dot gnu dot org wrote:

> ------- Comment #19 from davek at gcc dot gnu dot org  2010-01-17 15:08 -------
> Created an attachment (id=19635)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19635&action=view)
>  --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19635&action=view)
> lto for cygwin, and probably other coff targets
> 
> FTR.  Well, that turned out to be quite easy.  Needs some support in binutils
> to allow us to override the default section alignment for object files, but
> that's trivial, and I'll send it to the binutils list shortly.
> 
> Sigh, most of this is almost-safe-enough-for-stage-3.  Oh well.

Well.  I suppose we can backport stuff for 4.5.1 if it is LTO specific
but I don't want to have it before 4.5.0.

> Should I reopen this bug, assign it to myself, retarget it to 4.6 and add the
> words "or COFF" to the summary?

Please open an new bugreport for LTO on non-ELF platforms.

Thanks.

> Results from this patch:
> 
> Running /gnu/gcc/gcc/gcc/testsuite/gcc.dg/lto/lto.exp ...
> FAIL: gcc.dg/lto/20081222 c_lto_20081222_1.o assemble, -O0 -fwhopr
> FAIL: gcc.dg/lto/20081222 c_lto_20081222_1.o assemble, -O2 -fwhopr
> FAIL: gcc.dg/lto/20081222 c_lto_20081222_1.o assemble, -O0 -flto
> FAIL: gcc.dg/lto/20081222 c_lto_20081222_1.o assemble, -O2 -flto
> FAIL: gcc.dg/lto/20090914-2 c_lto_20090914-2_0.o assemble, -O0 -fwhopr
> FAIL: gcc.dg/lto/20090914-2 c_lto_20090914-2_0.o assemble, -O2 -fwhopr
> FAIL: gcc.dg/lto/20090914-2 c_lto_20090914-2_0.o assemble, -O0 -flto
> FAIL: gcc.dg/lto/20090914-2 c_lto_20090914-2_0.o assemble, -O2 -flto
> 
>                 === gcc Summary ===
> 
> # of expected passes            462
> # of unexpected failures        8
> # of unresolved testcases       16
> # of unsupported tests          2
> /gnu/gcc/obj-lto/gcc/xgcc  version 4.5.0 20100116 (experimental) (GCC)
> 
> ... i.e. the only tests that still fail are one that uses visibility and one
> that has an ELF-specific .section directive in an asm, all the rest work and in
> particular the "gcc.dg/lto/20081201-2 c_lto_20081201-2_0.o-c_lto_20081201-2_1.o
> execute -O3 -fwhopr" test succeeds which indicates real LTO is taking place :-)
> 
> 
> 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41529

[Bug bootstrap/41529] LTO configuration should detect if the target is ELF

[davek at gcc dot gnu dot org]

------- Comment #21 from davek at gcc dot gnu dot org  2010-01-17 16:01 -------
(In reply to comment #20)

> Well.  I suppose we can backport stuff for 4.5.1 if it is LTO specific
> but I don't want to have it before 4.5.0.

Thanks, that's how I'll proceed then.

> Please open an new bugreport for LTO on non-ELF platforms.

FTR: Bug 42776.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41529