From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) by sourceware.org (Postfix) with ESMTPS id 1166F3858C52 for ; Tue, 21 Mar 2023 07:29:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1166F3858C52 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-lj1-x22c.google.com with SMTP id s20so7333107ljp.1 for ; Tue, 21 Mar 2023 00:29:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679383768; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=HEA9peQNPX+RsL7rY8KFtGMfjr35YFuS0LuXUiVqPOk=; b=aCkZQhY3OiYvGfDB69LHxQK62IO+mtGIXkHMbtzPL2QVFyfuZ50Tg4s2nmfUrZVjZT c7uhHTdP5fX8x14PeQFNsUEG0tYXlS5Wyhnz0E/7tGfVymP6oCqGPeTTdQctnsQJrLV2 oypfM4lcF6h+84tqfkjiQ38ulvDjUmIBA62/c0HK0LLfSzW6z5/agTre1Z4u+7vSkpiV Zu/aXfFABlOMofz8TG98Pe3YQMRD0SKQBEXwdzxMdOcfWTqoEdyqF0/ry51eWi1mivxq 3arpepXSkDhEjJ/htvSGTQNH+l7kqzRM0v9Cx333M5astJSpA4eB9VcPl6Ap+W4Zn6oR SULw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679383768; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=HEA9peQNPX+RsL7rY8KFtGMfjr35YFuS0LuXUiVqPOk=; b=5TSqIlPi5P8tuO3DHIQZe6Wbg5fMyqmq5QQrMhk1mcz3gd2mcsPrANZOG1r8goLnbD P3dvbGJkZKDhLj+xCzZeX4fgZGPoF5aIzKEXT+ehowusPo/hHo2kjcWYzd1qiN8T4NEc 4sxnxk1TC7GpMQEHJ3wN8W03gKd1Ker/QfR48jCo3lwoZUQhW3cOFNHupynBFughGi3+ o4WplfEajZ9B3c2LhJB4I6T3TqZciDMhhx0QU7sToztpm6Fx4M76+DvSUrG61hqInXbG dDQgsQ0sqpzgwZMJbqNbQaAO5/CuQLZzFUkePbgFtdweLvw25FsYfmw9q7CIKBeCmDfa 58Kg== X-Gm-Message-State: AO0yUKVj3/+RYOav1or+La1t4tyDO/I4Dv5Dm5bxrB6mPv7gPBd9p4qx VWwwwXFc1/OaOzIE9ZvWEifFGOB5mKemyAYFKedDhB+b X-Google-Smtp-Source: AK7set83PJTEleHu/MXdHGG+c2OCylPZHdUxWz6WD+XmO9WHXbL+Y/z4QWaXz4S8HFekTVjPi7THO0RT8Ln9PJKxYSU= X-Received: by 2002:a2e:901a:0:b0:299:aa7a:94c8 with SMTP id h26-20020a2e901a000000b00299aa7a94c8mr529041ljg.10.1679383767956; Tue, 21 Mar 2023 00:29:27 -0700 (PDT) MIME-Version: 1.0 References: <9cbb57b3-3e66-3618-217f-bf2689cc8825@codesourcery.com> In-Reply-To: <9cbb57b3-3e66-3618-217f-bf2689cc8825@codesourcery.com> From: Richard Biener Date: Tue, 21 Mar 2023 08:29:14 +0100 Message-ID: Subject: Re: stor-layout: Set TYPE_TYPELESS_STORAGE consistently for type variants To: Joseph Myers Cc: gcc-patches@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-7.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,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: On Mon, Mar 20, 2023 at 8:47=E2=80=AFPM Joseph Myers wrote: > > 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? OK for trunk and branches. Thanks, Richard. > * 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 =3D TYPE_USER_ALIGN (type); > machine_mode mode =3D TYPE_MODE (type); > bool empty_p =3D TYPE_EMPTY_P (type); > + bool typeless =3D AGGREGATE_TYPE_P (type) && TYPE_TYPELESS_STORAGE= (type); > > /* Copy it into all variants. */ > for (variant =3D TYPE_MAIN_VARIANT (type); > @@ -2020,6 +2021,8 @@ finalize_type_size (tree type) > TYPE_PRECISION (variant) =3D precision; > SET_TYPE_MODE (variant, mode); > TYPE_EMPTY_P (variant) =3D empty_p; > + if (AGGREGATE_TYPE_P (variant)) > + TYPE_TYPELESS_STORAGE (variant) =3D typeless; > } > } > } > > -- > Joseph S. Myers > joseph@codesourcery.com