Test suite regressions

Mon Mar 19 13:26:00 GMT 2001

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