Le 02/11/2022 à 22:19, Harald Anlauf via Fortran a écrit :
Am 02.11.22 um 18:20 schrieb Mikael Morin:
Unfortunately no, the coarray case works, but the other problem remains.
The type problem is not visible in the definition of S, it is in the
declaration of S's prototype in P.
S is defined as:
void s (character(kind=1)[1:_c] & restrict c, integer(kind=4) o,
logical(kind=1) _o, integer(kind=8) _c)
{
...
}
but P has:
void p ()
{
static void s (character(kind=1)[1:] & restrict, integer(kind=4),
integer(kind=8), logical(kind=1));
void (*<T63a>) (character(kind=1)[1:] & restrict, integer(kind=4),
integer(kind=8), logical(kind=1)) pp;
pp = s;
...
}
Right, now I see it too. Simplified case:
program p
call s ("abcd")
contains
subroutine s(c, o)
character(*) :: c
integer, optional, value :: o
end subroutine s
end
I do see what needs to be done in gfc_get_function_type, which seems
in fact very simple. But I get really lost in create_function_arglist
when trying to get the typelist right.
One thing is I really don't understand how the (hidden_)typelist is
managed here. How does that macro TREE_CHAIN work? Can we somehow
chain two typelists the same way we chain arguments?
TREE_CHAIN is just a linked list "next" pointer like there is in the
fortran frontend a "next" pointer in gfc_ref or gfc_actual_arglist
structures.
Yes, we can chain typelists; the implementation of chainon in tree.cc is
just TREE_CHAIN appending under the hood.
(Failing that, I tried to split the loop over the dummy arguments in
create_function_arglist into two passes, one for the optional+value
variant, and one for the rest. It turned out to be a bad idea...)
Not necessarily a bad idea, but one has to be careful to keep linked
lists synchronized with argument walking.
The most simple, I think, is to move the hidden_typelist advancement for
optional, value presence arguments from the main loop to a preliminary loop.
I hope it helps.
