[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
routines.
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
confusing.
>
> 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.
Cheers,
Bill
>>
>> 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