Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
yeah-boi mannequin opened this issue Jan 7, 2019 · 8 comments
Closed

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

yeah-boi mannequin opened this issue Jan 7, 2019 · 8 comments
Labels
bugzilla Issues migrated from bugzilla clang:diagnostics New/improved warning or error message in Clang, but not in clang-tidy or static analyzer clang:frontend Language frontend issues, e.g. anything involving "Sema" confirmed Verified by a second party duplicate Resolved as duplicate

Comments

@yeah-boi
Copy link
Mannequin

yeah-boi mannequin commented Jan 7, 2019

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.

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 10, 2021
@AaronBallman
Copy link
Collaborator

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 AaronBallman added the confirmed Verified by a second party label May 18, 2022
@AaronBallman
Copy link
Collaborator

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

@EugeneZelenko EugeneZelenko added clang:frontend Language frontend issues, e.g. anything involving "Sema" clang:diagnostics New/improved warning or error message in Clang, but not in clang-tidy or static analyzer and removed clang Clang issues not falling into any other category labels May 18, 2022
@llvmbot
Copy link
Member

llvmbot commented May 18, 2022

@llvm/issue-subscribers-clang-frontend

@Abramo-Bagnara
Copy link
Contributor

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
Copy link
Collaborator

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

@Abramo-Bagnara
Copy link
Contributor

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

@AaronBallman
Copy link
Collaborator

Reopening this issue due to reverting the changes in c745f2c

@AaronBallman
Copy link
Collaborator

This is a duplicate of #39494 because it relates to not implementing DR423.

@AaronBallman AaronBallman closed this as not planned Won't fix, can't repro, duplicate, stale Jun 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugzilla Issues migrated from bugzilla clang:diagnostics New/improved warning or error message in Clang, but not in clang-tidy or static analyzer clang:frontend Language frontend issues, e.g. anything involving "Sema" confirmed Verified by a second party duplicate Resolved as duplicate
Projects
None yet
Development

No branches or pull requests

4 participants