[MPI3 Fortran] New Fortran proposal w.r.t. BIND(C)/logical/etc.

[Bill Long]

On 4/23/13 12:05 PM, Craig Rasmussen wrote:
> On Apr 23, 2013, at 5:17 AM, Bill Long wrote:
>
>>
>>
>> On 4/22/13 3:03 PM, Jeff Squyres (jsquyres) wrote:
>>> Craig and I would like to propose a different MPI-3 errata solution for the current MPI Fortran existential crisis (keep in mind: there may be a different solution for MPI-4).
>>>
>>> If the group likes these idea, we will draw up an actual proposal.  Here are the main points:
>>>
>>> 1. Remove BIND(C) from all prototypes in the spec.  Have a short Advice to Implementers saying that using BIND(C) is not prohibited.  If used, the effects of BIND(C) must *not* be visible to either the MPI application or PMPI-based tools (e.g., the linker symbol must be the same as if BIND(C) was not specified).
>>>
>>
>> I agree with not having BIND(C) in the prototypes in the spec.  However, the second sentence effectively prohibits implementation of any of the worker routines in Fortran, which is quite unacceptable.
>
> I'm not sure what you mean by worker routines (do you mean wrapper routines)?  Because as I see the proposal, it effectively requires that the WRAPPER routines be in Fortran.  The worker/implementation routines can be in either Fortran or C, just as in pre MPI-3 days.
>

For example, the routines that convert between the C and Fortran formats 
of the STATUS type.  I makes no sense whatever to write these in C since 
C does not know about Fortran default types.  Instead, you write one 
version, in Fortran, with BIND(C) that specifies the correct C name so 
that C functions could call it if they wanted.


> The requirement that the effects of BIND(C) must not be visible is meant to require that argument passing and linker symbols must be as if BIND(C) was not used.
>

Well, obviously not for the example above. You WANT the C calling 
conventions.

>>
>>> 2. MPI-3 says that all mpi_f08 subroutines must use INTERFACE with the official MPI API name suffixed with _f08 when MPI_SUBARRAYS_SUPPORTED equals .FALSE..  Our proposal changes this such that the Fortran subroutine name *always* has the _f08 suffix (this is a direct consequence of #1).  For example:
>>>
>>>      INTERFACE MPI_SEND
>>>          SUBROUTINE MPI_Send_f08(...args...)
>>>      END INTERFACE MPI_SEND
>>>
>>
>> For implementations that put the Fortran wrappers in the module (where they logically belong), this requirement is pointless.  It just adds three unnecessary lines to the module.  It is missing the point of trying to modernize the interface to take advantage of the C interoperability features in Fortran.
>
> Again, the above example is an example.  If an implementation can make it appear as if this interface body is in effect, then the vendor is free to implement the standard any way it wants.  For example,
>
> ----------------------
> module mpi_f08
>
> interface MPI_Recv
>    module procedure MPI_Recv_f08
> end interface MPI_Recv
>
> contains
>
> subroutine MPI_Recv_f08(args...) bind(C, name="mpi_recv_f08_")

No, you do not want this BIND(C). You get the problems with LOGICAL back 
again. (Not for this particular routine, but for others.)  Just name the 
subroutine MPI_Recv in the module and get rid of the interface block. 
This is a thin wrapper and the Fortran name (mangled or otherwise) will 
likely not even show up in the executable.  The actual call will to the 
C library routine, and that one is the only one the tools people see.


> end subroutine
>
> end module
> ----------------------
>
> With gfortran, this will produce the same symbol name, e.g. "_mpi_recv_f08_"  for tools (but would fail for argument passing reasons when DIMENSION(..) is used).  Otherwise when the implementation is included with the module the symbol name is mangled, e.g. "___mpi_f08_MOD_mpi_recv_f08".  Once you remove BIND(C) from the prototypes in the spec, you can't place the implementation within a module because we can't require tools to support mangled symbols even more heinous that they must do at the moment.
>
>>
>>> PROS
>>>
>>> 1. Removing BIND(C) solves LOGICAL/BIND(C) issues and string/BIND(C) issues.
>>> 2. This is a small enough change to be an MPI-3 errata.
>>> 3. Mandating the _f08 suffix for all cases removes corner cases and simplifies the standard.
>>>
>>> NEUTRAL
>>>
>>> 1. Tools will use the same name mangling schemes they have been using for years.  We have not made the issue *better* (though we have removed the need to support the BIND(C, name=) symbol from the MPI symbol namespace), but we have also not made it *worse* (e.g., a proliferation of symbol names introduced into the MPI standard).
>>>
>>> CONS
>>>
>>> 1. There may be advantages in adding new functionality related to linker symbols / PMPI.  However, this lies outside the scope of an errata; re-exmaining the whole solution/architecture can take place in the scope of MPI-4.
>>>
>>> Sidenotes / implications:
>>>
>>> 1. Chapter 14 explicitly states that Fortran symbols must be interceptable (MPI-3 p555).  This means the MPI-3 "use mpi_f08" implementation cannot be in the CONTAIN section of the mpi_f08 module.
>>>
>>
>> If that's the case, then this needs to be fixed.   It prevents the use of interoperability the way it was intended.
>
> An implementation is free to use interoperability with the implementation.  For example, the Fortran wrapper can turn around and immediately call the regular PMPI C implementation through a BIND(C) interface and a little argument marshaling to match the C interface.  Dropping BIND(C) from the interface specification means that a normal Fortran user can implement MPI_Send (for example) in a Fortran file which calls PMPI_Send, then links his application with the existing MPI library and have her implementation of MPI_Send be called.  This cannot happen unless the linker symbols are the same.
>
> There would be a huge backlash if Fortran symbols were not interceptable.
>

That is exactly the opposite of what I've heard from the tools people. 
My impression is that they would be happy to have to only look for the C 
names.  Why would there be backlash in this case?


>>
>>> 2. We don’t think that mandating extra MPI_<foo>_cdesc() symbols are a good idea; they impose a specific implementation model that is not universal.
>>>
>>
>> These names are only relevant for a modern implementation, and give the tools people standardized names to intercept.   If you opt for a last-century scheme, then these new names are not relevant to your implementation.  These names are for the tools people (which in the end are the only point of the whole discussion from the beginning.)
>
> We agree here.  The MPI standard should be changed to allow a vendor to implement the standard in the way you suggest.  I just don't see how this can be done in an errata.  Especially considering the interceptability argument made above (which absolutely can't be removed in an errata).  Thus to do this we have to wait until MPI-4.
>
> One further point which I think has been missing from the argument:  This proposal (and earlier MPI standards) allows PMPI tools to be implemented in Fortran in a portable way.  For example, suppose I implement MPI_Send in a Fortran file.  Then this file can be compiled and linked with any MPI version and it will still work.
>

If you implement MPI_Send (or any other MPI worker routine, such as the 
status conversions) in Fortran, this is easy since you specify the 
interface with BIND(C) so that C functions can have equal access.  This 
seems straightforward - the C interop feature was specifically designed 
to allow C functions to call Fortran-written library routines.


> I just don't see how user portability can be maintained with Rolf's A, B, C combinatorial proposal (because every vendor may have a different combination).  I could be wrong.
>

All that should be required for portability of source code is that the 
user writes calls according to the interface rules .   I don't see how 
any of the implementation methods violate that requirement.

Cheers,
Bill


> -craig
>
>

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