Mail Archives: djgpp-workers/2000/04/24/08:42:57
According to Eli Zaretskii:
>
> On Sun, 23 Apr 2000, Martin Str|mberg wrote:
> > So I sueggest we use __restrict__ instead of restrict which seems to
> > be recognised always (I guess, from the documentation).
>
> What docs says __restrict__ is always recognised? And what does
> ``always'' mean here?
The info pages of gcc 2.95.2, below the "-flang-isoc9x" option.
> > So how far back was __restrict__ supported?
>
> The following example (from the C99 standard) doesn't compile with GCC
> 2.7.2.1:
>
> void foo (int n, int * __restrict__ p, int * __restrict__ q)
> {
> while (n-- > 0)
> *p++ = *q++;
> }
>
> The #ifdef magic below (lifted from the GCC bug-reporting list) seems
> to imply that __restrict__ is only supported in GCC 2.91 and later.
>
> > Or can we demand that users of DJGPP v. 2.04 use gcc 2.95.2?
>
> I would like to avoid requiring specific versions of GCC, unless we
> absolutely must.
But then we would have the problem of libc headers not matching libc
compilation. Think: libc is compiled with gcc 2.95.2, and the user is
using 2.7.2.1 or the reverse. Thus it seems to me _if_ we are starting
to use restrict in libc we really _do_ need to say "you must use gcc
version X.Y or later for DJGPP 2.0Z".
> > Or do you know/suggest a different approach (some magic #define
> > somewhere, perhaps)?
>
> I suggest the following:
>
> #if __STDC_VERSION__ >= 199901
> #elif __GNUC__ >= 2 && __GNUC_MINOR__ >= 91
> #define restrict __restrict__
> #else
> #define restrict
> #endif
>
> In a recent discussion, this seems to have got a semi-formal blessing
> of at least one GCC maintainer.
And where to put that? In every file that needs it or some kind of
general file?
But the major problem is the libc headers not matching the compiled
libc.
Right,
MartinS
- Raw text -