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 <ve...@gmx.de> wrote:
> 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
>
