On Mon, Dec 23, 2013 at 10:55 AM, Markus Geimer <[email protected]> wrote:

Hi,

...

I guess the warning has nothing to do with padding.

Agreed. The warning is due to the type_tag attributes defined in MPICH's 'mpi.h' header file.

...

For MPI_Reduce(in, out, 1, MPI_2INT, ...), the compiler tries to match int, i.e., typeof(*in), with MPI_2INT. Whatever the layout of MPI_2INT is defined (e.g., struct {int i1; int i2} or int[2]), the compiler fails at matching. If you want to use MPI_2INT, then in, out should be defined as of type struct {int v1; int v2}.

This is not what the MPI standard says. MPI-3 Section 5.9.4 defines MPI_2INT _as if_ created by the following call: MPI_Type_contiguous(2, MPI_INT, MPI_2INT); Therefore, the resulting type corresponds to "int[2]" not "struct {int i1; int i2}".

Well, according to the C99 standard "Each non-bit-field member of a structure or union object is aligned in an *implementation-defined* manner appropriate to its type." (§6.7.2.1) It is therefore not guaranteed that the two ints in the struct are contiguous -- which means that, strictly speaking, int[2] is the only portable choice. (Although I'm not aware of any compiler that would insert padding between the two ints, i.e., in practice the struct should be fine, too.)

This is interesting, because it seems to suggest that either the MPI standard is wrong in its definition of mixed pair types (e.g. MPI_FLOAT_INT) or at least assumes that the compiler does no padding. To be explicit, the MPI standard (again, MPI-3 Section 5.9.4) says the following: 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) It would seem that disp[1] is wrong in the event that the compiler adds any padding between the float and the int. If it is intended to be absolutely correct, the the definition of MPI_FLOAT_INT demands the user take whatever steps are required to ensure that the compiler does no padding.

...

I agree that MPI_Reduce(in, out, 1, MPI_2INT, ...) is absolutely right. I think the only reason for the warning is that the compiler is not smart enough.

Compilers could always be smarter ;-) It would be great if you could come up with a datatype that is -- from the compiler's perspective -- compatible with both struct {int i1; int i2} and int[2]. Otherwise, I suggest to remove the type check for MPI_2INT as the warning is misleading.

If compilers were capable of being smart, everyone would just write naive UPC code and let the compiler do all the work instead of bother with MPI :-D

From what you've stated above, this requires a lot of introspection of the compiler. How does one know for sure that the compiler pads the same way every time? What if the user employs a flag that induces more or less padding? There seems to be no reasonable way to address this.

Fortunately, the MPI standard is quite clear and the valid type check is for equivalence to "int[2]" and not any manner of struct, and thus the following line of mpi.h.in should be changed accordingly: struct mpich_struct_mpi_2int { int i1; int i2; }; Best, Jeff

...

On Sun, Dec 22, 2013 at 3:56 AM, Markus Geimer <[email protected] <mailto:[email protected]>> wrote:

Dear MPICH developers,

When compiling the attached example with MPICH 3.1rc2 using Clang 3.3, I get the following compiler warnings:

-------------------- snip -------------------- mpi2int.c:17:20: warning: argument type 'int *' doesn't match specified 'MPI' type tag [-Wtype-safety] MPI_Reduce(in, out, 1, MPI_2INT, MPI_MAXLOC, 0, MPI_COMM_WORLD); ^~~ ~~~~~~~~ mpi2int.c:17:16: warning: argument type 'int *' doesn't match specified 'MPI' type tag [-Wtype-safety] MPI_Reduce(in, out, 1, MPI_2INT, MPI_MAXLOC, 0, MPI_COMM_WORLD); ^~ ~~~~~~~~ 2 warnings generated. -------------------- snip --------------------

According to the MPI standard, however, MPI_2INT is a datatype as if defined by

MPI_Type_contiguous(2, MPI_INT, MPI_2INT)

i.e., 'int[2]' should be a perfect match. This is not necessarily true for the type used for comparison,

struct mpich_struct_mpi_2int { int i1; int i2; };

which will only be contiguous if the compiler does not add any padding.

Is there any chance this gets fixed for the final 3.1 release? Or did I miss something?

Thanks, Markus

-- Dr. Markus Geimer Juelich Supercomputing Centre Institute for Advanced Simulation Forschungszentrum Juelich GmbH 52425 Juelich, Germany

Phone: +49-2461-61-1773 Fax: +49-2461-61-6656 E-mail: [email protected] WWW: http://www.fz-juelich.de/jsc/

------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------

_______________________________________________ discuss mailing list [email protected] To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

-- Jeff Hammond [email protected]