Your patch fixes the case where a NULL datatype is provided as a complement to MPI_IN_PLACE. I don't think this case is legitimate in MPI for two reasons:
1) NULL is not a legitimate datatype.
2) This I guess this is a matter of interpretation. The MPI standard refers to MPI_IN_PLACE as "using the same buffer", which I interpret as "having to provide the same pointer" (there is a good rationale on why providing the same pointer in the MPI call is not the right approach, and why a special constant is necessary). As such, my understanding of the MPI_IN_PLACE is that different datatypes on the send and recv side of the collective are allowed, as long as they have the same type signature. In other terms the datatype map might be different as long as the signature is identical.
Can you pinpoint me to the section/paragraph in the MPI standard that require the receive side to use the same datatype as the send side when MPI_IN_PLACE is used?
On Oct 31, 2012, at 04:55 , "Matsumoto, Yuki" <yuki.matsumoto_at_[hidden]> wrote:
> Dear all,
> There are some collective communications with the possibility of terminating abnormally when MPI_IN_PLACE is specified.
> They refer to sdtype or rdtype (For MPI_Scatter) unconditionally by the consideration leakage of the MPI standard at MPI_IN_PLACE.
> It terminates abnormally when NULL is specified for a data type of the sending side or receiving side with which MPI_IN_PLACE is specifiable.
> e.g.) MPI_Allgather(MPI_IN_PLACE, scount, NULL, rbuf, rcount, recvdtype, ...);
> - Functions which have this MPI_IN_PLACE problem:
> Which data type: The sending side data type
> It terminates abnormally when sdtype=NULL is specified at sbuf=MPI_IN_PLACE.
> (sdtype must be ignored when sbuf = MPI_IN_PLACE.)
> Which data type: The receiving side data type
> It terminates abnormally when rdtype=NULL is specified at rbuf=MPI_IN_PLACE.
> ("rdtype" must be ignored when rbuf = MPI_IN_PLACE.)
> We attach a patch.
> Best Regards,
> Yuki Matsumoto,
> MPI development team,
> devel mailing list