[Bug libstdc++/36801] New: config/cpu/generic/atomicity_mutex/atomicity.h incorrectly relies on global constructor ordering

[jifl-bugzilla at jifvik dot org]

In 4.3.1 (and 4.2.x and the trunk), ARM targets and no doubt plenty others use
libstdc++/config/cpu/generic/atomicity_mutex/atomicity.h.

With some build magic in libstdc++/src/Makefile.am, this file is also
atomicity.cc when building the library. Thus this object gets instantiated:
{
  __gnu_cxx::__mutex atomic_mutex;
} // anonymous namespace

The constructor for __mutex in include/ext/concurrence.h has a private member
of the underlying __gthread_mutex_t, and its constructor uses
GTHREAD_MUTEX_INIT or calls GTHREAD_MUTEX_INIT_FUNCTION as appropriate, as of
course it should.

The problem is that this becomes a global constructor and there is no control
over where in the running of global constructors it gets run. A consequence of
this is that any other initialisation function from another constructor using
atomic operations can end up locking a mutex which has never been initialised,
with unsurprising results. An example of such a case is ios_base::Init::Init()
which calls __gnu_cxx::__exchange_and_add_dispatch() which eventually reaches
__gnu_cxx::__scoped_lock sentry(atomic_mutex); which attempts to lock
atomic_mutex.

Code prior to this implementation used __gthread_mutex_t in atomicity.h
directly  using a macro defined by concurrence.h:
  __glibcxx_mutex_define_initialized(atomic_mutex);
and as such this used to work, so this is a regression.

It seems this is an unintended consequence of this change:
http://gcc.gnu.org/ml/libstdc++/2006-09/msg00084.html

I think this needs returning to something similar to the way it was before, so
that the __gthread_mutex_t was created in the atomic_mutex's own constructor.


-- 
           Summary: config/cpu/generic/atomicity_mutex/atomicity.h
                    incorrectly relies on global constructor ordering
           Product: gcc
           Version: 4.3.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: jifl-bugzilla at jifvik dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: arm-eabi


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36801