[mpiwg-abi] MPI_Fint in the ABI

[Lisandro Dalcin]

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

> 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.
>
>
Oh, OK, so your definition of Fortran ABI is the one that, for a given
Fortran compiler, matches the C ABI.


> 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.
>

Well, my point is, the ILP64 support is Fortran-only. There are no
provisions for C and mpi.h to interoperate with the ILP64 library.


> 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.
>

That's why I asked for a Fortran lawyer. My limited knowledge of Fortran
tells me that "integer" and "integer(kind=selected_int_kind(0))" are the
same type. I fail to see the extent of the breakage, or why new
module names are needed.
If the new module uses "integer(kind=MPI_HANDLE_KIND)" with MPI_HANDLE_KIND
equal to selected_int_kind(0) for a standard invocation of the compiler,
old code that uses plain "integer :: comm" declarations should continue to
work, as long as users do not compile with -i8. For new code to work
seamlessly with an ILP64 Fortran library, users have to update their
Fortran code to use integer(kind=MPI_HANDLE_KIND), but in this case
MPI_HANDLE_KIND is still a 32bits integer.

-- 
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/ea687749/attachment.html>