we now have 12 cases to deal (4 writers and 3 readers) :
1. C `void*` is written into the attribute value, and the value is read into a C `void*` (unity)
2. C `void*` is written, Fortran `INTEGER` is read
3. C `void*` is written, Fortran `INTEGER(KIND=MPI_ADDRESS_KIND)` is read
4. Fortran `INTEGER` is written, C `void*` is read
5. Fortran `INTEGER` is written, Fortran `INTEGER` is read (unity)
6. Fortran `INTEGER` is written, Fortran `INTEGER(KIND=MPI_ADDRESS_KIND)` is read
7. Fortran `INTEGER(KIND=MPI_ADDRESS_KIND)` is written, C `void*` is read
8. Fortran `INTEGER(KIND=MPI_ADDRESS_KIND)` is written, Fortran `INTEGER` is read
9. Fortran `INTEGER(KIND=MPI_ADDRESS_KIND)` is written, Fortran `INTEGER(KIND=MPI_ADDRESS_KIND)` is read (unity)
10. Intrinsic is written, C `void*` is read
11. Intrinsic is written, Fortran `INTEGER` is read
12. Intrinsic is written, Fortran `INTEGER(KIND=MPI_ADDRESS_KIND)` is read
MPI-2 Fortran "integer representation" has type `INTEGER(KIND=MPI_ADDRESS_KIND)` as clarified
at https://github.com/mpiwg-rma/rma-issues/issues/1
Signed-off-by: Gilles Gouaillardet <gilles@rist.or.jp>
Without this, an attribute copy function could return non-success, but
it would not be propagated upwards. This caused the intel
MPI_Keyval3_* tests to fail.
cmr=v1.8:reviewer=hjelmn
This commit was SVN r31147.
MPI_COMM_SELF in reverse order during MPI_FINALIZE (well, actually,
''all'' attributes are now deleted in reverse order whenever a
communicator is destructed).
Also revamped a few things in the MPI attribute implementation:
* use a One Big Lock philosophy for making the implementation thread
safe (vs. the pair of locks we were using before). One Big Lock is
quite a bit simpler and has fewer corner cases; the code for
attributes is still complicated, but is definitely less complex
than it used to be.
* The COPY_ATTR_CALLBACKS and DELETE_ATTR_CALLBACKS macros no longer
return; they simply set a value if something went wrong. Then we
check this value after the macros complete. This simplifies
unlocking, etc.
* Added write barriers right before releasing locks to ensure memory
consistency.
* Fixed a bunch of typos in comments, and some indenting.
Many thanks to KAWASHIMA Takahiro who contributed the original patch
for attribute destruction ordering, and who helped test/debug/evolve
the patch to its final form.
Fixes trac:3123.
cmr:v1.7.2:reviewer=bosilca
This commit was SVN r28439.
The following Trac tickets were found above:
Ticket 3123 --> https://svn.open-mpi.org/trac/ompi/ticket/3123
1. New mpifort wrapper compiler: you can utilize mpif.h, use mpi, and use mpi_f08 through this one wrapper compiler
1. mpif77 and mpif90 still exist, but are sym links to mpifort and may be removed in a future release
1. The mpi module has been re-implemented and is significantly "mo' bettah"
1. The mpi_f08 module offers many, many improvements over mpif.h and the mpi module
This stuff is coming from a VERY long-lived mercurial branch (3 years!); it'll almost certainly take a few SVN commits and a bunch of testing before I get it correctly committed to the SVN trunk.
== More details ==
Craig Rasmussen and I have been working with the MPI-3 Fortran WG and Fortran J3 committees for a long, long time to make a prototype MPI-3 Fortran bindings implementation. We think we're at a stable enough state to bring this stuff back to the trunk, with the goal of including it in OMPI v1.7.
Special thanks go out to everyone who has been incredibly patient and helpful to us in this journey:
* Rolf Rabenseifner/HLRS (mastermind/genius behind the entire MPI-3 Fortran effort)
* The Fortran J3 committee
* Tobias Burnus/gfortran
* Tony !Goetz/Absoft
* Terry !Donte/Oracle
* ...and probably others whom I'm forgetting :-(
There's still opportunities for optimization in the mpi_f08 implementation, but by and large, it is as far along as it can be until Fortran compilers start implementing the new F08 dimension(..) syntax.
Note that gfortran is currently unsupported for the mpi_f08 module and the new mpi module. gfortran users will a) fall back to the same mpi module implementation that is in OMPI v1.5.x, and b) not get the new mpi_f08 module. The gfortran maintainers are actively working hard to add the necessary features to support both the new mpi_f08 module and the new mpi module implementations. This will take some time.
As mentioned above, ompi/mpi/f77 and ompi/mpi/f90 no longer exist. All the fortran bindings implementations have been collated under ompi/mpi/fortran; each implementation has its own subdirectory:
{{{
ompi/mpi/fortran/
base/ - glue code
mpif-h/ - what used to be ompi/mpi/f77
use-mpi-tkr/ - what used to be ompi/mpi/f90
use-mpi-ignore-tkr/ - new mpi module implementation
use-mpi-f08/ - new mpi_f08 module implementation
}}}
There's also a prototype 6-function-MPI implementation under use-mpi-f08-desc that emulates the new F08 dimension(..) syntax that isn't fully available in Fortran compilers yet. We did that to prove it to ourselves that it could be done once the compilers fully support it. This directory/implementation will likely eventually replace the use-mpi-f08 version.
Other things that were done:
* ompi_info grew a few new output fields to describe what level of Fortran support is included
* Existing Fortran examples in examples/ were renamed; new mpi_f08 examples were added
* The old Fortran MPI libraries were renamed:
* libmpi_f77 -> libmpi_mpifh
* libmpi_f90 -> libmpi_usempi
* The configury for Fortran was consolidated and significantly slimmed down. Note that the F77 env variable is now IGNORED for configure; you should only use FC. Example:
{{{
shell$ ./configure CC=icc CXX=icpc FC=ifort ...
}}}
All of this work was done in a Mercurial branch off the SVN trunk, and hosted at Bitbucket. This branch has got to be one of OMPI's longest-running branches. Its first commit was Tue Apr 07 23:01:46 2009 -0400 -- it's over 3 years old! :-) We think we've pulled in all relevant changes from the OMPI trunk (e.g., Fortran implementations of the new MPI-3 MPROBE stuff for mpif.h, use mpi, and use mpi_f08, and the recent Fujitsu Fortran patches).
I anticipate some instability when we bring this stuff into the trunk, simply because it touches a LOT of code in the MPI layer in the OMPI code base. We'll try our best to make it as pain-free as possible, but please bear with us when it is committed.
This commit was SVN r26283.
Roll in the ORTE state machine. Remove last traces of opal_sos. Remove UTK epoch code.
Please see the various emails about the state machine change for details. I'll send something out later with more info on the new arch.
This commit was SVN r26242.
logic back (that was replaced by r25965 and r26000) and fix the one
place that missed OMPI_LOGICAL_2_INT. This missing OMPI_LOGICAL_2_INT
was the real problem.
This commit was SVN r26053.
The following SVN revision numbers were found above:
r25965 --> open-mpi/ompi@b10ebf4b2d
r26000 --> open-mpi/ompi@90811cb50c
defensive about the check of the flag value for the C-based keyvals.
We would never have had a problem because of the specific input data,
but being defensive is good (and it makes the code a little less
subtle / easier to read).
Also add in more comments about exactly what is going on, since this
is complicated stuff. :-)
This commit was SVN r26000.
MPI started!).
The FLAG argument to fortran attribute copy functions is a LOGICAL,
meaning that it can only return .TRUE. or .FALSE. The corresponding C
argument is an int, and the MPI spec says that it must return 1 or 0.
However, in Fortran, .TRUE. is not always necessarily == 1. So we
need to expand the test to see if it's a Fortran callback. If so,
check for the Fortran .TRUE. value (not 1). If it's a C callback,
then check for 1.
This commit was SVN r25965.
(OMPI_ERR_* = OPAL_SOS_GET_ERR_CODE(ret)), since the return value could be a
SOS-encoded error. The OPAL_SOS_GET_ERR_CODE() takes in a SOS error and returns
back the native error code.
* Since OPAL_SUCCESS is preserved by SOS, also change all calls of the form
(OPAL_ERROR == ret) to (OPAL_SUCCESS != ret). We thus avoid having to
decode 'ret' to get the native error code.
This commit was SVN r23162.
OMPI
and a language agnostic part in OPAL. The convertor is completely
moved into OPAL. This offers several benefits as described in RFC
http://www.open-mpi.org/community/lists/devel/2009/07/6387.php
namely:
- Fewer basic types (int* and float* types, boolean and wchar
- Fixing naming scheme to ompi-nomenclature.
- Usability outside of the ompi-layer.
- Due to the fixed nature of simple opal types, their information is
completely
known at compile time and therefore constified
- With fewer datatypes (22), the actual sizes of bit-field types may be
reduced
from 64 to 32 bits, allowing reorganizing the opal_datatype
structure, eliminating holes and keeping data required in convertor
(upon send/recv) in one cacheline...
This has implications to the convertor-datastructure and other parts
of the code.
- Several performance tests have been run, the netpipe latency does not
change with
this patch on Linux/x86-64 on the smoky cluster.
- Extensive tests have been done to verify correctness (no new
regressions) using:
1. mpi_test_suite on linux/x86-64 using clean ompi-trunk and
ompi-ddt:
a. running both trunk and ompi-ddt resulted in no differences
(except for MPI_SHORT_INT and MPI_TYPE_MIX_LB_UB do now run
correctly).
b. with --enable-memchecker and running under valgrind (one buglet
when run with static found in test-suite, commited)
2. ibm testsuite on linux/x86-64 using clean ompi-trunk and ompi-ddt:
all passed (except for the dynamic/ tests failed!! as trunk/MTT)
3. compilation and usage of HDF5 tests on Jaguar using PGI and
PathScale compilers.
4. compilation and usage on Scicortex.
- Please note, that for the heterogeneous case, (-m32 compiled
binaries/ompi), neither
ompi-trunk, nor ompi-ddt branch would successfully launch.
This commit was SVN r21641.
not end up in OPAL
- Will post an updated patch for the OMPI_ALIGNMENT_ parts (within C).
This commit was SVN r21342.
The following SVN revision numbers were found above:
r21330 --> open-mpi/ompi@95596d1814
into the OPAL namespace, eliminating cases like opal/util/arch.c
testing for ompi_fortran_logical_t.
As this is processor- and compiler-related information
(e.g. does the compiler/architecture support REAL*16)
this should have been on the OPAL layer.
- Unifies f77 code using MPI_Flogical instead of opal_fortran_logical_t
- Tested locally (Linux/x86-64) with mpich and intel testsuite
but would like to get this week-ends MTT output
- PLEASE NOTE: configure-internal macro-names and
ompi_cv_ variables have not been changed, so that
external platform (not in contrib/) files still work.
This commit was SVN r21330.
This has turned into an MPI spec interpretation issue. :-(
Open MPI has intrepreted the spec one way for the past several years;
these commits reflect a different interpretation that changes how we
treat the EXTRA_STATE parameter to the Fortran attribute copy and
delete callbacks. This new way breaks our internal copy of the Intel
Fortran attribute tests. So after talking with Terry/Sun, we're going
to back out these changes (both here and on the v1.3 branch) until we
get further clarification from the Forum.
This commit was SVN r21028.
The following SVN revision numbers were found above:
r20926 --> open-mpi/ompi@0a24eadaad
r20941 --> open-mpi/ompi@045b0e8871
r20950 --> open-mpi/ompi@73af921c22
The fix for #1864 in r20926 caused gcc to emit some warnings. Also,
Jeff Squyres pointed out parallel bugs in mpi_type_create_keyval and
mpi_win_create_keyval.
This commit was SVN r20950.
The following SVN revision numbers were found above:
r20926 --> open-mpi/ompi@0a24eadaad
The EXTRA_STATE parameter is passed by reference, and thus should be
dereferenced before it is stored. Similarly, the stored value should
be passed by reference to the copy and delete routines.
This fixes trac:1864.
This commit was SVN r20926.
The following Trac tickets were found above:
Ticket 1864 --> https://svn.open-mpi.org/trac/ompi/ticket/1864
opal layer.
Add a check against a maximum (actually get rid of ifs internally to
opal_bitmap.c) -- the functionality to set the current maximum size
opal_bitmap_set_max_size() is currently only used in attribute.c
to set the maximum OMPI_FORTRAN_HANDLE_MAX...
Tested on linux/x86-64 with intel-tests with all_tests_no_perf_f
run with 6 procs.
Let's look into MTT as well...
This commit was SVN r20708.
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.
single threaded builds. In its default configuration, all this does
is ensure that there's at least a good chance of threads building
based on non-threaded development (since the variable names will be
checked). There is also code to make sure that a "mutex" is never
"double locked" when using the conditional macro mutex operations.
This is off by default because there are a number of places in both
ORTE and OMPI where this alarm spews mega bytes of errors on a
simple test. So we have some work to do on our path towards
thread support.
Also removed the macro versions of the non-conditional thread locks,
as the only places they were used, the author of the code intended
to use the conditional thread locks. So now you have upper-case
macros for conditional thread locks and lowercase functions for
non-conditional locks. Simple, right? :).
This commit was SVN r15011.
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
* Fix for two problems introduced by r10661:
1. ensure to use the key ''after'' it is initialized (sigh).
1. handle the case where we free the attrkey before it is fully
initialized (i.e., some other error causes us to free it). In
this case, don't try to remove the key from the hash map,
because it won't exist.
* More accurate zeroing in the keyval constructor
(ompi_attrkey_item_constructor)
* Widen the scope of the alock such that the attrkey destructor does
not need to acquire it. Instead, assume that the caller already
has it.
* Add a comment about why the keyval may get destroyed as the result
of deleting an attribute (so that I don't have to figure it out
again the next time I read this code :-) )
This commit was SVN r10664.
The following SVN revision numbers were found above:
r10661 --> open-mpi/ompi@fdba2c9df0
thread safety. This is likely to be only the first of multiple steps
for complete thread safety in the MPI attribute code. All tests
[continue to] pass the intel and ibm attribute tests.
Also renamed a variable from "attr" to "attrkey" to reflect that it's
a keyval, not an attribute.
This commit was SVN r10661.
to use the appropriate macro for all the Fortran .TRUE. handling, or
things get misinterpeted and, with some compilers, it will look like
the attribute wasn't copied properly.
This commit was SVN r9536.
is the last one on the list and as on C the caller "make it right" this addition
will not affect the way we handle the user defined copy functions. Only the C
version of the function has this additional parameter. As it represent the pointer
to the newly created MPI object It hold the key to allow us to modify the new
object (communicator, window or type) depending on some key stored on the initial
communicator.
This commit was SVN r9371.
- move files out of toplevel include/ and etc/, moving it into the
sub-projects
- rather than including config headers with <project>/include,
have them as <project>
- require all headers to be included with a project prefix, with
the exception of the config headers ({opal,orte,ompi}_config.h
mpi.h, and mpif.h)
This commit was SVN r8985.
complete, but stable enough that it will have no impact on general development,
so into the trunk it goes. Changes in this commit include:
- Remove the --with option for disabling MPI-2 onesided support. It
complicated code, and has no real reason for existing
- add a framework osc (OneSided Communication) for encapsulating
all the MPI-2 onesided functionality
- Modify the MPI interface functions for the MPI-2 onesided chapter
to properly call the underlying framework and do the required
error checking
- Created an osc component pt2pt, which is layered over the BML/BTL
for communication (although it also uses the PML for long message
transfers). Currently, all support functions, all communication
functions (Put, Get, Accumulate), and the Fence synchronization
function are implemented. The PWSC active synchronization
functions and Lock/Unlock passive synchronization functions are
still not implemented
This commit was SVN r8836.
