Re: GCC2 merging (was "native language support now available")

[Richard Earnshaw <rearnsha at arm dot com>]

>   kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:
> > 
> > say that such testing isn't very valuable.  The kind of testing that's the
> > most important in producing high reliability software is *unit testing*,
> > which means testing each function individually to make sure it meets its
> > specifications under all conditions.  As far as I know, this is not done for
> > either gcc2 or egcs.
> > 
> IMHO it's difficult if not impossible to verify gcc this way. Just look at
> the bugs squashed during egcs-1.1 development. Many of them only surfaced
> under very specific circumstances and the test programs frequently are
> twenty lines of C, all important to trigger the bug.
> 
> Mind you, I don't have a better answer either...
> 

The problem lies in the fact that an optimizing compiler works by 
performing a series of transforms on its input.  These transforms are 
piled on top of each other, so transforms performed later in the 
compilation will be done differently depending on earlier transforms.  
Trying to reliably test, say, the reload pass by using a C source file is 
a nightmare, since small changes to earlier transforms can completely 
change the behaviour of the reload pass.

One solution *might* be to have an RTL reader in the compiler along with 
flags to make it just run particular passes of the compiler -- but even 
that wouldn't be easy because rtl dumps don't currently contain the 
complete meta data for the compilation.