From: Alejandro Colomar via Libc-alpha <libc-alpha@sourceware.org>
To: Joseph Myers <joseph@codesourcery.com>
Cc: Mike Frysinger <vapier@gentoo.org>,
"Seija K." <doremylover123@gmail.com>,
libc-alpha@sourceware.org
Subject: Re: Add restrict annotations to all functions that require it
Date: Wed, 7 Dec 2022 12:59:23 +0100 [thread overview]
Message-ID: <5ea5826c-e47c-2b4f-3699-4d6232b89332@gmail.com> (raw)
In-Reply-To: <7f169d-e67d-ab82-e77f-a6f78a301495@codesourcery.com>
[-- Attachment #1.1: Type: text/plain, Size: 1997 bytes --]
Hi Joseph!
On 12/7/22 00:57, Joseph Myers wrote:
> On Sat, 3 Dec 2022, Alejandro Colomar via Libc-alpha wrote:
>
>> For example, this would be nonsense (and I honestly don't know what the
>> compiler would understand from it):
>>
>> void broken(int *restrict a, int *b, int *c);
>> void broken(int *a, int *restrict b, int *c);
>
> Qualifiers on parameters in a function declarator that is not part of a
> definition of that function have no semantic effect; restrict on function
> parameters only has a semantic effect in the definition of the function.
>
Having restrict in the prototype may not change the semantics, but it is
meaningful to the warnings:
$ cat restrict.c
void broken(int *restrict a, int *b, int *c);
void broken(int *a, int *restrict b, int *c);
void f(int *restrict p, int *restrict q, int *restrict r)
{
broken(p, p, q);
broken(p, q, p);
broken(p, q, r);
}
$ cc -Wall -Wextra -S restrict.c
restrict.c: In function ‘f’:
restrict.c:6:9: warning: passing argument 1 to ‘restrict’-qualified parameter
aliases with argument 2 [-Wrestrict]
6 | broken(p, p, q);
| ^~~~~~
restrict.c:7:9: warning: passing argument 1 to ‘restrict’-qualified parameter
aliases with argument 3 [-Wrestrict]
7 | broken(p, q, p);
| ^~~~~~
By not having semantic effect you mean that the compiler (optimizer) won't take
advantage of those if the prototype with restrict is seen in the translation
unit where the function definition is compiled, given that the function
definition doesn't specify restrict?
Whatever is the semantic result, I believe GCC should have a warning for
mismatching restrict qualifiers. The above doubt is reasonable, and a warning
would help make sure that it's not relevant, because code should't do that
normally, and with the help of the warning, that can be enforced.
Cheers,
Alex
--
<http://www.alejandro-colomar.es/>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2022-12-07 12:00 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-27 0:56 Add restrict annotations to all functions that require it Seija K. via Libc-alpha
2022-11-27 11:44 ` Mike Frysinger via Libc-alpha
2022-11-27 12:00 ` Alejandro Colomar via Libc-alpha
2022-12-03 14:32 ` Alejandro Colomar via Libc-alpha
2022-12-06 23:57 ` Joseph Myers
2022-12-07 11:59 ` Alejandro Colomar via Libc-alpha [this message]
2022-12-07 19:05 ` Joseph Myers
2022-11-27 12:04 ` Alejandro Colomar via Libc-alpha
2022-11-27 12:30 ` Alejandro Colomar via Libc-alpha
2022-11-27 12:39 ` Alejandro Colomar via Libc-alpha
2022-11-28 21:17 ` Joseph Myers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/libc/involved.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5ea5826c-e47c-2b4f-3699-4d6232b89332@gmail.com \
--to=libc-alpha@sourceware.org \
--cc=alx.manpages@gmail.com \
--cc=doremylover123@gmail.com \
--cc=joseph@codesourcery.com \
--cc=vapier@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).