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" <[email protected]> To: "MPI-3 Fortran working group" <[email protected]> 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 [email protected] 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 [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran

-- Dr. Rolf Rabenseifner . . . . . . . . . .. email [email protected] 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)