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 Errhandler {
|
|
|
|
public:
|
|
|
|
// construction / destruction
|
|
|
|
inline Errhandler()
|
|
|
|
: mpi_errhandler(MPI_ERRHANDLER_NULL) {}
|
|
|
|
|
|
|
|
inline virtual ~Errhandler() { }
|
|
|
|
|
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 Errhandler(MPI_Errhandler i)
|
2004-07-14 18:11:03 +04:00
|
|
|
: mpi_errhandler(i) {}
|
|
|
|
|
|
|
|
// copy / assignment
|
|
|
|
inline Errhandler(const Errhandler& e)
|
2006-12-31 02:41:42 +03:00
|
|
|
: comm_handler_fn(e.comm_handler_fn),
|
|
|
|
file_handler_fn(e.file_handler_fn),
|
|
|
|
win_handler_fn(e.win_handler_fn),
|
|
|
|
mpi_errhandler(e.mpi_errhandler) { }
|
2004-07-14 18:11:03 +04:00
|
|
|
|
|
|
|
inline Errhandler& operator=(const Errhandler& e)
|
|
|
|
{
|
|
|
|
mpi_errhandler = e.mpi_errhandler;
|
2006-12-31 02:41:42 +03:00
|
|
|
comm_handler_fn = e.comm_handler_fn;
|
|
|
|
file_handler_fn = e.file_handler_fn;
|
|
|
|
win_handler_fn = e.win_handler_fn;
|
2004-07-14 18:11:03 +04:00
|
|
|
return *this;
|
|
|
|
}
|
|
|
|
|
|
|
|
// comparison
|
|
|
|
inline bool operator==(const Errhandler &a) {
|
|
|
|
return (bool)(mpi_errhandler == a.mpi_errhandler); }
|
|
|
|
|
|
|
|
inline bool operator!=(const Errhandler &a) {
|
|
|
|
return (bool)!(*this == a); }
|
|
|
|
|
|
|
|
// inter-language operability
|
|
|
|
inline Errhandler& operator= (const MPI_Errhandler &i) {
|
|
|
|
mpi_errhandler = i; return *this; }
|
|
|
|
|
|
|
|
inline operator MPI_Errhandler() const { return mpi_errhandler; }
|
|
|
|
|
|
|
|
// inline operator MPI_Errhandler*() { return &mpi_errhandler; }
|
|
|
|
|
|
|
|
//
|
|
|
|
// Errhandler access functions
|
|
|
|
//
|
|
|
|
|
|
|
|
virtual void Free();
|
|
|
|
|
2006-12-31 02:41:42 +03:00
|
|
|
Comm::Errhandler_fn* comm_handler_fn;
|
|
|
|
File::Errhandler_fn* file_handler_fn;
|
|
|
|
Win::Errhandler_fn* win_handler_fn;
|
2004-07-14 18:11:03 +04:00
|
|
|
|
|
|
|
MPI_Errhandler mpi_errhandler;
|
|
|
|
};
|