On 03/11/2014 05:35 PM, Jeff Squyres (jsquyres) wrote:
> On Mar 11, 2014, at 7:18 PM, Ralph Castain wrote:
>
>> Clarification: MPI_Address was deprecated for MPI_Get_address (which
>> properly has the const in it).
>
> Further clarification: MPI_Address was *removed* in MPI-3 (it was deprecated
On Mar 11, 2014, at 7:18 PM, Ralph Castain wrote:
> Clarification: MPI_Address was deprecated for MPI_Get_address (which properly
> has the const in it).
Further clarification: MPI_Address was *removed* in MPI-3 (it was deprecated
somewhere in the MPI-2.x series; I don't remember the exact ver
Clarification: MPI_Address was deprecated for MPI_Get_address (which properly
has the const in it). The MPI_Info_set problem is a bug and I'll commit a fix
for that one now.
What you might want to do is update your Score-P code to the current standard,
since you are striving for MPI-3 complianc
Hmmmwell, we appear to have a problem. According to our Forum reps, those
functions were deprecated by the Forum and hence the standard was actually NOT
updated with "const" declarations. For some odd reason, MPICH went ahead and
updated them anyway - leaving MPICH out of compliance with the
On 03/11/2014 11:30 AM, Jeff Squyres (jsquyres) wrote:
The safest thing for scoreP (and *any* MPI application/middleware) is to not
wholly rely on the MPI_VERSION macros.
From a theoretical sense, the MPI_VERSION macro should be sufficient.
But in reality, the upgrade of an MPI implementatio
Up to Nathan - I was just quieting the warning :-)
On Mar 11, 2014, at 3:06 PM, Dave Goodell (dgoodell) wrote:
> Might want to replace the bzero with memset while you're at it. I recall
> hitting portability problems on weird systems and Linux systems where
> features.h has been poked the wro
On Mar 6, 2014, at 12:00 PM, Mike Dubman wrote:
> but AF_IB is always declared, regardless of actual presence in the kernel.
Right, which is why I don't understand the original comments that you can't do
a run-time test for it...
>
> On Thu, Mar 6, 2014 at 5:56 PM, Ralph Castain wrote:
> Le
Might want to replace the bzero with memset while you're at it. I recall
hitting portability problems on weird systems and Linux systems where
features.h has been poked the wrong way with "_POSIX_SOURCE" and friends.
-Dave
On Mar 11, 2014, at 4:59 PM, svn-commit-mai...@open-mpi.org wrote:
> A
In the usual location:
http://www.open-mpi.org/software/ompi/v1.7/
Changes since 1.7.4:
- KNOWN PROBLEM: orteds will hang on MPI_ABORT or if processes exit with
nonzero status
- Multiple fixes to mapping/binding options. Thanks to Tetsuya Mishima
for his assistance
- Lots of oshmem fixes
I've trolled the SVN logs since 1.7.4, and here's what I think the version
numbers should be -- can someone double check these? (I only listed the values
from the VERSION file that should change). "Code change" simply means code in
the library has changed, but not interfaces.
libmpi_so_versio
Mellanox --
I realize that we're not always super careful about separating commits, but
this one commit contained 2 wholly separate things.
Can you please separate such obvious different things into multiple commits in
the future? Thanks.
On Mar 11, 2014, at 1:27 PM, wrote:
> Author: mike
The safest thing for scoreP (and *any* MPI application/middleware) is to not
wholly rely on the MPI_VERSION macros.
>From a theoretical sense, the MPI_VERSION macro should be sufficient.
But in reality, the upgrade of an MPI implementation to support all of MPI-3 is
a gradual thing and takes
Can't do much about 1.7.4, but fwiw 1.7.5 will not have this problem - nor will
it be present in 1.8.0 - as we have fully converted to MPI-3 now (and the
version will reflect it).
On Mar 11, 2014, at 10:14 AM, Orion Poplawski wrote:
> FYI -
>
> Looks like the mix of MPI 3 compliant and olde
FYI -
Looks like the mix of MPI 3 compliant and older declarations is causing a
bit of an issue for Score-P support. The current Score-P code bases adding
the const qualifiers on MPI_VERSION >= 3. But openmpi 1.7.4 is still
MPI_VERSION 2 (SUB 2). If I change scorep to add the const qualif
Yossi, is it possible to handle this with OBJ_RELEASE?
-Original Message-
From: bugs [mailto:bugs-boun...@open-mpi.org] On Behalf Of Open MPI
Sent: Monday, March 10, 2014 12:22 PM
Cc: b...@open-mpi.org
Subject: Re: [OMPI bugs] [Open MPI] #4354: Move r30966 to v1.7 branch (In
mtl_mxm, don
15 matches
Mail list logo
