[Bug c++/114210] New: Potential bug wrt __restrict on member function decl/def

[Bug c++/114210] New: Potential bug wrt __restrict on member function decl/def

[rl.alt.accnt at gmail dot com]

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?

[Bug c++/114210] Potential bug wrt __restrict on member function decl/def

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114210

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Note the class method is similar to how normal functions work:

```
void
foo (int* __restrict b);
void
foo (int*  b)
{
         static_assert(__is_same(decltype(b), int*));
}
void
foo1 (int*  b);
void
foo1 (int* __restrict b)
{
         static_assert(__is_same(decltype(b), int*__restrict));
}
```

[Bug c++/114210] Potential bug wrt __restrict on member function decl/def

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114210

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Exactly like the following standard C23 code:
```
void nonrestirct();
void restirctcall();
void
foo (int* a, int* __restrict b, int n);
void
foo (int* a, int*  b, int n)
{
        typeof(b) c = b;
        _Generic (&c ,
          int * __restrict*: restirctcall(),
          int **: nonrestirct()
        ); // calls nonrestirct
}
void
foo1 (int* a, int*  b, int n);
void
foo1 (int* a, int* __restrict b, int n)
{
        typeof(b) c = b;
        _Generic (&c ,
          int * __restrict*: restirctcall(),
          int **: nonrestirct()
        ); // calls restirctcall
}

```

[Bug c++/114210] Potential bug wrt __restrict on member function decl/def

[rl.alt.accnt at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114210

--- Comment #3 from Sirraide <rl.alt.accnt at gmail dot com> ---
Ah, that makes sense: it’s basically treated like any other top-level
cv-qualifier on a function parameter—it’s just that it happens to syntactically
be in an unusual place compared to cv-qualifiers on regular function
parameters. Thanks for clarifying this.