status that we get (which naturally returns 0 if all return 0). This
should pick up nonzero returns from main() after MPI_FINALIZE, but the
gpr is still reporting 0 while testing. So orterun looks cororect for
this behavior -- investigating what's happening on the ORTE side is a
different commit...
This commit was SVN r5521.
- After consulting with George, only define the fortran types if the
back end Fortran compiler actually supports them. We always have
the corresponding global C datatypes, but it seems nicer user
behavior to have them fail at compile time rather than at run time
if they try to use MPI_INTEGER8 and it doesn't exist (in which case
ompi_mpi_integer8 will be a synonym for ompi_mpi_datatype_null)
This commit was SVN r5520.
MPI_COMPLEX*x, and some optional C datatypes in MPI reduction
operations. These types are not technically supported by the letter
of the MPI standard, but are implied by the spirit of it (and there
are definitely users that use them in real applications)
- Add checks in configure for back-end C types for MPI_INTEGER*x and
MPI_REAL*x
- Create C data structs for MPI_COMPLEX*x
- Fixed typo for MPI_INTEGER8 in mpi.h
- Updated configure macros to create MPI_FORTRAN_INTEGER* defines, as
opposed to MPI_FORTRAN_INT, which was causing [me] lots of confusion
(between C "*_INT" names and Fortran "*_INT" names). This caused
some trivial updates in ddt, ompi_info, and the MPI layer to match.
- Update ompi_info to show whether we have each MPI_INTEGER*x,
MPI_REAL*x, and MPI_COMPLEX*x
- Extended reduction operations for optional datatypes:
- "C integer" now includes long long int, long long, and unsigned
long long
- "Fortran integer" now includes MPI_INTEGER*x
- "Floating point" now includes MPI_REAL*x
- "Complex" now includes MPI_COMPLEX*x
This commit was SVN r5511.
the whole datatype code, make it a little bit more readable and add some
additional checks for correctness. In same time I move some internal structures
from the external .h include to the internal one.
The ddt_test.c get one more datatype to test. This one look like those used
in the BLACS test code.
This commit was SVN r5498.
since you can't fork() in one thread and waitpid() on the child in another,
which is what this test expects you to do. If Linux would just implement
the stupid POSIX standard already, this wouldn't be a problem.
This commit was SVN r5482.
ompi_progress, unless someone is actually using it (MPI-2 dynamic,
TCP PTL). This is only for end of MPI_Init to start of MPI_Finalize.
All other times, the event library will be progressed every call
into ompi_progress().
This commit was SVN r5479.
was getting confused with the recent addition of "-lutil" to get the
system-level libutil (i.e., Libtool was confusing the two and doing
Bad Things).
This commit was SVN r5467.
Ralf W (core libtool developer). There are still a few more to plug
in ompi_info (mainly concerned with shutting down OMPI/ORTE
subsystems), but they can wait...
This commit was SVN r5466.
Last night's fix completely disregarded building the DSO components,
which need to have the dllimport flag set for all the libmpi stuff, and
need to export their component structures. Unfortunately needed to
add another #define to deal with the components for windows, but
it required the least amount of work for all the non-Windows people.
This commit was SVN r5461.
