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. Brian [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13684 [2] http://lists.apple.com/archives/darwin-drivers/2005/May/msg00066.html