Re: Test suite regressions

[Tom Tromey <tromey at redhat dot com>]

Mark> But running make check-target-libjava takes a very long time (a
Mark> lot of WARNING: program timed out messages).

That's a known problem.  I think someone is working on it.

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

Before the latest changes to the branch I had 2 FAILs.  That really
should be 0, and that's something I'll fix (probably by simply adding
some xfails) when I get a chance.

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

If you're working on the runtime then in general there won't be a test
for any bug you might fix.  Ideally every library bug fix would be
accompanied by a new Mauve regression test.  FWIW I haven't been
running against Mauve when I do my testing.

Mostly though I am concerned about compiler changes.  For the sorts of
library changes that will go on the 3.0 branch, we'll almost always
know the consequences.  Changes to the compiler seem to be a lot
touchier.

Tom