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

Bill Long longb at cray.com
Wed Mar 20 13:15:17 CDT 2013

Hi Rolf,

This looks like good progress toward a solution.  There is one missing 
piece that I think is needed.  If the tools target only the C functions, 
then the names of the versions of the C functions that take a choice/buf 
argument that is a pointer to a descriptor need to be standardized.

For the moment I'm using MPI_Send_cdesc  as the companion of MPI_Send. 
Besides the spelling of the function name, only the specification for 
the buf argument is changed - all the other arguments and the return 
type are the same as for MPI_Send.   Since this is a simple replacement 
pattern, we would need only a paragraph to describe the naming rule, and 
not a complete list of the new prototypes.  The actual form of the name 
modification is certainly open for discussion.  I picked appending 
"_cdesc" because the new argument declaration is CFI_cdesc_t, so it 
seemed like it would be easy to remember.

Because of the way these descriptors work, the routines that implement 
operations like MPI_Send that use a descriptor have to be written in C 
anyway.  If the interfaces is otherwise the same as for the traditional 
MPI_Send then the tools packages would have a much easier time (no 
INTEGER or LOGICAL Fortran issues).

For the case of thin Fortran wrappers without BIND(C) and tools looking 
at the C functions only, these names would be required.  For other 
implementation options, it is not as clear if it is necessary to require 
these C function names.  However, if they were required universally, 
then C programmers would have the option of calling these functions 
directly, which would seem like a nice facility for them, particularly 
where performance is an issue.


On 3/20/13 12:09 PM, Rolf Rabenseifner wrote:
> This mail contains a proposal how we can solve the current
> Fortran problems and possibly making the tools people also happy.
> I need at least answers for
>   - mpich (Bill Long),
>   - OpenMPI (Jeff or Craig),
>   - some tools people.
> Let me summarize what I've learnt so far for mpi_f08:
>   - #364 about LOGICAL correction is a must.
>   - MPI-3.0 allows BIND(C) and non-BIND(C), with the
>     new restrictions in #364
>   - BIND(C) needs TR29113, therefore any implementation now
>     should use non-BIND(C) for all non-TR29113 compilers.
>   - Most (or all) try to use the non-BIND(C) interface.
>   - Best way to do this are thin wrappers in Fortran that
>     internally call
>      - the oficial MPI-3.0 C binding
>        (here, the tools people have a problem because they
>         expect to wrap the Fortran interface and may therefore
>         double-wrap), or
>      - or an internal MPI-3.0 C routine
>        (which is half-perfect for the tools folk, because
>         they have to handle the implementation-dependant
>         Fortran names with underscores).
>   - And at least Bill wants to include the Fortran MPI
>     library routines itselves in the mpi_f08 module.
>     This is in conflict with the current MPI-3.0
>     linker naming rules.
> Implications and proposal:
>   - We should rewrite the linker names section MPI-3.0 17.1.5
>     with following goals:
>      - Allow additionally to define that the PMPI is provided
>        only on the MPI C interface and the Fortran MPI routines
>        internally call the C interface;
>        again, a macro definition in mpi.h tells whether this
>        is chosen.
>        Question: Would this cause a problem when linking a
>        C or Fortran user application with some own
>        MPI_Test etc. profiling routines that internally call
>        PMPI_Test?
>      - If Fortran profiling is done through the MPI C binding
>        then there are no rules about the Fortran linker names
>        needed, and therefore, one may put the thin Fortran
>        wrappers into a Fortran module.
>      - We can define BIND(C) for MPI routine groups as a
>        future option that is currently not used.
>        This would reduce the current effort for the tools people.
>        Is there anybody who wants to implement one of the Fortran
>        routine groups with BIND(C)?
> I would expect, that this is the best to solve the problem
> that #364 prohibits BIND(C) for some routines and implementors
> want to do the same method for all routines.
> Don't forget that BIND(C) and TR29113 is still important
> for implementing these thin wrappers internally.
> Without using BIND(C) on the official mpi_f08 and mpi module
> interface, some features of TR29113 are not used:
>    - the extension for interoperabple CHARACTER(LEN=*),
>    - the extension for OPTIONAL dummy arguments.
> Other TR29113 features are heavily used:
>   - The DIMENSION(..), TYPE(*) is needed for some internal
>     C-written MPI_Isend_desc.
>   - The ASYNCHRONOUS usage for communication buffers.
> Should we go in this direction?
> Best regards
> Rolf
> ----- Original Message -----
>> From: "Bill Long" <longb at cray.com>
>> To: "Jeff Squyres (jsquyres)" <jsquyres at cisco.com>
>> Cc: "Martin Schulz" <schulzm at llnl.gov>, "MPI-3 Fortran working group" <mpi3-fortran at lists.mpi-forum.org>
>> Sent: Wednesday, March 20, 2013 4:01:52 PM
>> Subject: Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind
>> On 3/20/13 8:26 AM, Jeff Squyres (jsquyres) wrote:
>>> On Mar 20, 2013, at 6:25 AM, Bill Long <longb at cray.com> wrote:
>>>> interface !--> MPI_Test
>>>>     ! int MPI_Test(MPI_Request *request, int *flag, MPI_Status
>>>>     *status);
>>>>     Function MPI_Test_C( request, flag, status) &
>>>>                 BIND(C, name="MPI_Test") RESULT (res)
>>>>       import :: C_request, c_int, MPI_Status_C
>>>>       integer(C_request) :: request
>>> This is not correct. You cannot assume that MPI handles are integers
>>> (they're pointers in Open MPI).
>> 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.
>> 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
>> _______________________________________________
>> mpi3-fortran mailing list
>> mpi3-fortran at lists.mpi-forum.org
>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran

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