https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109948
Mikael Morin <mikael at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mikael at gcc dot gnu.org
--- Comment #10 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to Paul Thomas from comment #8)
> I have flagged that this PR blocks PR87477.
>
> Guarding ref->u.ar.as is good practice. However, it turns out that the
> associate name symbol has a perfectly good array_spec. This version "double
> fixes" the PR and is somewhat more satisfactory.
>
> diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
> index 83e45f1b693..9863cdc1583 100644
> --- a/gcc/fortran/resolve.cc
> +++ b/gcc/fortran/resolve.cc
> @@ -5640,7 +5640,12 @@ gfc_expression_rank (gfc_expr *e)
> if (ref->type != REF_ARRAY)
> continue;
>
> - if (ref->u.ar.type == AR_FULL)
> + if (ref->u.ar.as == NULL
> + && e->expr_type == EXPR_VARIABLE
> + && e->symtree->n.sym->as)
> + ref->u.ar.as = e->symtree->n.sym->as;
> +
> + if (ref->u.ar.type == AR_FULL && ref->u.ar.as)
> {
> rank = ref->u.ar.as->rank;
> break;
>
Mmh, in a sense it also "double breaks" it. For example, with
associate(z=>array(1)%ar(2,3)%array(:,:,:)), I expect to get the wrong as in
ref->u.ar.as for the last two array references.
You probably want to copy what's done in find_array_spec or directly call it?
My opinion remains that calling eval_intrinsic at parsing time (as it appears
we do from the stack trace) is fundamentally too early. It doesn't make sure
that everything is properly set up, and that all the rules of the standard are
respected. We wouldn't have this problem if the call to eval_intrinsic was
deferred to the resolution time.
