Hi Andre,
Do not worry about the change team construct. Getting out my notes and
restarting is likely to take a few months yet. Besides which, the PDT fixes
have to come first.
Cheers
Paul
On Wed, 19 Mar 2025 at 13:59, Andre Vehreschild wrote:
> Hi Harald and Paul,
>
> thanks for the reviews
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 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 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
