From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) by sourceware.org (Postfix) with ESMTPS id B37693858D1E for ; Thu, 8 Sep 2022 07:37:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B37693858D1E 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-wm1-x333.google.com with SMTP id n17-20020a05600c3b9100b003b3235574dbso661377wms.2 for ; Thu, 08 Sep 2022 00:37:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date; bh=tybImlVEMgvFoTwx2CXTIoP8kSP8Y5In246h3EtbR/Q=; b=HY7CjZMGFVhcrJAxuDc681Z3c80HEBPpFC3G6il6hyz2xH75J+PDZAgBzMPhuHqeb0 L9kCbvo9j8JP4vW3qTXTH0TDycgOPkpFn6+aq3Awt2jibriHrbfZPnC1mIQPN8IuA40L iUU35JRA+5PBKXGU+G3hORVBbqz9l6U/T2PnyDiGx+nOrl3H0Qx6M9hxG+HEYQDzTqJm bv1eVtVKvmuBNCpuFoE9Ky2M5VKnMTdKifZ+MA+JhZRxlsQD4r7dKL9raOgwSc08eYJ6 VSCddkUtYPZEWNnw/f5AmeHlUq6wk27zje927m0vfvsjuOxSsOe/FCMKLKO2qJp9zJg7 gAIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date; bh=tybImlVEMgvFoTwx2CXTIoP8kSP8Y5In246h3EtbR/Q=; b=b8gy2uEz3UpNCs2j3P0ghnjWO5XKbREdPWxlpzTQV/03OzbBpxB+0fdj01WM9FZxI9 Iz3LSrEvqTBSwZ9XJT7VioLnpDqlDXAKttcnSFiAWd9xZnb7GNtQj6is+ObOzbrYgC9H AFCze2ZHb2o7xMox1mIvdTFI29k83feClFr9W1yx7X1w4dmzMBGKz+WZg1bcUwScQSgD vDtvIig8t4FVBk31MPpzX02k7lUR8qkvRDL6fDAZBHmaeLlgETnNuAz7zOhM2Z0wIEiR oaplHICo4Uh29AFxWC0hmHp8X0jy6kSlqVEBrts73ne7z2Vzvhz479rTaTeTPp4b6Mbh uWoA== X-Gm-Message-State: ACgBeo2mCkJRWJG+rqjek6Ck1eXXDTlfT2S3ob7bJgb3wCQST44rWI8i MZ411jCLVfXm0FLxXbStTdM= X-Google-Smtp-Source: AA6agR5IfyoMdOn91MXUsoY843XArl1DGdujE2LiKz7dwXamL1Eh7Qd9P1ClACr+OjaggPCfX1S/TA== X-Received: by 2002:a05:600c:1d12:b0:3a5:eb79:edc3 with SMTP id l18-20020a05600c1d1200b003a5eb79edc3mr1268070wms.136.1662622620425; Thu, 08 Sep 2022 00:37:00 -0700 (PDT) Received: from smtpclient.apple ([2a02:3038:209:6864:c1b9:1a90:e0dd:5e31]) by smtp.gmail.com with ESMTPSA id e2-20020a5d5942000000b00226f39d1a3esm20215770wri.73.2022.09.08.00.36.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 08 Sep 2022 00:36:58 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Richard Biener Mime-Version: 1.0 (1.0) Subject: Re: [PATCH] Handle OPAQUE_TYPE specially in verify_type [PR106833] Date: Thu, 8 Sep 2022 09:36:57 +0200 Message-Id: References: Cc: GCC Patches , Segher Boessenkool , Peter Bergner In-Reply-To: To: "Kewen.Lin" X-Mailer: iPhone Mail (19G82) X-Spam-Status: No, score=-10.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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: > Am 08.09.2022 um 07:53 schrieb Kewen.Lin : >=20 > =EF=BB=BFHi, >=20 > As PR106833 shows, cv-qualified opaque type can cause ICE > during LTO. It exposes that we missd to handle OPAQUE_TYPE > well in type verification. As Richi pointed out, also > assuming that target will always define TYPE_MAIN_VARIANT > and TYPE_CANONICAL for opaque type, this patch is to check > both are OPAQUE_TYPE_P. Besides, it also checks the only > available size and alignment information as well as type > mode for TYPE_MAIN_VARIANT. >=20 > Bootstrapped and regtested on powerpc64-linux-gnu P7 and > powerpc64le-linux-gnu P9 and P10. >=20 > Is it ok for trunk? >=20 > BR, > Kewen > ----- > PR middle-end/106833 >=20 > gcc/ChangeLog: >=20 > * tree.cc (verify_opaque_type): New function. > (verify_match): New macro. > (verify_type): Call verify_opaque_type for OPAQUE_TYPE. >=20 > gcc/testsuite/ChangeLog: >=20 > * gcc.target/powerpc/pr106833.c: New test. > --- > gcc/testsuite/gcc.target/powerpc/pr106833.c | 14 +++++++ > gcc/tree.cc | 45 ++++++++++++++++++++- > 2 files changed, 58 insertions(+), 1 deletion(-) > create mode 100644 gcc/testsuite/gcc.target/powerpc/pr106833.c >=20 > diff --git a/gcc/testsuite/gcc.target/powerpc/pr106833.c b/gcc/testsuite/g= cc.target/powerpc/pr106833.c > new file mode 100644 > index 00000000000..968d75184ff > --- /dev/null > +++ b/gcc/testsuite/gcc.target/powerpc/pr106833.c > @@ -0,0 +1,14 @@ > +/* { dg-do link } */ > +/* { dg-require-effective-target power10_ok } */ > +/* { dg-require-effective-target lto } */ > +/* { dg-options "-flto -mdejagnu-cpu=3Dpower10" } */ > + > +/* Verify there is no ICE in LTO mode. */ > + > +int main () > +{ > + float *b; > + const __vector_quad c; > + __builtin_mma_disassemble_acc (b, &c); > + return 0; > +} > diff --git a/gcc/tree.cc b/gcc/tree.cc > index fed1434d141..e67caa8f85d 100644 > --- a/gcc/tree.cc > +++ b/gcc/tree.cc > @@ -13670,6 +13670,42 @@ gimple_canonical_types_compatible_p (const_tree t= 1, const_tree t2, > } > } >=20 > +/* For OPAQUE_TYPE T, it has only size and alignment information, so veri= fy > + these properties of T match TV which is the main variant of T. Also > + verify the type of TC, which is the canonical of T, is OPAQUE_TYPE. *= / > + > +static void > +verify_opaque_type (const_tree t, tree tv, tree tc) > +{ > + gcc_assert (OPAQUE_TYPE_P (t)); > + gcc_assert (tv && tv =3D=3D TYPE_MAIN_VARIANT (tv)); > + gcc_assert (tc && tc =3D=3D TYPE_CANONICAL (tc)); > + > +#define verify_match(flag, t, tv) = \ > + do = \ > + { = \ > + if (flag (t) !=3D flag (tv)) = \ > + { = \ > + error ("opaque type differs by %s", #flag); = \ > + debug_tree (tv); = \ > + } = \ > + } = \ > + while (false) > + > + if (t !=3D tv) > + { > + verify_match (TREE_CODE, t, tv); > + verify_match (TYPE_MODE, t, tv); > + verify_match (TYPE_SIZE, t, tv); TYPE_SIZE is a tree, you should probably=20 Compare this with operand_equal_p. It=E2=80=99s=20 Not documented to be a constant size? Thus some VLA vector mode might be allowed ( a poly_int size), BLKmode Is ruled out(?), the docs say we have =E2=80=9AAn MODE_Opaque=E2=80=98 here but I don=E2=80=99t see This being verified? The macro makes this a bit unworldly For the only benefit of elaborate diagnostic Which I think isn=E2=80=99t really necessary > + verify_match (TYPE_ALIGN, t, tv); > + verify_match (TYPE_USER_ALIGN, t, tv); > + } > + > + if (t !=3D tc) > + verify_match (TREE_CODE, t, tc); > +#undef verify_match > +} > + > /* Verify type T. */ >=20 > void > @@ -13677,6 +13713,14 @@ verify_type (const_tree t) > { > bool error_found =3D false; > tree mv =3D TYPE_MAIN_VARIANT (t); > + tree ct =3D TYPE_CANONICAL (t); > + > + if (OPAQUE_TYPE_P (t)) > + { > + verify_opaque_type (t, mv, ct); > + return; > + } > + > if (!mv) > { > error ("main variant is not defined"); > @@ -13691,7 +13735,6 @@ verify_type (const_tree t) > else if (t !=3D mv && !verify_type_variant (t, mv)) > error_found =3D true; >=20 > - tree ct =3D TYPE_CANONICAL (t); > if (!ct) > ; > else if (TYPE_CANONICAL (ct) !=3D ct) > -- > 2.27.0 >=20