Re: GCC 4.0.1 RC3

[Eric Botcazou <ebotcazou at libertysurf dot fr>]

> 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