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?
