diff mbox series

c: Handle initializations of opaque types [PR106016]

Message ID 009c391d-3994-8755-0d22-9e80faf91f42@linux.ibm.com
State New
Headers show
Series c: Handle initializations of opaque types [PR106016] | expand

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

Segher Boessenkool June 18, 2022, 2:58 p.m. UTC | #1 
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
Peter Bergner July 25, 2022, 10:45 p.m. UTC | #2 
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]);
> +}
Richard Biener July 26, 2022, 6:57 a.m. UTC | #3 
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]);
> > +}
>
Peter Bergner July 26, 2022, 3:07 p.m. UTC | #4 
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 mbox series

Patch

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]);
+}