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

[Bill Long]

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.

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

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

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

Overall, I see this proposal as a big step backwards, and am not in 
favor. Sorry.

Cheers,
Bill


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