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. > 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
