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 producing to
many merge conflicts.
Thanks again and regards,
Andre
On Wed, 19 Mar 2025 10:51:49 +0000
Paul Richard Thomas <paul.richard.tho...@gmail.com> wrote:
> 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 had been parsed and resolved. It nearly worked
> and I think that I should get out my notes and restart :-)
>
> In the meantime, this is more than band-aid, it is a necessary correction,
> given the way associate is parsed.
>
> Regards and thanks for the patch
>
> Paul
>
>
> On Tue, 18 Mar 2025 at 22:08, Harald Anlauf <anl...@gmx.de> wrote:
>
> > 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 a compcall, the resolve branches into the incorrect case and
> > emits the
> > > error. My current fix is to wait with generating the error message until
> > the
> > > type has been resolved completely (aka. symbol's resolve_symbol_called
> > is set).
> > > I am not sure, if this is correct, therefore CC'ing Paul, who, to my
> > > knowledge, has more experience in the associate area. But everyone
> > please feel
> > > free to step in!
> >
> > 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 really a FUNCTION. */
> > - if (!e->value.compcall.tbp->function)
> > + if (!e->value.compcall.tbp->function
> > + && e->symtree && e->symtree->n.sym->resolve_symbol_called)
> > {
> > gfc_error ("%qs at %L should be a FUNCTION",
> > e->value.compcall.name, &e->where);
> >
> > Sorry if this is a stupid question. And not regtested, although
> > it also fixes the original report.
> >
> > > Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline?
> >
> > If neither Paul steps in nor anybody else, go ahead and commit.
> > Even if your patch were a band-aid, it does not look wrong, and
> > if it is later found to be it can be improved...
> >
> > Thanks,
> > Harald
> >
> > > Regards,
> > > Andre
> > > --
> > > Andre Vehreschild * Email: vehre ad gmx dot de
> >
> >
--
Andre Vehreschild * Email: vehre ad gmx dot de
