[MPI3 Fortran] Request for a straw vote.
donev1 at llnl.gov
Sun Jun 14 11:16:19 CDT 2009
How about a 14th question just to avoid the
On Tuesday 09 June 2009 14:41, Craig Rasmussen wrote:
> 1. Q: Should intents be specified in the MPI-3 interfaces?
> 2. Q: Should derived types be used in place of some MPI handles that
> are currently integers? For example, TYPE(MPI_Comm).
> 3. Q: What type should be specified for the extra_state and value
> parameters in MPI_Comm_create_keyval and MPI_Comm_attr_set?
> 4. Q: What should the name of the MPI-3 module be?
> 6. Q: How should type and rank be specified for buffer choice
> arguments? A: TYPE(*), DIMENSION(..)
This does not require using the descriptor interface, and seems closer
to the present and the C interface. Scalar arguments will need to be
> 7. Q: Are vendors allowed to provide a different actual interface in
> the MPI-3 module for TYPE(*), DIMENSION(..) as a workaround until
> compilers catch up.
> A: Yes, if possible.
> Unresolved issue: Can existing IGNORE TKR compiler directives be
> used instead?
No to the original question and no to the second question. If the
semantics is the same, it matters not to anyone how the compiler spells
it. And the semantics ought to be the same (uniform across compilers).
> 8. Q: Should the value attribute be given to some parameters?
No, INTENT will do.
> 9. Q: What syntax should be specified to inhibit aggresive compiler
> optimizations associated with asynchronous MPI calls.
Wait until the Fortran committee decides on this one. For now, use the
TARGET attribute, if it is urgent to say something.
> 10. Q: Should specific Fortran interfaces be specified in the MPI-3
> 11. Q: Should the F77 and F90 interfaces be deprecated?
> 12. Q: Is it an error if the user gives a non-contiguous buffer to a
> choice argument as it is for C?
is used then not only is it not an error but the compiler will make a
> 13. Q: Should mixed MPI-3 and older MPI code be compatible within the
> same application.
No---it should require recompilation, unless it is an entirely separate
MPI code that does not need to exchange communicators and such with the
More information about the mpiwg-fortran