rsmith added a comment.
I mailed WG14 asking for clarification on how these rules are supposed to work
(10 days ago) and am yet to hear anything in response. Is this apparent GCC
extension/bug seeing much use in the wild? If not, I think our path forward is
to file this as a bug against GCC and
d.zobnin.bugzilla added a comment.
Richard, please let me know what in your opinion we should do with this
revision.
Thank you,
Denis Zobnin
http://reviews.llvm.org/D18698
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.o
d.zobnin.bugzilla added a comment.
Richard, thank you for the review and explanation!
I don't have any examples of useful code using this extension, I was trying to
fix the PR... So, do you think we should add this GCC extension to Clang (with
a proper warning, of course) for compatibility reaso
rsmith added a comment.
I'm not convinced this change is correct. There are two possibilities for what
`int *_Atomic restrict` could mean:
1. `_Atomic(int *restrict)`: this seems to be ill-formed by 6.7.2.4/3, because
the type name in an atomic type specifier cannot be a qualified type
2. `_Ato
d.zobnin.bugzilla created this revision.
d.zobnin.bugzilla added a reviewer: rsmith.
d.zobnin.bugzilla added a subscriber: cfe-commits.
Treat _Atomic pointers as pointer types (check value type of AtomicType) in
case of handling the "restrict" qualifier. Accept such code (so does GCC):
int * res
