On Fri, 18 Nov 2011, Ian Lance Taylor wrote:
Matt <matt@xxxxxxx> 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
