[Fortran] Improved dependency analysis of pointer variables

Roger Sayle roger@eyesopen.com
Sat Mar 25 08:15:00 GMT 2006


Thanks for the review.

On Sat, 25 Mar 2006, Paul Thomas wrote:
> OK, subject to one comment/correction.
>
> >! 	  /* Symbols can only alias if they have the same type.  */
> >! 	  if (ts1->type != BT_UNKNOWN
> >! 	      && ts2->type != BT_UNKNOWN
> >! 	      && ts1->type != BT_DERIVED
> >! 	      && ts2->type != BT_DERIVED)
> >! 	    {
> >! 	      if (ts1->type != ts2->type
> >! 		  || ts1->kind != ts2->kind)
> >! 		return 0;
> >! 	    }
> >
> >
> This is too restrictive of derived types, isn't it? You could use
> interface.c (gfc_compare_derived_types, gfc_compare_derived_types) to
> determine if the types are the same; that way, derived types are
> tested too.

This was mostly paranoia due to my limited understanding (ignorance)
of Fortran's type system.

This hunk could theoretically/possibly be written much shorter/simpler
as something like:

      /* The interesting cases are when the symbols don't match.  */
      if (expr1->symtree->n.sym != expr2->symtree->n.sym)
	{
	  /* Return 1 if expr1 and expr2 are equivalenced arrays.  */
	  if (gfc_are_equivalenced_arrays (expr1, expr2))
  	    return 1;
	  /* Return 1 if expr1 and expr2 could alias each other.  */
	  if (gfc_symbols_could_alias (expr1->symtree->n.sym,
				       expr2->symtree->n.sym)
	    return 1;
	  /* Otherwise distinct symbols have no dependencies.  */
	  return 0;
	}

Unfortunately, I have no idea what a Fortran derived type is or can do,
so I was cautious/uncertain about the call to gfc_compare_derived_types
in gfc_compare_types, called from symbol.c:gfc_symbols_could_alias.
I wasn't sure if the definition of "derived" types included structures
and unions, where referencing a component may cause the types to match?
Can writes to X affect the values of Y%Z when the types of X and Y don't
match, but the types of X and Y%Z do?
Hence I went with the minimal "safe" patch, and kept/reused much of the
existing logic in gfc_check_dependency.  For example, the original
dependency checking always punted on pointers, but gfc_symbols_could_alias
only worries about pointers when the other symbol is a pointer, an
allocatable or a target.

Thanks to the feedback from you and Toon, perhaps the existing
dependency code isn't the best example to follow (or behaviour to
preserve), and gfc_symbols_could_alias is exactly what I need?

One remaining aspect that I don't fully understand is this idiom:

! 	  for (ref = expr2->ref; ref; ref = ref->next)
! 	    if (ref->type == REF_COMPONENT && ref->u.c.component->pointer)
! 	      return 1;

Is this still required from expr1 and expr2?  Does it also need to
check whether the other symbol is a pointer/targetable/allocatable?
Do component references always have the same types as their symbols?


The code in my patch whilst only handling a subset of cases is
(1) a subset that I fully understand and believe to be correct,
(2) probably covers the vast majority of "real world" cases, and
(3) I suspect an improvement on the current gfortran implementation.


Let me know how you'd prefer to proceed.  If you agree that the
current patch is correct but cautious, we could perhaps investigate
generalizing the fortran type matching as a follow-up patch.
I think gfc_symbols_could_alias looks promising, but my f9x-foo
isn't good enough for me to propose it as a solution on my own.
The lack of test coverage for these corner cases makes me nervous.

Roger
--



More information about the Gcc-patches mailing list