[mpiwg-abi] MPI_Fint in the ABI

[Erik Schnetter]

We can introduce a new type `MPIABI_Fint` which is always equal to a C
`int`. In the MPI ABI we only use this type.

Incompatibilities can only arise if the MPI ABI caller also interacts
with Fortran (in any way, e.g. directly with an MPI library or with an
application), then the caller must surely know the size of a Fortran
`integer` (how else could it interact), and can perform the necessary
type conversions.

That is, we  act as if `MPI_Fint` was equal to a C `int`, for the
purposes of this ABI. If this does not hold, then the caller needs to
convert. We guarantee that any handles etc. fit in this range and can
be converted losslessly.

I believe this is your option 1. I think this does not introduce any
problems that cannot be solved on the caller's side.

-erik

On Wed, Aug 16, 2023 at 4:09 AM Jeff Hammond <jeff.science at gmail.com> wrote:
>
> As we all know, Fortran users are permitted to change the size of INTEGER with compiler flags.  This creates a problem for the MPI C ABI.
>
> I have considered three options and would like your opinions on them:
>
> 1. MPI_Fint is defined to be a C int in the standard ABI.  This means MPI implementations that elect to provide an ILP64 MPI Fortran ABI on an I32LP64 system, for example, must not call this an implementation of the standard ABI.
>
> This would make a lot of things easier, but it might cause problems in the rare cases where users are using ILP64 in Fortran and using C code that actually uses MPI_Fint.
>
> 2. MPI_Fint ceases to be a compile-time fixed type in the standard ABI.  The C code that uses MPI_Fint must make an MPI library call to figure out the size and do all of the necessary things to call the correct size.
>
> 3. MPI_Fint is not a fixed size but the standard ABI specifies that Fortran handle values must always fit into the range of a C int and we rely on the pass-by-value behavior of all the f2c/c2f APIs to behave properly when they are truncated.
>
> This is my preference but it breaks Example 19.11 in a serious way, because that user code makes use of a MPI_Fint pointer.  However, this code isn't standard-compliant and relies on universal but non-standard argument passing conventions in Fortran.  Writing a standard-compliant interface from Fortran to C - by doing the cast to INTEGER(kind=c_int) in Fortran - would resolve this.
>
> Example 19.11 is awful (https://github.com/mpi-forum/mpi-issues/issues/739) but it is nonetheless important to instruct users that if Option 3 is implemented, they need to do the casting to INTEGER(kind=c_int) and know that this is safe with the standard ABI.
>
>
> None of these options is perfect.  I'm not sure how much code is even impacted by MPI_Fint so it's hard to know which option breaks the most stuff, although Option 2 seems the least desirable in any case.
>
> Thanks,
>
> Jeff
>
> --
> Jeff Hammond
> jeff.science at gmail.com
> http://jeffhammond.github.io/
> --
> mpiwg-abi mailing list
> mpiwg-abi at lists.mpi-forum.org
> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi



-- 
Erik Schnetter <schnetter at gmail.com>
http://www.perimeterinstitute.ca/personal/eschnetter/