have different sizes:
1. Do not modify the read only parameter of the Fortran MPI interface (i.e be
standard compliant).
2. When Fortran integers are 64 bits long, don't generate unlawful code.
Thanks to Christoph van Wullen for the bug report.
This commit was SVN r20420.
* New "op" MPI layer framework
* Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2)
= Op framework =
Add new "op" framework in the ompi layer. This framework replaces the
hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples
for pre-defined MPI_Ops, allowing components and modules to provide
the back-end functions. The intent is that components can be written
to take advantage of hardware acceleration (GPU, FPGA, specialized CPU
instructions, etc.). Similar to other frameworks, components are
intended to be able to discover at run-time if they can be used, and
if so, elect themselves to be selected (or disqualify themselves from
selection if they cannot run). If specialized hardware is not
available, there is a default set of functions that will automatically
be used.
This framework is ''not'' used for user-defined MPI_Ops.
The new op framework is similar to the existing coll framework, in
that the final set of function pointers that are used on any given
intrinsic MPI_Op can be a mixed bag of function pointers, potentially
coming from multiple different op modules. This allows for hardware
that only supports some of the operations, not all of them (e.g., a
GPU that only supports single-precision operations).
All the hard-coded back-end MPI_Op functions for (MPI_Op,
MPI_Datatype) tuples still exist, but unlike coll, they're in the
framework base (vs. being in a separate "basic" component) and are
automatically used if no component is found at runtime that provides a
module with the necessary function pointers.
There is an "example" op component that will hopefully be useful to
those writing meaningful op components. It is currently
.ompi_ignore'd so that it doesn't impinge on other developers (it's
somewhat chatty in terms of opal_output() so that you can tell when
its functions have been invoked). See the README file in the example
op component directory. Developers of new op components are
encouraged to look at the following wiki pages:
https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogenhttps://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponenthttps://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework
= MPI_REDUCE_LOCAL =
Part of the MPI-2.2 proposal listed here:
https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24
is to add a new function named MPI_REDUCE_LOCAL. It is very easy to
implement, so I added it (also because it makes testing the op
framework pretty easy -- you can do it in serial rather than via
parallel reductions). There's even a man page!
This commit was SVN r20280.
pondering about this problem, we came to the conclusion that the best approach
is to keep what we had before (i.e. the original approach).
The main reason for this is being nice with tool developers. In the current
incarnation, they can either catch the Fortran calls or the C calls. If they
provide both, then they will have to figure out how to cope with the double
calls (as your example highlight).
Here is the behavior Open MPI will stick too:
Fortran MPI -> C MPI
Fortran PMPI -> C MPI
However, the is another possible approach. This might avoid the double calls
while preserving the tool writers friendliness. This possible approach will do:
Fortran MPI -> C MPI
Fortran PMPI -> C PMPI
^
Unfortunately, we will have to heavily modify all files in the Fortran
interface layer in order to support this approach.
This commit was SVN r20079.
"make distclean". It's not clear whether it's an Automake bug or
whether what I did simply is not supported (I've got pending mail into
Ralf W. asking about it). The short version is that during "make
distclean", ompi/mpi/f77/Makefile would rm -rf ompi/mpi/f77/.deps.
But ompi/Makefile still include's some .Plo files from that directory,
so Bad Things happened when "make distclean" unrolled from the
ompi/mpi/f77 dir back up to the ompi/ dir.
So I went with George's original suggestion and moved the f77 "base"
files in question into a new directory: ompi/mpi/f77/base and put a
Makefile.include in there. That way, this directory is not traversed
twice by distclean, and .deps is only removed when it is supposed to
be. Maybe we'll be able to do it a little better someday, but that's
the way it is now.
I'll check this with a fresh checkout once this is committed to SVN as
well; some of these kinds of problems don't show up until you do a
build from a completely fresh SVN checkout.
This commit was SVN r19054.
The following SVN revision numbers were found above:
r19040 --> open-mpi/ompi@9f4d4c4312
are properly linked against libmpi.la.
This required a little creative AM usage, inspired by discussion on
OMPI devel list:
* Make a new ompi/mpi/f77/Makefile_f77base.include; effectively move
the building of the f77 "base" glue stuff (libmpi_f77base.la) into
this Makefile and away from ompi/mpi/f77/Makefile.am. The sources
in question require some specific CPPFLAGS, so we couldn't just add
the raw sources into libmpi_la_SOURCES, unfortunately.
* Include this new Makefile in the top-level ompi/Makefile.am
* The libmpi_f77base.la LT convenience library was already sucked
into libmpi.la; breaking it out into its own Makefile allows us
to build it earlier and therefore complete buidling libmpi.la
earlier.
* Side effect: the ompi/mpi/Makefile.am is now mostly unnecessary; it
no longer specifies a SUBDIRS for each of the bindings directories
to traverse into (since they are now in the top-level SUBDIRS). As
such, the man pages are now also now included in the top-level
ompi/Makefile.am.
The end of the result is that libmpi.la -- including a few sources
from mpi/f77 -- is fully built before the C++, F77, and F90 bindings
are built. Therefore, the C++, F77, and F90 bindings libraries can
all link against libmpi.la.
This commit was SVN r19040.
The following Trac tickets were found above:
Ticket 1409 --> https://svn.open-mpi.org/trac/ompi/ticket/1409
of strings. We mostly did the Right Things already; I simplified the
code a bit and also had us not write to more characters in the C
bindings than we're supposed to (per language in the MPI-2.1 spec).
Fixes trac:1238.
This commit was SVN r18705.
The following Trac tickets were found above:
Ticket 1238 --> https://svn.open-mpi.org/trac/ompi/ticket/1238
to *not* use the STL as well as removing the STL use from the error handler
routines. This was removing the STL from the C++ bindings (Solaris has 2
versions of the STL; if OMPI uses one and an MPI application wants to use
another, Bad Things happen).
The main idea is to wrap up the C++ callback function pointers and the user's
extra_state into our own struct that is passed as the extra_state to the C
keyval registration along with the intercept routines in intercepts.cc. When the
C++ intercepts are activated, they unwrap the user's callback and extra state
and call them.
This commit was SVN r17409.
added there on my last commit was wrong. This variable should be included
only once, and here is the right way of doing:
- if we have weak symbols we compile each file once, so the variable should
[always] get included.
- if we don't have weak symbols, then each file will get compiled multiple
times (if profiling is enabled). In this case include the variable only
when we build the generic layer (not the profile one).
This commit was SVN r16950.
only defined when we build the normal version (not in the profiling compilation step).
Make sure the conversion_null function compil in all cases.
This commit was SVN r16908.
This commit brings over all the work from the /tmp-public/datarep
branch. See commits r16855, r16859, r16860 for the highlights of what
was done.
This commit was SVN r16891.
The following SVN revisions from the original message are invalid or
inconsistent and therefore were not cross-referenced:
r16855
r16859
r16860
The following Trac tickets were found above:
Ticket 1029 --> https://svn.open-mpi.org/trac/ompi/ticket/1029
methods (in order of precedence):
1. #pragma ident <ident string> (e.g., Intel and Sun)
1. #ident <ident string> (e.g., GCC)
1. static const char ident[] = <ident string> (all others)
By default, the ident string used is the standard Open MPI version string. Only
the following libraries will get the embedded version strings (e.g., DSOs will
not):
* libmpi.so
* libmpi_cxx.so
* libmpi_f77.so
* libopen-pal.so
* libopen-rte.so
* Added two new configure options:
* `--with-package-name="STRING"` (defaults to "Open MPI username@hostname
Distribution"). `STRING` is displayed by `ompi_info` next to the "Package"
heading.
* `--with-ident-string="STRING"` (defaults to the standard Open MPI version
string - e.g., X.Y.Zr######). `%VERSION%` will expand to the Open MPI
version string if it is supplied to this configure option.
This commit was SVN r16644.
- If one wants to use this solution, remember to unload the project 'orte-restart' which is currently not working for Windows.
This commit was SVN r15680.
interface:
- Fix the handling of MPI_BOTTOM in various places
Update of r15030
- While being at it, handle MPI_IN_PLACE in the same way.
Convert OMPI_ADDR -> OMPI_F2C_BOTTOM
Convert OMPI_IN_PLACE -> OMPI_F2C_IN_PLACE
and have them converted before the actual call.
- Approved by George and tested with icc and simple f77 mpi-program and
with program by Daniel.
This commit was SVN r15129.
The following SVN revision numbers were found above:
r15030 --> open-mpi/ompi@15f9e58c68
The C++ bindings were not tracking keyvals properly -- they were
freeing some internal meta data when Free_keyval() was called, not
when the keyval was actually destroyed (keyvals are refcounted in the
C layer, just like all other MPI objects, because they can live for
long after their corresponding Free call is invoked). This commit
fixes this problem and several other things:
* Add infrastructure on the ompi_attribute_keyval_t for an "extra"
destructor pointer that will be invoked during the "real"
constructor (i.e., when OBJ_RELEASE puts the refcount to 0). This
allows calling back into the C++ layer to release meta data
associated with the keyval.
* Adjust all cases where keyvals are created to pass in relevant
destructors (NULL or the C++ destructor).
* Do essentially the same for MPI::Comm, MPI::Win, and MPI:Datatype:
* Move several functions out of the .cc file into the _inln.h file
since they no longer require locks
* Make the 4 Create_keyval() functions call a common back-end
keyval creation function that does the Right Thing depending on
whether C or C++ function pointers were used for the keyval
functions. The back-end function does not call the corresponding
C MPI_*_create_keyval function, but rather does the work itself
so that it can associate a "destructor" callback for the C++
bindings for when the keyval is actually destroyed.
* Change a few type names to be more indicative of what they are
(mostly dealing with keyvals [not "keys"]).
* Add the 3 missing bindings for MPI::Comm::Create_keyval().
* Remove MPI::Comm::comm_map (and associated types) because it's no
longer necessary in the intercepts -- it was a by-product of being
a portable C++ bindings layer. Now we can just query the C layer
directly to figure out what type a communicator is. This solves
some logistics / callback issues, too.
* Rename several types, variables, and fix many comments in the
back-end C attribute implementation to make the names really
reflect what they are (keyvals vs. attributes). The previous names
heavily overloaded the name "key" and were ''extremely''
confusing.
This commit was SVN r13565.
The following Trac tickets were found above:
Ticket 817 --> https://svn.open-mpi.org/trac/ompi/ticket/817
return the buffer address from Fortran. It is not expected
behavior. For MPI_Buffer_attach, adjust the address of
the buffer handed in so it is always aligned.
Refs trac:750
Buffer detach reviewed by Jeff Squyres
Buffer attach alignment reviewed by George Bosilca
This commit was SVN r13205.
The following Trac tickets were found above:
Ticket 750 --> https://svn.open-mpi.org/trac/ompi/ticket/750
MPI_Aint. On 64-bit big endian machines, these can have some unpleasent
issues.
Refs trac:734
This commit was SVN r13140.
The following Trac tickets were found above:
Ticket 734 --> https://svn.open-mpi.org/trac/ompi/ticket/734
The 2nd parameter in MPI_WIN_CREATE is actually an address integer,
not a regular integer. The F77 prototype for this function was wrong,
causing Bad Things on some 64 bit platforms (on other 64 bit
platforms, we just got lucky).
This commit was SVN r13133.
The following Trac tickets were found above:
Ticket 732 --> https://svn.open-mpi.org/trac/ompi/ticket/732
the value of __n holds. This is not a problem in the first case
because sizeof(int) == sizeof(MPI_Flogical), so no alloc is actually
performed (which is most compilers, and why we haven't been bitten by
this yet). But the second case -- where sizeof(int) !=
sizeof(MPI_Flogical) -- is definitely a problem and needs the "+1" in
the alloc, or Bad Things will happen.
This commit was SVN r12953.
The following SVN revision numbers were found above:
r12712 --> open-mpi/ompi@3e11c76d4c
OMPI_ARRAY_INT_2_LOGICAL had an array bounds error - fixed this and the
analogous error in OMPI_ARRAY_LOGICAL_2_INT.
This commit was SVN r12712.
The following Trac tickets were found above:
Ticket 482 --> https://svn.open-mpi.org/trac/ompi/ticket/482
case where sizeof(INTEGER) > sizeof(int).
This commit was SVN r12707.
The following SVN revision numbers were found above:
r12684 --> open-mpi/ompi@e2c605f32a
Ensure that the new predefined MPI-2 attribute callback functions take
the proper types (INTEGER, kind=MPI_ADDRESS_KIND instead of just
INTEGER).
This commit was SVN r12639.
The following Trac tickets were found above:
Ticket 624 --> https://svn.open-mpi.org/trac/ompi/ticket/624
* Add some more error checking to GREQUEST_START
* Move the error checking in GREQUEST_COMPLETE up to inside the
MPI_PARAM_CHECK block, where it belongs
* Invoke the gen request query_fn in all the Right spots (per MPI-2:8.2)
* Distinguish between grequests created from C and Fortran
* Use the OBJ system to reference count to release the grequest at
the Right time and invoke the grequest free_fn properly (see
lengthy comment in grequest.c above the destructor)
* Have ompi_grequest_complete() call ompi_request_complete() rather
than [poorly] copy the contents of ompi_request_complete()
* Fix Fortran function callback pointer typedefs to use proper
Fortran types
* Edit ompi_request_test* and ompi_request_wait* to properly handle
generalized requests. This adds an "if" statement in the critical
path for all the back-end test* and wait* functions :-(,
but fortunately George took out two "if" statements from the
critical path last week. So we're still ahead. :-)
* Move ompi_request_test() out of request.h and into request.c (all
other test* and wait* functions were already in the .c file -- and
ompi_request_test() was too long to be statically inlined anyway)
This commit was SVN r12402.
The following Trac tickets were found above:
Ticket 496 --> https://svn.open-mpi.org/trac/ompi/ticket/496
Doing pointer math properly (e.g., incrementing by the right amount)
helps you not overflow buffers, cause random chaos, and contribute to
the heat death of the universe. Sigh.
This commit was SVN r12015.
The following Trac tickets were found above:
Ticket 236 --> https://svn.open-mpi.org/trac/ompi/ticket/236
* Consolidate everything inside of the same AM_CONDITIONAL that is
used to suck in the glue convenience library in ompi/Makefile.am:
OMPI_WANT_F77_BINDINGS. This AM conditional is set to true if we
want (and can support) the F77 MPI API bindings at all (And does
not say anything about whether we are compiling the top-level or
bottom-level f77 directory to get the bindings).
* Clarify all the comments surrounding the [confusing!] issue.
* The problem with r11563 was that it used the wrong AM_CONDITIONAL
to decide whether to build the separate F77 library or not; it
would do so only if the top-level library was being built (e.g., on
systems like OSX where weak symbols don't work the way we need them
to). This patch somewhat simplifies the situation by encapsulating
everything in one large conditional (OMPI_WANT_F77_BINDINGS, as
described above). Hence, libmpi_f77 will exist (and be installed)
if F77 support is enabled overall, regardless of whether you're on
a system with insufficient weak symbol support (e.g., OSX) or not
(e.g., Linux).
This commit was SVN r11618.
The following SVN revision numbers were found above:
r11563 --> open-mpi/ompi@c8f3ff71b1
Had the wrong type for one of the arguments of MPI_TYPE_GET_CONTENTS
(MPI_Fint should have been MPI_Aint).
This commit was SVN r11517.
The following Trac tickets were found above:
Ticket 330 --> https://svn.open-mpi.org/trac/ompi/ticket/330
