The PSM MTL for Intel's TrueScale Infiniband HCAs is not being actively
maintained and should be removed from the master branch.
Fixes issue: #6877
Signed-off-by: Michael Heinz <michael.william.heinz@intel.com:
Do not require an archive when the OMPI_MPIEXT_<ext>_HAVE_OBJECT
macro is defined to 0.
See `ompi/mpiext/example/configure.m4`.
Allow some extensions to be built on OS X since the creation of
archives with no files is not permitted.
Refs. open-mpi/ompi#6205
Signed-off-by: Gilles Gouaillardet <gilles@rist.or.jp>
Signed-off-by: KAWASHIMA Takahiro <t-kawashima@jp.fujitsu.com>
Signed-off-by: Jeff Squyres <jsquyres@cisco.com>
Fix one message in opal_summary.m4 be consistent with other messages
in the same area of opal_summary.m4.
Signed-off-by: Jeff Squyres <jsquyres@cisco.com>
This is so when a debugger attaches using MPIR, it can step out of this stack back into main.
This cannot be done with certain aggressive optimisations and missing debug information.
Signed-off-by: James Clark <james.clark@arm.com>
Signed-off-by: Jeff Squyres <jsquyres@cisco.com>
Co-authored-by: Jeff Squyres <jsquyres@cisco.com>
- there was a set of UCX related issues reported which caused
by mmap API hooks conflicts. We added diagnostic of such
problems to simplify bug-resolving pipeline
Signed-off-by: Sergey Oblomov <sergeyo@mellanox.com>
This configure CLI option should probably have been removed as part of
a6d6be2853. Regardless, the #defines it
sets no longer exist in the code base at all, so they should be
removed. Also remove the text about it in README.
Signed-off-by: Jeff Squyres <jsquyres@cisco.com>
This commit DELETES the removed MPI1 functions and datatypes from
both the mpi.h header and from the library (they were deleted from the
MPI standard in MPI-3.0).
WARNING: This changes the MPI API in a non-backwards compatible way.
This also removes the configure option that was added in Open
MPI v4.0.x, requiring users to change their apps if they are
using any of these almost 20 year old APIs.
This commit removes the following MPI1 removed functions and datatypes:
MPI_Address
MPI_Errhandler_create
MPI_Errhandler_get
MPI_Errhandler_set
MPI_Type_extent
MPI_Type_hindexed
MPI_Type_hvector
MPI_Type_struct
MPI_Type_UB
MPI_Type_LB
Signed-off-by: Geoffrey Paulsen <gpaulsen@us.ibm.com>
When Slurm is built against PMIx, some installations place a copy of the
PMIx library that Slurm is linking against in the Slurm PMI location.
Current configury ignores that location. The desired behavior is to look
for a PMIx lib in that location when --with-pmi is given. If the user
also specifies --with-pmix and gives a different location, then override
anything previously found and look for it where the user directed.
Signed-off-by: Ralph Castain <rhc@pmix.org>
In the commit cacd6f389c, I removed `#if HAVE_[TYPE]` lines for types
which are always available in C99 compilers. But I forgot to remove
this line. The `HAVE_LONG_LONG` macro is still defined in `confdefs.h`.
So this is not a bug but code cleanup.
Signed-off-by: KAWASHIMA Takahiro <t-kawashima@jp.fujitsu.com>
For remote node peers pack smaller worker address, which contains
network device addresses only. This would reduce amount of OOB traffic
during startup.
Signed-off-by: Mikhail Brinskii <mikhailb@mellanox.com>
Update the OPAL_CHECK_OFI configury macro:
- Make it safe to call the macro multiple times:
- The checks only execute the first time it is invoked
- Subsequent invocations, it just emits a friendly "checking..."
message so that configure output is sensible/logical
- With the goal of ultimately removing opal/mca/common/ofi, rename the
output variables from OPAL_CHECK_OFI to be
opal_ofi_{happy|CPPFLAGS|LDFLAGS|LIBS}.
- Update btl/ofi, btl/usnic, and mtl/ofi for these new conventions.
- Also, don't use AC_REQUIRE to invoke OPAL_CHECK_OFI because that
causes the macro to be invoked at a fairly random time, which makes
configure stdout confusing / hard to grok.
- Remove a little left-over kruft in OPAL_CHECK_OFI, too (which
resulted in an indenting change, making the change to
opal_check_ofi.m4 look larger than it really is).
Thanks Alastair McKinstry for the report and initial fix.
Thanks Rashika Kheria for the reminder.
Signed-off-by: Jeff Squyres <jsquyres@cisco.com>
Now that all components that use libibverbs are gone, remove
OPAL_CHECK_VERBS and the confusingly-named OPAL_CHECK_OPENFABRICS
(which really just checked for verbs things -- not all the possible
OpenFabrics APIs/libraries).
The only code left in Open MPI that calls verbs is hwloc -- and that's
just the APIs that takes an IBV device and returns topological
information about it. Since nothing in the Open MPI code base uses
the "ibv_*" API any more, we have no need for this hwloc functionality
so we'll even remove the --with-verbs configure options.
Signed-off-by: Jeff Squyres <jsquyres@cisco.com>
... and add `MPI_COMPLEX4`.
This commit changes values of existing `OMPI_DATATYPE_MPI_*` macros.
This change does not affect ABI compatibility of `libmpi.so` and the
like because these values are only used in OMPI internal code.
On the other hand, `ompi_datatype_t::id` values of existing datatypes
are not changed and 73 is newly assigned to for `MPI_COMPLEX4` to
retain ABI compatibility.
Signed-off-by: KAWASHIMA Takahiro <t-kawashima@jp.fujitsu.com>
The type `short float`, which is proposed in ISO/IEC JTC 1/SC 22 WG 14
(C WG), is not supported by most compilers yet. But some compilers
(including gcc 7 for AArch64 and clang 6) support `_Float16`, which
is defined in ISO/IEC TS 18661-3:2015 (ISO/IEC JTC 1/SC 22/WG 14 N1945)
as an extensions for C. If it is detected in `configure`, it is used
as an alternate type of `short float` in Open MPI internal code.
This commit adds a `configure` option `--enable-alt-short-float=TYPE`.
It can be used to specify a type other than `short float` and `_Float16`
as the alternate type.
Signed-off-by: KAWASHIMA Takahiro <t-kawashima@jp.fujitsu.com>
If MPI extensions are enabled, all
`ompi/mpiext/pcollreq/use-mpi/mpiext_*_usempi.h` are included in
`ompi/mpi/fortran/mpiext-use-mpi/mpi-ext-module.F90` and all
`ompi/mpiext/pcollreq/use-mpi/mpiext_*_usempif08.h` are included in
`ompi/mpi/fortran/mpiext-use-mpi-f08/mpi-f08-ext-module.F90` using
`#include` directives.
In `mpiext_*_usempi.h` and `mpiext_*_usempif08.h`, some MPI extension
may want to use constants or handles defined in the `mpi` module and
the `mpi_f08` module. For example, if you want to define a new
datatype in `mpi_f08_ext`, you'll need the definition of
`type(mpi_datatype)`. However, putting `use mpi_f08` line in thier
`mpiext_*_usempif08.h` may cause a compilation error if more than
one MPI extensions are enabled because the `use` statement must be
put prior to any variable declarations.
To resolve this problem, this commit puts `use mpi` and `use mpi_f08`
as first lines of `mpi-ext-module.F90` and `mpi-f08-ext-module.F90`
respectively.
Signed-off-by: KAWASHIMA Takahiro <t-kawashima@jp.fujitsu.com>
Including `mpiext_*_mpifh.h` in the source file of the `mpi_f08_ext`
module is not always appropriate. For example, if you want to define
a new datatype in an MPI extension, the `include 'mpif-ext.h'` binding
defines the datatype as `integer` but the `use mpi_f08_ext` binding
defines it as `type(mpi_datatype)`. They conflict.
This commit allows each MPI extension to declare whether it wants to
include its `mpiext_*_mpifh.h` in `mpi_f08` and `mpi_f08_ext`
respectively. The default (no declaration) is 'want'.
See `ompi/mpiext/example/configure.m4` for an example.
Signed-off-by: KAWASHIMA Takahiro <t-kawashima@jp.fujitsu.com>
clang 5.0 on trusty is busted with respect to C11 atomics
This can be evidenced with the simple program below.
This test was added into OPAL_PROG_CC_C11_HELPER() and disable
C11 atomics if it fails.
_Atomic uint32_t a;
uint32_t b;
atomic_fetch_xor_explicit(&a, b, memory_order_relaxed);
Refs. open-mpi/ompi#6264
Signed-off-by: Gilles Gouaillardet <gilles@rist.or.jp>
Allow MPI extensions to generate Fortran headers using Autoconf.
For example, allow following files.
```
ompi/mpiext/example/mpif-h/mpiext_example_mpifh.h.in
ompi/mpiext/example/use-mpi/mpiext_example_usempi.h.in
ompi/mpiext/example/use-mpi-f08/mpiext_example_usempif08.h.in
```
Generated MPI extension C headers are already allowed in commit
6a7d5271c4.
Signed-off-by: KAWASHIMA Takahiro <t-kawashima@jp.fujitsu.com>
If the default value of `ofc_type_size` is `$ac_cv_sizeof_int`,
`OMPI_SIZEOF_FORTRAN_*` of all unavailable types become `sizeof(int)`.
This leads `OMPI_SIZEOF_FORTRAN_REAL2 == OMPI_SIZEOF_FORTRAN_REAL`
to become true unintentionally and `OMPI_DATATYPE_MPI_REAL2` has a
wrong value in `ompi/datatype/ompi_datatype_internal.h`. This is not
an actual bug because datatypes for unavailable types are not used.
However it is confusing. I looked the source tree and the history but
could find any basis of `$ac_cv_sizeof_int`.
If we don't use `implicit none` in `OMPI_FORTRAN_GET_KIND_VALUE`, and
if a Fortran compiler does not support `ISO_C_BINDING` completely,
a random value is set in `value` and the fallback route is not used.
It is not our intention.
Signed-off-by: KAWASHIMA Takahiro <t-kawashima@jp.fujitsu.com>
Ensure that MPI extensions with mpif.h bindings have names that are
<=26 characters long. 26 is the magic number that still allows us to
have an "include ..." line in the user-facing mpif-ext.h header file
that includes this extension's header file without going over 72
characters.
Signed-off-by: Jeff Squyres <jsquyres@cisco.com>
Signed-off-by: Gilles Gouaillardet <gilles@rist.or.jp>
Per discussion on https://github.com/open-mpi/ompi/pull/6030
and https://github.com/open-mpi/ompi/pull/6145, move
around where MPI extension header files are installed (specifically:
the installation tree path does not need to match the source tree
path).
For reference, header files were installed like this :
- <prefix>/include/openmpi/ompi/mpiext/pcollreq/mpif-h/mpiext_pcollreq_mpifh.h
- <prefix>/include/openmpi/ompi/mpiext/pcollreq/c/mpiext_pcollreq_c.h
and they are now installed like this :
- <prefix>/include/openmpi/mpiext/mpiext_pcollreq_mpifh.h
- <prefix>/include/openmpi/mpiext/mpiext_pcollreq_c.h
Signed-off-by: Jeff Squyres <jsquyres@cisco.com>
Signed-off-by: Gilles Gouaillardet <gilles@rist.or.jp>
move openmpi/ompi/mpiext/FOO/c/mpiext_FOO_c.h to
openmpi/ompi/mpiext/FOO_c.h in order to use consistent
paths with mpif.h extensions
Refs. open-mpi/ompi#6019
Signed-off-by: Gilles Gouaillardet <gilles@rist.or.jp>
in order to cope with the 72 characters per line limit, move
openmpi/ompi/mpiext/FOO/mpif-h/mpiext_FOO_mpifh.h to
openmpi/ompi/mpiext/FOO_mpifh.h
Refs. open-mpi/ompi#6019
Signed-off-by: Gilles Gouaillardet <gilles@rist.or.jp>
prefer #include vs include in order to correctly handle long Fortran lines.
We use the full path, and it can be very long, this is why
it cannot be passed to the Fortran compiler.
Thanks Igor Andriyash and Axel Huebl for reporting this issue.
Refs open-mpi/ompi#6106
Signed-off-by: Gilles Gouaillardet <gilles@rist.or.jp>
Now Open MPI requires a C99 compiler. Checking availability of
the following types is no more needed.
- `long long` (`signed` and `unsigned`)
- `long double`
- `float _Complex`
- `double _Complex`
- `long double _Complex`
Signed-off-by: KAWASHIMA Takahiro <t-kawashima@jp.fujitsu.com>
using the standard $USER and $HOSTNAME environment variables
to make reproducible builds possible.
See https://reproducible-builds.org/ for why this is good.
This helps improve issue #3759
Signed-off-by: Bernhard M. Wiedemann <bwiedemann@suse.de>
A typo inadvertantly crept in to e836dbd506. Add the extra '-' to
make it correctly search for --with-*=internal.
Signed-off-by: Jeff Squyres <jsquyres@cisco.com>
Our components that have a --with-foo configure option won't know what
to do with a value of "internal". This scenario only occurs with hwloc
and libevent, both of which are statically contained in libopen-pal
Thanks to @jsquyres for the diff
Signed-off-by: Ralph Castain <rhc@open-mpi.org>
- do not generate bindings for pompi_FOO_f symbols
(they are simply not used anywhere)
- move ompi_FOO_f bindings out of mpi_f08.mod into
ompi_mpifh_bindings.mod that is only used at build time
Signed-off-by: Gilles Gouaillardet <gilles@rist.or.jp>
