[MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind
rabenseifner at hlrs.de
Thu Mar 28 14:11:01 CDT 2013
shows all 32 routines with CHARACTER arguments.
Can I summarize your analysis to:
- 21 routines CHARACTER(LEN=*),INTENT(IN) arguments
All these routines need the length information at the callee.
The non-BIND(C) interface works fine (as in mpif.h and the mpi module)
A BIND(C) interface would need to be changed, because the length
information must be passed in an additional argument
(or as in C by a special terminator character).
- 2 routines with CHARACTER(LEN=*),INTENT(OUT) arguments
These routines works with non-BIND(C) and BIND(C),
because the application must provide a string-buffer
that is large enough.
- 0 routines with CHARACTER(LEN=SOME_CONST),INTENT(IN)
- 7 routines with (only) CHARACTER(LEN=SOME_CONST),INTENT(OUT)
These routines work with non-BIND(C).
For BIND(C), we need to change the declaration into
With non-BIND(C), this alternative declaration would
also work correctly with any arguments passed
in the same way as to CHARACTER(LEN=xxx).
This interface change requires Fortran 2003 compilers.
- and following special cases:
A shortcut of this summary:
Due to the 22 routines with LEN=*,
BIND(C) on the MPI API level should be fully removed.
BIND(C) makes sense only on this internal interface,
which should be optional.
Based on this, the possible options dramatically shrink.
----- Original Message -----
> From: "Tobias Burnus" <burnus at net-b.de>
> To: "Rolf Rabenseifner" <rabenseifner at hlrs.de>
> Cc: "MPI-3 Fortran working group" <mpi3-fortran at lists.mpi-forum.org>, longb at cray.com, "Craig Rasmussen"
> <rasmus at cas.uoregon.edu>, "Hubert Ritzdorf" <Hubert.Ritzdorf at emea.nec.com>, "Martin Schulz" <schulzm at llnl.gov>, "Jeff
> Squyres (jsquyres)" <jsquyres at cisco.com>
> Sent: Wednesday, March 27, 2013 11:44:56 PM
> Subject: Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind
> I restrict myself to replying to Option 4, only, in this email.
> Rolf Rabenseifner wrote:
> > Option 4:
> > (needed for 2c, for all others it is independent)
> > - Substituting in mpi_f08
> > all CHARACTER(LEN=xxx)
> > by CHARACTER(LEN=1),DIMENSION(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.
> For C interoperability, "character(len=*)" doesn't make sense as with
> Bind(C) just a pointer is passed without any length information (and
> string is also not zero-terminated). With Fortran semantics, one
> passes the length as hidden argument or does not pass the pointer to
> data but some descriptor with the length information. In order to make
> "len=*" work with Bind(C), the information has to be passed in some
> However, using
> subroutine sub(str, len) Bind(C)
> integer :: len
> character, dimension(len) :: str
> would be one valid replacement - albeit slightly inconvenient.
> BIND(C), character(len=len) is also valid but has no advantage to
> > 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.
> Note: For users, both interfaces act exactly in the same way and they
> shouldn't be able to detect the difference. (Unless their compiler
> doesn't support that part of Fortran 2003. But (nearly) all current
> compilers should be able to do so.)
> > 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.
> I fail to see why the diagnostic should be impossible. Compilers are
> doing array bounds checks since ages. If the explicit interface is
> known, compilers can simply insert a check before the function call.
> the interface is not known, it gets more cumbersome but it is also
> possible (e.g. some compiler store in the caller the size of the
> arguments in a global variable and compare in the callee the values
> the expected sizes).
> The only advantage of len=... is that Fortran semantic implies that
> string length of the actual argument is available to the callee, which
> makes checking simpler. But of one passes a simple "char *" with
> BIND(C), this information is also not available.
> In addition, if the the array sizes are known at compile time and an
> explicit interface is used (or, as here, both are in the same file), a
> compiler can detect the mismatch even at compile time:
> Warning: Actual argument contains too few elements for dummy
> argument 'x' (3/5)
> subroutine foo(x)
> character :: x(5)
> call foo("abc")
> > 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?
> Well, TS29113 cannot be changed as it is not a bug (solvable via an
> interpretation request) and as the TS is published; it would be rather
> something for the next Fortran standard.
> At least if one does not allow assumed-length, there is no real
> fundamental reason to not allow other lengths.
> However, one runs into many inconsistencies and has to deal with a lot
> of special cases. For instance, while "character(len=1), value" and
> "char" are passed in the same way, "character(len=2), value" does not
> match any C type. Assuming, one could use "char". But then, passing
> len=1 by value ("char") and len=2 by reference ("char") doesn't look
> clean. A "character(len=1)" would be "char *" and "character(len=2)"
> then "char**". But what would be "character(len=n)" - what happens if
> one changes an "integer :: n = 1" to "integer, paramter :: n=1", would
> that change the ABI?
> I think there are too many issues like those to make it very unlikely
> be changed in the next standard. In particular, as using
> character(len=1), dimension(xxx) :: str
> works sufficiently well and it is already implemented in most
> used compilers. Hence, I believe the standard will only be augmented
> a very strong case can be made that allowing len=1 has large
> (I do not see this happening.)
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