clang doesn't drop the top level `_Atomic` qualifier when inferring an `__auto_type` from an initializer

[ahatanak]

When the following code is compiled, the type of b is _Atomic int instead of int:

$ cat test.c

_Atomic int a;
int g;

void test() {
   __auto_type b = a;
   g = b;
}

$ clang -S -o - -emit-llvm test.c

define void @test() #0 {
entry:
  %b = alloca i32, align 4
  %atomic-load = load atomic i32, ptr @a seq_cst, align 4
  store i32 %atomic-load, ptr %b, align 4
  %atomic-load1 = load atomic i32, ptr %b seq_cst, align 4
  store i32 %atomic-load1, ptr @g, align 4
  ret void
}

This seems to differ from gcc's behavior if I understand its output in https://godbolt.org correctly. gcc drops _Atomic just like it drops const when it infers the type of d in the following code:

$ cat test.c

const int c = 100;

void test() {
    __auto_type d = c;
    d = 123;
}

[llvmbot]

@llvm/issue-subscribers-clang-frontend

[ahatanak]

@AaronBallman @zygoloid should clang drop qualifiers like _Atomic or _Nonnull if they are at the top level?

[ahatanak]

Is there a reason to treat top level _Atomic or _Nonnull differently than cv qualifiers in this case?

[shafik]

May be related to: #60171

[ahatanak]

Yes, it looks like it's related.

According to the following paper, the inferred type of __auto_type is typeof((0, init)) where init is the initializer expression.

https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3007.htm

Also, if I understand the standard correctly, it says:

1. Comma operator doesn't yield an lvalue.
2. After conversion, if an lvalue has atomic type, the value has the non-atomic version of the type of the lvalue.

https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2310.pdf

Based on these facts, it seems to me that the inferred type of b should be int in the above code.

[AaronBallman]

Agreed;

C23 6.5.16p3 says (in part): The type of an assignment expression is the type the left operand would have after lvalue conversion.

C23 6.7.10p12 says (in part): If the initializer is not the empty initializer, the initial value of the object is that of the expression (after conversion); the same type constraints and conversions as for simple assignment apply, taking the type of the scalar to be the unqualified version of its declared type.

C23 6.3.2.1p2 says (in part): If the lvalue has qualified type, the value has the unqualified version of the type of the lvalue; additionally, if the lvalue has atomic type, the value has the non-atomic version of the type of the lvalue; otherwise, the value has the type of the lvalue.

So the assignment expression strips all the qualifiers including _Atomic, so __auto_type doesn't have the opportunity to see the qualifier on the type to begin with.

[ldionne]

I want to point out that this makes C and C++ really inconsistent: https://godbolt.org/z/vf68jn7b1

In C++:

#include <stdatomic.h>

int main() {
    auto x = _Atomic(int)(3);
    // x is _Atomic(int)

    _Atomic(int) i = 3;
    auto j = i; // invalid, would try to copy-initialize an _Atomic(int),
                // but _Atomic(int) is std::atomic<int>, which is not copyable
}

In C:

#include <stdatomic.h>

int main() {
    _Atomic(int) i = 3;
    __auto_type x = i; // x is int, deduction dropped the qualifier.

    _Atomic(int) j = i; // also for some reason this is allowed, I'm not sure what the semantics are
}

I know there were numerous attempts to fix the state of interoperation of atomics in C and C++ -- would it be worth taking this to the C committee? The inconsistencies definitely seem at least a bit messed up.

[AaronBallman]

I want to point out that this makes C and C++ really inconsistent: https://godbolt.org/z/vf68jn7b1

Yeah, atomics in C are a mess IMO.

I know there were numerous attempts to fix the state of interoperation of atomics in C and C++ -- would it be worth taking this to the C committee? The inconsistencies definitely seem at least a bit messed up.

Absolutely worth it, but the trouble is two-fold: we know we've got atomic issues to fix both in terms of semantic functionality and in terms of specification (atomic qualifiers are specified in about the worst way I can imagine in C), and we've heard that SG1 is going to help unify the model between C and C++ (basically, closing the loop as we've been expecting since 2011). I think WG14 doesn't want to take a shot at fixing too many atomic things without coordinating with SG1, as that risks even more interesting divergences.

It would be super handy if we could somehow leverage SG22 into helping coordinate between WG14 and SG1, but I've not heard if we've gotten a new chair since I stepped down. I'll poke Herb to see what's going on there.