This is the mail archive of the
mailing list for the GCC project.
Re: GCC 3.2
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
* > 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
> libstdc++ consistency from release to release
Exists as of a couple hours ago...
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
> whatever we want
> part of every testsuite run
> 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
> anything for the compiler and runtime support library
> has the potential to uncover unexpected problems that wouldn't be
> detected by other testing
> 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!
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