An MPI implementation providing a Fortran interface must provide a module named mpi that can be used in a Fortran program. Within all MPI function specifications, the second of the set of two Fortran routine interface specifications is provided by this module. This module must:
They are needed only when the application
converts old-style INTEGER
handles into new-style handles with a named type.
( End of rationale.)
For an MPI implementation that fully supports nonblocking
calls with the ASYNCHRONOUS attribute for choice buffers,
an existing MPI-2.2 application may fail to compile even
if it compiled and executed with expected results with an MPI-2.2 implementation.
One reason may be that the application uses ``contiguous'' but not ``simply contiguous''
ASYNCHRONOUS arrays as actual arguments for choice buffers of nonblocking routines,
e.g., by using subscript triplets with stride one or specifying (1:n)
for a whole dimension instead of using (:). This should be fixed
to fulfill the Fortran constraints for ASYNCHRONOUS
dummy arguments.
This is not considered a violation of backward compatibility because
existing applications can not use the ASYNCHRONOUS attribute
to protect nonblocking calls.
Another reason may be that
the application does not conform either to the MPI standard
or to the Fortran standard,
typically because the program forces the compiler to
perform copy-in/out for a choice buffer argument in a
nonblocking MPI call.
This is also not a violation of backward compatibility because
the application itself is nonconforming.
See Section Problems Due to Data Copying and Sequence Association with Subscript Triplets for more details.
( End of advice to users.)
Advice
to implementors.
The appropriate INTENT may be different from what is given in the
MPI language-neutral bindings.
Implementations must choose INTENT so that
the function adheres to the MPI standard, e.g., by defining the INTENT
as provided in the mpi_f08 bindings.
( End of advice to implementors.)
Rationale.
The intent given by the MPI generic interface is not precisely
defined and does not in all cases correspond to the correct Fortran
INTENT. For instance, receiving into a buffer specified by a datatype
with absolute addresses may require associating MPI_BOTTOM
with a dummy OUT argument. Moreover, ``constants'' such as
MPI_BOTTOM and MPI_STATUS_IGNORE are not constants
as defined by Fortran, but ``special addresses'' used in a nonstandard
way. Finally, the MPI-1 generic intent was changed in several places
in MPI-2.
For instance, MPI_IN_PLACE changes the intent of
an OUT argument to be INOUT.
( End of rationale.)
Advice
to implementors.
The Fortran 2008 standard illustrates in its Note 5.17 that
``INTENT(OUT) means that the value of the argument
after invoking the procedure is entirely the result
of executing that procedure. If an argument should
retain its value rather than being redefined, INTENT(INOUT)
should be used rather than INTENT(OUT), even if there is
no explicit reference to the value of the dummy argument.
Furthermore,
INTENT(INOUT) is not equivalent to omitting the INTENT attribute,
because INTENT(INOUT) always requires that
the associated actual argument is definable.''
Applications that include the (deprecated) mpif.h may not expect
that INTENT(OUT) is used. In particular, output array
arguments are expected to keep their content as long as the
MPI routine does not modify them.
To keep this behavior, it is recommended that implementations
not use INTENT(OUT)
in the mpi module and the (deprecated) mpif.h include file,
even though INTENT(OUT) is specified in
an interface description of the mpi_f08 module.
( End of advice to implementors.)