August 2023 - mpiwg-abi - mailman3.cels.anl.gov

Re: [mpiwg-abi] MPI_Fint in the ABI
by Jeff Hammond 19 Aug '23

19 Aug '23

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(a)gmail.com> wrote: External email: Use caution opening links or attachments On Sat, 19 Aug 2023 at 10:32, Jeff Hammond <jehammond(a)nvidia.com<mailto:[email protected]>> 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/

1 0

Re: [mpiwg-abi] MPI_Fint in the ABI
by Lisandro Dalcin 19 Aug '23

19 Aug '23

On Sat, 19 Aug 2023 at 10:32, Jeff Hammond <jehammond(a)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/

1 0

Re: [mpiwg-abi] MPI_Fint in the ABI
by Jeff Hammond 19 Aug '23

19 Aug '23

First, I withdraw my idea for MPI_Abi_sizes since MPI_Type_size already works for all of that. We just need Advice to Users about it. 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. This means that these symbols have to come from the libmpifort_abi.so (not previously discussed, but obvious), not libmpi.so, and therefore this scheme works with implementations that provide both LP64 and ILP64 Fortran, as Intel MPI does. We will need to add Advice to Implementers about this, that ensure MPI_Type_size(MPI_INTEGER) does the right thing. 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. This is Option 2, with more detail. Jeff On 18. Aug 2023, at 21.04, Lisandro Dalcin <dalcinl(a)gmail.com> wrote: External email: Use caution opening links or attachments On Fri, 18 Aug 2023 at 17:28, Erik Schnetter <schnetter(a)gmail.com<mailto:[email protected]>> wrote: We can introduce a new type `MPIABI_Fint` which is always equal to a C `int`. In the MPI ABI we only use this type. But then we will need new MPIABI_XXX_{c2f|f2c} converters, right? And keep MPI_Fint (and current converters) for backward compatibility? -- Lisandro Dalcin ============ Senior Research Scientist Extreme Computing Research Center (ECRC) King Abdullah University of Science and Technology (KAUST) http://ecrc.kaust.edu.sa/ -- mpiwg-abi mailing list mpiwg-abi(a)lists.mpi-forum.org https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi

1 0

Re: [mpiwg-abi] MPI_Fint in the ABI
by Lisandro Dalcin 18 Aug '23

18 Aug '23

On Fri, 18 Aug 2023 at 17:28, Erik Schnetter <schnetter(a)gmail.com> wrote: > We can introduce a new type `MPIABI_Fint` which is always equal to a C > `int`. In the MPI ABI we only use this type. > > But then we will need new MPIABI_XXX_{c2f|f2c} converters, right? And keep MPI_Fint (and current converters) for backward compatibility? -- Lisandro Dalcin ============ Senior Research Scientist Extreme Computing Research Center (ECRC) King Abdullah University of Science and Technology (KAUST) http://ecrc.kaust.edu.sa/

1 0

Re: [mpiwg-abi] MPI_Fint in the ABI
by Erik Schnetter 18 Aug '23

18 Aug '23

We can introduce a new type `MPIABI_Fint` which is always equal to a C `int`. In the MPI ABI we only use this type. Incompatibilities can only arise if the MPI ABI caller also interacts with Fortran (in any way, e.g. directly with an MPI library or with an application), then the caller must surely know the size of a Fortran `integer` (how else could it interact), and can perform the necessary type conversions. That is, we act as if `MPI_Fint` was equal to a C `int`, for the purposes of this ABI. If this does not hold, then the caller needs to convert. We guarantee that any handles etc. fit in this range and can be converted losslessly. I believe this is your option 1. I think this does not introduce any problems that cannot be solved on the caller's side. -erik On Wed, Aug 16, 2023 at 4:09 AM Jeff Hammond <jeff.science(a)gmail.com> wrote: > > As we all know, Fortran users are permitted to change the size of INTEGER with compiler flags. This creates a problem for the MPI C ABI. > > I have considered three options and would like your opinions on them: > > 1. MPI_Fint is defined to be a C int in the standard ABI. This means MPI implementations that elect to provide an ILP64 MPI Fortran ABI on an I32LP64 system, for example, must not call this an implementation of the standard ABI. > > This would make a lot of things easier, but it might cause problems in the rare cases where users are using ILP64 in Fortran and using C code that actually uses MPI_Fint. > > 2. MPI_Fint ceases to be a compile-time fixed type in the standard ABI. The C code that uses MPI_Fint must make an MPI library call to figure out the size and do all of the necessary things to call the correct size. > > 3. MPI_Fint is not a fixed size but the standard ABI specifies that Fortran handle values must always fit into the range of a C int and we rely on the pass-by-value behavior of all the f2c/c2f APIs to behave properly when they are truncated. > > This is my preference but it breaks Example 19.11 in a serious way, because that user code makes use of a MPI_Fint pointer. However, this code isn't standard-compliant and relies on universal but non-standard argument passing conventions in Fortran. Writing a standard-compliant interface from Fortran to C - by doing the cast to INTEGER(kind=c_int) in Fortran - would resolve this. > > Example 19.11 is awful (https://github.com/mpi-forum/mpi-issues/issues/739) but it is nonetheless important to instruct users that if Option 3 is implemented, they need to do the casting to INTEGER(kind=c_int) and know that this is safe with the standard ABI. > > > None of these options is perfect. I'm not sure how much code is even impacted by MPI_Fint so it's hard to know which option breaks the most stuff, although Option 2 seems the least desirable in any case. > > Thanks, > > Jeff > > -- > Jeff Hammond > jeff.science(a)gmail.com > http://jeffhammond.github.io/ > -- > mpiwg-abi mailing list > mpiwg-abi(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi -- Erik Schnetter <schnetter(a)gmail.com> http://www.perimeterinstitute.ca/personal/eschnetter/

1 0

Re: [mpiwg-abi] MPI_Fint in the ABI
by Zhou, Hui 18 Aug '23

18 Aug '23

MPI_Fint is "part of C API" with a sole purpose of interoperate with Fortran. MPI_Fint be the same as Fortran INTEGER or it lose its design purpose. Since Fortran INTEGER is not binary fixed, we can't fix MPI_Fint in a ABI. The conversion routines such as MPI_Comm_f2c are in the same boat as MPI_Fint. They all need to be fixed in the ABI, or they need to be omitted together. My suggestion is to leave them out of ABI. They are still in the MPI API, so we are not breaking any applications. I imagine the use cases for MPI_Fint are all related to interoperate with Fortran, they always need to pay attention to ensure the compatibility of their Fortran compilers and Fortran binaries. Hui ________________________________ From: Jeff Hammond <jeff.science(a)gmail.com> Sent: Friday, August 18, 2023 4:35 AM To: Zhou, Hui <zhouh(a)anl.gov> Cc: Erik Schnetter <schnetter(a)gmail.com>; mpiwg-abi <mpiwg-abi(a)lists.mpi-forum.org>; MPI Forum <mpiwg-fortran(a)lists.mpi-forum.org> Subject: Re: [mpiwg-abi] MPI_Fint in the ABI MPI_Fint is part of the C ABI. It is strictly used in MPI C code to allow conversion of Fortran handles to C handles and vice versa. It must be part of the C ABI for the f2c/c2f functions to be part of the C ABI. For example, from 19.3.4: C binding MPI_Comm MPI_Comm_f2c(MPI_Fint comm) MPI_Fint MPI_Comm_c2f(MPI_Comm comm) MPI_Fint is not part of the Fortran API or ABI, because Fortran handles are defined to be INTEGER (or an INTEGER inside of a type(MPI_Handle) object). Jeff On 17. Aug 2023, at 17.52, Zhou, Hui <zhouh(a)anl.gov> wrote: I haven't gone through all the use cases, but my current opinion is, it is really a Fortran binding issue and should be left out of C ABI. Hui ________________________________ From: mpiwg-abi <mpiwg-abi-bounces(a)lists.mpi-forum.org<mailto:[email protected]>> on behalf of Erik Schnetter <schnetter(a)gmail.com<mailto:[email protected]>> Sent: Thursday, August 17, 2023 9:35 AM To: Jeff Hammond <jeff.science(a)gmail.com<mailto:[email protected]>> Cc: mpiwg-abi <mpiwg-abi(a)lists.mpi-forum.org<mailto:[email protected]>>; MPI Forum <mpiwg-fortran(a)lists.mpi-forum.org<mailto:[email protected]>> Subject: Re: [mpiwg-abi] MPI_Fint in the ABI Jeff As per the Fortran standard, the sizes of integer and real need to be the same. In practice this means that integers have 4 bytes. If someone chooses to change this – either changing the size of real as well or not – then they are breaking the Fortran standard, and probably know what they are doing, and are aware of the various incompatibilities and problems this will introduce. I would thus suggest keeping things simple for the common case. I would not expect there to be some code that interoperates with Fortran, and which is unaware of the Fortran integer size and still expects to get things right. People will either assume that integer = int, or will know the Fortran ABI details. In the MPI ABI we assume that the caller knows sizeof(int) and sizeof(void*), and I would also assume that they know sizeof(integer). I would keep `MPI_Fint` a fixed type. To cover all bases I also suggest that we provide a global constant struct with as much ABI information as we can think of, such as const struct MPIABI_info_t { int32_t MPIABI_version_major, MPIABI_version_minor; int32_t sizeof_bool; int32_t sizeof_char; int32_t sizeof_short; int32_t sizeof_int; int32_t sizeof_long; int32_t sizeof_long_long; int32_t sizeof_float; int32_t sizeof_double; int32_t sizeof_long_double; int32_t sizeof_void_p; int32_t sizeof_logical; int32_t sizeof_integer; int32_t sizeof_real; int32_t sizeof_char; } MPIABI_info; This information would not be necessary to use the ABI, but it will be convenient to check assumptions. Unsupported types report a size of -1. This struct can be extended in the future. -erik On Wed, Aug 16, 2023 at 4:09 AM Jeff Hammond <jeff.science(a)gmail.com<mailto:[email protected]>> wrote: > > As we all know, Fortran users are permitted to change the size of INTEGER with compiler flags. This creates a problem for the MPI C ABI. > > I have considered three options and would like your opinions on them: > > 1. MPI_Fint is defined to be a C int in the standard ABI. This means MPI implementations that elect to provide an ILP64 MPI Fortran ABI on an I32LP64 system, for example, must not call this an implementation of the standard ABI. > > This would make a lot of things easier, but it might cause problems in the rare cases where users are using ILP64 in Fortran and using C code that actually uses MPI_Fint. > > 2. MPI_Fint ceases to be a compile-time fixed type in the standard ABI. The C code that uses MPI_Fint must make an MPI library call to figure out the size and do all of the necessary things to call the correct size. > > 3. MPI_Fint is not a fixed size but the standard ABI specifies that Fortran handle values must always fit into the range of a C int and we rely on the pass-by-value behavior of all the f2c/c2f APIs to behave properly when they are truncated. > > This is my preference but it breaks Example 19.11 in a serious way, because that user code makes use of a MPI_Fint pointer. However, this code isn't standard-compliant and relies on universal but non-standard argument passing conventions in Fortran. Writing a standard-compliant interface from Fortran to C - by doing the cast to INTEGER(kind=c_int) in Fortran - would resolve this. > > Example 19.11 is awful (https://github.com/mpi-forum/mpi-issues/issues/739) but it is nonetheless important to instruct users that if Option 3 is implemented, they need to do the casting to INTEGER(kind=c_int) and know that this is safe with the standard ABI. > > > None of these options is perfect. I'm not sure how much code is even impacted by MPI_Fint so it's hard to know which option breaks the most stuff, although Option 2 seems the least desirable in any case. > > Thanks, > > Jeff > > -- > Jeff Hammond > jeff.science(a)gmail.com<mailto:[email protected]> > http://jeffhammond.github.io/ > -- > mpiwg-abi mailing list > mpiwg-abi(a)lists.mpi-forum.org<mailto:[email protected]> > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi -- Erik Schnetter <schnetter(a)gmail.com<mailto:[email protected]>> http://www.perimeterinstitute.ca/personal/eschnetter/ -- mpiwg-abi mailing list mpiwg-abi(a)lists.mpi-forum.org<mailto:[email protected]> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi

1 0

Re: [mpiwg-abi] MPI_Fint in the ABI
by Jeff Hammond 18 Aug '23

18 Aug '23

The problem with that is here: int MPI_Status_c2f(const MPI_Status *c_status, MPI_Fint *f_status) You are right that pass-by-value scalars are fine if we bound the range to make truncation work, but pointers do not allow this. Jeff > On 18. Aug 2023, at 12.45, William Robert Williams <william.williams(a)tu-dresden.de> wrote: > > Is there a reason not to mix 1 and 3: MPI_Fint is a fixed C type, decouple it from INTEGER, and require Fortran handles to stay within the smaller of INTEGER and MPI_Fint in order to be valid? (Yes, backwards compatibility, but that’s probably gone regardless in order to ABI-specify MPI_Fint.) This way an implementation can have larger or smaller INTEGERs vs. C ints as it desires, as long as it guarantees that they are valid MPI_Fints as well, and Fint stays fixed. > > 19.3.4 will need revision no matter what we decide. > > —Bill > >> On 18. Aug 2023, at 11:35, Jeff Hammond <jeff.science(a)gmail.com <mailto:[email protected]>> wrote: >> >> MPI_Fint is part of the C ABI. It is strictly used in MPI C code to allow conversion of Fortran handles to C handles and vice versa. It must be part of the C ABI for the f2c/c2f functions to be part of the C ABI. >> >> For example, from 19.3.4: >> >> C binding >> MPI_Comm MPI_Comm_f2c(MPI_Fint comm) >> MPI_Fint MPI_Comm_c2f(MPI_Comm comm) >> >> MPI_Fint is not part of the Fortran API or ABI, because Fortran handles are defined to be INTEGER (or an INTEGER inside of a type(MPI_Handle) object). >> >> Jeff >> >>> On 17. Aug 2023, at 17.52, Zhou, Hui <zhouh(a)anl.gov <mailto:[email protected]>> wrote: >>> >>> I haven't gone through all the use cases, but my current opinion is, it is really a Fortran binding issue and should be left out of C ABI. >>> >>> Hui >>> >>> From: mpiwg-abi <mpiwg-abi-bounces(a)lists.mpi-forum.org <mailto:[email protected]>> on behalf of Erik Schnetter <schnetter(a)gmail.com <mailto:[email protected]>> >>> Sent: Thursday, August 17, 2023 9:35 AM >>> To: Jeff Hammond <jeff.science(a)gmail.com <mailto:[email protected]>> >>> Cc: mpiwg-abi <mpiwg-abi(a)lists.mpi-forum.org <mailto:[email protected]>>; MPI Forum <mpiwg-fortran(a)lists.mpi-forum.org <mailto:[email protected]>> >>> Subject: Re: [mpiwg-abi] MPI_Fint in the ABI >>> >>> Jeff >>> >>> As per the Fortran standard, the sizes of integer and real need to be >>> the same. In practice this means that integers have 4 bytes. If >>> someone chooses to change this – either changing the size of real as >>> well or not – then they are breaking the Fortran standard, and >>> probably know what they are doing, and are aware of the various >>> incompatibilities and problems this will introduce. I would thus >>> suggest keeping things simple for the common case. I would not expect >>> there to be some code that interoperates with Fortran, and which is >>> unaware of the Fortran integer size and still expects to get things >>> right. People will either assume that integer = int, or will know the >>> Fortran ABI details. >>> >>> In the MPI ABI we assume that the caller knows sizeof(int) and >>> sizeof(void*), and I would also assume that they know sizeof(integer). >>> I would keep `MPI_Fint` a fixed type. >>> >>> To cover all bases I also suggest that we provide a global constant >>> struct with as much ABI information as we can think of, such as >>> >>> const struct MPIABI_info_t { >>> int32_t MPIABI_version_major, MPIABI_version_minor; >>> int32_t sizeof_bool; >>> int32_t sizeof_char; >>> int32_t sizeof_short; >>> int32_t sizeof_int; >>> int32_t sizeof_long; >>> int32_t sizeof_long_long; >>> int32_t sizeof_float; >>> int32_t sizeof_double; >>> int32_t sizeof_long_double; >>> int32_t sizeof_void_p; >>> int32_t sizeof_logical; >>> int32_t sizeof_integer; >>> int32_t sizeof_real; >>> int32_t sizeof_char; >>> } MPIABI_info; >>> >>> This information would not be necessary to use the ABI, but it will be >>> convenient to check assumptions. Unsupported types report a size of >>> -1. >>> >>> This struct can be extended in the future. >>> >>> -erik >>> >>> On Wed, Aug 16, 2023 at 4:09 AM Jeff Hammond <jeff.science(a)gmail.com <mailto:[email protected]>> wrote: >>> > >>> > As we all know, Fortran users are permitted to change the size of INTEGER with compiler flags. This creates a problem for the MPI C ABI. >>> > >>> > I have considered three options and would like your opinions on them: >>> > >>> > 1. MPI_Fint is defined to be a C int in the standard ABI. This means MPI implementations that elect to provide an ILP64 MPI Fortran ABI on an I32LP64 system, for example, must not call this an implementation of the standard ABI. >>> > >>> > This would make a lot of things easier, but it might cause problems in the rare cases where users are using ILP64 in Fortran and using C code that actually uses MPI_Fint. >>> > >>> > 2. MPI_Fint ceases to be a compile-time fixed type in the standard ABI. The C code that uses MPI_Fint must make an MPI library call to figure out the size and do all of the necessary things to call the correct size. >>> > >>> > 3. MPI_Fint is not a fixed size but the standard ABI specifies that Fortran handle values must always fit into the range of a C int and we rely on the pass-by-value behavior of all the f2c/c2f APIs to behave properly when they are truncated. >>> > >>> > This is my preference but it breaks Example 19.11 in a serious way, because that user code makes use of a MPI_Fint pointer. However, this code isn't standard-compliant and relies on universal but non-standard argument passing conventions in Fortran. Writing a standard-compliant interface from Fortran to C - by doing the cast to INTEGER(kind=c_int) in Fortran - would resolve this. >>> > >>> > Example 19.11 is awful (https://github.com/mpi-forum/mpi-issues/issues/739) but it is nonetheless important to instruct users that if Option 3 is implemented, they need to do the casting to INTEGER(kind=c_int) and know that this is safe with the standard ABI. >>> > >>> > >>> > None of these options is perfect. I'm not sure how much code is even impacted by MPI_Fint so it's hard to know which option breaks the most stuff, although Option 2 seems the least desirable in any case. >>> > >>> > Thanks, >>> > >>> > Jeff >>> > >>> > -- >>> > Jeff Hammond >>> > jeff.science(a)gmail.com <mailto:[email protected]> >>> > http://jeffhammond.github.io/ >>> > -- >>> > mpiwg-abi mailing list >>> > mpiwg-abi(a)lists.mpi-forum.org <mailto:[email protected]> >>> > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi >>> >>> >>> >>> -- >>> Erik Schnetter <schnetter(a)gmail.com <mailto:[email protected]>> >>> http://www.perimeterinstitute.ca/personal/eschnetter/ >>> -- >>> mpiwg-abi mailing list >>> mpiwg-abi(a)lists.mpi-forum.org <mailto:[email protected]> >>> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi >> >> -- >> mpiwg-abi mailing list >> mpiwg-abi(a)lists.mpi-forum.org <mailto:[email protected]> >> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi > > -- > Bill Williams > Wiss. Mitarbeiter > ZIH-IAK, TU-Dresden > Falkenbrunnen, Room 009 > Chemnitzer Straße 50 > 01187 Dresden > Phone: +49 351 463-39976 > e-mail: william.williams(a)tu-dresden.de <mailto:[email protected]> > He/him/his >

1 0

Re: [mpiwg-abi] MPI_Fint in the ABI
by Jeff Hammond 18 Aug '23

18 Aug '23

I just realized that option 3 doesn’t work for MPI_Status f2c/c2f, so it must be rejected. We have to choose 1 or 2. We are building an ABI to allow people to write libraries that just work with all of the implementations. This includes enabling programmers to write C libraries that interoperate with arbitrary MPI Fortran code. This code needs a way to know what MPI_Fint is without interacting with the Fortran environment. That is why we need to either prescribe the value of MPI_Fint or make it queryable from C code using MPI features. As far as ABI information, the proposal includes the following: int MPI_Abi_supported(int *flag) Int MPI_Abi_version(int *major, int *minor) int MPI_Abi_sizes(int *aint_size, int *offset_size, int *count_size, int *fint_size) int MPI_Abi_details(int *buflen, char *details) My intent with MPI_Abi_details was to allow implementations to disclose their non-standard ABI info there when flag=false. I’m happy to add an MPI_Info there if people prefer that method of including data. The struct design you propose isn’t really the MPI Way (TM). I’m not personally opposed but we don’t have a nice way to expose that in Fortran. I do not understand the need for MPIABI_info_t. We have MPI_TYPE_SIZE to query what the size of the MPI types arrow, which is what one needs to know when interacting with the ABI. Can you describe the use case where non-C code needs to know the size of a C long double, for example? If Julia is going to pass long double data into MPI, what matters if MPI_LONG_DOUBLE. Jeff > On 17. Aug 2023, at 17.35, Erik Schnetter <schnetter(a)gmail.com> wrote: > > Jeff > > As per the Fortran standard, the sizes of integer and real need to be > the same. In practice this means that integers have 4 bytes. If > someone chooses to change this – either changing the size of real as > well or not – then they are breaking the Fortran standard, and > probably know what they are doing, and are aware of the various > incompatibilities and problems this will introduce. I would thus > suggest keeping things simple for the common case. I would not expect > there to be some code that interoperates with Fortran, and which is > unaware of the Fortran integer size and still expects to get things > right. People will either assume that integer = int, or will know the > Fortran ABI details. > > In the MPI ABI we assume that the caller knows sizeof(int) and > sizeof(void*), and I would also assume that they know sizeof(integer). > I would keep `MPI_Fint` a fixed type. > > To cover all bases I also suggest that we provide a global constant > struct with as much ABI information as we can think of, such as > > const struct MPIABI_info_t { > int32_t MPIABI_version_major, MPIABI_version_minor; > int32_t sizeof_bool; > int32_t sizeof_char; > int32_t sizeof_short; > int32_t sizeof_int; > int32_t sizeof_long; > int32_t sizeof_long_long; > int32_t sizeof_float; > int32_t sizeof_double; > int32_t sizeof_long_double; > int32_t sizeof_void_p; > int32_t sizeof_logical; > int32_t sizeof_integer; > int32_t sizeof_real; > int32_t sizeof_char; > } MPIABI_info; > > This information would not be necessary to use the ABI, but it will be > convenient to check assumptions. Unsupported types report a size of > -1. > > This struct can be extended in the future. > > -erik > > On Wed, Aug 16, 2023 at 4:09 AM Jeff Hammond <jeff.science(a)gmail.com> wrote: >> >> As we all know, Fortran users are permitted to change the size of INTEGER with compiler flags. This creates a problem for the MPI C ABI. >> >> I have considered three options and would like your opinions on them: >> >> 1. MPI_Fint is defined to be a C int in the standard ABI. This means MPI implementations that elect to provide an ILP64 MPI Fortran ABI on an I32LP64 system, for example, must not call this an implementation of the standard ABI. >> >> This would make a lot of things easier, but it might cause problems in the rare cases where users are using ILP64 in Fortran and using C code that actually uses MPI_Fint. >> >> 2. MPI_Fint ceases to be a compile-time fixed type in the standard ABI. The C code that uses MPI_Fint must make an MPI library call to figure out the size and do all of the necessary things to call the correct size. >> >> 3. MPI_Fint is not a fixed size but the standard ABI specifies that Fortran handle values must always fit into the range of a C int and we rely on the pass-by-value behavior of all the f2c/c2f APIs to behave properly when they are truncated. >> >> This is my preference but it breaks Example 19.11 in a serious way, because that user code makes use of a MPI_Fint pointer. However, this code isn't standard-compliant and relies on universal but non-standard argument passing conventions in Fortran. Writing a standard-compliant interface from Fortran to C - by doing the cast to INTEGER(kind=c_int) in Fortran - would resolve this. >> >> Example 19.11 is awful (https://github.com/mpi-forum/mpi-issues/issues/739) but it is nonetheless important to instruct users that if Option 3 is implemented, they need to do the casting to INTEGER(kind=c_int) and know that this is safe with the standard ABI. >> >> >> None of these options is perfect. I'm not sure how much code is even impacted by MPI_Fint so it's hard to know which option breaks the most stuff, although Option 2 seems the least desirable in any case. >> >> Thanks, >> >> Jeff >> >> -- >> Jeff Hammond >> jeff.science(a)gmail.com >> http://jeffhammond.github.io/ >> -- >> mpiwg-abi mailing list >> mpiwg-abi(a)lists.mpi-forum.org >> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi > > > > -- > Erik Schnetter <schnetter(a)gmail.com> > http://www.perimeterinstitute.ca/personal/eschnetter/

1 0

Re: [mpiwg-abi] MPI_Fint in the ABI
by William Robert Williams 18 Aug '23

18 Aug '23

Is there a reason not to mix 1 and 3: MPI_Fint is a fixed C type, decouple it from INTEGER, and require Fortran handles to stay within the smaller of INTEGER and MPI_Fint in order to be valid? (Yes, backwards compatibility, but that’s probably gone regardless in order to ABI-specify MPI_Fint.) This way an implementation can have larger or smaller INTEGERs vs. C ints as it desires, as long as it guarantees that they are valid MPI_Fints as well, and Fint stays fixed. 19.3.4 will need revision no matter what we decide. —Bill > On 18. Aug 2023, at 11:35, Jeff Hammond <jeff.science(a)gmail.com> wrote: > > MPI_Fint is part of the C ABI. It is strictly used in MPI C code to allow conversion of Fortran handles to C handles and vice versa. It must be part of the C ABI for the f2c/c2f functions to be part of the C ABI. > > For example, from 19.3.4: > > C binding > MPI_Comm MPI_Comm_f2c(MPI_Fint comm) > MPI_Fint MPI_Comm_c2f(MPI_Comm comm) > > MPI_Fint is not part of the Fortran API or ABI, because Fortran handles are defined to be INTEGER (or an INTEGER inside of a type(MPI_Handle) object). > > Jeff > >> On 17. Aug 2023, at 17.52, Zhou, Hui <zhouh(a)anl.gov> wrote: >> >> I haven't gone through all the use cases, but my current opinion is, it is really a Fortran binding issue and should be left out of C ABI. >> >> Hui >> >> From: mpiwg-abi <mpiwg-abi-bounces(a)lists.mpi-forum.org <mailto:[email protected]>> on behalf of Erik Schnetter <schnetter(a)gmail.com <mailto:[email protected]>> >> Sent: Thursday, August 17, 2023 9:35 AM >> To: Jeff Hammond <jeff.science(a)gmail.com <mailto:[email protected]>> >> Cc: mpiwg-abi <mpiwg-abi(a)lists.mpi-forum.org <mailto:[email protected]>>; MPI Forum <mpiwg-fortran(a)lists.mpi-forum.org <mailto:[email protected]>> >> Subject: Re: [mpiwg-abi] MPI_Fint in the ABI >> >> Jeff >> >> As per the Fortran standard, the sizes of integer and real need to be >> the same. In practice this means that integers have 4 bytes. If >> someone chooses to change this – either changing the size of real as >> well or not – then they are breaking the Fortran standard, and >> probably know what they are doing, and are aware of the various >> incompatibilities and problems this will introduce. I would thus >> suggest keeping things simple for the common case. I would not expect >> there to be some code that interoperates with Fortran, and which is >> unaware of the Fortran integer size and still expects to get things >> right. People will either assume that integer = int, or will know the >> Fortran ABI details. >> >> In the MPI ABI we assume that the caller knows sizeof(int) and >> sizeof(void*), and I would also assume that they know sizeof(integer). >> I would keep `MPI_Fint` a fixed type. >> >> To cover all bases I also suggest that we provide a global constant >> struct with as much ABI information as we can think of, such as >> >> const struct MPIABI_info_t { >> int32_t MPIABI_version_major, MPIABI_version_minor; >> int32_t sizeof_bool; >> int32_t sizeof_char; >> int32_t sizeof_short; >> int32_t sizeof_int; >> int32_t sizeof_long; >> int32_t sizeof_long_long; >> int32_t sizeof_float; >> int32_t sizeof_double; >> int32_t sizeof_long_double; >> int32_t sizeof_void_p; >> int32_t sizeof_logical; >> int32_t sizeof_integer; >> int32_t sizeof_real; >> int32_t sizeof_char; >> } MPIABI_info; >> >> This information would not be necessary to use the ABI, but it will be >> convenient to check assumptions. Unsupported types report a size of >> -1. >> >> This struct can be extended in the future. >> >> -erik >> >> On Wed, Aug 16, 2023 at 4:09 AM Jeff Hammond <jeff.science(a)gmail.com <mailto:[email protected]>> wrote: >> > >> > As we all know, Fortran users are permitted to change the size of INTEGER with compiler flags. This creates a problem for the MPI C ABI. >> > >> > I have considered three options and would like your opinions on them: >> > >> > 1. MPI_Fint is defined to be a C int in the standard ABI. This means MPI implementations that elect to provide an ILP64 MPI Fortran ABI on an I32LP64 system, for example, must not call this an implementation of the standard ABI. >> > >> > This would make a lot of things easier, but it might cause problems in the rare cases where users are using ILP64 in Fortran and using C code that actually uses MPI_Fint. >> > >> > 2. MPI_Fint ceases to be a compile-time fixed type in the standard ABI. The C code that uses MPI_Fint must make an MPI library call to figure out the size and do all of the necessary things to call the correct size. >> > >> > 3. MPI_Fint is not a fixed size but the standard ABI specifies that Fortran handle values must always fit into the range of a C int and we rely on the pass-by-value behavior of all the f2c/c2f APIs to behave properly when they are truncated. >> > >> > This is my preference but it breaks Example 19.11 in a serious way, because that user code makes use of a MPI_Fint pointer. However, this code isn't standard-compliant and relies on universal but non-standard argument passing conventions in Fortran. Writing a standard-compliant interface from Fortran to C - by doing the cast to INTEGER(kind=c_int) in Fortran - would resolve this. >> > >> > Example 19.11 is awful (https://github.com/mpi-forum/mpi-issues/issues/739 <https://github.com/mpi-forum/mpi-issues/issues/739>) but it is nonetheless important to instruct users that if Option 3 is implemented, they need to do the casting to INTEGER(kind=c_int) and know that this is safe with the standard ABI. >> > >> > >> > None of these options is perfect. I'm not sure how much code is even impacted by MPI_Fint so it's hard to know which option breaks the most stuff, although Option 2 seems the least desirable in any case. >> > >> > Thanks, >> > >> > Jeff >> > >> > -- >> > Jeff Hammond >> > jeff.science(a)gmail.com <mailto:[email protected]> >> > http://jeffhammond.github.io/ <http://jeffhammond.github.io/> >> > -- >> > mpiwg-abi mailing list >> > mpiwg-abi(a)lists.mpi-forum.org <mailto:[email protected]> >> > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi <https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi> >> >> >> >> -- >> Erik Schnetter <schnetter(a)gmail.com <mailto:[email protected]>> >> http://www.perimeterinstitute.ca/personal/eschnetter/ <http://www.perimeterinstitute.ca/personal/eschnetter/> >> -- >> mpiwg-abi mailing list >> mpiwg-abi(a)lists.mpi-forum.org <mailto:[email protected]> >> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi <https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi> > -- > mpiwg-abi mailing list > mpiwg-abi(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi -- Bill Williams Wiss. Mitarbeiter ZIH-IAK, TU-Dresden Falkenbrunnen, Room 009 Chemnitzer Straße 50 01187 Dresden Phone: +49 351 463-39976 e-mail: william.williams(a)tu-dresden.de He/him/his

1 0

Re: [mpiwg-abi] MPI_Fint in the ABI
by Jeff Hammond 18 Aug '23

18 Aug '23

MPI_Fint is part of the C ABI. It is strictly used in MPI C code to allow conversion of Fortran handles to C handles and vice versa. It must be part of the C ABI for the f2c/c2f functions to be part of the C ABI. For example, from 19.3.4: C binding MPI_Comm MPI_Comm_f2c(MPI_Fint comm) MPI_Fint MPI_Comm_c2f(MPI_Comm comm) MPI_Fint is not part of the Fortran API or ABI, because Fortran handles are defined to be INTEGER (or an INTEGER inside of a type(MPI_Handle) object). Jeff > On 17. Aug 2023, at 17.52, Zhou, Hui <zhouh(a)anl.gov> wrote: > > I haven't gone through all the use cases, but my current opinion is, it is really a Fortran binding issue and should be left out of C ABI. > > Hui > > From: mpiwg-abi <mpiwg-abi-bounces(a)lists.mpi-forum.org <mailto:[email protected]>> on behalf of Erik Schnetter <schnetter(a)gmail.com <mailto:[email protected]>> > Sent: Thursday, August 17, 2023 9:35 AM > To: Jeff Hammond <jeff.science(a)gmail.com <mailto:[email protected]>> > Cc: mpiwg-abi <mpiwg-abi(a)lists.mpi-forum.org <mailto:[email protected]>>; MPI Forum <mpiwg-fortran(a)lists.mpi-forum.org <mailto:[email protected]>> > Subject: Re: [mpiwg-abi] MPI_Fint in the ABI > > Jeff > > As per the Fortran standard, the sizes of integer and real need to be > the same. In practice this means that integers have 4 bytes. If > someone chooses to change this – either changing the size of real as > well or not – then they are breaking the Fortran standard, and > probably know what they are doing, and are aware of the various > incompatibilities and problems this will introduce. I would thus > suggest keeping things simple for the common case. I would not expect > there to be some code that interoperates with Fortran, and which is > unaware of the Fortran integer size and still expects to get things > right. People will either assume that integer = int, or will know the > Fortran ABI details. > > In the MPI ABI we assume that the caller knows sizeof(int) and > sizeof(void*), and I would also assume that they know sizeof(integer). > I would keep `MPI_Fint` a fixed type. > > To cover all bases I also suggest that we provide a global constant > struct with as much ABI information as we can think of, such as > > const struct MPIABI_info_t { > int32_t MPIABI_version_major, MPIABI_version_minor; > int32_t sizeof_bool; > int32_t sizeof_char; > int32_t sizeof_short; > int32_t sizeof_int; > int32_t sizeof_long; > int32_t sizeof_long_long; > int32_t sizeof_float; > int32_t sizeof_double; > int32_t sizeof_long_double; > int32_t sizeof_void_p; > int32_t sizeof_logical; > int32_t sizeof_integer; > int32_t sizeof_real; > int32_t sizeof_char; > } MPIABI_info; > > This information would not be necessary to use the ABI, but it will be > convenient to check assumptions. Unsupported types report a size of > -1. > > This struct can be extended in the future. > > -erik > > On Wed, Aug 16, 2023 at 4:09 AM Jeff Hammond <jeff.science(a)gmail.com <mailto:[email protected]>> wrote: > > > > As we all know, Fortran users are permitted to change the size of INTEGER with compiler flags. This creates a problem for the MPI C ABI. > > > > I have considered three options and would like your opinions on them: > > > > 1. MPI_Fint is defined to be a C int in the standard ABI. This means MPI implementations that elect to provide an ILP64 MPI Fortran ABI on an I32LP64 system, for example, must not call this an implementation of the standard ABI. > > > > This would make a lot of things easier, but it might cause problems in the rare cases where users are using ILP64 in Fortran and using C code that actually uses MPI_Fint. > > > > 2. MPI_Fint ceases to be a compile-time fixed type in the standard ABI. The C code that uses MPI_Fint must make an MPI library call to figure out the size and do all of the necessary things to call the correct size. > > > > 3. MPI_Fint is not a fixed size but the standard ABI specifies that Fortran handle values must always fit into the range of a C int and we rely on the pass-by-value behavior of all the f2c/c2f APIs to behave properly when they are truncated. > > > > This is my preference but it breaks Example 19.11 in a serious way, because that user code makes use of a MPI_Fint pointer. However, this code isn't standard-compliant and relies on universal but non-standard argument passing conventions in Fortran. Writing a standard-compliant interface from Fortran to C - by doing the cast to INTEGER(kind=c_int) in Fortran - would resolve this. > > > > Example 19.11 is awful (https://github.com/mpi-forum/mpi-issues/issues/739) but it is nonetheless important to instruct users that if Option 3 is implemented, they need to do the casting to INTEGER(kind=c_int) and know that this is safe with the standard ABI. > > > > > > None of these options is perfect. I'm not sure how much code is even impacted by MPI_Fint so it's hard to know which option breaks the most stuff, although Option 2 seems the least desirable in any case. > > > > Thanks, > > > > Jeff > > > > -- > > Jeff Hammond > > jeff.science(a)gmail.com <mailto:[email protected]> > > http://jeffhammond.github.io/ > > -- > > mpiwg-abi mailing list > > mpiwg-abi(a)lists.mpi-forum.org <mailto:[email protected]> > > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi > > > > -- > Erik Schnetter <schnetter(a)gmail.com <mailto:[email protected]>> > http://www.perimeterinstitute.ca/personal/eschnetter/ > -- > mpiwg-abi mailing list > mpiwg-abi(a)lists.mpi-forum.org <mailto:[email protected]> > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi

1 0