2004-07-14 18:11:03 +04:00
|
|
|
// -*- c++ -*-
|
|
|
|
//
|
2005-11-05 22:57:48 +03:00
|
|
|
// Copyright (c) 2004-2005 The Trustees of Indiana University and Indiana
|
|
|
|
// University Research and Technology
|
|
|
|
// Corporation. All rights reserved.
|
|
|
|
// Copyright (c) 2004-2005 The University of Tennessee and The University
|
|
|
|
// of Tennessee Research Foundation. All rights
|
|
|
|
// reserved.
|
2004-11-28 23:09:25 +03:00
|
|
|
// Copyright (c) 2004-2005 High Performance Computing Center Stuttgart,
|
|
|
|
// University of Stuttgart. All rights reserved.
|
2005-03-24 15:43:37 +03:00
|
|
|
// Copyright (c) 2004-2005 The Regents of the University of California.
|
|
|
|
// All rights reserved.
|
This is a workaround to bug in the Intel C++ compiler, version 9.1
(all versions up to and including 20060925). The issue has been
reported to Intel, along with a small [non-MPI] test program that
reproduces the problem (the test program and the OMPI C++ bindings
work fine with Intel C++ 9.0 and many other C++ compilers).
In short, a static initializer for a global variable (i.e., its
constructor is fired before main()) that takes as an argument a
reference to a typedef'd type will simply get the wrong value in the
argument. Specifically:
{{{
namespace MPI {
Intracomm COMM_WORLD(MPI_COMM_WORLD);
}
}}}
The constructor for MPI::Intracomm should get the value of
&ompi_mpi_comm_world. It does not; it seems to get a random value.
As mandated by MPI-2, annex B.13.4, for C/C++ interoperability, the
prototype for this constructor is:
{{{
class Intracomm {
public:
Intracomm(const MPI_Comm& data);
};
}}}
Experiments with icpc 9.1/20060925 have shown that removing the
reference from the prototype makes it work (!). After lots of
discussions about this issue with a C++ expert (Doug Gregor from IU),
we decided the following (cut-n-paste from an e-mail):
-----
> So here's my question: given that OMPI's MPI_<CLASS> types are all
> pointers, is there any legal MPI program that adheres to the above
> bindings that would fail to compile or work properly if we simply
> removed the "&" from the second binding, above?
I don't know of any way that a program could detect this change. FWIW,
the C++ committee has agreed that implementation of the C++ standard
library are allowed to decide arbitrarily between const& and by-value.
If they don't care, MPI users won't care.
When you remove the '&', I suggest also removing the "const". It is
redundant, but can trigger some strange name mangling in Sun's C++
compiler.
-----
So with this change:
* we now work again with the Intel 9.1 compiler
* our C++ bindings do not exactly conform to the MPI-2 spec, but
valid/legal MPI C++ apps cannot tell the difference (i.e., the
functionality is the same)
This commit was SVN r12514.
2006-11-09 20:34:12 +03:00
|
|
|
// Copyright (c) 2006 Cisco Systems, Inc. All rights reserved.
|
2004-11-22 04:38:40 +03:00
|
|
|
// $COPYRIGHT$
|
|
|
|
//
|
|
|
|
// Additional copyrights may follow
|
|
|
|
//
|
2004-07-14 18:11:03 +04:00
|
|
|
// $HEADER$
|
|
|
|
//
|
|
|
|
|
|
|
|
class Group {
|
|
|
|
#if 0 /* OMPI_ENABLE_MPI_PROFILING */
|
|
|
|
// friend class PMPI::Group;
|
|
|
|
#endif
|
|
|
|
public:
|
|
|
|
|
|
|
|
#if 0 /* OMPI_ENABLE_MPI_PROFILING */
|
|
|
|
|
|
|
|
// construction
|
|
|
|
inline Group() { }
|
This is a workaround to bug in the Intel C++ compiler, version 9.1
(all versions up to and including 20060925). The issue has been
reported to Intel, along with a small [non-MPI] test program that
reproduces the problem (the test program and the OMPI C++ bindings
work fine with Intel C++ 9.0 and many other C++ compilers).
In short, a static initializer for a global variable (i.e., its
constructor is fired before main()) that takes as an argument a
reference to a typedef'd type will simply get the wrong value in the
argument. Specifically:
{{{
namespace MPI {
Intracomm COMM_WORLD(MPI_COMM_WORLD);
}
}}}
The constructor for MPI::Intracomm should get the value of
&ompi_mpi_comm_world. It does not; it seems to get a random value.
As mandated by MPI-2, annex B.13.4, for C/C++ interoperability, the
prototype for this constructor is:
{{{
class Intracomm {
public:
Intracomm(const MPI_Comm& data);
};
}}}
Experiments with icpc 9.1/20060925 have shown that removing the
reference from the prototype makes it work (!). After lots of
discussions about this issue with a C++ expert (Doug Gregor from IU),
we decided the following (cut-n-paste from an e-mail):
-----
> So here's my question: given that OMPI's MPI_<CLASS> types are all
> pointers, is there any legal MPI program that adheres to the above
> bindings that would fail to compile or work properly if we simply
> removed the "&" from the second binding, above?
I don't know of any way that a program could detect this change. FWIW,
the C++ committee has agreed that implementation of the C++ standard
library are allowed to decide arbitrarily between const& and by-value.
If they don't care, MPI users won't care.
When you remove the '&', I suggest also removing the "const". It is
redundant, but can trigger some strange name mangling in Sun's C++
compiler.
-----
So with this change:
* we now work again with the Intel 9.1 compiler
* our C++ bindings do not exactly conform to the MPI-2 spec, but
valid/legal MPI C++ apps cannot tell the difference (i.e., the
functionality is the same)
This commit was SVN r12514.
2006-11-09 20:34:12 +03:00
|
|
|
inline Group(MPI_Group i) : pmpi_group(i) { }
|
2004-07-14 18:11:03 +04:00
|
|
|
// copy
|
|
|
|
inline Group(const Group& g) : pmpi_group(g.pmpi_group) { }
|
|
|
|
|
|
|
|
inline Group(const PMPI::Group& g) : pmpi_group(g) { }
|
|
|
|
|
|
|
|
inline virtual ~Group() {}
|
|
|
|
|
|
|
|
Group& operator=(const Group& g) {
|
|
|
|
pmpi_group = g.pmpi_group; return *this;
|
|
|
|
}
|
|
|
|
|
|
|
|
// comparison
|
|
|
|
inline bool operator== (const Group &a) {
|
|
|
|
return (bool)(pmpi_group == a.pmpi_group);
|
|
|
|
}
|
|
|
|
inline bool operator!= (const Group &a) {
|
|
|
|
return (bool)!(*this == a);
|
|
|
|
}
|
|
|
|
|
|
|
|
// inter-language operability
|
|
|
|
Group& operator= (const MPI_Group &i) { pmpi_group = i; return *this; }
|
|
|
|
inline operator MPI_Group () const { return pmpi_group.mpi(); }
|
|
|
|
// inline operator MPI_Group* () const { return pmpi_group; }
|
|
|
|
inline operator const PMPI::Group&() const { return pmpi_group; }
|
|
|
|
|
|
|
|
const PMPI::Group& pmpi() { return pmpi_group; }
|
|
|
|
#else
|
|
|
|
|
|
|
|
// construction
|
|
|
|
inline Group() : mpi_group(MPI_GROUP_NULL) { }
|
This is a workaround to bug in the Intel C++ compiler, version 9.1
(all versions up to and including 20060925). The issue has been
reported to Intel, along with a small [non-MPI] test program that
reproduces the problem (the test program and the OMPI C++ bindings
work fine with Intel C++ 9.0 and many other C++ compilers).
In short, a static initializer for a global variable (i.e., its
constructor is fired before main()) that takes as an argument a
reference to a typedef'd type will simply get the wrong value in the
argument. Specifically:
{{{
namespace MPI {
Intracomm COMM_WORLD(MPI_COMM_WORLD);
}
}}}
The constructor for MPI::Intracomm should get the value of
&ompi_mpi_comm_world. It does not; it seems to get a random value.
As mandated by MPI-2, annex B.13.4, for C/C++ interoperability, the
prototype for this constructor is:
{{{
class Intracomm {
public:
Intracomm(const MPI_Comm& data);
};
}}}
Experiments with icpc 9.1/20060925 have shown that removing the
reference from the prototype makes it work (!). After lots of
discussions about this issue with a C++ expert (Doug Gregor from IU),
we decided the following (cut-n-paste from an e-mail):
-----
> So here's my question: given that OMPI's MPI_<CLASS> types are all
> pointers, is there any legal MPI program that adheres to the above
> bindings that would fail to compile or work properly if we simply
> removed the "&" from the second binding, above?
I don't know of any way that a program could detect this change. FWIW,
the C++ committee has agreed that implementation of the C++ standard
library are allowed to decide arbitrarily between const& and by-value.
If they don't care, MPI users won't care.
When you remove the '&', I suggest also removing the "const". It is
redundant, but can trigger some strange name mangling in Sun's C++
compiler.
-----
So with this change:
* we now work again with the Intel 9.1 compiler
* our C++ bindings do not exactly conform to the MPI-2 spec, but
valid/legal MPI C++ apps cannot tell the difference (i.e., the
functionality is the same)
This commit was SVN r12514.
2006-11-09 20:34:12 +03:00
|
|
|
inline Group(MPI_Group i) : mpi_group(i) { }
|
2004-07-14 18:11:03 +04:00
|
|
|
|
|
|
|
// copy
|
|
|
|
inline Group(const Group& g) : mpi_group(g.mpi_group) { }
|
|
|
|
|
|
|
|
inline virtual ~Group() {}
|
|
|
|
|
|
|
|
inline Group& operator=(const Group& g) { mpi_group = g.mpi_group; return *this; }
|
|
|
|
|
|
|
|
// comparison
|
|
|
|
inline bool operator== (const Group &a) { return (bool)(mpi_group == a.mpi_group); }
|
|
|
|
inline bool operator!= (const Group &a) { return (bool)!(*this == a); }
|
|
|
|
|
|
|
|
// inter-language operability
|
|
|
|
inline Group& operator= (const MPI_Group &i) { mpi_group = i; return *this; }
|
|
|
|
inline operator MPI_Group () const { return mpi_group; }
|
|
|
|
// inline operator MPI_Group* () const { return (MPI_Group*)&mpi_group; }
|
|
|
|
|
|
|
|
inline MPI_Group mpi() const { return mpi_group; }
|
|
|
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
//
|
|
|
|
// Groups, Contexts, and Communicators
|
|
|
|
//
|
|
|
|
|
|
|
|
virtual int Get_size() const;
|
|
|
|
|
|
|
|
virtual int Get_rank() const;
|
|
|
|
|
|
|
|
static void Translate_ranks (const Group& group1, int n, const int ranks1[],
|
|
|
|
const Group& group2, int ranks2[]);
|
|
|
|
|
|
|
|
static int Compare(const Group& group1, const Group& group2);
|
|
|
|
|
|
|
|
static Group Union(const Group &group1, const Group &group2);
|
|
|
|
|
|
|
|
static Group Intersect(const Group &group1, const Group &group2);
|
|
|
|
|
|
|
|
static Group Difference(const Group &group1, const Group &group2);
|
|
|
|
|
|
|
|
virtual Group Incl(int n, const int ranks[]) const;
|
|
|
|
|
|
|
|
virtual Group Excl(int n, const int ranks[]) const;
|
|
|
|
|
|
|
|
virtual Group Range_incl(int n, const int ranges[][3]) const;
|
|
|
|
|
|
|
|
virtual Group Range_excl(int n, const int ranges[][3]) const;
|
|
|
|
|
|
|
|
virtual void Free();
|
|
|
|
|
|
|
|
protected:
|
|
|
|
#if ! 0 /* OMPI_ENABLE_MPI_PROFILING */
|
|
|
|
MPI_Group mpi_group;
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#if 0 /* OMPI_ENABLE_MPI_PROFILING */
|
|
|
|
private:
|
|
|
|
PMPI::Group pmpi_group;
|
|
|
|
#endif
|
|
|
|
|
|
|
|
};
|
|
|
|
|