From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 54333 invoked by alias); 5 Apr 2017 17:23:04 -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 53737 invoked by uid 89); 5 Apr 2017 17:23:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: EUR03-AM5-obe.outbound.protection.outlook.com Received: from mail-oln040092070091.outbound.protection.outlook.com (HELO EUR03-AM5-obe.outbound.protection.outlook.com) (40.92.70.91) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 05 Apr 2017 17:23:01 +0000 Received: from VE1EUR03FT013.eop-EUR03.prod.protection.outlook.com (10.152.18.56) by VE1EUR03HT060.eop-EUR03.prod.protection.outlook.com (10.152.19.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1005.5; Wed, 5 Apr 2017 17:22:48 +0000 Received: from AM4PR0701MB2162.eurprd07.prod.outlook.com (10.152.18.56) by VE1EUR03FT013.mail.protection.outlook.com (10.152.19.37) 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; Wed, 5 Apr 2017 17:22:49 +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; Wed, 5 Apr 2017 17:22:49 +0000 From: Bernd Edlinger To: Jakub Jelinek , Jonathan Wakely CC: Richard Biener , Florian Weimer , GCC Patches , Jason Merrill , "Jeff Law" Subject: Re: [PATCH] Add a new type attribute always_alias (PR79671) Date: Wed, 05 Apr 2017 17:23: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> In-Reply-To: <20170405160849.GV17461@tucnak> authentication-results: redhat.com; dkim=none (message not signed) header.d=none;redhat.com; dmarc=none action=none header.from=hotmail.de; x-incomingtopheadermarker: OriginalChecksum:7F496550C0A6D90BA15976D83B118411ECE23F7E766F4BE59BDBE02BB95FBDD3;UpperCasedChecksum:B9E68EBB4971891AF3112C645FA152A7C471FE21B28A20F8C0E34273EAC5ACAA;SizeAsReceived:8443;Count:40 x-ms-exchange-messagesentrepresentingtype: 1 x-microsoft-exchange-diagnostics: 1;VE1EUR03HT060;5:I5Qg8VS2D/IlXUxdLPdmTg9iMIf3w1dnf+11QTJjvG/oik44Einbyg1c+LVULWJvfKm7Tqdu5nRPDZ/w6FzVDScMcZnG0cOsM5JX7yX0N0PgDYj8KMdfukiPHZRaKWNjG41em+9Wkz8Eb7+HKhH+Ug==;24:1Op3xaFMbyKjxurOoQPThMLL46BtuG632DNugZE49DC1dN3rJUKD26Ak4h54aJEfigtMlp9ffZdhVfMGKs+6j8diGUkYjVgVuYrl1wn0FZk=;7:wiNh4rcKFc6RtPsFN+afO/lgSuKhAK689YIY4cJQYKIG50q3E5N9+Il2CS5JiBI/GVMK7Ck/THt9ituxKn/Udycc1U96+1Y8zg/jHrcBRamLctYWLoAY9Yc7zkafGICiPUZkhnNGeBsvNcdN4/OMSbOvmzXlnnOHe7MJeO17i7SPvav12traca+xHtNDofpxu/EJljzShHthre+cExdBrrh4y1cT15Pna+TwRyUX/NA4guwjf+fgk+jIA+gTK23WqN1zC2uWc0OfZk+jgluhT9S1F+YrVoQ7Fd0Hi+IzwTWczkg5se5A2hFpzKUdk3Ce x-incomingheadercount: 40 x-eopattributedmessage: 0 x-forefront-antispam-report: EFV:NLI;SFV:NSPM;SFS:(7070007)(98901004);DIR:OUT;SFP:1901;SCL:1;SRVR:VE1EUR03HT060;H:AM4PR0701MB2162.eurprd07.prod.outlook.com;FPR:;SPF:None;LANG:en; x-ms-office365-filtering-correlation-id: 5631dab3-54d2-44d3-d31f-08d47c486149 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031322274)(1603101448)(1601125374)(1701031045);SRVR:VE1EUR03HT060; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(444000031);SRVR:VE1EUR03HT060;BCL:0;PCL:0;RULEID:;SRVR:VE1EUR03HT060; x-forefront-prvs: 0268246AE7 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-ID: <46BB3FB98DA117428D8368B0DF5CD594@eurprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Apr 2017 17:22:48.8359 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1EUR03HT060 X-SW-Source: 2017-04/txt/msg00241.txt.bz2 On 04/05/17 18:08, Jakub Jelinek wrote: > On Wed, Apr 05, 2017 at 05:03:33PM +0100, Jonathan Wakely wrote: >>> I wanted to say it behaves mostly like __attribute__((may_alias)) >>> except that may_alias only has an effect on pointers and references >>> but not when accessing an object directly, (I hope you know what >>> I mean). >> >> And may_alias is not a very helpful name either. >> >> I much prefer Richi's suggestion of typeless_storage. >> >> But I'm not convinced we need the attribute at all. If a struct >> containing an array of std::byte or unsigned char has the property >> already then that's good. I don't think we need a non-portable way to >> make other types behave the same. If you can change the code to use a >> new GCC attribute then you can change the code to use an array of >> unsigned char, and be portable. > > It will only work that way in C++ though, so if you want to achieve > the same in C, which doesn't have any special case for unsigned char > arrays nor std::byte, you need an attribute. > 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. Bernd.