From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 103746 invoked by alias); 6 Apr 2017 14:22:56 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 102228 invoked by uid 89); 6 Apr 2017 14:22:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-6.9 required=5.0 tests=BAYES_00,GIT_PATCH_1,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=invent, invites 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 14:22:53 +0000 Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 9DCEAAC21; Thu, 6 Apr 2017 14:22:52 +0000 (UTC) Date: Thu, 06 Apr 2017 14:22:00 -0000 From: Richard Biener To: Bernd Edlinger cc: Jakub Jelinek , Jonathan Wakely , Florian Weimer , GCC Patches , Jason Merrill , Jeff Law Subject: Re: [PATCH] Add a new type attribute always_alias (PR79671) In-Reply-To: Message-ID: References: <6a5109d6-81fb-c36c-e525-b2ed984760dc@redhat.com> <21E940B5-C8C4-4A86-8C15-49A86547DD87@suse.de> <20170405160333.GR4425@redhat.com> <20170405160849.GV17461@tucnak> <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/msg00298.txt.bz2 On Thu, 6 Apr 2017, Bernd Edlinger wrote: > On 04/06/17 09:55, Richard Biener wrote: > > 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). > > > > The typeless_storage does not need to implement all the C++ semantic > by itself. It would be possible, but then it is not as generic as > it could be. What I'd really like to have is make an arbitrary > type behave as if it were a char with respect to aliasing. > > In my mind, the typeless_storage attribute has a value of its own, > but it can be used to implement the C++17 semantic of std::byte [N]. > > So I would not want to completely change the way TBAA is working > today. I believe it is doing a fairly good job. > > The TBAA machinery, does for instance not need to propagate this > attribute from the member to the enclosing struct that is > also not done for a struct that contains a char. > > I think it is not too complicated to done in the C++ FE. > The FE looks for array of std::byte and unsigned char, > and sets the attribute when the final type is constructed. > > What I am trying to do is just extend the semantic of may_alias > a bit, and then have the C++ FE use it in the way it has to. > > Here is what I want to write in the doc: > > @item typeless_storage > @cindex @code{typeless_storage} type attribute > A type declared with this attribute behaves like a character type > with respect to aliasing semantics. > This is attribute is similar to the @code{may_alias} attribute, > except that it is not restricted to pointers. > > Example of use: > > @smallexample > typedef int __attribute__((__typeless_storage__)) int_a; > > int > main (void) > @{ > int_a a = 0x12345678; > short *b = (short *) &a; > > b[1] = 0; > > if (a == 0x12345678) > abort(); > > exit(0); > @} > @end smallexample > > > we should first agree on that. I don't see anyone needing the above example, it's not going to be portable in any way. Please don't invent sth that invites users to write bad code. I'd even restrict it to work on arrays of chars only! (arrays of byte-size integer types) Richard.