Matt <matt@xxxxxxx> 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
