Hi Harald,
thanks for the comments.
> your solution looks basically correct to me, but I wonder why to
> return early w/o error. Would the following logic be wrong?
>
> @@ -7349,7 +7357,8 @@ resolve_compcall (gfc_expr* e, const char **name)
> gfc_symtree* target;
>
> /* Check that's real
Hi Harald and Paul,
thanks for the reviews. Committed as gcc-15-8297-g9a13dc48a3a.
Paul, I am working on the change team construct at the moment. It has an
association list embedded. I will finish that work hopefully soon. After that
it will be safe for you to "get out your notes and restart" w/o
Hi Andre and Harald,
It looks good to me too.
Indeed, the associate construct is a strange one since TKR guessing is done
at a very early stage so that the associate block can be parsed. About a
year ago, I started looking at tackling this by delaying parsing the blocks
until the containing block
Hi Andre,
Am 17.03.25 um 09:56 schrieb Andre Vehreschild:
The issue is that the tbp (the typebound proc info structure) is not resolved
completely when the associate tries to do an early resolve to determine the
rank of the associate variable. When the expression to be resolved for that
contains
Hi all,
when Harald attached this PR to the associate meta-bug, I immediately thought:
"Oh, this another one of these missing branches on ts.type == BT_CLASS
thingies". Well, I was wrong.
The issue is that the tbp (the typebound proc info structure) is not resolved
completely when the associate t
