* [PATCH] c++: ICE with constexpr lambda [PR107280] @ 2023-03-10 16:17 Marek Polacek 2023-03-10 18:47 ` Jason Merrill 0 siblings, 1 reply; 5+ messages in thread From: Marek Polacek @ 2023-03-10 16:17 UTC (permalink / raw) To: GCC Patches, Jason Merrill We crash here since r10-3661, the store_init_value hunk in particular. Before, we called cp_fully_fold_init, so e.g. {.str=VIEW_CONVERT_EXPR<char[8]>("")} was folded into {.str=""} but now we don't fold and keep the VCE around, and it causes trouble in cxx_eval_store_expression: in the !refs->is_empty () loop we descend on .str's initializer but since it's wrapped in a VCE, we skip the STRING_CST check and then crash on the CONSTRUCTOR_NO_CLEARING. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/12? PR c++/107280 gcc/cp/ChangeLog: * constexpr.cc (cxx_eval_store_expression): Strip location wrappers. gcc/testsuite/ChangeLog: * g++.dg/cpp1z/constexpr-lambda28.C: New test. --- gcc/cp/constexpr.cc | 3 ++- gcc/testsuite/g++.dg/cpp1z/constexpr-lambda28.C | 15 +++++++++++++++ 2 files changed, 17 insertions(+), 1 deletion(-) create mode 100644 gcc/testsuite/g++.dg/cpp1z/constexpr-lambda28.C diff --git a/gcc/cp/constexpr.cc b/gcc/cp/constexpr.cc index 8683c00596a..abf6ee560c5 100644 --- a/gcc/cp/constexpr.cc +++ b/gcc/cp/constexpr.cc @@ -6033,7 +6033,8 @@ cxx_eval_store_expression (const constexpr_ctx *ctx, tree t, *valp = build_constructor (type, NULL); CONSTRUCTOR_NO_CLEARING (*valp) = no_zero_init; } - else if (TREE_CODE (*valp) == STRING_CST) + else if (STRIP_ANY_LOCATION_WRAPPER (*valp), + TREE_CODE (*valp) == STRING_CST) { /* An array was initialized with a string constant, and now we're writing into one of its elements. Explode the diff --git a/gcc/testsuite/g++.dg/cpp1z/constexpr-lambda28.C b/gcc/testsuite/g++.dg/cpp1z/constexpr-lambda28.C new file mode 100644 index 00000000000..aafbfddd8b9 --- /dev/null +++ b/gcc/testsuite/g++.dg/cpp1z/constexpr-lambda28.C @@ -0,0 +1,15 @@ +// PR c++/107280 +// { dg-do compile { target c++17 } } + +struct string { + char str[8] = ""; +}; +template <int, int> constexpr void +test () +{ + string str{}; + auto append = [&](const char *s) { *str.str = *s; }; + append(""); +} + +static_assert ((test<true, true>(), true), ""); base-commit: 2b2340e236c0bba8aaca358ea25a5accd8249fbd -- 2.39.2 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] c++: ICE with constexpr lambda [PR107280] 2023-03-10 16:17 [PATCH] c++: ICE with constexpr lambda [PR107280] Marek Polacek @ 2023-03-10 18:47 ` Jason Merrill 2023-03-15 14:37 ` [PATCH v2] " Marek Polacek 0 siblings, 1 reply; 5+ messages in thread From: Jason Merrill @ 2023-03-10 18:47 UTC (permalink / raw) To: Marek Polacek, GCC Patches On 3/10/23 11:17, Marek Polacek wrote: > We crash here since r10-3661, the store_init_value hunk in particular. > Before, we called cp_fully_fold_init, so e.g. > > {.str=VIEW_CONVERT_EXPR<char[8]>("")} > > was folded into > > {.str=""} > > but now we don't fold and keep the VCE around, and it causes trouble in > cxx_eval_store_expression: in the !refs->is_empty () loop we descend on > .str's initializer but since it's wrapped in a VCE, we skip the STRING_CST > check and then crash on the CONSTRUCTOR_NO_CLEARING. > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/12? > > PR c++/107280 > > gcc/cp/ChangeLog: > > * constexpr.cc (cxx_eval_store_expression): Strip location wrappers. > > gcc/testsuite/ChangeLog: > > * g++.dg/cpp1z/constexpr-lambda28.C: New test. > --- > gcc/cp/constexpr.cc | 3 ++- > gcc/testsuite/g++.dg/cpp1z/constexpr-lambda28.C | 15 +++++++++++++++ > 2 files changed, 17 insertions(+), 1 deletion(-) > create mode 100644 gcc/testsuite/g++.dg/cpp1z/constexpr-lambda28.C > > diff --git a/gcc/cp/constexpr.cc b/gcc/cp/constexpr.cc > index 8683c00596a..abf6ee560c5 100644 > --- a/gcc/cp/constexpr.cc > +++ b/gcc/cp/constexpr.cc > @@ -6033,7 +6033,8 @@ cxx_eval_store_expression (const constexpr_ctx *ctx, tree t, > *valp = build_constructor (type, NULL); > CONSTRUCTOR_NO_CLEARING (*valp) = no_zero_init; > } > - else if (TREE_CODE (*valp) == STRING_CST) > + else if (STRIP_ANY_LOCATION_WRAPPER (*valp), > + TREE_CODE (*valp) == STRING_CST) Seems like this is stripping the location wrapper when we try to modify the string; I think we want to strip it earlier, when we first initialize the array member. Jason ^ permalink raw reply [flat|nested] 5+ messages in thread
* [PATCH v2] c++: ICE with constexpr lambda [PR107280] 2023-03-10 18:47 ` Jason Merrill @ 2023-03-15 14:37 ` Marek Polacek 2023-03-15 16:48 ` Jason Merrill 0 siblings, 1 reply; 5+ messages in thread From: Marek Polacek @ 2023-03-15 14:37 UTC (permalink / raw) To: Jason Merrill; +Cc: GCC Patches On Fri, Mar 10, 2023 at 01:47:46PM -0500, Jason Merrill wrote: > On 3/10/23 11:17, Marek Polacek wrote: > > We crash here since r10-3661, the store_init_value hunk in particular. > > Before, we called cp_fully_fold_init, so e.g. > > > > {.str=VIEW_CONVERT_EXPR<char[8]>("")} > > > > was folded into > > > > {.str=""} > > > > but now we don't fold and keep the VCE around, and it causes trouble in > > cxx_eval_store_expression: in the !refs->is_empty () loop we descend on > > .str's initializer but since it's wrapped in a VCE, we skip the STRING_CST > > check and then crash on the CONSTRUCTOR_NO_CLEARING. > > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/12? > > > > PR c++/107280 > > > > gcc/cp/ChangeLog: > > > > * constexpr.cc (cxx_eval_store_expression): Strip location wrappers. > > > > gcc/testsuite/ChangeLog: > > > > * g++.dg/cpp1z/constexpr-lambda28.C: New test. > > --- > > gcc/cp/constexpr.cc | 3 ++- > > gcc/testsuite/g++.dg/cpp1z/constexpr-lambda28.C | 15 +++++++++++++++ > > 2 files changed, 17 insertions(+), 1 deletion(-) > > create mode 100644 gcc/testsuite/g++.dg/cpp1z/constexpr-lambda28.C > > > > diff --git a/gcc/cp/constexpr.cc b/gcc/cp/constexpr.cc > > index 8683c00596a..abf6ee560c5 100644 > > --- a/gcc/cp/constexpr.cc > > +++ b/gcc/cp/constexpr.cc > > @@ -6033,7 +6033,8 @@ cxx_eval_store_expression (const constexpr_ctx *ctx, tree t, > > *valp = build_constructor (type, NULL); > > CONSTRUCTOR_NO_CLEARING (*valp) = no_zero_init; > > } > > - else if (TREE_CODE (*valp) == STRING_CST) > > + else if (STRIP_ANY_LOCATION_WRAPPER (*valp), > > + TREE_CODE (*valp) == STRING_CST) > > Seems like this is stripping the location wrapper when we try to modify the > string; I think we want to strip it earlier, when we first initialize the > array member. Hmm, I suppose we don't want to do the stripping too early. I could have put it in get_nsdmi, for instance, but maybe here is good as well? Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- We crash here since r10-3661, the store_init_value hunk in particular. Before, we called cp_fully_fold_init, so e.g. {.str=VIEW_CONVERT_EXPR<char[8]>("")} was folded into {.str=""} but now we don't fold and keep the VCE around, and it causes trouble in cxx_eval_store_expression: in the !refs->is_empty () loop we descend on .str's initializer but since it's wrapped in a VCE, we skip the STRING_CST check and then crash on the CONSTRUCTOR_NO_CLEARING. PR c++/107280 gcc/cp/ChangeLog: * typeck2.cc (process_init_constructor_record): Strip location wrappers. gcc/testsuite/ChangeLog: * g++.dg/cpp1z/constexpr-lambda28.C: New test. --- gcc/cp/typeck2.cc | 1 + gcc/testsuite/g++.dg/cpp1z/constexpr-lambda28.C | 15 +++++++++++++++ 2 files changed, 16 insertions(+) create mode 100644 gcc/testsuite/g++.dg/cpp1z/constexpr-lambda28.C diff --git a/gcc/cp/typeck2.cc b/gcc/cp/typeck2.cc index c56b69164e2..d0984910ce4 100644 --- a/gcc/cp/typeck2.cc +++ b/gcc/cp/typeck2.cc @@ -1889,6 +1889,7 @@ process_init_constructor_record (tree type, tree init, int nested, int flags, CONSTRUCTOR_PLACEHOLDER_BOUNDARY (init) = 1; CONSTRUCTOR_PLACEHOLDER_BOUNDARY (next) = 0; } + STRIP_ANY_LOCATION_WRAPPER (next); CONSTRUCTOR_APPEND_ELT (v, field, next); } diff --git a/gcc/testsuite/g++.dg/cpp1z/constexpr-lambda28.C b/gcc/testsuite/g++.dg/cpp1z/constexpr-lambda28.C new file mode 100644 index 00000000000..aafbfddd8b9 --- /dev/null +++ b/gcc/testsuite/g++.dg/cpp1z/constexpr-lambda28.C @@ -0,0 +1,15 @@ +// PR c++/107280 +// { dg-do compile { target c++17 } } + +struct string { + char str[8] = ""; +}; +template <int, int> constexpr void +test () +{ + string str{}; + auto append = [&](const char *s) { *str.str = *s; }; + append(""); +} + +static_assert ((test<true, true>(), true), ""); base-commit: 40c1352c5a4530350012d6a922435cf491663daa -- 2.39.2 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v2] c++: ICE with constexpr lambda [PR107280] 2023-03-15 14:37 ` [PATCH v2] " Marek Polacek @ 2023-03-15 16:48 ` Jason Merrill 2023-03-15 18:20 ` Marek Polacek 0 siblings, 1 reply; 5+ messages in thread From: Jason Merrill @ 2023-03-15 16:48 UTC (permalink / raw) To: Marek Polacek; +Cc: GCC Patches On 3/15/23 10:37, Marek Polacek wrote: > On Fri, Mar 10, 2023 at 01:47:46PM -0500, Jason Merrill wrote: >> On 3/10/23 11:17, Marek Polacek wrote: >>> We crash here since r10-3661, the store_init_value hunk in particular. >>> Before, we called cp_fully_fold_init, so e.g. >>> >>> {.str=VIEW_CONVERT_EXPR<char[8]>("")} >>> >>> was folded into >>> >>> {.str=""} >>> >>> but now we don't fold and keep the VCE around, and it causes trouble in >>> cxx_eval_store_expression: in the !refs->is_empty () loop we descend on >>> .str's initializer but since it's wrapped in a VCE, we skip the STRING_CST >>> check and then crash on the CONSTRUCTOR_NO_CLEARING. >>> >>> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/12? >>> >>> PR c++/107280 >>> >>> gcc/cp/ChangeLog: >>> >>> * constexpr.cc (cxx_eval_store_expression): Strip location wrappers. >>> >>> gcc/testsuite/ChangeLog: >>> >>> * g++.dg/cpp1z/constexpr-lambda28.C: New test. >>> --- >>> gcc/cp/constexpr.cc | 3 ++- >>> gcc/testsuite/g++.dg/cpp1z/constexpr-lambda28.C | 15 +++++++++++++++ >>> 2 files changed, 17 insertions(+), 1 deletion(-) >>> create mode 100644 gcc/testsuite/g++.dg/cpp1z/constexpr-lambda28.C >>> >>> diff --git a/gcc/cp/constexpr.cc b/gcc/cp/constexpr.cc >>> index 8683c00596a..abf6ee560c5 100644 >>> --- a/gcc/cp/constexpr.cc >>> +++ b/gcc/cp/constexpr.cc >>> @@ -6033,7 +6033,8 @@ cxx_eval_store_expression (const constexpr_ctx *ctx, tree t, >>> *valp = build_constructor (type, NULL); >>> CONSTRUCTOR_NO_CLEARING (*valp) = no_zero_init; >>> } >>> - else if (TREE_CODE (*valp) == STRING_CST) >>> + else if (STRIP_ANY_LOCATION_WRAPPER (*valp), >>> + TREE_CODE (*valp) == STRING_CST) >> >> Seems like this is stripping the location wrapper when we try to modify the >> string; I think we want to strip it earlier, when we first initialize the >> array member. > > Hmm, I suppose we don't want to do the stripping too early. I could > have put it in get_nsdmi, for instance, but maybe here is good as well? I guess I was thinking more around the time when the value is imported into constant evaluation, i.e. this chunk of cxx_eval_constant_expression: > if (tree init = DECL_INITIAL (r)) > { > init = cxx_eval_constant_expression (ctx, init, vc_prvalue, > non_constant_p, overflow_p); > /* Don't share a CONSTRUCTOR that might be changed. */ > init = unshare_constructor (init); > /* Remember that a constant object's constructor has already > run. */ > if (CLASS_TYPE_P (TREE_TYPE (r)) > && CP_TYPE_CONST_P (TREE_TYPE (r))) > TREE_READONLY (init) = true; > ctx->global->put_value (r, init); > } Feel free to pursue that approach or go ahead and push your first patch, whichever you prefer. Jason ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v2] c++: ICE with constexpr lambda [PR107280] 2023-03-15 16:48 ` Jason Merrill @ 2023-03-15 18:20 ` Marek Polacek 0 siblings, 0 replies; 5+ messages in thread From: Marek Polacek @ 2023-03-15 18:20 UTC (permalink / raw) To: Jason Merrill; +Cc: GCC Patches On Wed, Mar 15, 2023 at 12:48:27PM -0400, Jason Merrill wrote: > On 3/15/23 10:37, Marek Polacek wrote: > > On Fri, Mar 10, 2023 at 01:47:46PM -0500, Jason Merrill wrote: > > > On 3/10/23 11:17, Marek Polacek wrote: > > > > We crash here since r10-3661, the store_init_value hunk in particular. > > > > Before, we called cp_fully_fold_init, so e.g. > > > > > > > > {.str=VIEW_CONVERT_EXPR<char[8]>("")} > > > > > > > > was folded into > > > > > > > > {.str=""} > > > > > > > > but now we don't fold and keep the VCE around, and it causes trouble in > > > > cxx_eval_store_expression: in the !refs->is_empty () loop we descend on > > > > .str's initializer but since it's wrapped in a VCE, we skip the STRING_CST > > > > check and then crash on the CONSTRUCTOR_NO_CLEARING. > > > > > > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/12? > > > > > > > > PR c++/107280 > > > > > > > > gcc/cp/ChangeLog: > > > > > > > > * constexpr.cc (cxx_eval_store_expression): Strip location wrappers. > > > > > > > > gcc/testsuite/ChangeLog: > > > > > > > > * g++.dg/cpp1z/constexpr-lambda28.C: New test. > > > > --- > > > > gcc/cp/constexpr.cc | 3 ++- > > > > gcc/testsuite/g++.dg/cpp1z/constexpr-lambda28.C | 15 +++++++++++++++ > > > > 2 files changed, 17 insertions(+), 1 deletion(-) > > > > create mode 100644 gcc/testsuite/g++.dg/cpp1z/constexpr-lambda28.C > > > > > > > > diff --git a/gcc/cp/constexpr.cc b/gcc/cp/constexpr.cc > > > > index 8683c00596a..abf6ee560c5 100644 > > > > --- a/gcc/cp/constexpr.cc > > > > +++ b/gcc/cp/constexpr.cc > > > > @@ -6033,7 +6033,8 @@ cxx_eval_store_expression (const constexpr_ctx *ctx, tree t, > > > > *valp = build_constructor (type, NULL); > > > > CONSTRUCTOR_NO_CLEARING (*valp) = no_zero_init; > > > > } > > > > - else if (TREE_CODE (*valp) == STRING_CST) > > > > + else if (STRIP_ANY_LOCATION_WRAPPER (*valp), > > > > + TREE_CODE (*valp) == STRING_CST) > > > > > > Seems like this is stripping the location wrapper when we try to modify the > > > string; I think we want to strip it earlier, when we first initialize the > > > array member. > > > > Hmm, I suppose we don't want to do the stripping too early. I could > > have put it in get_nsdmi, for instance, but maybe here is good as well? > > I guess I was thinking more around the time when the value is imported into > constant evaluation, i.e. this chunk of cxx_eval_constant_expression: > > > if (tree init = DECL_INITIAL (r)) > > { > > init = cxx_eval_constant_expression (ctx, init, vc_prvalue, > > non_constant_p, overflow_p); > > /* Don't share a CONSTRUCTOR that might be changed. */ > > init = unshare_constructor (init); > > /* Remember that a constant object's constructor has already > > run. */ > > if (CLASS_TYPE_P (TREE_TYPE (r)) > > && CP_TYPE_CONST_P (TREE_TYPE (r))) > > TREE_READONLY (init) = true; > > ctx->global->put_value (r, init); > > } Ah, that wouldn't fix the problem as far as I can tell -- here init is the whole constructor: {.str=VIEW_CONVERT_EXPR<char[8]>("")} so we'd not have a way to strip the inner init. > Feel free to pursue that approach or go ahead and push your first patch, > whichever you prefer. The original patch it is, then. Thanks. Marek ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2023-03-15 18:20 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-03-10 16:17 [PATCH] c++: ICE with constexpr lambda [PR107280] Marek Polacek 2023-03-10 18:47 ` Jason Merrill 2023-03-15 14:37 ` [PATCH v2] " Marek Polacek 2023-03-15 16:48 ` Jason Merrill 2023-03-15 18:20 ` Marek Polacek
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).