This is the mail archive of the
mailing list for the GCC project.
Re: [trunk<-vta] Re: [vta,vta4.3,trunk?] introduce -fcompare-debug
- From: Richard Guenther <richard dot guenther at gmail dot com>
- To: Alexandre Oliva <aoliva at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Tue, 2 Jun 2009 11:16:14 +0200
- Subject: Re: [trunk<-vta] Re: [vta,vta4.3,trunk?] introduce -fcompare-debug
- References: <email@example.com> <firstname.lastname@example.org>
On Mon, Jun 1, 2009 at 10:08 AM, Alexandre Oliva <email@example.com> wrote:
> On Sep 11, 2008, Alexandre Oliva <firstname.lastname@example.org> wrote:
>> This patch introduces a better mechanism to test that the compiler
>> produces the same output with and without -g than the one I've been
>> using before.
>> With this option, the compiler will compile the same program twice,
>> dumping the final RTL and comparing the dumps. ?This will enable us to
>> verify that -g and/or -fvar-tracking-assignments have no codegen
>> effects on our entire testsuite, and any other codebase you might want
>> to compile with -fcompare-debug.
>> This has already uncovered a number of codegen differences in a full
>> build, that had been missed by bootstrap-debug and
>> bootstrap-debug-lib. ?I've already fixed some of them, but I still
>> have others to fix.
>> This also exposed a number of situations in which GCC compilers
>> (rather than drivers) dumped information to stdout or to files not
>> mentioned in the command line. ?The patch below takes care of the ones
>> I've located so far.
>> One shortcoming of this approach is that it doesn't notice differences
>> that aren't represented as RTL, such as data variable definitions and
>> anything else that is not part of a function RTL. ?I still haven't
>> tried to add variables, initializers and constant pools, but this
>> shouldn't be too hard, except that debug information output must be
>> prevented from causing differences in the dumps.
>> This could be useful for GCC even without VTA, to detect latent
>> errors. ?Probably too late for 4.4, but hey, it doesn't hurt to ask.
>> Ok to install?
> Ok for trunk?
I don't think we should expose all this stuff to our users.