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$
|
|
|
|
//
|
|
|
|
|
|
|
|
#if 0 /* OMPI_ENABLE_MPI_PROFILING */
|
|
|
|
|
|
|
|
inline
|
|
|
|
MPI::Op::Op() { }
|
|
|
|
|
|
|
|
inline
|
|
|
|
MPI::Op::Op(const MPI::Op& o) : pmpi_op(o.pmpi_op) { }
|
|
|
|
|
|
|
|
inline
|
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
|
|
|
MPI::Op::Op(MPI_Op o) : pmpi_op(o) { }
|
2004-07-14 18:11:03 +04:00
|
|
|
|
|
|
|
inline
|
|
|
|
MPI::Op::~Op() { }
|
|
|
|
|
|
|
|
inline
|
|
|
|
MPI::Op& MPI::Op::operator=(const MPI::Op& op) {
|
|
|
|
pmpi_op = op.pmpi_op; return *this;
|
|
|
|
}
|
|
|
|
|
|
|
|
// comparison
|
|
|
|
inline bool
|
|
|
|
MPI::Op::operator== (const MPI::Op &a) {
|
|
|
|
return (bool)(pmpi_op == a.pmpi_op);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline bool
|
|
|
|
MPI::Op::operator!= (const MPI::Op &a) {
|
|
|
|
return (bool)!(*this == a);
|
|
|
|
}
|
|
|
|
|
|
|
|
// inter-language operability
|
|
|
|
inline MPI::Op&
|
|
|
|
MPI::Op::operator= (const MPI_Op &i) { pmpi_op = i; return *this; }
|
|
|
|
|
|
|
|
inline
|
|
|
|
MPI::Op::operator MPI_Op () const { return pmpi_op; }
|
|
|
|
|
|
|
|
//inline
|
|
|
|
//MPI::Op::operator MPI_Op* () { return pmpi_op; }
|
|
|
|
|
|
|
|
|
|
|
|
#else // ============= NO PROFILING ===================================
|
|
|
|
|
|
|
|
// construction
|
|
|
|
inline
|
|
|
|
MPI::Op::Op() : mpi_op(MPI_OP_NULL) { }
|
|
|
|
|
|
|
|
inline
|
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
|
|
|
MPI::Op::Op(MPI_Op i) : mpi_op(i) { }
|
2004-07-14 18:11:03 +04:00
|
|
|
|
|
|
|
inline
|
|
|
|
MPI::Op::Op(const MPI::Op& op)
|
2005-12-23 19:49:09 +03:00
|
|
|
: mpi_op(op.mpi_op) { }
|
2004-07-14 18:11:03 +04:00
|
|
|
|
|
|
|
inline
|
|
|
|
MPI::Op::~Op()
|
|
|
|
{
|
|
|
|
#if 0
|
|
|
|
mpi_op = MPI_OP_NULL;
|
|
|
|
op_user_function = 0;
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
|
|
|
inline MPI::Op&
|
|
|
|
MPI::Op::operator=(const MPI::Op& op) {
|
|
|
|
mpi_op = op.mpi_op;
|
|
|
|
return *this;
|
|
|
|
}
|
|
|
|
|
|
|
|
// comparison
|
|
|
|
inline bool
|
|
|
|
MPI::Op::operator== (const MPI::Op &a) { return (bool)(mpi_op == a.mpi_op); }
|
|
|
|
|
|
|
|
inline bool
|
|
|
|
MPI::Op::operator!= (const MPI::Op &a) { return (bool)!(*this == a); }
|
|
|
|
|
|
|
|
// inter-language operability
|
|
|
|
inline MPI::Op&
|
|
|
|
MPI::Op::operator= (const MPI_Op &i) { mpi_op = i; return *this; }
|
|
|
|
|
|
|
|
inline
|
|
|
|
MPI::Op::operator MPI_Op () const { return mpi_op; }
|
|
|
|
|
|
|
|
//inline
|
|
|
|
//MPI::Op::operator MPI_Op* () { return &mpi_op; }
|
|
|
|
|
|
|
|
#endif
|
|
|
|
|
2005-12-23 19:49:09 +03:00
|
|
|
// Extern this function here rather than include an internal Open MPI
|
|
|
|
// header file (and therefore force installing the internal Open MPI
|
|
|
|
// header file so that user apps can #include it)
|
|
|
|
|
|
|
|
extern "C" void ompi_op_set_cxx_callback(MPI_Op op, MPI_User_function*);
|
|
|
|
|
|
|
|
// There is a lengthy comment in ompi/mpi/cxx/intercepts.cc explaining
|
|
|
|
// what this function is doing. Please read it before modifying this
|
|
|
|
// function.
|
2004-07-14 18:11:03 +04:00
|
|
|
inline void
|
|
|
|
MPI::Op::Init(MPI::User_function *func, bool commute)
|
|
|
|
{
|
2005-12-23 19:49:09 +03:00
|
|
|
(void)MPI_Op_create((MPI_User_function*) ompi_mpi_cxx_op_intercept,
|
|
|
|
(int) commute, &mpi_op);
|
|
|
|
ompi_op_set_cxx_callback(mpi_op, (MPI_User_function*) func);
|
2004-07-14 18:11:03 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
inline void
|
|
|
|
MPI::Op::Free()
|
|
|
|
{
|
|
|
|
(void)MPI_Op_free(&mpi_op);
|
|
|
|
}
|