Le 04/02/2013 09:37, Janus Weil a écrit :
>> - In PR54107(comment 26), the procedure result is a procedure pointer
>> whose interface is the procedure itself, which leads to an infinite
>> recursion during resolution.
>> - In PR54195, a type's type bound procedures are resolved twice, leading
>> to a symbol being added twice in an interface and rejected.
>
> What about PR 54107 comment 4?
Ah, yes, this patch fixes comment26 only.
> This also still fails, right? You had
> already posted a patch for this in this PR, which however was quite
> different from the one you propose here. (I was assuming that the
> problems of comment 4 and comment 26 were quite similar.)
Well, that's what I thought and I even developed a patch limited to
trans-types.c and supposed to fix both. But it turned out that it
didn't, as comment26 is a recursion during resolution while comment4 is
a recursion during translation. I didn't investigate the reasons why
comment26 doesn't recurse during translation; I suppose it's caused by
code like this (several instances):
if (sym->attr.proc_pointer && /* whatever */)
{
sym->attr.proc_pointer = 0;
type = build_pointer_type (gfc_get_function_type (sym));
sym->attr.proc_pointer = 1;
}
>
> Can your 'resolved' attribute also help to fix comment 4, or are you
> going to post the other patch later?
It can't really help for the reasons above; at the time we start
translation, all the symbols are resolved, so if we reuse that flag, we
have to clear it somewhere, so that it doesn't really mean 'resolved'
any more. I'll post the other patch later.
>
>
>> The fix, as discussed in PR54195, adds a flag to mark a symbol as
>> resolved.
>
> Why not add this flag directly to gfc_symbol instead of
> symbol_attribute? It seems we do not need the attribute for components
> (or do we?).
Hum, indeed. symbol_attribute, despite its name, also applies to
components :-/.
OK, I'll move the flag to gfc_symbol.
Thanks for the review.
Mikael
