This commit:
* Adds the configury to figure out how many Fortran INTEGERs are
necessary to represent the C MPI_Status (which now includes a size_t
member).
* Sets MPI_STATUS_SIZE to this value in mpif-config.h.in.
* Adds a big comment in status_c2f.c explaining why the no changes
were necessary to how we copy statuses between Fortran and C.
This commit was SVN r23472.
The following SVN revision numbers were found above:
r23467 --> open-mpi/ompi@733d25a8a3
r23468 --> open-mpi/ompi@963fcb13a5
r23470 --> open-mpi/ompi@418b989781
r23471 --> open-mpi/ompi@bc74a446ac
step is the configure and Fortran mojo that Jeff will put in. Until then I
guess the Fortran interface is broken (at least all functions using the hidden
count firld in the MPI_Status).
This commit was SVN r23467.
from "MPI_*_errhandler_fn" to "MPI_*_errhandler_function" (and their
corresponding C++ types, too). Also updated the corresponding man
pages, and marked the typedefs to the now-deprecated types as
deprecated.
This commit was SVN r22122.
The following Trac tickets were found above:
Ticket 2060 --> https://svn.open-mpi.org/trac/ompi/ticket/2060
#if defined (c_plusplus)
defined (__cplusplus)
followed by
extern "C" {
and the closing counterpart by BEGIN_C_DECLS and END_C_DECLS.
Notable exceptions are:
- opal/include/opal_config_bottom.h:
This is our generated code, that itself defines BEGIN_C_DECL and
END_C_DECL
- ompi/mpi/cxx/mpicxx.h:
Here we do not include opal_config_bottom.h:
- Belongs to external code:
opal/mca/backtrace/darwin/MoreBacktrace/MoreDebugging/MoreBacktrace.c
opal/mca/backtrace/darwin/MoreBacktrace/MoreDebugging/MoreBacktrace.h
- opal/include/opal/prefetch.h:
Has C++ specific macros that are protected:
- Had #if ... } #endif _and_ END_C_DECLS (aka end up with 2x
END_C_DECLS)
ompi/mca/btl/openib/btl_openib.h
- opal/event/event.h has #ifdef __cplusplus as BEGIN_C_DECLS...
- opal/win32/ompi_process.h: had extern "C"\n {...
opal/win32/ompi_process.h: dito
- ompi/mca/btl/pcie/btl_pcie_lex.l: needed to add *_C_DECLS
ompi/mpi/f90/test/align_c.c: dito
- ompi/debuggers/msgq_interface.h: used #ifdef __cplusplus
- ompi/mpi/f90/xml/common-C.xsl: Amend
Tested on linux using --with-openib and --with-mx
The following do not contain either opal_config.h, orte_config.h or
ompi_config.h
(but possibly other header files, that include one of the above):
ompi/mca/bml/r2/bml_r2_ft.h
ompi/mca/btl/gm/btl_gm_endpoint.h
ompi/mca/btl/gm/btl_gm_proc.h
ompi/mca/btl/mx/btl_mx_endpoint.h
ompi/mca/btl/ofud/btl_ofud_endpoint.h
ompi/mca/btl/ofud/btl_ofud_frag.h
ompi/mca/btl/ofud/btl_ofud_proc.h
ompi/mca/btl/openib/btl_openib_mca.h
ompi/mca/btl/portals/btl_portals_endpoint.h
ompi/mca/btl/portals/btl_portals_frag.h
ompi/mca/btl/sctp/btl_sctp_endpoint.h
ompi/mca/btl/sctp/btl_sctp_proc.h
ompi/mca/btl/tcp/btl_tcp_endpoint.h
ompi/mca/btl/tcp/btl_tcp_ft.h
ompi/mca/btl/tcp/btl_tcp_proc.h
ompi/mca/btl/template/btl_template_endpoint.h
ompi/mca/btl/template/btl_template_proc.h
ompi/mca/btl/udapl/btl_udapl_eager_rdma.h
ompi/mca/btl/udapl/btl_udapl_endpoint.h
ompi/mca/btl/udapl/btl_udapl_mca.h
ompi/mca/btl/udapl/btl_udapl_proc.h
ompi/mca/mtl/mx/mtl_mx_endpoint.h
ompi/mca/mtl/mx/mtl_mx.h
ompi/mca/mtl/psm/mtl_psm_endpoint.h
ompi/mca/mtl/psm/mtl_psm.h
ompi/mca/pml/cm/pml_cm_component.h
ompi/mca/pml/csum/pml_csum_comm.h
ompi/mca/pml/dr/pml_dr_comm.h
ompi/mca/pml/dr/pml_dr_component.h
ompi/mca/pml/dr/pml_dr_endpoint.h
ompi/mca/pml/dr/pml_dr_recvfrag.h
ompi/mca/pml/example/pml_example.h
ompi/mca/pml/ob1/pml_ob1_comm.h
ompi/mca/pml/ob1/pml_ob1_component.h
ompi/mca/pml/ob1/pml_ob1_endpoint.h
ompi/mca/pml/ob1/pml_ob1_rdmafrag.h
ompi/mca/pml/ob1/pml_ob1_recvfrag.h
ompi/mca/pml/v/pml_v_output.h
opal/include/opal/prefetch.h
opal/mca/timer/aix/timer_aix.h
opal/util/qsort.h
test/support/components.h
This commit was SVN r21855.
The following SVN revision numbers were found above:
r2 --> open-mpi/ompi@58fdc18855
not end up in OPAL
- Will post an updated patch for the OMPI_ALIGNMENT_ parts (within C).
This commit was SVN r21342.
The following SVN revision numbers were found above:
r21330 --> open-mpi/ompi@95596d1814
MTT caught builds failing with the following error which flagged the problem:
{{{
param.cc:802: error: ‘MPI_MAX_DATAREP_STRING’ was not declared in this scope
}}}
This commit was SVN r21337.
The following SVN revision numbers were found above:
r21308 --> open-mpi/ompi@2f9765926e
into the OPAL namespace, eliminating cases like opal/util/arch.c
testing for ompi_fortran_logical_t.
As this is processor- and compiler-related information
(e.g. does the compiler/architecture support REAL*16)
this should have been on the OPAL layer.
- Unifies f77 code using MPI_Flogical instead of opal_fortran_logical_t
- Tested locally (Linux/x86-64) with mpich and intel testsuite
but would like to get this week-ends MTT output
- PLEASE NOTE: configure-internal macro-names and
ompi_cv_ variables have not been changed, so that
external platform (not in contrib/) files still work.
This commit was SVN r21330.
MPI_MAX_PROCESSOR_NAME
MPI_MAX_ERROR_STRING
MPI_MAX_OBJECT_NAME
MPI_MAX_INFO_KEY
MPI_MAX_INFO_VAL
MPI_MAX_PORT_NAME
MPI_MAX_DATAREP_STRING
Defaults stay as theyr currently are -- and now give an explanation on the
min/max values being used in a central place...
m4-macro _OPAL_WITH_OPTION_MIN_MAX_VALUE may be benefical in other parts
of the configure system.
- We need some of these in the lower level OPAL for an upcoming commit!
All other levels base their values on them.
This commit was SVN r21292.
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.
OMPI_* to OPAL_*. This allows opal layer to be used more independent
from the whole of ompi.
NOTE: 9 "svn mv" operations immediately follow this commit.
This commit was SVN r21180.
- Delete unnecessary header files using
contrib/check_unnecessary_headers.sh after applying
patches, that include headers, being "lost" due to
inclusion in one of the now deleted headers...
In total 817 files are touched.
In ompi/mpi/c/ header files are moved up into the actual c-file,
where necessary (these are the only additional #include),
otherwise it is only deletions of #include (apart from the above
additions required due to notifier...)
- To get different MCAs (OpenIB, TM, ALPS), an earlier version was
successfully compiled (yesterday) on:
Linux locally using intel-11, gcc-4.3.2 and gcc-SVN + warnings enabled
Smoky cluster (x86-64 running Linux) using PGI-8.0.2 + warnings enabled
Lens cluster (x86-64 running Linux) using Pathscale-3.2 + warnings enabled
This commit was SVN r21096.
opal layer.
Add a check against a maximum (actually get rid of ifs internally to
opal_bitmap.c) -- the functionality to set the current maximum size
opal_bitmap_set_max_size() is currently only used in attribute.c
to set the maximum OMPI_FORTRAN_HANDLE_MAX...
Tested on linux/x86-64 with intel-tests with all_tests_no_perf_f
run with 6 procs.
Let's look into MTT as well...
This commit was SVN r20708.
* New "op" MPI layer framework
* Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2)
= Op framework =
Add new "op" framework in the ompi layer. This framework replaces the
hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples
for pre-defined MPI_Ops, allowing components and modules to provide
the back-end functions. The intent is that components can be written
to take advantage of hardware acceleration (GPU, FPGA, specialized CPU
instructions, etc.). Similar to other frameworks, components are
intended to be able to discover at run-time if they can be used, and
if so, elect themselves to be selected (or disqualify themselves from
selection if they cannot run). If specialized hardware is not
available, there is a default set of functions that will automatically
be used.
This framework is ''not'' used for user-defined MPI_Ops.
The new op framework is similar to the existing coll framework, in
that the final set of function pointers that are used on any given
intrinsic MPI_Op can be a mixed bag of function pointers, potentially
coming from multiple different op modules. This allows for hardware
that only supports some of the operations, not all of them (e.g., a
GPU that only supports single-precision operations).
All the hard-coded back-end MPI_Op functions for (MPI_Op,
MPI_Datatype) tuples still exist, but unlike coll, they're in the
framework base (vs. being in a separate "basic" component) and are
automatically used if no component is found at runtime that provides a
module with the necessary function pointers.
There is an "example" op component that will hopefully be useful to
those writing meaningful op components. It is currently
.ompi_ignore'd so that it doesn't impinge on other developers (it's
somewhat chatty in terms of opal_output() so that you can tell when
its functions have been invoked). See the README file in the example
op component directory. Developers of new op components are
encouraged to look at the following wiki pages:
https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogenhttps://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponenthttps://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework
= MPI_REDUCE_LOCAL =
Part of the MPI-2.2 proposal listed here:
https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24
is to add a new function named MPI_REDUCE_LOCAL. It is very easy to
implement, so I added it (also because it makes testing the op
framework pretty easy -- you can do it in serial rather than via
parallel reductions). There's even a man page!
This commit was SVN r20280.
corrections to non-windows files (but within ifdef __WINDOWS__)
type casts, event library for windows use win32.
in orte runtime, add windows sockets handling and object construction.
This commit was SVN r20110.
Rationale:
1. This value has already changed since v1.2 (v1.2 MPI_MAX_PORT_NAME
== 36). Hence, this commit simply increases the value from a
previous change.
1. The changes does increase OMPI's memory footprint slightly, but
only when using MPI-2 dynamics. So it is expected that the change
will have minimal impact on the overall footprint.
1. The change is helpful for nodes that have 4 or more IP networks
(e.g., regular ethernet and multiple IP-over-<pick your favorite
high-speed network> networks). Without this change, invoking
MPI_COMM_SPAWN on hosts with 4 or more IP networks will fail
because we'll exceed 256 bytes for the port name. Some OMPI
developer test clusters already have this kind of configuration
(e.g., Cisco); it is expected that this is not too common in the
real world yet, but with "manycore" coming, having multiple
IP-based networks in a single server will likely become more
common.
This commit was SVN r19638.
This fixes trac:1477.
Help provided by Jeff and Terry.
This commit was SVN r19533.
The following Trac tickets were found above:
Ticket 1477 --> https://svn.open-mpi.org/trac/ompi/ticket/1477
* Various changes to enable 0-dimensional cartesian communicators:
* Set various mtc_* members to NULL when there are 0 dimensions (and
don't bother trying to memcpy these arrays when duplicating the
communicator -- because they're NULL)
* adjust topo_base_cart_sub to correctly handle 0 dimensions
(simplified it a bit)
* adjust a few error codes to return ERR_OUT_OF_RESOURCE
* adjust error checking of CART_CREATE, CART_RANK
* Allow MPI_GRAPH_CREATE to accept 0 == nnodes.
* Bump reported MPI version in mpi.h to 2.1
This commit was SVN r19461.
The following Trac tickets were found above:
Ticket 1236 --> https://svn.open-mpi.org/trac/ompi/ticket/1236
* add "register" function to mca_base_component_t
* converted coll:basic and paffinity:linux and paffinity:solaris to
use this function
* we'll convert the rest over time (I'll file a ticket once all
this is committed)
* add 32 bytes of "reserved" space to the end of mca_base_component_t
and mca_base_component_data_2_0_0_t to make future upgrades
[slightly] easier
* new mca_base_component_t size: 196 bytes
* new mca_base_component_data_2_0_0_t size: 36 bytes
* MCA base version bumped to v2.0
* '''We now refuse to load components that are not MCA v2.0.x'''
* all MCA frameworks versions bumped to v2.0
* be a little more explicit about version numbers in the MCA base
* add big comment in mca.h about versioning philosophy
This commit was SVN r19073.
The following Trac tickets were found above:
Ticket 1392 --> https://svn.open-mpi.org/trac/ompi/ticket/1392
Benefits of this function will be using less memory, compactness and better performance. Thanks to George.
Keep the old memchecker function as well in case of convertor is not available.
This commit was SVN r18084.
implement specific function, thereby
removing bogus requirement on valgrind/valgrind.h
dough...
- Call specific function runindebugger() before
doing expensive checks on each component of struct.
- Get rid of void* warnings..
This commit was SVN r17438.
ensure that including valgrind.h is within the WANT_MEMCHECKER macro.
But this does not seem right; memchecker is a framework and valgrind
is the component -- why are we including a component-specific header
file in a top-level OMPI .h file? It seems like there should be a
memchecker .h file that generically hides these component-specific
details (i.e., what if we add some other memchecker components
someday?).
This commit was SVN r17432.
This commit brings over all the work from the /tmp-public/datarep
branch. See commits r16855, r16859, r16860 for the highlights of what
was done.
This commit was SVN r16891.
The following SVN revisions from the original message are invalid or
inconsistent and therefore were not cross-referenced:
r16855
r16859
r16860
The following Trac tickets were found above:
Ticket 1029 --> https://svn.open-mpi.org/trac/ompi/ticket/1029
methods (in order of precedence):
1. #pragma ident <ident string> (e.g., Intel and Sun)
1. #ident <ident string> (e.g., GCC)
1. static const char ident[] = <ident string> (all others)
By default, the ident string used is the standard Open MPI version string. Only
the following libraries will get the embedded version strings (e.g., DSOs will
not):
* libmpi.so
* libmpi_cxx.so
* libmpi_f77.so
* libopen-pal.so
* libopen-rte.so
* Added two new configure options:
* `--with-package-name="STRING"` (defaults to "Open MPI username@hostname
Distribution"). `STRING` is displayed by `ompi_info` next to the "Package"
heading.
* `--with-ident-string="STRING"` (defaults to the standard Open MPI version
string - e.g., X.Y.Zr######). `%VERSION%` will expand to the Open MPI
version string if it is supplied to this configure option.
This commit was SVN r16644.
The default odls has been updated and works fine. The process odls has been updated, but I could not verify its operation. The bproc ODLS has not been updated yet. Ralph will look at it soon.
This commit was SVN r15257.
of Fortran datatypes (mpif-common.h) and the list of registered
datatypes: MOOG(REAL2).
Configure and Compilation with ia32/gcc just finished, naturally
without real2.
This commit was SVN r15137.
to make checks for MPI-implementations fail in the right way ,-]
- check in configure.ac
- BINARY INCOMPATIBLE change to mpif-common.h
(if implemented the *right* way)
Actually OMPI_F90_CHECK takes two arguments, not three.
- Only have corresponding C-Type, if the opt. Fortran
type is really supported,
Otherwise pass ompi_mpi_unavailable to DECLARE_MPI_SYNONYM_DDT;
- Reviewed by George and Jeff
This commit was SVN r15133.
via the visibility feature that is provided by some compilers.
Per default this feature is disabled, to enable it you need to
configure with --enable-visibility and obviously you need a compiler
with visibility support. Please refer to the wiki for more information.
https://svn.open-mpi.org/trac/ompi/wiki/Visibility
This commit was SVN r14582.
provide one for the internals of Open MPI. For mpi.h, typedef MPI_Aint
either to ptrdiff_t or whatever we used as ptrdiff_t if that type doesn't
actually exist.
This commit was SVN r12212.
The following SVN revision numbers were found above:
r12146 --> open-mpi/ompi@8852c00c36
size and diplacement of data-type. After this patch all data can contain size_t bytes
and the displacements are defined as ptrdiff_t. All of the files I was able to compile
have been modified to match this requirement.
This commit was SVN r12146.
some issues with the C #defines SEEK_{SET, END, POS}. The workaround
involves some hackery that should work in almost every common use case
for the C stdio constants (and all the legal issues of the MPI constants).
The one issue is that the C stdio constants are now const ints instead
of #defines, which means that #ifdef checks will fail for the constants.
Behavior can be disabled at either configure time or build time.
Refs trac:387
This commit was SVN r12121.
The following Trac tickets were found above:
Ticket 387 --> https://svn.open-mpi.org/trac/ompi/ticket/387
Make the Fortran MPI_MAX_DATAREP_STRING follow the same convention as
the rest of the Fortran constants -- be one less than the C constant
of the same name.
This commit was SVN r11842.
The following Trac tickets were found above:
Ticket 389 --> https://svn.open-mpi.org/trac/ompi/ticket/389
- everything statically built (dynamically opened).
- OPAL, ORTE and OMPI static libraries and all the components
as dynamic files(DLL).
- everything as dynamic files (DLL).
This commit was SVN r11461.
and MPI_WIN_DISP_UNIT were off by one from their C counterparts.
This fixes trac:304.
This commit was SVN r11385.
The following Trac tickets were found above:
Ticket 304 --> https://svn.open-mpi.org/trac/ompi/ticket/304
different macros, one for each project. Therefore, now we have OPAL_DECLSPEC,
ORTE_DECLSPEC and OMPI_DECLSPEC. Please use them based on the sub-project.
This commit was SVN r11270.
releases on Linux and OS X) don't handle const_cast<> of 2-dimensional
arrays properly. If we're using one of the compilers that isn't friendly
to such casts, fall back to a standard C-style cast.
refs: #271
This commit was SVN r11263.
users mailing list:
http://www.open-mpi.org/community/lists/users/2006/07/1680.php
Warning: this log message is not for the weak. Read at your own
risk.
The problem was that we had several variables in Fortran common blocks
of various types, but their C counterparts were all of a type
equivalent to a fortran double complex. This didn't seem to matter
for the compilers that we tested, but we never tested static builds
(which is where this problem seems to occur, at least with the Intel
compiler: the linker compilains that the variable in the common block
in the user's .o file was of one size/alignment but the one in the C
library was a different size/alignment).
So this patch fixes the sizes/types of the Fortran common block
variables and their corresponding C instantiations to be of the same
sizes/types.
But wait, there's more.
We recently introduced a fix for the OSX linker where some C versions
of the fortran common block variables (e.g.,
_ompi_fortran_status_ignore) were not being found when linking
ompi_info (!). Further research shows that the code path for
ompi_info to require ompi_fortran_status_ignore is, unfortunately,
necessary (a quirk of how various components pull in different
portions of the code base -- nothing in ompi_info itself requires
fortran or MPI knowledge, of course).
Hence, the real problem was that there was no code path from ompi_info
to the portion of the code base where the C globals corresponding to
the Fortran common block variables were instantiated. This is because
the OSX linker does not automatically pull in .o files that only
contain unintialized global variables; the OSX linker typically only
pulls in a .o file from a library if it either has a function that is
used or have a global variable that is initialized (that's the short
version; lots of details and corner cases omitted). Hence, we changed
the global C variables corresponding to the fortran common blocks to
be initialized, thereby causing the OSX linker to pull them in
automatically -- problem solved. At the same time, we moved the
constants to another .c file with a function, just for good measure.
However, this didn't really solve the problem:
1. The function in the file with the C versions of the fortran common
block variables (ompi/mpi/f77/test_constants_f.c) did not have a
code path that was reachable from ompi_info, so the only reason
that the constants were found (on OSX) was because they were
initialized in the global scope (i.e., causing the OSX compiler to
pull in that .o file).
2. Initializing these variable in the global scope causes problems for
some linkers where -- once all the size/type problems mentioned
above were fixed -- the alignments of fortran common blocks and C
global variables do not match (even though the types of the Fortran
and C variables match -- wow!). Hence, initializing the C
variables would not necessarily match the alignment of what Fortran
expected, and the linker would issue a warning (i.e., the alignment
warnings referenced in the original post).
The solution is two-fold:
1. Move the Fortran variables from test_constants_f.c to
ompi/mpi/runtime/ompi_mpi_init.c where there are other global
constants that *are* initialized (that had nothing to do with
fortran, so the alignment issues described above are not a factor),
and therefore all linkers (including the OSX linker) will pull in
this .o file and find all the symbols that it needs.
2. Do not initialize the C variables corresponding to the Fortran
common blocks in the global scope. Indeed, never initialize them
at all (because we never need their *values* - we only check for
their *locations*). Since nothing is ever written to these
variables (particularly in the global scope), the linker does not
see any alignment differences during initialization, but does make
both the C and Fortran variables have the same addresses (this
method has been working in LAM/MPI for over a decade).
There were some comments here in the OMPI code base and in the LAM
code base that stated/implied that C variables corresponding to
Fortran common blocks had to have the same alignment as the Fortran
common blocks (i.e., 16). There were attempts in both code bases to
ensure that this was true. However, the attempts were wrong (in both
code bases), and I have now read enough Fortran compiler documentation
to convince myself that matching alignments is not required (indeed,
it's beyond our control). As long as C variables corresponding to
Fortran common blocks are not initialized in the global scope, the
linker will "figure it out" and adjust the alignment to whatever is
required (i.e., the greater of the alignments). Specifically (to
counter comments that no longer exist in the OMPI code base but still
exist in the LAM code base):
- there is no need to make attempts to specially align C variables
corresponding to Fortran common blocks
- the types and sizes of C variables corresponding to Fortran common
blocks should match, but do not need to be on any particular
alignment
Finally, as a side effect of this effort, I found a bunch of
inconsistencies with the intent of status/array_of_statuses
parameters. For all the functions that I modified they should be
"out" (not inout).
This commit was SVN r11057.
cannot include the PMPI_WTIME|WTICK functions in the external and
double precision statements because some compilers complain about
this. Instead, we need to use the macro that is defined by
configure.ac (MPIF_H_PMPI_W_FUNCS). This unfortunately means that we
need to generate mpif.h (in addition to mpif-config.h) because the
"external" statement is toxic to F90 compilers.
This commit was SVN r10464.
was that declaring the type of MPI_WTICK and MPI_TIME in mpif-common.h
would allow the F90 bindings to call through to the back end f77
function and have the right return type. But upon reflection, that's
silly -- we were just declaring the variables MPI_WTICK and MPI_WTIME
that were of type double precision. Duh.
So add some fixed (non-generated) wrapper F90 functions to call the
back-end *C* MPI_WTICK and MPI_TIME functions (vs. the back end *F77*
functions). We have to call the back-end C functions because there's
a name conflict if we try to call the back-end F77 functions -- for
the same reasons that we can't "implicitly" define MPI_WTIME and
MPI_WTICK in the f90 module, we can't call such an implicitly-defined
function. So we had to add new back-end C functions that are directly
callable from Fortran, the easiest implementation of which was to
provide 4 one-line functions for each (rather than muck around with
weak symbols).
This commit was SVN r10448.
* Change the type of Fortan's MPI_STATUSES_IGNORE to double complex
so that it will never possibly be mistaken for a real status (i.e.,
integer(MPI_STATUS_SIZE)), particularly in the F90 bindings. See
comment in mpif-common.h explaining this (analogous argument to
MPI_ARGVS_NULL for MPI_COMM_SPAWN_MULTIPLE).
* Add second interfaces for the following functions that take a double
complex (i.e., MPI_STATUSES_IGNORE). This required adding the second
interface in mpi-f90-interfaces.h[.sh] and then generating new wrapper
functions to call the back-end F77 function for each of these four, so
we added 4 new files in ompi/mpi/f90/scripts/ and updated the various
Makefile.am's to match:
* MPI_TESTALL
* MPI_TESTSOME
* MPI_WAITALL
* MPI_WAITSOME
The XSL is now not in sync with the scripts. Although I suppose that
that is becoming less and less important (because it does not impact
the end user at all -- to be 100% explicit, no release should ever be
held up because the XSL is out of sync), but it will probably be
important when we go to fix the "large" interface; so it's still worth
fixing... for now...
This commit was SVN r10281.
- Make the F90 bindings compile and link properly with gfortran 4.0,
4.1, Intel 9.0, PGI 6.1, Sun (don't know version offhand -- the most
current as of this writing, I think), and NAG 5.2, although some
have limitations (e.g., NAG can't seem to handle the medium and
large sizes)
- Building the F90 "small" module size is now the default, even for
developers
- Split up mpif.h into multiple files because parts of it were toxic
to the F90 bindings
- Properly specify unsized/unshaped arrays to make the bindings work
on all known compilers
- Make ompi_info show Fortran 90 bindings size
- XML somewhat lags the generated scripts as of this commit, but
functionality was my main goal -- the XML can be updated later (if
at all).
This commit was SVN r10118.
- split mpif.h into mpif.h and mpif-common.h[.in]
- mpif-common.h is included by various f90 things and contains output
from configure
- mpif.h defines some f77-specific stuff and then includes
mpif-common.h
This commit was SVN r9997.
svn merge -r 9453:9609 https://svn.open-mpi.org/svn/ompi/tmp/f90-stuff .
Several improvements over the current F90 MPI bindings:
- The capability to make 4 sizes of the F90 bindings:
- trivial: only the F90-specific MPI functions (sizeof and a few
others)
- small: (this is the default) all MPI functions that do not take
choice buffers
- medium: small + all MPI functions that take one choice buffer
(e.g., MPI_SEND)
- large: all MPI functions, but those that take 2 choice buffers
(e.g., MPI_GATHER) only allow both buffers to be of the same type
- Remove all non-standard MPI types (LOGICAL*x, CHARACTER*x)
- Remove use of selected_*_kind() and only use MPI-defined types
(INTEGER*x, etc.)
- Decrease complexity of the F90 configure and build system
This commit was SVN r9610.
* Don't do the .in -> .tmp -> header thing for the prefixes and versions.
It causes some severe cleanup issues all to save 4 files from rebuilding
when configure is run.
* Clean up some makefiles so it's clear what is being installed/disted
This commit was SVN r9260.
installation directories) in configure, the files that depend on this
information are not properly rebuilt. If you need this information,
don't setup a -D in the Makefile.am - instead, include
opal/install_dirs.h.
* Use the : option in AC_CONFIG_FILES to avoid needing to expose that
we are playing around with temporary files with our headers to avoid
rebuilding
* Clean up the version file information a bit, and like the install
directory stuff, make sure that there is a dependency so that
ompi_info gets rebuilt properly when a version number changes.
This commit was SVN r9256.
