This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: "restrict" implementation bug ?
- To: Dan Nicolaescu <dann at godzilla dot ICS dot UCI dot EDU>
- Subject: Re: "restrict" implementation bug ?
- From: "Joseph S. Myers" <jsm28 at cam dot ac dot uk>
- Date: Mon, 2 Apr 2001 08:26:29 +0100 (BST)
- cc: <gcc at gcc dot gnu dot org>
On Sun, 1 Apr 2001, Dan Nicolaescu wrote:
> According to http://wwwold.dkuug.dk/JTC1/SC22/WG14/www/docs/n897.pdf
> (pointed to by a link from http://gcc.gnu.org/readings.html)
> (and BTW there is a n937.pdf file in the same place that seems to be
> a newer version)
> global variables with a restrict qualifier should act "as if it were
> declared as an array".
>
> It seems that there is a bug when using both a restricted global var
> and a pointer obtained from "malloc" call.
> As shown in the example bellow when using either of them individualy
> "restrict" works correctly.
Can you please send actual bug reports (as opposed to questions) for
non-bootstrap bugs to our GNATS bug tracking database, rather than to the
gcc list, so they are properly tracked for when someone looks at the
problem, quite likely months later? With 60Mbyte/month of mail to the GCC
mailing lists, if a bug isn't filed properly then it is unlikely to be
looked at ever if no-one has the time and inclination to look at it
immediately.
Also, when dealing with subtle areas of the language, it would be helpful
to reference the actual standard wording (with subclause and paragraph
numbers) rather than the draft Rationale. Especially here, where I don't
think the Rationale has been effectively updated for the changes in
"restrict" between the public C9X drafts and the FDIS and final standard.
I think category "c", class "pessimizes-code" would be appropriate for the
PR. Note 6.7.3.1 paragraph 6 and 6.7.3 paragraph 7: a conforming C99
implementation could entirely ignore "restrict" apart from checking type
compatibility rules.
It is deliberate that I haven't sent a patch to link to N937, since the
changes are minor and the marking of individual changes in red makes it an
excessively confusing version for the ordinary user. If a version of the
updated Rationale appears without such markings of edits, I'll send a
patch to link to it.
--
Joseph S. Myers
jsm28@cam.ac.uk