From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 69414 invoked by alias); 6 Apr 2017 05:40:40 -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 69284 invoked by uid 89); 6 Apr 2017 05:40:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-16.9 required=5.0 tests=BAYES_00,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 06 Apr 2017 05:40:32 +0000 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8F5D18046D; Thu, 6 Apr 2017 05:40:32 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 8F5D18046D Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=jakub@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 8F5D18046D Received: from tucnak.zalov.cz (ovpn-116-72.ams2.redhat.com [10.36.116.72]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 16A5E8804D; Thu, 6 Apr 2017 05:40:31 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id v365eSSM015678; Thu, 6 Apr 2017 07:40:28 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id v365eOZT015676; Thu, 6 Apr 2017 07:40:24 +0200 Date: Thu, 06 Apr 2017 05:40:00 -0000 From: Jakub Jelinek To: Sandra Loosemore Cc: Bernd Edlinger , Jonathan Wakely , Richard Biener , Florian Weimer , GCC Patches , Jason Merrill , Jeff Law Subject: Re: [PATCH] Add a new type attribute always_alias (PR79671) Message-ID: <20170406054024.GY17461@tucnak> Reply-To: Jakub Jelinek References: <6a5109d6-81fb-c36c-e525-b2ed984760dc@redhat.com> <21E940B5-C8C4-4A86-8C15-49A86547DD87@suse.de> <20170405160333.GR4425@redhat.com> <20170405160849.GV17461@tucnak> <58E57B04.70907@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <58E57B04.70907@codesourcery.com> User-Agent: Mutt/1.7.1 (2016-10-04) X-IsSubscribed: yes X-SW-Source: 2017-04/txt/msg00261.txt.bz2 On Wed, Apr 05, 2017 at 05:17:24PM -0600, Sandra Loosemore wrote: > > > Yes, exactly. I really want to reach the deadline for gcc-7. > > > Fixing the name is certainly the most important first step, > > > and if everybody agrees on "typeless_storage", for the name > > > I can start with adjusting the name, and look into how > > > to use a spare type-flag that should be a mechanical change. > > > > > > > Jakub, I just renamed the attribute and reworked the patch > > as you suggested, reg-testing is not yet completed, but > > it looks good so far. I also added a few more tests. > > > > I have changed the documentation as Richi suggested, but > > I am not too sure what to say here. > > > > > Index: gcc/doc/extend.texi > > =================================================================== > > --- gcc/doc/extend.texi (revision 246678) > > +++ gcc/doc/extend.texi (working copy) > > @@ -6656,6 +6656,11 @@ declaration, the above program would abort when co > > @option{-fstrict-aliasing}, which is on by default at @option{-O2} or > > above. > > > > +@item typeless_storage > > +@cindex @code{typeless_storage} type attribute > > +An object declared with a type with this attribute behaves like a > > +character type with respect to aliasing semantics. > > + > > @item packed > > @cindex @code{packed} type attribute > > This attribute, attached to @code{struct} or @code{union} type > > > "An object .... behaves like a character type"? I think you mean "as if it > had character type". Or maybe something simpler like "A type declared with > this attribute has the same aliasing semantics as @code{char} type." Well, that wording doesn't make much sense, because the problem is exactly that alias semantics of the char type does not do what C++ needs from unsigned char [N] or std::byte [N] arrays. char type inside of a structure no longer means you can put anything in there. If you have effective type of char and access it through lvalue of some type incompatible with it (see the C99 6.5/7 rules), then it is still invalid, only if you access object of any effective type through lvalue of char type, then it is valid. Now, for objects with type with typeless_storage or for C++ unsigned char or std::byte arrays, we basically want to say that accessing them through lvalue of any type is well defined. I'd probably document it just for typeless_storage attribute, because for the unsigned char and std::byte arrays it is C++17 that defines the exact rules and they are probably less strict than that, so it would be good if we leave it open to refine the unsigned char/std::byte array behavior later on to better match what C++ requires. Not sure if we want to document anything about accesses through lvalue of type with typeless_storage attribute, whether that also implies it is like accesses through lvalue of type char. If yes, that would be may_alias attribute behavior extended, so that it is not just accesses through pointers/references to type with may_alias attribute that are treated that way, but any accesses through lvalue with type with typeless_storage attribute. Jakub