| Message ID | 8181e06d-2c22-845c-ec25-4254009782fd@linux.ibm.com |
|---|---|
| State | New |
| Headers | show |
| Series | c++: Treat OPAQUE_TYPE types as an aggregate type [PR97947] | expand |
On Wed, Dec 02, 2020 at 02:20:17PM -0600, Peter Bergner via Gcc-patches wrote: > My apologies for sending this a second time. I forgot to add the > mailing list to the CC list. :-( > > > c++: Treat OPAQUE_TYPE types as an aggregate type > > MODE_OPAQUE and the associated OPAQUE_TYPE were added to stop the optimizers > from knowing how the bits in a variable with an opaque type are laid out. > This makes them a kind of pseudo aggregate type and we need to treat them > as such when we process the INIT initializer for variables with an > opaque type. Just a random question, do you have some testsuite coverage for constant expression evaluation (primarily C++) with the opaque types, do you verify any object with that type is treated as something that may not appear in constant expression and does constexpr.c properly punt on it rather than ICE? Jakub
On 12/2/20 3:36 PM, Jakub Jelinek wrote: > On Wed, Dec 02, 2020 at 02:20:17PM -0600, Peter Bergner via Gcc-patches wrote: >> My apologies for sending this a second time. I forgot to add the >> mailing list to the CC list. :-( >> >> >> c++: Treat OPAQUE_TYPE types as an aggregate type >> >> MODE_OPAQUE and the associated OPAQUE_TYPE were added to stop the optimizers >> from knowing how the bits in a variable with an opaque type are laid out. >> This makes them a kind of pseudo aggregate type and we need to treat them >> as such when we process the INIT initializer for variables with an >> opaque type. > > Just a random question, do you have some testsuite coverage for constant > expression evaluation (primarily C++) with the opaque types, do you verify > any object with that type is treated as something that may not appear in > constant expression and does constexpr.c properly punt on it rather than > ICE? Yes, I'm sure many more changes are necessary for significant C++ support. But this patch is OK. Jason
On 12/2/20 3:37 PM, Jason Merrill wrote: > On 12/2/20 3:36 PM, Jakub Jelinek wrote: >> On Wed, Dec 02, 2020 at 02:20:17PM -0600, Peter Bergner via >> Gcc-patches wrote: >>> My apologies for sending this a second time. I forgot to add the >>> mailing list to the CC list. :-( >>> >>> >>> c++: Treat OPAQUE_TYPE types as an aggregate type >>> >>> MODE_OPAQUE and the associated OPAQUE_TYPE were added to stop the >>> optimizers >>> from knowing how the bits in a variable with an opaque type are laid >>> out. >>> This makes them a kind of pseudo aggregate type and we need to treat >>> them >>> as such when we process the INIT initializer for variables with an >>> opaque type. >> >> Just a random question, do you have some testsuite coverage for constant >> expression evaluation (primarily C++) with the opaque types, do you >> verify >> any object with that type is treated as something that may not appear in >> constant expression and does constexpr.c properly punt on it rather than >> ICE? > > Yes, I'm sure many more changes are necessary for significant C++ > support. But this patch is OK. Well, they ain't gonna serialize though modules :) nathan
On 12/2/20 2:36 PM, Jakub Jelinek wrote: > Just a random question, do you have some testsuite coverage for constant > expression evaluation (primarily C++) with the opaque types, do you verify > any object with that type is treated as something that may not appear in > constant expression and does constexpr.c properly punt on it rather than > ICE? We don't, since we don't support that with these specific types, but yeah, an ICE isn't as good as an error message. We'll look into adding some. Thanks. Peter
On 12/2/20 2:37 PM, Jason Merrill wrote:
> But this patch is OK.
Ok, pushed to trunk. Thanks!
Peter
diff --git a/gcc/cp/typeck2.c b/gcc/cp/typeck2.c index 721987e8502..97bb41b7d2e 100644 --- a/gcc/cp/typeck2.c +++ b/gcc/cp/typeck2.c @@ -1147,6 +1147,7 @@ digest_init_r (tree type, tree init, int nested, int flags, || VECTOR_TYPE_P (type) || code == RECORD_TYPE || code == UNION_TYPE + || code == OPAQUE_TYPE || code == COMPLEX_TYPE); /* "If T is a class type and the initializer list has a single diff --git a/gcc/testsuite/g++.target/powerpc/pr97947.C b/gcc/testsuite/g++.target/powerpc/pr97947.C new file mode 100644 index 00000000000..05ddbef2d17 --- /dev/null +++ b/gcc/testsuite/g++.target/powerpc/pr97947.C @@ -0,0 +1,12 @@ +/* PR c++/97947 */ +/* { dg-do compile } */ +/* { dg-require-effective-target power10_ok } */ +/* { dg-options "-O2 -mdejagnu-cpu=power10" } */ + +/* Verify we do not ICE on the test below. */ + +void +bug (__vector_pair *src) +{ + volatile __vector_pair dd = *src; +}