Test suite regressions

[Per Bothner]

Tom Tromey <tromey@redhat.com> writes:

> I updated the gcc3 branch today, rebuilt libjava using the new
> compiler, and ran the test suite.  We had a lot of regressions, over 40.

I guess I've been the worst offender lately.  My only excuse (and not
a good one) was that I really wanted to improve gcc 3 to be solid
enough that I could use it myself (for Kawa), plus I wasn't really use
what was involved in running the testsuite. I now at least am running
'make check' in the libjava directory on a frequent basis, and trying
very hard to bring the regressions down.

By "the testsuite", do you mean anything besides running "make check"
in the libjava build directory?

> For instance, one is appended.
> anon
> ...
> Premature end of .class file <stdin>.
> compiler exited with status 1

I may have a fix for that one; I am running the testsuite right now.

> 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.

Well, that may be going too far:  Sometimes a changes may break a
test-case (which often tests less common uses), but allow an
application to build.  I think the rule should be:  no changes
that causes a test suite regression *unless* it has been discussed
on this list first, and the consensus is that it is worth it.

> 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.

Wel, "working" is not pssing test suites - working is building and
running applications.  The test suite is valuable tool to help us make
sure we are moving in the right directorion.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/