https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109948
--- Comment #14 from Paul Thomas <pault at gcc dot gnu.org> ---
Hi Mikael,
> 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?
Agreed - working both on parse_associate and gfc_expression_rank provides most
of the required repairs. However, the target expression is so incomplete during
parsing that this fails as before:
>
> 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.
subroutine comment10
implicit none
type(ulap) :: z(2)
integer :: i
real :: r(1,1) = 3.0
z(1)%u = [tlap([1,2,3]),tlap([4,5,6])]
z(2)%u = [tlap([7,8,9]),tlap([10,11,12])]
associate (k=>z(2)%u(1)%z)
i = k(1)
if (any(k==8)) i = 1 ! This is OK
end associate
if (i .ne. 1) stop 8
associate (k=>z(1)%u(2)%z)
print *, k
if ((k == r) .neqv. .true.) stop 9 ! Still broken
end associate
end subroutine comment10
Unfortunately, resolving the target expression in parse_associate causes a
large number of regressions (I stopped the regression test after the 'a's). So,
yes, you are quite right about the timing, especially in regard of operator
interfaces.
Andy Vaught's obsession with single pass parsing is biting us in the posterior.
I'll report back later on where I have got to with this PR.
Cheers
Paul
