On Wed, Sep 30, 2009 at 7:36 PM, Rainer Orth <r...@techfak.uni-bielefeld.de> wrote: > Diego Novillo <dnovi...@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.
