This commit is related to an RFC from June 2014. Disscussion can be
found at:
http://www.open-mpi.org/community/lists/devel/2014/07/15140.php
The finalize function is set using either the linker option -fini or
__attribute__((destructor)) depending on compiler support. I have
confirmed that this hybrid approach works with all the major
compilers. The attribute is supported by gcc, clang, llvm, xlc, and
icc. The fini function will support pgi. If a compiler/linker
combination does not support either the destructor or fini function a
message will be printed on re-init indicating it is not supported (an
improvement over the current behavior-- SEGV).
I moved the following to the destructor function:
- Class system finalize. This solves a bug when MPI_T_finalize is
called before MPI_Init. The only downside to this change is we will
leave the footprint of the opal class system after
MPI_Finalize. This footprint should be relatively small.
This is an alternative to #517 but the two PRs are not
mutually-exclusive (with some modifications). This commit should also
be safe for 1.8.x as it does not change internal or external ABI (#517
changes internal ABI).
Signed-off-by: Nathan Hjelm <hjelmn@lanl.gov>
Apologies for the breakage, I did my test build in the wrong window...
No reviewer.
cmr=v1.7.4:ticket=3865
This commit was SVN r29492.
The following SVN revision numbers were found above:
r29488 --> open-mpi/ompi@25dd719d4d
The following Trac tickets were found above:
Ticket 3865 --> https://svn.open-mpi.org/trac/ompi/ticket/3865
First cut does not attempt any "cross-check". As we discover compilers
which complain about __noinline__, we will add specific cross checks to
handle those cases.
Reviewed-by: Jeff Squyres <jsquyres@cisco.com>
This commit was SVN r29488.
config/ directory. We split them apart a while ago in the hopes that
it would simplify things, but it didn't really (e.g., because there
were still some ompi/opal .m4 files in the top-level config/
directory, resulting in developer confusion where any given m4 macro
was defined).
So this commit consolidates them back into the top-level directory for
simplicity.
There's still (at least) two changes that would be nice to make:
1. Split any generated .m4 file (e.g., autogen-generated .m4 files)
into a separate directory somewhere so that a top-level -Iconfig/
will only get our explicitly defined macros, not the autogen stuff
(e.g., with libevent2019 needing to get the visibility macro, but
NOT all the autogen-generated inclusion of component configure.m4
files).
1. Change configure to be of the form:
{{{
# ...a small amount of preamble/setup...
OPAL_SETUP
m4_ifdef([project_orte], [ORTE_SETUP])
m4_ifdef([project_ompi], [OMPI_SETUP])
# ...a small amount of finishing stuff...
}}}
I doubt we'll ever get anything as clean as that, but that would be
the goal to shoot for.
This commit was SVN r27704.
Continue the reorganization of the configure system. Move files from the main config directory to their appropriate level-specific config directories. Modify the configure system to correctly handle compiler detection, test, and setup so that all things pertaining to opal and orte are done at the lower level, with the ompi configure system only looking at mpi-specific options.
Ensure the wrapper compilers for orte and ompi only get built when appropriate. Add support for c++ to the orte wrapper compilers, both script and non-script versions.
This commit was SVN r22138.
Re-enable "./autogen.sh -no-ompi" again. If you -no-ompi, the entire OMPI
configury is skipped and the entire ompi/ subtree is not built. There's
some simple m4-isms that prune out the relevant parts.
I added ompi/config/, orte/config/, and opal/config/ directories. I moved a
bunch of m4 files from the top-level config/ dir into ompi/config/, and a few
into orte/config/.
Note that all 3 <project>/config directories have a config_files.m4 file. This
file contains the AC_CONFIG_FILES list for that project. The AC_CONFIG_FILES
call cannot be in an AC_DEFUN macro and conditionally called -- if it is
included at all, Autoconf will process it. Hence, these config_files.m4 files
don't AC_DEFUN -- they just have AC_CONFIG_FILES. m4_ifdef() is used to
conditionally include the files or not.
I moved a bunch of obvious OMPI-only m4 files from config/ to ompi/config/,
but I'm sure that there's more that could go. A ticket will be filed with
thoughts on future work in this area.
This commit was SVN r22113.
functionality (per MPI-2.1). This warning can be toggled using
--enable-mpi-interface-warning (default OFF), but can be
selectively turned on passing
mpicc -DOMPI_WANT_MPI_INTERFACE_WARNING
Using icc, gcc < 4.5, warnings (such as in mpi2basic_tests) show:
type_vector.c:83: warning: ‘MPI_Type_hvector’ is deprecated
(declared at /home/../usr/include/mpi.h:1379)
Using gcc-4.5 (gcc-svn) these show up as:
type_vector.c:83: warning: ‘MPI_Type_hvector’ is deprecated
(declared at /home/../usr/include/mpi.h:1379):
MPI_Type_hvector is superseded by MPI_Type_create_hvector in MPI-2.0
Jeff and I propose to turn such warnings on with Open MPI-1.7 by default.
- Detection of user-level compiler is handled using the preprocessor
checks of GASnet's other/portable_platform.h (thanks to Paul Hargrove
and Dan Bonachea) adapted into ompi/include/mpi_portable_platform.h
(see comments).
The OMPI-build time detection is output (Familyname and Version)
with ompi_info.
This functionality (actually any upcoming __attribute__) are turned
off, if a different compiler (and version) is being detected.
- Note, that any warnings regarding (user-compiler!=build-compiler)
as discussed in the RFC are _not_ included for now.
- Tested on Linux with --enable-mpi-interface-warning on
Linux, gcc-4.5 (deprecated w/ specific msg)
Linux, gcc-4.3 (deprecated w/o specific msg)
Linux, pathscale 3.1 (deprecated w/o specific msg)
Linux, icc-11.0 (deprecated w/o specific msg)
Linux, PGI-8.0.6 accepts __deprecated__ but does not issue a warning,
further investigation needed...
This commit was SVN r21262.