Make the checks for macro weak symbols be equivalent to the checks for
weak symbols.
Also fix up several OSHMEM configure checks:
* fix an errant AC_MSG_REQUEST
* don't check for profiling ability during configure options checks.
Instead, defer it to later, when we have weak symbol check results.
* don't directly call _FOO macros from the top level
* make setting up OSHMEM profiling similar to MPI profiling: create
OSHMEM_SETUP_PROFILING macro
* cache the results of checking for macro weak symbols (for parity
with the weak symbol check -- although we should really
revisit/audit the whole cache-checking scheme throughout all m4
code; it may well be inconsistently used)
* add some more [] m4 quoting, even in the original C weak symbols test
* style: fix some whitespace errors
Refs trac:4868
This commit was SVN r32590.
The following Trac tickets were found above:
Ticket 4868 --> https://svn.open-mpi.org/trac/ompi/ticket/4868
WHAT: Merge the PMIx branch into the devel repo, creating a new
OPAL “lmix” framework to abstract PMI support for all RTEs.
Replace the ORTE daemon-level collectives with a new PMIx
server and update the ORTE grpcomm framework to support
server-to-server collectives
WHY: We’ve had problems dealing with variations in PMI implementations,
and need to extend the existing PMI definitions to meet exascale
requirements.
WHEN: Mon, Aug 25
WHERE: https://github.com/rhc54/ompi-svn-mirror.git
Several community members have been working on a refactoring of the current PMI support within OMPI. Although the APIs are common, Slurm and Cray implement a different range of capabilities, and package them differently. For example, Cray provides an integrated PMI-1/2 library, while Slurm separates the two and requires the user to specify the one to be used at runtime. In addition, several bugs in the Slurm implementations have caused problems requiring extra coding.
All this has led to a slew of #if’s in the PMI code and bugs when the corner-case logic for one implementation accidentally traps the other. Extending this support to other implementations would have increased this complexity to an unacceptable level.
Accordingly, we have:
* created a new OPAL “pmix” framework to abstract the PMI support, with separate components for Cray, Slurm PMI-1, and Slurm PMI-2 implementations.
* Replaced the current ORTE grpcomm daemon-based collective operation with an integrated PMIx server, and updated the grpcomm APIs to provide more flexible, multi-algorithm support for collective operations. At this time, only the xcast and allgather operations are supported.
* Replaced the current global collective id with a signature based on the names of the participating procs. The allows an unlimited number of collectives to be executed by any group of processes, subject to the requirement that only one collective can be active at a time for a unique combination of procs. Note that a proc can be involved in any number of simultaneous collectives - it is the specific combination of procs that is subject to the constraint
* removed the prior OMPI/OPAL modex code
* added new macros for executing modex send/recv to simplify use of the new APIs. The send macros allow the caller to specify whether or not the BTL supports async modex operations - if so, then the non-blocking “fence” operation is used, if the active PMIx component supports it. Otherwise, the default is a full blocking modex exchange as we currently perform.
* retained the current flag that directs us to use a blocking fence operation, but only to retrieve data upon demand
This commit was SVN r32570.
PGI compilers older that 2013 have a buggy preprocessor
that does not support pragma defined in a macro called
itself called from an other macro
cmr=v1.8.2:reviewer=jsquyres
This commit was SVN r32551.
Unfortunately, I didn't see Dave's review until CMR #4841 went in.
Oops.
This commit is a handful of minor m4 improvements to that original
r32447 commit. It can go to v1.8.3, just to minimize drift between
trunk and v1.8.
Reviewed by Dave Goodell.
cmr=v1.8.3:reviewer=ompi-rm1.8
This commit was SVN r32477.
The following SVN revision numbers were found above:
r32447 --> open-mpi/ompi@c6d9bf906e
In core library portions of the configury (e.g., top-level
configure.ac itself), we were calling AC_CHECK_LIB and
OPAL_CHECK_FUNC_LIB to check for various libraries.
'''SIDENOTE:''' It turns out that modern Autoconf has AC_SEARCH_LIBS,
which does just about exactly what OPAL_CHECK_FUNC_LIB does. So this
commit effectively replaces OPAL_CHECK_FUNC_LIB with AC_SEARCH_LIBS.
However, we never bothered to add these found libraries to the wrapper
compiler list of libraries used for static linking (doh!). We've been
getting lucky for quite a while that components were adding the same
libraries to their wrapper compiler LIBS list.
This is problematic, however, if we don't build some of these
components. For example, Paul Hargrove noticed that if he configured
with --disable-shared --enable-static --disable-io-romio, ROMIO was no
longer adding some libraries to the wrapper LIBS list -- libraries
that just happened to also be needed by core OPAL/ORTE/OMPI layers.
The solution is not to use AC_CHECK_LIB or OPAL_CHECK_FUNC_LIB, but
use a pair of new macros:
* OPAL_SEARCH_LIBS_CORE: a wrapper around AC_SEARCH_LIBS. If we add
something to $LIBS, then also add it to the wrapper list of static
libraries. This is the main piece of functionality that was
wrong/missing.
* OPAL_SEARCH_LIBS_COMPONENT: similar to OPAL_SEARCH_LIBS_CORE, but
instead of directly adding it to the wrapper list of static
libaries, add it to <framework>_<component>_LIBS (which eventually
gets slurped up into the wrapper list of static libraries. See the
lengthy comment in config/opal_setup_wrappers.m4 near the beginning
of OPAL_SETUP_WRAPPER_INIT() for a more detailed explanation).
Most components did this correctly already, but one or two weren't
right, so I implemented this second macro quite similar to the
first and put it everywhere we already used AC_SEARCH_LIBS or
OPAL_CHECK_FUNC_LIB.
This needs to soak for a day or two on the trunk before moving to the
v1.8 branch.
Refs trac:4834
cmr=v1.8.2:reviewer=ggouaillardet
This commit was SVN r32447.
The following Trac tickets were found above:
Ticket 4834 --> https://svn.open-mpi.org/trac/ompi/ticket/4834
r32354 breaks gfortran if you --enable-mpi-fortran, because it assumes
the value "all", when then errors out of configure because gfortran
can't currently build the mpi_f08 bindings.
Need to think about what the Right solution is here...
This commit was SVN r32369.
The following SVN revision numbers were found above:
r32354 --> open-mpi/ompi@6a44eb6c82
as pointed by Paul Hargrove, abort configure is the fortran
bindings explicitly requested with --enable-mpi-fortran=...
cannot be built
cmr=v1.8.2:reviewer=jsquyres
This commit was SVN r32354.
WHAT: Open our low-level communication infrastructure by moving all necessary components (btl/rcache/allocator/mpool) down in OPAL
All the components required for inter-process communications are currently deeply integrated in the OMPI layer. Several groups/institutions have express interest in having a more generic communication infrastructure, without all the OMPI layer dependencies. This communication layer should be made available at a different software level, available to all layers in the Open MPI software stack. As an example, our ORTE layer could replace the current OOB and instead use the BTL directly, gaining access to more reactive network interfaces than TCP. Similarly, external software libraries could take advantage of our highly optimized AM (active message) communication layer for their own purpose. UTK with support from Sandia, developped a version of Open MPI where the entire communication infrastucture has been moved down to OPAL (btl/rcache/allocator/mpool). Most of the moved components have been updated to match the new schema, with few exceptions (mainly BTLs where I have no way of compiling/testing them). Thus, the completion of this RFC is tied to being able to completing this move for all BTLs. For this we need help from the rest of the Open MPI community, especially those supporting some of the BTLs. A non-exhaustive list of BTLs that qualify here is: mx, portals4, scif, udapl, ugni, usnic.
This commit was SVN r32317.
Rever r32246, r32254, and 32255 -- they were fixing side-effects of
the real bug. Real fix coming after this one.
This commit was SVN r32286.
The following SVN revision numbers were found above:
r32246 --> open-mpi/ompi@08d2a1a48d
r32254 --> open-mpi/ompi@232d4dbb7b
ABSoft compilers cannot compile a fortran subroutine
with the BIND(C, NAME="name") modifier *and* argument(s)
with the OPTIONAL modifier
This patch detects this unsupported feature and use
adhoc wrappers if it is missing
cmr=v1.8.2:reviewer=jsquyres
This commit was SVN r32246.
Older gfortran compilers (e.g., the gfortran that ships in RHEL5) do
not support ISO_C_BINDING, and therefore do not support the
TYPE(C_PTR) type. As such, they cannot support the overloaded
interfaces for MPI_WIN_ALLOCATE_SHARED and MPI_SHARED_QUERY that are
mandated in MPI-3.
So we separate those interfaces out into a separate .F90 file that is
#include'd in the tkr mpi.F90 file. In this separate .F90 file, we
use an #if to determine whether the compiler supports ISO_C_BINDING or
not.
Also re-jiggered the order of testing in ompi_setup_mpi_fortran.m4: we
now need to test whether the compiler supports ISO_C_BINDING even when
we're only building the mpi module (not strictly when we're building
the mpi_f08 module).
Finally, tweaked the use-mpi-tkr/Makefile.am to:
* Add some proper dependencies for mpi.F90
* Allow the general AM compilation to be used instead of supplying a
specific rule for compiling mpi.F90
cmr=v1.8.2:ticket=trac:4736
This commit was SVN r32204.
The following Trac tickets were found above:
Ticket 4736 --> https://svn.open-mpi.org/trac/ompi/ticket/4736
It will come back someday.
cmr=v1.8.2:ticket=trac:4736
This commit was SVN r32044.
The following Trac tickets were found above:
Ticket 4736 --> https://svn.open-mpi.org/trac/ompi/ticket/4736
This is part one of several Fortran improvements and fixes. This
first part removes the now-defunct scripts that are used to generate
the .f90 files in the use-mpi-tkr implementation, and just commits the
output from those scripts. This makes long-term maintenance of the
use-mpi-tkr implementation simpler.
cmr=v1.8.2:reviewer=jsquyres:subject=Various Fortran fixes/improvements
This commit was SVN r32040.
top_ompi_srcdir -> OMPI_TOP_SRCDIR
top_ompi_builddir -> OMPI_TOP_BUILDDIR
We also split the srcdir/builddir flags according to their local tree (e.g., OPAL_TOP_SRCDIR), and tied them all together in configure.ac. Renamed ompi_ignore and ompi_unignore to be opal_<foo> as these are agnostic markers.
Only thing left is ompilibdir being treated similar to what we dif for srcdir/builddir. Coming soon.
This commit was SVN r31678.
We didn't AC_LANG_PUSH(C++) before checking to see if the compiler
supports -finline-functions, meaning that configure used the C
compiler for these checkes, not the C++ compiler.
Due to #2999, we have to fix both opal_setup_cxx.m4 and
ompi_setup_cxx.m4.
cmr=v1.8.2:reviewer=rolfv
This commit was SVN r31651.
- This line, and those below, will be ignored--
M opal/mca/event/libevent2021/configure.m4
M opal/mca/hwloc/hwloc172/configure.m4
M configure.ac
M config/opal_setup_libltdl.m4
M config/opal_check_visibility.m4
M config/opal_setup_cc.m4
This commit was SVN r31637.
Clang 3.4 static analysis is now smart enough that it refuses to
compile our POSIX threading tests because we simply passed 0 for
several arguments (the test is checking for the linker presence of
symbols, so the NULL arguments didn't matter). Specifically, Clang's
anti-NULL compile-time checks now refuse to compile this bogus code.
Hence, these 2 configure test codes now have real variables and
pointers so that clang will compile it properly.
Without this fix, configure determines that there is no POSIX
threading support, and the osc/sm component fails to compile (which is
a different defect I'll be filing shortly). As such, we need this fix
in 1.8.1.
Also, change from the deprecated AC_TRY_LINK to AC_LINK_IFELSE.
cmr=v1.8.1:reviewer=dgoodell
This commit was SVN r31458.
* Fixed the AC_ARG_ENABLE for the oshmem option.
* Fixed the AM_CONDITIONALs values for the projects.
* Re-added (and slightly simplified) the use of PROJECT_OSHMEM in
various Makefile.am's to disable building OSHMEM stuff
Submitted by Jeff, reviewed and approved by Ralph.
cmr=v1.7.5:reviewer=ompi-gk1.7
This commit was SVN r31062.
NOTE: I transferred the oshmem-disabled-by-default from the 1.7 branch to the trunk to minimize future disruption if/when we change that option.
cmr=v1.8:reviewer=jsquyres
This commit was SVN r31006.
- -check-shmem-params is OFF by default. It checks OSHMEM API params and will abort on bad input
- hcoll do not save fallback coll pointers for unsupported collectives.
fixed by Val, Roman, reviewed by Miked/Igor
cmr=v1.7.5:reviewer=ompi-rm1.7
This commit was SVN r30995.
This commit decouples OMPI deployment from the version(s) of the lower
layers of the stack by probing for UDP support.
Verbs applications assume a 40-byte header (there is no current
mechanism for querying payload offset). So to support a 42-byte UDP
header without causing existing applications like ibv_ud_pingpong or
older versions of OMPI to crash, we must inform libusnic_verbs that we
are aware of the nonstandard payload offset. We do this by overriding
the `transport_type` field of the device to be 42 before calling
`ibv_open_device`. If the library resets it to something else, then we
know the lower layers are UDP capable. Otherwise we use the older
custom-L2 format.
This necessitated some minor ugliness in common_verbs, but it's as tidy
as Jeff and I know how to make it right now.
This commit only adds support for UDP headers and connectivity over the
same L2 network, it does not touch routing or interface pairing.
Reviewed-by: Jeff Squyres <jsquyres@cisco.com>
cmr=v1.7.5:ticket=trac:4253
This commit was SVN r30838.
The following Trac tickets were found above:
Ticket 4253 --> https://svn.open-mpi.org/trac/ompi/ticket/4253
We're going to be bringing a bunch of usnic code to the SVN trunk
soon, and I basically brought this commit over out of order. So I'm
reverting it for now; the same functionality will come back shortly.
This commit was SVN r30805.
The following SVN revision numbers were found above:
r30804 --> open-mpi/ompi@5bedcc15bf
These constants are now upstream (see
https://git.kernel.org/cgit/libs/infiniband/libibverbs.git/commit/?id=f57a9c67eabb9e7f19c624ac3c8c27b7be55796c),
so let's support them properly in Open MPI.
Added bonus: consolidating these checks up in
ompi_check_openfabrics.m4 allowed removing some custom checks and
AC_DEFINE's from the usnic configure.m4 script.
Also change the usnic/configure.m4 check for IBV_EVENT_GID_CHANGE to
use AC_CHECK_DECLS (vs. AC_CHECK_DECL).
cmr=v1.7.5:reviewer=dgoodell
This commit was SVN r30804.
- Move the ptrdiff_t tests up higher in configure.ac to be with the
rest of the type tests.
- Create new OMPI_FIND_MPI_AINT_COUNT_OFFSET for finding the
corresponding types of MPI_Aint, MPI_Count, and MPI_Offset.
Consolidate all the old C and Fortran tests into this new macro (and
.m4 file).
- Fix Fortran MPI_*_KIND tests that incorrectly keyed off assumed
types (e.g., int64_t) rather than whatever the corresponding C
MPI_Aint, MPI_Count, MPI_Offset types turned out to be.
- Add new logic to ensure that sizeof(MPI_Count) <= sizeof(size_t),
because our entire PML, BTL, and convertor infrastructure requires
this. As a side effect, just like MPI_Offset the same type of
MPI_Count (because MPI_Count has to be able to hold an MPI_Offset,
so we can't let MPI_Offset be larger than a MPI_Count).
This commit was SVN r30776.
The following Trac tickets were found above:
Ticket 4205 --> https://svn.open-mpi.org/trac/ompi/ticket/4205
