Re: test for restrict fails with MS compiler

[Ralf Wildenhues]

Hello Jerker,

* Jerker Bäck wrote on Thu, Jul 19, 2007 at 11:36:07AM CEST:
> 
> > As Ralf said, `AC_C_RESTRICT' supports your compiler precisely as
> > intended: it defines away the `restrict' keyword, which your
> > compiler implements incorrectly
> 
> No, I'm not so sure about that. Indeed, I'm convinced the compiler
> implements the keyword exactly as intended.

There are two different issues here:

First, defining away the `restrict' keyword does no harm to correctness
of the source, only, if at all, to the efficiency of the generated code.
C99 guarantees that, and all implementations I've heard of -- even if
they only partially implement this keyword (und the name `restrict' or
`__restrict' or `__restrict__') -- have this correctness feature.

This implies that, if Autoconf used this:
  AC_DEFUN([AC_C_RESTRICT],
  [AC_DEFINE([restrict], [/* empty */],
    [We always turn off restrict.])])

it would be a very simplistic implementation.  But it would be correct
for programs, both from the ISO C99 standard point of view, and also
from experience with any compiler implementation (I've seen so far).

You would have a case with this first issue if you could prove that
defining away `restrict' is a problem with MSVC.  If that were the case,
then of course that would be another C99-complicance bug on MSVC's side.


Second, a claim that MSVC fully implements restrict as conforming to
C99, is wrong, we've gone through this before.  You seem to claim that
it is worthwhile to support MSVC's incomplete support for restrict.

This implies a certain trade-off: some valid C99 programs will fail to
compile, but some other programs (yours, presumably) that use restrict
may end up being optimized better by MSVC.  Well, for Autoconf such a
choice is easily made: Autoconf is foremost a portability tool.  As such
getting more programs to run as widely as possible is more important
than getting some programs to compile to faster code, while others fail
to even compile at all.

The fact that those compilers which have incomplete support for
`restrict' all happen to be proprietary ones may even facilitate
Autoconf's choice, but is only a side note and really not relevant to
the technical argumentation here.

> Furthermore, it has the
> __declspec(restrict) and __declspec(noalias) function attributes. The
> feature is not new, related with e.g. old and now obsolete -Oa and -Ow
> compiler switches. The problem is more that the autoconf test require
> modification of a custom type, which is not allowed - but as Ralf pointed
> out, is allowed in C99. This limitation have little to do with the restrict
> keyword.

Your argumentation seems to imply that leaving out
`__declspec(restrict)' (and `__declspec(noalias)'?  I don't know about
this one) implies correctness issues for the code in question.  Is that
the case?  If yes, then I would like to see an example (say, code that
fails without these attributes).  Barring an example, could you please
point out some documentation that would imply this?

> My point is: Why not lighten up the strict C99 requirement for better
> portability?

Because it *does not improve* portability.  Au contraire, it reduces it.
The arguments have all been presented: the way the macro is currently
written gets you the most portability, at the expense of possibily some
performance.

Cheers,
Ralf