On Mar 17, 2009, at 2:46 AM, Ralf Wildenhues wrote:
> It seems that AC_C_RESTRICT can sometimes find "restrict" for the
PGI C
> compiler, but it can sometimes find "__restrict". Both of these
values
> work for the PGI C compiler, but only "__restrict" works for the
PGI C++
> compiler.
The Autoconf test tries __restrict first, at least the current code
does. Can you please find the bits in the config.log file that show
why the test fails with __restrict but later passes with restrict,
for the PGI C compiler?
Sure; I'll ping the original reporter to get his config.log (I'm not
sure what timezone he's in). For whatever reason, AC_C_RESTRICT gets
__restrict for me with the PGI 7.x compiler, and therefore it all
works properly for me (I'm waiting for IT to install the PGI 8.0
licenses -- that's the compiler the original reporter was using).
> - should there be an AC_CXX_RESTRICT test? E.g., perhaps the
output of
> AC_C_RESTRICT and AC_CXX_RESTRICT tests would be protected with
> appropriate #if's that determine if you're compiling in C or C++.
I don't see the need for that yet: both Sun and PGI compiler suites
have
a common denominator; only if you want to mix-and-match compilers from
different suites, then we need to go all the way.
Ok.
Our hackaround in OMPI is currently to have the following in a top-
level header file:
#if defined(c_plusplus) || defined(__cplusplus)
#undef restrict
#define restrict
#endif
It's definitely sub-optimal, but we're pretty sure it's safe.
Would it be a tragedy to repeat the guts of the AC_C_RESTRICT test
with the C++ compiler and then know what the two different values
are? The value of "restrict" can then be #define'd (or not) depending
on whether you're compiling in C or C++.
--
Jeff Squyres
Cisco Systems