I was asked about this privately. I don't really like that it would ever be needed, but it also seems fairly harmless. We already do similar things for some of the libstdc++ versions of <stdlib.h> etc.
Any objections? Tested x86_64-linux. -- >8 -- This shouldn't be needed, but apparently the Bazel build tool has a misfeature where it uses -nostdinc and explicitly provides the system include paths, and it uses the same set of paths for compiling C and C++ code. This means that the libstdc++ header paths get used when compiling C code, and so our new <stdatomic.h> gets included. Just forward to the C header using #include_next if that happens. libstdc++-v3/ChangeLog: * include/c_compatibility/stdatomic.h: Use #include_next if included by C code. --- libstdc++-v3/include/c_compatibility/stdatomic.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libstdc++-v3/include/c_compatibility/stdatomic.h b/libstdc++-v3/include/c_compatibility/stdatomic.h index a51a84c2054..aa7bbb923dc 100644 --- a/libstdc++-v3/include/c_compatibility/stdatomic.h +++ b/libstdc++-v3/include/c_compatibility/stdatomic.h @@ -124,7 +124,7 @@ using std::atomic_flag_clear_explicit; using std::atomic_thread_fence; using std::atomic_signal_fence; -#elif defined __clang__ +#elif !defined __cplusplus || defined __clang__ # include_next <stdatomic.h> #endif // C++23 #endif // _GLIBCXX_STDATOMIC_H -- 2.39.0