with the use of MPI_IN_PLACE, and make some optimization checks more
correct. Thanks to Lisandro Dalcin for reporting the problems.
This commit was SVN r11904.
The following Trac tickets were found above:
Ticket 430 --> https://svn.open-mpi.org/trac/ompi/ticket/430
groups. And zero is also an acceptable value according to the MPI spec.
Fixes trac:428
This commit was SVN r11841.
The following Trac tickets were found above:
Ticket 428 --> https://svn.open-mpi.org/trac/ompi/ticket/428
Fixes simple off-by-one error in the error check for
MPI_INFO_GET_NTHKEY.
This commit was SVN r11838.
The following Trac tickets were found above:
Ticket 429 --> https://svn.open-mpi.org/trac/ompi/ticket/429
Makefile.am's is from a very old Automake bug which has long-since
been fixed. Since we require very recent versions of AM, we don't
need these anymore.
This commit was SVN r11774.
* 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
* Print a warning error message if a target is not in an exposure epoch
and an update is received. This results in the app continuing with
that call having never happened, rather than evil hangs.
refs trac:325
This commit was SVN r11514.
The following Trac tickets were found above:
Ticket 325 --> https://svn.open-mpi.org/trac/ompi/ticket/325
to return the value on seconds not some other unit based on the resolution
of MPI_Wtick. Which I think it's the wrong solution, as instead of forcing
the user to do additional computations in order to convert when he needs
the result in seconds, force us to convert every time. Unfortunately,
converting requires a division with a double which is a costly
operation. But, MPI is a standard and we have to follow it ...
This commit was SVN r11481.
strings. Here's one: no matter how much of the string you copy, the
destination string must be space-padded for the entire remaining area.
Specifically, even if you call MPI_INFO_GET and tell MPI to only copy
a max of N characters of the value into the result string, if the
Fortran string is M characters (where M > N), MPI must space-pad the
remaining (M-N) characters to be spaces. So you're supposed to obey
the argument to MPI_INFO_GET... sorta.
Precedents:
* http://www.ibiblio.org/pub/languages/fortran/ch2-13.html
* LAM/MPI
* Sun CT MPI
This commit was SVN r11412.
convert between fortran and C string representations properly. In
doing so, we properly adhere to the MPI spec stating that MPI_Info
keys and values must be whitespace-trimmed when coming in from
Fortran. Hence, this fixes bug #241.
This commit was SVN r11356.
of 4 when we are finding the next MPI_STATUS in the array.
Refs trac:236
This commit was SVN r11332.
The following Trac tickets were found above:
Ticket 236 --> https://svn.open-mpi.org/trac/ompi/ticket/236
(but didn't use it), but MPI_TYPE_GET_NAME and MPI_WIN_GET_NAME did
not.
This commit changes all three functions to pass the compile-added
string length parameter to clear out the remainder of the string with
spaces (i.e., the rest of the string that was not set with the name).
This is what was done in LAM/MPI, and apparently what was done in
Sun's MPI, because the test that Rolf attached now passes.
Fixes trac:274.
This commit was SVN r11301.
The following Trac tickets were found above:
Ticket 274 --> https://svn.open-mpi.org/trac/ompi/ticket/274
that the compiler might need to inform the compiler that a .f90 extension
means "this is Fortran 90 code". Fortran compilers are so weird.
refs trac:284
This commit was SVN r11280.
The following Trac tickets were found above:
Ticket 284 --> https://svn.open-mpi.org/trac/ompi/ticket/284
releases on Linux and OS X) don't handle const_cast<> of 2-dimensional
arrays properly. If we're using one of the compilers that isn't friendly
to such casts, fall back to a standard C-style cast.
refs: #271
This commit was SVN r11263.
full argument checking (allowing that MPI_PROC_NULL is legal, of course).
Only after the argument checking do we shortcut. Fixes trac:237, which
was caused by moving the MPI_PROC_NULL test in MPI_Bsend_init,
but not allowing for MPI_PROC_NULL when checking rank.
This commit was SVN r11108.
The following SVN revision numbers were found above:
r10972 --> open-mpi/ompi@31c66d92aa
The following Trac tickets were found above:
Ticket 237 --> https://svn.open-mpi.org/trac/ompi/ticket/237
on almost all platforms (except OS X... sigh...). This is the merge
of r10846 - 10894 from the tmp/f90-shared branch to the trunk.
This commit was SVN r11103.
The following SVN revisions from the original message are invalid or
inconsistent and therefore were not cross-referenced:
r10846
users mailing list:
http://www.open-mpi.org/community/lists/users/2006/07/1680.php
Warning: this log message is not for the weak. Read at your own
risk.
The problem was that we had several variables in Fortran common blocks
of various types, but their C counterparts were all of a type
equivalent to a fortran double complex. This didn't seem to matter
for the compilers that we tested, but we never tested static builds
(which is where this problem seems to occur, at least with the Intel
compiler: the linker compilains that the variable in the common block
in the user's .o file was of one size/alignment but the one in the C
library was a different size/alignment).
So this patch fixes the sizes/types of the Fortran common block
variables and their corresponding C instantiations to be of the same
sizes/types.
But wait, there's more.
We recently introduced a fix for the OSX linker where some C versions
of the fortran common block variables (e.g.,
_ompi_fortran_status_ignore) were not being found when linking
ompi_info (!). Further research shows that the code path for
ompi_info to require ompi_fortran_status_ignore is, unfortunately,
necessary (a quirk of how various components pull in different
portions of the code base -- nothing in ompi_info itself requires
fortran or MPI knowledge, of course).
Hence, the real problem was that there was no code path from ompi_info
to the portion of the code base where the C globals corresponding to
the Fortran common block variables were instantiated. This is because
the OSX linker does not automatically pull in .o files that only
contain unintialized global variables; the OSX linker typically only
pulls in a .o file from a library if it either has a function that is
used or have a global variable that is initialized (that's the short
version; lots of details and corner cases omitted). Hence, we changed
the global C variables corresponding to the fortran common blocks to
be initialized, thereby causing the OSX linker to pull them in
automatically -- problem solved. At the same time, we moved the
constants to another .c file with a function, just for good measure.
However, this didn't really solve the problem:
1. The function in the file with the C versions of the fortran common
block variables (ompi/mpi/f77/test_constants_f.c) did not have a
code path that was reachable from ompi_info, so the only reason
that the constants were found (on OSX) was because they were
initialized in the global scope (i.e., causing the OSX compiler to
pull in that .o file).
2. Initializing these variable in the global scope causes problems for
some linkers where -- once all the size/type problems mentioned
above were fixed -- the alignments of fortran common blocks and C
global variables do not match (even though the types of the Fortran
and C variables match -- wow!). Hence, initializing the C
variables would not necessarily match the alignment of what Fortran
expected, and the linker would issue a warning (i.e., the alignment
warnings referenced in the original post).
The solution is two-fold:
1. Move the Fortran variables from test_constants_f.c to
ompi/mpi/runtime/ompi_mpi_init.c where there are other global
constants that *are* initialized (that had nothing to do with
fortran, so the alignment issues described above are not a factor),
and therefore all linkers (including the OSX linker) will pull in
this .o file and find all the symbols that it needs.
2. Do not initialize the C variables corresponding to the Fortran
common blocks in the global scope. Indeed, never initialize them
at all (because we never need their *values* - we only check for
their *locations*). Since nothing is ever written to these
variables (particularly in the global scope), the linker does not
see any alignment differences during initialization, but does make
both the C and Fortran variables have the same addresses (this
method has been working in LAM/MPI for over a decade).
There were some comments here in the OMPI code base and in the LAM
code base that stated/implied that C variables corresponding to
Fortran common blocks had to have the same alignment as the Fortran
common blocks (i.e., 16). There were attempts in both code bases to
ensure that this was true. However, the attempts were wrong (in both
code bases), and I have now read enough Fortran compiler documentation
to convince myself that matching alignments is not required (indeed,
it's beyond our control). As long as C variables corresponding to
Fortran common blocks are not initialized in the global scope, the
linker will "figure it out" and adjust the alignment to whatever is
required (i.e., the greater of the alignments). Specifically (to
counter comments that no longer exist in the OMPI code base but still
exist in the LAM code base):
- there is no need to make attempts to specially align C variables
corresponding to Fortran common blocks
- the types and sizes of C variables corresponding to Fortran common
blocks should match, but do not need to be on any particular
alignment
Finally, as a side effect of this effort, I found a bunch of
inconsistencies with the intent of status/array_of_statuses
parameters. For all the functions that I modified they should be
"out" (not inout).
This commit was SVN r11057.
Reviewed by: Jeff Squyres
Fix for ticket #220. Missing a few C++ methods.
MPI::Datatype::Create_indexed_block
MPI::Datatype::Create_resize
MPI::Datatype::Get_true_extent
This commit was SVN r11010.
functions MPI_Test, MPI_Testany, MPI_Wait, MPI_Waitany
should not reset the status.MPI_ERROR as passed by user.
- This needed implementing the MPI_Waitsome and MPI_Testsome.
This commit was SVN r10980.
- bsend_init: use *request after error-checking
- Always reset the status->cancelled
- cancel, wait: need to check *request for MPI_REQUEST_NULL, not
NULL...
(actually ompi_request_wait handles MPI_PROC_NULL, so no need
to check&set of status_empty in wait.c)
This commit was SVN r10972.
- ensure to initialize the values that we use for fortran constants
(even tough their *values* don't matter -- only their *addresses* do,
but initializing them or not has implications for the OSX linker)
- move the fortran constants to a file with functions in it, because
the OSX linker sometimes does not import global variables from
object files that do not have functions (I'm not even going to
pretend to get all the subtle details about the OSX linker right
here -- it's just "better" to have global variables in object files
with functions that otherwise get pulled in during linker
resolution).
This commit was SVN r10908.
SPAWN[_MULTIPLE] from a singleton (and displays a pretty help message
explaining that you need to use mpirun). This can be removed when
fixes for ORTE come over that allow SPAWN[_MULTIPLE] from singletons.
This commit was SVN r10898.
