bootstrap comparison failure with bootstrap-lto

bootstrap comparison failure with bootstrap-lto

[Matt]

I am getting this on Ubuntu 11.10/amd64. If I remove the 
--with-build-config=bootstrap-lto, the build succeeds just fine. Is this a 
known problem, or should I file a bug? (A search of bugzilla didn't bring 
up this specific symptom.)

matt@matt-desktop:~/src/gcc-trunk/obj$ ../configure --enable-bootstrap 
--prefix=/home/matt --enable-clocale=gnu --with-system-zlib 
--enable-shared --with-demangler-in-ld --enable-lto 
--with-build-config=bootstrap-lto --with-fpmath=sse 
--enable-languages=c,c++,lto

matt@matt-desktop:~/src/gcc-trunk/obj$ make -j7

make "DESTDIR=" "RPATH_ENVVAR=LD_LIBRARY_PATH" 
"TARGET_SUBDIR=x86_64-unknown-linux-gnu" "bindir=/home/matt/bin" 
"datadir=/home/matt/share" "exec_prefix=/home/matt" 
"includedir=/home/matt/include" "datarootdir=/home/matt/share" 
"docdir=/home/matt/share/doc/" "infodir=/home/matt/share/info" 
"pdfdir=/home/matt/share/doc/" "htmldir=/home/matt/share/doc/" 
"libdir=/home/matt/lib" "libexecdir=/home/matt/libexec" "lispdir=" 
"localstatedir=/home/matt/var" "mandir=/home/matt/share/man" 
"oldincludedir=/usr/include" "prefix=/home/matt" "sbindir=/home/matt/sbin" 
"sharedstatedir=/home/matt/com" "sysconfdir=/home/matt/etc" 
"tooldir=/home/matt/x86_64-unknown-linux-gnu" 
"build_tooldir=/home/matt/x86_64-unknown-linux-gnu" 
"target_alias=x86_64-unknown-linux-gnu" "AWK=gawk" "BISON=bison" 
"CC_FOR_BUILD=gcc" "CFLAGS_FOR_BUILD=-g -O2" "CXX_FOR_BUILD=g++" 
"EXPECT=expect" "FLEX=flex" "INSTALL=/usr/bin/install -c" 
"INSTALL_DATA=/usr/bin/install -c -m 644" 
"INSTALL_PROGRAM=/usr/bin/install -c" "INSTALL_SCRIPT=/usr/bin/install -c" 
"LDFLAGS_FOR_BUILD=" "LEX=flex" "M4=m4" "MAKE=make" "RUNTEST=runtest" 
"RUNTESTFLAGS=" "SED=/bin/sed" "SHELL=/bin/bash" "YACC=bison -y" "`echo 
'ADAFLAGS=' | sed -e s'/[^=][^=]*=$/XFOO=/'`" "ADA_CFLAGS=" "AR_FLAGS=rc" 
"`echo 'BOOT_ADAFLAGS=-gnatpg -gnata' | sed -e s'/[^=][^=]*=$/XFOO=/'`" 
"BOOT_CFLAGS=-g -O2" "BOOT_LDFLAGS=" "CFLAGS=-g -O2" "CXXFLAGS=-g -O2" 
"LDFLAGS=" "LIBCFLAGS=-g -O2" "LIBCXXFLAGS=-g -O2 -fno-implicit-templates" 
"STAGE1_CHECKING=--enable-checking=yes,types" "STAGE1_LANGUAGES=c,c++,lto" 
"GNATBIND=gnatbind" "GNATMAKE=gnatmake" "AR_FOR_TARGET=ar" 
"AS_FOR_TARGET=as" "CC_FOR_TARGET=/home/matt/src/gcc-trunk/obj/./gcc/xgcc 
-B/home/matt/src/gcc-trunk/obj/./gcc/" "CFLAGS_FOR_TARGET=-g -O2" 
"CPPFLAGS_FOR_TARGET=" "CXXFLAGS_FOR_TARGET=-g -O2 -D_GNU_SOURCE" 
"DLLTOOL_FOR_TARGET=dlltool" 
"FLAGS_FOR_TARGET=-B/home/matt/x86_64-unknown-linux-gnu/bin/ 
-B/home/matt/x86_64-unknown-linux-gnu/lib/ -isystem 
/home/matt/x86_64-unknown-linux-gnu/include -isystem 
/home/matt/x86_64-unknown-linux-gnu/sys-include" "GCJ_FOR_TARGET=" 
"GFORTRAN_FOR_TARGET=" "GOC_FOR_TARGET=" "GOCFLAGS_FOR_TARGET=-O2 -g" 
"LD_FOR_TARGET=ld" "LIPO_FOR_TARGET=lipo" "LDFLAGS_FOR_TARGET=" 
"LIBCFLAGS_FOR_TARGET=-g -O2" "LIBCXXFLAGS_FOR_TARGET=-g -O2 -D_GNU_SOURCE 
-fno-implicit-templates" "NM_FOR_TARGET=nm" "OBJDUMP_FOR_TARGET=objdump" 
"RANLIB_FOR_TARGET=ranlib" "READELF_FOR_TARGET=readelf" 
"STRIP_FOR_TARGET=strip" "WINDRES_FOR_TARGET=windres" 
"WINDMC_FOR_TARGET=windmc" "BUILD_CONFIG=bootstrap-lto" "`echo 
'LANGUAGES=' | sed -e s'/[^=][^=]*=$/XFOO=/'`" "LEAN=false" 
"STAGE1_CFLAGS=-g -fkeep-inline-functions" "STAGE1_CXXFLAGS=-g 
-fkeep-inline-functions" "STAGE1_TFLAGS=" "STAGE2_CFLAGS=-g -O2 
-flto=jobserver -frandom-seed=1" "STAGE2_CXXFLAGS=-g -O2 -flto=jobserver 
-frandom-seed=1" "STAGE2_TFLAGS=" "STAGE3_CFLAGS=-g -O2 -flto=jobserver 
-frandom-seed=1" "STAGE3_CXXFLAGS=-g -O2 -flto=jobserver -frandom-seed=1" 
"STAGE3_TFLAGS=" "STAGE4_CFLAGS=-g -O2" "STAGE4_CXXFLAGS=-g -O2" 
"STAGE4_TFLAGS=" "STAGEprofile_CFLAGS=-g -O2 -flto=jobserver 
-frandom-seed=1 -fprofile-generate -fno-lto" "STAGEprofile_CXXFLAGS=-g -O2 
-flto=jobserver -frandom-seed=1 -fprofile-generate -fno-lto" 
"STAGEprofile_TFLAGS=" "STAGEfeedback_CFLAGS=-g -O2 -flto=jobserver 
-frandom-seed=1 -fprofile-use" "STAGEfeedback_CXXFLAGS=-g -O2 
-flto=jobserver -frandom-seed=1 -fprofile-use" "STAGEfeedback_TFLAGS=" 
"CXX_FOR_TARGET= $r/./gcc/g++ -B$r/./gcc/ -nostdinc++ `if test -f 
$r/x86_64-unknown-linux-gnu/libstdc++-v3/scripts/testsuite_flags; then 
/bin/bash $r/x86_64-unknown-linux-gnu/libstdc++-v3/scripts/testsuite_flags 
--build-includes; else echo -funconfigured-libstdc++-v3 ; fi` 
-L$r/x86_64-unknown-linux-gnu/libstdc++-v3/src 
-L$r/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs" "TFLAGS=" 
"CONFIG_SHELL=/bin/bash" "MAKEINFO=makeinfo --split-size=5000000 
--split-size=5000000"  compare
make[2]: Entering directory `/home/matt/src/gcc-trunk/obj'
make[3]: Entering directory `/home/matt/src/gcc-trunk/obj'
rm -f stage_current
make[3]: Leaving directory `/home/matt/src/gcc-trunk/obj'
Comparing stages 2 and 3
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1-checksum.o differs
Bootstrap comparison failure!
libcpp/lex.o differs
make[2]: *** [compare] Error 1


--
tangled strands of DNA explain the way that I behave.
http://www.clock.org/~matt

Re: bootstrap comparison failure with bootstrap-lto

[Ian Lance Taylor]

Matt <matt@use.net> writes:

> I am getting this on Ubuntu 11.10/amd64. If I remove the
> --with-build-config=bootstrap-lto, the build succeeds just fine. Is
> this a known problem, or should I file a bug? (A search of bugzilla
> didn't bring up this specific symptom.)

> libcpp/lex.o differs

What are the differences between stage2-libcpp/lex.o and
stage3-libcpp/lex.o?  Ignore the fact that one will have debug info and
the other will not.  Look at the readelf -S output for both files, and
see if there are any differences in sections whose names do not start
with ".debug".

Also, what linker are you using?

Ian

Re: bootstrap comparison failure with bootstrap-lto

[Matt]

On Mon, 14 Nov 2011, Ian Lance Taylor wrote:

> Matt <matt@use.net> writes:
>
>> I am getting this on Ubuntu 11.10/amd64. If I remove the
>> --with-build-config=bootstrap-lto, the build succeeds just fine. Is
>> this a known problem, or should I file a bug? (A search of bugzilla
>> didn't bring up this specific symptom.)
>
>> libcpp/lex.o differs
>
> What are the differences between stage2-libcpp/lex.o and
> stage3-libcpp/lex.o?  Ignore the fact that one will have debug info and
> the other will not.  Look at the readelf -S output for both files, and
> see if there are any differences in sections whose names do not start
> with ".debug".

in stage2-libcpp/lex.o:
   [79] .init_array       INIT_ARRAY       0000000000000000  00021280
        0000000000000008  0000000000000000  WA       0     0     8
   [80] .rela.init_array  RELA             0000000000000000  0003a8e8
        0000000000000018  0000000000000018          101    79     8



in stage3-libcpp/lex.o:
   [79] .ctors            PROGBITS         0000000000000000  00021280
        0000000000000008  0000000000000000  WA       0     0     8
   [80] .rela.ctors       RELA             0000000000000000  0003a8e0
        0000000000000018  0000000000000018          101    79     8


There's a few other minor differences, but they're related to debug stuff, 
as far as I can tell.


> Also, what linker are you using?

ld --version outputs:
GNU ld (GNU Binutils for Ubuntu) 2.21.53.20110810

AFAIK, I'm using the default linker for Ubuntu 11.10/amd64.


--
tangled strands of DNA explain the way that I behave.
http://www.clock.org/~matt

Re: bootstrap comparison failure with bootstrap-lto

[Ian Lance Taylor]

Matt <matt@use.net> writes:

> On Mon, 14 Nov 2011, Ian Lance Taylor wrote:
>
>> Matt <matt@use.net> writes:
>>
>>> I am getting this on Ubuntu 11.10/amd64. If I remove the
>>> --with-build-config=bootstrap-lto, the build succeeds just fine. Is
>>> this a known problem, or should I file a bug? (A search of bugzilla
>>> didn't bring up this specific symptom.)
>>
>>> libcpp/lex.o differs
>>
>> What are the differences between stage2-libcpp/lex.o and
>> stage3-libcpp/lex.o?  Ignore the fact that one will have debug info and
>> the other will not.  Look at the readelf -S output for both files, and
>> see if there are any differences in sections whose names do not start
>> with ".debug".
>
> in stage2-libcpp/lex.o:
>   [79] .init_array       INIT_ARRAY       0000000000000000  00021280
>        0000000000000008  0000000000000000  WA       0     0     8
>   [80] .rela.init_array  RELA             0000000000000000  0003a8e8
>        0000000000000018  0000000000000018          101    79     8
>
>
>
> in stage3-libcpp/lex.o:
>   [79] .ctors            PROGBITS         0000000000000000  00021280
>        0000000000000008  0000000000000000  WA       0     0     8
>   [80] .rela.ctors       RELA             0000000000000000  0003a8e0
>        0000000000000018  0000000000000018          101    79     8
>
>
> There's a few other minor differences, but they're related to debug
> stuff, as far as I can tell.
>
>
>> Also, what linker are you using?
>
> ld --version outputs:
> GNU ld (GNU Binutils for Ubuntu) 2.21.53.20110810
>
> AFAIK, I'm using the default linker for Ubuntu 11.10/amd64.


Thanks.  It appears that for some reason your stage2 build is using
--enable-initfini-array while your stage3 build is using
--disable-initfini-array.  The default value for this configure option
is set by the configure script.

grep for gcc_cv_initfini_array in stage1-gcc/config.log and
stage2-gcc/config.log.  I am guessing that they will have different
values.

Look in stage1-gcc/config.log and stage2-gcc/config.log.  Look for
"checking for .preinit_array/.init_array/.fini_array support".  It
should be followed by a compile and run of conftest.  I'm guessing that
one of those runs succeeded and one failed.  See if config.log says why.

Ian

Re: bootstrap comparison failure with bootstrap-lto

[Matt]

On Wed, 16 Nov 2011, Ian Lance Taylor wrote:

> Matt <matt@use.net> writes:
>
>> On Mon, 14 Nov 2011, Ian Lance Taylor wrote:
>>
>>> Matt <matt@use.net> writes:
>>>
>>>> libcpp/lex.o differs
>>>
>>> What are the differences between stage2-libcpp/lex.o and
>>> stage3-libcpp/lex.o?  Ignore the fact that one will have debug info and
>>> the other will not.  Look at the readelf -S output for both files, and
>>> see if there are any differences in sections whose names do not start
>>> with ".debug".
>>
>> in stage2-libcpp/lex.o:
>>   [79] .init_array       INIT_ARRAY       0000000000000000  00021280
>>        0000000000000008  0000000000000000  WA       0     0     8
>>   [80] .rela.init_array  RELA             0000000000000000  0003a8e8
>>        0000000000000018  0000000000000018          101    79     8
>>
>>
>>
>> in stage3-libcpp/lex.o:
>>   [79] .ctors            PROGBITS         0000000000000000  00021280
>>        0000000000000008  0000000000000000  WA       0     0     8
>>   [80] .rela.ctors       RELA             0000000000000000  0003a8e0
>>        0000000000000018  0000000000000018          101    79     8
>>

> Thanks.  It appears that for some reason your stage2 build is using
> --enable-initfini-array while your stage3 build is using
> --disable-initfini-array.  The default value for this configure option
> is set by the configure script.
>
> grep for gcc_cv_initfini_array in stage1-gcc/config.log and
> stage2-gcc/config.log.  I am guessing that they will have different
> values.

yup. stage1 succeeds and stage2 fails, as you predicted.


> Look in stage1-gcc/config.log and stage2-gcc/config.log.  Look for
> "checking for .preinit_array/.init_array/.fini_array support".  It
> should be followed by a compile and run of conftest.  I'm guessing that
> one of those runs succeeded and one failed.  See if config.log says why.

It *kind of* says why. I've pasted the output below. Unfortunately, when 
the full build is finished, the prev-gcc/xgcc no longer exists. When I 
test the conftest.c (copied and pasted from the log), the stage1-gcc/xgcc 
and stage2-gcc/xgcc have no problem with it (of course).

I did run valgrind on stage1's xgcc and stage2's xgcc, but the only thing 
interesting I saw was some branching on unconditional values from data fed 
to libz via lto.c:

==9766== Conditional jump or move depends on uninitialised value(s)
==9766==    at 0x7035510: inflateReset2 (in 
/lib/x86_64-linux-gnu/libz.so.1.2.3.4)
==9766==    by 0x7035605: inflateInit2_ (in 
/lib/x86_64-linux-gnu/libz.so.1.2.3.4)
==9766==    by 0x12C0805: lto_end_uncompression (lto-compress.c:277)
==9766==    by 0x1223FBF: lto_get_section_data (lto-section-in.c:172)
==9766==    by 0x507019: lto_file_finalize (lto.c:1134)
==9766==    by 0x5070A6: lto_create_files_from_ids (lto.c:1150)
==9766==    by 0x5071BF: lto_file_read (lto.c:1190)

Regardless, here's the output. I'll try another build and "catch" the 
build before it removes the prev-gcc/xgcc and try to reproduce the error 
there. If you have some ideas in the meantime, let me know.

configure:10965: checking for .preinit_array/.init_array/.fini_array 
support
configure:11084:  /home/matt/src/gcc-trunk/obj/./prev-gcc/xgcc 
-B/home/matt/src/gcc-trunk/obj/./prev-gcc/ 
-B/home/matt/x86_64-unknown-linux-gnu/bin/ 
-B/home/matt/x86_64-unknown-linux-gnu/bin/ 
-B/home/matt/x86_64-unknown-linux-gnu/lib/ -isystem 
/home/matt/x86_64-unknown-linux-gnu/include -isystem 
/home/matt/x86_64-unknown-linux-gnu/sys-include    -o conftest -g -O2 
-flto=jobserver -frandom-seed=1  -static-libstdc++ -static-libgcc 
conftest.c  >&5
configure:11084: $? = 0
configure:11084: ./conftest
/home/matt/src/gcc-trunk/gcc/configure: line 1997:  4819 Aborted 
./conftest$ac_exeext
configure:11084: $? = 134
configure: program exited with status 134
configure: failed program was:
[...]


PS: I imagine anyone with an Ubuntu 11.10/amd64 installation (or something 
similar) would have the same issue. I'll try and reproduce on 11.04 and a 
fresh 11.10, as I have time, as well.


--
tangled strands of DNA explain the way that I behave.
http://www.clock.org/~matt

Re: bootstrap comparison failure with bootstrap-lto

[Ian Lance Taylor]

Matt <matt@use.net> writes:

> It *kind of* says why. I've pasted the output below. Unfortunately,
> when the full build is finished, the prev-gcc/xgcc no longer
> exists. When I test the conftest.c (copied and pasted from the log),
> the stage1-gcc/xgcc and stage2-gcc/xgcc have no problem with it (of
> course).

OK, if this works after the build is complete, then you are going to
need to stop the build in the middle.  Fortunately, this can be done
easily enough by running "make configure-stage2-gcc".  That should stop
after the stage2-gcc directory is configured.  At that point, you should
see a stage2-gcc directory and a prev-gcc directory.  Presumably the
stage2-gcc/config.log file will show a failure, and with luck you will
be able to recreate that failure at that point.

Ian

Re: bootstrap comparison failure with bootstrap-lto

[Matt]

On Thu, 17 Nov 2011, Ian Lance Taylor wrote:

> Matt <matt@use.net> writes:
>
>> It *kind of* says why. I've pasted the output below. Unfortunately,
>> when the full build is finished, the prev-gcc/xgcc no longer
>> exists. When I test the conftest.c (copied and pasted from the log),
>> the stage1-gcc/xgcc and stage2-gcc/xgcc have no problem with it (of
>> course).
>
> OK, if this works after the build is complete, then you are going to
> need to stop the build in the middle.  Fortunately, this can be done
> easily enough by running "make configure-stage2-gcc".  That should stop
> after the stage2-gcc directory is configured.  At that point, you should
> see a stage2-gcc directory and a prev-gcc directory.  Presumably the
> stage2-gcc/config.log file will show a failure, and with luck you will
> be able to recreate that failure at that point.

Do I need to run a complete build first? When I run that make target right 
after configure, it fails in multiple ways when building from r181491:

matt@matt-desktop:~/src/gcc-trunk/obj$ ../configure --enable-bootstrap 
--prefix=/home/matt --enable-clocale=gnu --with-system-zlib 
--enable-shared --with-demangler-in-ld --enable-lto 
--with-build-config=bootstrap-lto --with-fpmath=sse 
--enable-languages=c,c++,lto

[...]

matt@matt-desktop:~/src/gcc-trunk/obj$ make configure-stage2-gcc
make[1]: Entering directory `/home/matt/src/gcc-trunk/obj'
mv: cannot stat `stage1-gcc': No such file or directory
make[1]: *** [stage2-start] Error 1
make[1]: Leaving directory `/home/matt/src/gcc-trunk/obj'
make: *** [configure-stage2-lto-plugin] Error 2

matt@matt-desktop:~/src/gcc-trunk/obj$ make configure-stage2-gcc
mkdir -p -- ./lto-plugin
Configuring stage 2 in ./lto-plugin
configure: creating cache ./config.cache
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking for x86_64-unknown-linux-gnu-gcc... 
/home/matt/src/gcc-trunk/obj/./prev-gcc/xgcc 
-B/home/matt/src/gcc-trunk/obj/./prev-gcc/ 
-B/home/matt/x86_64-unknown-linux-gnu/bin/ 
-B/home/matt/x86_64-unknown-linux-gnu/bin/ 
-B/home/matt/x86_64-unknown-linux-gnu/lib/ -isystem 
/home/matt/x86_64-unknown-linux-gnu/include -isystem 
/home/matt/x86_64-unknown-linux-gnu/sys-include
checking for C compiler default output file name...
configure: error: in `/home/matt/src/gcc-trunk/obj/lto-plugin':
configure: error: C compiler cannot create executables
See `config.log' for more details.
make: *** [configure-stage2-lto-plugin] Error 77

Weird.

By the way, thanks for taking the time to help me work through debugging 
this issue so I can file a meaningful bug. I really appreciate it :)

--
tangled strands of DNA explain the way that I behave.
http://www.clock.org/~matt

Re: bootstrap comparison failure with bootstrap-lto

[Ian Lance Taylor]

Matt <matt@use.net> writes:

> Do I need to run a complete build first? When I run that make target
> right after configure, it fails in multiple ways when building from
> r181491:

Hmmmm, you're right, it doesn't work.  Sounds like a bug.  Try running
"make all-stage1" (I had to run it a couple of times for some reason)
and then run "make configure-stage2-gcc" (which I also had to run
twice).  You should wind up with a prev-gcc directory and a gcc
directory.  The gcc directory is what will in the end become stage2-gcc.

> By the way, thanks for taking the time to help me work through
> debugging this issue so I can file a meaningful bug. I really
> appreciate it :)

Thanks for helping to try to sort this out.

Ian

Re: bootstrap comparison failure with bootstrap-lto

[Matt]

On Fri, 18 Nov 2011, Ian Lance Taylor wrote:

> Matt <matt@use.net> writes:
>
>> Do I need to run a complete build first? When I run that make target
>> right after configure, it fails in multiple ways when building from
>> r181491:
>
> Hmmmm, you're right, it doesn't work.  Sounds like a bug.  Try running
> "make all-stage1" (I had to run it a couple of times for some reason)
> and then run "make configure-stage2-gcc" (which I also had to run
> twice).  You should wind up with a prev-gcc directory and a gcc
> directory.  The gcc directory is what will in the end become stage2-gcc.

Should I file a bug about the multiple runs being necessary? I poked 
around a bit and it seemed that different -j options results in a 
different number of tries. That being said, even -j1 required multiple 
tries. (This may be a symptom of one of the issues that causes my builds 
to fail spectacularly every blue moon when doing -jN>6.)

Beyond that, I now have the binary generated by prev-gcc/xgcc and it does 
indeed crash:

Starting program: /home/matt/src/gcc-trunk/obj/conftest

Program received signal SIGABRT, Aborted.
0x00007ffff7a733a5 in __GI_raise (sig=6) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:64
64	../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or 
directory.
 	in ../nptl/sysdeps/unix/sysv/linux/raise.c
(gdb) bt
#0  0x00007ffff7a733a5 in __GI_raise (sig=6) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00007ffff7a76b0b in __GI_abort () at abort.c:92
#2  0x00000000004003c9 in main () at /tmp/conf.c:270


Is it tripping over a bug in the system compiler (again, GCC 4.6.1-based 
default from Ubuntu 11.10)?

Let me know how you'd like me to proceed.

Thanks!



--
tangled strands of DNA explain the way that I behave.
http://www.clock.org/~matt

Re: bootstrap comparison failure with bootstrap-lto

[Ian Lance Taylor]

Matt <matt@use.net> writes:

> Should I file a bug about the multiple runs being necessary? I poked
> around a bit and it seemed that different -j options results in a
> different number of tries. That being said, even -j1 required multiple
> tries. (This may be a symptom of one of the issues that causes my
> builds to fail spectacularly every blue moon when doing -jN>6.)

Sure, go ahead and file a bug.  It would be nice to get these things
cleaned up.


> Beyond that, I now have the binary generated by prev-gcc/xgcc and it
> does indeed crash:
>
> Starting program: /home/matt/src/gcc-trunk/obj/conftest
>
> Program received signal SIGABRT, Aborted.
> 0x00007ffff7a733a5 in __GI_raise (sig=6) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> 64	../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or
> directory.
> 	in ../nptl/sysdeps/unix/sysv/linux/raise.c
> (gdb) bt
> #0  0x00007ffff7a733a5 in __GI_raise (sig=6) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> #1  0x00007ffff7a76b0b in __GI_abort () at abort.c:92
> #2  0x00000000004003c9 in main () at /tmp/conf.c:270
>
>
> Is it tripping over a bug in the system compiler (again, GCC
> 4.6.1-based default from Ubuntu 11.10)?
>
> Let me know how you'd like me to proceed.

Great.  I think that now we've cleared through the weeds and gotten to
the interesting part: why does it crash?  I think the failing test is
gcc_AC_INITFINI_ARRAY in gcc/acinclude.m4.  It is intended to see
whether the host linker correctly supports a mix of .init_array and
.ctors sections with priorities.  This test is intended to be more or
less independent of the compiler, and is intended to only test the
linker.  Both the host gcc used to build stage1 and the stage1 gcc
itself are presumably using the same linker (right?).  So, why would the
test pass with the host gcc and fail with the stage1 gcc?

If you can trace the points at which the static variable "count"
changes, that may help us pin down what is going wrong.

Ian

Re: bootstrap comparison failure with bootstrap-lto

[Matt]

On Fri, 18 Nov 2011, Ian Lance Taylor wrote:

> Matt <matt@use.net> writes:
>
>> Should I file a bug about the multiple runs being necessary? I poked
>> around a bit and it seemed that different -j options results in a
>> different number of tries. That being said, even -j1 required multiple
>> tries. (This may be a symptom of one of the issues that causes my
>> builds to fail spectacularly every blue moon when doing -jN>6.)
>
> Sure, go ahead and file a bug.  It would be nice to get these things
> cleaned up.

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

  I added you on the cc for it, hope you don't mind.


> Great.  I think that now we've cleared through the weeds and gotten to
> the interesting part: why does it crash?  I think the failing test is
> gcc_AC_INITFINI_ARRAY in gcc/acinclude.m4.  It is intended to see
> whether the host linker correctly supports a mix of .init_array and
> .ctors sections with priorities.  This test is intended to be more or
> less independent of the compiler, and is intended to only test the
> linker.  Both the host gcc used to build stage1 and the stage1 gcc
> itself are presumably using the same linker (right?).  So, why would the
> test pass with the host gcc and fail with the stage1 gcc?
>
> If you can trace the points at which the static variable "count"
> changes, that may help us pin down what is going wrong.

Pin down, indeed :) When I try to watch or print 'count', I get this from 
GDB:
Reading symbols from /home/matt/src/gcc-trunk/obj/conftest...done.
(gdb) watch count
Watchpoint 1: count
(gdb) run
Starting program: /home/matt/src/gcc-trunk/obj/conftest
Error evaluating expression for watchpoint 1
value has been optimized out
Watchpoint 1 deleted.

So, it looks like an optimization bug of a sort to my naive eyes. As such, 
I started trying different combinations on the compile line, the original 
was:
/home/matt/src/gcc-trunk/obj/./prev-gcc/xgcc 
-B/home/matt/src/gcc-trunk/obj/./prev-gcc/ 
-B/home/matt/x86_64-unknown-linux-gnu/bin/ 
-B/home/matt/x86_64-unknown-linux-gnu/bin/ 
-B/home/matt/x86_64-unknown-linux-gnu/lib/ -isystem 
/home/matt/x86_64-unknown-linux-gnu/include -isystem 
/home/matt/x86_64-unknown-linux-gnu/sys-include  -o conftest -g -O2 
-flto=jobserver -frandom-seed=1  -static-libstdc++ -static-libgcc ~/finitest.c


If I take out the -flto=jobserver, the test no longer crashes and the 
variable is no longer optimized out incorrectly. Trying other -flto 
variants all elicited the original problem. When I tested compilation 
using the trunk *or* the system compiler (GCC 4.6.1-based) with 
-O2 -flto, I was able to repeat the problem exactly.

Is this a wrong-code bug, and/or should that test never be 
compiled with -flto?


--
tangled strands of DNA explain the way that I behave.
http://www.clock.org/~matt

Re: bootstrap comparison failure with bootstrap-lto

[Ian Lance Taylor]

Matt <matt@use.net> writes:

>> Great.  I think that now we've cleared through the weeds and gotten to
>> the interesting part: why does it crash?  I think the failing test is
>> gcc_AC_INITFINI_ARRAY in gcc/acinclude.m4.  It is intended to see
>> whether the host linker correctly supports a mix of .init_array and
>> .ctors sections with priorities.  This test is intended to be more or
>> less independent of the compiler, and is intended to only test the
>> linker.  Both the host gcc used to build stage1 and the stage1 gcc
>> itself are presumably using the same linker (right?).  So, why would the
>> test pass with the host gcc and fail with the stage1 gcc?
>>
>> If you can trace the points at which the static variable "count"
>> changes, that may help us pin down what is going wrong.
>
> Pin down, indeed :) When I try to watch or print 'count', I get this
> from GDB:
> Reading symbols from /home/matt/src/gcc-trunk/obj/conftest...done.
> (gdb) watch count
> Watchpoint 1: count
> (gdb) run
> Starting program: /home/matt/src/gcc-trunk/obj/conftest
> Error evaluating expression for watchpoint 1
> value has been optimized out
> Watchpoint 1 deleted.
>
> So, it looks like an optimization bug of a sort to my naive eyes.

It more likely is a problem with the generating of debug info for
optimized code, rather than an optimization bug per se.  It's fairly
normal to have problem running the debugger on optimized code.

> As
> such, I started trying different combinations on the compile line, the
> original was:
> /home/matt/src/gcc-trunk/obj/./prev-gcc/xgcc
> -B/home/matt/src/gcc-trunk/obj/./prev-gcc/
> -B/home/matt/x86_64-unknown-linux-gnu/bin/
> -B/home/matt/x86_64-unknown-linux-gnu/bin/
> -B/home/matt/x86_64-unknown-linux-gnu/lib/ -isystem
> /home/matt/x86_64-unknown-linux-gnu/include -isystem
> /home/matt/x86_64-unknown-linux-gnu/sys-include  -o conftest -g -O2
> -flto=jobserver -frandom-seed=1  -static-libstdc++ -static-libgcc
> ~/finitest.c
>
>
> If I take out the -flto=jobserver, the test no longer crashes and the
> variable is no longer optimized out incorrectly. Trying other -flto
> variants all elicited the original problem. When I tested compilation
> using the trunk *or* the system compiler (GCC 4.6.1-based) with -O2
> -flto, I was able to repeat the problem exactly.
>
> Is this a wrong-code bug, and/or should that test never be compiled
> with -flto?

That's interesting.  Where did the -flto=jobserver option come from?
Did you add that?

Looking at this, I think that this kind of test is going to fail when
using -flto and gold, because gold is going to report that the symbols
listed in the .ctors and .init_array sections are not visible from the
outside.  Unfortunately this is not simple to fix in gold.  In fact, I'm
not sure it's possible in the general case.

Ian

Re: bootstrap comparison failure with bootstrap-lto

[Matt Hargett]

On Nov 19, 2011, at 10:50 PM, Ian Lance Taylor <iant@google.com> wrote:

> Matt <matt@use.net> writes:
> 
>>> Great.  I think that now we've cleared through the weeds and gotten to
>>> the interesting part: why does it crash?  I think the failing test is
>>> gcc_AC_INITFINI_ARRAY in gcc/acinclude.m4.  It is intended to see
>>> whether the host linker correctly supports a mix of .init_array and
>>> .ctors sections with priorities.  This test is intended to be more or
>>> less independent of the compiler, and is intended to only test the
>>> linker.  Both the host gcc used to build stage1 and the stage1 gcc
>>> itself are presumably using the same linker (right?).  So, why would the
>>> test pass with the host gcc and fail with the stage1 gcc?
>>> 
>>> If you can trace the points at which the static variable "count"
>>> changes, that may help us pin down what is going wrong.
>> 
>> Pin down, indeed :) When I try to watch or print 'count', I get this
>> from GDB:
>> Reading symbols from /home/matt/src/gcc-trunk/obj/conftest...done.
>> (gdb) watch count
>> Watchpoint 1: count
>> (gdb) run
>> Starting program: /home/matt/src/gcc-trunk/obj/conftest
>> Error evaluating expression for watchpoint 1
>> value has been optimized out
>> Watchpoint 1 deleted.
>> 
>> So, it looks like an optimization bug of a sort to my naive eyes.
>> 
>> If I take out the -flto=jobserver, the test no longer crashes and the
>> variable is no longer optimized out incorrectly. Trying other -flto
>> variants all elicited the original problem. When I tested compilation
>> using the trunk *or* the system compiler (GCC 4.6.1-based) with -O2
>> -flto, I was able to repeat the problem exactly.
>> 
>> Is this a wrong-code bug, and/or should that test never be compiled
>> with -flto?
> 
> That's interesting.  Where did the -flto=jobserver option come from?
> Did you add that?

That commandline was pulled out of the config.log. My guess is that setting the profile to bootstrap-lto during configure does it. This might not have been seen before if no one tried using bootstrap-lto on a system where gold is the default system linker.


> Looking at this, I think that this kind of test is going to fail when
> using -flto and gold, because gold is going to report that the symbols
> listed in the .ctors and .init_array sections are not visible from the
> outside.  Unfortunately this is not simple to fix in gold.  In fact, I'm
> not sure it's possible in the general case.

Do we have enough info to file an actionable bug (or bugs)? if so, should I file it under the bootstrap component?

Re: bootstrap comparison failure with bootstrap-lto

[Ian Lance Taylor]

Matt Hargett <matt@use.net> writes:

>> Looking at this, I think that this kind of test is going to fail when
>> using -flto and gold, because gold is going to report that the symbols
>> listed in the .ctors and .init_array sections are not visible from the
>> outside.  Unfortunately this is not simple to fix in gold.  In fact, I'm
>> not sure it's possible in the general case.
>
> Do we have enough info to file an actionable bug (or bugs)? if so, should I file it under the bootstrap component?

I filed http://gcc.gnu.org/PR51225 .

I'm testing a patch to add -fno-lto when running that test in the
configure script.

Ian