Re: Ada and TBAA and arrays vs. VIEW_CONVERT_EXPRs

[Richard Guenther <rguenther at suse dot de>]

On Sun, 8 Feb 2009, Richard Guenther wrote:

> On Sun, 8 Feb 2009, Richard Guenther wrote:
> 
> > On Sun, 8 Feb 2009, Eric Botcazou wrote:
> > 
> > > > Yes, A[i] and A are not disambiguated without TBAA unless the frontend
> > > > explicitly allows this.  Citing from get_alias_set:
> > > >
> > > >   /* Unless the language specifies otherwise, treat array types the
> > > >      same as their components.  This avoids the asymmetry we get
> > > >      through recording the components.  Consider accessing a
> > > >      character(kind=1) through a reference to a character(kind=1)[1:1].
> > > >      Or consider if we want to assign integer(kind=4)[0:D.1387] and
> > > >      integer(kind=4)[4] the same alias set or not.
> > > >      Just be pragmatic here and make sure the array and its element
> > > >      type get the same alias set assigned.  */
> > > >   else if (TREE_CODE (t) == ARRAY_TYPE
> > > >            && !TYPE_NONALIASED_COMPONENT (t))
> > > >     set = get_alias_set (TREE_TYPE (t));
> > > >
> > > > the problems with other languages were simply too big.  The gimplifier
> > > > problem hints into the same direction here.  Thus, the above means
> > > > that if it is legal to take the address of an element both the
> > > > array and the element will share their alias sets (which is always
> > > > for any language but Ada and Java).
> > > 
> > > OK but there are no addresses in the example, just direct accesses A[i] and A.
> > > They are memory references with the same base DECL so they should conflict, 
> > > otherwise TYPE_NONALIASED_COMPONENT cannot possibly work.
> > 
> > Right, A[i] and A are direct accesses and TREE_ADDRESSABLE is not set.
> > But their alias sets do _not_ conflict.  For whatever reason.
> 
> Probably because of
> 
>         (record_component_aliases): For arrays and vectors do nothing.
> 
> doh.  It did
> 
>  34078     kenner     case ARRAY_TYPE:
> 134868  ebotcazou       if (!TYPE_NONALIASED_COMPONENT (type))
>  34373     kenner       record_alias_subset (superset, get_alias_set 
> (TREE_TYPE 
> (type)));
>  34078     kenner       break;
> 
> before.  I'll see if re-instantiating this fixed the problem as well.

Sorry for following up again ... it does fix it, but I do not see how.
For !TYPE_NONALIASED_COMPONENT arrays get_alias_set always returns the
alias set of the element type.  But somehow this didn't get done but
instead the array got a new alias set.  I see that Ada 
decl.c:copy_alias_set copies stuff around, but as it uses get_alias_set
it should work as well.  So, I'm confused and still believe removing
the hunk above was ok.

Ah, it looks like

  TYPE_ALIAS_SET (gnu_new_type) = get_alias_set (gnu_old_type);
  record_component_aliases (gnu_new_type);

breaks if gnu_old_type uses TYPE_NONALIASED_COMPONENT but gnu_new_type
does not.  Is this a valid scenario or shouldn't this happen?  I see
this comes from exactly where your initial fix fixed things up.

Richard.