[libcxx-commits] [libcxx] [libc++][Android] Always redirect <stdatomic.h> to <atomic> (PR #143036)
Nick Desaulniers via libcxx-commits
libcxx-commits at lists.llvm.org
Wed May 6 09:17:36 PDT 2026
nickdesaulniers wrote:
We discussed this more at the May 6th instance of Clang's C & C++ Language Working Group ([Notes](https://docs.google.com/document/d/1x5-RbOC6-jnI_NcJ9Dp4pSmGhhNe7lUevuWUIB46TeM/edit?tab=t.0).
There were a few comments about resolving ABI concerns and possibly getting something updated in the Itanium ABI or processor specific ABI docs, but that seemed less pressing here. The concerns were around whether a function signature had a pointer/ref to an `_Atomic`, would it get mangled appropriately wrt. the extension.
There was some discussion about pulling out a new named diagnostic for the usage of `_Atomic` in C++ modes pre C++23 from [-Wc11-diagnostics](https://godbolt.org/z/WPKMaWzv3) _and then enabling it by default in clang_. Even if we had this, from an Android perspective, I think then we would simply _turn that off_, at least in the near term if would be possible to work through fixing up sources.
There was a discussion that perhaps a pattern that could be used for folks that want to be able to use `_Atomic` in C++ modes pre C++23 with libc++, that they could `#define` a macro _BEFORE_ inclusion of <atomic>, and otherwise libc++ would warn (@philnik777 correct me if my understanding of the pattern proposed in imprecise; @philnik777 mentioned libc++ had prior art in this area related to `nodiscard`(?)) . I suspect then on the Android side we could ensure we define that in our sources where necessary.
The next libc++ meeting is May 12; the next Clang C/C++ WG meeting is May 20. So we can discuss the above at the next libc++ meeting and circle back with the Clang WG with any feedback.
https://github.com/llvm/llvm-project/pull/143036
More information about the libcxx-commits
mailing list