[MPI3 Fortran] [Mpi-comments] MPI 3.0:Fortran 2008 interface - issue with the LOGICAL kind
Bill Long
longb at cray.com
Thu Mar 14 17:04:22 CDT 2013
On 3/14/13 4:14 PM, Rolf Rabenseifner wrote:
> Dear all,
>
> I would like to learn
> - Who is implementing the new mpi_f08 module
> -- for mpich?
> Is this you, Bill Long?
I've been working under that assumption.
> -- for OpenMPI?
> Is this you, Craig?
> -- who else is currently implementing the
> new Fortran mpi_f08 module?
> - Do I understand correctly that both implementations:
> -- do use Fortran-written wrappers as MPI user-API?
I use thin Fortran wrappers that call C functions directly for the
'normal' MPI routines. The wrappers are contained in the module.
The implementations of the require defined operators for comparing the
new Fortran types are all written in Fortran in the module.
The conversion functions between the Fortran and C versions of STATUS
structures are all written in Fortran and in the module.
(Basically, any part of the implementation that has to understand
Fortran types is in Fortran.)
> -- I.e., it is simple to change it to BIND(C) or non-BIND(C)?
For the normal routines, there is no requirement for BIND(C) on the
Fortran wrappers. The interfaces for the C functions do have BIND(C),
of course. (I included an example for MPI_Isend in an earlier email -
basically the pattern is the same for the others.) In fact, one would
like for the compiler to inline, and optimize away the wrapper. In that
case, the external name of the wrapper becomes irrelevant since it does
not occur in the final executable. Only the name of the C worker
function remains as an external.
The module procedures that implement the conversions for STATUS do need
BIND(C) since it is possible that these would be called from a C
function and there is no C version of these routines.
> -- I.e., only for the tools people, it is of
> interest whether BIND(C) or non-BIND(C) was chosen?
> -- What are other implementations do?
>
> I ask this, to learn whether the BIND(C)/non-BIND(C) freedom
> for the implementations can/should be reduced
> to make life easier.
Having more freedom here would be helpful.
Cheers,
Bill
>
> The current proposal #364 is based on minimal restrictions
> based on the missing C-interoperability of LOGICAL.
> I expect, that life can be more simple if we make more
> restrictions, e.g., same BIND(C) roule for all routine groups
> (this would mean no BIND(C) in the moment).
>
> Best regards
> Rolf
>
>
> ----- Original Message -----
>> From: "Bill Long" <longb at cray.com>
>> To: mpi3-fortran at lists.mpi-forum.org
>> Cc: rabenseifner at hlrs.de, "Kathryn Mohror" <kathryn at llnl.gov>, "Nick Maclaren" <nmm1 at cam.ac.uk>
>> Sent: Monday, March 11, 2013 2:01:37 PM
>> Subject: Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0:Fortran 2008 interface - issue with the LOGICAL kind
>> Hi Martin,
>>
>> Ultimately, the problem is that some Fortran compilers (one out of
>> five
>> that I tried) will give an error for a dummy argument declared default
>> LOGICAL in a BIND(C) interface. This is because there is not really a
>> good corresponding type in C for all Fortran compilers, and the
>> internal
>> representation of LOGICAL in Fortran might not even match the _Bool
>> type
>> in C.
>>
>> One solution to the problem, at least for the "normal" MPI functions,
>> is
>> the write the Fortran wrapper in Fortran, with no BIND(C) [gets around
>> the compiler error message] and within the wrapper, convert the
>> LOGICAL
>> value to an int value that is passed in a call to the actual C
>> function
>> [since the corresponding C argument is an int]. If the argument is
>> intent(out) then you convert it back from int to LOGICAL after the C
>> function call, before returning from the wrapper. These conversions
>> are
>> each single lines of Fortran code, and (if the wrapper is in a module)
>> will probably get inlined, and possibly optimized away for some
>> Fortran
>> implementations. The goal is that C should never have to be confronted
>> with the foreign Fortran default LOGICAL directly.
>>
>> I believe that the current wording of the MPI 3 spec for using mpif.h
>> still requires dealing with the no/single/double underscore issue, and
>> that is assuming one of those is the choice for default linker names
>> in
>> Fortran for a particular implementation. There is nothing in the
>> Fortran standard that requires any of these three options.
>>
>> I noted that Nick Maclaren replied to this message as well. For those
>> not aware, Nick is in a rather unique position of having participated
>> on
>> both the C and Fortran standardization committees. He pretty much
>> knows where all the [Fortran-C interoperability] dead bodies are
>> buried.
>>
>> Cheers,
>> Bill
>>
>>
>> On 3/11/13 12:18 AM, Schulz, Martin wrote:
>>> Hi all,
>>>
>>> I am trying to catch up with the various threads on this (sorry,
>>> last week was hectic and I didn't get to all emails). I have to
>>> admit that I am still confused why there is a problem, but we can
>>> clarify this during a phone call or during the march meeting.
>>> However, doesn't not doing BINDC create a problem, since I now have
>>> to again deal with the no/one/two underscore issue? This sounds like
>>> a bad interface design to me, especially when we starting mixing
>>> things.
>>>
>>> Martin
>>>
>>>
>>> On Mar 4, 2013, at 9:47 AM, Rolf Rabenseifner <rabenseifner at hlrs.de>
>>> wrote:
>>>
>>>> Dear all,
>>>>
>>>> I forget to say thank you to all of you who helped to solve
>>>> this hard problem. It was a really helpful discussion.
>>>> It is a pity that we could not keep the BIND(C) for
>>>> all routines in mpi_f08, which was one goal with mpi_f08 and TS
>>>> 29113.
>>>>
>>>> In my proposal #364, we have to remove BIND(C) from
>>>> - the 30 normal MPI routines with LOGICAL arguments,
>>>> - the 9 MPI routines with callbacks in the argument list,
>>>> - and 10 predefined callbacks,
>>>> i.e., from 49 out of 357 MPI routines.
>>>>
>>>> I do not see a better solution that can be done by the MPI Forum.
>>>> Better solutions are still possible for the 30 normal routines
>>>> and/or for the 9 routines with callback-arguments as soon as
>>>> the Fortran standard will include some additions and
>>>> those additions are provided by the compilers - but if this
>>>> will happen then it will not happen soon.
>>>>
>>>> It was luck that all routines with buffer arguments do not
>>>> have also a LOGICAL argument.
>>>>
>>>> Best regards
>>>> Rolf
>>>>
>>>> ------------------
>>>> Malcolm and all MPI implementors,
>>>> and TOOLS implementors,
>>>>
>>>> First Malcolm, thank you for your helpful answer.
>>>> After all the discussion, the MPI-3.0 errata decision is
>>>> very simple: Remove BIND(C) everywhere where LOGICAL is around.
>>>>
>>>> I did it in the ticket #364
>>>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/364
>>>>
>>>> I hope that one of the implementors with Fortran knowledge goes
>>>> through my proposal and returns an "okay" as a review on the
>>>> ticket.
>>>>
>>>> The major changes:
>>>> - BIND(C) removed on all callback abstract interfaces.
>>>> - BIND(C) removed on all predefined callbacks.
>>>> - Creating a new routine group "MPI_TEST" for all MPI routines
>>>> with LOGICAL arguments, except MPI_OP_CREATE, which is already
>>>> in an own group.
>>>> - Telling that the routines in the groups MPI_TEST,
>>>> MPI_OP_CREATE, MPI_REGISTER_DATEREP, and MPI_COMM_KEYVAL_CREATE
>>>> cannot be implemented with BIND(C) in Fortran 2008 + TS 29113
>>>> and earlier.
>>>>
>>>> TOOLS implementors should be aware that I added this new routine
>>>> group.
>>>>
>>>> Best regards
>>>> Rolf
>>>>
>>>> ----- Original Message -----
>>>>> From: "Malcolm Cohen" <malcolm at nag-j.co.jp>
>>>>> To: "MPI-3 Fortran working group"
>>>>> <mpi3-fortran at lists.mpi-forum.org>
>>>>> Sent: Monday, March 4, 2013 3:56:50 AM
>>>>> Subject: Re: [MPI3 Fortran] Fwd: [Mpi-comments] MPI 3.0:Fortran
>>>>> 2008 interface - issue with the LOGICAL kind
>>>>>> (B1) Is it possible, that a BIND(C) routine
>>>>>> has a dummy argument that is a non-BIND(C)
>>>>>> ABSTRACT INTERFACE procedure argument?
>>>>>
>>>>> That is not possible: all dummy arguments of a BIND(C) routine
>>>>> must be
>>>>> interoperable - for procedures that requires BIND(C).
>>>>>
>>>>> It would be reasonable to extend C_FUNLOC and C_F_PROCPOINTER to
>>>>> permit
>>>>> non-interoperable procedures, similarly to how we permit
>>>>> non-interoperable
>>>>> variables in C_LOC and C_F_POINTER. Then the argument could be
>>>>> C_FUNPTR (by
>>>>> value). I don't know whether this would help you though.
>>>>>
>>>>>> (B2) Do we have any problem with
>>>>>> the TYPE(C_PTR), VALUE dummy arguments
>>>>>> in the ABSTRACT INTERFACE MPI_User_function
>>>>>> on MPI-3.0 page 183 line 45 - page 184 line 3
>>>>>> if the we remove the BIND(C) from this
>>>>>> ABSTRACT INTERFACE (i.e. on page 183, line 47).
>>>>>
>>>>> No problem.
>>>>>
>>>>> Cheers,
>>>>> --
>>>>> ................................Malcolm Cohen, Nihon NAG, Tokyo.
>>>>>
>>>>> _______________________________________________
>>>>> 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)
>>>
>>> ________________________________________________________________________
>>> Martin Schulz, schulzm at llnl.gov, http://people.llnl.gov/schulzm
>>> CASC @ Lawrence Livermore National Laboratory, Livermore, USA
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>
--
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