[PATCH] c: Handle initializations of opaque types [PR106016]

[PATCH] c: Handle initializations of opaque types [PR106016]

[Peter Bergner]

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

Re: [PATCH] c: Handle initializations of opaque types [PR106016]

[Segher Boessenkool]

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

[PING][PATCH] c: Handle initializations of opaque types [PR106016] (need review of expr.cc hunk)

[Peter Bergner]

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

Re: [PING][PATCH] c: Handle initializations of opaque types [PR106016] (need review of expr.cc hunk)

[Richard Biener]

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

Re: [PING][PATCH] c: Handle initializations of opaque types [PR106016] (need review of expr.cc hunk)

[Peter Bergner]

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