Re: AC_C_RESTRICT

[Jeff Squyres]

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