On Aug 15, 2013, at 4:59 PM, Reid Kleckner <[email protected]> wrote: > Static locals requiring initialization are not thread safe on Windows. > Unfortunately, it's possible to create static locals that are actually > externally visible with inline functions and templates. As a result, we > have to implement an initialization guard scheme that is compatible with > TUs built by MSVC, which makes thread safety prohibitively difficult. > > MSVC's scheme is that every function that requires a guard gets an i32 > bitfield. Each static local is assigned a bit that indicates if it has > been initialized, up to 32 bits, at which point a new bitfield is > created. MSVC rejects inline functions with more than 32 static locals, > and the externally visible mangling (?_B) only allows for one guard > variable per function.
Hilarious. Itanium has a similar concept of function-specific mangling state tracked with startNewFunction() on the mangle context; you should try to unify the two. You should also figure out whether the same things that cause a new context to be suppressed should apply here. It would be nice to let the FunctionState be lazily initialized. Otherwise looks good. John. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
