From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa4.mentor.iphmx.com (esa4.mentor.iphmx.com [68.232.137.252]) by sourceware.org (Postfix) with ESMTPS id 9C36D3858D32 for ; Mon, 20 Mar 2023 19:46:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9C36D3858D32 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com X-IronPort-AV: E=Sophos;i="5.98,276,1673942400"; d="cc'?scan'208";a="100953490" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa4.mentor.iphmx.com with ESMTP; 20 Mar 2023 11:46:38 -0800 IronPort-SDR: bM9Hp41Is/t8qXQT2fFPWfRdUMK47WAqFy7YmZnbdoU1VyfBsRvnIJvZN/FANqOgDoDjEbMWtZ BjEm0/UmV4W2n7GJ0ZWyNdanFuzJ6pJj8Nj806XG44nvdgh+SY02ObQ+jiLfJRe+JARQCfMD73 PqXrZ89WMg4Nd8acAQNKL3ZMaZKIhqX/b4qbk2e+OP6UP6D6pt94pRtya/tOzuAbkX6lj4Mxey 9my0OzbQPARtn1Gw+Gla5dYUrzoxLiTwI8iVV63d+b1VUudf92oltRGTh+cxS2fcrn7/Tu1VyI lv0= Date: Mon, 20 Mar 2023 19:46:32 +0000 From: Joseph Myers To: Subject: stor-layout: Set TYPE_TYPELESS_STORAGE consistently for type variants Message-ID: <9cbb57b3-3e66-3618-217f-bf2689cc8825@codesourcery.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="-1152306461-1672972182-1679341592=:1070469" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-14.mgc.mentorg.com (139.181.222.14) To svr-ies-mbx-10.mgc.mentorg.com (139.181.222.10) X-Spam-Status: No, score=-3113.6 required=5.0 tests=BAYES_00,GIT_PATCH_0,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: ---1152306461-1672972182-1679341592=:1070469 Content-Type: text/plain; charset="US-ASCII" I've observed an LTO wrong-code bug with a large testcase in GCC 12, that results from TYPE_TYPELESS_STORAGE not being set consistently on type variants. Specifically, in the LTO stage of compilation, there is an aggregate type passed to get_alias_set, whose TYPE_MAIN_VARIANT does not have TYPE_TYPELESS_STORAGE set. However, the TYPE_CANONICAL of that main variant *does* have have TYPE_TYPELESS_STORAGE set; note that the use of TYPE_CANONICAL in get_alias_set comes after the check of TYPE_TYPELESS_STORAGE. The effect is that when (one-argument) record_component_aliases is called, the recursive call to get_alias_set gives alias set 0, and the aggregate type ends up not being considered to alias its members, with wrong-code consequences. I haven't managed to produce a self-contained executable testcase to demonstrate this, but it clearly seems appropriate for TYPE_TYPELESS_STORAGE to be consistent on type variants, so this patch makes it so, which appears to be sufficient to resolve the bug. I've attached a reduced test that does at least demonstrate main-variant versions of a type (SB in this test) being written out to LTO IR both with and without TYPE_TYPELESS_STORAGE, although not the subsequent consequences of a type without TYPE_TYPELESS_STORAGE with a TYPE_CANONICAL (as constructed after LTO type merging) with TYPE_TYPELESS_STORAGE and following wrong-code. Bootstrapped with no regressions for x86_64-pc-linux-gnu. OK to commit? * stor-layout.cc (finalize_type_size): Copy TYPE_TYPELESS_STORAGE to variants. diff --git a/gcc/stor-layout.cc b/gcc/stor-layout.cc index 45bf2d18639..023de8c37db 100644 --- a/gcc/stor-layout.cc +++ b/gcc/stor-layout.cc @@ -1996,6 +1996,7 @@ finalize_type_size (tree type) unsigned int user_align = TYPE_USER_ALIGN (type); machine_mode mode = TYPE_MODE (type); bool empty_p = TYPE_EMPTY_P (type); + bool typeless = AGGREGATE_TYPE_P (type) && TYPE_TYPELESS_STORAGE (type); /* Copy it into all variants. */ for (variant = TYPE_MAIN_VARIANT (type); @@ -2020,6 +2021,8 @@ finalize_type_size (tree type) TYPE_PRECISION (variant) = precision; SET_TYPE_MODE (variant, mode); TYPE_EMPTY_P (variant) = empty_p; + if (AGGREGATE_TYPE_P (variant)) + TYPE_TYPELESS_STORAGE (variant) = typeless; } } } -- Joseph S. Myers joseph@codesourcery.com ---1152306461-1672972182-1679341592=:1070469 Content-Type: text/x-c++src; name="typeless.cc" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="typeless.cc" c3RydWN0IFMgew0KICBpbnQgYTsNCiAgY2hhciBiWzhdOw0KfTsNCnRlbXBs YXRlIDxpbnQ+IGNsYXNzIFNCIHsNCnB1YmxpYzoNCiAgb3BlcmF0b3IgYm9v bCgpIHsgcmV0dXJuIHRydWU7IH07DQogIFMgeDsNCn07DQpjbGFzcyBUIDog cHVibGljIFNCPDA+IHt9Ow0KdGVtcGxhdGUgPHR5cGVuYW1lIFRUPiBjbGFz cyBtMSB7DQpwdWJsaWM6DQogIG0xKFRUKSB7fQ0KICB2b2lkIG0yKCkge307 DQp9Ow0KY2xhc3MgVSB7DQpwdWJsaWM6DQogIFUoaW50LCBUIGMpIHsNCiAg ICBhdXRvIHYgPSBtMShbXSB7fSk7DQogICAgaWYgKGMpDQogICAgICB2Lm0y KCk7DQogIH0NCn07DQp2b2lkIGYoKSB7DQogIFQgYyA9IHt9Ow0KICBVKDAs IGMpOw0KfQ0K ---1152306461-1672972182-1679341592=:1070469--