The patch for 22309 kills Solaris 2.6, 2.7, 2.8, and 2.9. The failure mode is as
follows:

FAIL: ext/mt_allocator/check_allocate_big_per_type.cc execution test
FAIL: ext/mt_allocator/check_delete.cc execution test
FAIL: ext/mt_allocator/check_new.cc execution test
FAIL: ext/mt_allocator/deallocate_global_thread-1.cc execution test
FAIL: ext/mt_allocator/deallocate_global_thread-3.cc execution test
FAIL: ext/mt_allocator/deallocate_local_thread-1.cc execution test
FAIL: ext/mt_allocator/deallocate_local_thread-3.cc execution test
FAIL: ext/mt_allocator/tune-1.cc execution test
FAIL: ext/mt_allocator/tune-2.cc execution test
FAIL: ext/mt_allocator/tune-3.cc execution test
FAIL: ext/mt_allocator/tune-4.cc execution test

And can be seen here:
http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg01189.html

Eric Botcazou provided the following commentary in private email:

backtrace at -O0:

Program received signal SIGSEGV, Segmentation fault.
0x0001d354 in __gnu_cxx::__pool_base::_M_get_binmap (this=0x30eac, __bytes=40)
    at ext/mt_allocator.h:146
146         { return _M_binmap[__bytes]; }
(gdb) bt
#0  0x0001d354 in __gnu_cxx::__pool_base::_M_get_binmap (this=0x30eac,
    __bytes=40) at ext/mt_allocator.h:146
#1  0x0001d7fc in __gnu_cxx::__mt_alloc<unsigned int, 
__gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true> >::allocate 
(this=0xffbefa3e, __n=10)
    at ext/mt_allocator.h:674
#2  0x0001d940 in __gnu_test::check_new<__gnu_cxx::__mt_alloc<unsigned int, 
__gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true> >, true> 
(a=@0xffbefa3e)
    at testsuite_allocator.h:187
#3  0x0001d9cc in test01 ()
    at
/home/eric/cvs/gcc-4_0-branch/libstdc++-v3/testsuite/ext/mt_allocator/check_new.cc:49
#4  0x0001da7c in main ()
    at
/home/eric/cvs/gcc-4_0-branch/libstdc++-v3/testsuite/ext/mt_allocator/check_new.cc:54

(gdb) p _M_binmap
$1 = (short unsigned int *) 0x0

I put 3 breakpoints in mt_allocator.cc and _M_binmap is never initialized, as 
__gnu_cxx::__common_pool_base<__gnu_cxx::__pool, true>::_S_initialize() is 
never called.

The problem stems from:

      static void
      _S_initialize_once()
      { 
	static bool __init;
	if (__builtin_expect(__init == false, false))
	  {
	    if (__gthread_active_p())
	      {
		// On some platforms, __gthread_once_t is an aggregate.
		static __gthread_once_t __once = __GTHREAD_ONCE_INIT;
		__gthread_once(&__once, _S_initialize);
	      }
	    else
	      _S_get_pool()._M_initialize_once(); 
	    __init = true;
	  }
      }

__gthread_once never calls _S_initialize on Solaris 7, 8, 9, while it does on 
Solaris 10.  This boils down to the following lines in the manual:

" These switches are supported in addition to the above on Solaris:

`-threads'
     Add support for multithreading using the Solaris threads library.
     This option sets flags for both the preprocessor and linker.  This
     option does not affect the thread safety of object code produced
     by the compiler or that of libraries supplied with it.

`-pthreads'
     Add support for multithreading using the POSIX threads library.
     This option sets flags for both the preprocessor and linker.  This
     option does not affect the thread safety of object code produced
     by the compiler or that of libraries supplied with it."

You need to pass -pthreads to the compiler to make the thing work.

More:


No, pthread_cancel is defined because it is present in the libc:

gax% nm -pl /lib/libc.so.1 | grep pthread_cancel
0000634812 T* _pthread_cancel
0000634812 T* pthread_cancel
gax% nm -pl /lib/libpthread.so.1 | grep pthread_cancel
0000015516 T  _pthread_cancel
0000015516 T* pthread_cancel

Same for pthread_once:
gax% nm -pl /lib/libc.so.1 | grep pthread_once
0000635324 T* _pthread_once
0000635324 T* pthread_once
gax% nm -pl /lib/libpthread.so.1 | grep pthread_once
0000015476 T  _pthread_once
0000015476 T* pthread_once


But the latter is probably a dummy function because:

Reformatting page.  Please Wait... done

Threads Library Functions                      pthread_once(3THR)

NAME
     pthread_once - initialize dynamic package

[...]

NOTES
     Solaris threads do not offer this functionality.

SunOS 5.8            Last change: 2 Jun 1998                    2


The situation is different on Solaris 10 because all the functions in the 
pthreads library are only placeholders for the libc functions:

hikaru% nm -pl /lib/libpthread.so.1 | grep pthread_cancel
0000000000 T  _pthread_cancel
0000000000 T  pthread_cancel

hikaru% nm -pl /lib/libc.so.1 | grep pthread_cancel
0000703188 T  _pthread_cancel
0000703188 T* pthread_cancel

... thus leading to the odd behavior where __gthread_active_p is true, but
__gthread_once doesn't run the "once" function, and yet returns zero.

It looks like this has been an issue in past versions of the mt_allocator.h
code, in that initialization was forced after the gthread_once call. This was
confusing, but apparently necessary due to the tricky gthread_once issue.

Possible solutions:

1) force double initialization again.
2) add dg-options "-pthread" for solaris on the given testsuite files
3) link libstdc++ builds on solaris with -pthread. Libjava already does this.
See see libjava/configure.ac:759.
4) fix __gthread_active_p on solaris to make it work like other systems.