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>
The feature of persistent collectives is approved in the Sept. 2018
MPI Forum meeting and 2018 Draft Specification of the MPI standard is
published during SC18.
Signed-off-by: KAWASHIMA Takahiro <t-kawashima@jp.fujitsu.com>
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>
without this fix, an error handler invoked on pml_ucx request would
segfault while trying to dereference requests[i]->req_mpi_object.comm
Signed-off-by: Yossi Itigin <yosefe@mellanox.com>
- according spec 1.4, annex C shmem collectives should process
calls where number of elements is zero independently from pointer
value
- added zero-count processing - it just call barrier to
sync ranks
Signed-off-by: Sergey Oblomov <sergeyo@mellanox.com>
Per https://github.com/open-mpi/ompi/issues/6058, add some text about
building on network filesystem, particularly with respect to
filesystem timestamps.
Signed-off-by: Jeff Squyres <jsquyres@cisco.com>
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>
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`
Furthermore, the `#if HAVE_[TYPE]` style checking is not correct.
Availability of C types is checked by `AC_CHECK_TYPES` in `configure.ac`.
`AC_CHECK_TYPES` defines macro `HAVE_[TYPE]` as `1` in `opal_config.h`
if the `[TYPE]` is available. But it does not define `HAVE_[TYPE]`
(instead of defining as `0`) if it is not available. So even if we
need `HAVE_[TYPE]` checking, it should be `#if defined(HAVE_[TYPE])`.
I didn't remove `AC_CHECK_TYPES` for these types in `configure.ac`
since someone may use `HAVE_[TYPE]` macros somewhere.
Signed-off-by: KAWASHIMA Takahiro <t-kawashima@jp.fujitsu.com>
This commit fixes an compilation error when configured
with `--enable-timing`.
Procedures in the function `orte_ess_base_app_setup`
in `orte/mca/ess/base/ess_base_std_app.c` are moved
to `orte/mca/ess/pmi/ess_pmi_module.c`
and `orte/mca/ess/singleton/ess_singleton_module.c`
in the recent commit 57f6b94fa5.
In `ess_pmi_module.c`, the first argument of the
`OPAL_TIMING_ENV_NEXT` macro should have been adapted
to the destination function but was not.
In `ess_singleton_module.c`, `OPAL_TIMING_ENV_INIT`
was not used in the destination function originally.
So `OPAL_TIMING_ENV_NEXT` cannot be used in the function.
Signed-off-by: KAWASHIMA Takahiro <t-kawashima@jp.fujitsu.com>
This fixes a regression introduced in commit open-mpi/ompi@f8318f0a8f.
Fixesopen-mpi/ompi#6069
Thanks Kawashima-san for the heads up !
Signed-off-by: Gilles Gouaillardet <gilles@rist.or.jp>
Update the show_help message for when there are not enough slots to
run an application.
Also, remove a bunch of copies of this message in various show_help
text files that aren't used/referred to anywhere in the code.
Signed-off-by: Jeff Squyres <jsquyres@cisco.com>
