[mpiwg-abi] MPI_Fint in the ABI

Fri Aug 18 04:45:02 CDT 2023

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 at 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 at 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 at lists.mpi-forum.org <mailto:mpiwg-abi-bounces at lists.mpi-forum.org>> on behalf of Erik Schnetter <schnetter at gmail.com <mailto:schnetter at gmail.com>>
>> Sent: Thursday, August 17, 2023 9:35 AM
>> To: Jeff Hammond <jeff.science at gmail.com <mailto:jeff.science at gmail.com>>
>> Cc: mpiwg-abi <mpiwg-abi at lists.mpi-forum.org <mailto:mpiwg-abi at lists.mpi-forum.org>>; MPI Forum <mpiwg-fortran at lists.mpi-forum.org <mailto:mpiwg-fortran at lists.mpi-forum.org>>
>> 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 at gmail.com <mailto:jeff.science at 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 <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 at gmail.com <mailto:jeff.science at gmail.com>
>> > http://jeffhammond.github.io/ <http://jeffhammond.github.io/>
>> > --
>> > mpiwg-abi mailing list
>> > mpiwg-abi at lists.mpi-forum.org <mailto:mpiwg-abi at lists.mpi-forum.org>
>> > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi <https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi>
>> 
>> 
>> 
>> -- 
>> Erik Schnetter <schnetter at gmail.com <mailto:schnetter at gmail.com>>
>> http://www.perimeterinstitute.ca/personal/eschnetter/ <http://www.perimeterinstitute.ca/personal/eschnetter/>
>> -- 
>> mpiwg-abi mailing list
>> mpiwg-abi at lists.mpi-forum.org <mailto:mpiwg-abi at lists.mpi-forum.org>
>> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi <https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi>
> -- 
> mpiwg-abi mailing list
> mpiwg-abi at 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 at tu-dresden.de
He/him/his

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-abi/attachments/20230818/5095ce32/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5658 bytes
Desc: not available
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-abi/attachments/20230818/5095ce32/attachment-0001.p7s>