[J3] BIND(F)?

Malcolm Cohen malcolm at nag-j.co.jp
Fri Jun 24 08:30:26 UTC 2022


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 < <mailto:j3-bounces at mailman.j3-fortran.org>
j3-bounces at mailman.j3-fortran.org> on behalf of Steve Lionel via J3 <
<mailto:j3 at mailman.j3-fortran.org> j3 at mailman.j3-fortran.org>
Date: Friday, 24June 2022 at 12:40 AM
To:  <mailto:j3 at mailman.j3-fortran.org> j3 at mailman.j3-fortran.org <
<mailto:j3 at mailman.j3-fortran.org> j3 at mailman.j3-fortran.org>
Cc: Steve Lionel < <mailto:steve at stevelionel.com> 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.co
m%2Fj3-fortran%2Ffortran_proposals&data=05%7C01%7Cjehammond%40nvidia.com%7Cf
d8f74b2329d4386933408da55610376%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7
C637916172405649146%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu
MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=10VecJ16JXBfWOM8Y0g
0gMPcOFJ2lSGrBUQaaM6DceI%3D&reserved=0>
https://github.com/j3-fortran/fortran_proposals (if it's not already there)?

 

Steve

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


More information about the J3 mailing list