GCC 3.2

[Phil Edwards]

On Wed, Aug 21, 2002 at 11:25:07AM -0700, Janis Johnson wrote:
> You are focusing on libstdc++ testing rather than compiler and runtime
> support, is that correct?

Not speaking for Benjmain but:  yes, mostly, that's my understanding.
But of course changes in the latter could show up while testing the former.

We're /explicitly/ testing the former.  I think the expectation is that
explicit tests for the latter should go into the compiler testsuite.
(And we'll try to help, of course; the division is not so much "who does
the work" but rather "where does the work go".)


   >   compiler and runtime support covered by the C++ ABI:
   >     data layout
   >       layout of class and structure elements
   >       alignment of variables
   >       pointer to data member
   >       pointer to member function
   >       virtual table layout and alignment
   >       array operator "new" cookies
   >       initialization guard variables
   >       run-time type information (RTTI)
   >     function calling conventions and APIs
   >       stack unwind
   >       argument passing
   >       virtual function
   >       demangler API
   >       constructor and destructor APIs
   >     exception handling interfaces
   >     linkage and object files
*  >       name mangling
*  >       linkage of inline functions, vtables
   >       unwind table location
   >     other
*  >       template instantiation
   >       runtime arithmetic support
   > 
   >   C++ Standard Library:
*  >     namespaces
*  >     sizes and layout of externally visible classes and structures
*  >     signatures of externally visible functions

We are working on '*' as we speak.  (Perhaps not the linkage of inline
functions, and layout tests are currently not done.  But vtables and sizes
are.  Well, I /know/ sizes are tested, and I /think/ vtables are tested.)


> Approaches to testing C++ and libstdc++ compatibility, ABI conformance
> 
> libstdc++ consistency
>   http://gcc.gnu.org/ml/libstdc++/2002-08/msg00190.html
> 
>   covers:
>     libstdc++ consistency from release to release
> 
>   advantages:
      Exists as of a couple hours ago...

>   disadvantages:
      Looks like we're going to need to gather more per-OS/-per-CPU
      baseline data than what we originally thought.  Help solicited.


> special-purpose self-checking tests in GCC testsuite
>   covers:
>     whatever we want
> 
>   advantages:
>     part of every testsuite run
> 
>   disadvantages:
>     limited to what the testsuite supports: single file per test, no
>     shared libraries, use of a single compiler

No shared libraries?  I know for a fact that if I accidentally move the
libstdc++.so out of the way, all the testsuite fails when the runtime
loader can't satisfy the dependancies.


> split tests to compile pieces with two compilers
>   http://gcc.gnu.org/ml/gcc/2002-08/msg00712.html
> 
>   covers:
>     anything for the compiler and runtime support library
> 
>   advantages:
>     has the potential to uncover unexpected problems that wouldn't be
>     detected by other testing
> 
>   disadvantages:
>     doesn't yet exist
> 
>     won't easily fit into the GCC testsuite
>       need to have two compilers available when tests are run or else
>       save baseline object files for each platform (.o, .so, .a)
> 
>       building static libraries and shared objects is OS-dependent

I might just have a go at this.  Right now I've automated the "test both
branches, swap the .so's, test both branches again" test that people tried
just before the 3.2 release.  So the two-compilers problem is solved.


This document is extraordinarily helpful.  Thanks!

Phil

-- 
I would therefore like to posit that computing's central challenge, viz. "How
not to make a mess of it," has /not/ been met.
                                                 - Edsger Dijkstra, 1930-2002