From: Ian Lance Taylor <iant@google.com>
To: Matt <matt@use.net>
Cc: gcc-help@gcc.gnu.org
Subject: Re: bootstrap comparison failure with bootstrap-lto
Date: Sat, 19 Nov 2011 15:37:00 -0000 [thread overview]
Message-ID: <mcrpqgolxw0.fsf@dhcp-172-18-216-180.mtv.corp.google.com> (raw)
In-Reply-To: <Pine.NEB.4.64.1111181446330.20625@cesium.clock.org> (matt@use.net's message of "Fri, 18 Nov 2011 14:50:15 -0800 (PST)")
Matt <matt@use.net> 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
next prev parent reply other threads:[~2011-11-19 1:11 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-14 22:23 Matt
2011-11-15 5:56 ` Ian Lance Taylor
2011-11-16 21:55 ` Matt
2011-11-17 5:43 ` Ian Lance Taylor
2011-11-18 6:35 ` Matt
2011-11-18 13:47 ` Ian Lance Taylor
2011-11-18 21:08 ` Matt
2011-11-19 1:11 ` Ian Lance Taylor
2011-11-19 2:41 ` Matt
2011-11-19 15:37 ` Ian Lance Taylor [this message]
2011-11-20 6:51 ` Matt
2011-11-20 7:32 ` Ian Lance Taylor
2011-11-20 20:23 ` Matt Hargett
2011-11-21 17:27 ` Ian Lance Taylor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=mcrpqgolxw0.fsf@dhcp-172-18-216-180.mtv.corp.google.com \
--to=iant@google.com \
--cc=gcc-help@gcc.gnu.org \
--cc=matt@use.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).