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

Wed Sep 28 09:20:23 EDT 2016

Even when the processor provides flags to control the external binding name, their use is effectively impossible in a complex software stack.   They are too broad of a brush.

E.g., our model has (at least) the following _external_ dependencies that involve Fortran bindings:

  *   ESMF
  *   NetCDF
  *   HDF
  *   MPI
  *   LAPACK/BLAS

The use of processor-specific flags to control name mangling requires that we modify the the build system for all of the other layers involved to create proper compatibility in the call stack.   Not only is this sometimes challenging, in the case of commercial libraries like Intel MPI, it is completely impossible.

I?ve only been successful with such flags in very small projects.

The BIND(C) approach does not create such difficulties as we can be selective about which procedures are involved.

Cheers,

- Tom

On Sep 28, 2016, at 5:15 AM, Rafik Zurob <rzurob at ca.ibm.com<mailto:rzurob at ca.ibm.com>> wrote:

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<mailto: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<mailto:malcolm at nag-j.co.jp>>
To: "fortran standards email list for J3" <j3 at mailman.j3-fortran.org<mailto: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<mailto: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<mailto:J3 at mailman.j3-fortran.org>
http://mailman.j3-fortran.org/mailman/listinfo/j3

_______________________________________________
J3 mailing list
J3 at mailman.j3-fortran.org<mailto:J3 at mailman.j3-fortran.org>
http://mailman.j3-fortran.org/mailman/listinfo/j3

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.j3-fortran.org/pipermail/j3/attachments/20160928/a41767bd/attachment-0001.html 