gcc4 and local statics

Christopher Faylor cgf-no-personal-reply-please@cygwin.com
Wed May 18 19:48:00 GMT 2005

On Wed, May 18, 2005 at 11:51:55AM -0700, Brian Dessent wrote:
>Corinna Vinschen wrote:
>> While this might help to avoid... something, I'm seriously wondering
>> what's wrong with this expression.  Why does each new version of gcc
>> add new incompatibilities?
>I think I've figured this out.  PR/13684 added thread safety to
>initialization of local statics.[1]  It does this by wrapping the call
>to the contructor around __cxa_guard_acquire and __cxa_guard_release,
>which are supposed to prevent two threads from both calling the
>constructor at the same time.
>The problem is that in Cygwin, these functions are defined as no-ops in
>cxx.cc.  That means that GCC calls the function and expects a nonzero
>return value if it was able to acquire the mutex, but in our case the
>function always returns zero (or rather, it does nothing and eax
>contained zero before the function call) and so gcc never tries to call
>the constructor.
>There seem to be several possible ways to go here:
>1. Compile with -fno-threadsafe-statics.
>2. Implement an actual muto in __cxa_guard_*.
>3. Remove Cygwin's no-op __cxa_guard_* and rely on the libstdc++
>provided ones.
>4. Move the variable to file/global scope.
>This recently came up on an Apple list[2], apparently in the context of
>a vendor trying to compile their kernel driver against Tiger using
>gcc4.  It looks like they're going with either #4 or #1.
>I tested #1 and it indeed cures the failing mmap testsuites.
>For Cygwin's purposes it seems that we need to decide if two threads
>could ever potentially call this function at the same time.  If so, then
>#1 is out.  Correct me if I'm wrong but Cygwin does not use anything
>from libstdc++ so #3 is out as well.  In this particular case of
>'granularity' it seems rather trivial to spend much time implementing
>actual locking.  But then you have to determine if there are any other
>local statics that will be suffering from the same fate, and if so then
>#2 starts to become reasonable, otherwise I'd say #4.

Now that we know what's causing this, I guess I'd have to say that 4.
is the way to go.  The expense of a mutex for this case doesn't seem
worth it.


More information about the Cygwin-developers mailing list