Only check the if the Fortran compiler needs additional CLI flags for
preprocessing .F90 files if we actually have an F90 compiler.
Also fix a the AC_MSG_* usage.
Signed-off-by: Jeff Squyres <jsquyres@cisco.com>
(cherry picked from commit a7e4ca4dc0)
.F90 files are preprocessed by gfortran and other compilers.
NAG compilers only preprocess .{ff,ff90,ff95} files, and the -fpp
flag is required to process .F90 files.
Fixesopen-mpi/ompi#7583
Signed-off-by: Gilles Gouaillardet <gilles@rist.or.jp>
(cherry picked from commit a2c711b54b)
- pgcc18 defines __GNUC__ similar to Intel compilers. So we must
check for pgi higher up, or else configury will mistake
it for gcc.
Signed-off-by: Austen Lauria <awlauria@us.ibm.com>
(cherry picked from commit 14785deb3c)
Automake's Fortran compilation rules inexplicably use CPPFLAGS and
AM_CPPFLAGS. Unfortunately, this can cause problems in some cases
(e.g., picking up already-installed mpi.mod in a system-default
include search path).
So in relevant module-using Fortran compilation Makefile.am's, zero
out CPPFLAGS and AM_CPPFLAGS.
This has a side-effect of requiring that we compile the one .c file in
the F08 library in a new, separate subdirectory (with its own
Makefile.am that does _not_ have CPPFLAGS/AM_CPPFLAGS zeroed out).
Signed-off-by: Jeff Squyres <jsquyres@cisco.com>
Signed-off-by: Gilles Gouaillardet <gilles@rist.or.jp>
(cherry picked from commit ab398f4b9a)
to support the Cray Fortran compiler. Cray Fortran compiler does not
contain all symbol info in the module file, have to link with the *.o
created as part of module file compilation.
Signed-off-by: Howard Pritchard <howardp@lanl.gov>
(cherry picked from commit 441bad9a75)
There was a path where OPAL_CHECK_ALPS would exit its testing but
still leave `opal_check_cray_alps_happy` blank. Fix that by setting
it to "no".
Signed-off-by: Jeff Squyres <jsquyres@cisco.com>
(cherry picked from commit 26705efad0)
Commit d7053a3 broke things for the case when Open MPI 4.0.x is built
without UCX support. Problem was it was trying to partially initialize
the btl to try and delay printing of a help message till wireup. Well
this sort of doesn't work in all cases. Rather than keep piling on
changes to support a help message for a BTL that we are deprecating, take
a keep it simple stupid approach.
So, revert most of d7053a3 and instead put the help message back in the
original location, during scan of ports of the available HCAs to check
for whether or not link layer for that port is configured for ethernet or infiniband.
If Open MPI was built with UCX support, don't emit the help message, if
UCX was not linked in, emit the help message.
Verified on a system with connectX5 HCAs configured with two ports configured
for ethernet and two for infiniband.
relates to #6785
Signed-off-by: Howard Pritchard <howardp@lanl.gov>
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>
(cherry-picked from 20f5840)
- 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>
(cherry picked from commit d8e3562bae)
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>
(cherry picked from commit cd1b5641be)
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>
(cherry picked from commit 751d88192d)
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/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.
Updated from master cherry pick: the OFI BTL does not exist on the
v4.0.x branch. Therefore, did not include the OFI BTL changes on
master in this cherry pick.
Signed-off-by: Jeff Squyres <jsquyres@cisco.com>
(cherry picked from commit f5e1a672cc)
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>
(cherry picked from commit open-mpi/ompi@d1fadebc65)
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>
(cherry picked from commit open-mpi/ompi@c0faf34855)
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>
(cherry picked from commit open-mpi/ompi@975e3cd0c9)
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>
(cherry picked from commit 475d0355d7)
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>
(cherry picked from commit 7675956b8f)
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>
(cherry picked from commit e836dbd506)
Having the "make_manpage.pl" script in the ompi/ tree broke
"./autogen.pl --no-ompi" (specifically: "make distcheck" of --no-ompi
builds would break).
(cherry picked from commit 89773c41)
Signed-off-by: Jeff Squyres <jsquyres@cisco.com>
- 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>
(cherry picked from commit open-mpi/ompi@c6070fd2e0)
Thanks to Stefan Teleman for identifying this issue and providing a
proof-of-concept patch. We ended up revamping the detection of
128-bit atomics to reduce duplicated code and be a slightly simpler --
albiet perhaps a bit more verbose -- approach:
- Remove the --enable-cross-* options; they were confusing and
unnecessary.
- Always try to compile / link the compiler-intrinsic 128-bit atomic
functions.
- Strengthen the C tests we use to be more robust.
- Use m4 to avoid duplicating the C tests multiple times in the .m4
source.
- If not cross-compiling, try to run a short test and ensure that they
actually work (as of Aug 2018, there's at least one platform where
they don't: clang 6 on ARM64). If cross-compiling, just assume that
they work.
- Add more comments about what is going on with all the tests; it's
tricky stuff. Our Future Selves will thank us.
Signed-off-by: George Bosilca <bosilca@icl.utk.edu>
Signed-off-by: Jeff Squyres <jsquyres@cisco.com>
(cherry picked from commit ff9df91887)
Per https://github.com/open-mpi/ompi/issues/5031, if the user didn't specify a particular PMIx installation, then default back to the internal version if it is newer than the discovered external one. PMIx doesn't yet provide a full signature so we have to just get as close as possible for now.
Signed-off-by: Ralph Castain <rhc@open-mpi.org>
(cherry picked from commit 1e6aaf7f22)
Per today's telecon, check for supported version and do not use anything less than 1.2.x. Sadly, we don't include the last piece of the version triplet in the version file and so we cannot check for 1.2.5.
If someone explicitly points us at an external installation that isn't acceptable, then error out
Add PMIx support to summary
Signed-off-by: Ralph Castain <rhc@open-mpi.org>
- added implementation and/or/xor operations for post and
fetch-op notations
- implemented basic and UCX transports, mxm added
NON-IMPLEMENTED wrapper
- updated C interfaces only (fortran will be added later)
- existing API is not updated to spec v1.4
Signed-off-by: Sergey Oblomov <sergeyo@mellanox.com>
