https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118854
--- Comment #9 from Jonathan Wakely <redi at gcc dot gnu.org> --- (In reply to Andrew Pinski from comment #6) > Libc++ is NOT a variation or fork of libstc++ but it's own implementation > and unrelated to libstdc++. If you hit there too, 99% chances were it is a > bug in your code. It's unclear if he's using -stdlib=libc++ or -stdlib=libstdc++ so it might be using libstdc++ after all, even with Clang. (In reply to Andrew Pinski from comment #5) > One way of fixing this is to move _pInstance to be a static variable inside > instance function which makes the initialization dynamic and correctly > ordered. Are you sure? pInstance would still be constructed after gBackgroundThread, which means it would be destroyed before it, and so the pInstance destructor would still run potentially concurrently with accesses to pInstance, which means a data race which means undefined behaviour. The fix is to join the background thread before pInstance is destroyed, which can be done by ensuring that pInstance is constructed *before* gBackgroundThread, so that it's not destroyed until *after* gBackgroundThread.
