Re: # of unexpected failures 768 ?

[Dennis Clarke <dclarke@blastwave.org>]

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

Right, thank you. On i386 I rectified that situation with binutils however
on Sparc this was not an issue.

See results :

  http://gcc.gnu.org/ml/gcc-testresults/2011-11/msg00683.html


Only the new "go" language seems to be a major issue now.

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

Any "internal compiler error" mean throw the whole thing out and start
over. At least that is the only safe course of action in my mind.

> 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 ;-(

I'm so happy to hit those special cases :-)


> Overall, your results don't look bad to me, once you've installed
> objdump and investigated the PCH failures.

yep ... I have been digging. On Sparc things are going much better but on
i386 I have tossed the whole scenario out and am starting over from first
principles. Build everything from scratch with the Sun Studio compiler
until I hit things that need gcc. Like libgmp etc.

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

Yep, did that. Thank you. However on i386 things got worse, not better. I
have to toss that out and start over. On Sparc things are much better with
the exception of "go".

Thank you for the input.

Dennis


-- 
--
http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B
+-------------------------+-----------------------------------+
| Dennis Clarke           | Solaris and Linux and Open Source |
| dclarke@blastwave.org   | Respect for open standards.       |
+-------------------------+-----------------------------------+