This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: results for egcs-2.92.15 586-pc-linux-gnulibc1
> These are the testsuite results for egcs-2.92.15 19981012 on the
> i586-pc-linux-gnulibc1 system.
> (g++.robertl/eb27.C, g++.pt/overload5.C, g++.other/using5.C,
> g++.other/friend5.C, g++.other/decl2.C, g++.ext/typeof1.C)
> Are these explicit checks for internal compiler errors or is there
> something wrong with the dejagnu testsuite mechanism?
They're explicit checks for things that currently happen to cause
internal compiler errors on your target.
> Gcc seems buggy. There are 43 unexpected failures.
That's why they're called "snapshots" and not "releases" :-) Besides,
new tests are frequently being added and they're often added before the
thing they're testing is fixed. That's how the bar gets raised.
If you look closer at the results, you'll see that many of them are the
same test that fail at multiple optimization levels. For example:
> FAIL: gcc.c-torture/compile/930217-1.c, -O1
> FAIL: gcc.c-torture/compile/930217-1.c, -O2
> FAIL: gcc.c-torture/compile/930217-1.c, -O2 -fomit-frame-pointer -finline-functions
> FAIL: gcc.c-torture/compile/930217-1.c, -O2 -g
> FAIL: gcc.c-torture/compile/930217-1.c, -Os
The list you cite sounds about right for a 1012 snap. The last set of
tests I ran on 1016 on a very similar target showed 11 fewer failures
than when the tests I ran on 1012. In fact, this very example no longer
fails on x86. (Thanx, Richard!)
Think of it as a cycle. Tests get added and the number of failures
go up for a while. Then people bang on the fixing newly discovered
failures and the count goes down. Then people add new code and
accidentally subtly break something or expose something that has long
been broken but hidden. This drives the numbers back up. The cycle
repeats.
I think that's just the way development in the bazaar model works.
RJL