[J3] BIND(F)?

Jeff Hammond jehammond at nvidia.com
Fri Jun 24 08:40:38 UTC 2022

I understand it is possible to make choices such that the ABI situation with C is not good, but it takes work. On all modern computers, it is easy to get a good situation. The issues with eg MUSL or strange GCC flags are easily understood if needed but can be ignored by most users.

In contrast, basic interoperability between Fortran compilers is effectively impossible once one uses strings or complex numbers. This creates a huge mess for software developers and why, for example, we observe MKL shipping an Intel, GCC and PGI Fortran library, when C users see only one.

If we are going to do BIND(F..), we ought to try to make finite progress here.


Sent from my iPhone

On 24. Jun 2022, at 11.30, Malcolm Cohen via J3 <j3 at mailman.j3-fortran.org> wrote:

External email: Use caution opening links or attachments

However, different C compilers can and do have different ABIs. If one is lucky, the ABI is the same for all the C compilers on a particular machine/operating-system, but it is not guaranteed. That’s why BIND(C) has a single “companion processor”, which is not only the C compiler but also the options that change the ABI...

Indeed, even gcc by itself has multiple ABIs available via options, and these may be incompatible (for example, -freg-struct-return vs. -pcc-struct-return; gcc says that one “is not binary compatible” with the other).

Similarly, different C compilers may have their own implementation of stdio, and one compiler may generate different (incompatible) code from another compiler for getc et al. Or the maths functions.

So it is sadly untrue that such “interfaces are compiler independent”. They may be, and it is more likely to be true these days than in decades past (e.g. the hardware vendors did a lot of work to try to get people on the same ABI page for x86-64), or they may not be.

I note that Tom’s proposal as initially stated is useful for the stated purpose regardless of ABI; dlsym does not care what the ABI of the global symbol is.

..............Malcolm Cohen, NAG Oxford/Tokyo.

From: J3 <j3-bounces at mailman.j3-fortran.org> On Behalf Of Jeff Hammond via J3
Sent: Friday, June 24, 2022 2:39 PM
To: General J3 interest list <j3 at mailman.j3-fortran.org>
Cc: Jeff Hammond <jehammond at nvidia.com>
Subject: Re: [J3] BIND(F)?

One important feature of BIND(C..) is that, because C has an ABI, such interfaces are compiler independent.  Will BIND(F..) have that property or not?  I doubt it.  It sounds like more of a BIND(F_BUT_JUST_MY_COMPILER..) interface.

It seems to me that if one is going to add such a feature, it should be a true implementation of BIND(F..) and allow users to build Fortran DSOs that always work, and not just with the same compiler that created them.  Otherwise, they are not particularly useful as DSOs.


From: J3 <j3-bounces at mailman.j3-fortran.org<mailto:j3-bounces at mailman.j3-fortran.org>> on behalf of Steve Lionel via J3 <j3 at mailman.j3-fortran.org<mailto:j3 at mailman.j3-fortran.org>>
Date: Friday, 24June 2022 at 12:40 AM
To: j3 at mailman.j3-fortran.org<mailto:j3 at mailman.j3-fortran.org> <j3 at mailman.j3-fortran.org<mailto:j3 at mailman.j3-fortran.org>>
Cc: Steve Lionel <steve at stevelionel.com<mailto:steve at stevelionel.com>>
Subject: Re: [J3] BIND(F)?
External email: Use caution opening links or attachments

On 6/23/2022 5:35 PM, Clune, Thomas L. (GSFC-6101) via J3 wrote:
It seems a natural request then to allow a procedure to be declared BIND(F, name=”…”)   The procedure could then even live inside of a module (amusingly allowing the module to have no PUBLIC entities).

Is this unworkable for reasons that I don’t understand?   Low priority?    Or maybe a very small feature that could be put into 202y?
Every compiler I have used has syntax (usually a directive) to specify the global name of a procedure - ALIAS is often the keyword. It does sound like a small but useful feature that could be proposed for 202Y. One might quibble with the syntax suggested, but the basic idea is sound.

Why not post this at https://github.com/j3-fortran/fortran_proposals<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fj3-fortran%2Ffortran_proposals&data=05%7C01%7Cjehammond%40nvidia.com%7Cbd4f9d25fc90436b84d308da55bbce36%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637916562362053646%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=giNO9Y8k%2F8k0DtpuemPxzcILZuX7o8WSVkyFzwAaWkA%3D&reserved=0> (if it's not already there)?

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

More information about the J3 mailing list