[MPI3 Fortran] Fortran proposal w.r.t. BIND(C)/logical/linker symbols/etc. (take 2)

Sat Jun 1 14:49:05 CDT 2013

Dear all,

my apologies that I had no time to continue the discussion.
I looked at Bill's proposal and tried to correct some necessary
things (1c, 1d, 3b).
I added also a sentence that cases 1a-d are only available
if there is a Version with 2a+b.

With this, the proposal should fit to the results of our discussion
in April.

I added a subsection on the macros for the tools developers.

I hope that it is a good basis for your discussion.

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, April 26, 2013 9:41:16 PM
> Subject: Re: [MPI3 Fortran] Fortran proposal w.r.t. BIND(C)/logical/linker symbols/etc. (take 2)
> Interestingly, as I was writing the attached file, this email arrived.
> I'll try to point out differences. Overall, the attached version
> explicitly moves in the direction that Jeff suggested - that the spec
> should not require a particular implementation.
> 
> 
> On 4/26/13 1:26 PM, Jeff Squyres (jsquyres) wrote:
> > With lots of feedback and discussions since Craig's+my proposal on
> > April 22, we have updated our proposal to be the following
> > (remember: if everyone likes these ideas, then we can go see what
> > this means in terms of the text of chapter 17):
> >
> > 1. Remove BIND(C) from all prototypes in the spec.
> >
> 
> Agreed.
> 
> > 2. As has been the case since MPI-1, all Fortran symbols must be
> > interceptable at link time:
> >
> 
> I guess I find this too vague. What is a "Fortran symbol" ? I prefer
> to spell out explicitly the required names without trying to identify
> whether the underlying code is written in Fortran, C, or Python. The
> tools that care about this need to know only the external name and
> also
> the calling convention used. That's enough as far as I can see.
> 
> [Note: In the attached file, I did take an extra step in exempting the
> routines in A.2.12 through A.2.15 from having separate PMPI_* names.
> These routines are so trivial that intercepting them would seem to
> make
> no sense. Further, they are often only 1 line of code, so it would be
> far better to have the compiler just inline them (resulting on no
> external symbol to intercept). The tools library would, of course,
> still have the MPI_* names available to call of needed. They would
> just
> not intercept them.
> 
> > Class 1: For all MPI routines "MPI_<foo>" with a void * choice
> > argument, or with no choice argument:
> >
> > A) If mpif.h/mpi module is provided, an external must be provided
> > with the name "MPI_<foo>" that uses the Fortran calling conventions
> > and has INTEGER handle arguments, as specified in Annex A.
> >
> 
> An external name of MPI_<foo>, by definition in the spec, has the C
> calling conventions, and already exists in the library this way. You
> cannot have an MPI_<foo> with Fortran calling conventions, or INTEGER
> arguments. I assume this is just a mistake. More likely, the name is
> mpi_<foo>_.
> 
> Furthermore, this requirements conflates the external names with what
> environment is being used. These should be independent issues.
> 
> 
> > B) If the mpi_f08 module is provided, an external must be provided
> > with the name "MPI_<foo>_<f08_buffer>" that uses the Fortran calling
> > conventions and has derived type handle arguments, as specified in
> > Annex A.
> >
> 
> Again, having the Fortran routine name start with upper case letters
> is
> not a good idea. If this is not a mistake, it is doing what we are
> trying to get away from - it puts an unnecessary constraint on the
> implementation. To get a name of MPI_... you either have to specify
> BIND(C) [with we are trying to get rid of], or it forces the
> implementation to not write this routine in Fortran. That is the type
> of restriction that we're trying to get rid of.
> 
> 
> > Class 2: For all MPI routines "MPI_<foo>" with a descriptor choice
> > argument:
> >
> > A) If mpif.h/mpi module is provided, an external must be provided
> > with the name "MPI_<foo>_<old_descriptor>" that uses the Fortran
> > calling conventions and has INTEGER handle arguments, as specified
> > in Annex A.
> >
> > B) If the mpi_f08 module is provided, an external must be provided
> > with the name "MPI_<foo>_<f08_descriptor>" that uses the Fortran
> > calling conventions and has derived type handle arguments, as
> > specified in Annex A.
> >
> 
> My impression from an earlier exchange with Rolf was that it is also
> an
> option to have derived type handles and (void *) choice arguments.
> This is only through the mpi_f08 module, for compilers that do not
> support the TS yet. I included this option in my list (so I have 5
> names, instead of the 4 listed here). If this combination is being
> removed, then I'm happy to adjust my proposal accordingly.
> 
> > *** The exact suffixes <f08_buffer>, <old_descriptor>, and
> > <f08_descriptor> are up for discussion.
> >
> 
> Ditto for the MPI... as above.
> 
> 
> > 3. Implementations that want to use CONTAIN blocks for inlined
> > implementations -- probably for performance reasons -- can supply 2
> > Fortran libraries: one with CONTAIN/inlined implementations, and a
> > second one with interceptable symbols (perhaps this should be an
> > Advice to Implementors?).
> >
> 
> This misses the main point. Sorry. There is no reason to have two
> Fortran libraries. Or any Fortran libraries, for that matter, if the
> implementation chooses some other method that satisfies the
> requirements. The point, as you said before, is to not specify the
> implementation.
> 
> 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)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: c18.comments.txt
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-fortran/attachments/20130601/a22035d9/attachment.txt>