You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have spent a lot of time imagining how to standardize an ABI where MPI_Fint is not hard-coded to C int. I have not found any solution to this problem.
This issue is mostly to describe the thought process so people can think about it on its own, before they dig into the full ABI proposal, which is where it matters.
I started by imagining a scenario where an implementation could provide both LP64 and ILP64 MPI Fortran shared objects. In that scenario, the f2c/c2f functions, which include cases where MPI_Fint arguments are passed by value and by pointer (status array). If these functions were implemented in the MPI Fortran shared object, they could be invoked consistently with the MPI Fortran code.
Even with this ambiguity, C code could invoke f2c/c2f and pass the arguments correctly using the correct C type. How would C determine that? Using MPI_Type_size(MPI_INTEGER,..), of course.
Except this doesn't work.
As shown in the program below, it is impossible for MPI_Type_size to determine the size of MPI_INTEGER prior to the invocation of any Fortran code, unless the size is hard-coded. And if the MPI implementation called out to Fortran inside of MPI_Type_size, it still wouldn't know what Fortran INTEGER the user selected at compile-time.
MPI_Fint will be defined to be C int in the ABI. The signatures of c2f/f2c functions will therefore be unambiguous.
Fortran INTEGER will be required to match C int in the ABI. The standard ABI will not support the scenario where INTEGER is modified by compiler flags.
Changes to the Text
This will be part of the ABI pull request.
Impact on Implementations
Intel MPI hard-codes MPI_Fint to C int already, even though they support both LP64 and ILP64 MPI modules. Their MPI_F08 module does not support ILP64.
Open MPI allows users to change the size of Fortran INTEGER. That flexibility would need to be disabled when compiling Open MPI with standard ABI support.
Impact on Users
Users who want to use the standard ABI and modify the default INTEGER in Fortran are not permitted to use INTEGER for MPI handles. They need to explicitly use INTEGER(kind=c_int) or something equivalent to it.
In NWChem, which often has a 64-bit INTEGER at build time, there's already code to use INTEGER*4 handles when MPI is called from Fortran, so clearly a finite number of users understand this issue already.
Now that we have deprecated mpif.h, we can rely on the fact that MPI Fortran modules perform type-checking to catch erroneous usage. Anyone insisting on using mpif.h has many problems, of which the lack of type-checking is only one.
References and Pull Requests
The text was updated successfully, but these errors were encountered:
Problem
I have spent a lot of time imagining how to standardize an ABI where
MPI_Fint
is not hard-coded to Cint
. I have not found any solution to this problem.This issue is mostly to describe the thought process so people can think about it on its own, before they dig into the full ABI proposal, which is where it matters.
I started by imagining a scenario where an implementation could provide both LP64 and ILP64 MPI Fortran shared objects. In that scenario, the f2c/c2f functions, which include cases where
MPI_Fint
arguments are passed by value and by pointer (status array). If these functions were implemented in the MPI Fortran shared object, they could be invoked consistently with the MPI Fortran code.Even with this ambiguity, C code could invoke f2c/c2f and pass the arguments correctly using the correct C type. How would C determine that? Using
MPI_Type_size(MPI_INTEGER,..)
, of course.Except this doesn't work.
As shown in the program below, it is impossible for
MPI_Type_size
to determine the size ofMPI_INTEGER
prior to the invocation of any Fortran code, unless the size is hard-coded. And if the MPI implementation called out to Fortran inside ofMPI_Type_size
, it still wouldn't know what FortranINTEGER
the user selected at compile-time.Proposal
MPI_Fint
will be defined to be Cint
in the ABI. The signatures of c2f/f2c functions will therefore be unambiguous.INTEGER
will be required to match Cint
in the ABI. The standard ABI will not support the scenario whereINTEGER
is modified by compiler flags.Changes to the Text
This will be part of the ABI pull request.
Impact on Implementations
Intel MPI hard-codes
MPI_Fint
to Cint
already, even though they support both LP64 and ILP64MPI
modules. TheirMPI_F08
module does not support ILP64.Open MPI allows users to change the size of Fortran
INTEGER
. That flexibility would need to be disabled when compiling Open MPI with standard ABI support.Impact on Users
Users who want to use the standard ABI and modify the default
INTEGER
in Fortran are not permitted to useINTEGER
for MPI handles. They need to explicitly useINTEGER(kind=c_int)
or something equivalent to it.In NWChem, which often has a 64-bit INTEGER at build time, there's already code to use
INTEGER*4
handles when MPI is called from Fortran, so clearly a finite number of users understand this issue already.Now that we have deprecated
mpif.h
, we can rely on the fact that MPI Fortran modules perform type-checking to catch erroneous usage. Anyone insisting on usingmpif.h
has many problems, of which the lack of type-checking is only one.References and Pull Requests
The text was updated successfully, but these errors were encountered: