[Mpi3-tools] [MPI3 Fortran] Issues with Fortran bindings for MPI_Pcontrol

Bill Long longb at cray.com
Sun Apr 14 16:28:34 CDT 2013

On 4/14/13 3:40 PM, Schulz, Martin wrote:
> Hi all,
> I am sending this to both the Fortran list and the tools list, since this affects both (sorry if some of you get this twice).
> The MPI standard currently has some inconsistencies with respect to how the MPI_Pcontrol call is defined. The prototype in the tools chapter does not have the usual ierr return code (which is an historical artifact from the use of variable arguments up to MPI 2.2). In particular, it is now stated as:
> MPI_Pcontrol(level) BIND(C)
>     INTEGER, INTENT(IN) ::  level
> This is, however, in contradiction to the text on page 19:
> "All MPI Fortran subroutines have a return code in the last argument. With USE mpi_f08, this last argument is declared as OPTIONAL, except for user-defined callback func- tions (e.g., COMM_COPY_ATTR_FUNCTION) and their predefined callbacks (e.g., MPI_NULL_COPY_FN). A few MPI operations which are functions do not have the return code argument."
> MPI_Pcontrol is not a function and hence shouldn't be covered by the last sentence.

A view from someone who has not been involved on either side of the 

The C prototype is

int MPI_Pcontrol(const int level, ...)

which says to me that MPI_Pcontrol is a function that returns a result 
value.  Absent indication otherwise, the int results from the C MPI_* 
functions are assumed to be error codes.  So, it seems to me that the 
Fortran interfaces should have included the IERROR argument, and the 
omission was just an oversight.   Alternatively, the documentation for 
MPI_Pcontrol should explicitly say that the return value is not an error 
code, and has no meaning. In the later case, the Fortran wrapper would 
just discard the return value.


> We ran into this, when one developer added Pcontrol calls with ierr arguments, which led to a seg fault and then he pointed to the statement that all MPI routines require that argument.
> We (Jeff S., Dave G., Bill, and I) had a brief discussion on this and it turns out that MPICH and Open MPI actually implement this differently: MPICH includes ierr (following the general rule) and Open MPI does not (following the specified prototype). This does cause problems for codes that are used on both implementations (as we had in our case that led to this discussion) and hence breaks portability.
> The two options seem to be to either change the prototype or allow for exceptions to the general rule and there are obvious pros and cons for either option. That's why we thought it would be better to get both working  groups involved.
> Any comments or other good ideas on how to fix this?
> Thanks!
> `
> Martin
> ________________________________________________________________________
> Martin Schulz, schulzm at llnl.gov, http://people.llnl.gov/schulzm
> CASC @ Lawrence Livermore National Laboratory, Livermore, USA
> _______________________________________________
> mpi3-fortran mailing list
> mpi3-fortran at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran

Bill Long                                           longb at cray.com
Fortran Technical Support    &                 voice: 651-605-9024
Bioinformatics Software Development            fax:   651-605-9142
Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101

More information about the mpiwg-tools mailing list