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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
