https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104573
--- Comment #3 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Wed, Feb 16, 2022 at 08:10:34PM +0000, anlauf at gcc dot gnu.org wrote:
>
> I was wondering if we also need to allow BT_CLASS.
I'm not sure. I don't use CLASSes, so only know a bit
about them. If I check F18:7.5.6, I find
C786 (R753) A final-subroutine-name shall be the name of a moduler
procedure with exactly one dummy argument. That argument shall
be nonoptional and shall be a noncoarray, nonpointer, nonallocatable,
*** nonpolymorphic ***
variable of the derived type being defined. All length type
parameters of the dummy argument shall be assumed. The dummy
argument shall not have the INTENT (OUT) or VALUE attribute.
Does the highlighted "*** nonpolymorphic ***" eliminate
CLASS?
> So something like the following might also work:
>
> diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
> index 266e41e25b1..2fa1acdbd6d 100644
> --- a/gcc/fortran/resolve.cc
> +++ b/gcc/fortran/resolve.cc
> @@ -1288,15 +1288,17 @@ resolve_structure_cons (gfc_expr *expr, int init)
> }
> }
>
> - cons = gfc_constructor_first (expr->value.constructor);
> -
> /* A constructor may have references if it is the result of substituting a
> parameter variable. In this case we just pull out the component we
> want. */
> if (expr->ref)
> comp = expr->ref->u.c.sym->components;
> - else
> + else if (expr->ts.u.derived)
> comp = expr->ts.u.derived->components;
> + else
> + return false;
> +
> + cons = gfc_constructor_first (expr->value.constructor);
>
> for (; comp && cons; comp = comp->next, cons = gfc_constructor_next (cons))
> {
Your patch looks cleaner than mine. Once we decide on whether
CLASS can occur and if yours regression tests okay, then I
think you can commit. It's fairly obvious patch.
