Tru64/OSF 5.1D fails the "AC_C_RESTRICT and C++" test, when using the
vendor C and C++ compiler:
265. c.at:266: testing AC_C_RESTRICT and C++ ...
../../autoconf/tests/c.at:316: autoconf
../../autoconf/tests/c.at:317: autoheader
../../autoconf/tests/c.at:318: ./configure $configure_options
stderr:
stdout:
checking for gcc... cc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... no
checking whether cc accepts -g... yes
checking for cc option to accept ISO C89... none needed
checking whether we are using the GNU C++ compiler... no
checking whether cxx accepts -g... yes
checking for C/C++ restrict keyword... __restrict
configure: creating ./config.status
config.status: creating Makefile
config.status: creating config.h
../../autoconf/tests/c.at:319: ${MAKE-make} cpp-works || exit 77
stderr:
stdout:
cxx -I. -g -c cpp-works.cpp
../../autoconf/tests/c.at:320: ${MAKE-make}
stderr:
cxx: Error: bar.cpp, line 3: expected a ")"
int foo (int * restrict i1, int * restrict i2)
------------------------^
cxx: Error: bar.cpp, line 5: identifier "i1" is undefined
return i1[0] + i2[0];
---------^
cxx: Error: bar.cpp, line 5: identifier "i2" is undefined
return i1[0] + i2[0];
-----------------^
cxx: Info: 3 errors detected in the compilation of "bar.cpp".
Stop.
stdout:
cc -I. -g -c foo.c
cxx -I. -g -c bar.cpp
*** Exit 1../../autoconf/tests/c.at:320: exit code was 1, expected 0
265. c.at:266: 265. AC_C_RESTRICT and C++ (c.at:266): FAILED (c.at:320)
This is a bit weird, because cxx.1 documents the following:
-accept [no]restrict_keyword
Specifying -accept restrict_keyword option causes the compiler to
recognize the restrict keyword, which may be used to inform the com-
piler that the pointer has no aliases. This information is an asser-
tion by the user to assist optimization. The compiler cannot detect
erroneous assertions. The restrict keyword is mangled into function
signatures when appropriate; you may overload a function based on the
restrict keyword.
Specifying -accept norestrict_keyword option causes the compiler not
to treat restrict as a keyword. This is the default.
You can also use __restrict to qualify pointers in all dialects except
-std strict_ansi or -std strict_ansi_errors. This is useful in pro-
grams where restrict is used an identifier.
The -accept [no]restrict_keyword option is applicable only in the
model ansi mode of the compiler.
where `-model arm' is the default, not `-model ansi', and -model changes
class layout and causes other binary incompatibilities.
I don't really that we can set this automatically, due to the binary
incompatibility, so we may need to resort to C++ specific restrict
setting based on __cplusplus. Thoughts?
I do wonder whether this is an undesirable compiler limitation though.
Thanks,
Ralf
