From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25199 invoked by alias); 7 Apr 2017 13:37:35 -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 25130 invoked by uid 89); 7 Apr 2017 13:37:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 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=pee, deciding, taste X-HELO: EUR02-AM5-obe.outbound.protection.outlook.com Received: from mail-oln040092067055.outbound.protection.outlook.com (HELO EUR02-AM5-obe.outbound.protection.outlook.com) (40.92.67.55) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 07 Apr 2017 13:37:32 +0000 Received: from VE1EUR02FT037.eop-EUR02.prod.protection.outlook.com (10.152.12.51) by VE1EUR02HT129.eop-EUR02.prod.protection.outlook.com (10.152.13.128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1005.5; Fri, 7 Apr 2017 13:37:31 +0000 Received: from AM4PR0701MB2162.eurprd07.prod.outlook.com (10.152.12.53) by VE1EUR02FT037.mail.protection.outlook.com (10.152.12.195) 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; Fri, 7 Apr 2017 13:37:31 +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.021; Fri, 7 Apr 2017 13:37:30 +0000 From: Bernd Edlinger To: Richard Biener CC: Jakub Jelinek , Jonathan Wakely , Florian Weimer , GCC Patches , Jason Merrill , Jeff Law Subject: Re: [PATCH] Add a new type attribute always_alias (PR79671) Date: Fri, 07 Apr 2017 13:37: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: 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:2DDA6484D32719B7134D42AF381BA0EBD6EA70808F330F9EF1005B3D03F89A11;UpperCasedChecksum:4672649ABD2303DD97E37E2C64CD06BFBAF6FF878A63A85AAF951CFF723CA3CC;SizeAsReceived:8871;Count:40 x-ms-exchange-messagesentrepresentingtype: 1 x-microsoft-exchange-diagnostics: 1;VE1EUR02HT129;5:sIT2qW4+hT72pHO5OadpOJyG1ZXOEszwCK1SoxoEcnUJlpAx1A6aO13UiT1+D5A2KoQQMhGmm02vGzrUPFL0D3o404u5JQkpHL+pjg/Ioyr5y9n2O4BTTA3xi/9dTfRZWA0yGxUkhNY9bB9Z9BQzQg==;24:HU7JhjAFTZIWW9LwUw15ysWN1GBs68sgCo2+RZuie1DQNLqrKAkHriY034NaDv24F/c/Sjt3EdQ07bvxeVB1l+FrarSAOr8UIWkx/j2gMng=;7:y+ZSOfwpu7Tc6yQAvBz4UkPqKjabAN8caYvsjHH+uf0g7oFUUqxbIVOYH72TIvw4lwDkel9vpw03odtV9pFEsnDjSrkdTwYtWsCOFEaIki/l++abALpBkYXY1fyxuYEFqIbcUFpp7lDcdxDb4sLuWB/tEdn1EEf+pQllJ/0/5qjXobWeXfrWf9/gdYiAxETRn6WRnEn6DtcoGdM4qXX0CPZfLF+4lmpF8gRo8EINADzxoFllGIkKkZwRNOtjALKOgq6F6Sx+IVnIo67ZtvChNU/JUPFiTxmyla6G8qvo/dnl4M7zLTYTvDmi/GVEE0zH x-incomingheadercount: 40 x-eopattributedmessage: 0 x-forefront-antispam-report: EFV:NLI;SFV:NSPM;SFS:(7070007)(98901004);DIR:OUT;SFP:1901;SCL:1;SRVR:VE1EUR02HT129;H:AM4PR0701MB2162.eurprd07.prod.outlook.com;FPR:;SPF:None;LANG:en; x-ms-office365-filtering-correlation-id: 649f2008-90e6-428d-e656-08d47dbb3caf x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031322274)(1603101448)(1601125374)(1701031045);SRVR:VE1EUR02HT129; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(444000031);SRVR:VE1EUR02HT129;BCL:0;PCL:0;RULEID:;SRVR:VE1EUR02HT129; x-forefront-prvs: 0270ED2845 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-ID: <6EC4D9D475430F4AB1AD62B569919963@eurprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Apr 2017 13:37:30.6257 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1EUR02HT129 X-SW-Source: 2017-04/txt/msg00367.txt.bz2 On 04/07/17 08:54, Richard Biener wrote: > On Thu, 6 Apr 2017, Bernd Edlinger wrote: >> I think get_alias_set(t) will return 0 for typeless_storage >> types, and therefore has_zero_child will be set anyway. >> I think both mean the same thing in the end, but it depends on >> what typeless_storage should actually mean, and we have >> not yet the same idea about it. > > But has_zero_child does not do what we like it to because otherwise > in the PR using the char[] array member would have worked! > > has_zero_child doesn't do that on purpose of course, but this means > returing alias-set zero for the typeless storage _member_ doesn't > suffice. > I see you have a certain idea how to solve the C++17 issue. And yes, I apologize, if I tried to pee on your tree :) What you propose is I think the following: The C++ FE sets TYPE_TYPELESS_STORAGE a std::byte and on "unsigned char" if the language dialect is cxx17 and the TBAA makes all the rest. What I propose is as follows: The TYPE_TYPELESS_STORAGE is a generic attribute, it can be set on any type, and in the TBAA the attribute does not squirrel around at all. If it is on a type, then all DECLs with this type get the alias set 0. If it is on a member of a struct that does not mean more than if the struct has a char member this it sets has_zero_child, which I do not want to mean anything else than before. The C++ FE does the business logic here, in deciding where to distribute the TYPE_TYPELESS_STORAGE flags. in this example class A { class B { std::byte x[5]; } b; }; std::byte, class B, and class A would get the TYPE_TYPELESS_STORAGE flag set by the C++FE if the language dialect is cxx17 or above, so that you can place anything into any object of class A and class B, and of type std::byte. but in this example class B { std::byte x; }; only std::byte would get the TYPE_TYPELESS_STORAGE flag, so you can not put anyting into an object of class B, just on an object of std::byte. >> >> I wanted to be able to declare a int __attribute__((typeless_storage)) >> as in the test case, and the sample in the spec. And that >> information is not in the TYPE_MAIN_VARIANT. Therefore I look for >> typeless_storage before "t =3D TYPE_MAIN_VARIANT (t)". > > As I said I believe this is a useless feature. If you want something > typeless then the underlying type doesn't matter so we can as well > force it to be an array of char. Makes our live simpler. And > even makes the code portable to compilers that treat arrays of char > conservatively. > I just learned that the C11 standard does not guarantee that, and also an array of char does not provide the necessary alignment per se, at least without alignment attributes. >> >> See cxx_type_contains_byte_buffer: this function looks recursively into >> structures and unions, and returns the information if the beast >> contains an array of unsigned char or std::byte. > > But with a properly designed middle-end feature that's not needed. > > There's technically no reason to pessimize TBAA for anything but > the typeless storage member of a structure. > Yes, it is just a matter of taste. And if you want the middle end to be flexible here or if everything should work without user intervention. >>> >>> @@ -1491,6 +1491,7 @@ struct GTY(()) tree_type_common { >>> unsigned needs_constructing_flag : 1; >>> unsigned transparent_aggr_flag : 1; >>> unsigned restrict_flag : 1; >>> + unsigned typeless_storage_flag : 1; >>> unsigned contains_placeholder_bits : 2; >>> >>> ENUM_BITFIELD(machine_mode) mode : 8; >>> >>> bits are grouped in groups of 8 bits, this breaks it. >>> >> >> Oh..., does this explain the problems that I had with this version??? > > No, just "cosmetics". > >>> @@ -8041,7 +8041,8 @@ build_pointer_type_for_mode (tree to_type, machine >>> >>> /* If the pointed-to type has the may_alias attribute set, force >>> a TYPE_REF_CAN_ALIAS_ALL pointer to be generated. */ >>> - if (lookup_attribute ("may_alias", TYPE_ATTRIBUTES (to_type))) >>> + if (TYPE_TYPELESS_STORAGE (to_type) >>> + || lookup_attribute ("may_alias", TYPE_ATTRIBUTES (to_type))) >>> can_alias_all =3D true; >>> >>> /* In some cases, languages will have things that aren't a POINTER_T= YPE >>> @@ -8110,7 +8111,8 @@ build_reference_type_for_mode (tree to_type, machi >>> >>> /* If the pointed-to type has the may_alias attribute set, force >>> a TYPE_REF_CAN_ALIAS_ALL pointer to be generated. */ >>> - if (lookup_attribute ("may_alias", TYPE_ATTRIBUTES (to_type))) >>> + if (TYPE_TYPELESS_STORAGE (to_type) >>> + || lookup_attribute ("may_alias", TYPE_ATTRIBUTES (to_type))) >>> can_alias_all =3D true; >>> >>> /* In some cases, languages will have things that aren't a >>> >>> not needed. >>> >> >> You mean, because the get_alias_set (to_type) will be 0 anyways, >> and can_alias_all wont change the semantic? > > Well, typeless_storage and may_alias are something different. If > you require the above then your implementation of typeless_storage > is broken. > You are right, the hunk above is actually unnecessary. > Richard. > >> >> Bernd. >> >>> +/* Nonzero if the type should behave like a character type >>> + with respect to aliasing sementics. */ >>> +#define TYPE_TYPELESS_STORAGE(NODE) \ >>> + (TYPE_CHECK (NODE)->type_common.typeless_storage_flag) >>> >>> ARRAY_TYPE_CHECK (NODE)-> >>> >>> Richard. >>> >> >> >