Re: bootstrap comparison failure with bootstrap-lto

[Matt <matt@use.net>]

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