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

[Jeff Squyres (jsquyres)]

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

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

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.

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. 

- Jeff and Craig

-- 
Jeff Squyres
jsquyres at cisco.com
For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/