On Apr 14 2013, Schulz, Martin wrote:

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?

My main comment isn't particularly helpful for a solution, and is probably well-known. When I first looked at MPI_Pcontrol, I tried to work out what it could be used for, and failed. If anyone is writing a PMPI-based tool and needs programmatic control, it is both unlikely to be just a single integer and is absolutely trivial to provide extra tool-dependent functions. Because MPI_Pcontrol had no defined semantics in MPI 2.2, it couldn't be used by any program that wants to interoperate with arbitrary PMPI-based tools. So there is unlikely to be a significant amount of old code using it, and changes should not be a big deal. I would favour restoring IERR as an optional argument. Regards, Nick Maclaren.