Pristine gcc-4.6.2 result on Solaris 8 Sparc

Pristine gcc-4.6.2 result on Solaris 8 Sparc

[Dennis Clarke]

  * wow *

I want to thank a pile of great guys here on the gcc/gcc-help ml as your
input allowed me to dig and dig and find the root cause of many strange
failures here on my Solaris builds. Since the SPARC platform is still a
very widely used production platform it was of great interest to me to
ensure that very best quality build and not merely "good enough".

Thus I present something pristine and beautiful :

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

I had to stare at those results and blink a few times. A stark contrast to
previous results and I know this happened because of valuable input from
Rainer Orth, Andrew Haley, Michael Haubenwallner, Ian Lance Taylor and a
few others that chimed in with pointers, no pun intended.

We have a whole new stack of software at Blastwave and the compiler is a
critical piece. Always has been, always will be, and this result on Sparc
must be built and tested on Solaris 8. Solaris 10 can run anything that
was compiled on Solaris 8 flawlessly and thanks to the ABI rules that
includes Solaris 9. This explains why the ccompiler and similar tools must
be built on Solaris 8.

In any case, I am happy with these results as I refuse to release a
compiler without *public* tests results and I think the tests I just
posted are perfect for the GCC project "successful builds" page.  GCC is
the essential piece of any open source software stack and must b qualified
and verified. I am so very happy with these results!

Thank you all for an awesome open source compiler!

Dennis Clarke
dclarke@blastwave.org

ps: still working on Solaris 8 i386 and Solaris 10 x86_64
    A week of work at least is required .. but I'll get there!

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

---------------------------- Original Message ----------------------------
Subject: Re: # of unexpected failures        768 ?
From:    "Rainer Orth" <ro@CeBiTec.Uni-Bielefeld.DE>
Date:    Mon, October 31, 2011 10:33
To:      dclarke@blastwave.org
Cc:      gcc@gcc.gnu.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.

> 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