[MPI3 Fortran] Results of recent J3 Fortran meeting

[Bill Long]

Hi Rolf,

On 3/26/11 2:13 PM, Rolf Rabenseifner wrote:
> Dear all,
>
> please take this mail also as input for your ballot informal ballot
> March 31, 2011.
>
> When I understand N1845 correctly, then it is invalid to use
> BIND(C) when dummy arguments have standard Fortran types.
>

Certainly not the case. That is allowed even with the existing Fortran 
2003 interoperability.


> What we need in MPI is, that this is valid.
> It is up to the C procedure to handle the dummy arguments
> correctly, e.g., to find a correct type that is equivalent for
> e.g. Fortran INTEGER.
>
> As I can see, for Character arrays and arrays of derived types,
> all works fine according to N1845: the elem_len is the string length
> or sizeof(derived type).
>

The elem_len is provided only for cases when the argument is passed by 
descriptor. The element length is set in the descriptor for all of the 
"normal" Fortran types at the call site. Not just for character and 
derived types.


> I do not understand, which value is in CFI_type_t type
> if the actual argument is an array of Fortran INTEGER.
>

A Fortran caller will fill in the type field in the descriptor at the 
call site, based on the type and kind of the actual argument.

I'm not convinced there is a problem here.

Cheers,
Bill



> We need this interoperability, because we want to have
> all MPI Fortran 2008 interfaces able to be specified with BIND(C).
> And all interfaces are specified with normal Fortran types, like INTEGER.
> (It is formulated within a Rationale in
> Section 16.2.5 Fortran Support Through the mpi_f08 Module in the
> pdfs attached to
> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/229 )
>
> Best regards
> Rolf
>
> ----- Original Message -----
>> From: "Bill Long"<longb at cray.com>
>> To: "MPI-3 Fortran working group"<mpi3-fortran at lists.mpi-forum.org>
>> Sent: Friday, October 22, 2010 12:59:42 AM
>> Subject: Re: [MPI3 Fortran] Results of recent J3 Fortran meeting
>> N.M. Maclaren wrote:
>>> On Oct 21 2010, Bill Long wrote:
>>>>> Except for the last sentence, that is true. But one of MPI's major
>>>>> requirements is that it should be able to handle Fortran default
>>>>> types,
>>>>> and NOT force every program to use the C-interoperability KINDs to
>>>>> call MPI! Sorry, but there IS an issue.
>>>>>
>>>> OK, I agree that there is a general issue for MPI with
>>>> non-interoperable
>>>> types. We have a type code for that - CFI_type_unspecified. I
>>>> assume
>>>> that, if the MPI routines are expecting data objects of Fortran
>>>> types
>>>> that have no corresponding C types (and hence there is little that
>>>> can
>>>> be done with them in C other than memory copies) then the actual
>>>> intent
>>>> is to only make memory copies. In that case, knowing the size of a
>>>> single character is unimportant. All you need is the base_addr,
>>>> elem_len, rank, and dim[] information.
>>>
>>> That is true, but why do you assume that they have no corresponding
>>> C
>>> types? C90 had a fixed number of integer types, but C99 has an
>>> arbitrary
>>> number. It is also possible to translate between any number of bytes
>>> and an integer/character in C - all you need to know is how many
>>> there
>>> are.
>>
>> I am assuming that the interoperable types are the ones we say are
>> interoperable in Table 15.2 of the Fortran standard (and in the
>> corresponding table in the TR). If the table is missing some entries
>> for types that correspond between Fortran and C, then we can expand
>> the
>> table. The sort of games you can play with bits inside C is separate
>> from interoperability of interfaces.
>>
>>>
>>> What I said at the beginning, and which was my point, is that this
>>> approach
>>> is the least FUTURE-PROOF of the approaches, not that it was
>>> incompatible
>>> with the existing interoperability design. And one of the things
>>> that I
>>> hope Fortran has learnt is that assuming that requirements aren't
>>> going to
>>> become important is a mistake. It isn't possible to design for
>>> everything,
>>> but maximising the flexibility is definitely good.
>>
>> I think we have good flexibility. The table of interoperable types is
>> expandable, and we (with TYPE(*)) have provisions for
>> non-interoperable
>> types. Flexibility is not the only goal. Another design goal is to
>> avoid internal inconsistency and contradictions. The rank expansion
>> scheme fails that goal.
>>
>> Cheers,
>> Bill
>>
>>
>>>
>>> Regards,
>>> Nick Maclaren.
>>>
>>> _______________________________________________
>>> 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
>>
>>
>> _______________________________________________
>> 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