Accessing qualified member of a structure or union rvalue allows creating qualified rvalues

[Halalaluyafail3]

The following code demonstrates the issue:

struct{
    const int c;
}foo();
puts(_Generic(foo().c,int:"A",const int:"B"));

foo returns a structure that contains a qualified member named c of type const int. Calling foo results in an rvalue structure, which when accessing one of the members via . results in an rvalue. Clang does not remove qualifiers or _Atomic (C23 removes _Atomic from rvalues as well, and GCC does this in earlier versions as well) here while GCC does and the result of DR 423 seems intended to remove cases of qualified rvalues. Additionally, Clang actually generates a warning here with the default warnings stating that the const int branch will never be taken (and then it takes it anyway). The wording doesn't state that the result is the non-atomic (C23) and unqualified member when getting the member though I assume that is a defect.

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: None (Halalaluyafail3)

The following code demonstrates the issue: ```c struct{ const int c; }foo(); puts(_Generic(foo().c,int:"A",const int:"B")); ``` `foo` returns a structure that contains a qualified member named `c` of type `const int`. Calling `foo` results in an rvalue structure, which when accessing one of the members via `.` results in an rvalue. Clang does not remove qualifiers or _Atomic (C23 removes _Atomic from rvalues as well, and GCC does this in earlier versions as well) here while GCC does and the result of DR 423 seems intended to remove cases of qualified rvalues. Additionally, Clang actually generates a warning here with the default warnings stating that the `const int` branch will never be taken (and then it takes it anyway). The wording doesn't state that the result is the non-atomic (C23) and unqualified member when getting the member though I assume that is a defect.

[shafik]

CC @AaronBallman

[AaronBallman]

The return statement in foo() is what determines the value that is returned, and that is an rvalue (C23 6.8.7.5p3) of the unnamed structure type, which is unqualified. So if we're doing anything wrong, I think it has more to do with the . operator. C23 6.5.3.4p3 says:

A postfix expression followed by the . operator and an identifier designates a member of a structure or union object. The value is that of the named member,93) and is an lvalue if the first expression is an lvalue. If the first expression has qualified type, the result has the so-qualified version of the type of the designated member.

So the member named here is not an lvalue because the returned structure object is not an lvalue. However, "if the first expression has qualified type" can be read to apply here and Clang's behavior is correct. I took a look at what other C compilers do and the results are wonderful:

Clang, Chibicc, EDG: do not strip the qualifier
GCC, MSVC, TCC, CompCert: strips the qualifier
SDCC: claims there are multiple matching associations

So I'm going to ask on the WG14 reflectors to see what folks think.

[AaronBallman]

I lied, I didn't need to go ask WG14. _Generic's controlling operand behaves as though lvalue conversion happens and that needs to drop the qualifiers anyway.

[AaronBallman]

I lied again and have asked on WG14 because I think this is a standards wording defect or I'm reading the standard wrong. lvalue conversion only applies to lvalues, so if we do get an rvalue from the member access expression, then the lvalue conversion wouldn't drop qualifiers because no conversion occurs.

https://godbolt.org/z/W64hxa4jj shows the compiler divergence for this.

[Halalaluyafail3]

Interestingly, it seems that all compilers agree that with an array member qualifiers should not be removed in this situation (after decay it is no longer a qualified rvalue, but it being a qualified rvalue can still be observed with typeof). Also, I have discovered that GCC does not remove qualifiers from the result of . with an rvalue left operand in situations where lvalue conversions do not apply. That is, using the example typeof(foo().c) is the type const int but typeof(0,foo().c) is the type int. I'm thinking about making a bug report to GCC for that since it seems strange for an rvalue to undergo lvalue conversions.

[AaronBallman]

Committee discussion on the WG14 reflectors suggests a few things: 1) qualified rvalues are a thing in C and that was a benign thing largely because qualifiers were never observable until _Generic, but now means we need more clarity in the standard; 2) _Generic should still strip those qualifiers even if it gets an rvalue. (So the typeof behavior observing the qualifiers on the rvalue is correct.)