This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: C++ compatibility testing


On Fri, Sep 20, 2002 at 02:58:54PM -0700, Janis Johnson wrote:
> Phil and Benjamin,
> 
> I'm again looking into how to set up tests within the GCC testsuite to
> build two pieces of a C++ test using different versions of GCC and then
> linking them and running the test.  Phil, you mentioned that you might
> try this (http://gcc.gnu.org/ml/gcc/2002-08/msg01259.html); please let
> me know if you're doing something similar.

Er, well, best laid plans...

    http://gcc.gnu.org/ml/libstdc++/2002-09/msg00119.html

Still catching up on versioning work.


> If you've got a scheme for
> specifying a second compiler for the test tools to use, let me know what
> it is.

When you posted your script to do this, you wrote:

> They required either building
> object files with older compilers ahead of time and then using those
> archived files when testing the new compiler, or else having both old
> and new compilers available when running the tests.

I will be using the second approach, since I already have both compilers:

    http://gcc.gnu.org/ml/gcc/2002-08/msg01133.html

For each night, I can just run the autocrasher, then I have both branches
available in an easily computable pathname:

    27% ls -d build/*2002-09-21*
    build/build-2002-09-21/        build/install-2002-09-21/
    build/build-2002-09-21-3.2/    build/install-2002-09-21-3.2/
    build/build-2002-09-21-trunk/  build/install-2002-09-21-trunk/
    28%

So, using a variant of your script, OLDCXX is install-(the_date)-3.2/bin/g++
and NEWCXX is install-(the_date)-trunk/bin/g++.


I still have not thought of a decent way to do this inside the gcc testsuite.
It may be that we need to use the first approach for general testing,
and have some .o's sitting around for people.


> After I've got things working with building simple relocatable objects
> and linking them together, I'll try building the pieces of a test into
> static and/or shared libraries in the hopes of finding different kinds
> of problems.  That might be messy using dejagnu, though, and I only have
> GNU/Linux systems on which to try out my changes.

You might (or might not) find it easier to use the QMTest thingy that
the Software Carpentry slash CodeSorcery folks are putting together.
I made one pass, but apparently my version of Python was too recent.
At any rate, making "unusual" configurations work is supposed to be much
easier in QMTest than in DejaGNU.


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]