From patchwork Mon Mar 20 19:46:32 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Joseph Myers X-Patchwork-Id: 72427 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:604a:0:0:0:0:0 with SMTP id j10csp1404262wrt; Mon, 20 Mar 2023 12:47:21 -0700 (PDT) X-Google-Smtp-Source: AK7set8sXge7I+DUM7LmS0wRFHWgIbae306slKMuse3vJzicadlj0nFbYSJWjq7I45HoBu+9FfyX X-Received: by 2002:a05:6402:44:b0:500:40b4:f348 with SMTP id f4-20020a056402004400b0050040b4f348mr658582edu.29.1679341641248; Mon, 20 Mar 2023 12:47:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1679341641; cv=none; d=google.com; s=arc-20160816; b=0KhH2hp/PiC8ncFoZJ9EzyOt6O7mhzauTQyxTgApMwR9UQTQ5fPRhRL3RL5RhJ3Hzf AirnYVn/znJCnGC/f1umGfqeddLkj0bNSPFDOniY47eykm6CPlRvDGQemTT2zsPZiK/4 ywftA497OBZCdvBMGLTuU6qA7JdBPaM6DGp5QkVpm/TpXEbbxUlt9jLIXJPF1QlXssCR LlX8NwK2QqBqLlz2bEuSy0QjatgLJaV90/BPQ24ck3oAvGMekFlRjluF6tV8Rqve4ZaM pKMBKNn0P+jrb4dIDvn8JuL815VDhi5ju4HrCCi6I96IM/ftc8u7t5c8SCQBxE/R5/Db Knjw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:list-subscribe:list-help:list-post:list-archive :list-unsubscribe:list-id:precedence:mime-version:message-id:subject :to:from:date:ironport-sdr:dmarc-filter:delivered-to; bh=/AtauXhMoejPihuURNLZXZDeGF6yuLJXWAuleG1QXa0=; b=MuWehDh+eatOH2rv7BQDPSOi1xZjaKf67IWphDPDpISeRhBbyHHsFAg1o17UAbrNG9 boQh5XrtZx7XqzK2d1D35dKE4O1wWPCQ9PWYv7DSHLMSHFxp6xn70gS9aJnZQiczI4OI F21WUGLSX+nZ3YWCviHJD0jZpbXcK9GkKxe2U6iPzGyZtl201mNDNy1v8r8E0ez9ygjL 32hJQQBP4NQkTtjoFlTlLJscLXH58LUqL8GN0gRMmeFOuP2Noglfmia8HjsZKs7dubBT Lu7qOcCEJfP7PwihZcVoJG5O0uALn9CMi5P6G9TSBS6NjK841MJFxNB0P7u+j8vyptz2 VeLw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org" Received: from sourceware.org (server2.sourceware.org. [2620:52:3:1:0:246e:9693:128c]) by mx.google.com with ESMTPS id d9-20020aa7c1c9000000b004fd2b14ad0asi4384206edp.85.2023.03.20.12.47.21 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 20 Mar 2023 12:47:21 -0700 (PDT) Received-SPF: pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) client-ip=2620:52:3:1:0:246e:9693:128c; Authentication-Results: mx.google.com; spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org" Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 23AD7384F036 for ; Mon, 20 Mar 2023 19:47:08 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org 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 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 X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org Sender: "Gcc-patches" X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1760917341099766359?= X-GMAIL-MSGID: =?utf-8?q?1760917341099766359?= 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; } } }