don't set the ref count to 1, it has been already set by the call to OBJ_NEW
when the type was allocated. This fixes ticket #2014.
This commit was SVN r21976.
As noted in http://www.open-mpi.org/community/lists/devel/2009/08/6741.php,
we do not correctly free a dupped predefined datatype.
The fix is a bit more involving. See ticket for details.
Tested with ibm tests and mpi_test_suite (though there's two "old" failures
zero5.c and zero6.c)
Thanks to Lisandro Dalcin for bringing this up.
This commit was SVN r21929.
The following Trac tickets were found above:
Ticket 2014 --> https://svn.open-mpi.org/trac/ompi/ticket/2014
support for _Complex is disabled until we figure out the correct
black magic. So instead of using this nice C99 feature, we use the
a strcture with a double type, the same approach that worked pretty
well for the last couple of years.
Switching from one mode to the other is done using the
OPAL_USE_[FLOAT|DOUBLE|LONG_DOUBLE]__COMPLEX macros defined in
opal_datatype_internal.h at line 442.
This commit was SVN r21800.
Complex should either be a struct of float on the ompi-layer
or as C99 float _complex in opal.
unconstify to not break windows / the mpi* wrappers.
This commit was SVN r21770.
The following SVN revision numbers were found above:
r21763 --> open-mpi/ompi@668f001351
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.
