Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

why MPI_Fint must be C int (and related) #743

Open
jeffhammond opened this issue Aug 21, 2023 · 0 comments
Open

why MPI_Fint must be C int (and related) #743

jeffhammond opened this issue Aug 21, 2023 · 0 comments
Assignees
Labels
mpi-4.2 wg-abi ABI Working Group wg-fortran Fortran Working Group

Comments

@jeffhammond
Copy link
Member

jeffhammond commented Aug 21, 2023

Problem

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.

#include <stdint.h>
#include <mpi.h>

// Fortran library init routines
void initialize_fortran_library_i4(int32_t fcomm);
void initialize_fortran_library_i8(int64_t fcomm);

int main(void)
{
  MPI_Init(NULL,NULL);

  MPI_Comm node_comm = MPI_COMM_NULL;
  MPI_Comm_split_type(MPI_COMM_WORLD, MPI_COMM_TYPE_SHARED, 0, MPI_INFO_NULL, &node_comm);

  int fortran_int_size;
  MPI_Type_size(MPI_INTEGER, &fortran_int_size);

  // the Fortran procedure called has this interface
  // subroutine initialize_fortran_library_i{4,8}(comm) &
  //            bind(C,name=initialize_fortran_library_{4,8})
  //   integer, intent(in), value :: comm

  if (fortran_int_size == 4) {
    int32_t fcomm = MPI_Comm_c2f(node_comm);
    initialize_fortran_library_i4(fcomm);
  } else if (fortran_int_size == 8) {
    int64_t fcomm = MPI_Comm_c2f(node_comm);
    initialize_fortran_library_i8(fcomm);
  } else {
    call MPI_Abort(MPI_COMM_SELF, fortran_int_size);
  }

  MPI_Finalize();
  return 0;
}

Proposal

  1. MPI_Fint will be defined to be C int in the ABI. The signatures of c2f/f2c functions will therefore be unambiguous.
  2. 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

@jeffhammond jeffhammond added wg-fortran Fortran Working Group wg-abi ABI Working Group labels Aug 21, 2023
@jeffhammond jeffhammond self-assigned this Aug 21, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
mpi-4.2 wg-abi ABI Working Group wg-fortran Fortran Working Group
Projects
Status: To Do
Development

No branches or pull requests

2 participants