* bootstrap comparison failure with bootstrap-lto
@ 2011-11-14 22:23 Matt
2011-11-15 5:56 ` Ian Lance Taylor
0 siblings, 1 reply; 14+ messages in thread
From: Matt @ 2011-11-14 22:23 UTC (permalink / raw)
To: gcc-help
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: bootstrap comparison failure with bootstrap-lto
2011-11-14 22:23 bootstrap comparison failure with bootstrap-lto Matt
@ 2011-11-15 5:56 ` Ian Lance Taylor
2011-11-16 21:55 ` Matt
0 siblings, 1 reply; 14+ messages in thread
From: Ian Lance Taylor @ 2011-11-15 5:56 UTC (permalink / raw)
To: Matt; +Cc: gcc-help
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: bootstrap comparison failure with bootstrap-lto
2011-11-15 5:56 ` Ian Lance Taylor
@ 2011-11-16 21:55 ` Matt
2011-11-17 5:43 ` Ian Lance Taylor
0 siblings, 1 reply; 14+ messages in thread
From: Matt @ 2011-11-16 21:55 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: gcc-help
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
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: bootstrap comparison failure with bootstrap-lto
2011-11-16 21:55 ` Matt
@ 2011-11-17 5:43 ` Ian Lance Taylor
2011-11-18 6:35 ` Matt
0 siblings, 1 reply; 14+ messages in thread
From: Ian Lance Taylor @ 2011-11-17 5:43 UTC (permalink / raw)
To: Matt; +Cc: gcc-help
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: bootstrap comparison failure with bootstrap-lto
2011-11-17 5:43 ` Ian Lance Taylor
@ 2011-11-18 6:35 ` Matt
2011-11-18 13:47 ` Ian Lance Taylor
0 siblings, 1 reply; 14+ messages in thread
From: Matt @ 2011-11-18 6:35 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: gcc-help
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: bootstrap comparison failure with bootstrap-lto
2011-11-18 6:35 ` Matt
@ 2011-11-18 13:47 ` Ian Lance Taylor
2011-11-18 21:08 ` Matt
0 siblings, 1 reply; 14+ messages in thread
From: Ian Lance Taylor @ 2011-11-18 13:47 UTC (permalink / raw)
To: Matt; +Cc: gcc-help
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: bootstrap comparison failure with bootstrap-lto
2011-11-18 13:47 ` Ian Lance Taylor
@ 2011-11-18 21:08 ` Matt
2011-11-19 1:11 ` Ian Lance Taylor
0 siblings, 1 reply; 14+ messages in thread
From: Matt @ 2011-11-18 21:08 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: gcc-help
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: bootstrap comparison failure with bootstrap-lto
2011-11-18 21:08 ` Matt
@ 2011-11-19 1:11 ` Ian Lance Taylor
2011-11-19 2:41 ` Matt
0 siblings, 1 reply; 14+ messages in thread
From: Ian Lance Taylor @ 2011-11-19 1:11 UTC (permalink / raw)
To: Matt; +Cc: gcc-help
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: bootstrap comparison failure with bootstrap-lto
2011-11-19 1:11 ` Ian Lance Taylor
@ 2011-11-19 2:41 ` Matt
2011-11-19 15:37 ` Ian Lance Taylor
0 siblings, 1 reply; 14+ messages in thread
From: Matt @ 2011-11-19 2:41 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: gcc-help
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: bootstrap comparison failure with bootstrap-lto
2011-11-19 2:41 ` Matt
@ 2011-11-19 15:37 ` Ian Lance Taylor
2011-11-20 6:51 ` Matt
0 siblings, 1 reply; 14+ messages in thread
From: Ian Lance Taylor @ 2011-11-19 15:37 UTC (permalink / raw)
To: Matt; +Cc: gcc-help
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: bootstrap comparison failure with bootstrap-lto
2011-11-19 15:37 ` Ian Lance Taylor
@ 2011-11-20 6:51 ` Matt
2011-11-20 7:32 ` Ian Lance Taylor
0 siblings, 1 reply; 14+ messages in thread
From: Matt @ 2011-11-20 6:51 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: gcc-help
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: bootstrap comparison failure with bootstrap-lto
2011-11-20 6:51 ` Matt
@ 2011-11-20 7:32 ` Ian Lance Taylor
2011-11-20 20:23 ` Matt Hargett
0 siblings, 1 reply; 14+ messages in thread
From: Ian Lance Taylor @ 2011-11-20 7:32 UTC (permalink / raw)
To: Matt; +Cc: gcc-help
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: bootstrap comparison failure with bootstrap-lto
2011-11-20 7:32 ` Ian Lance Taylor
@ 2011-11-20 20:23 ` Matt Hargett
2011-11-21 17:27 ` Ian Lance Taylor
0 siblings, 1 reply; 14+ messages in thread
From: Matt Hargett @ 2011-11-20 20:23 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: gcc-help
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?
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: bootstrap comparison failure with bootstrap-lto
2011-11-20 20:23 ` Matt Hargett
@ 2011-11-21 17:27 ` Ian Lance Taylor
0 siblings, 0 replies; 14+ messages in thread
From: Ian Lance Taylor @ 2011-11-21 17:27 UTC (permalink / raw)
To: Matt Hargett; +Cc: gcc-help
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
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2011-11-21 5:03 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-11-14 22:23 bootstrap comparison failure with bootstrap-lto Matt
2011-11-15 5:56 ` Ian Lance Taylor
2011-11-16 21:55 ` Matt
2011-11-17 5:43 ` Ian Lance Taylor
2011-11-18 6:35 ` Matt
2011-11-18 13:47 ` Ian Lance Taylor
2011-11-18 21:08 ` Matt
2011-11-19 1:11 ` Ian Lance Taylor
2011-11-19 2:41 ` Matt
2011-11-19 15:37 ` Ian Lance Taylor
2011-11-20 6:51 ` Matt
2011-11-20 7:32 ` Ian Lance Taylor
2011-11-20 20:23 ` Matt Hargett
2011-11-21 17:27 ` Ian Lance Taylor
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).