This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Add a new type attribute always_alias (PR79671)


On Thu, 6 Apr 2017, Jakub Jelinek wrote:

> On Thu, Apr 06, 2017 at 09:47:10AM +0200, Richard Biener wrote:
> > @@ -955,6 +960,7 @@ get_alias_set (tree t)
> >       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_TYPELESS_STORAGE (t)
> >  	   && (!TYPE_NONALIASED_COMPONENT (t)
> >  	       || TYPE_STRUCTURAL_EQUALITY_P (t)))
> >      set = get_alias_set (TREE_TYPE (t));
> > @@ -1094,6 +1100,15 @@ get_alias_set (tree t)
> >  
> >    TYPE_ALIAS_SET (t) = set;
> >  
> > +  if (TREE_CODE (t) == ARRAY_TYPE
> > +      && TYPE_TYPELESS_STORAGE (t))
> 
> Shouldn't TYPE_TYPELESS_STORAGE apply even for non-array types?
> If somebody chooses to store anything in long long
> __attribute__((typeless_storage)), so be it.  Or what kind of complications
> do you see for that?

It's a new feature so I don't see why we should allow that.  Given that
people will have to do sth when the compiler doesn't support it the
only "reliable" way of using it is on an array of char anyway.

The complication starts when people use it on a type that currently
uses alias-set zero (because "zero" doesn't get an alias_set_entry).

Richard.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]