Re: GCC 3.2

[Jeff Law <law at porcupine dot slc dot redhat dot com>]

 In message <20020812164321.A4428@us.ibm.com>, Janis Johnson writes:
 >There are many things that can break compatibility between two releases
 >of a C++ compiler or between two different compilers that are expected
 >to be binary compatible.
Certainly.  

 > In a previous position I set up some tests to
 >help detect such breakage between one release and another.  They
 >occasionally found things like entry points that were thought to no
 >longer be needed in runtime support libraries, or conflicts between
 >symbols in shared objects.  These were tests of compatibility for the
 >compiler and its run-time support, not for functionality within the
 >Standard C++ Library.
Right.  That's one of the reasons why I mentioned in an earlier message
that we need a test which verifies that all of the exported functions
in libstdc++ (and libgcc) are maintained over time -- which has the
side effect of being a reasonable tester for name mangling changes.
We need ways to verify structure layouts aren't changing, etc etc.


 >Existing tests were broken apart into two pieces plus a main program.
Yes.  We had something like this in very old versions of c-torture (before
we moved to the dejagnu framework).  It was never populated with very
many tests and nobody ever wrote a suitable dejagnu framework so that
we could use those tests.

At the time when we brought c-torture into the dejagnu framework I
briefly poked at building a harness which would work for those tests,
but ultimately dropped the project due to lack of time.

 >These tests were a pain to set up, even for testing one compiler on one
 >platform with one operating system. 
Most definitely!

 >and new compilers available when running the tests.  I'm not at all sure
 >how to set up such tests for use with GCC.  The test harness needs to
 >know about two compilers under test rather than one, and the tests need
 >to build static and shared libraries, which GCC tests don't normally do.
 >I don't know how difficult it is with either DejaGNU or QMTest to handle
 >either of these, but if there's interest I'll look into it.
The existing harness for dejagnu doesn't currently know how to do this,
it's something that we definitely need though, along with shared library
support.

jeff