Message ID | 009c391d-3994-8755-0d22-9e80faf91f42@linux.ibm.com |
---|---|
State | Committed |
Commit | 975658b782f36dcf6eb190966d5b705977bfd5eb |
Headers |
Return-Path: <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id E2506385735C for <patchwork@sourceware.org>; Sat, 18 Jun 2022 04:51:08 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E2506385735C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1655527868; bh=Scar7ipXXfDxYxhxIZEhwSGUjBJdB6Dy+mPJ6a/WLzQ=; h=Date:To:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:Cc:From; b=ZZNprQhNcwRsNMw6//aV26LgQImt44UH2ix0Ie0CRMduBNu00rjKDtC5sTqNUoMt3 02deuzp6CeWt96R+k4CRDaV/ZCQm0Bx1OweSIZbnCTdp0LDwds4uhsQTs/W7YC4Gyl TndU91ROucOsr6KAJK/i1aeCuDWHOEBX7cSbh6qE= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id 9B4CF3857B92 for <gcc-patches@gcc.gnu.org>; Sat, 18 Jun 2022 04:50:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9B4CF3857B92 Received: from pps.filterd (m0098421.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 25I4fwWB025820; Sat, 18 Jun 2022 04:50:38 GMT Received: from ppma03wdc.us.ibm.com (ba.79.3fa9.ip4.static.sl-reverse.com [169.63.121.186]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3gs7668pey-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 18 Jun 2022 04:50:38 +0000 Received: from pps.filterd (ppma03wdc.us.ibm.com [127.0.0.1]) by ppma03wdc.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 25I4ZDF2025359; Sat, 18 Jun 2022 04:50:38 GMT Received: from b03cxnp07028.gho.boulder.ibm.com (b03cxnp07028.gho.boulder.ibm.com [9.17.130.15]) by ppma03wdc.us.ibm.com with ESMTP id 3gs6b9remq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 18 Jun 2022 04:50:38 +0000 Received: from b03ledav006.gho.boulder.ibm.com (b03ledav006.gho.boulder.ibm.com [9.17.130.237]) by b03cxnp07028.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 25I4obpa31064542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 18 Jun 2022 04:50:37 GMT Received: from b03ledav006.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id F2A22C6055; Sat, 18 Jun 2022 04:50:36 +0000 (GMT) Received: from b03ledav006.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8B6BFC6059; Sat, 18 Jun 2022 04:50:36 +0000 (GMT) Received: from [9.160.110.162] (unknown [9.160.110.162]) by b03ledav006.gho.boulder.ibm.com (Postfix) with ESMTP; Sat, 18 Jun 2022 04:50:36 +0000 (GMT) Message-ID: <009c391d-3994-8755-0d22-9e80faf91f42@linux.ibm.com> Date: Fri, 17 Jun 2022 23:50:35 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Content-Language: en-US To: GCC Patches <gcc-patches@gcc.gnu.org> Subject: [PATCH] c: Handle initializations of opaque types [PR106016] Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: RL2GOeoPvXxGSVWqW7iGqDCm6NkswEWl X-Proofpoint-GUID: RL2GOeoPvXxGSVWqW7iGqDCm6NkswEWl X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.883,Hydra:6.0.517,FMLib:17.11.64.514 definitions=2022-06-18_02,2022-06-17_01,2022-02-23_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 phishscore=0 priorityscore=1501 clxscore=1015 impostorscore=0 lowpriorityscore=0 malwarescore=0 mlxlogscore=999 spamscore=0 suspectscore=0 bulkscore=0 adultscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2204290000 definitions=main-2206180021 X-Spam-Status: No, score=-10.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, GIT_PATCH_0, 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 <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> From: Peter Bergner via Gcc-patches <gcc-patches@gcc.gnu.org> Reply-To: Peter Bergner <bergner@linux.ibm.com> Cc: Segher Boessenkool <segher@kernel.crashing.org> Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> |
Series |
c: Handle initializations of opaque types [PR106016]
|
|
Commit Message
Peter Bergner
June 18, 2022, 4:50 a.m. UTC
The initial commit that added opaque types thought that there couldn't be any valid initializations for variables of these types, but the test case in the bug report shows that isn't true. The solution is to handle OPAQUE_TYPE initializations just like the other scalar types. This passed bootstrap and regtesting with no regressions on powerpc64le-linux. Ok for trunk? This is an issue in GCC 12 and 11 too. Ok for the release branches after some burn-in on trunk? Peter gcc/ PR c/106016 * expr.cc (count_type_elements): Handle OPAQUE_TYPE. gcc/testsuite/ PR c/106016 * gcc.target/powerpc/pr106016.c: New test.
Comments
Hi Peter, On Fri, Jun 17, 2022 at 11:50:35PM -0500, Peter Bergner wrote: > The initial commit that added opaque types thought that there couldn't > be any valid initializations for variables of these types, but the test > case in the bug report shows that isn't true. The solution is to handle > OPAQUE_TYPE initializations just like the other scalar types. > > This passed bootstrap and regtesting with no regressions on powerpc64le-linux. > Ok for trunk? This is an issue in GCC 12 and 11 too. Ok for the release > branches after some burn-in on trunk? > > Peter > > gcc/ > PR c/106016 > * expr.cc (count_type_elements): Handle OPAQUE_TYPE. > > gcc/testsuite/ > PR c/106016 > * gcc.target/powerpc/pr106016.c: New test. The testcase is fine everywhere. Thanks! Segher
I'd like to ping the following patch. Segher has approved the test case change, so I just need a review for the expr.cc change. Peter Message-ID: <009c391d-3994-8755-0d22-9e80faf91f42@linux.ibm.com> Date: Fri, 17 Jun 2022 23:50:35 -0500 To: GCC Patches <gcc-patches@gcc.gnu.org> Subject: [PATCH] c: Handle initializations of opaque types [PR106016] On 6/17/22 11:50 PM, Peter Bergner via Gcc-patches wrote: > The initial commit that added opaque types thought that there couldn't > be any valid initializations for variables of these types, but the test > case in the bug report shows that isn't true. The solution is to handle > OPAQUE_TYPE initializations just like the other scalar types. > > This passed bootstrap and regtesting with no regressions on powerpc64le-linux. > Ok for trunk? This is an issue in GCC 12 and 11 too. Ok for the release > branches after some burn-in on trunk? > > Peter > > gcc/ > PR c/106016 > * expr.cc (count_type_elements): Handle OPAQUE_TYPE. > > gcc/testsuite/ > PR c/106016 > * gcc.target/powerpc/pr106016.c: New test. > > diff --git a/gcc/expr.cc b/gcc/expr.cc > index 78c839ab425..1675198a146 100644 > --- a/gcc/expr.cc > +++ b/gcc/expr.cc > @@ -6423,13 +6423,13 @@ count_type_elements (const_tree type, bool for_ctor_p) > case OFFSET_TYPE: > case REFERENCE_TYPE: > case NULLPTR_TYPE: > + case OPAQUE_TYPE: > return 1; > > case ERROR_MARK: > return 0; > > case VOID_TYPE: > - case OPAQUE_TYPE: > case METHOD_TYPE: > case FUNCTION_TYPE: > case LANG_TYPE: > diff --git a/gcc/testsuite/gcc.target/powerpc/pr106016.c b/gcc/testsuite/gcc.target/powerpc/pr106016.c > new file mode 100644 > index 00000000000..3db8345dcc6 > --- /dev/null > +++ b/gcc/testsuite/gcc.target/powerpc/pr106016.c > @@ -0,0 +1,14 @@ > +/* PR target/106016 */ > +/* { dg-require-effective-target power10_ok } */ > +/* { dg-options "-O2 -mdejagnu-cpu=power10" } */ > + > +/* Make sure we do not ICE on the following test case. */ > + > +extern void bar (__vector_quad *); > + > +void > +foo (__vector_quad *a, __vector_quad *b) > +{ > + __vector_quad arr[2] = {*a, *b}; > + bar (&arr[0]); > +}
On Tue, Jul 26, 2022 at 12:46 AM Peter Bergner via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > > I'd like to ping the following patch. Segher has approved the > test case change, so I just need a review for the expr.cc change. > > Peter > > > > Message-ID: <009c391d-3994-8755-0d22-9e80faf91f42@linux.ibm.com> > Date: Fri, 17 Jun 2022 23:50:35 -0500 > To: GCC Patches <gcc-patches@gcc.gnu.org> > Subject: [PATCH] c: Handle initializations of opaque types [PR106016] > > > On 6/17/22 11:50 PM, Peter Bergner via Gcc-patches wrote: > > The initial commit that added opaque types thought that there couldn't > > be any valid initializations for variables of these types, but the test > > case in the bug report shows that isn't true. The solution is to handle > > OPAQUE_TYPE initializations just like the other scalar types. > > > > This passed bootstrap and regtesting with no regressions on powerpc64le-linux. > > Ok for trunk? This is an issue in GCC 12 and 11 too. Ok for the release > > branches after some burn-in on trunk? OK. Richard. > > Peter > > > > gcc/ > > PR c/106016 > > * expr.cc (count_type_elements): Handle OPAQUE_TYPE. > > > > gcc/testsuite/ > > PR c/106016 > > * gcc.target/powerpc/pr106016.c: New test. > > > > diff --git a/gcc/expr.cc b/gcc/expr.cc > > index 78c839ab425..1675198a146 100644 > > --- a/gcc/expr.cc > > +++ b/gcc/expr.cc > > @@ -6423,13 +6423,13 @@ count_type_elements (const_tree type, bool for_ctor_p) > > case OFFSET_TYPE: > > case REFERENCE_TYPE: > > case NULLPTR_TYPE: > > + case OPAQUE_TYPE: > > return 1; > > > > case ERROR_MARK: > > return 0; > > > > case VOID_TYPE: > > - case OPAQUE_TYPE: > > case METHOD_TYPE: > > case FUNCTION_TYPE: > > case LANG_TYPE: > > diff --git a/gcc/testsuite/gcc.target/powerpc/pr106016.c b/gcc/testsuite/gcc.target/powerpc/pr106016.c > > new file mode 100644 > > index 00000000000..3db8345dcc6 > > --- /dev/null > > +++ b/gcc/testsuite/gcc.target/powerpc/pr106016.c > > @@ -0,0 +1,14 @@ > > +/* PR target/106016 */ > > +/* { dg-require-effective-target power10_ok } */ > > +/* { dg-options "-O2 -mdejagnu-cpu=power10" } */ > > + > > +/* Make sure we do not ICE on the following test case. */ > > + > > +extern void bar (__vector_quad *); > > + > > +void > > +foo (__vector_quad *a, __vector_quad *b) > > +{ > > + __vector_quad arr[2] = {*a, *b}; > > + bar (&arr[0]); > > +} >
On 7/26/22 1:57 AM, Richard Biener via Gcc-patches wrote: >> On 6/17/22 11:50 PM, Peter Bergner via Gcc-patches wrote: >>> The initial commit that added opaque types thought that there couldn't >>> be any valid initializations for variables of these types, but the test >>> case in the bug report shows that isn't true. The solution is to handle >>> OPAQUE_TYPE initializations just like the other scalar types. >>> >>> This passed bootstrap and regtesting with no regressions on powerpc64le-linux. >>> Ok for trunk? This is an issue in GCC 12 and 11 too. Ok for the release >>> branches after some burn-in on trunk? > > OK. Ok, pushed to trunk. I'll push the backports after a little burn-in on trunk. Thanks! Peter
diff --git a/gcc/expr.cc b/gcc/expr.cc index 78c839ab425..1675198a146 100644 --- a/gcc/expr.cc +++ b/gcc/expr.cc @@ -6423,13 +6423,13 @@ count_type_elements (const_tree type, bool for_ctor_p) case OFFSET_TYPE: case REFERENCE_TYPE: case NULLPTR_TYPE: + case OPAQUE_TYPE: return 1; case ERROR_MARK: return 0; case VOID_TYPE: - case OPAQUE_TYPE: case METHOD_TYPE: case FUNCTION_TYPE: case LANG_TYPE: diff --git a/gcc/testsuite/gcc.target/powerpc/pr106016.c b/gcc/testsuite/gcc.target/powerpc/pr106016.c new file mode 100644 index 00000000000..3db8345dcc6 --- /dev/null +++ b/gcc/testsuite/gcc.target/powerpc/pr106016.c @@ -0,0 +1,14 @@ +/* PR target/106016 */ +/* { dg-require-effective-target power10_ok } */ +/* { dg-options "-O2 -mdejagnu-cpu=power10" } */ + +/* Make sure we do not ICE on the following test case. */ + +extern void bar (__vector_quad *); + +void +foo (__vector_quad *a, __vector_quad *b) +{ + __vector_quad arr[2] = {*a, *b}; + bar (&arr[0]); +}