An MPI implementation providing a Fortran interface must provide a module named mpi_f08 that can be used in a Fortran program. Section MPI for Different Fortran Standard Versions describes restrictions if the compiler does not support all the needed features. Within all MPI function specifications, the first of the set of two Fortran routine interface specifications is provided by this module. This module must:
It is strongly recommended that developers substitute calls to deprecated routines
when upgrading from the (deprecated) mpif.h or the mpi module to the
mpi_f08 module.
( End of advice to users.)
In all blocking routines, i.e., if the choice-buffer
is not declared as ASYNCHRONOUS, the
Fortran 2018 feature is not needed
for the support of noncontiguous buffers because the compiler
can pass the buffer by in-and-out-copy through a contiguous scratch
array.
( End of rationale.)
For these definitions in the mpi_f08 bindings,
in most cases, INTENT(IN) is used if the C interface
uses call-by-value. For all buffer arguments and for
OUT and INOUT dummy arguments
that allow one of the nonordinary Fortran constants
(see MPI_BOTTOM, etc. in Section Named Constants)
as input, an INTENT is not specified.
( End of rationale.)
Advice to users.
If a dummy argument is declared with INTENT(OUT),
then the Fortran standard stipulates that the actual argument
becomes undefined upon invocation of the MPI routine,
i.e., it may be overwritten by some other values, e.g. zeros;
according to [46], 12.5.2.4 Ordinary dummy variables,
Paragraph 17:
``If a dummy argument has INTENT(OUT), the actual argument becomes undefined
at the time the association is established, except [...]''.
For example, if the dummy argument is an
assumed-size array and the actual argument is a strided array,
the call may be implemented with copy-in and copy-out
of the argument. In the case of INTENT(OUT) the copy-in may
be suppressed by the optimization and the routine starts execution using
an array of undefined values. If the routine stores fewer
elements into the dummy argument than is provided in the actual
argument, then the remaining locations are overwritten with these
undefined values.
See also both advices to implementors in
Section Fortran Support Through the mpi Module.
( End of advice to users.)
For user-defined callback functions
(e.g., of type MPI_Comm_copy_attr_function or COMM_COPY_ATTR_FUNCTION) and their
predefined callbacks (e.g., MPI_COMM_NULL_COPY_FN),
the ierror argument is not optional.
The MPI library must always call these routines with an actual ierror argument.
Therefore, these user-defined functions need not check whether the MPI
library calls these routines with or without an actual ierror output argument.
( End of rationale.)
The MPI Fortran bindings in the mpi_f08 module are designed based on
the Fortran 2008 standard [46] together with the
Technical Specification ``TS 29113 Further Interoperability with C''
[47]
of the ISO/IEC JTC1/SC22/WG5 (Fortran) working group,
which is now integrated in Fortran 2018 standard [48].
Rationale.
The features in TS 29113 on further interoperability with C were decided on by ISO/IEC JTC1/SC22/WG5 and designed by PL22.3 (formerly J3) to support a higher level of integration between Fortran-specific features and C than was provided in the Fortran 2008 standard; part of this design is based on requirements from the MPI Forum to support MPI-3.0. These features became part of Fortran 2018 [48], so references to TS 29113 are obsolete, except insofar as to specify a particular feature set from Fortran 2018 or minimal requirements to a compiler.
Fortran 2018 contains the following language features that are needed for the MPI bindings in the mpi_f08 module: assumed-type and assumed-rank. It is important that any possible actual argument can be used for such dummy arguments, e.g., scalars, arrays, assumed-shape arrays, assumed-size arrays, allocatable arrays, and with any element type, e.g., REAL, CHARACTER*5, CHARACTER*(*), sequence derived types, or BIND(C) derived types. Especially for backward compatibility reasons, it is important that any possible actual argument in an implicit interface implementation of a choice buffer dummy argument (e.g., with the deprecated mpif.h without argument-checking) can be used in an implementation with assumed-type and assumed-rank argument in an explicit interface (e.g., with the mpi_f08 module).
A further feature useful for MPI is the extension of the semantics of the ASYNCHRONOUS attribute: In F2003 and F2008, this attribute could be used only to protect buffers of Fortran asynchronous I/O. With TS 29113 and now Fortran 2018, this attribute also covers asynchronous communication occurring within library routines written in C.
The MPI Forum hereby wishes to acknowledge this
important effort by the Fortran PL22.3 and WG5 committee.
( End of rationale.)