[MPI3 Fortran] Fwd: [Mpi-comments] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind

N.M. Maclaren nmm1 at cam.ac.uk
Sat Mar 2 03:10:49 CST 2013


On Mar 1 2013, Bill Long wrote:
>>
>> I don't see how that will work, anyway, as BIND(C) passes all non-VALUE
>> arguments as addresses, and the C interfaces define a lot of them as
>> values.  Communicators are one example, but they are used in almost all
>> of the calls.
>
>For the cases where C expects a value, you need the VALUE attribute in 
>the Fortran interface for that C function.   This works.

They don't have it at present.  The simplest example is MPI_Barrier.

    int MPI_Barrier(MPI_Comm comm)

    [SUBROUTINE] MPI_Barrier(comm, ierror) BIND(C)
    TYPE(MPI_Comm), INTENT(IN) :: comm

No VALUE there.  Thanks for the correction on the opacity - I had
forgotten that gotcha.  That's not nice at all.

>The even worse problem with default INTEGER is that some users will 
>compile their Fortran codes with options like -r8 -i8, leading to the 
>near certainty that in at least one case, KIND(0) will not be the same 
>as C_INT.   You need two copies of the .mod file for the module - one 
>for 32-bit default integers, and the other for 64-bit default integers. 
>The source for the module can be the same, you just have to compile the 
>module twice, once each with and without the -r8 -i8 options. And make 
>sure the compiler points to the right module file depending on the -r8 
>-i8 settings in later compilations.  Wrappers and "path magic" solve 
>this problem.  But it is an artificial problem introduced by the use of 
>default INTEGER.

Bill, we have been here several times before.  That particular problem
may be the one that affects you, but it affects very few users of MPI,
and it is the least of small issues as far as the option compatibility
goes.  Other than the half-dozen USA mountain-top sites, most MPI users
do not run with more than 2-4 GB per process, because cores and memory
are increasing pro-rata.

There are a zillion options that can cause such problems, especially at
the C side, and some are truly evil.  My unfavourite are the alignment
ones, where code can pass testing and then fail because one particular
facility needs an alignment that it doesn't always get.  The simple
fact is that the Fortran and C/MPI options MUST be selected to work
together, and that constraints most of the code-generation ones.

Until fairly recently, many C compilers had options to change the sizes
of the built-in types - these are in abeyance, but I expect them to
return in some new form.  This is not least for the reasons that you
need -r8 -i8 - people will start wanting to run OpenMP on a node and
MPI across nodes - in C and C++.  Thank heavens, I shall be retired :-)

While the type in the C interface to MPI is int, there really isn't a
major problem with default INTEGER.  If that changes, all bets are off.


Regards,
Nick Maclaren.




More information about the mpiwg-fortran mailing list