MPI_MINLOC/MPI_MAXLOC types

[hjelmn]

This is both an issue and a question. I am running into problems with these types (which only exist because of minloc/maxloc): MPI_SHORT_INT, MPI_LONG_INT, and MPI_DOUBLE_INT. The issues exist because two of these datatypes are externally non-contiguous if defined properly and one is internally non-contiguous (MPI_SHORT_INT).

So, first the issue (I think). In the standard we show this as an example of how MPI_FLOAT_INT could be defined:

type[0] = MPI_FLOAT
type[1] = MPI_INT
disp[0] = 0
disp[1] = sizeof(float)
block[0] = 1
block[1] = 1
MPI_TYPE_CREATE_STRUCT(2, block, disp, type, MPI_FLOAT_INT)

This is clearly wrong if sizeof (float) == 4, sizeof (int) == 8, and alignof (int) == 8. A more correct definition is:

struct mpi_float_int {
    float elem_f;
    int elem_i;
};
type[0] = MPI_FLOAT
type[1] = MPI_INT
disp[0] = 0
disp[1] = offsetof (struct mpi_float_int, elem_i)
block[0] = 1
block[1] = 1
MPI_TYPE_CREATE_STRUCT(2, block, disp, type, MPI_FLOAT_INT)

Now for the questions

1. From my understanding of non-contiguous datatypes (correct me if I am wrong) we are not allowed to touch any padding bit in a composed datatype. Is this also true of predefined datatypes?

2. Sort of related, when writing these to a file, should these types get packed like any other composed datatype or should they appear on disc with the same layout they have in memory?

3. Why isn't the call MPI_Type_get_contents() allowed on these datatypes? Without this call it is difficult for middleware (romio for example) to find the layout without essentially creating the datatypes themselves and then calling MPI_Type_get_contents() on the new datatype.

[hjelmn]

To be clear. I would like to see these datatypes deprecated. If minloc and maxloc are here to stay I would prefer if we described how to construct datatypes that can be used with minloc and maxloc instead of predefining them.