[PATCH] D122656: [C11] Improve the diagnostic when accessing a member of an atomic struct

Erich Keane via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Tue Mar 29 08:22:27 PDT 2022


erichkeane accepted this revision.
erichkeane added inline comments.
This revision is now accepted and ready to land.


================
Comment at: clang/lib/Sema/SemaExprMember.cpp:1300
+  // warning defaults to an error.
+  if (const auto *ATy = BaseType->getAs<AtomicType>()) {
+    S.Diag(OpLoc, diag::warn_atomic_member_access);
----------------
aaron.ballman wrote:
> erichkeane wrote:
> > This seems to apply to both C and C++.  I guess "_Atomic" is C only, so we get to define its behavior for C++?
> > 
> > What does GCC do in C++ mode?
> Clang supports `_Atomic` in C++ as an extension (with the C semantics), GCC does not.
> 
> However, after doing some testing, I actually question whether Clang supports `_Atomic` in C++ more or just "pretends everything will work out fine in C++ mode but nobody ever actually checked that". I'm not going to add additional test coverage for this because I'm going to see just how many issues I spot in C++ first (it may be a better approach to disable the extension in C++).
Based on the examples I've seen, I think we're better off matching GCC's behavior here of disallowing _Atomic in both forms in C++, unless it is necessary/used to implement the std::atomic version in libc++ (obviously it isn't in libstdc++ if they disable it in c++ mode?).


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D122656/new/

https://reviews.llvm.org/D122656



More information about the cfe-commits mailing list