This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Ada and TBAA and arrays vs. VIEW_CONVERT_EXPRs
On Sun, 8 Feb 2009, Eric Botcazou wrote:
> > The problem is that the gimplifier through gimplify_init_constructor
> > happily generates "aliases" for { 32, 50, 53, 53 } to produce a
> > temporary, but at the same time accesses the result in whole. Which
> > of course won't work if the element and the array object have
> > non-conflicting alias sets. Huh. No idea how to fix that.
>
> Do you mean that A[i] and A cannot be disambiguated without TBAA anymore? Or
> does the problem pertain only to the VIEW_CONVERT_EXPR around A?
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).
Richard.