public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Alexandre Oliva <aoliva@redhat.com>
To: gcc@gcc.gnu.org
Subject: VTA bootstrap compare failures
Date: Wed, 02 Sep 2009 16:46:00 -0000	[thread overview]
Message-ID: <or7hwh9tw7.fsf@huru.localdomain> (raw)

Along with the VTA merge, a change was installed that made
bootstrap-debug BUILD_CONFIG the default.

This means stage2 is built with -g0, and stage3 is built with -g, and
then we compare the object files after stripping them.

Although this works fine on numerous GNU/Linux platforms on which I
tested it, and the bootstrap-debug option has been available and
recommended, even in the trunk, for quite a while, without any problem
reports whatsoever, making it default immediately showed it hadn't got
much testing elsewhere :-(

PRs 41224 and 41228 are the ones I know about.  Basically, the problem
is that stripping is not enough to get identical object files.
Significant differences remain, even after stripping.

So I guess we'll have to find a way to enable bootstrap-debug only when
this works.  I can't think of a way to test whether it comparing
stripped -g0 and -g object files works using the stage1 compiler, but I
guess if we test the compiler used to build stage1 and that works, we
should strive to ensure the stage1 compiler works as well.

So tonight I'll write a patch that performs a contrib/compare-debug test
and enables or disables BUILD_CONFIG=bootstrap-debug accordingly.  I
hereby ask for help, as mentioned in the bug reports, in coming up with
a minimal testcase that is enough to fail contrib/compare-debug on the
affected platforms.  I assume a trivial main(){} wouldn't do, but
perhaps even that might.  If you are willing to help, please test:

cat > test.c << EOF
void f() {}
EOF
gcc -c -g0 test.c -o test-g0.o
gcc -c -g test.c -o test-g.o
.../gcc/contrib/compare-debug test-g0.o test-g.o
echo $?

If it prints 0 at the end, this is too simple a testcase, and we need
something more complex to trigger a compare error.  If it prints 1, we
have something we can use.


Now, if you're not interested in helping come up with this minimal
testcase, but still want bootstrap to pass, please drop bootstrap-debug
from the BUILD_CONFIG line in Makefile.in, or override BUILD_CONFIG in
the make command line.

If anyone feels this is serious and urgent enough to deserve a reversal,
please revert only the Makefile.* changes.  I won't be around much for
the next 6 hours or so, but I'll deal with it as soon as I return.


Thanks,

-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist      Red Hat Brazil Compiler Engineer

                 reply	other threads:[~2009-09-02 16:46 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=or7hwh9tw7.fsf@huru.localdomain \
    --to=aoliva@redhat.com \
    --cc=gcc@gcc.gnu.org \
    /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).