we are part of the source tree and not defined otherwise, we are going
with an always defined if ompi_config.h is included policy. If
ompi_config.h is included before mpi.h or before OMPI_BUILDING is set,
it will set OMPI_BUILDING to 1 and enable all the internal code that
is in ompi_config_bottom.h. Otherwise, it will only include the
system configuration data (enough for defining the C and C++ interfaces
to MPI, but not perturbing the user environment).
This should fix the problems with bool and the like that the Eclipse
folks were seeing. It also cleans up some build system hacks that
we had along the way.
Also, don't use int64_t as the default size of MPI_Offset, because it
requires us including stdint.h in mpi.h, which is something we really
shouldn't be doing.
And finally, fix a ROMIO Makefile that didn't set -DOMPI_BUILDING=1,
as ROMIO includes mpi.h, but not ompi_config.h
This commit was SVN r5430.
having it in config/ompi_setup_cxx.m4
2. Adding --enable-coverage option. This will add teh flags -ftest-coverage
and -fprofile-arcs to the flags. Also, one needs to compile with
debug and static only to enable code coverage
3. Adding the coverage flag options to WRAPPER_*_FLAGS so that mpicc and co.,
will add these to teh executables when they are compiled
This commit was SVN r5416.
Monday with Craig:
- split two f90 modules into two separate .f90 files so that
dependencies can be satisfied properly in parallel builds (i.e.,
mpi_kinds.f90 can be compiled and its f90 module can be generated
before any others are compiled, because it is needed by all of the
other f90 source files).
- rename mpi.i.h* to be mpi-f90-interfaces.h, just to be a little more
clear and less name-confusing with mpi.h and mpif.h
- update the build process in src/mpi/f90, including printing out a
warning that compiling mpi.f90 may take quite a while :-\
- update the wrapper compilers to add in the Right Things for
compiling F90 MPI applications
- add a check in configure to find what flag the F90 compiler uses to
identify where f90 module files live
This commit was SVN r5297.
linked into libmpi
* add --enable-mca-direct to specify components that should be directly
called (instead of going through component structs and the like). The
components and component frameworks must explicitly support this.
Currently, only the TEG PML does so.
* Updated all the calls to the PML to use a macro so that they can either
be direct called or called through function pointer interfaces (aka
the component infrastructure)
This commit was SVN r5291.
dimensions the f90 MPI bindings should support (they are strongly
typed, and the number of dimensions of choice arguments must be
specified -- it cannot be arbitrary). The default is four.
Note that even though increasing this value has essentially a linear
effect on the code, the multiplier constant is fairly large (only a
small number of functions have 2 choice buffers, so the exponential
factor is relatively small). Increasing this value increases the
amount of time f90 compilers will spend compiling src/mpi/f90/mpi.f90
(some compilers will crash if it is too big).
This commit was SVN r5268.
more obvious (and documented)
- VERSION now has lots of comments in it
- separate out whether we want the SVN r number in the version and
what the SVN r number is
- clearly describe the process for building the full version number
string
- make ompi info have a separate line item specifically for the SVN r
number, regardless of what the version number is
- update "make dist" process to substitute in the SVN r version
This commit was SVN r5022.
* SPARC Assembly fixes:
- Use SPARC assembly type only when not able to use the SPARC v9
instruction set (instead of previous whenever sizeof(void*) == 4
- Use SPARCV9_32 (aka sparc v8plus) and SPARCV9_64 (aka sparc v9) when
possible. Already were doing so for the 64bit, but on 32bit we
were falling back to SPARC.
- Implemented SPARCV9_32 atomic operations
- Emit warning if user is going to get SPARC atomic, as that probably
isn't what the user wants for best performance.
* Started shell of MIPS assembly. Does not work, but wanted something
so that everyone would only have to re-autogen once today....
This commit was SVN r4465.
threads (defaults to use MPI threads, disable progress threads). This
allows us to have MPI threaded support, but without progress threads
and all that fun stuff.
This commit was SVN r4443.
the test barfs on AIX, since it has some strange non-mangling of the
labels in the inline assembly that all the other platforms seem to be
ok making right. *sigh*
This commit was SVN r4365.
script in components and distributes them as appropriate throughout
the tree (previously, we only did WRAPPERS_* flags). These flags are
*only* used when libmpi is being build statically (--disable-shared
--enable-static).
I also added another classification of flags -- LIBMPI_ALWAYS_* and
WRAPPERS_ALWAYS_* for flags that should always be added to the libmpi
/ wrapper linker lines, not just when compiling libmpi statically.
This commit was SVN r4322.
test for the pthread-library fails, due to pthread_t th
not being initialized.
Fix remaining warnings (hopefully correctly casted).
Spelling buglet in help-output for mpirun
This commit was SVN r4272.
looks like we need to do the same thing for UltaSparc / MIPS machines
* The atomic_cmpset_64 bit code made some assumptions about calling
convention that wouldn't be true if the function was inlined. Fix
those assumptions, so we should work fine whether GCC inlines
the function or not.
This commit was SVN r4249.
of assembler format
* Fix minor bugs in AMD64, PPC, and IA32 assembly for atomic operations
* Clean up the #defines to look for when examining level of atomic operation
support
This commit was SVN r4183.
from themselves -- but doesn't look valid. For example, it's legal to
have $FC and $F77 to both be ifort (intel fortran compiler).
This commit was SVN r4148.
Note: in bringing this across, I have obeyed the mca-prefix-rule in defining functions and variables. However, I left the name of the component call as "orte_errmgr.xxx" so that any use of the code will directly "merge" with the new RTE branch without changes.
This commit was SVN r4099.
which was resulting in the pthreads functions never getting linked in.
Which would cause false positives on the threading tests. Make sure
that there is a call chain from main() -> pthread_create(), which should
be enough to make the test happy.
This commit was SVN r3998.
