(j3.2006) Alternative binding label without C interoperability?

[Rafik Zurob]

I've run into this problem when implementing libraries in Fortran that are 
intended to be called from Fortran.  The same Fortran compiler is used for 
both the library and the caller.  Here is an example:  Let's say I'm 
implementing a library function mylib_function() and I need it to call a 
helper mylib_helper().  Let's also assume that I would like the two 
functions to be in the same compilation unit (*).  One way is to make 
mylib_function external and mylib_helper internal.  Some platforms, 
however, such as the current NVIDIA GPU toolkits don't support internal 
procedures.  So my alternative is to write a module mylib_mod that 
contains a public mylib_function and a private mylib_helper.  But making 
mylib_function a module procedure introduces mangling, which I don't want. 
 The fact the function is implemented as a module procedure is a library 
implementation choice and not part of its public interface.  My current 
solution is to use bind(c) binding labels on it.  This breaks down if the 
function has dummy arguments that are not representable in bind(c) or that 
change the calling convention.  Some compilers have directives to rename 
procedures.  This proposal provides a portable way of doing that.

Regards

Rafik
(*) The reasons are irrelevant to this discussion.

j3-bounces at mailman.j3-fortran.org wrote on 27/09/2016 09:19:19 PM:

> From: "Cohen Malcolm" <malcolm at nag-j.co.jp>
> To: "fortran standards email list for J3" <j3 at mailman.j3-fortran.org>
> Date: 27/09/2016 09:19 PM
> Subject: Re: (j3.2006) Alternative binding label without C 
interoperability?
> Sent by: j3-bounces at mailman.j3-fortran.org
> 
> I'm not sure what the problem is with normal external procedures here. 
If 
> there is a problem with name mangling, surely there will also be 
problems 
> with other parts of the ABI (argument passing conventions and the like). 

> Compilers that have compatibility options (so that things can 
interoperate 
> with other compilers) usually have those options affect more than just 
the 
> "name mangling", but how the stack and registers are used, what method 
is 
> used for passing character argument lengths, dope vector layouts, and so 
on.
> 
> Furthermore, without linking this binding name to the companion 
processor, 
> there is no reason for any compiler to produce something that is even 
the 
> same as that of another compiler.  The standard is able to specify this 
by 
> explicitly linking it to the companion processor's entity with that 
name. 
> Without any such entity, there is no way the standard can specify this.
> 
> Cheers,
> -- 
> ........................Malcolm Cohen, Nihon NAG, Tokyo. 
> 
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3
>