Re: [LTO] Request for testing: Last merge from trunk before final merge

[Richard Guenther <richard dot guenther at gmail dot com>]

On Wed, Sep 30, 2009 at 7:36 PM, Rainer Orth
<ro@techfak.uni-bielefeld.de> wrote:
> Diego Novillo <dnovillo@google.com> writes:
>
>> In preparation for the final merge into mainline. ?I need to test
>> the branch on various platforms. ?Richi is currently testing on
>> i586, ppc, ppc64, ia64, s390, s390x.
>>
>> If anyone has free cycles I would appreciate results from other
>> ELF-capable targets.
>
> I've run those for sparc-sun-solaris2.11, i386-pc-solaris2.10 and
> mips-sgi-irix6.5. ?Details below.
>
>> $ svn co svn://gcc.gnu.org/svn/gcc/branches/lto
>> $ mkdir bld && cd bld
>> $ ../lto/configure --enable-lto && make
>
> Why just a make and no make bootstrap? ?This is also on the LTO wiki page,
> which btw. is confusing since it states `Last updated: 07-Jul-2009'. ?For
> all my tests, I've just run regular bootstraps.
>
>> You will need to have libelf 0.8.12 installed
>> (http://www.mr511.de/software/libelf-0.8.12.tar.gz)
>
> libelf 0.8.12 builds without problems on Solaris 10 and 11, but fails out
> of the box on IRIX 6.5. ?I've contacted the maintainer about this, and he
> suggested configuring with
>
> $ ac_cv_header_elf_h=no ac_cv_header_sys_elf_h=no ./configure
>
> as a hack. ?This works for now, until I ran into PR lto/40790 which is
> still unfixed. ?I stopped here, but it should be possible to use
> GCC_HEADER_STDINT to work around this.
>
> I've posted testsuite results for sparc-sun-solaris2.11 to
>
> ? ? ? ?http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg02772.html
>
> and compared them with mainline results as of 20090922. ?Ada is missing
> here, since I had to use a non-Ada enabled bootstrap compiler due to PR
> bootstrap/39020.
>
> @@ -20,13 +15,19 @@
>
> ? ? ? ? ? ? ? ?=== g++ Summary for unix ===
>
> [...]
>
> ?Running target unix/-m64
> +FAIL: tmpdir-g++.dg-struct-layout-1/t003 cp_compat_x_tst.o-cp_compat_y_tst.o execute "-O2","-fwhopr"
> +FAIL: tmpdir-g++.dg-struct-layout-1/t003 cp_compat_x_tst.o-cp_compat_y_tst.o execute "-O2","-flto"
> +FAIL: tmpdir-g++.dg-struct-layout-1/t019 cp_compat_x_tst.o-cp_compat_y_tst.o execute "-O2","-fwhopr"
> +FAIL: tmpdir-g++.dg-struct-layout-1/t019 cp_compat_x_tst.o-cp_compat_y_tst.o execute "-O2","-flto"
> +FAIL: tmpdir-g++.dg-struct-layout-1/t030 cp_compat_x_tst.o-cp_compat_y_tst.o execute "-O2","-fwhopr"
> +FAIL: tmpdir-g++.dg-struct-layout-1/t030 cp_compat_x_tst.o-cp_compat_y_tst.o execute "-O2","-flto"
>
> There's no indication in the logs why those fail, the 32-bit tests are
> fine.
>
> ? ? ? ? ? ? ? ?=== gcc tests ===
> [...]
> @@ -64,18 +65,22 @@
> ?FAIL: gcc.c-torture/compile/pr38789.c ?-O3 -fomit-frame-pointer ?(test for excess errors)
> ?FAIL: gcc.c-torture/compile/pr38789.c ?-O3 -g ?(test for excess errors)
> ?FAIL: gcc.c-torture/compile/pr38789.c ?-Os ?(test for excess errors)
> +FAIL: gcc.c-torture/compile/pr38789.c ?-O2 -flto ?(test for excess errors)
> +FAIL: gcc.c-torture/compile/pr38789.c ?-O2 -fwhopr ?(test for excess errors)
>
> The test fails without -flto/-fwhopr as well: Sun as cannot cope with the
> input. ?I've filed PR testsuite/41522 for that.
>
> ?FAIL: gcc.c-torture/execute/pr38819.c execution, ?-O2
> ?FAIL: gcc.c-torture/execute/pr38819.c execution, ?-O3 -fomit-frame-pointer
> ?FAIL: gcc.c-torture/execute/pr38819.c execution, ?-O3 -fomit-frame-pointer -funroll-loops
> ?FAIL: gcc.c-torture/execute/pr38819.c execution, ?-O3 -fomit-frame-pointer -funroll-all-loops -finline-functions
> ?FAIL: gcc.c-torture/execute/pr38819.c execution, ?-O3 -g
> +FAIL: gcc.c-torture/execute/pr38819.c execution, ?-O2 -flto
> +FAIL: gcc.c-torture/execute/pr38819.c execution, ?-O2 -fwhopr
>
> Similarly here: already fails without -flto.
>
> +FAIL: gcc.dg/lto/20081120-1 c_lto_20081120-1_0.o-c_lto_20081120-1_1.o link
> +UNRESOLVED: gcc.dg/lto/20081120-1 c_lto_20081120-1_0.o-c_lto_20081120-1_1.o execute -flto -shared
>
> This fails like this:
>
> output is:
> Text relocation remains ? ? ? ? ? ? ? ? ? ? ? ? referenced
> ? ?against symbol ? ? ? ? ? ? ? ? ?offset ? ? ?in file
> stat64 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?0x4 ? ? ? ? c_lto_20081120-1_0.o
> stat64 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?0x4 ? ? ? ? c_lto_20081120-1_1.o
> ld: fatal: relocations remain against allocatable but non-writable sections
> collect2: ld returned 1 exit status
>
> FAIL: gcc.dg/lto/20081120-1 c_lto_20081120-1_0.o-c_lto_20081120-1_1.o link
>
> It seems like -flto -shared doesn't create PIC code here for some reason.
>
> +FAIL: gcc.dg/lto/20081201-2 c_lto_20081201-2_0.o-c_lto_20081201-2_1.o execute -O3 -fwhopr
>
> No hint why this fails.
>
> +FAIL: gcc.dg/lto/20090729 c_lto_20090729_0.o-c_lto_20090729_1.o link
> +UNRESOLVED: gcc.dg/lto/20090729 c_lto_20090729_0.o-c_lto_20090729_1.o execute -w
>
> output is:
> ld: warning: symbol `i' has differing sizes:
> ? ? ? ?(file c_lto_20090729_0.o value=0x8; file c_lto_20090729_1.o value=0x4);
> ? ? ? ?c_lto_20090729_0.o definition taken
> ld: warning: symbol `j' has differing sizes:
> ? ? ? ?(file c_lto_20090729_0.o value=0x4; file c_lto_20090729_1.o value=0x8);
> ? ? ? ?c_lto_20090729_1.o definition taken
>
> This seems like it cannot work.

Ah.  We don't expect the linker to complain here - GNU ld accepts different
size common sections.  The testcase is reduced from broken SPEC CPU 2000
source ...

If you happen to know a linker option that would silence the warning ...

Richard.