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

Bill Long longb at cray.com
Wed Mar 20 15:40:08 CDT 2013

My impression is that Rolf's proposal was to offer two options:

a)  no bind(c) on the Fortran wrappers, no requirements on the Fortran 
external names, but the wrappers are REQUIRED to call the C library 

b) specific external names are required for the Fortran-called routines, 
but they do not have to be wrappers.  (Still a bit unclear to me  in 
this case where bind(c) might be required).

On 3/20/13 2:58 PM, Jeff Squyres (jsquyres) wrote:
> Not only that, I think that there are some cases where tools *need* to intercept the Fortran call, not the C call.  In OMPI, for example, we have a few corner cases where the Fortran MPI subroutine does *not* call the corresponding C MPI API function.  Instead, it calls a back-end OMPI routine.

True for implementations using option (b), but not for the (a) case.

> One obvious case that jumps to mind is anything involving a callback.

Looking at the callback examples on page 268, I have some questions:

1) The BIND(C) and an argument of type LOGICAL are likely incompatible, 
so either the BIND(C) or the LOGICAL needs to go.

2) The external names for the C and Fortran versions are different. I 
assume this does not matter assuming that the function that is calling 
these has only an address, and not a name, to call.  But how does the 
function know the calling signature for the callback routine with only a 
procedure pointer to work with?

If I were writing a code with a callback like this, I would want to 
assume the C prototype even of the code was in Fortran.   I assume the 
existence of the separate (and apparently flawed) Fortran interface is 
for legacy code.  But there should not be legacy mpi_f08 code. A bit 

> If you have integer handles in C, they might be able to get away with not swizzling/de-swizzling the arguments to the callback to the proper language.  But this is not always the case.
> On Mar 20, 2013, at 12:29 PM, Hubert Ritzdorf <Hubert.Ritzdorf at emea.nec.com> wrote:
>> Hi,
>> I think that Bill's proposal kills the Fortran Profiling Interface.
>> If the user defines a
>>   subroutine MPI_Test (....)
>>       do something
>>       call PMPI _Test()
>>       do something
>> end subroutine MPI_Test

I was under the impression that users would not directly call PMPI 
routines.  Those were for the tools people.   Why would a normal user 
want to do something like the above?

>> then this function will never be executed because the Fortrran compiler may have already
>> inlined the MPI_Test subroutine in the original code or the module version of MPI_Test is used.

In the scope where this routine is called, the Fortran wrapper would 
have to be inaccessible.  That would be done by NOT having a USE of the 
module in this scope. The external name of the module procedure would be 
mangled  to include the name of the module, whereas a stand-alone 
routine like this would have an external name like mpi_test_ .   The 
linker would see these as different routines.


>> Hubert
>> ________________________________________
>> From: mpi3-fortran-bounces at lists.mpi-forum.org [mpi3-fortran-bounces at lists.mpi-forum.org] on behalf of Rolf Rabenseifner [rabenseifner at hlrs.de]
>> Sent: Wednesday, March 20, 2013 6:09 PM
>> To: longb at cray.com; MPI-3 Fortran working group
>> Cc: Martin Schulz
>> Subject: Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran     2008 interface - issue with the LOGICAL kind
>> 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
>> --
>> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner at hlrs.de
>> High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530
>> University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832
>> Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner
>> Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307)
>> _______________________________________________
>> mpi3-fortran mailing list
>> mpi3-fortran at lists.mpi-forum.org
>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran
>> Click https://www.mailcontrol.com/sr/oUBxarVXlArGX2PQPOmvUrwgXREt4LZXdolWasoQmWDbX5aSB7TlS9if4+7oDyxaXeCWFTId+Sn5pl0FDW8fzw==  to report this email as spam.
>> _______________________________________________
>> 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