From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 29E97384D6F3 for ; Wed, 7 Dec 2022 12:55:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 29E97384D6F3 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 7515B23A; Wed, 7 Dec 2022 04:55:48 -0800 (PST) Received: from localhost (e121540-lin.manchester.arm.com [10.32.99.50]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 9175D3F73D; Wed, 7 Dec 2022 04:55:40 -0800 (PST) From: Richard Sandiford To: "Kewen.Lin" Mail-Followup-To: "Kewen.Lin" ,apinski@marvell.com, gcc-patches@gcc.gnu.org, polacek@redhat.com, Joseph Myers , jason@redhat.com, nathan@acm.org, Segher Boessenkool , richard.sandiford@arm.com Cc: apinski@marvell.com, gcc-patches@gcc.gnu.org, polacek@redhat.com, Joseph Myers , jason@redhat.com, nathan@acm.org, Segher Boessenkool Subject: Re: [PATCH] Fix aarch64 PR 99657: ICE with SVE types used without an error References: <1636452570-4846-1-git-send-email-apinski@marvell.com> <27c3ea14-1e54-5077-77bf-e3e6ddaf786c@linux.ibm.com> <2c058aad-6863-6979-ce6f-116d63b940a5@linux.ibm.com> Date: Wed, 07 Dec 2022 12:55:39 +0000 In-Reply-To: <2c058aad-6863-6979-ce6f-116d63b940a5@linux.ibm.com> (Kewen Lin's message of "Wed, 7 Dec 2022 19:29:11 +0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-32.6 required=5.0 tests=BAYES_00,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: "Kewen.Lin" writes: > Hi Richard, > > on 2022/12/7 17:16, Richard Sandiford wrote: >> "Kewen.Lin" writes: >>> Hi, >>> >>> In the recent discussion on how to make some built-in type only valid for >>> some target features efficiently[1], Andrew mentioned this patch which he >>> made previously (Thanks!). I confirmed it can help rs6000 related issue, >>> and noticed PR99657 is still opened, so I think we still want this to >>> be reviewed. >> >> But does it work for things like: >> >> void f(foo_t *x, foo_t *y) { *x = *y; } >> >> where no variables are being created with foo_t type? >> > > I think it can work for this case as it touches build_indirect_ref. Ah, ok. But indirecting through a pointer doesn't seem to match TCTX_AUTO_STORAGE. I guess another case is where there are global variables of the type that you want to forbid, compiled while the target feature is enabled, and then a function tries to access those variables with the target feature locally disabled (through a pragma or attribute). Does that case work? That's not an issue for SVE because global variables can't have sizeless type. >> That's not to say we shouldn't have the patch. I'm just not sure >> it can be the complete solution. > > I'm not sure about that either, maybe Andrew have more insights. > But as you pointed out in [1], I doubted trying to find all invalid > uses of a built-in type is worthwhile, it seems catching those usual > cases is enough and practical. So if this verify_type_context > framework can cover the most of uses, maybe it's a good direction > to go and extend. IMO it depends on what we're trying to protect against. If the compiler can handle these types correctly even when the target feature is disabled, and we're simply disallowing the types for policy rather than correctness reasons, then maybe just handling the usual cases is good enough. But things are different if the compiler is going to ICE or generate invalid code when something slips through. In that case, I think the niche cases matter too. Thanks, Richard