[MPI3 Fortran] What to do with mpif.h in MPI-3?

N.M. Maclaren nmm1 at cam.ac.uk
Mon Jan 25 14:58:10 CST 2010

On Jan 25 2010, Jeff Squyres wrote:
>On Jan 24, 2010, at 6:38 PM, Torsten Hoefler wrote:
>> > What is everyone's opinion on which (1-4) the Forum should go with?
>> It seems like the route to go with the C-bindings (and also the general
>> bindings) is not clear yet and this would decide the outcome. Because if
>> we decide to take the "64-bit" (tm) approach and double the number of
>> function symbols, then the issue would be much simpler. However, if we
>> decide to take the int -> MPI_Count approach, then I don't see how we
>> can "extend" F77 in a standard-conforming and portable manner (but I
>> might miss something).
> Hmm -- maybe I missed something in ATL, but I thought we agreed that we 
> would do *both* things:
> - Add new versions of various MPI functions with a <suffix> appended 
> (e.g., MPI_File_write<suffix>) and take the large count parameter - The 
> large count parameter in these new functions would have (in C) a 
> parameter type of MPI_Count

That's upwards compatible in both C and Fortran.

> There has been some discussion on the mailing list (by 1 person) since 
> ATL about *not* using an "MPI_Count" datatype (rather, use uint64_t or 
> somesuch), but my $0.02 is that we should use MPI_Count.

Unquestionably!  Please do not touch any of the <stdint.h> stuff with a
bargepole!  Stick to the basic types and MPI type names.

There are many different ways where <stdint.h> integers cause portability,
efficiency and other problems.  Inter alia, the current revision of C is
thinking of changing them in ways that could be incompatible with old code,
and they are semantically incompatible with Fortran and many other languages
in several respects.

MPI_count gives the opportunity to evade any such chaos, whether introduced
by the standard or an implementation.

Nick maclaren.

More information about the mpiwg-fortran mailing list