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

[Craig Rasmussen]

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.

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.

> 
>> 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_")
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.

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

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.

-craig