From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-451167-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 96110 invoked by alias); 6 Apr 2017 07:55:31 -0000
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
Received: (qmail 96087 invoked by uid 89); 6 Apr 2017 07:55:31 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=
X-HELO: mx2.suse.de
Received: from mx2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 06 Apr 2017 07:55:30 +0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])	by mx2.suse.de (Postfix) with ESMTP id 7E4C4AC4A;	Thu,  6 Apr 2017 07:55:29 +0000 (UTC)
Date: Thu, 06 Apr 2017 07:55:00 -0000
From: Richard Biener <rguenther@suse.de>
To: Jakub Jelinek <jakub@redhat.com>
cc: Bernd Edlinger <bernd.edlinger@hotmail.de>,     Jonathan Wakely <jwakely@redhat.com>, Florian Weimer <fweimer@redhat.com>,     GCC Patches <gcc-patches@gcc.gnu.org>, Jason Merrill <jason@redhat.com>,     Jeff Law <law@redhat.com>
Subject: Re: [PATCH] Add a new type attribute always_alias (PR79671)
In-Reply-To: <20170406075104.GA17461@tucnak>
Message-ID: <alpine.LSU.2.20.1704060952480.30715@zhemvz.fhfr.qr>
References: <AM4PR0701MB216292327A207737064C3CA3E40A0@AM4PR0701MB2162.eurprd07.prod.outlook.com> <6a5109d6-81fb-c36c-e525-b2ed984760dc@redhat.com> <21E940B5-C8C4-4A86-8C15-49A86547DD87@suse.de> <AM4PR0701MB2162D4E4FBF1612E05C35A0EE40A0@AM4PR0701MB2162.eurprd07.prod.outlook.com> <20170405160333.GR4425@redhat.com> <20170405160849.GV17461@tucnak> <AM4PR0701MB2162884DCF4538DC0FF5C2F1E40A0@AM4PR0701MB2162.eurprd07.prod.outlook.com> <AM4PR0701MB21623337A5C0C1850D3DF4C7E40A0@AM4PR0701MB2162.eurprd07.prod.outlook.com> <alpine.LSU.2.20.1704060925130.30715@zhemvz.fhfr.qr> <20170406075104.GA17461@tucnak>
User-Agent: Alpine 2.20 (LSU 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-SW-Source: 2017-04/txt/msg00266.txt.bz2

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.