public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/114210] New: Potential bug wrt __restrict on member function decl/def
@ 2024-03-02 17:41 rl.alt.accnt at gmail dot com
2024-03-31 0:08 ` [Bug c++/114210] " pinskia at gcc dot gnu.org
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: rl.alt.accnt at gmail dot com @ 2024-03-02 17:41 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug c++/114210] Potential bug wrt __restrict on member function decl/def
2024-03-02 17:41 [Bug c++/114210] New: Potential bug wrt __restrict on member function decl/def rl.alt.accnt at gmail dot com
@ 2024-03-31 0:08 ` pinskia at gcc dot gnu.org
2024-03-31 0:18 ` pinskia at gcc dot gnu.org
2024-03-31 0:25 ` rl.alt.accnt at gmail dot com
2 siblings, 0 replies; 4+ messages in thread
From: pinskia at gcc dot gnu.org @ 2024-03-31 0:08 UTC (permalink / raw)
To: gcc-bugs
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));
}
```
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug c++/114210] Potential bug wrt __restrict on member function decl/def
2024-03-02 17:41 [Bug c++/114210] New: Potential bug wrt __restrict on member function decl/def rl.alt.accnt at gmail dot com
2024-03-31 0:08 ` [Bug c++/114210] " pinskia at gcc dot gnu.org
@ 2024-03-31 0:18 ` pinskia at gcc dot gnu.org
2024-03-31 0:25 ` rl.alt.accnt at gmail dot com
2 siblings, 0 replies; 4+ messages in thread
From: pinskia at gcc dot gnu.org @ 2024-03-31 0:18 UTC (permalink / raw)
To: gcc-bugs
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
}
```
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug c++/114210] Potential bug wrt __restrict on member function decl/def
2024-03-02 17:41 [Bug c++/114210] New: Potential bug wrt __restrict on member function decl/def rl.alt.accnt at gmail dot com
2024-03-31 0:08 ` [Bug c++/114210] " pinskia at gcc dot gnu.org
2024-03-31 0:18 ` pinskia at gcc dot gnu.org
@ 2024-03-31 0:25 ` rl.alt.accnt at gmail dot com
2 siblings, 0 replies; 4+ messages in thread
From: rl.alt.accnt at gmail dot com @ 2024-03-31 0:25 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2024-03-31 0:25 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-03-02 17:41 [Bug c++/114210] New: Potential bug wrt __restrict on member function decl/def rl.alt.accnt at gmail dot com
2024-03-31 0:08 ` [Bug c++/114210] " pinskia at gcc dot gnu.org
2024-03-31 0:18 ` pinskia at gcc dot gnu.org
2024-03-31 0:25 ` rl.alt.accnt at gmail dot com
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).