which should ease building:
--no_check: do not make check -- may not be interesting,
we still want to do further testing.
--install-dir: On clusters, tmp may not be shared,
still, one may not want to use --scrdir
build_tests.pl is taken form build_tarball.pl.
Actually all subs are the same (is it possible to have
a module that is included by both?)
It configures and compiles two tests (now PMB and the
mpichtests) and installs them for later execution.
This takes a (misnamed) input --outfile, the output
file of build_tarball.pl, so the test-files are
compiled for every combination of OpenMPI-compilations.
The following ompi_crontab.sh script the pulls all
combinations of MPI-tests compiled and qsubs them.
This commit was SVN r5579.
based around PTL_MD_MAX_SIZE, which apparently isn't implemented in
Cray's Portals implementation. Time to rethink that design :/
This commit was SVN r5576.
HEADS UP: string versions of names are now presented in DECIMAL format - not HEX as they previously were. If you used the name services functions (as you were supposed to do) to access these names, you will not have any problems. If you did it yourself, then you need to fix it - my suggestion would be that you fix your code by using the name service functions to avoid future problems.
This commit was SVN r5571.
1. *correctly* fix the printing of size_t variables. Need to do this through a #define, not just typecast things. Thanks to Jeff/Brian for suggesting a cleaner way to do it (as opposed to just doing the #define at the print location). Note that not ALL of the prints have been "fixed" yet - will continue to identify them.
2. Add int64 and size_t to the pack/unpack unit tests.
3. Fix a bug in the int64 pack/unpack system.
This commit was SVN r5570.
the trick: I decide to print it always as an unsigned long and explicitly cast everything to this type.
Thus, I change all printf formats from %d to %lu and cast all arguemnts to the correct type (unsigned long).
This commit was SVN r5568.
when dps_internal.h get touched. Anyway the name say it should be internal to the dps system, so
there is no reason to have it included everywhere.
This commit was SVN r5555.
Merged in from:
svn merge -r5506:5553 https://svn.open-mpi.org/svn/ompi/tmp/hetero .
This commit was SVN r5552.
The following SVN revisions from the original message are invalid or
inconsistent and therefore were not cross-referenced:
r5506
r5553
Merged from:
svn merge -r5496:5506 https://svn.open-mpi.org/svn/ompi/tmp/hetero .
This commit was SVN r5551.
The following SVN revisions from the original message are invalid or
inconsistent and therefore were not cross-referenced:
r5496
r5506
Merged in from:
svn merge -r5448:5496 https://svn.open-mpi.org/svn/ompi/tmp/hetero .
This commit was SVN r5550.
The following SVN revisions from the original message are invalid or
inconsistent and therefore were not cross-referenced:
r5448
r5496
from:
svn merge -r5440:5448 https://svn.open-mpi.org/svn/ompi/tmp/hetero .
This commit was SVN r5549.
The following SVN revisions from the original message are invalid or
inconsistent and therefore were not cross-referenced:
r5440
r5448
soon.
Make ORTE_EXIT_CODE be the same as INT32, not INT8. This allows the
full propogation of the value returned by waitpid() rather than just
the lowest 8 bites. Also change the naming of it in orterun to be
exit_status, not exit_code (per POSIX standard naming convention).
orterun now returns the first nonzero exit status that it receives.
This commit was SVN r5530.
functions we destroy the frame pointer for the next call so very very weird things
happened. Like seg fault on i = 50 !!!
Both 32 and 64 bits versions have been modified but only the 32 version have been tested (by lack of ressources).
This commit was SVN r5525.
The following SVN revision numbers were found above:
r2 --> open-mpi/ompi@58fdc18855
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.
