> GCC 4.0.1 RC3 is now available here: > > ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.1-20050702/ > > With luck, this will be the last 4.0.1 release candidate.
SPARC/Solaris 8, 9, 10 are OK: http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00140.html http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00141.html http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00142.html We have 1 new failure on SPARC/Solaris 2.5.1, 2.6 and 7 over RC2: http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00137.html http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00138.html http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00139.html WARNING: program timed out. FAIL: 21_strings/basic_string/cons/char/1.cc execution test try { std::string str03(csz01 - 1, 'z'); <--- stuck here VERIFY( str03.size() != 0 ); VERIFY( str03.size() <= str03.capacity() ); } // NB: bad_alloc is regrettable but entirely kosher for // out-of-memory situations. catch(std::bad_alloc& fail) { VERIFY( true ); } catch(...) { VERIFY( false ); } The machines are apparently stuck in 'wmemset' from libc initializing str03, which is a biiiiiiiig object: csz01 = str01.max_size(); This didn't happen in RC2 and I've not investigated what changed. The code is the same on Solaris 7 and 8, but the Solaris 2.5.1, 2.6 and 7 machines are substantially more limited than the Solaris 8, 9 and 10 machines. -- Eric Botcazou
