[MPI3 Fortran] Results of recent J3 Fortran meeting

[Rolf Rabenseifner]

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.

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).

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

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

-- 
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: Allmandring 30)