[mpich-devel] Possible problem with accfence1 test

[Jeff Hammond]

On Tue, Feb 24, 2015 at 1:32 PM, Nathan Hjelm <hjelmn at lanl.gov> wrote:
>
> Hey, I am looking that the accfence1 test in MPICH and I think the tests
> is invalid. The test attempts to execute an MPI_Accumulate with different
> datatypes for the origin and destination. The problem is that the test
> violates MPI 3.0 § 11.3.4 p. 426 1-4:

Not everyone has the standard open on their computer all the time, so
for reference, you are referring to:

"Each datatype argument must be a predefined datatype or a derived
datatype, where all basic components are of the same predefined
datatype.  Both datatype arguments must be constructed from the same
predefined datatype."

> Each datatype argument must be a predefined datatype or a derived
> datatype, where all basic components are of the same predefined
> datatype. Both datatype arguments must be constructed from the same
> predefined datatype. The operation op applies to elements of that
> predefined type.

Indeed, I see that e.g. MTestGetSendDerivedDatatypes use as the
underlying predefined type MPI_DOUBLE on one side and MPI_CHAR on the
other, which violated the aforementioned condition.

> I see no wording in the standard that says this restriction does not
> apply when the operator is MPI_REPLACE. The test is correct if the
> operation is changed from MPI_Accumulate to MPI_Put.

Because MPI_Put doesn't have to be atomic, whereas MPI_Accumulate with
MPI_REPLACE does.

> If the test is correct then it might make sense to make it explicit in
> the standard that the datatype restriction does not apply to MPI_REPLACE.

We don't want to do that.  Trust me.  I'll be happy to have the debate
on the MPI Forum RMA WG list if you want, but the right answer here is
the trivial mods to the MPICH test suite to not violate the MPI
standard.

Best,

Jeff


-- 
Jeff Hammond
jeff.science at gmail.com
http://jeffhammond.github.io/