[J3] BIND(F)?

Fri Jun 24 15:17:40 UTC 2022

On 24. Jun 2022, at 17.50, Bill Long <billlong at centurylink.net> wrote:

[You don't often get email from billlong at centurylink.net. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

External email: Use caution opening links or attachments

On Jun 24, 2022, at 6:37 AM, Long, Bill F <william.long at hpe.com> wrote:

From: J3 <j3-bounces at mailman.j3-fortran.org> on behalf of Jeff Hammond via J3 <j3 at mailman.j3-fortran.org>
Sent: Friday, June 24, 2022 3:40 AM
To: General J3 interest list <j3 at mailman.j3-fortran.org>
Cc: Jeff Hammond <jehammond at nvidia.com>
Subject: Re: [J3] BIND(F)?

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.

C interop only works because C has a mostly uniform ABI. Even so, a particular Fortran compiler is only interoperable with its specified “companion” C compiler.  (Usually the C compiler provided by the same vendor as the Fortran compiler, though that C compiler, these days, likely uses the CLANG specification as a base.)

At least in x86, I suspect the foundation remains https://refspecs.linuxfoundation.org/cxxabi-1.75.html and is indifferent to C compilers, which are themselves perfectly interoperable on a given platform, in the absence of perverse behavior.

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.

In the case of MKL ( or MPI, for that matter) the vendor could provide a Fortran module with all the interfaces for the library routines with BIND(C) specified, and then ship only the C library.  (Assuming that for every routine in the Fortran library, there is a corresponding one in the C library.)

And all the quantum chemists of the world said, “sorry, what’s a module?”

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

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.

I would assume that BIND(F,…) would affect ONLY the externally visible name of the routine.  (Which could get complicated if Fortran introduced a facility like templates. For the same reason, we do not have a BIND(C++,…) attribute supported. )

Fortran already had polymorphism and it works much more intelligently than C++. It is impossible to generate a 100000-line Fortran error message, and that’s a good thing.

Jeff

Cheers,
Bill

Jeff

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.

Cheers,
--
..............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.

Jeff

From: J3 <j3-bounces at mailman.j3-fortran.org> on behalf of Steve Lionel via J3 <j3 at mailman.j3-fortran.org>
Date: Friday, 24June 2022 at 12:40 AM
To: j3 at mailman.j3-fortran.org <j3 at mailman.j3-fortran.org>
Cc: Steve Lionel <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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fj3-fortran%2Ffortran_proposals&data=05%7C01%7Cjehammond%40nvidia.com%7Cc3e2b7be4c364e8f395608da55f0d4b5%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637916790096247272%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=iOkp7DqnR2Jw6IMfyo%2FipskD0Z%2BREon9M3W0RIDG0m0%3D&reserved=0 (if it's not already there)?

Steve

Bill Long
billlong at centurylink.net

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