* 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@xxxxxxxxxxxxx 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@xxxxxxxxxxxxx | Respect for open standards. | +-------------------------+-----------------------------------+ ---------------------------- Original Message ---------------------------- Subject: Re: # of unexpected failures 768 ? From: "Rainer Orth" <ro@xxxxxxxxxxxxxxxxxxxxxxxx> Date: Mon, October 31, 2011 10:33 To: dclarke@xxxxxxxxxxxxx Cc: gcc@xxxxxxxxxxx -------------------------------------------------------------------------- Dennis Clarke <dclarke@xxxxxxxxxxxxx> 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
