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

[Bill Long]

Hi Rolf,

  See comments below to be sure I understand things correctly. Also some 
corrections and  questions, particularly about an apparent contradiction.


On 6/1/13 2:49 PM, Rolf Rabenseifner wrote:
> 17.1.5.2 External linkage names and calling conventions
>
> A Fortran call to an MPI routine shall result in a call to a procedure
> with one of the following external linkage names and calling conventions.
> MPI_Send is used as an example. Case is significant in the names.
>
>      External Linkage name     Calling convention
>      ---------------------     ------------------
>
> 1a) MPI_Send 	     	      C interface and arguments, as in A.2.
>
> 1b) MPI_Send_cdesc	      Same as (1) except that choice arguments
>      			      are pointer to CFI_cdesc_t rather than
> 			      void *.
>
> 1c) MPI_Send_f08cb	      Same as (1) except that the callback dummy argument
>                                is a Fortran callback according to the A.1.3
>                                Fortran 2008 Bindings with the mpi_f08 module.
>
> 1d) MPI_Send_fcb	      Same as (1) except that the callback dummy argument
>                                is a Fortran callback according to the A.1.3
>                                Fortran Bindings with mpif.h or the mpi module.

1c and 1d are only for the limited number of routines that have a 
callback procedure as an argument.  These are all C functions (at least 
in the abstract), so there is no issue about derived-type versus INTEGER 
handles. However, it is possible for the routine to have a choice 
argument? If the routine has a choice argument then 1c will have a 
pointer to descriptor argument for that argument and 1d will have a void 
* choice argument.   Correct?


>
>
> 2a) mpi_send_f08_             Fortran interface and arguments, as in A.3.
>                                In routines with a choice buffer, the choice buffer
>                                dummy argument is implemented with non-standard
>                                extensions like !$PRAGMA IGNORE_TKR.

I would prefer that the "non-standard extensions ... TKR" be worded 
differently. It is reasonable for the interface to declare the choice 
argument TYPE(*),DIMENSION(*) if the TS is supported, and that would not 
be "non-standard".   What is actually required (as opposed to 
implementation suggestions) is that the choice argument be declared in a 
way compatible with (void *).

The beginning of the description needs a change of "in A.3. In routines" 
-> "in A.3, except that in routines".   A.3 specifies the descriptor 
arguments, and this text is making an exception to the A.3 text

A.3 also specifies OPTIONAL for the ierror argument, implying TS 
support.  Does 2a) also need an exception to remove the OPTIONAL 
attribute in the interface?

>
> 2b) mpi_send_f08ts_           Fortran interface and arguments, as in A.3,
>                                but only for routines with a choice buffer argument
>                                and this dummy argument is implemented
>                                with TYPE(*), DIMENSION(..).

A.3 already specifies TYPE(*),DIMENSION(..) in the interfaces with 
choice arguments.  So, the description here can end with the A.3 in the 
first line.  Since the OPTIONAL attribute used throughout A.3 requires 
basically all of the routines to be in this category, the "but only for 
routines" is confusing - at least to me.

Just from the names, I expected that mpi_send_f08_ would have 
{derived-type handles, void * choice arguments, and no OPTIONAL 
attribute} and mpi_send_f08ts_ would have {derived-type handles, 
descriptor for choice, and OPTIONAL arguments} - i.e. as in A.3.

>
> 3a) mpi_send_		      Fortran interface and arguments, as in A.4.
>                                In routines with a choice buffer, the choice buffer
>                                dummy argument is implemented with non-standard
>                                extensions like !$PRAGMA IGNORE_TKR.
>
> 3b) mpi_send_fts_             Fortran interface and arguments, as in A.4,
>                                but only for routines with a choice buffer argument
>                                and this dummy argument is implemented
>                                with TYPE(*), DIMENSION(..).

I see  missing details here, similar to 2 above.  Basically all of the 
same comments, except that the handles are declared INTEGER here.

>
> For each external linkage name supported, a second entry point with
> the same calling characteristics shall be supplied, expect that the
> name is modified by prefixing with the letter "p" in the same case as
> the leading "m".  For example, PMPI_Send and pmpi_send_.
>
> [No exceptions according to p555:35-37.]
>
> The external linkage names as mpi_send_, or mpi_send_fts_
> are examples for the external linkage name that the Fortran compiler
> chooses for the Fortran routine names MPI_Send, or MPI_Send_fts.

I assume that the intent here is that these are examples and  that the 
real requirement is that the external linage names are the ones 
generated by the particular Fortran compiler for MPI_Send  and 
MPI_Send_fts.

>
> Using the mpi_f08 module, a Fortran call to MPI_Send must be implemented
> through a call one of the linker names defined in 1a) - 2b);
> if linker names in 1a) - 1d) are used, then an additional library
> must be provided that uses only 2a) and 2b) in the mpi_f08 module.

Actually, 1d is not for the mpi_f08 module. It should be omitted from 
the ranges in the paragraph above.

I assume you don't mean "in the mpi_f08 module" here since you would not 
get routines with names like these in a module.  And hopefully the 
"only" is also wrong since otherwise this would lead to a huge amount of 
unnecessary duplication.   The obvious way to implement these routines 
is in a file outside the module, with

   subroutine mpi_send_f08 ( <args> )
   use mpi_f08
   <declarations for args>
   call mpi_send (<args> )
   end subroutine mpi_send_f08

This ensures correct mpi_f08 behavior and allows the maintenance of the 
actual Fortran MPI_Send to occur in only one place.  And, of course, 
avoid all of the duplicated work of providing two complete 
implementations - one in the old pre-interop style, and one using modules.

>
> Using the mpi module or mpif.h, a Fortran call to MPI_Send must
> be implemented through a call to one of the linker names defined in 3a) and 3b).
>

This is hopefully wrong, since it contradicts 1d which is specifically 
for the mpi module.  The current wording seems to suggest that a module 
implementation using C interoperability is prohibited for the mpi 
module, which (hopefully) is not the case.   This needs to  read similar 
to the previous paragraph, such as

"Using the mpi module, a Fortran call to MPI_Send must be implemented 
through one of the linker names 1a), 1d),  3a), or 3b).  If 1a) and 1d) 
are used, then routines with  external linkage names as specified in 3a) 
and 3b) must also be provided."

Do the tools people really need that second sentence?  I was under the 
impression they would be happy with dealing only with the C functions.

[Although is this, and similarly for the mpi_f08 module case, actually 
true? It seems that this requirement is only relevant for the tools 
developers, and that their real need is that  the PMPI_xxx versions be 
available.]

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