aaron.ballman added a comment. In D125919#3554599 <https://reviews.llvm.org/D125919#3554599>, @rjmccall wrote:
> Ah, true, the standard doesn't describe it as a normal qualifier. From the > DR, it sounds like the committee certainly expected that this reasoning would > also apply to `_Atomic`, even if that's not quite what they've written, but > that the DR submitter seems to not want that behavior. Have you been able to > track down the solicited paper mentioned in that DR? In the absence of > further indication, I think dropping `_Atomic` like anything else is the > right thing to do; like the other qualifiers, it isn't meaningful for > r-values. I think it's less clear to me that the committee expected to drop `_Atomic` because the standard basically makes `_Atomic` introduce a new type rather than a qualified use like `const`; it's more akin to `_Complex` in that regard. e.g., it's not clear to me that these are redeclarations: int func(void); _Atomic(int) func(void); When I survey non-Clang C compilers which support `_Atomic`, it's evenly split between thinking these are valid redeclarations or not (GCC and ICC say they're not valid redeclarations, ICC and TCC say they are) but when I use `const int` and `int` as the return types, only ICC claims they're incompatible types. Further, this seems like a gratuitous incompatibility with C++ where the qualifiers are *not* dropped, given that function call expressions explicitly drop the qualifiers anyway. (So you're right, they are effectively useless on the return type, but why should C and C++ differ in what's a valid redeclaration?) Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D125919/new/ https://reviews.llvm.org/D125919 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
