[mpiwg-abi] MPI_Fint in the ABI

[Lisandro Dalcin]

On Sat, 19 Aug 2023 at 10:32, Jeff Hammond <jehammond at nvidia.com> wrote:

>
> Second, I think we just need to say that the f2c/c2f symbols, while part
> of the C API, are part of the Fortran ABI and therefore must match the way
> the Fortran library was compiled.
>

That sounds appealing, but...


>  This means that these symbols have to come from the libmpifort_abi.so
> (not previously discussed, but obvious), not libmpi.so,
>

1) The concept of "Fortran ABI" is an oxymoron. I don't see
libmpifort_abi.so as obvious. Fortran does not even offer portability for
.mod files!
2) It is not fun to depend on Fortran MPI libraries (which may depend in
turn on Fortran runtime libraries) just to convert between handle
representations. In my particular case as the maintainer of a language
wrapper, I would rather remove my f2c/c2f methods.

I'm still scratching my head about this issue, and I do not have so far a
sound idea to offer.


> and therefore this scheme works with implementations that provide both
> LP64 and ILP64 Fortran, as Intel MPI does.
>

Intel is not a good example of how to do things. This whole Intel thing
looks semi-broken. "mpi.h" has "typedef int MPI_Fint;" How are you supposed
to write portable C code that can call with the ILP64 version of the
library? Of course, we know that within Intel MPI, c2f/f2c are just macros,
and you can get things hacked. In any case, the MPI_Fint definition is
useless for portability.


> We also need Advice to Users saying that MPI_Fint is not part of the C ABI
> and is not present in the ABI mpi.h, but rather the user is required to
> query the type size at runtime and use the appropriate C type.
>
>
An alternative would be to provide new mechanisms for the C library to be
able to interoperate with both LP64 and ILP64 Fortran libraries, without an
explicit dependency on them (in the sense of dynamic linking dependency).
The old mechanisms (FInt/c2f/f2c) could be retained (and perhaps moved to
the Fortran libraries, if backward compatibility is not a concern). But on
a second though, perhaps the following is even better:

We can say that the old FInt/c2f/f2c mechanisms are still part of the C API
(and ABI), but they assume that Fortran INTEGER is compatible with C int,
and advise users to use the new mechanisms introduced in MPI-5.
This way we can move to a more productive discussion about what these
mechanisms would look like, rather than continue entangled in backward
compatibility concerns.

Additionally, maybe it is time for Fortran bindings to adapt to the new
reality and bend to the C API and ABI as lingua franca, pretty much as
Python/Julia/Java/Rust bindings would do. For example, an
"integer(kind=MPI_HANDLE_KIND)" would definitely help a lot with the issue
we are trying to address here. We could simply mandate that both MPI_Fint
and integer(kind=MPI_HANDLE_KIND) are pointer-sized integrals. This would
even eliminate the need for most of the c2f/f2c converters! Anyway, I
understand this change would introduce huge backward compatibility
headaches to Fortran users. We can still mandate MPI_Fint and
integer(kind=MPI_HANDLE_KIND) compatible with C int, this would be largely
backward compatible. New code compiled in either LP64 or ILP64 modes would
not need special handling.

At this point I need a Fortran lawyer here. Would
"integer(kind=MPI_HANDLE_KIND)" with "MPI_HANDLE_KIND" the default integer
kind be compatible with a plain "integer" declaration, for an invocation of
the Fortran compiler without special flags like -i8? If that is the case,
then we can unconditionally define MPI_Fint in C and
"integer(kind=MPI_HANDLE_KIND)" in Fortran as types compatible with
Fortran's default "INTEGER" type when invoked without special compilation
flags -i8 or -ilp64.

Sorry for the long email, it is definitely quite messy. I just wrote down
thoughts and they pop up in my head after a couple days of thinking about
it.

-- 
Lisandro Dalcin
============
Senior Research Scientist
Extreme Computing Research Center (ECRC)
King Abdullah University of Science and Technology (KAUST)
http://ecrc.kaust.edu.sa/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-abi/attachments/20230819/199e3b15/attachment.html>