From patchwork Fri Sep 9 06:51:14 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: "Kewen.Lin" X-Patchwork-Id: 1106 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:5044:0:0:0:0:0 with SMTP id h4csp585857wrt; Thu, 8 Sep 2022 23:52:13 -0700 (PDT) X-Google-Smtp-Source: AA6agR5sTxctbe0J33ZcE5A6ARJy9jRbEIlPZWQJPH34p0OCIfhVl8hd+3XQ4WHimg2QP801jQxY X-Received: by 2002:a05:6402:e94:b0:443:e3fe:7c87 with SMTP id h20-20020a0564020e9400b00443e3fe7c87mr10381704eda.144.1662706333152; Thu, 08 Sep 2022 23:52:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1662706333; cv=none; d=google.com; s=arc-20160816; b=Oh2LYE0IHMdPQacCVxA+pWSp9lWL/iJ1MvJ944e2y6hUo3mizi4liH6myeDHXI+ZhZ BthKtN7ON9upkdMwpHx6m9NrYoOs84ev/eNxDSwSSljJc48tEaOCEHcZ5VssXEu3B5Dh zyny7WsMCPxX2PgJB/SEgL75ZV4pKExXe89EPg3iy4qVp0/soBoeuU2FEh3aofEYXw2q MbsVZOeJk7ofAQLf6jjS9qQVxPmkJ22ynrYx3kYUqPywt900DmCyk9BwIJ+HaLZFSg1L lvPGlB7l8v2zBLKbXJhFXkdH7wkr/LFyMTcBgPNiWXlTudQA29mQyCQqFq7ZwCyGjZO6 +t+g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:cc:reply-to:from:list-subscribe:list-help :list-post:list-archive:list-unsubscribe:list-id:precedence :in-reply-to:references:to:content-language:subject:user-agent :mime-version:date:message-id:dmarc-filter:delivered-to :dkim-signature:dkim-filter; bh=KqxrIHFo6It7WgdT5BKy3HwPN7fXCfy5hVpeY7sKLEk=; b=CKWS2kBDy1xbTyw9zIL06XhvicB3XE7wqnhUUh/K5X+k9GW91kbDY7GoqG+N7QibiQ jUBcVthu9o5kUoA4x7EukAQbvpwBavZXcAJ0c1SEe654ljVJRY0KMkx6HKjMz3xSFMw7 wfJkVnLl2eKl7v24Qeyo3kMNns85rUUf9IZDrypydwUG0j5p46mIqd6vXVkElScWdCL1 c9+iropN1NpEcAeVn+vLvdX9ySAFkG2Yem5lq88SuKVOkh8i9O0NTBH9ym6FEQgVWBLz po0M2FbO3K8EiPBWJAkkdfm16/ToZobMmlCqw0WiiHLXV9KCRJlJ4ftuCEPdsDNVI/5k 19Rw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b=r2fBryYx; 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"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gnu.org Received: from sourceware.org (server2.sourceware.org. [2620:52:3:1:0:246e:9693:128c]) by mx.google.com with ESMTPS id q15-20020a170906540f00b0073056870528si855689ejo.888.2022.09.08.23.52.12 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 08 Sep 2022 23:52:13 -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; dkim=pass header.i=@gcc.gnu.org header.s=default header.b=r2fBryYx; 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"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gnu.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 811DA38582A4 for ; Fri, 9 Sep 2022 06:52:08 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 811DA38582A4 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1662706328; bh=KqxrIHFo6It7WgdT5BKy3HwPN7fXCfy5hVpeY7sKLEk=; h=Date:Subject:To:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=r2fBryYxNCXmElcwgn774OdgwknHvG3maX16ZalzPPbggfbb+DD1mNL3e1HZYSk+s OUCi9gWoGoXys1NzUJw2RX41vG5BNTH65S+GAuM+cHu0rACfbkePZztOmqDeyCpYrV 90y6Aua2SaJDoyltMt1A8lWfn7PAQftuXSbf7Y4E= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id C52CC385829C for ; Fri, 9 Sep 2022 06:51:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C52CC385829C Received: from pps.filterd (m0098419.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 2896QH6l020535; Fri, 9 Sep 2022 06:51:23 GMT Received: from pps.reinject (localhost [127.0.0.1]) by mx0b-001b2d01.pphosted.com (PPS) with ESMTPS id 3jg07egpm7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 09 Sep 2022 06:51:22 +0000 Received: from m0098419.ppops.net (m0098419.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 2896RpT9027433; Fri, 9 Sep 2022 06:51:22 GMT Received: from ppma05fra.de.ibm.com (6c.4a.5195.ip4.static.sl-reverse.com [149.81.74.108]) by mx0b-001b2d01.pphosted.com (PPS) with ESMTPS id 3jg07egpkm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 09 Sep 2022 06:51:22 +0000 Received: from pps.filterd (ppma05fra.de.ibm.com [127.0.0.1]) by ppma05fra.de.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 2896pKca012354; Fri, 9 Sep 2022 06:51:20 GMT Received: from b06cxnps4074.portsmouth.uk.ibm.com (d06relay11.portsmouth.uk.ibm.com [9.149.109.196]) by ppma05fra.de.ibm.com with ESMTP id 3jbxj8wkh0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 09 Sep 2022 06:51:20 +0000 Received: from d06av23.portsmouth.uk.ibm.com (d06av23.portsmouth.uk.ibm.com [9.149.105.59]) by b06cxnps4074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 2896pHfa30933268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 9 Sep 2022 06:51:18 GMT Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D5FB4A4040; Fri, 9 Sep 2022 06:51:17 +0000 (GMT) Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 2E547A4059; Fri, 9 Sep 2022 06:51:16 +0000 (GMT) Received: from [9.197.248.186] (unknown [9.197.248.186]) by d06av23.portsmouth.uk.ibm.com (Postfix) with ESMTP; Fri, 9 Sep 2022 06:51:15 +0000 (GMT) Message-ID: <302a193a-2751-a404-31c6-f5b4a3e6856a@linux.ibm.com> Date: Fri, 9 Sep 2022 14:51:14 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Subject: [PATCH v2] Handle OPAQUE_TYPE specially in verify_type [PR106833] Content-Language: en-US To: Richard Biener References: In-Reply-To: X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: UiOAZUambBmLP5m4g-uK6ds_-8HJVz37 X-Proofpoint-GUID: dNGTz7ceaQb8rzr7-lMWk57utBZ7GU5Y X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.528,FMLib:17.11.122.1 definitions=2022-09-09_02,2022-09-09_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 spamscore=0 clxscore=1015 phishscore=0 impostorscore=0 mlxscore=0 adultscore=0 mlxlogscore=999 lowpriorityscore=0 bulkscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2207270000 definitions=main-2209090021 X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, GIT_PATCH_0, IMAGE_ATTACHED, KAM_SHORT, RCVD_IN_MSPIKE_H2, 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 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: , X-Patchwork-Original-From: "Kewen.Lin via Gcc-patches" From: "Kewen.Lin" Reply-To: "Kewen.Lin" Cc: Peter Bergner , GCC Patches , Segher Boessenkool 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?1743379724432754258?= X-GMAIL-MSGID: =?utf-8?q?1743473955736604043?= Hi Richi, Thanks for the review comments! on 2022/9/8 15:36, Richard Biener wrote: > > >> Am 08.09.2022 um 07:53 schrieb Kewen.Lin : >> >> Hi, >> >> 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. >> ... >> + >> + if (t != 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 > Compare this with operand_equal_p. It’s > Not documented to be a constant size? > Thus some VLA vector mode might be allowed ( a poly_int size), Thanks for catching, I was referencing the code in function verify_type_variant, that corresponding part seems imperfect: if (TREE_CODE (TYPE_SIZE (t)) != PLACEHOLDER_EXPR && TREE_CODE (TYPE_SIZE (tv)) != PLACEHOLDER_EXPR) verify_variant_match (TYPE_SIZE); I agree poly_int size is allowed, the patch was updated for it. BLKmode > Is ruled out(?), Yes, it requires a mode of MODE_OPAQUE class. the docs say we have > ‚An MODE_Opaque‘ here but I don’t see > This being verified? > There is a MODE equality check, I assumed the given t already has one MODE_OPAQUE mode, but the patch was updated to make it explicit as you concerned. > The macro makes this a bit unworldly > For the only benefit of elaborate diagnostic > Which I think isn’t really necessary OK, fixed! The previous version makes just one check on TYPE_CANONICAL to be cheap as gimple_canonical_types_compatible_p said, but since there are just several fields to be check, this updated version adjusted it to be the same as what's for TYPE_MAIN_VARIANT. Hope it's fine. :) Tested as before. Does this updated patch look good to you? BR, Kewen ------ From 4a905fcb2abcc4e488d90011dd2c2125fb9e14b2 Mon Sep 17 00:00:00 2001 From: Kewen Lin Date: Thu, 8 Sep 2022 21:34:29 -0500 Subject: [PATCH] Handle OPAQUE_TYPE specially in verify_type [PR106833] 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 TYPE_CANONICAL for opaque type, this patch is to check both are OPAQUE_TYPE_P and their modes are of MODE_OPAQUE class. Besides, it also checks the only available size and alignment information. PR middle-end/106833 gcc/ChangeLog: * tree.cc (verify_opaque_type): New function. (verify_type): Call verify_opaque_type for OPAQUE_TYPE. gcc/testsuite/ChangeLog: * gcc.target/powerpc/pr106833.c: New test. --- gcc/testsuite/gcc.target/powerpc/pr106833.c | 14 ++++ gcc/tree.cc | 74 ++++++++++++++++++++- 2 files changed, 87 insertions(+), 1 deletion(-) create mode 100644 gcc/testsuite/gcc.target/powerpc/pr106833.c diff --git a/gcc/testsuite/gcc.target/powerpc/pr106833.c b/gcc/testsuite/gcc.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=power10" } */ + +/* 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..b755cd5083a 100644 --- a/gcc/tree.cc +++ b/gcc/tree.cc @@ -13670,6 +13670,71 @@ gimple_canonical_types_compatible_p (const_tree t1, const_tree t2, } } +/* For OPAQUE_TYPE T, it should have only size and alignment information + and its mode should be of class MODE_OPAQUE. This function verifies + these properties of T match TV which is the main variant of T and TC + which is the canonical of T. */ + +static void +verify_opaque_type (const_tree t, tree tv, tree tc) +{ + gcc_assert (OPAQUE_TYPE_P (t)); + gcc_assert (tv && tv == TYPE_MAIN_VARIANT (tv)); + gcc_assert (tc && tc == TYPE_CANONICAL (tc)); + + /* For an opaque type T1, check if some of its properties match + the corresponding ones of the other opaque type T2, emit some + error messages for those inconsistent ones. */ + auto check_properties_for_opaque_type = [](const_tree t1, tree t2, + const char *kind_msg) + { + if (!OPAQUE_TYPE_P (t2)) + { + error ("type %s is not an opaque type", kind_msg); + debug_tree (t2); + return; + } + if (!OPAQUE_MODE_P (TYPE_MODE (t2))) + { + error ("type %s is not with opaque mode", kind_msg); + debug_tree (t2); + return; + } + if (TYPE_MODE (t1) != TYPE_MODE (t2)) + { + error ("type %s differs by %", kind_msg); + debug_tree (t2); + return; + } + poly_uint64 t1_size = tree_to_poly_uint64 (TYPE_SIZE (t1)); + poly_uint64 t2_size = tree_to_poly_uint64 (TYPE_SIZE (t2)); + if (maybe_ne (t1_size, t2_size)) + { + error ("type %s differs by %", kind_msg); + debug_tree (t2); + return; + } + if (TYPE_ALIGN (t1) != TYPE_ALIGN (t2)) + { + error ("type %s differs by %", kind_msg); + debug_tree (t2); + return; + } + if (TYPE_USER_ALIGN (t1) != TYPE_USER_ALIGN (t2)) + { + error ("type %s differs by %", kind_msg); + debug_tree (t2); + return; + } + }; + + if (t != tv) + check_properties_for_opaque_type (t, tv, "variant"); + + if (t != tc) + check_properties_for_opaque_type (t, tc, "canonical"); +} + /* Verify type T. */ void @@ -13677,6 +13742,14 @@ verify_type (const_tree t) { bool error_found = false; tree mv = TYPE_MAIN_VARIANT (t); + tree ct = 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 +13764,6 @@ verify_type (const_tree t) else if (t != mv && !verify_type_variant (t, mv)) error_found = true; - tree ct = TYPE_CANONICAL (t); if (!ct) ; else if (TYPE_CANONICAL (ct) != ct)