c11: _Atomic not removed from rvalue in controlling expression of _Generic.

[yeah-boi]

Bugzilla Link	40248
Version	trunk
OS	All
CC	@hfinkel,@zygoloid

Extended Description

Test case (prog.c):

_Atomic int f();

int main()
{
_Generic(f(), int: 0);
}

Compilation command line:

clang prog.c -Wall -Wextra -std=c11 -pedantic-errors

Observed behaviour:

The following error message was outputed:

 error: controlling expression type '_Atomic(int)' not compatible with any
        generic association type

Expected behaviour:

No error message.

The program is well-formed.

See 6.5.1.1/2:

"The type of the controlling expression is the type of the expression as if it
had undergone an lvalue conversion, array to pointer conversion, or function
to pointer conversion"

and 6.3.2/2:

"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."

Note:

GCC accepts the program without outputing any error message.

[AaronBallman]

The cited sections of the standard are relevant but don't actually point out where we've gone wrong (we properly implement those paragraphs as far as I can see). The issue is that we don't implement all of the changes in WG14 DR 423; critically we seem to miss the changes to 6.7.6.3p4, which cause the declaration of the function to drop the qualifiers. You can see this in an AST dump:

_Atomic int f();
const int g();

yields:

FunctionDecl <line:1:1, col:15> col:13 f '_Atomic(int) ()'
FunctionDecl <line:2:1, col:13> col:11 g 'const int ()'

The signature for those functions should not have the qualifiers in C (but should retain them in C++). Once we resolve that issue, this code should begin to work properly.

[AaronBallman]

I made https://reviews.llvm.org/D125919 to address this.

[llvmbot]

@llvm/issue-subscribers-clang-frontend

[Abramo-Bagnara]

Doing that you have unexpectedly compromised source code fidelity of the AST as the presence of qualifiers in return type is lost also in TypeSourceInfo.
This does not happen in similar handling of qualified cast type, as it is expected.
@AaronBallman, should I open a new issue for that?

[AaronBallman]

Hmm, yes, I think that is worth a new issue. Good catch, @Abramo-Bagnara!

[Abramo-Bagnara]

Thanks @AaronBallman. I've just filed issue #55778.

[AaronBallman]

Reopening this issue due to reverting the changes in c745f2c