[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.
Regards,
Nick maclaren.
More information about the mpiwg-fortran
mailing list