From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id CD61B388BA7E for ; Thu, 8 Dec 2022 09:16:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CD61B388BA7E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=linux.ibm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linux.ibm.com Received: from pps.filterd (m0187473.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 2B87VenP000772; Thu, 8 Dec 2022 09:16:01 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : date : mime-version : subject : to : references : cc : from : in-reply-to : content-type : content-transfer-encoding; s=pp1; bh=FT5vgAE5Wkx6Yx8YMX11SpPZFkVaQZ6/K+7Gb6QPVqQ=; b=NGWmdBGgWALIqsgo2b+Nf6fsS2CmFq2OENpN0cGKlcutmrL+eGNgfWtRC9cSncf0Stbb E341WSBwo/NDiFb3DyPg4A43LTZwBdpF8sUV2ZuVQ2Jmwgj/MhDS2MDRABwiVfo/0Sps MrDypJKZoXtMp3OfIC9ADHZMw+a6chu364w9/ttbu6P5Wb7f2xte14W+7Vg6IvAJMDTf Bj84EYumB23NVfECsPPhGXM2kWFENYGToleYBK8USFibP7uRc6jiy/n9SJfNYHL2U/NW iC4fErS+p8cGdFNy0Sx1Lw8dPID+zf9CJiGlTru0Co8zu8+wcEdwcQ0pGbLc5MXLI8/W PQ== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3mbbm6a8y2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 08 Dec 2022 09:16:00 +0000 Received: from m0187473.ppops.net (m0187473.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 2B890Tt1027198; Thu, 8 Dec 2022 09:16:00 GMT Received: from ppma04fra.de.ibm.com (6a.4a.5195.ip4.static.sl-reverse.com [149.81.74.106]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3mbbm6a8x5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 08 Dec 2022 09:15:59 +0000 Received: from pps.filterd (ppma04fra.de.ibm.com [127.0.0.1]) by ppma04fra.de.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 2B7HHPdG022335; Thu, 8 Dec 2022 09:15:57 GMT Received: from smtprelay02.fra02v.mail.ibm.com ([9.218.2.226]) by ppma04fra.de.ibm.com (PPS) with ESMTPS id 3m9kur323n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 08 Dec 2022 09:15:57 +0000 Received: from smtpav01.fra02v.mail.ibm.com (smtpav01.fra02v.mail.ibm.com [10.20.54.100]) by smtprelay02.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 2B89Ftxq42729946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 8 Dec 2022 09:15:55 GMT Received: from smtpav01.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 15F8520043; Thu, 8 Dec 2022 09:15:55 +0000 (GMT) Received: from smtpav01.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 3F0EE20040; Thu, 8 Dec 2022 09:15:52 +0000 (GMT) Received: from [9.197.235.114] (unknown [9.197.235.114]) by smtpav01.fra02v.mail.ibm.com (Postfix) with ESMTP; Thu, 8 Dec 2022 09:15:50 +0000 (GMT) Message-ID: Date: Thu, 8 Dec 2022 17:15:49 +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: Re: [PATCH] Fix aarch64 PR 99657: ICE with SVE types used without an error Content-Language: en-US To: richard.sandiford@arm.com 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> Cc: apinski@marvell.com, gcc-patches@gcc.gnu.org, polacek@redhat.com, Joseph Myers , jason@redhat.com, nathan@acm.org, Segher Boessenkool From: "Kewen.Lin" In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-GUID: qKo144JT8QDmUUHPJyLLkWdGFcL_NL-k X-Proofpoint-ORIG-GUID: VWc5pE6DeWvNC___JcMVtL2B8jEbRQDf X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.923,Hydra:6.0.545,FMLib:17.11.122.1 definitions=2022-12-08_04,2022-12-07_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 mlxlogscore=999 bulkscore=0 priorityscore=1501 impostorscore=0 spamscore=0 phishscore=0 mlxscore=0 lowpriorityscore=0 malwarescore=0 adultscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2210170000 definitions=main-2212080073 X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_MSPIKE_H2,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 2022/12/8 15:43, Richard Sandiford wrote: > "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). OK, thanks for the information, MMA built-in types are not allowed to be used in function arguments, by hacking with the restriction relaxing, I confirm the verify_type_context check can't catch this case. BR, Kewen