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 Intercomm : public Comm {
|
|
|
|
#if 0 /* OMPI_ENABLE_MPI_PROFILING */
|
|
|
|
// friend class PMPI::Intercomm;
|
|
|
|
#endif
|
|
|
|
public:
|
|
|
|
|
|
|
|
// construction
|
|
|
|
Intercomm() : Comm(MPI_COMM_NULL) { }
|
|
|
|
// copy
|
|
|
|
Intercomm(const Comm_Null& data) : Comm(data) { }
|
|
|
|
// inter-language operability
|
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
|
|
|
Intercomm(MPI_Comm data) : Comm(data) { }
|
2004-07-14 18:11:03 +04:00
|
|
|
|
|
|
|
#if 0 /* OMPI_ENABLE_MPI_PROFILING */
|
|
|
|
// copy
|
|
|
|
Intercomm(const Intercomm& data) : Comm(data), pmpi_comm(data.pmpi_comm) { }
|
|
|
|
Intercomm(const PMPI::Intercomm& d) :
|
|
|
|
Comm((const PMPI::Comm&)d), pmpi_comm(d) { }
|
|
|
|
|
|
|
|
// assignment
|
|
|
|
Intercomm& operator=(const Intercomm& data) {
|
|
|
|
Comm::operator=(data);
|
|
|
|
pmpi_comm = data.pmpi_comm; return *this; }
|
|
|
|
Intercomm& operator=(const Comm_Null& data) {
|
|
|
|
Comm::operator=(data);
|
|
|
|
Intercomm& ic = (Intercomm&)data;
|
|
|
|
pmpi_comm = ic.pmpi_comm; return *this; }
|
|
|
|
// inter-language operability
|
|
|
|
Intercomm& operator=(const MPI_Comm& data) {
|
|
|
|
Comm::operator=(data);
|
|
|
|
pmpi_comm = PMPI::Intercomm(data); return *this; }
|
|
|
|
#else
|
|
|
|
// copy
|
|
|
|
Intercomm(const Intercomm& data) : Comm(data.mpi_comm) { }
|
|
|
|
// assignment
|
|
|
|
Intercomm& operator=(const Intercomm& data) {
|
|
|
|
mpi_comm = data.mpi_comm; return *this; }
|
|
|
|
Intercomm& operator=(const Comm_Null& data) {
|
|
|
|
mpi_comm = data; return *this; }
|
|
|
|
// inter-language operability
|
|
|
|
Intercomm& operator=(const MPI_Comm& data) {
|
|
|
|
mpi_comm = data; return *this; }
|
|
|
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
|
|
//
|
|
|
|
// Groups, Contexts, and Communicators
|
|
|
|
//
|
|
|
|
|
|
|
|
Intercomm Dup() const;
|
|
|
|
|
|
|
|
virtual Intercomm& Clone() const;
|
|
|
|
|
|
|
|
virtual int Get_remote_size() const;
|
|
|
|
|
|
|
|
virtual Group Get_remote_group() const;
|
|
|
|
|
|
|
|
virtual Intracomm Merge(bool high);
|
|
|
|
|
|
|
|
virtual Intercomm Create(const Group& group) const;
|
|
|
|
|
|
|
|
virtual Intercomm Split(int color, int key) const;
|
|
|
|
|
|
|
|
};
|