[J3] BIND(F)?

Jeff Hammond jehammond at nvidia.com
Mon Jun 27 13:42:02 UTC 2022

> Lots of users would appreciate well-defined, interoperable Fortran calling conventions without using modules.

But which one to choose?

It doesn’t matter as long as it is consistent.  Breaking ABI once to achieve consistency is vastly superior to having N different ABIs forever.

>>> If we are going to do BIND(F..), we ought to try to make finite progress here.
>> Trying to enforce a uniform calling interface among all Fortran implementations would meet with a lot of resistance.  If only because of the significant changes required of compiler vendors, and the need for users to recompile all their existing  libraries.   (There was a language named “F”, making things even more confusing, as F lacked much of the newer features in Fortran.)
> I’m aware. But there are far more users than there are compiler implementers. Whatever the implementation pain might be, it is dwarfed by the pain Fortran users already endure because there is no standard.

But trying to mix object files created by different compilers seems less common in Fortran.  A  compilation organizer better than “make” (and MUCH better than CMAKE or SPACK) would be more useful, in my experience.  But that seems outside the domain of a language definition.

It is less common because it has never been practical.  What people will accept from reality does not represent the way they want the world to be.  Who wouldn’t want interoperable Fortran object files, other than compiler developers who would have to collaborate with each other to achieve this?

Right now, I guarantee you that there are ISVs and HPC customers who would combine Fortran object files in order to support NVIDIA, Intel and AMD GPUs in a single binary if this were not a recipe for endless misery.  Build systems and package managers are not really solutions here.  They just make working around the problem of building N binaries less painful.  What is actually useful is not having to build N binaries in the first place.

Lots of folks tolerate not having an ABI.  MPI is another example.  This does not mean users don’t want this.  Essentially every MPI library developer I know plus the Spack team would love to have this.  The only opponents are implementers who ABI innovation to cut 50 nanoseconds out of an MPI ping-pong benchmark is worth doubling or tripling the CI/QA cost of every MPI library on earth.

More on the MPI ABI topic, for those who might care:



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20220627/81e2c31b/attachment.htm>

More information about the J3 mailing list