# of unexpected failures 768 ?
Rainer Orth
ro@CeBiTec.Uni-Bielefeld.DE
Mon Oct 31 17:22:00 GMT 2011
Dennis Clarke <dclarke@blastwave.org> writes:
> I'm not too sure how many things changed from 4.6.1 to 4.6.2 but I am
> seeing a really large increase in the number of "unexpected failures" on
> various tests.
>
> With 4.6.1 and Solaris I was able to get reasonable results :
>
> http://gcc.gnu.org/ml/gcc-testresults/2011-07/msg00139.html
>
> Then if I use the resultant compiler from a 4.6.1 build I get a massive
> increase in failures on both i386 and Sparc :
>
> http://gcc.gnu.org/ml/gcc-testresults/2011-10/msg03286.html
FAIL: g++.dg/ext/visibility/fvisibility-inlines-hidden-2.C scan-not-hidden
All the scan-not-hidden failures are usually an indication that objdump
isn't in your PATH.
> This seems blatantly wrong. At what point does one throw out the result of
> a bootstrap as not-acceptable ? With any non-zero value for "unexpected
> failures" ?
There's no such number, only comparisons to other testsuite results. In
many cases (e.g. in the scan-not-hidden failures above), there's nothing
wrong with the compiler, just with the test environment. And in your
case, only two problems account for the vast majority of the failures.
> Also, I see bucket loads of these :
>
> FAIL: g++.dg/pch/wchar-1.C -O2 -g -I. (internal compiler error)
>
> What should I think about an "internal compiler error" ?
This seems fundamentally broken on your machine. With the exception of
the largefile.c testcases, those pass everywhere else, so you'd have to
debug what's going on there.
FAIL: gcc.c-torture/compile/limits-exprparen.c -O0 (internal compiler error)
[...]
FAIL: gcc.c-torture/compile/limits-structnest.c -O2 (test for excess errors)
WARNING: program timed out.
Those test cases have excessive stack space or runtime requirements and
are known to fail on slow machines or those with default resource
limits. Those are known testcase bugs, but nobody cared about this so
far ;-(
Overall, your results don't look bad to me, once you've installed
objdump and investigated the PCH failures.
As an asside, I'd suggest to considerably reduce your set of configure
options: many of them are the default (like --without-gnu-ld
--with-ld=/usr/ccs/bin/ld, --enable-nls, --enable-threads=posix,
--enable-shared, --enable-multilib, --host=i386-pc-solaris2.8
--build=i386-pc-solaris2.8) or unnecessary
(--enable-stage1-languages=c).
I'm uncertain if Solaris 8/x86 still supports bare i386 machines, so it
might be better to keep the default of pentiumpro instead.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
More information about the Gcc
mailing list