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

Bill Long longb at cray.com
Wed Mar 20 12:50:08 CDT 2013



On 3/20/13 12:17 PM, Jeff Squyres (jsquyres) wrote:
> On Mar 20, 2013, at 8:01 AM, Bill Long <longb at cray.com> wrote:
>
>>>>      integer(C_request) :: request
>>
>> This is correct for mpich.  OpenMPI would evidently have a different version.  But the concept is still the same - make a correct interface to the C library routine, however it is defined by the implementation, and then call that from a thin Fortran wrapper that takes care of the issues related to LOGICAL, the use of default INTEGER, and OPTIONAL arguments.
>
>
> Instead of integer(c_request), is there a way to standardize on a type that can be implementation-defined?  That way, a tool doesn't have to figure out integer vs. <something_else>.
>
> It would be terrible to force a tool to figure out the type that they're supposed to use.

I'm assuming that the tool only cares about the C functions, so the type 
is MPI_request, as defined in the mpi.h file, which differs for each 
implementation.  I assume the tools already know how to deal with this 
(by looking in mpi.h). For mpich,  this is in mpi.h:

typedef int MPI_Request;

and in my mpi_C_types module I define C_request to be C_int from the 
ISO_C_Binding module, which makes it portable across Fortran compilers 
(for mpich).   Using integer(C_Request) in the interfaces allows the 
mpi.h definition to change (to 'long', for example) with only one line 
of change in the modules.  If the C prototype explicitly says 'int' then 
I use integer(C_int), but for the typedefs I include this extra layer of 
abstraction (all eliminated by the compiler).

At one point Fortran did have a typedef-like facility (early in the 
Fortran 2003 development; it was removed before the final version).  The 
Cray compiler actually still has this implemented, so I could have 
defined a Fortran MPI_Result and used type(MPI_Result) for the C 
function arguments, but that would not be portable across Fortran compilers.


A related tool question is the handling of OPTIONAL arguments.  If the 
tool is expected to handle the Fortran wrappers directly, and you do not 
have BIND(C) on the wrapper, then this is a complication because the 
implementation of optional arguments without BIND(C) is different among 
Fortran compilers.  Another argument for having the tools ignore the 
Fortran wrappers.

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





More information about the mpiwg-fortran mailing list