https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684
--- Comment #21 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Wed, Aug 09, 2023 at 10:08:45AM +0000, trnka at scm dot com wrote:
>
> --- Comment #17 from Tomáš Trnka <trnka at scm dot com> ---
> (In reply to kargl from comment #10)
> > diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
> > index 3cd470ddcca..b0bb8bc1471 100644
> > --- a/gcc/fortran/resolve.cc
> > +++ b/gcc/fortran/resolve.cc
> > @@ -17966,7 +17966,9 @@ resolve_types (gfc_namespace *ns)
> >
> > for (n = ns->contained; n; n = n->sibling)
> > {
> > - if (gfc_pure (ns->proc_name) && !gfc_pure (n->proc_name))
> > + if (gfc_pure (ns->proc_name)
> > + && !gfc_pure (n->proc_name)
> > + && !n->proc_name->attr.artificial)
> > gfc_error ("Contained procedure %qs at %L of a PURE procedure must "
> > "also be PURE", n->proc_name->name,
> > &n->proc_name->declared_at);
> >
> > pault, dos the above look correct?
>
> On our codebase, this patch behaves just like the patch in comment #5, in that
> it also triggers the issue described in comment #7 (assert in a warning about
> non-recursive procedures getting called recursively).
>
> Does either of you have any idea as to what that issue could be about? Or is
> isolating a testcase our only hope?
I missed your comment #7 as simply grabbed the "slightly
more simplified" attachment and started a bug hunt from there.
Do either of the other testcase attachments exhibit the issue?
The code in class.cc(generate_finalization_wrapper) sets
final->attr.pure = 0;
final->attr.recursive = 1;
final->attr.artificial = 1;
for the artificial __final_* wrapper function. So, the routine
should be recursive.
