[MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind

Rolf Rabenseifner rabenseifner at hlrs.de
Wed Mar 27 13:57:58 CDT 2013

After all the replies, I tried to update the list of options.
Please answer at the end the list of "straw votes",
may be also with "more clarification needed".

Option 1
- #364 as it currently is, as a minimal solution for 
  the LOGICAL problem.
  #364 removes BIND(C) only for routines with LOGICAL arguments  
  and for all predefined callback routines 
  and on all ABSTRACT INTERFACE definitions for user written callbacks,
  and all MPI routines that have such callback PROCEDURE 
  dummy arguments.
  Tools will need to support underscore name
  mangling forever (even when TS29113 is implemented by compilers) but
  only on routines with LOGICAL and PROCEDURE arguments, 
  and for all predefined callbacks.

    Pro: It is consistent between Fortran and MPI.
         I.e., it is the minimal solution that we must do.
    Con: It has a mix of BIND(C) and non-BIND(C) routine groups
         which is ugly for the future.
    Remark: non-BIND(C) will stay there because the callbacks 
            need non-BIND(C) in the moment and this cannot be 
            changed in the future by nice new concepts from 
            the Fortran language standardization.

Option 2a
- #364 plus changing MPI-3.0 page 605 lines 24-30 and 
  page 605 line 47 - page 606 line 6 by also using non-BIND(C),
  but other linker names:
   MPI_Send_f08d (in mpi_f08 with TS29113 quality, i.e.,
                  buffers are done with C-descriptors and
                  not with void* pointers.)
   MPI_Send_fd (in the mpi module or mpif.h if 
                MPI_SUBARRAYS_SUPPORTED=.TRUE. is also done
                there, i.e., with the descriptors.)
  The real linker name is defined through the compiler's name
  mangling for these names.

  This means, we remove BIND(C) from all routines.  
  Tools will need to support underscore name mangling 
  for all routines.

    Pro: It is consistent between Fortran and MPI
         and it is consistent within MPI, i.e., all
         functionality is done with non-BIND(C) routines.
         BIND(C) can be still used internally to
         call MPI_Send_cdesc and MPI_Isend_cdesc.
         To be fair, implementatiosn will be based mainly 
         on this TS 29113 feature, but only internally.
    Con: No BIND(C) on the official MPI interface.
         We urged Fortran to put some features into TS 29113,
         but we will not use these features, because they
         are not needed on this internal interface.

Option 2b
- Same as Option 2a, but allow the four options
   MPI_Send_f08d (mpi_f08 interface with array descriptor for buffers)
   MPI_Send_fd   (mpi and mpif.h    with array descriptor for buffers)
   MPI_Send_f08  (mpi_f08 interface with void *, via IGNORE_TKR etc.)
   MPI_Send      (mpi and mpif.h    with void *, via IGNORE_TKR etc.)
  only for routines in the two routine groups MPI_SEND and MPI_ISEND.
  For all other routine groups, we provide only the options
   MPI_Send_f08  (mpi_f08 interface)
   MPI_Send      (mpi and mpif.h)
  because there are no DIMENSION(..),TYPE(*) buffers.

   Additional Pro: Reduces significantly the routine sets that 
                   must be handled with the PMPI interface. 
   No additional Con.

Option 2c
- Same as 2b, but we allow that all routine groups are done with
  BIND(C), except the callback routine group MPI_COMM_DUP_FN (and also 
  and MPI_COMM_CREATE_KEYVAL as long as the required Fortran-C support 
  is missing).
  For this, the following linker names are used, but without 
  name mangling:
   MPI_Send_f08d (mpi_f08 interface with array descriptor for buffers)
   MPI_Send_fd   (mpi and mpif.h    with array descriptor for buffers)
   MPI_Send_f08  (mpi_f08 interface with void *, via IGNORE_TKR etc.)
   MPI_Send_f    (mpi and mpif.h    with void *, via IGNORE_TKR etc.) 

  Pro: In long term, when also LOGICAL and Fortran-callback wiil
       have become interoperable, an implementation can choose 
       to internally implement all in C based on BIND(C), except
       these 9 predefined callbacks.
       This is an ideal basis for option 2d.
  Con: The tools people have more work.
Option 2d
- Same as 2c, but we define one additional small routine group:

   Routine group MPI_STATUS_F2F08 
     contains MPI_STATUS_F2F08 and MPI_STATUS_F082F.
   Pro: An implementor may want to choose that this routine group is
        implemented in Fortran with BIND(C) and the C MPI_Status...
        routines internally call these BIND(C) Fortran routines.
   Con: One more routine group (a very weak argument). 
Option 3:
- Option 2 plus the following rule:
   - The Fortran PMPI interface can be substituted by a 
     wrapper based sulution that internally calls the full 
     MPI C interface.
   - In this case, the Fortran interface should be hidden
     to the tools.
   - For the buffer routines with the new cdesc descriptor,
     new interfaces are added for the tools people,
     e.g., MPI_Send_cdesc and MPI_Isend_cdesc.

    1. The thin wrappers can be put in a module.
    2. Compilers may be able to inline the wrappers for 
       very efficient implementations.
    3. Fortran implementations are much simpler because 
       they won't have to directly support PMPI in Fortran.
    4. Since the Fortran implementation is substantially 
       less complex, the costs associated with testing, 
       supporting, and maintaining a Fortran 
       implementation will also be reduced.
    4. If all MPI implementations eventually choose to call 
       the C API, then the tools community eventually will 
       not have to support underscore name mangling, 
       thus reducing their costs as well.
   Con: An additional new interface for the tools folk.
        It is not backward compatible for users who really 
        intercept the Fortran MPI interface.
   Open question: Does Option 3 require MPI-3.1 or can it
   be done as an MPI-3.0 erratum.
   Pro erratum: One goal of MPI-3.0 mpi_f08 was to allow
     a fully standardized implementation, i.e., without
     compiler dependent software (e.g., name mangling).
     MPI-3.0 was supposed to do this.
     The Option 3 will keep this quality.
     It is a change of the PMPI Fortran interface,
     but MPI-3.0 allows such changes (See removal of C++).
     It is an erratum that requires at least double-vote,
     if we allow this also for the mpi module and mpif.h.
   Con erratum: It is a real change for the user-interface
     of Fortran's PMPI. 

- Option 3a: allowing this only for the mpi_f08 module
- Option 3b: allowing it for all three Fortran support methods.
- Option 3c: To allow this Option 3 independently for 
             each routine group.

Option 4: 
(needed for 2c, for all others it is independent)
- Substituting in mpi_f08 
  all CHARACTER(LEN=xxx) 
  with xxx = a fixed constant.

  As far as I understand, this cannot be done for CHARACTER(LEN=*)
  because otherwise the MPI routine cannot learn about the length 
  of the string, see, e.g., argv array in MPI_COMM_SPAWN.

  Pro: As far as I understand, this is needed for BIND(C) for the
       MPI routines that have CHARACTER(LEN=xxx) dummy arguments.
  Con: Non-consistent solution for a bug in TS29113 that should be 
       fixed in TS29113.
       The mpi and the mpi_f08 moudlues will be inconsistent
       to each other.
       We do not want to change the old mpi module and mpif.h Fortran interface. 
       With current CHARACTER(LEN=xxx), the MPI routine can check at
       runtime whether the provided actual argument is long enough.
       With CHARACTER(LEN=1),DIMENSION(xxx), such a check is impossible. 

  Bill and Craig, please correct me if I'm wrong. 
       Is this bug fixable in TS29113, or is there a reason, 
       why CHARACTER(LEN=xxx) is not interoperable with C?    

Open questions:

 - Is anybody for Option 1?
 - If we are doing Option 2, which version is your favorite 2a, 2b, 2c, 2d?
 - For each Option 2a-d do you say 
    - absolute necessary
    - is okay for me
    - is not okay for me
 - Do you want Option 3?
    - If yes, do you want 3a, or 3b?
    - Can we do 3a as erratum (instead of postponing to MPI-3.1)?
    - Can we do 3b as erratum (instead of postponing to MPI-3.1)?
    - If yes, do you additionally want 3c?
 - Do you want Option 4?


My personal answers:
 - Is anybody for Option 1?
       ** No, it is to few.
 - If we are doing Option 2, which version is your favorite 2a, 2b, 2c, 2d?
       ** I would prefer 2d.
 - For each Option 2a-d do you say 
    - absolute necessary
    - is okay for me
    - is not okay for me
       ** 2a: absolute necessary
       ** 2b: absolute necessary
       ** 2c: is okay
       ** 2d: is okay
 - Do you want Option 3?
       ** Yes
    - If yes, do you want 3a, or 3b?
       ** 3b
    - Can we do 3a as erratum (instead of postponing to MPI-3.1)?
       ** Yes 
    - Can we do 3b as erratum (instead of postponing to MPI-3.1)?
       ** Yes 
    - If yes to 3a or b, do you additionally want 3c?
       ** Yes
 - Do you want Option 4?
       ** No, should be done by the Fortran standardization 
              as correction to TS29113.
Best regards


----- Original Message -----
> From: "Bill Long" <longb at cray.com>
> To: "Jeff Squyres (jsquyres)" <jsquyres at cisco.com>
> Cc: "Craig Rasmussen" <rasmus at cas.uoregon.edu>, "Rolf Rabenseifner" <rabenseifner at hlrs.de>, "MPI-3 Fortran working
> group" <mpi3-fortran at lists.mpi-forum.org>, "Hubert Ritzdorf" <Hubert.Ritzdorf at emea.nec.com>, "Martin Schulz"
> <schulzm at llnl.gov>, "Tobias Burnus" <burnus at net-b.de>
> Sent: Wednesday, March 27, 2013 12:03:27 AM
> Subject: Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind
> On 3/26/13 11:26 AM, Jeff Squyres (jsquyres) wrote:
> > On Mar 26, 2013, at 12:16 PM, Bill Long <longb at cray.com> wrote:
> >
> >> I don't think there is a problem. To accommodate -i8 you have to
> >> recompile the MPI module with the -i8 flag set. We've been shipping
> >> two mpi modules as long as I can remember; the compiler scripts
> >> pick the right one based on how the user code is compiled. Same as
> >> how we select the right version of other libraries that also have
> >> Fortran default type arguments. Within the MPI module source the
> >> values of MPI_INTEGER and the similar data types for other Fortran
> >> default types are set based on detection of the actual sizes of the
> >> default types (which change with the compiler options). If you are
> >> using the module compiled with -i8, MPI_INTEGER will encode the
> >> information for an 8-byte integer.
> >
> >
> > But not all Fortran types have corresponding C types (from a
> > standards/strict perspective), right? (e.g., logical -- and I'm not
> > sure about the various complex types...?) So the MPI implementation
> > needs to know that it has to create some synthetic / "good enough"
> > MPI datatypes based on actual Fortran types.
> >
> > ...at least, that's what OMPI does...
> What I did was less sophisticated (at least in terms of mpich
> internals). The values for the various handles at page 666 (how
> appropriate) lines 5-10, and 34, and page 667 lines 15-17 are not new.
> I took the values out of the mpich mpif.h files generated for 32-bit
> defaults and 64-bit defaults. Those values are assigned to internal
> constants in the module. The definition of MPI_INTEGER selects between
> the two options depending on KIND(0), and similarly for the others.
> The
> goal is to produce the same values in the module as in the mpif.h
> files,
> only automatically selected based on the default type size specified
> by
> the compiler options used to compile the module.
> 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

Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner at hlrs.de
High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530
University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832
Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner
Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307)

More information about the mpiwg-fortran mailing list