1
1
Граф коммитов

7 Коммитов

Автор SHA1 Сообщение Дата
Brian Barrett
2b8af283de Add ability to completely turn off MPI one-sided support, so that users
can experiment with using ROMIO directly.

This commit was SVN r15922.
2007-08-18 21:35:51 +00:00
Brian Barrett
1ba97181dc A number of MPI-2 compliance fixes for the C++ bindings:
* Added Create_errhandler for MPI::File
  * Make errors_throw_exceptions a first-class predefined exception
    handler, and make it work for Comm, File, and Win
  * Deal with error handlers and attributes for Files, Types, and Wins
    like we do with Comms - can't just cast the callbacks from C++
    signatures to C signatures.  Callbacks will then fire with the
    C object, not the C++ object.  That's bad.

Refs trac:455

This commit was SVN r12945.

The following Trac tickets were found above:
  Ticket 455 --> https://svn.open-mpi.org/trac/ompi/ticket/455
2006-12-30 23:41:42 +00:00
Jeff Squyres
0a28212392 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 17:34:12 +00:00
Jeff Squyres
83d34c8435 - Remove some dead code
- Fix some typos from last commit
- Add collectives of intercommunicators
- Move the static current_op member from Intracomm to Comm
  --> this is still a remaining problem: the global variable
      current_op is not thread safe!

This commit was SVN r8520.
2005-12-15 22:07:34 +00:00
Jeff Squyres
4379be6edc Fix some more const_cast issues. Thanks to Martin Audet for helping
with this.

This commit was SVN r8516.
2005-12-15 21:24:42 +00:00
Jeff Squyres
42ec26e640 Update the copyright notices for IU and UTK.
This commit was SVN r7999.
2005-11-05 19:57:48 +00:00
Jeff Squyres
4ab17f019b Rename src -> ompi
This commit was SVN r6269.
2005-07-02 13:43:57 +00:00