Re: [Fortran] Improved dependency analysis of pointer variables

[Roger Sayle <roger at eyesopen dot com>]

On Thu, 16 Mar 2006, Paul Brook wrote:
> > Consider instead this slightly modified version:
> >
> > ! { dg-do compile }
> > ! { dg-options "-O2 -fdump-tree-original" }
> >    integer :: i(5)
> >    real(4) :: x(5)
> >    equivalence(x,i)
> >
> >    i = (/ 1, 0, 3, 5, 0 /)
> >    where (i(1:4) .ne. 0)
> >      x(2:5) = -42.
> >    end where
> >    end
> > ! { dg-final { scan-tree-dump-times "malloc" 1 "original" } }
> > ! { dg-final { cleanup-tree-dump "original" } }
> >
> > which is miscompiled both on mainline and with my patch.  It appears
> > that the gfc_are_equivalenced_arrays test isn't doing its job in this
> > case?  Perhaps gfc_are_equivalenced_arrays *is* doing its job and my
> > modified example is considered invalid Fortran.
>
> Technically it's illegal code, but we want to support it for the same
> reason we support aliasing in C unions.


Ok, I've found the bug in gfc_are_equivalenced_arrays.  Its on line
450 of dependency.c in the following test:

          if (fl1 && fl2 && (fl1->offset > fl2->offset))
            return 1;

For the test cases above, the offset of both "x" and "i" are zero,
as they are the first items in their equivalence lists.  However,
I'm unsure how best to fix this.  My first thought was that this
test needs to be changed to (fl1->offset >= fl2->offset) but then
I realized that this introduces/preserves a curious assymmetry.
If "x" and "i" are equivalenced arrays, then "i" and "x" should
also be equivalenced.

If not precisely sure what "offset" is supposed to represent, but
it if is a "byte" offset, i.e. a location in a COMMON block, then
we'd also need a length field in gfc_equiv_info to detect/confirm
an overlap.


Can anyone suggest the appropriate way to fix this?

Roger
--