[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