configured with --disable-mpi-cxx so that the default -I flags in the
wrapper compilers don't point to a directory that doesn't exist.
Thanks to Martin Audet for identifying the problem.
This commit was SVN r13296.
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
to the F90 binding for MPI_INITIALIZED was wrong (should have been
logical, not integer).
Fixes trac:782.
This commit was SVN r13170.
The following Trac tickets were found above:
Ticket 782 --> https://svn.open-mpi.org/trac/ompi/ticket/782
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
to pass some of the tests provided by Sun. These will, of course, greatly
slow down calls to MPI_ACCUMULATE, but there's no way to pass the test
suite without them :/.
Refs trac:760
This commit was SVN r13117.
The following Trac tickets were found above:
Ticket 760 --> https://svn.open-mpi.org/trac/ompi/ticket/760
corrected in the MPI 2.0 errata.
* initialized some variables to make our sensitive sun compiler not to
not warn about them when user apps are compiling.
This commit was SVN r13058.
that a) STATUS[ES]_IGNORE *is* NULL, and b) ROMIO blindly sends its
status through to STATUS_SET_ELEMENTS, even if the status is IGNORE.
So we have some legal cases where IGNORE can be passed through here.
Well, that's what we get for trying to do good error checking. :-(
This commit was SVN r12999.
- Fix some fpritnf's in ompi_mpi_abort() that incorrectly assumed that
we were always being invoked from MPI_ABORT (ompi_mpi_abort() may be
invoked from a bunch of different places)
- Also try to opal_backtrace_print() if opal_bactrace_buffer() is not
supported.
- Print a message in MPI_ABORT if we're aborting.
This commit was SVN r12998.
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
* 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
add_error_class and add_error_code files. Also fixed the update of the
lastusedcode attribute, all of work according to my tests pretty fine.
Please note: the testcode attached to the bug 683 still reports some bugs. I
am however pretty sure that the testcode is wrong at that points:
- the standard says that the attribute MPI_LASTUSEDCODE has to be updated for
a new error_class or a new error_code. The test currently assumes, that only
the add_error_code call changes the attribute value.
- you have to comment out the two lines 73 and 74 in order to make the
test finish, since these lines check for the error string of non-existent
codes.
- line 126 the error-string of MPI_ERR_ARG is not "invalid argument" but a
little bit more, so the test thinks the output is wrong. So probably the test
has to be update to match the according error string of MPI_ERR_ARG.
Fixes trac:682
This commit was SVN r12913.
The following Trac tickets were found above:
Ticket 682 --> https://svn.open-mpi.org/trac/ompi/ticket/682
This commit fixes several aspects regarding MPI conformance of requests.
* Eliminate the last argument of ompi_errhandler_request_invoke(); we
''always'' want to invoke the back-end exception handler with the
real error code.
* Make it clear in comments that we only invoke the ''first''
exception in a given array of requests, even if there's more than
one request with a non-MPI_SUCCESS value for MPI_ERROR.
* Defer the freeing of requests upon exception in the back-end
functions to MPI_WAIT* and MPI_TEST* until later; the requests are
kept so that we know what handler to invoke when we actually invoke
the exception. After figuring that out, ''then'' we free requests
with pending exceptions on them.
* Clean up return codes from the back-end MPI_TEST* and MPI_WAIT*
functions.
* Slightly modify ompi_errcode_get_mpi_code() to return unity if it
receives an MPI error code (vs. an OMPI error code).
This commit was SVN r12810.
The following Trac tickets were found above:
Ticket 659 --> https://svn.open-mpi.org/trac/ompi/ticket/659
- we have to be able to attach a string to an error class, not just to an
error code
- according to MPI-2 the attribute MPI_LASTUSEDCODE has to be updated
everytime you add a new code or a new class. Thus, you have to have single
list for both.
Thus, we got rid of the error_class structure. In the error-code structure, we
can distinguish whether we are dealing with an error code or an error class by
looking at the err->code element of the structure. In case its value is
MPI_UNDEFINED, the according entry is a class, else it is an error code. All
predefined error codes have the code and the class field set to the same
value.
The test MPI_Add_error_class1 passes now.
Fixes trac:418
This commit was SVN r12764.
The following Trac tickets were found above:
Ticket 418 --> https://svn.open-mpi.org/trac/ompi/ticket/418
* Always invoke the error handler on MPI_COMM_WORLD for
invalid windows (except in win_create, which should
instead be on the given communicator).
* Allow get_errhandler in addition to set_errhandler
on MPI_WIN_NULL
Refs trac:647
This commit was SVN r12718.
The following Trac tickets were found above:
Ticket 647 --> https://svn.open-mpi.org/trac/ompi/ticket/647
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
* use one-sided datatype check instead of send/receive and check both
the origin and target datatypes
* allow error handler to be set on MPI_WIN_NULL, per standard
* Allow recursive calls into the pt2pt osc component's progress
function
* Fix an uninitialized variable problem in the unlock header
This commit was SVN r12667.
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
(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.
* Add MPI::Status methods Set_elements() and Set_cancelled()
* Added a bunch of comments in various places in the MPI C++ bindings
implementatio just to explain what's going on (because C++ can hide
a lot from you)
* Insert C++ callbacks for the MPI_Grequest callback functions
registered by MPI::Grequest::Start(). These callbacks keep a
little meta-data (created by Grequest::Start()) that allow the
proper callback signatures from C (i.e., from ompi_grequest_<foo>()
in libmpi.a -- C code), translate arguments as required, and then
invoke the callbacks with proper C++ signatures (i.e., call
user-defined callbacks with C++ function signatures).
This commit was SVN r12446.
The following Trac tickets were found above:
Ticket 580 --> https://svn.open-mpi.org/trac/ompi/ticket/580
size of the complex type as determined by configure; not the size of
the next larger complex type (i.e., a complex*N is 2 real*(N/2)'s, not
2 real*N's).
This commit was SVN r12421.
* 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
Had group discussion about this on the weekly call. The decision was
that we should pass the real error code to the back-end exception
handler because it's pretty useless to pass MPI_ERR_IN_STATUS to the
back-end exception handler (because exception handlers don't have
access to the request or the status - this has potential issues for
fault tolerance kinds of scenarios). So in TESTALL, TESTSOME,
WAITALL, and WAITSOME, we examine the error code and if it's not
MPI_SUCCESS, return MPI_ERR_IN_STATUS.
This commit was SVN r12389.
The following Trac tickets were found above:
Ticket 549 --> https://svn.open-mpi.org/trac/ompi/ticket/549
Have no idea why this function always returns a failure. It should
always return SUCCESS (provided the status is value).
This commit was SVN r12364.
The following Trac tickets were found above:
Ticket 496 --> https://svn.open-mpi.org/trac/ompi/ticket/496
* For MPI_TEST, MPI_TESTANY, MPI_WAIT, and MPI_WAITANY (i.e., the
TEST/WAIT functions that return up to exactly one completed
request), return the actual error code.
* For MPI_TESTALL, MPI_TESTSOME, MPI_WAITALL, MPI_WAITSOME, (i.e.,
the TEST/WAIT functions that can return more than one completed
request), return MPI_ERR_IN_STATUS.
This commit was SVN r12355.
The following Trac tickets were found above:
Ticket 549 --> https://svn.open-mpi.org/trac/ompi/ticket/549
This commit essentially caches the invoking comm/win/file on the
ompi_request_t. This, paired with the req_type field, allows us to
retrieve the invoking MPI object and invoke the proper errhandler.
The patch is missing most updates for the MPI-2 one-sided stuff (i.e.,
the patch mainly fixes comms and files); I didn't really understand
that code and didn't want to hazard trying to figure it out when Brian
can probably do it much more quickly.
So #250 will still stay open, pending MPI-2 one-sided updates for this
stuff.
This commit was SVN r12339.
The following Trac tickets were found above:
Ticket 250 --> https://svn.open-mpi.org/trac/ompi/ticket/250
* Create a new request type: NOOP (described below)
* For all MPI_*_INIT functions, OBJ_NEW an ompi_request_t and set its
type to NOOP
* Ensure that the NOOP requests are OBJ_RELEASE'd when they are done
* MPI_START looks at the request type; if NOOP, just return success. If
not, call the PML start() function
* MPI_STARTALL always pass the entire array of requests back to the PML
(see next point)
* Make the PMLs only process PML requests (i.e., ignore/skip anything
that isn't of type PML -- such as the NOOP requests)
* Add a little more param error checking in STARTALL
This commit was SVN r12338.
The following Trac tickets were found above:
Ticket 529 --> https://svn.open-mpi.org/trac/ompi/ticket/529
allocation logic is completely done outside the data-type engine (in the PML) there is
no need for any special case inside the data-type engine. There is less arguments for
the ompi_convertor_pack and ompi_convertor_unpack as well (the last field free_after is
not required anymore as there is no memory allocated in the engine itself). This change
affect all components using datatypes. I test most of them, but it might happens that I
miss some ... If it's the case please let me know (don't shoot the pianist!!).
This commit was SVN r12331.
all platforms. The only exceptions (and I will not deal with them
anytime soon) are on Windows:
- the write functions which require the length to be an int when it's
a size_t on all UNIX variants.
- all iovec manipulation functions where the iov_len is again an int
when it's a size_t on most of the UNIXes.
As these only happens on Windows, so I think we're set for now :)
This commit was SVN r12215.
size and diplacement of data-type. After this patch all data can contain size_t bytes
and the displacements are defined as ptrdiff_t. All of the files I was able to compile
have been modified to match this requirement.
This commit was SVN r12146.
* Update comments in some MPI_FILE_* functions to reflect that the
MPI specs have different page numbers in the ps and pdf (woof!).
* Update comments to say "Retain" where we meant retain (not "return)
* Add a check in MPI_ERRHANDLER_FREE to raise an MPI exception if the
user attempts to free an intrinsic errhandler *and* the refcount is
1 (meaning that it would actually free the intrinsic). This
protects erroneous programs from segv'ing.
* Remove lengthy comment from comm_get_errhandler.c which is no
longer valid (because of the MPI-2 errata that says that users *do*
have to call MPI_ERRHANDLER_FREE).
This commit was SVN r12128.
The following SVN revision numbers were found above:
r12122 --> open-mpi/ompi@407b3cb788
The following Trac tickets were found above:
Ticket 502 --> https://svn.open-mpi.org/trac/ompi/ticket/502
MPI::SEEK_* because iostreams (well, ios_base, but I don't think that
should be included directly) can use SEEK_* as values in an enum, which
means that 'const int' is bad for them.
* Remove now useless comments in the cxx example programs
* include iostream after mpi.h so that our examples work with other MPI
implementations that don't try to be as friendly with the constants.
Refs trac:387
This commit was SVN r12125.
The following Trac tickets were found above:
Ticket 387 --> https://svn.open-mpi.org/trac/ompi/ticket/387
* Fix MPI-2 page number in comments for a specific reference in the
spec
* Allow getting/setting the errhandler on MPI_FILE_NULL
* Allow freeing of intrinsic errhandlers, per MPI-2 errata (if you GET
an errhandler on a communicator, you must be able to FREE it, even
if it's an intrinsic).
Thanks to Lisandro Dalcin for reporting these problems.
This commit was SVN r12122.
some issues with the C #defines SEEK_{SET, END, POS}. The workaround
involves some hackery that should work in almost every common use case
for the C stdio constants (and all the legal issues of the MPI constants).
The one issue is that the C stdio constants are now const ints instead
of #defines, which means that #ifdef checks will fail for the constants.
Behavior can be disabled at either configure time or build time.
Refs trac:387
This commit was SVN r12121.
The following Trac tickets were found above:
Ticket 387 --> https://svn.open-mpi.org/trac/ompi/ticket/387
where a window was in both the passive and active side of a lock sequence.
Refs trac:488
This commit was SVN r12112.
The following Trac tickets were found above:
Ticket 488 --> https://svn.open-mpi.org/trac/ompi/ticket/488
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
recvbuf in MPI_GATHER).
* Minor style updates (constants on the left of == and !=)
* Fix a minor buglet that crept in r11904: had a recvbuf where it
should have been recvcount. Thankfully, this would have only
affected erroneous programs. ;-)
This commit was SVN r11980.
The following SVN revision numbers were found above:
r11904 --> open-mpi/ompi@17539dc154
The following Trac tickets were found above:
Ticket 338 --> https://svn.open-mpi.org/trac/ompi/ticket/338
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.
with the other methodology even if there are no choice buffers and no
special constants. But it keeps the Makefile.am simple and the
methodology consistent.
This commit was SVN r10462.
was that declaring the type of MPI_WTICK and MPI_TIME in mpif-common.h
would allow the F90 bindings to call through to the back end f77
function and have the right return type. But upon reflection, that's
silly -- we were just declaring the variables MPI_WTICK and MPI_WTIME
that were of type double precision. Duh.
So add some fixed (non-generated) wrapper F90 functions to call the
back-end *C* MPI_WTICK and MPI_TIME functions (vs. the back end *F77*
functions). We have to call the back-end C functions because there's
a name conflict if we try to call the back-end F77 functions -- for
the same reasons that we can't "implicitly" define MPI_WTIME and
MPI_WTICK in the f90 module, we can't call such an implicitly-defined
function. So we had to add new back-end C functions that are directly
callable from Fortran, the easiest implementation of which was to
provide 4 one-line functions for each (rather than muck around with
weak symbols).
This commit was SVN r10448.
with the last one was that the resized function only set the soft lb and ub
markers without actually moving the usefull data up to the correct
displacement. Using a struct instead solve the problem. Anyway, as defined
in the MPI standard we have to set the lower bound and the upper bound
of the new type to the correct values too.
This commit was SVN r10328.
MPI_FILE_GET_INFO should return the info currently in use, not the one
used to create the file handle. ROMIO adds a bunch of keys, so you can
create a file handle with MPI_INFO_NULL and have MPI_FILE_GET_INFO return
something totatlly different.
This commit was SVN r10312.
* Change the type of Fortan's MPI_STATUSES_IGNORE to double complex
so that it will never possibly be mistaken for a real status (i.e.,
integer(MPI_STATUS_SIZE)), particularly in the F90 bindings. See
comment in mpif-common.h explaining this (analogous argument to
MPI_ARGVS_NULL for MPI_COMM_SPAWN_MULTIPLE).
* Add second interfaces for the following functions that take a double
complex (i.e., MPI_STATUSES_IGNORE). This required adding the second
interface in mpi-f90-interfaces.h[.sh] and then generating new wrapper
functions to call the back-end F77 function for each of these four, so
we added 4 new files in ompi/mpi/f90/scripts/ and updated the various
Makefile.am's to match:
* MPI_TESTALL
* MPI_TESTSOME
* MPI_WAITALL
* MPI_WAITSOME
The XSL is now not in sync with the scripts. Although I suppose that
that is becoming less and less important (because it does not impact
the end user at all -- to be 100% explicit, no release should ever be
held up because the XSL is out of sync), but it will probably be
important when we go to fix the "large" interface; so it's still worth
fixing... for now...
This commit was SVN r10281.
- Make the F90 bindings compile and link properly with gfortran 4.0,
4.1, Intel 9.0, PGI 6.1, Sun (don't know version offhand -- the most
current as of this writing, I think), and NAG 5.2, although some
have limitations (e.g., NAG can't seem to handle the medium and
large sizes)
- Building the F90 "small" module size is now the default, even for
developers
- Split up mpif.h into multiple files because parts of it were toxic
to the F90 bindings
- Properly specify unsized/unshaped arrays to make the bindings work
on all known compilers
- Make ompi_info show Fortran 90 bindings size
- XML somewhat lags the generated scripts as of this commit, but
functionality was my main goal -- the XML can be updated later (if
at all).
This commit was SVN r10118.
- split mpif.h into mpif.h and mpif-common.h[.in]
- mpif-common.h is included by various f90 things and contains output
from configure
- mpif.h defines some f77-specific stuff and then includes
mpif-common.h
This commit was SVN r9997.
comment in ompi_comm_invalid() in
source:/trunk/ompi/communicator/communicator.h.
Short version:
- ompi_comm_invalid() returns TRUE for MPI_COMM_NULL
- therefore MPI_COMM_C2F needs to explicitly check for MPI_COMM_NULL
(because it uses ompi_comm_invalid())
- make ~20 MPI functions only call ompi_comm_invalid() instead of
calling ompi_comm_invalid() *and* checking for MPI_COMM_NULL (~40 MPI
functions already only called ompi_comm_invalid() -- we should be
consistent)
- similar issue for ompi_win_invalid(), so I added a cross-referencing
comment in win.h and fixed MPI_WIN_SET_NAME to only call
ompi_win_invalid() (and not check for MPI_WIN_NULL)
This commit was SVN r9970.
