I had an off-list discussion about this issue with a colleague at PGI.
I think the issue is this: apparently, "restrict" is different in C
than it is in C++. The Autoconf built-in AC_C_RESTRICT test *only*
tests the C compiler. The particular file you are compiling is C++
(components.cc), and the PGI 8.0 compiler only has __restrict in that
case.
I just checked my own setup and found that AC_C_RESTRICT finds
"__restrict" for me when I compile with PGI 6.2.5, 7.0.x, and 7.1.x.
Hence, it also works for me in C++ (i.e., components.c).
What does the stdout of configure say for you when it's checking for
restrict for you?
On Mar 13, 2009, at 3:07 PM, Mostyn Lewis wrote:
Well George's syntax didn't work, either:
"../../../.././ompi/mca/op/op.h", line 263: error: expected a ")"
typedef void (*ompi_op_base_3buff_handler_fn_1_0_0_t)(void
*restrict in1,
^
"../../../.././ompi/mca/op/op.h", line 267: warning: parsing
restarts here
after previous syntax error
struct
ompi_op_base_module_1_0_0_t *);
^
1 error detected in the compilation of "../../../.././ompi/tools/
ompi_info/components.cc".
make[2]: *** [components.o] Error 2
Using -c99 as a compiler flag made no difference, using the original
source.
Using -c89 as a compiler flag brought in a ton of other errors.
I'll be sending PGI a bug report to see what they say.
DM
On Thu, 12 Mar 2009, Jeff Squyres wrote:
> Mostyn -- can you try this and see if it works with the PGI 8.0
compiler?
>
>
> On Mar 12, 2009, at 6:20 PM, George Bosilca wrote:
>
>> Apparently, the PGI compiler (version 8) doesn't recognize
restrict as
>> a keyword in a function prototype if the associated argument is not
>> named. There is one obvious solution: remove the restrict keyword
but
>> I don't think it's the right one.
>>
>> Can you try to replace
>>> typedef void (*ompi_op_base_3buff_handler_fn_1_0_0_t)(void
*restrict,
>>> void
*restrict,
>>> void
*restrict,
>>> int *,
>>> struct
>>> ompi_datatype_t **,
>>> struct
>>> ompi_op_base_module_1_0_0_t *);
>>
>> by typedef void (*ompi_op_base_3buff_handler_fn_1_0_0_t)(void
>> *restrict in1,
>>> void
*restrict
>>> in2,
>>> void
*restrict
>>> out, int *,
>>> struct
>>> ompi_datatype_t **,
>>> struct
>>> ompi_op_base_module_1_0_0_t *);
>>
>> Thanks,
>> george.
>>
>> On Mar 11, 2009, at 15:52 , Mostyn Lewis wrote:
>>
>>> Compiling SVN r20757 with PGI 8.0-4 failed doing ompi_info with
>>>
>>> "../../../.././ompi/mca/op/op.h", line 264: error: duplicate
>>> parameter name
>>> void
*restrict,
>>> ^
>>>
>>> "../../../.././ompi/mca/op/op.h", line 265: error: duplicate
>>> parameter name
>>> void
>>> *restrict, int *,
>>> ^
>>>
>>> 2 errors detected in the compilation of "../../../.././ompi/tools/
>>> ompi_info/components.cc".
>>> make[2]: *** [components.o] Error 2
>>> make[2]: Leaving directory `/tmp/o/openmpi-1.4a1r20757_svn/build/
>>> ompi/tools/ompi_info'
>>>
>>> Code is:
>>>
>>> /*
>>> * Typedef for 3-buffer (two input and one output) op functions.
>>> */
>>> typedef void (*ompi_op_base_3buff_handler_fn_1_0_0_t)(void
*restrict,
>>> void
*restrict,
>>> void
*restrict,
>>> int *,
>>> struct
>>> ompi_datatype_t **,
>>> struct
>>> ompi_op_base_module_1_0_0_t *);
>>>
>>> DM
>>> _______________________________________________
>>> users mailing list
>>> us...@open-mpi.org
>>> http://www.open-mpi.org/mailman/listinfo.cgi/users
>>
>> _______________________________________________
>> users mailing list
>> us...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/users
>
>
> --
> Jeff Squyres
> Cisco Systems
>
> _______________________________________________
> users mailing list
> us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/users
_______________________________________________
users mailing list
us...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/users
--
Jeff Squyres
Cisco Systems
