From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15995 invoked by alias); 6 Apr 2017 18:12:37 -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 13991 invoked by uid 89); 6 Apr 2017 18:12:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-6.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= X-HELO: EUR03-DB5-obe.outbound.protection.outlook.com Received: from mail-oln040092071017.outbound.protection.outlook.com (HELO EUR03-DB5-obe.outbound.protection.outlook.com) (40.92.71.17) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 06 Apr 2017 18:12:31 +0000 Received: from VE1EUR03FT055.eop-EUR03.prod.protection.outlook.com (10.152.18.55) by VE1EUR03HT102.eop-EUR03.prod.protection.outlook.com (10.152.19.74) 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 18:12:30 +0000 Received: from AM4PR0701MB2162.eurprd07.prod.outlook.com (10.152.18.51) by VE1EUR03FT055.mail.protection.outlook.com (10.152.19.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1019.14 via Frontend Transport; Thu, 6 Apr 2017 18:12:29 +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 18:12:29 +0000 From: Bernd Edlinger To: Florian Weimer , Richard Biener , Jakub Jelinek CC: Jonathan Wakely , GCC Patches , Jason Merrill , Jeff Law Subject: Re: [PATCH] Add a new type attribute always_alias (PR79671) Date: Thu, 06 Apr 2017 18:12: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> <7d17b3b7-2d38-6184-8bd6-eb9f96f87912@redhat.com> <50936a77-870a-5156-1f5e-b1e0327498b6@redhat.com> In-Reply-To: <50936a77-870a-5156-1f5e-b1e0327498b6@redhat.com> 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:82E13432BD06E81F5F132F3BC0900A42604765BAB16CA3810AF6544EBA9DA864;UpperCasedChecksum:F2BDEA10AAA427E35220A39AD1B29FBD7451FC21D2A8BA96FDC6E651723A193C;SizeAsReceived:9118;Count:40 x-ms-exchange-messagesentrepresentingtype: 1 x-microsoft-exchange-diagnostics: 1;VE1EUR03HT102;5:hr/wMaZNTob4r49DNrc4O33172jc24L7pYR+jayXr8d19uQPK4t0hHWvIay05UYIOZmdbVzRlvRkZMEU8JhIaqlTYHysTWhVDHrQlxriu+kn23FjW+dAyt4TBxFFKmxbyj9tdTcpJD+5xR9SZn8BGg==;24:+YOj7NfKrYrtyGLFDkjWo/wqmg0pMPw+uy/U7JwYAYn2FAIy7iawowjK6y/feV2jcatmkbCc4XSsZiMBOhofvDs9vqxKsgw885zHBm8C8Ls=;7:YY9od5HsZF9Y+x44qsuNNA9gTTKMNy0kvgs2gZUeNlC0eXkG12t+COmeG7l9n5L9/mk1mMqFvNzEnSv3FrZouR8hY6y58EaacMGVxixVcnmPdPYeoW7mRtoRyphctsZOvYrp/SXA92ZlQtQHmdre19i4e57pEhzwV399nREJhOGot3A7HHA+4LHdfFYxC5ixEaTj2drui+oaqgzSGyh2GUtPzS6F3ODL1hw4VXTsHaVa1RQKPagBTar8iDWa49xsbFyoVVGuH5IUZVdfKYkutrRn1dIS8u/4GPEhzBQwIu8T6HDrAM0kKnTGbPzHry1Z x-incomingheadercount: 40 x-eopattributedmessage: 0 x-forefront-antispam-report: EFV:NLI;SFV:NSPM;SFS:(7070007)(98901004);DIR:OUT;SFP:1901;SCL:1;SRVR:VE1EUR03HT102;H:AM4PR0701MB2162.eurprd07.prod.outlook.com;FPR:;SPF:None;LANG:en; x-ms-office365-filtering-correlation-id: 1cfd9b61-d2a0-404d-5e0c-08d47d187c69 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031322274)(1603101448)(1601125374)(1701031045);SRVR:VE1EUR03HT102; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(444000031);SRVR:VE1EUR03HT102;BCL:0;PCL:0;RULEID:;SRVR:VE1EUR03HT102; x-forefront-prvs: 02698DF457 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-ID: <02995FAEEFB2BF49BD449624F286043D@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 18:12:29.6368 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1EUR03HT102 X-SW-Source: 2017-04/txt/msg00319.txt.bz2 On 04/06/17 19:47, Florian Weimer wrote: > On 04/06/2017 07:39 PM, Bernd Edlinger wrote: >> On 04/06/17 16:17, Florian Weimer wrote: >>>> 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. >>> >>> As Jakub pointed out, this is not what we need here. An object of type >>> char does *not* have untyped storage. Accessing it as a different type >>> is still undefined. >>> >> >> but, do you agree that this is valid in C11? >> >> typedef char char_a[4]; >> >> int >> main (void) >> { >> char_a a =3D {1,2,3,4}; >> short *b =3D (short *) &a; >> >> b[1] =3D 0; >> >> if (a[0] =3D=3D 1 && a[1] =3D=3D 2 && a[2] =3D=3D 3 && a[3] =3D=3D 4) >> abort(); >> >> exit(0); >> } >> >> >> all I want to do is replace "char" with a different type. > > Thanks a lot for posting a concrete example. > > The effective type of a[2] and [3] is char. The character type wildcard > in 6.5(7) only applies to the type of the lvalue expression ysed for the > access, not the effective type of the object being accessed. The type > of the LHS of the assignment expression is short. So the access is > undefined. > exactly *that* is what I want to make valid with that attribute, which would be also useful in C and kernel code, IMHO. But isn't the effective type changed by the assignment b[1] =3D 0; as described in 6.5(6): "If a value is stored into an object having no declared type through an lvalue having a type that is not a character type, then the type of the lvalue becomes the effective type of the object for that access and for subsequent accesses that do not modify the stored value." Bernd.