================
@@ -78,7 +78,13 @@ namespace {
// the qualifier.
if (!S.Context.getLangOpts().ObjC && !DestType->isRecordType() &&
!DestType->isArrayType() && !DestType.getPointerAuth()) {
- DestType = DestType.getAtomicUnqualifiedType();
+ if (S.Context.getLangOpts().CPlusPlus) {
+ // Note that in C++, _Atomic(T) is a distinct type, not a
+ // cv-qualifier, so it is not stripped.
+ DestType = DestType.getUnqualifiedType();
+ } else {
+ DestType = DestType.getAtomicUnqualifiedType();
+ }
----------------
AaronBallman wrote:
`_Atomic` isn't in C++, so the C++ standard doesn't mandate anything here. (For
example, we intentionally don't strip qualifications for ptrauth types either;
extensions get to deviate from the standard but `_Atomic` is a bit of a special
case because it is covered by the C standard.)
My question was more prosaic though -- if we're incorrectly stripping the
atomic qualification here today but managing to get the expected diagnostic
about atomics, something elsewhere likely also needs to be adjusted because
something was picking the atomic qualification back up. So I was looking for
more details about what's going on there in the compiler.
It turns out that we're incorrect in C too: https://godbolt.org/z/rP8dn9a5M
because `typeof` should be giving you the type with all qualifications, but the
atomic qualifier was supposed to be dropped by the cast; this could be related
to whatever is picking those qualifications back up in C++ mode.
https://github.com/llvm/llvm-project/pull/207616
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
