These two macros set the prefix for the OPAL and ORTE libraries,
respectively. Specifically, the OPAL library will be named
libPREFIXopen-pal.la and the ORTE library will be named
libPREFIXopen-rte.la.
These macros must be called, even if the prefix argument is empty.
The intent is that Open MPI will call these macros with an empty
prefix, but other projects (such as ORCM) will call these macros with
a non-empty prefix. For example, ORCM libraries can be named
liborcm-open-pal.la and liborcm-open-rte.la.
This scheme is necessary to allow running Open MPI applications under
systems that use their own versions of ORTE and OPAL. For example,
when running MPI applications under ORTE, if the ORTE and OPAL
libraries between OMPI and ORCM are not identical (which, because they
are released at different times, are likely to be different), we need
to ensure that the OMPI applications link against their ORTE and OPAL
libraries, but the ORCM executables link against their ORTE and OPAL
libraries.
This commit makes the folowing changes:
- Add support for the knem single-copy mechanism. Initially vader will only
support the synchronous copy mode. Asynchronous copy support may be added
int the future.
- Improve Linux cross memory attach (CMA) when using restrictive ptrace
settings. This will allow Open MPI to use CMA without modifying the system
settings to support ptrace attach (see /etc/sysctl.d/10-ptrace.conf).
- Allow runtime selection of the single copy mechanism. The default behavior
is to use the best available. The priority list of single-copy mehanisms is
as follows: xpmem, cma, and knem.
- Allow disabling support for kernel-assisted single copy.
- Some tuning and bug fixes.
Update the VERSION file scheme:
* Remove "want_repo_rev".
* Add "tarball_version".
All values are now always included (major, minor, release, greek,
repo_rev). However, configure.ac now runs "opal_get_version.sh
... --tarball", which will return the value of tarball_version (if it
is non-empty) or the "full" version string (i.e.,
"major.minor.releasegreek").
Remove configure.params support: configure.params hasn't been used in
years.
Also remove autogen.subdirs support; those should really be handled by
their respective Makefile.am's.
This is a first cut at updating various infrastructure for git. There
will definitely be more commits; some of the scripts require
committed/pushed code (e.g., the various make-tarball scripts). So
it's not possible to know if we got it right without committing/pushing.
In all previous releases, the version number would be "A.B.C" unless C
was 0, in which case it would be "A.B". This commit changes that
scheme to always be "A.B.C", even if C==0.
Hence, v1.9.0 will be the first release where this new scheme is evident.
This commit was SVN r32816.
It's not enough to AC_COMPILE_IFELSE, do AC_LINK_IFELSE to really make
sure the compiler suite supports it.
Refs trac:4917
This commit was SVN r32802.
The following Trac tickets were found above:
Ticket 4917 --> https://svn.open-mpi.org/trac/ompi/ticket/4917
* remove config/ompi_config_solaris_threads.m4 which was dead code
* check if pthreads work "as is" on all platforms including Solaris
(FWIW, the test should have been skipped if Solaris threads are used
and not if configure is ran on a Solaris box)
Refs trac:4911
This commit was SVN r32792.
The following Trac tickets were found above:
Ticket 4911 --> https://svn.open-mpi.org/trac/ompi/ticket/4911
gfortran 4.8 does not support storage_size() on all relevant types
that we need. So add a configure test to check and see if the
compiler's storage_size() intrinsic supports enough types for us to do
MPI_SIZEOF.
Also remove an accidentally redundant check for fortran INTERFACE.
Refs trac:4917
This commit was SVN r32790.
The following Trac tickets were found above:
Ticket 4917 --> https://svn.open-mpi.org/trac/ompi/ticket/4917
1. Fixes according to (http://www.open-mpi.org/community/lists/devel/2014/09/15869.php)
2. Force mpisync:rank0 to gather results. Now sync info is written by rank0 to the output file.
3. Improve mpirun_prof: 1) adopt to the environment (SLURM/TORQUE); 2) recognize some noteset-related mpirun options.
This commit was SVN r32772.
What started as a simple ticket ended up reaching the way up to the
MPI Forum.
It turns out that we are supposed to have MPI_SIZEOF for all Fortran
interfaces: mpif.h, the mpi module, and the mpi_f08 module.
It further turns out that to properly support MPI_SIZEOF, your Fortran
compiler *has* support the INTERFACE keyword and ISO_FORTRAN_ENV. We
can't use "ignore TKR" functionality, because the whole point of
MPI_SIZEOF is that the implementation knows what type was passed to it
("ignore TKR" functionality, by definition, throws that information
away). Hence, we have to have an MPI_SIZEOF interface+implementation
for all intrinsic types, kinds, and ranks.
This commit therefore adds a perl script that generates both the
interfaces and implementations for MPI_SIZEOF in each of mpif.h, the
mpi module, and mpi_f08 module (yay consolidation!).
The perl script uses the results of some new configure tests:
* check if the Fortran compiler supports the INTERFACE keyword
* check if the Fortran compiler supports ISO_FORTRAN_ENV
* find the max array rank (i.e., dimension) that the compiler supports
If the Fortran compiler supports both INTERFACE and ISO_FORTRAN_ENV,
then we'll build the MPI_SIZEOF interfaces. If not, we'll skip
MPI_SIZEOF in mpif.h and the mpi module. Note that we won't build the
mpi_f08 module -- to include the MPI_SIZEOF interfaces -- if the
Fortran compiler doesn't support INTERFACE, ISO_FORTRAN_ENV, and a
whole bunch of ther modern Fortran stuff.
Since MPI_SIZEOF interfaces are now generated by the perl script, this
commit also removes all the old MPI_SIZEOF implementations (which were
laden with a zillion #if blocks).
cmr=v1.8.3
This commit was SVN r32764.
After discussions with Craig, it looks like the check in this
configure test was too aggressive and based on a prior mpi_f08
implementation model. We don't use "value" any more, and we also
don't pass optional parameters back to C code, so this test was
checking far more than it needed to... in a non-standard way (which
breaks in the Intel 2015 Fortran compiler). All we ''really'' need is
to check whether the compiler supports the "optional" keyword. So
make the test ''much'' simpler and just check whether ''optional''
compiles successfull or not.
Reviewed by Craig Rasmussen
cmr=v1.8.3:reviewer=ompi-rm1.8
This commit was SVN r32752.
Replace our old, clunky timing setup with a much nicer one that is only available if configured with --enable-timing. Add a tool for profiling clock differences between the nodes so you can get more precise timing measurements. I'll ask Artem to update the Github wiki with full instructions on how to use this setup.
This commit was SVN r32738.
1. It is not sufficient to put the result of m4_toupper() in a
variable and use that variable as the variable name in
AC_DEFINE_UNQUOTED. Instead, just use m4_toupper() directly in
AC_DEFINE_UNQUOTED. Also, save the result value in a "permanent"
variable that isn't erased, just in case autoconf decides to be lazy
about instantiating the body AC_DEFINE_UNQUOTED and move it later
(this is probably overkill :-) ).
1. Use the OMPI Way of always defining macros (to 0 or 1). Then also
slightly change the logic in util/basename.c to just check
OPAL_HAVE_DIRNAME (because it will always be defined).
Refs trac:4894
This commit was SVN r32723.
The following Trac tickets were found above:
Ticket 4894 --> https://svn.open-mpi.org/trac/ompi/ticket/4894
Based on a patch from Joshua Randall, improve the search for LSF
libraries in orte_check_lsf.m4. This improvement theorhetically
allows the LSF libraries to work in a variety of OSs by properly
searching for its dependent libraries using a variety of library
names.
Fixes trac:4889.
This commit was SVN r32722.
The following Trac tickets were found above:
Ticket 4889 --> https://svn.open-mpi.org/trac/ompi/ticket/4889
The AC_MSG_CHECKING/AC_MSG_RESULT in OPAL_SEARCH_LIBS_CORE were
generating recursive redundant output (i.e., AC_SEARCH_LIBS already
outputs "checking for library containing X... -lY".
Also add the "uppername" logic to OPAL_SEARCH_LIBS_COMPONENT so that
these two macros stay symmetrical.
Refs trac:4894.
This commit was SVN r32721.
The following Trac tickets were found above:
Ticket 4894 --> https://svn.open-mpi.org/trac/ompi/ticket/4894
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
This particular test can leave various <foo>.mod files in the OMPI top
build dir, which leads developers to say "what are these .mod files in
my 'svn status' output?".
So make a subdir, run the tests in there, and then remove the subdir.
Reviewed by Dave Goodell.
This is not 100% necessary for OMPI 1.7.4, but it would be nice. The
goal is to have this test removed by OMPI 1.7.5 (i.e., fix ticket
4157). So I leave it up to the RM to decide whether this goes into
1.7.4 or not.
cmr=v1.7.4:reviewer=ompi-rm1.7
This commit was SVN r30524.
Ensure that these two flags are in all of mpif.h, the mpi module, and
the mpi_f08 module. Thanks to Rolf Rabenseifner for pointing out the
issue.
cmr=v1.7.4:reviewer=ompi-rm1.7
This commit was SVN r30519.
for 32-bit architectures.
This commit also modifies _OMPI_CHECK_HEADER to use AC_CHECK_HEADERS instead
of AC_CHECK_HEADER. This allows components to check for multiple headers
instead of just one. The new semantics of the header check in OMPI_CHECK_PACKAGE
are to return success if at least one of the specified headers exists. The new
semantics will not break current usage.
cmr=v1.7.5:ticket=trac:4053
This commit was SVN r30476.
The following Trac tickets were found above:
Ticket 4053 --> https://svn.open-mpi.org/trac/ompi/ticket/4053
implementation does (that is not quite adherant to the Fortran
standard). If a compiler allows this behavior, build the mpi_f08
wrapper. For example, ifort allows it, but Pathscale/EKOPath 5.0 is
stricter in its Fortran compliance and disallows it.
This test is temporary; the real fix is to make OMPI adhere to Fortran
properly (i.e., see #4157). Once we fix#4157, this test should be
removed. The main reason for committing this test is to put it into
v1.7.4 so that we can release, but with the intent to remove it by
1.7.5 (or 1.8.x at the latest!).
Refs trac:4157
cmr=v1.7.4:reviewer=ompi-rm1.7:subject=Add mpi_f08-(non)compliance configure test
This commit was SVN r30440.
The following Trac tickets were found above:
Ticket 4157 --> https://svn.open-mpi.org/trac/ompi/ticket/4157
names longer than 32 characters.
Per discussion on the devel list starting here:
http://www.open-mpi.org/community/lists/devel/2014/01/13799.php we
need a new litmus test to disqualify older Fortran compilers (e.g.,
Pathscale 4.0.12) that *seem* to support all the Right Things, but a)
do not support BIND(C, name="super_long_name") or b) run into an
internal error when compiling our mpi_f08 module.
Testing for b) is sketchy at best. But OMPI has some BIND(C) names
that are >32 characters, and the same compilers that exhibit b) also
seem to not support BIND(C) names that are >32 characters (i.e., a)).
Hence, the following BIND(C) test checks to ensure that BIND(C,
name="foo") works, where "foo" is actually a name >32 characters.
cmr=v1.7.4:reviewer=rhc:subject=Update Fortran configure test to exclude older pathscale/open64 compilers from mpi_f08
This commit was SVN r30421.
fix the case, to enable oshmem-fortran when "with-shmem" was specified and "ompi-fortran" was enabled and happy.
fixed by Roman, reviewed by Miked
Refs trac:3763
This commit was SVN r30391.
The following Trac tickets were found above:
Ticket 3763 --> https://svn.open-mpi.org/trac/ompi/ticket/3763
As discovered by the nightly build, r30379 broke the case where
configure does not find a fortran compiler, and no form of
--enable-mpi-fortran was specified.
This commit specifically calls out the difference between a user
specifying that they want Fortran bindings and the default "try to
compile all the Fortran bindings" cases.
cmr=v1.7.4:ticket=4162
This commit was SVN r30386.
The following SVN revision numbers were found above:
r30379 --> open-mpi/ompi@7b28af54bb
The following Trac tickets were found above:
Ticket 4162 --> https://svn.open-mpi.org/trac/ompi/ticket/4162
So just take out this useless warning.
cmr=v1.7.5:ticket=4163
This commit was SVN r30383.
The following Trac tickets were found above:
Ticket 4163 --> https://svn.open-mpi.org/trac/ompi/ticket/4163
Each Fortran bindings layer builds on the other. Specifically:
* You can build just mpif.h support
* You can build mpif.h and "use mpi" support
* You can build mpif.h and "use mpi" and "use mpi_f08" support
You cannot build mpif.h and "use mpi_f08" support without also
building "use mpi" support.
This new functionality adds new capabilities to the existing
--enable-fortran-mpi switch. You can now pass the following values:
* --enable-fortran-mpi=no or none: synonyms for --disable-fortran-mpi
(i.e., build no Fortran bindings).
* --enable-fortran-mpi=mpifh: build only mpif.h support
* --enable-fortran-mpi=usempi: build mpif.h and "use mpi" support
* --enable-fortran-mpi=usempif08: build mpif.h, "use mpi", and "use
mpi_f08" support
* --enable-fortran-mpi=yes or all: synonyms for --enable-fortran-mpi
(i.e., no argument), which will attempt to build all 3 Fortran
bindings
cmr=v1.7.4:ticket=4162
This commit was SVN r30379.
The following Trac tickets were found above:
Ticket 4162 --> https://svn.open-mpi.org/trac/ompi/ticket/4162
The check to enable shmem fortran was too early, MPI can disable fortran but SHMEM fortran check was already done.
Refs trac:3763
This commit was SVN r30340.
The following Trac tickets were found above:
Ticket 3763 --> https://svn.open-mpi.org/trac/ompi/ticket/3763
Add a configure test to see if the Fortran compiler supports the
PROTECTED keyword. If it does, use in mpi-f08-types.F90 (via a macro
defined in configure-fortran-output-bottom.h).
This is needed to support the PGI 9 Fortran compiler, which does not
support the PROTECTED keyword.
Note that regardless of whether we want to support the PGI 9 Fortran
compiler + mpi_f08, we need to correctly detect whether PROTECTED
works or not, and then use that determination as a criteria for
building the mpi_f08 module. Previously, mpi-f08-types.F90 used
PROTECTED unconditionally, and we didn't test for it in configure. So
if a compiler (e.g., PGI 9) supported everything else but didn't
support PROTECTED, it would try to compile the mpi_f08 stuff and choke
on the use of PROTECTED.
Refs trac:4093
This commit was SVN r30273.
The following Trac tickets were found above:
Ticket 4093 --> https://svn.open-mpi.org/trac/ompi/ticket/4093
Just some minor updates to make some Fortran test outputs be a bit
more consistent with each other. This can definitely wait until
1.7.5, unless it causes conflicts with other changes that need to come
into 1.7.4.
cmr=v1.7.5:reviewer=dgoodell
This commit was SVN r30271.
This configure option was only relevant when we were generating TKR
"use mpi" interfaces for MPI subroutines with choice buffers. Now
that we aren't, the only interface that needs to accept a choice
buffer is MPI_SIZEOF (which we have to provide).
And since there's now only several dozen interfaces in the "mpi" TKR
module, there's no reason to not generate ''all'' possible array rank
values (when there were thousands of interfaces, generating 4-vs-7
array ranks per interface per type was a big deal). The default used
to be 4; now we can just hard-code it to 7, the max possible value for
Fortran 2003 (I think the max was raised ?to 11? in F2008, but let's
not go there for now).
cmr=v1.7.5:reviewer=dgoodell:subject=Remove even more dead Fortran configury
This commit was SVN r30257.
BIND(C), but not ''all'' of it. So expand our configure checks to
look for multiple different forms of BIND(C):
* ISO_C_BINDING
* SUBROUTINE ... BIND(C)
* TYPE, BIND(C)
* TYPE(foo), BIND(C, name="bar")
If the compiler supports all of these, then declare that we support
BIND(C), and the rest of the mpi_f08 checks can continue. If we miss
any one of those, don't bother continuing -- we won't build the
mpi_f08 module.
Also push the results of all of these tests down to ompi_info so that
they can be reported easily (e.g., "Hey, why doesn't my OMPI
installation have the mpi_f08 module?").
cmr=v1.7.4:reviewer=jsquyres:subject=Expand Fortran BIND(C) configure checks
This commit was SVN r30247.
This should have been part of r30151/#4057. Oops.
cmr=v1.7.4:reviewer=dgoodell
This commit was SVN r30246.
The following SVN revision numbers were found above:
r30151 --> open-mpi/ompi@52b5e17d97
upcoming GCC/gfortran 4.9's ignore TKR interface.
This was originally committed in a side mercurial repo, but I sadly
completely forgot about it until Tobias reminded me.
cmr=v1.7.5:reviewer=dgoodell:subject=Add support for gfortran 4.9 Fortran ignore TKR
This commit was SVN r30152.
This commit adds support for placing the send memory segment in a
traditional shared memory segment when XPMEM is not available. The
current default is to reserve 4MB for shared memory on each process.
The latest benchmarks show vader performing better than sm on both
Intel and AMD CPUs.
For large messages vader will now use CMA if it is available (and
XPMEM is not).
cmr=v1.7.5:reviewer=jsquyres
This commit was SVN r30123.
r30016 was not enough to solve the issue.
So properly prefix all the shell variables used in opal_setup_java.m4
(one of them had an orte_ prefix -- oops!). Now we won't get any
conflicts.
Refs trac:4015
This commit was SVN r30037.
The following SVN revision numbers were found above:
r30016 --> open-mpi/ompi@35dfd26f9e
The following Trac tickets were found above:
Ticket 4015 --> https://svn.open-mpi.org/trac/ompi/ticket/4015
This *should* fix following situation:
1 mxm.rpm puts /etc/ld.so.conf.d/mxm.conf file during rpm install with libpath to /opt/mellanox/mxm/lib
2 some1 can extract mxm.rpm into $HOME/mxm and compile OMPI with new mxm location
3 during runtime, OMPI from prev step will pick MXM from step (1) instead of from step (2)
cmr=v1.7.4:reviewer=ompi-rm1.7
This commit was SVN r30005.
got linked together (work on one caused work in the other):
* Clean up a bunch of VAR_SCOPE issues in configure. This includes:
* Using VAR_SCOPE_PUSH and VAR_SCOPE_POP in more places
* Cleaning up the use of some shell variables (e.g., name them better)
* Add support for external libevent via
--with-libevent=<dir-to-libevent-install-tree>, as specifically
asked for by downstream packagers.
* Revamp how wrapper compiler RPATH (and RUNPATH) support is done.
The external libevent work exposed weakenesses in how the original
RPATH/RUNPATH work was done, so we had to re-do it to be a bit more
robust.
This work has not yet been tested on Solaris.
Refs trac:3694
This commit was SVN r29899.
The following Trac tickets were found above:
Ticket 3694 --> https://svn.open-mpi.org/trac/ompi/ticket/3694
more:
- Remove OPAL_ENABLE_MULTI_THREADS, since it didn't really do anything
correctly. Opal always has threads enabled at this point.
- Remove OMPI_ENABLE_PROGRESS_THREADS, since this hasn't worked in
8 years and it has performance issues we'll never be able to
overcome. Note that we have plans for re-adding async progress, using
a hybrid protocol of async and sync sends.
- OMPI_ENABLE_THREAD_MULTIPLE now determines whether the thread lock
macros do the check or not.
- Condition variables are ALWAYS polling right now, which fixes the thread
live-lock currently found when THREAD_MULTIPLE is turned on.
This commit was SVN r29891.
http://www.open-mpi.org/community/lists/users/2013/10/22882.php, fix
the value of MPI_STATUS_SIZE for the -i8 case. Thanks to Jim Parker
for bringing up the issue and providing the patch.
Separate patches are required for v1.6 and v1.7 (and will be attached
to their respective tickets), because this breaks ABI, so we need a
non-default configure option to fix the issue but knowingly break ABI.
cmr=v1.7.4:reviewer=bosilca:subject=Fix MPI_STATUS_SIZE for -i8 case
cmr=v1.6.6:reviewer=bosilca:subject=Fix MPI_STATUS_SIZE for -i8 case
This commit was SVN r29858.
r29830 -- Jeff will straighten this out with Alexander in person next
week (I can't test this myself because I have no access to libhcoll).
Sorry for the hassle...
Refs trac:3694
This commit was SVN r29842.
The following SVN revision numbers were found above:
r29830 --> open-mpi/ompi@3bd9c603ff
The following Trac tickets were found above:
Ticket 3694 --> https://svn.open-mpi.org/trac/ompi/ticket/3694
needed in the global scope ($ompi_check_fca_dir). This commit removes
it from the OPAL_VAR_SCOPE, so it should be fixed now.
Sorry about that, folks! :-(
This commit was SVN r29838.
The following SVN revision numbers were found above:
r29830 --> open-mpi/ompi@3bd9c603ff
This is helpful in the work for #3694: ensure that many places that
eventually end up in configure don't overly-pollute the global shell
variable space (because debugging accidental shell variable pollution
can be a real pain).
Refs trac:3694
This commit was SVN r29830.
The following Trac tickets were found above:
Ticket 3694 --> https://svn.open-mpi.org/trac/ompi/ticket/3694
This prevents bazillions of warnings from clang tha -Wno-long-double
isn't supported.
The warning that clang issues when it see -Wno-long-double is does not
use any of the words we were looking for, so I added "unknown" to the
list of words to look for. I also re-indented the two m4 tests so
that they're a bit more readable.
cmr=v1.7.4:reviewer=brbarret:subject=Update -Wno-long-double test to support clang
This commit was SVN r29681.
patch. See ticket #3885, comment 10 for an explination of why calling
_STRINGIFY on something that's not a numerical constant is always a bad idea.
This commit was SVN r29613.
The following SVN revision numbers were found above:
r29608 --> open-mpi/ompi@b71bd51cdd
OSX atomic support is disabled by default. Enable with --enable-osx-builtin-atomics.
Fixes trac:2120
This commit was SVN r29568.
The following Trac tickets were found above:
Ticket 2120 --> https://svn.open-mpi.org/trac/ompi/ticket/2120
