[mpiwg-abi] MPI_Fint in the ABI

[Jeff Hammond]

Fortran doesn’t have an ABI across compilers but the MPI Fortran ABI is defined by the use of constants that match the C ABI, as is required. It is involves similarly required compatibility with Aint, Offset and Count.

Intel likely achieves their ILP64 support by ignoring MPI_Fint in the header and dlopen-ing the right symbol on launch. I’ll verify that later.

A more expansive Fortran ABI definition that does what you propose has been considered. It represents a breaking API change and thus requires new module (and deprecated header) names. I intend to work on that after more important things are chugging along.

Jeff

Sent from my iPhone

On 19. Aug 2023, at 13.28, Lisandro Dalcin <dalcinl at gmail.com> wrote:


External email: Use caution opening links or attachments



On Sat, 19 Aug 2023 at 10:32, Jeff Hammond <jehammond at nvidia.com<mailto: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/cad2a4e0/attachment-0001.html>