From 30c675400f56e6d4636e8f8f2b347655581613da Mon Sep 17 00:00:00 2001 From: Boris Kolpackov Date: Wed, 11 May 2022 10:25:47 +0200 Subject: Restrict to only using __thread with own C++14 threads implementation --- libbutl/buildfile | 5 +++++ libbutl/ft/lang.hxx | 9 +++++++-- 2 files changed, 12 insertions(+), 2 deletions(-) diff --git a/libbutl/buildfile b/libbutl/buildfile index 499800c..a7b20f3 100644 --- a/libbutl/buildfile +++ b/libbutl/buildfile @@ -16,6 +16,11 @@ windows = ($tclass == 'windows') # Whether to use our own implementation of C++14 threads on MinGW (note: # requires Windows 7 or later). # +# Note that for now we use built-in POSIX thread support during bootstrap +# (which, as a side effect, verifies we still use MinGW GCC configured with +# POSIX support, which we still need for TLS, exceptions, and thread-safe +# static locals). +# mingw_stdthread = ($tsys == 'mingw32') # Exclude these from compilation on targets where does not apply. diff --git a/libbutl/ft/lang.hxx b/libbutl/ft/lang.hxx index 567f5a4..82971d2 100644 --- a/libbutl/ft/lang.hxx +++ b/libbutl/ft/lang.hxx @@ -7,9 +7,14 @@ // __cpp_thread_local (extension) // // If this macro is undefined then one may choose to fallback to __thread. -// Note, however, that it only for values that do not require dynamic +// Note, however, that it only works for values that do not require dynamic // (runtime) initialization. // +// Note that thread_local with dynamic allocation/destruction appears to be +// broken when we use our own implementation of C++14 threads on MinGW. So +// we restrict ourselves to __thread which appears to be functioning, at +// least in the POSIX threads GCC configuration. +// #ifndef __cpp_thread_local // // Apparently Apple's Clang "temporarily disabled" C++11 thread_local until @@ -20,7 +25,7 @@ # if __apple_build_version__ >= 8000000 # define __cpp_thread_local 201103 # endif -# else +# elif !defined(LIBBUTL_MINGW_STDTHREAD) # define __cpp_thread_local 201103 # endif #endif -- cgit v1.1