[trunk<-vta] Re: [vta,vta4.3,trunk?] introduce -fcompare-debug

Richard Guenther richard.guenther@gmail.com
Tue Jun 2 09:16:00 GMT 2009


On Mon, Jun 1, 2009 at 10:08 AM, Alexandre Oliva <aoliva@redhat.com> wrote:
> On Sep 11, 2008, Alexandre Oliva <aoliva@redhat.com> 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?
>
> Ping?
>
> Ok for trunk?

I don't think we should expose all this stuff to our users.

Richard.



More information about the Gcc-patches mailing list