I took yet another straw vote on MPI integer kind specifier today at the MPI Forum. The poll was essentially what this email group responded to earlier: 1. Maintain the status quo (default integers). 2. Use MPI_INTEGER_KIND. 3. Use generics. 4. Some reasonable combination of the above (e.g., generics option left to the MPI vendor as a quality of implementation issue). Results: 1. 10 votes 2. 0 votes 3. 0 votes 4. 0 votes (with 13 C geeks abstaining) I had a long conversation with Rolf Rabenseifner and he explained to me why maintaining the status quo is the correct response. I'll try to summarize: 1. Default integers are less complicated than specifying kinds and would have the least impact on user's code. 2. Default integers automatically work with whatever compiler options (including -i8) that were used to compile the MPI library. For example, there might be two mpif90 wrapper compilers, mpif90 (standard options) and mpif90_i8 (-i8 options). 3. If users explicitly specify the kind with MPI_INTEGER_KIND, it would be meaningless if the wrapper compiler is used, as MPI_INTEGER_KIND is always the kind of a default integer. 4. Suppose a user specifies MPI_INTEGER_KIND, uses the mpif90 wrapper compiler and specifies the -i8 option directly (rather than using mpif90_i8). This will produce incorrect results as the MPI_INTEGER datatype in MPI_Send (for example) would no longer be correct. Perhaps MPI_INTEGER4 and MPI_INTEGER8 could be used for a datatype but things start to get complicated in a hurry. Using the version of the wrapper compiler you want, combined with default integers seems a much simpler and error prone solution. 5. Use of generics doesn't seem to help. The generics would apply to integer parameters like tag, dest, ... but not to the datatype. Since the different wrapper compilers would have to used anyway, using generics only pollutes the interface without any real benefit. So given the vote of the MPI Forum, given that they have the only votes that count (and unless feedback from users at SuperComputing indicates otherwise) it looks like this issue is resolved in favor of the status quo. -craig