https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114210
Bug ID: 114210 Summary: Potential bug wrt __restrict on member function decl/def Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: rl.alt.accnt at gmail dot com Target Milestone: --- Clang dev here; I’m currently working on improving our support for `__restrict` in the cv-qualifier-seq of member functions, and I have a question about the following situation: struct S { void a() __restrict; void b(); }; void S::a() { static_assert(__is_same(decltype(this), S*)); } void S::b() __restrict { static_assert(__is_same(decltype(this), S* __restrict)); } `decltype(this)` is `S* __restrict` in the body of `S::b`, but `S*` (no `__restrict`) in the body of `S::a`, i.e. GCC only seems to care about `__restrict` being present in the definition, not the declaration. According to the documentation (https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Restricted-Pointers.html), ‘you only need to specify __restrict__ in a function definition, rather than in a function prototype as well.’ This doesn’t really say anything about what happens if the opposite is the case (i.e. if `__restrict` is only present in the declaration, not the definition). My question, then: is this intended, or is it a bug?