Re: Counter-PATCH (libstdc++-v3, mainline) for: std::_Atomic_swap for i386

[Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>]

In article <je7k941ds1.fsf@sykes.suse.de>,
Andreas Schwab<schwab@suse.de> writes:

> Loren James Rittle <rittle@latour.rsch.comm.mot.com> writes:
> |> Index: include/ext/stl_rope.h

> Breaks bootstrap on [almost every or every] linux [and solaris].
> You can't use __GTHREAD_MUTEX_INIT like this, it is only usable as a
> static initializer.

Thanks for the heads up (Michael, Matt, Roger, Andreas, Wolfgang,
Nathan and Benjamin; anyone else on the list that didn't CC me but
that I haven't seen yet); a real fix was installed for this issue.  I
hang my head in shame, the mutex mapping stuff is an area of gcc that
I know very well.  Ah, the evils of unknown junk in a free-format C
macro while in C++ thinking mode (yes, I knew that some system's mutex
implementation used braced initializers)...

Regarding Nathan's comment on the libstdc++ list and Andreas quoted
text above: I know of no system which defines __GTHREAD_MUTEX_INIT
which may not in fact use the idiom below (sorry, it took 3 tries to
get it right; obviously C++ initializers don't allow the full range of
options of the C style).  The key is that a certain bit pattern must
get into memory and that once a mutex has been seen by the system it
is no longer legal to copy.  Before it is seen by the system, the bits
obtained from the (e.g.) PTHREAD_MUTEX_INIT may be so copied.

Regards,
Loren

As installed and credited to Matt Kraai:

Index: libstdc++-v3/include/ext/stl_rope.h
===================================================================
RCS file: /cvs/gcc/gcc/libstdc++-v3/include/ext/stl_rope.h,v
retrieving revision 1.21
diff -r1.21 stl_rope.h
503c503,507
<     { _M_c_string_lock = __GTHREAD_MUTEX_INIT; }
---
>     {
>       // Do not copy a POSIX/gthr mutex once in use.  However, bits are bits.
>       __gthread_mutex_t __tmp = __GTHREAD_MUTEX_INIT;
>       _M_c_string_lock = __tmp;
>     }