This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC 3.2
On Wed, Aug 21, 2002 at 03:02:34PM -0400, Phil Edwards wrote:
> 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.
Yes, they are all interconnected.
> 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".)
Yes; I just wanted to make sure that I understood your main focus.
>
> > 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.
What I meant is that I know of no provision for a test to build and use
a shared library that is part of the test itself.
>
> > 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 approach uses two compilers to build pieces of a single test which
are then linked together and run. Is that problem solved?
> This document is extraordinarily helpful. Thanks!
Then I'll keep updating it. Would this be useful as part of the
projects list while we figure out what needs to be done?
Janis