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

[Bill Long]

On 3/1/13 3:20 PM, N.M. Maclaren wrote:

>
> This assumes that BIND(C) is specified on the procedures; if it is not,
> implementations may have to provide wrappers, in which case all of these
> problems disappear.  The difficulties are caused SOLELY by the desire to
> use the same functions for both.

There are practical difficulties with not having BIND(C).  With the use 
of default INTEGER, the need for wrappers is basically unavoidable. Use 
of pseudo-opaque types like MPI_Comm makes that even more certain.  A 
structure like that "clearly" does not interoperate with a C int.    The 
obvious implementation is to put the wrappers directly in the Fortran 
module file. This way you have a good chance they will be inlined, 
removing the overhead.  However, there is still the 1970's requirement 
of having things work with only the mpif.h include file.  The means that 
the module procedure external names have to be visible even when the 
module is not.  The solution is the NAME= spec in the BIND(C) so that 
the external name can be accessible for the dusty-deck codes that still 
use the include file.  The BIND(C) semantics are not so important for 
the wrapper, but the ability to give it a module-free name is.

[Note:  If you have thin Fortran wrappers that inline into calls to the 
actual C functions, then the PMPI_xxxx interfaces for Fortran are 
probably unnecessary. You just need PMPI for the C functions, which are 
the routines actually being called.  This greatly simplifies the 
implementation.]

The solutions above work well for the "normal" MPI functions.  The 
callback routines are a different story.  Given that these are vary 
rarely used, my preference in those cases is to change the interfaces so 
that they are exactly the C interfaces, requiring KIND values for the 
arguments.  One could argue that this is what should have been done for 
all of the interfaces, had it not been disruptive for old codes. 
However, for the exceptional case of the callbacks, I see very little 
disruption for the user, and a huge benefit for the implementation and spec.

>
> 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.

>
>     A) Default INTEGER is, as you say, supported only if it maps to some
> C integer type.  Because of the attempt to keep the same interfaces for
> Fortran and C, I would be chary about a system where KIND(0) was not
> equal to C_INT, but that will be the dominating case.

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.

Cheers,
Bill

-- 
Bill Long                                           longb at cray.com
Fortran Technical Support    &                 voice: 651-605-9024
Bioinformatics Software Development            fax:   651-605-9142
Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101