We tracked this down further -- it appears that the culprit was an out-
of-date Autoconf installation.
Specifically, somewhere between Autoconf 2.61 and 2.63, they changed
the order of looking for the various "restrict" keywords. AC 2.63
looks at "__restrict" *first* (i.e., before "restrict
George and I talked more off-list / phone and he convinced me that
it's ok to do this in a top-level header file:
#if defined(c_plusplus) || defined(__cplusplus)
#undef restrict
#define restrict
#endif
I'll post to the Autoconf list about this soon.
On Mar 16, 2009, at 4:43 AM, Samuel Sarhol
Hi,
I am pretty sure that C++ has no restrict keyword (only C99), so IMHO
it's not the compilers fault is not compiling.
You probably want to turn restricts off for C++ by default, unless you
know the compiler supports it.
best regards,
Samuel
smime.p7s
Description: S/MIME Cryptographic Si
this way.
On Mar 14, 2009, at 7:39 AM, Terry Dontje wrote:
> You know this all looks very similar to the reason why rolfv putback
> r20351 which essentially defined out restrict within
> opal_config_bottom.h when using Sun Studio.
>
> --td
>
> Date: Fri, 13 Mar 2009
ery similar to the reason why rolfv putback
r20351 which essentially defined out restrict within
opal_config_bottom.h when using Sun Studio.
--td
Date: Fri, 13 Mar 2009 16:40:49 -0400
From: Jeff Squyres
Subject: Re: [OMPI users] PGI 8.0-4 doesn't like ompi/mca/op/op.h
To: "Ope
] PGI 8.0-4 doesn't like ompi/mca/op/op.h
To: "Open MPI Users"
Message-ID: <2aca69ab-5f23-4ae9-8826-77a6348e9...@cisco.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
On Mar 13, 2009, at 4:37 PM, Mostyn Lewis wrote:
> >From config.log
>
>
On 03/13/09 16:40, Jeff Squyres wrote:
On Mar 13, 2009, at 4:37 PM, Mostyn Lewis wrote:
>From config.log
configure:21522: checking for C/C++ restrict keyword
configure:21558: pgcc -c -DNDEBUG -fast -Msignextend -tp p7-64
conftest.c >&5
configure:21564: $? = 0
configure:21582: result: restri
On Mar 13, 2009, at 4:37 PM, Mostyn Lewis wrote:
>From config.log
configure:21522: checking for C/C++ restrict keyword
configure:21558: pgcc -c -DNDEBUG -fast -Msignextend -tp p7-64
conftest.c >&5
configure:21564: $? = 0
configure:21582: result: restrict
So you only check using pgcc (not p
From config.log
configure:21522: checking for C/C++ restrict keyword
configure:21558: pgcc -c -DNDEBUG -fast -Msignextend -tp p7-64 conftest.c >&5
configure:21564: $? = 0
configure:21582: result: restrict
So you only check using pgcc (not pgCC)?
DM
On Fri, 13 Mar 2009, Jeff Squyres wrote:
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),
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
Mark Potts wrote:
> All,
>I don't know PGI's compilers, but is it possible that since "restrict"
>was supposedly introduced as a C99 feature that it is not supported
>by default by their C compiler? This would explain the wording of
>the error message which indicates interpretation
I was able to compile 1.3.0 with PGI 8.0-3 on January 27th. If that
helps anyone.
--
Prentice
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 solutio
FWIW, It compiles with PGI 7.2 on RHEL4U7
[acaird@nyx-login1 ~]$ ompi_info | grep "compiler abs"
C compiler absolute: /usr/caen/pgi-7.2/linux86-64/7.2-1/bin/pgcc
C++ compiler absolute: /usr/caen/pgi-7.2/linux86-64/7.2-1/bin/pgCC
Fortran77 compiler abs: /usr/caen/pgi-7.2/linux86-64/7.2
I believe Mostyn's error is due to a change in PGI 8.0-x from earlier
releases (PGI has been known to do these kind of things). My point was
only that PGI is a tad different from our other compilers, and that we
do typically see kernel-related issues as well. So one needs to watch
out for P
On Mar 12, 2009, at 11:17 PM, Ralph Castain wrote:
I believe I reported this before on a different mailing list, but will
repeat it here. The PGI compilers rely on the Linux kernel for some
things. We found that the ability of the PGI compilers to build OMPI,
therefore, was highly dependent upon
I believe I reported this before on a different mailing list, but will
repeat it here. The PGI compilers rely on the Linux kernel for some
things. We found that the ability of the PGI compilers to build OMPI,
therefore, was highly dependent upon the specific Linux kernel on the
machine.
F
It's odd because PGI 7.0 and 7.1 compile OMPI just fine (don't know
about PGI 7.2).
On Mar 12, 2009, at 7:09 PM, Mark Potts wrote:
All,
I don't know PGI's compilers, but is it possible that since
"restrict"
was supposedly introduced as a C99 feature that it is not
supported
All,
I don't know PGI's compilers, but is it possible that since "restrict"
was supposedly introduced as a C99 feature that it is not supported
by default by their C compiler? This would explain the wording of
the error message which indicates interpretation of "restrict" as a
vari
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
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_b
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/
22 matches
Mail list logo