In my interpretation of the text you mention I have not considered the type name as an intrinsic property of the datatype (unlike ub, lb, size and many others). Thus, I took the freedom to alter it in a meaningful way for debugging purposes. This should not affect the users if they set the name, as it will be overwritten.
George. PS: the text is obviously wrong when it claims that the "[type] yields the same net result when fully decoded with the functions in Section 4.1.13". If that was the case we wouldn't have had a need for MPI_COMBINER_DUP. On Tue, May 2, 2017 at 4:31 AM, Aboorva Devarajan <aburvadevara...@gmail.com > wrote: > This particular test from MPICH fails : https://github.com/pmodels/ > mpich/blob/master/test/mpi/f77/datatype/typesnamef.f > > $ mpirun -n 1 ./typesnamef > > (type2) Expected length 0, got 17 > (type2) Datatype name is not all blank > Found 2 errors > > The test case expects the duplicated datatype's name to be blank soon > after duplication. > > I could see in open-mpi we are actually duplicating the old datatype name > in MPI_Type_Dup and pre-pending it with string "Dup" > > https://github.com/open-mpi/ompi/blob/872cf44c28203fcb21838b0705d5b9 > c85c3e1407/ompi/datatype/ompi_datatype_create.c#L111 > > > According to the MPI Standard v3.1 On Page 111: > > "MPI_TYPE_DUP is a type constructor which duplicates the existing > oldtype with associated key values. For each key value, the respective > copy callback function determines the attribute value associated with this > key in the new communicator; one particular action that a copy callback may > take is to delete the attribute from the new datatype. Returns in newtype a > new datatype with exactly the same properties as oldtype and any copied > cached information, see Section 6.7.4. The new datatype has identical upper > bound and lower bound and yields the same net result when fully decoded > with the functions in Section 4.1.13. The newtype has the same committed > state as the old oldtype. > > *"Returns in newtype a new datatype with exactly the same properties as > oldtype"* > > Any information on how this spec must be interpreted? Should we consider > datatype name as a property? > > > - Aboorva > > _______________________________________________ > devel mailing list > devel@lists.open-mpi.org > https://rfd.newmexicoconsortium.org/mailman/listinfo/devel >
_______________________________________________ devel mailing list devel@lists.open-mpi.org https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
