16.8 [cpp.predefined] in C++11 says: __STDCPP_THREADS__ Defined, and has the value integer constant 1, if and only if a program can have more than one thread of execution (1.10). I'm not sure what the best way to meet that requirement is, given that . For some platforms we could make -pthread imply -D__STDCPP_THREADS__, or maybe we just want to define it unconditionally in every gthr-xxx.h header except gthr-single.h
(In reply to Jonathan Wakely from comment #0) > I'm not sure what the best way to meet that requirement is, given that . Oops, I was going to say "... given that the availability of threads may not be known until link-time, depending whether libpthread is used.
*** Bug 92138 has been marked as a duplicate of this bug. ***
I tried to implement this by adding a macro definition to c_cpp_builtins in gcc/c-family/c-cppbuiltin.c but failed. I think we want to inspect the 'thread_model' global variable and see if it is "single", but that might only be available to the driver, not cc1plus. Maybe the driver needs to check THREAD_MODEL_SPEC and thread_model and then pass -D__STDCPP_THREADS__=1 to cc1plus when strcmp(thread_model, "single"). For now, I think we can define it in libstdc++'s <bits/c++config.h> based on the value of the _GLIBCXX_HAS_GTHREADS macro.
Library patch: diff --git a/libgcc/gthr.h b/libgcc/gthr.h index f31cf083cbe5..e6462679b362 100644 --- a/libgcc/gthr.h +++ b/libgcc/gthr.h @@ -147,6 +147,13 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If not, see #endif #include "gthr-default.h" +#if defined __GTHREADS_CXX0X && ! defined __STDCPP_THREADS__ +// The C++ standard says that __STDCPP_THREADS__ should be defined to 1, +// but G++ does not currently do that (PR c++/63287). +// Define it here if gthr-default.h defined __GTHREADS_CXX0X. +# define __STDCPP_THREADS__ 1 +#endif + #ifndef HIDE_EXPORTS #pragma GCC visibility pop #endif diff --git a/libstdc++-v3/include/Makefile.am b/libstdc++-v3/include/Makefile.am index 292d89da8ba7..74e3e4932579 100644 --- a/libstdc++-v3/include/Makefile.am +++ b/libstdc++-v3/include/Makefile.am @@ -1316,6 +1316,7 @@ uppercase = [ABCDEFGHIJKLMNOPQRSTUVWXYZ_] ${host_builddir}/gthr.h: ${toplevel_srcdir}/libgcc/gthr.h stamp-${host_alias} sed -e '/^#pragma/b' \ + -e '/__STDCPP_THREADS__/b' \ -e '/^#/s/\(${uppercase}${uppercase}*\)/_GLIBCXX_\1/g' \ -e 's/_GLIBCXX_SUPPORTS_WEAK/__GXX_WEAK__/g' \ -e 's/_GLIBCXX___MINGW32_GLIBCXX___/__MINGW32__/g' \
FWIW libc++ does it in the library: #if !defined(_LIBCPP_HAS_NO_THREADS) && !defined(__STDCPP_THREADS__) #define __STDCPP_THREADS__ 1 #endif
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>: https://gcc.gnu.org/g:1d9a8675d379f02f5e39639f469ae8dfcf33fea9 commit r11-5017-g1d9a8675d379f02f5e39639f469ae8dfcf33fea9 Author: Jakub Jelinek <jakub@redhat.com> Date: Fri Nov 13 23:23:33 2020 +0100 c++: Predefine __STDCPP_THREADS__ in the compiler if thread model is not single [PR63287] The following patch predefines __STDCPP_THREADS__ macro to 1 if c++11 or later and thread model (e.g. printed by gcc -v) is not single. There are two targets not handled by this patch, those that define THREAD_MODEL_SPEC. In one case - QNX - it looks just like a mistake to me, instead of setting thread_model=posix in config.gcc it uses THREAD_MODEL_SPEC macro to set it unconditionally to posix. The other is hpux10, which uses -threads option to decide if threads are enabled or not, but that option isn't really passed to the compiler. I think that is something that really should be solved in config/pa/ instead, e.g. in the config/xxx/xxx-c.c targets usually set their own predefined macros and it could handle this, and either pass the option also to the compiler, or say predefine __STDCPP_THREADS__ if _DCE_THREADS macro is defined already (or -D_DCE_THREADS found on the command line), or whatever else. 2020-11-13 Jakub Jelinek <jakub@redhat.com> PR c++/63287 * c-cppbuiltin.c: Include configargs.h. (c_cpp_builtins): For C++11 and later if THREAD_MODEL_SPEC is not defined, predefine __STDCPP_THREADS__ to 1 unless thread_model is "single".
Late comment: according to [intro.multithread.general] it is a requirement for hosted implementations to support more than one thread of execution, but implementation defined for a free-standing implementation. I am not sure if that has a bearing on the affected platforms.