GCC 4.0.1 RC3
Eric Botcazou
ebotcazou@libertysurf.fr
Sun Jul 3 20:54:00 GMT 2005
> 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
More information about the Gcc
mailing list