From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 62446 invoked by alias); 6 Apr 2017 14:11:38 -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 61019 invoked by uid 89); 6 Apr 2017 14:11:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-7.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GIT_PATCH_1,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:2891 X-HELO: EUR02-VE1-obe.outbound.protection.outlook.com Received: from mail-oln040092069042.outbound.protection.outlook.com (HELO EUR02-VE1-obe.outbound.protection.outlook.com) (40.92.69.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 06 Apr 2017 14:11:35 +0000 Received: from AM5EUR02FT008.eop-EUR02.prod.protection.outlook.com (10.152.8.52) by AM5EUR02HT241.eop-EUR02.prod.protection.outlook.com (10.152.9.67) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1005.5; Thu, 6 Apr 2017 14:11:34 +0000 Received: from AM4PR0701MB2162.eurprd07.prod.outlook.com (10.152.8.52) by AM5EUR02FT008.mail.protection.outlook.com (10.152.8.69) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.5 via Frontend Transport; Thu, 6 Apr 2017 14:11:34 +0000 Received: from AM4PR0701MB2162.eurprd07.prod.outlook.com ([fe80::a806:64f0:6377:f3ea]) by AM4PR0701MB2162.eurprd07.prod.outlook.com ([fe80::a806:64f0:6377:f3ea%19]) with mapi id 15.01.1019.015; Thu, 6 Apr 2017 14:11:33 +0000 From: Bernd Edlinger To: Richard Biener , Jakub Jelinek CC: Jonathan Wakely , Florian Weimer , GCC Patches , Jason Merrill , "Jeff Law" Subject: Re: [PATCH] Add a new type attribute always_alias (PR79671) Date: Thu, 06 Apr 2017 14:11:00 -0000 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> In-Reply-To: authentication-results: suse.de; dkim=none (message not signed) header.d=none;suse.de; dmarc=none action=none header.from=hotmail.de; x-incomingtopheadermarker: OriginalChecksum:AD359AF40FBA6D2C3AE7FD0436AB05F0D57DEE47925DBB226E0393D5A0B0B4C5;UpperCasedChecksum:6A8559CAF043B19DB347C66171D585D9F400EE746E5F23BDAF67947744E63263;SizeAsReceived:8806;Count:40 x-ms-exchange-messagesentrepresentingtype: 1 x-microsoft-exchange-diagnostics: 1;AM5EUR02HT241;5:cifu7Ccxhru/JsLErU9WkMVZObgfn+O5Jv9OxjECKLXbkPFgMXGYuHTIAUDurp4GeNfa8E44xk1JFdITxDFipZKKrr0pazediPgKAiRObPP6wPtVWuCnaCVPCkMu8RYeUK5wYZdpFTmFOpF2hzra0Q==;24:pxgUGas84cq7CeI7RAiOXb6M3kPLDKvAMZzOHmEBnfnvCBs6oN8DaQ/uOuhH3A/qXAjcGyXRNgFBDCIFdXvKra1GjfKaMe1vdOLgroYOj9A=;7:41/U7kHE+LN2gJBALtqvlaDMzus6+liLI97BDfV7lW4K8BQ7g/XxYlPYJlz2Gm9SfLBr/J/rkm2Yt/VklPrUServ+QF7he6YG+dY3Ee3dninWt2m5lYRN5M+RiMB5baJy5yKwmL+w7QmNRYbCjLJrj14pqET4J1kQMLN5AttNPmh+kxzZhbYbFSZYfHkgxCyqmjUneNdXdJ7I25wpmjlODe81rwaUvh/Oy1yowu0i8skzLWCsOs50qSykhv3aeAlXrB8VgVoRBZeQje0Tqep7sSZ1V9zmdz3+UJMeq/yMGzQSa5NZx1qTNogbvRJhtk9 x-incomingheadercount: 40 x-eopattributedmessage: 0 x-forefront-antispam-report: EFV:NLI;SFV:NSPM;SFS:(7070007)(98901004);DIR:OUT;SFP:1901;SCL:1;SRVR:AM5EUR02HT241;H:AM4PR0701MB2162.eurprd07.prod.outlook.com;FPR:;SPF:None;LANG:en; x-ms-office365-filtering-correlation-id: 6c5f4802-d5f7-473a-bce6-08d47cf6d400 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031322274)(1603101448)(1601125374)(1701031045);SRVR:AM5EUR02HT241; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(444000031);SRVR:AM5EUR02HT241;BCL:0;PCL:0;RULEID:;SRVR:AM5EUR02HT241; x-forefront-prvs: 02698DF457 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-ID: <3408B723DB94404EBF1AD7F527C0745E@eurprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2017 14:11:33.9310 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5EUR02HT241 X-SW-Source: 2017-04/txt/msg00294.txt.bz2 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) =3D=3D ARRAY_TYPE >>> + && ! TYPE_TYPELESS_STORAGE (t) >>> && (!TYPE_NONALIASED_COMPONENT (t) >>> || TYPE_STRUCTURAL_EQUALITY_P (t))) >>> set =3D get_alias_set (TREE_TYPE (t)); >>> @@ -1094,6 +1100,15 @@ get_alias_set (tree t) >>> >>> TYPE_ALIAS_SET (t) =3D set; >>> >>> + if (TREE_CODE (t) =3D=3D 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 complicati= ons >> 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 =3D 0x12345678; short *b =3D (short *) &a; b[1] =3D 0; if (a =3D=3D 0x12345678) abort(); exit(0); @} @end smallexample we should first agree on that. Bernd.