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 BAAAA392B150 for ; Thu, 8 Dec 2022 07:43:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BAAAA392B150 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 2D98523A; Wed, 7 Dec 2022 23:43: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 493583F73D; Wed, 7 Dec 2022 23:43: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> <9be25782-d2de-80ca-a9e1-55cd3fc7f9a2@linux.ibm.com> Date: Thu, 08 Dec 2022 07:43:39 +0000 In-Reply-To: <9be25782-d2de-80ca-a9e1-55cd3fc7f9a2@linux.ibm.com> (Kewen Lin's message of "Thu, 8 Dec 2022 10:14:19 +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.5 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: > on 2022/12/7 20:55, Richard Sandiford wrote: >> "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. >> > > Indeed. :) > >> 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? >> > > Thanks for pointing out this, I tried with the below test case: > > __vector_quad a1; > __vector_quad a2; > > __attribute__((target("cpu=power8"))) > void foo () > { > a2 = a3; > } > > the verify_type_context doesn't catch it as you suspected, I think > it needs some enhancements somewhere. FWIW, another possible case is: foo_t f(); void g(foo_t); void h() { g(f()); } I'm not aware of any verify_type_context checks that would catch this for SVE (since it's valid for SVE types). Thanks, Richard