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 <[email protected]> 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, [email protected], http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA

_______________________________________________ Mpi3-tools mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools

-- Jeff Hammond Argonne Leadership Computing Facility University of Chicago Computation Institute [email protected] / (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