[MPI3 Fortran] Results of recent J3 Fortran meeting

Sun Mar 27 03:10:40 CDT 2011

Hi Bill and all,

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

Only two small additional questions:
Do I understand correctly, that the CFT_type_t type is CFI_type_other that must be
used by the caller because in Table 5.2 of TR 1845 (because there isn't
an entry for Fortran types, only for C types)?
Do I understand correctly, that size_t elem will have 
the number of bytes of an INTEGER, depending on how much bytes are used
when compiling the caller's program?

> > 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.
thank you for your fast and positive answer.

About a comment from Craig:
gfortran issues a warning when having a
INTEGER dummy argument in combination with BIND(C). 
This means that the warning of gfortran is not necessary.
Compiling the interface, it would be okay to have an information message.
On the caller site, a warning would not be helpful
because it would cause a warning with each MPI call.
I do not know, where gfortran currently produces its warning.

> I'm not convinced there is a problem here.
If I understood all correctly, then you convinced me 
that there is not a problem, because it is part of an MPI library
compilation to check which C integer type is equivalent
to Fortran INTEGER. Because MPI is doing all by call by reference
(i.e. not by VALUE), I expect that the problem is really solved.

Best regards
Rolf

----- Original Message -----
> From: "Bill Long" <longb at cray.com>
> To: "Rolf Rabenseifner" <rabenseifner at hlrs.de>
> Cc: "MPI-3 Fortran working group" <mpi3-fortran at lists.mpi-forum.org>, "Craig E Rasmussen" <rasmussn at lanl.gov>, "N.M.
> Maclaren" <nmm1 at cam.ac.uk>, "Reinhold Bader" <reinhold.bader at lrz.de>
> Sent: Sunday, March 27, 2011 5:11:51 AM
> Subject: Re: [MPI3 Fortran] Results of recent J3 Fortran meeting
> 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

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