[J3] [SC22WG5.6583] Fortran type sizes - please help with MPI Fortran

Jeff Hammond jehammond at nvidia.com
Fri Mar 29 20:22:32 UTC 2024


Intel MPI ships both LP64 and ILP64 libraries, although the latter is partial.  The ILP64 version doesn’t define DOUBLE PRECISION as FP128 though, so it violates the Fortran standard.  Users don’t care.

All I was asking for is for WG5 to recommend that the MPI ABI standardize on NUMERIC_STORAGE_SIZE=32, at least on systems where C int is 32b, which solves a huge range of problems.  It seems that isn’t compelling.

Jeff

On 29. Mar 2024, at 21.15, Brad Richardson <everythingfunctional at protonmail.com> wrote:

External email: Use caution opening links or attachments


Hi Jeff,

It is my expectation that there is virtually no existing code using MPI
where "INTEGER is INTEGER(kind=c_int)" is not the case, else it
wouldn't have worked in the first place. Unless you're telling me that
somebody is building a version of an MPI library and the Fortran
interface to it where that isn't the case, but if so I have faith they
could figure out how to continue doing weird things with the right
compiler options.

Brad

On Fri, 2024-03-29 at 17:54 +0000, Jeff Hammond via J3 wrote:
MPI has three types of Fortran support.  The (deprecated) mpif.h and
MPI.mod support an old-fashioned API, where we only use the primitive
types of Fortran 77.  At least with MPI.mod, the compiler can do
interface checking, although the type-safety is quite weak given most
arguments are INTEGER.  The newer MPI_F08.mod, which Bill Long was
instrumental in creating and which WG5 made possible with the Fortran
2018 CFI extensions, is a properly typed, modern Fortran API.

The idea that "it will work" is equivalent to MPI asserting that
INTEGER is INTEGER(kind=c_int) or the MPI ABI doesn’t work, which
certain people will not accept unless WG5 provides some sort of
evidence that I am not a lunatic for wanting to assert this.

Jeff

On 29. Mar 2024, at 19.33, Thomas König <tk at tkoenig.net> wrote:

External email: Use caution opening links or attachments


Am 29.03.24 um 16:24 schrieb Jeff Hammond via J3:
The issue is, we have 30 years of MPI Fortran code that does
things
that are correct according to MPI and Fortran, but which are
broken if
we do certain things that are otherwise very nice from a software
design perspective.  Breaking user code is bad for business, as
everybody here knows :-)

If we could redefine MPI Fortran to use ISO_C_BINDING types, we’d
have
zero problems, but ISO_C_BINDING came a decade after MPI was
created
and Fortran 2003 compilers weren’t widely available until well
after 2003.

How does MPI define its interfaces?  Does it use Fortran modules or
the traditional F77-style ABI (with no checking) that f2c etc use?

For the former, C interoperable types could be used; I think all
major compilers support it by now.

For Linux and at least some BSD variants on AMD64, the latter is
defined in the x86-64-ABI psABI, which can be found at
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.com%2Fx86-psABIs%2Fx86-64-ABI&data=05%7C02%7Cjehammond%40nvidia.com%7Cfe68b7dd3e4b452c158908dc5024a39a%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C638473365516602903%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Ofynpf24uYP0ba4X7hhf%2BduZWAV4SE71RFRozVTAIp0%3D&reserved=0<https://gitlab.com/x86-psABIs/x86-64-ABI> (section 9.2),
and major other architectures and operating systems effectively do
the same.

Maybe defining the MPI interface with respect to an existing ABI
would be less onerous than just saying "it will work".

Best regards

  Thomas

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20240329/de33195a/attachment-0001.htm>


More information about the J3 mailing list