[petsc-users] Fortran interfaces: Google Summer of Code project?

[Martin Diehl]

On Thu, 2024-03-21 at 16:35 -0600, Jed Brown wrote:
> Barry Smith <bsmith at petsc.dev> writes:
> 
> > In my limited understanding of the Fortran iso_c_binding, if we do
> > not provide an equivalent Fortran stub (the user calls) that uses
> > the iso_c_binding to call PETSc C code, then when the user calls
> > PETSc C code directly via the iso_c_binding they have to pass
> > iso_c_binding type arguments to the call. This I consider
> > unacceptable. So my conclusion was there is the same number of
> > stubs, just in a different language, so there is no reason to
> > consider changing since we cannot "delete lots of stubs", but I
> > could be wrong.
> 
> I don't want users to deal with iso_c_binding manually.
> 
> We already have the generated ftn-auto-interfaces/*.h90. The
> INTERFACE keyword could be replaced with CONTAINS (making these
> definitions instead of just interfaces), and then the bodies could
> use iso_c_binding to call the C functions. That would reduce
> repetition and be the standards-compliant way to do this. What we do
> now with detecting the Fortran mangling scheme and calling
> conventions "works" but doesn't conform to any standard and there's
> nothing stopping Fortran implementations from creating yet another
> variant that we have to deal with manually.
I think for "easy" functions, interfaces are sufficient. The only
change I propose with my current knowledge would be the use of
"bind(C)" on the Fortran side to get rid of the preprocessor statements
for name mangling.
For complicated functions, e.g. those having a string argument, I
currently use an interface that tells Fortran how the C function looks
like and a function definition that translates the Fortran string to a
C string.
> 
> I don't know if this change would enable inlining without LTO, though
> I think the indirection through our C sourcef.c is rarely a
> performance factor for Fortran users.

From the discussion, I conclude that there is general interest in the
topic and I would suggest that I go ahead and propose the topic. The
first task would then the comparison of different approaches for the
automated generation of interfaces

-- 
KU Leuven
Department of Computer Science
Department of Materials Engineering
Celestijnenlaan 200a
3001 Leuven, Belgium

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: This is a digitally signed message part
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20240321/2370e091/attachment.sig>