[Mpi3-tools] Issues with Fortran bindings for MPI_Pcontrol

[Jeff Hammond]

It seems better to correct the text than to break the existing
definition of MPI_PCONTROL.  What error code would be returned
anyways?

Jeff

On Sun, Apr 14, 2013 at 3:40 PM, Schulz, Martin <schulz6 at llnl.gov> 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
>
> MPI_PCONTROL(LEVEL)
>    INTEGER 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.
>
> 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-tools mailing list
> Mpi3-tools at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools



-- 
Jeff Hammond
Argonne Leadership Computing Facility
University of Chicago Computation Institute
jhammond at alcf.anl.gov / (630) 252-5381
http://www.linkedin.com/in/jeffhammond
https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond
ALCF docs: http://www.alcf.anl.gov/user-guides