[PATCH] c++: Handle RANGE_EXPR indexes in init_subob_ctx [PR97328]
Patrick Palka
ppalka@redhat.com
Wed Oct 21 21:46:38 GMT 2020
On Wed, 21 Oct 2020, Jason Merrill wrote:
> On 10/8/20 4:47 PM, Patrick Palka wrote:
> > In the testcase below, we're ICEing during constexpr evaluation of the
> > CONSTRUCTOR {.data={{}, [1 ... 7]={}}} of type 'vector'. The apparently
> > unique thing about this CONSTRUCTOR is that it has a RANGE_EXPR index
> > whose corresponding sub-aggregate initializer doesn't satisfy
> > reduced_constant_expression_p (because its field 't' is uninitialized).
> >
> > This is a problem because init_subob_ctx currently punts if the
> > constructor index is a RANGE_EXPR, so when cxx_eval_bare_aggregate
> > recurses into this sub-aggregate initializer we trip over the
> > same_type_p assert in verify_ctor_sanity.
> >
> > Fix this by making init_subob_ctx set up an appropriate sub-aggregate
> > initialization context even when the index is a RANGE_EXPR.
> >
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> > trunk and the 10 branch?
> >
> > gcc/cp/ChangeLog:
> >
> > PR c++/97328
> > * constexpr.c (init_subob_ctx): Don't punt if the index is a
> > RANGE_EXPR, instead build a sub-aggregate initialization context
> > with no subobject.
> >
> > gcc/testsuite/ChangeLog:
> >
> > PR c++/97328
> > * g++.dg/cpp2a/constexpr-init19.C: New test.
> > * g++.dg/cpp2a/constexpr-init20.C: New test.
> > ---
> > gcc/cp/constexpr.c | 13 +++++++------
> > gcc/testsuite/g++.dg/cpp2a/constexpr-init19.C | 15 +++++++++++++++
> > gcc/testsuite/g++.dg/cpp2a/constexpr-init20.C | 15 +++++++++++++++
> > 3 files changed, 37 insertions(+), 6 deletions(-)
> > create mode 100644 gcc/testsuite/g++.dg/cpp2a/constexpr-init19.C
> > create mode 100644 gcc/testsuite/g++.dg/cpp2a/constexpr-init20.C
> >
> > diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
> > index a118f8a810b..e50a2a220cb 100644
> > --- a/gcc/cp/constexpr.c
> > +++ b/gcc/cp/constexpr.c
> > @@ -3953,11 +3953,6 @@ init_subob_ctx (const constexpr_ctx *ctx,
> > constexpr_ctx &new_ctx,
> > {
> > new_ctx = *ctx;
> > - if (index && TREE_CODE (index) != INTEGER_CST
> > - && TREE_CODE (index) != FIELD_DECL)
> > - /* This won't have an element in the new CONSTRUCTOR. */
> > - return;
>
> Hmm, I wonder what this was trying to exclude? I'd be more comfortable adding
> RANGE_EXPR to the allowed index codes.
Ah, it's probably COMPONENT_REF, NOP_EXPR and/or POINTER_PLUS_EXPR.
I missed that cxx_eval_bare_aggregate explicitly checks for such
indexes.
Here's a patch which refines the above check rather than removing it
entirely. Does it look OK for 10/trunk after testing?
-- >8 --
Subject: [PATCH] c++: Handle RANGE_EXPR index in init_subob_ctx [PR97328]
In the testcase below, we're ICEing during constexpr evaluation of the
CONSTRUCTOR {.data={{}, [1 ... 7]={}}} of type 'vector'. The interesting
thing about this CONSTRUCTOR is that it has a RANGE_EXPR index for an
element initializer which doesn't satisfy reduced_constant_expression_p
(because the field 't' is uninitialized).
This is a problem because init_subob_ctx currently punts on setting up a
sub-aggregate initialization context when given a RANGE_EXPR index, so
we later trip over the asserts in verify_ctor_sanity when recursing into
cxx_eval_bare_aggregate on this element initializer.
Fix this by making init_subob_ctx set up an appropriate initialization
context when given a RANGE_EXPR index.
gcc/cp/ChangeLog:
PR c++/97328
* constexpr.c (init_subob_ctx): Don't punt on RANGE_EXPR
indexes, instead build a sub-aggregate initialization context
with no subobject.
gcc/testsuite/ChangeLog:
PR c++/97328
* g++.dg/cpp2a/constexpr-init19.C: New test.
* g++.dg/cpp2a/constexpr-init20.C: New test.
---
gcc/cp/constexpr.c | 11 +++++++++--
gcc/testsuite/g++.dg/cpp2a/constexpr-init19.C | 15 +++++++++++++++
gcc/testsuite/g++.dg/cpp2a/constexpr-init20.C | 15 +++++++++++++++
3 files changed, 39 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/cpp2a/constexpr-init19.C
create mode 100644 gcc/testsuite/g++.dg/cpp2a/constexpr-init20.C
diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index a118f8a810b..cb3c787094c 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -3954,7 +3954,8 @@ init_subob_ctx (const constexpr_ctx *ctx, constexpr_ctx &new_ctx,
new_ctx = *ctx;
if (index && TREE_CODE (index) != INTEGER_CST
- && TREE_CODE (index) != FIELD_DECL)
+ && TREE_CODE (index) != FIELD_DECL
+ && TREE_CODE (index) != RANGE_EXPR)
/* This won't have an element in the new CONSTRUCTOR. */
return;
@@ -3967,7 +3968,13 @@ init_subob_ctx (const constexpr_ctx *ctx, constexpr_ctx &new_ctx,
update object to refer to the subobject and ctor to refer to
the (newly created) sub-initializer. */
if (ctx->object)
- new_ctx.object = build_ctor_subob_ref (index, type, ctx->object);
+ {
+ if (index == NULL_TREE || TREE_CODE (index) == RANGE_EXPR)
+ /* There's no well-defined subobject for this index. */
+ new_ctx.object = NULL_TREE;
+ else
+ new_ctx.object = build_ctor_subob_ref (index, type, ctx->object);
+ }
tree elt = build_constructor (type, NULL);
CONSTRUCTOR_NO_CLEARING (elt) = true;
new_ctx.ctor = elt;
diff --git a/gcc/testsuite/g++.dg/cpp2a/constexpr-init19.C b/gcc/testsuite/g++.dg/cpp2a/constexpr-init19.C
new file mode 100644
index 00000000000..d354c5ad609
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/constexpr-init19.C
@@ -0,0 +1,15 @@
+// PR c++/97328
+// { dg-do compile { target c++20 } }
+
+struct vector {
+ struct storage {
+ int t;
+ constexpr storage() {}
+ } data[8];
+};
+
+constexpr auto foo() {
+ vector i;
+ return i;
+}
+auto val = foo();
diff --git a/gcc/testsuite/g++.dg/cpp2a/constexpr-init20.C b/gcc/testsuite/g++.dg/cpp2a/constexpr-init20.C
new file mode 100644
index 00000000000..1a6ed8d86dd
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/constexpr-init20.C
@@ -0,0 +1,15 @@
+// PR c++/97328
+// { dg-do compile { target c++20 } }
+
+struct vector {
+ union storage {
+ int t;
+ constexpr storage() {}
+ } data[8];
+};
+
+constexpr auto foo() {
+ vector i;
+ return i;
+}
+auto val = foo();
--
2.29.0.rc0
More information about the Gcc-patches
mailing list