Test suite regressions

Mon Mar 19 13:39:00 GMT 2001

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/