1
1
openmpi/ompi/mpi/cxx/intercomm.h

87 строки
2.5 KiB
C
Исходник Обычный вид История

// -*- c++ -*-
//
// 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.
// Copyright (c) 2004-2005 High Performance Computing Center Stuttgart,
// University of Stuttgart. All rights reserved.
// 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.
// $COPYRIGHT$
//
// Additional copyrights may follow
//
// $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) { }
#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;
};