Re: bootstrap comparison failure with bootstrap-lto

[Ian Lance Taylor <iant@google.com>]

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