Re: Test suite regressions

[Mark Wielaard <mark at klomp dot org>]

Hi,

On Mon, Mar 19, 2001 at 01:50:10PM -0700, Tom Tromey wrote:
> I think we should adopt a rule whereby we don't check in any change
> that causes a test suite regression.  At the very least this is what
> we should do on the gcc3 branch.  I'm guessing that Mark won't hold up
> the gcc3 release just because Java is broken.  This means we must be
> careful to ensure it is working at all times.

I only have a (more or less) working version of the branch on powerpc.
See <http://gcc.gnu.org/ml/java/2001-03/msg00075.html> for the patches
and configure flags to make it work.

But running make check-target-libjava takes a very long time (a lot of
WARNING: program timed out messages). Running it overnight gave the
following result:

                === libjava Summary ===
                
                # of expected passes            1221
                # of unexpected failures        164
                # of unexpected successes       81
                # of expected failures          254
                
That doesn't look good :( What are the 'correct' numbers?

Does all this mean that I have to set up a i586 machine with a working
branch before commiting? I do have a working trunk on i586, but also setting
up a working branch does mean a lot of extra disk space.
(Note almost all my commits are simple libgcj runtime class changes, I don't
work on the compiler.)

Cheers,

Mark
-- 
Stuff to read:
    <http://www.toad.com/gnu/whatswrong.html>
  What's Wrong with Copy Protection, by John Gilmore