* [PATCH] c++: ICE with template code in constexpr [PR104284] @ 2022-03-10 22:04 Marek Polacek 2022-03-10 22:27 ` Marek Polacek 2022-03-11 23:46 ` Jason Merrill 0 siblings, 2 replies; 7+ messages in thread From: Marek Polacek @ 2022-03-10 22:04 UTC (permalink / raw) To: GCC Patches, Jason Merrill Since r9-6073 cxx_eval_store_expression preevaluates the value to be stored, and that revealed a crash where a template code (here, code=IMPLICIT_CONV_EXPR) leaks into cxx_eval*. It happens because we're performing build_vec_init while processing a template, which calls get_temp_regvar which creates an INIT_EXPR. This INIT_EXPR's RHS contains an rvalue conversion so we create an IMPLICIT_CONV_EXPR. Its operand is not type-dependent and the whole INIT_EXPR is not type-dependent. So we call build_non_dependent_expr which, with -fchecking=2, calls fold_non_dependent_expr. At this point the expression still has an IMPLICIT_CONV_EXPR, which ought to be handled in instantiate_non_dependent_expr_internal. However, tsubst_copy_and_build doesn't handle INIT_EXPR; it will just call tsubst_copy which does nothing when args is null. So we fail to replace the IMPLICIT_CONV_EXPR and ICE. Eliding the IMPLICIT_CONV_EXPR in this particular case would be too risky, so we could do if (TREE_CODE (t) == INIT_EXPR) t = TREE_OPERAND (t, 1); in fold_non_dependent_expr, but that feels too ad hoc. So it might make sense to actually take care of INIT_EXPR in tsubst_c_and_b. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/11? PR c++/104284 gcc/cp/ChangeLog: * pt.cc (tsubst_copy_and_build): Handle INIT_EXPR. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/constexpr-104284.C: New test. --- gcc/cp/pt.cc | 8 ++++++++ gcc/testsuite/g++.dg/cpp1y/constexpr-104284.C | 17 +++++++++++++++++ 2 files changed, 25 insertions(+) create mode 100644 gcc/testsuite/g++.dg/cpp1y/constexpr-104284.C diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc index f7ee33a6dfd..e8920f98e4d 100644 --- a/gcc/cp/pt.cc +++ b/gcc/cp/pt.cc @@ -21289,6 +21289,14 @@ tsubst_copy_and_build (tree t, with constant operands. */ RETURN (t); + case INIT_EXPR: + { + tree op0 = RECUR (TREE_OPERAND (t, 0)); + tree op1 = RECUR (TREE_OPERAND (t, 1)); + RETURN (build2_loc (input_location, INIT_EXPR, TREE_TYPE (op0), + op0, op1)); + } + case NON_LVALUE_EXPR: case VIEW_CONVERT_EXPR: if (location_wrapper_p (t)) diff --git a/gcc/testsuite/g++.dg/cpp1y/constexpr-104284.C b/gcc/testsuite/g++.dg/cpp1y/constexpr-104284.C new file mode 100644 index 00000000000..f60033069e4 --- /dev/null +++ b/gcc/testsuite/g++.dg/cpp1y/constexpr-104284.C @@ -0,0 +1,17 @@ +// PR c++/104284 +// { dg-do compile { target c++14 } } +// { dg-additional-options "-fchecking=2" } + +struct S { + char c{}; +}; + +auto x = [](auto) { constexpr S s[]{{}}; }; + +template<class> +constexpr void gn () +{ + constexpr S s[]{{}}; +} + +static_assert ((gn<int>(), true), ""); base-commit: b5417a0ba7e26bec2abf05cad6c6ef840a9be41c -- 2.35.1 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] c++: ICE with template code in constexpr [PR104284] 2022-03-10 22:04 [PATCH] c++: ICE with template code in constexpr [PR104284] Marek Polacek @ 2022-03-10 22:27 ` Marek Polacek 2022-03-11 23:46 ` Jason Merrill 1 sibling, 0 replies; 7+ messages in thread From: Marek Polacek @ 2022-03-10 22:27 UTC (permalink / raw) To: GCC Patches, Jason Merrill On Thu, Mar 10, 2022 at 05:04:59PM -0500, Marek Polacek via Gcc-patches wrote: > Since r9-6073 cxx_eval_store_expression preevaluates the value to > be stored, and that revealed a crash where a template code (here, > code=IMPLICIT_CONV_EXPR) leaks into cxx_eval*. > > It happens because we're performing build_vec_init while processing > a template, which calls get_temp_regvar which creates an INIT_EXPR. > This INIT_EXPR's RHS contains an rvalue conversion so we create an > IMPLICIT_CONV_EXPR. Its operand is not type-dependent and the whole > INIT_EXPR is not type-dependent. So we call build_non_dependent_expr > which, with -fchecking=2, calls fold_non_dependent_expr. At this > point the expression still has an IMPLICIT_CONV_EXPR, which ought to > be handled in instantiate_non_dependent_expr_internal. However, > tsubst_copy_and_build doesn't handle INIT_EXPR; it will just call > tsubst_copy which does nothing when args is null. So we fail to > replace the IMPLICIT_CONV_EXPR and ICE. Forgot to mention: without -fchecking=2 there's no problem because digest_init will subst the IMPLICIT_CONV_EXPR: #0 tsubst_copy_and_build (t=<implicit_conv_expr 0x7fffea4a9f20>, args=<tree 0x0>, complain=3, in_decl=<tree 0x0>, function_p=false, integral_constant_expression_p=true) at /home/mpolacek/src/gcc/gcc/cp/pt.cc:20063 #1 0x0000000000de1ae1 in instantiate_non_dependent_expr_internal (expr=<implicit_conv_expr 0x7fffea4a9f20>, complain=3) at /home/mpolacek/src/gcc/gcc/cp/pt.cc:6358 #2 0x0000000000b702d4 in fold_non_dependent_expr_template (t=<implicit_conv_expr 0x7fffea4a9f20>, complain=3, manifestly_const_eval=false, object=<tree 0x0>) at /home/mpolacek/src/gcc/gcc/cp/constexpr.cc:8050 #3 0x0000000000b706f0 in fold_non_dependent_init (t=<implicit_conv_expr 0x7fffea4a9f20>, complain=3, manifestly_const_eval=false, object=<tree 0x0>) at /home/mpolacek/src/gcc/gcc/cp/constexpr.cc:8143 #4 0x0000000000f08f4f in massage_init_elt (type=<record_type 0x7fffea4b29d8 S>, init=<implicit_conv_expr 0x7fffea4a9f20>, nested=0, flags=257, complain=3) at /home/mpolacek/src/gcc/gcc/cp/typeck2.cc:1437 #5 0x0000000000f0949c in process_init_constructor_array (type=<array_type 0x7fffea4c9348>, init=<constructor 0x7fffea4bfb10>, nested=0, flags=257, complain=3) at /home/mpolacek/src/gcc/gcc/cp/typeck2.cc:1502 #6 0x0000000000f0aec1 in process_init_constructor (type=<array_type 0x7fffea4c9348>, init=<constructor 0x7fffea4bfb10>, nested=0, flags=257, complain=3) at /home/mpolacek/src/gcc/gcc/cp/typeck2.cc:1917 #7 0x0000000000f0890c in digest_init_r (type=<array_type 0x7fffea4c9348>, init=<constructor 0x7fffea4bfb10>, nested=0, flags=257, complain=3) at /home/mpolacek/src/gcc/gcc/cp/typeck2.cc:1324 #8 0x0000000000f08b1b in digest_init_flags (type=<array_type 0x7fffea4c9348>, init=<constructor 0x7fffea4bfb10>, flags=257, complain=3) at /home/mpolacek/src/gcc/gcc/cp/typeck2.cc:1370 #9 0x0000000000f06815 in store_init_value (decl=<var_decl 0x7fffea357cf0 s>, init=<constructor 0x7fffea4bfb10>, cleanups=0x7fffffffba68, flags=257) at /home/mpolacek/src/gcc/gcc/cp/typeck2.cc:842 #10 0x0000000000bf56cc in check_initializer (decl=<var_decl 0x7fffea357cf0 s>, init=<constructor 0x7fffea4bfb10>, flags=257, cleanups=0x7fffffffba68) at /home/mpolacek/src/gcc/gcc/cp/decl.cc:7337 #11 0x0000000000bfa8df in cp_finish_decl (decl=<var_decl 0x7fffea357cf0 s>, init=<constructor 0x7fffea4bfac8>, init_const_expr_p=true, asmspec_tree=<tree 0x0>, flags=1) at /home/mpolacek/src/gcc/gcc/cp/decl.cc:8174 > Eliding the IMPLICIT_CONV_EXPR in this particular case would be too > risky, so we could do > > if (TREE_CODE (t) == INIT_EXPR) > t = TREE_OPERAND (t, 1); > > in fold_non_dependent_expr, but that feels too ad hoc. So it might > make sense to actually take care of INIT_EXPR in tsubst_c_and_b. > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/11? > > PR c++/104284 > > gcc/cp/ChangeLog: > > * pt.cc (tsubst_copy_and_build): Handle INIT_EXPR. > > gcc/testsuite/ChangeLog: > > * g++.dg/cpp1y/constexpr-104284.C: New test. > --- > gcc/cp/pt.cc | 8 ++++++++ > gcc/testsuite/g++.dg/cpp1y/constexpr-104284.C | 17 +++++++++++++++++ > 2 files changed, 25 insertions(+) > create mode 100644 gcc/testsuite/g++.dg/cpp1y/constexpr-104284.C > > diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc > index f7ee33a6dfd..e8920f98e4d 100644 > --- a/gcc/cp/pt.cc > +++ b/gcc/cp/pt.cc > @@ -21289,6 +21289,14 @@ tsubst_copy_and_build (tree t, > with constant operands. */ > RETURN (t); > > + case INIT_EXPR: > + { > + tree op0 = RECUR (TREE_OPERAND (t, 0)); > + tree op1 = RECUR (TREE_OPERAND (t, 1)); > + RETURN (build2_loc (input_location, INIT_EXPR, TREE_TYPE (op0), > + op0, op1)); > + } > + > case NON_LVALUE_EXPR: > case VIEW_CONVERT_EXPR: > if (location_wrapper_p (t)) > diff --git a/gcc/testsuite/g++.dg/cpp1y/constexpr-104284.C b/gcc/testsuite/g++.dg/cpp1y/constexpr-104284.C > new file mode 100644 > index 00000000000..f60033069e4 > --- /dev/null > +++ b/gcc/testsuite/g++.dg/cpp1y/constexpr-104284.C > @@ -0,0 +1,17 @@ > +// PR c++/104284 > +// { dg-do compile { target c++14 } } > +// { dg-additional-options "-fchecking=2" } > + > +struct S { > + char c{}; > +}; > + > +auto x = [](auto) { constexpr S s[]{{}}; }; > + > +template<class> > +constexpr void gn () > +{ > + constexpr S s[]{{}}; > +} > + > +static_assert ((gn<int>(), true), ""); > > base-commit: b5417a0ba7e26bec2abf05cad6c6ef840a9be41c > -- > 2.35.1 > Marek ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] c++: ICE with template code in constexpr [PR104284] 2022-03-10 22:04 [PATCH] c++: ICE with template code in constexpr [PR104284] Marek Polacek 2022-03-10 22:27 ` Marek Polacek @ 2022-03-11 23:46 ` Jason Merrill 2022-03-18 21:55 ` [PATCH v2] " Marek Polacek 1 sibling, 1 reply; 7+ messages in thread From: Jason Merrill @ 2022-03-11 23:46 UTC (permalink / raw) To: Marek Polacek, GCC Patches On 3/10/22 18:04, Marek Polacek wrote: > Since r9-6073 cxx_eval_store_expression preevaluates the value to > be stored, and that revealed a crash where a template code (here, > code=IMPLICIT_CONV_EXPR) leaks into cxx_eval*. > > It happens because we're performing build_vec_init while processing > a template Hmm, that seems like the bug. Where's that call coming from? > which calls get_temp_regvar which creates an INIT_EXPR. > This INIT_EXPR's RHS contains an rvalue conversion so we create an > IMPLICIT_CONV_EXPR. Its operand is not type-dependent and the whole > INIT_EXPR is not type-dependent. So we call build_non_dependent_expr > which, with -fchecking=2, calls fold_non_dependent_expr. At this > point the expression still has an IMPLICIT_CONV_EXPR, which ought to > be handled in instantiate_non_dependent_expr_internal. However, > tsubst_copy_and_build doesn't handle INIT_EXPR; it will just call > tsubst_copy which does nothing when args is null. So we fail to > replace the IMPLICIT_CONV_EXPR and ICE. > > Eliding the IMPLICIT_CONV_EXPR in this particular case would be too > risky, so we could do > > if (TREE_CODE (t) == INIT_EXPR) > t = TREE_OPERAND (t, 1); > > in fold_non_dependent_expr, but that feels too ad hoc. So it might > make sense to actually take care of INIT_EXPR in tsubst_c_and_b. > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/11? > > PR c++/104284 > > gcc/cp/ChangeLog: > > * pt.cc (tsubst_copy_and_build): Handle INIT_EXPR. > > gcc/testsuite/ChangeLog: > > * g++.dg/cpp1y/constexpr-104284.C: New test. > --- > gcc/cp/pt.cc | 8 ++++++++ > gcc/testsuite/g++.dg/cpp1y/constexpr-104284.C | 17 +++++++++++++++++ > 2 files changed, 25 insertions(+) > create mode 100644 gcc/testsuite/g++.dg/cpp1y/constexpr-104284.C > > diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc > index f7ee33a6dfd..e8920f98e4d 100644 > --- a/gcc/cp/pt.cc > +++ b/gcc/cp/pt.cc > @@ -21289,6 +21289,14 @@ tsubst_copy_and_build (tree t, > with constant operands. */ > RETURN (t); > > + case INIT_EXPR: > + { > + tree op0 = RECUR (TREE_OPERAND (t, 0)); > + tree op1 = RECUR (TREE_OPERAND (t, 1)); > + RETURN (build2_loc (input_location, INIT_EXPR, TREE_TYPE (op0), > + op0, op1)); > + } > + > case NON_LVALUE_EXPR: > case VIEW_CONVERT_EXPR: > if (location_wrapper_p (t)) > diff --git a/gcc/testsuite/g++.dg/cpp1y/constexpr-104284.C b/gcc/testsuite/g++.dg/cpp1y/constexpr-104284.C > new file mode 100644 > index 00000000000..f60033069e4 > --- /dev/null > +++ b/gcc/testsuite/g++.dg/cpp1y/constexpr-104284.C > @@ -0,0 +1,17 @@ > +// PR c++/104284 > +// { dg-do compile { target c++14 } } > +// { dg-additional-options "-fchecking=2" } > + > +struct S { > + char c{}; > +}; > + > +auto x = [](auto) { constexpr S s[]{{}}; }; > + > +template<class> > +constexpr void gn () > +{ > + constexpr S s[]{{}}; > +} > + > +static_assert ((gn<int>(), true), ""); > > base-commit: b5417a0ba7e26bec2abf05cad6c6ef840a9be41c ^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH v2] c++: ICE with template code in constexpr [PR104284] 2022-03-11 23:46 ` Jason Merrill @ 2022-03-18 21:55 ` Marek Polacek 2022-03-24 15:40 ` Jason Merrill 0 siblings, 1 reply; 7+ messages in thread From: Marek Polacek @ 2022-03-18 21:55 UTC (permalink / raw) To: Jason Merrill; +Cc: GCC Patches On Fri, Mar 11, 2022 at 06:46:42PM -0500, Jason Merrill wrote: > On 3/10/22 18:04, Marek Polacek wrote: > > Since r9-6073 cxx_eval_store_expression preevaluates the value to > > be stored, and that revealed a crash where a template code (here, > > code=IMPLICIT_CONV_EXPR) leaks into cxx_eval*. > > > > It happens because we're performing build_vec_init while processing > > a template > > Hmm, that seems like the bug. Where's that call coming from? From build_aggr_init. So we're handling e.g. template<class> constexpr void g () { constexpr S s2[]{{'a'}}; } cp_finish_decl (decl=s2, init={{'a'}}) sees we're in processing_template_decl, but also that we have a constexpr var which is not dependent, nor is its initializer: else if (init && (init_const_expr_p || DECL_DECLARED_CONSTEXPR_P (decl)) && !TYPE_REF_P (type) && decl_maybe_constant_var_p (decl) && !(dep_init = value_dependent_init_p (init))) { /* This variable seems to be a non-dependent constant, so process its initializer. If check_initializer returns non-null the initialization wasn't constant after all. */ tree init_code; cleanups = make_tree_vector (); init_code = check_initializer (decl, init, flags, &cleanups); so we call check_initializer, where we go down this path: init_code = build_aggr_init_full_exprs (decl, init, flags); build_aggr_init sees that the type of 's2' is ARRAY_TYPE, so it calls build_vec_init. I now recall that we've discussed build_vec_init in a template in the past, for example in the context of c++/93676. So I agree we ought to make an effort to avoid calling build_vec_init in a template. Perhaps like this: use an INIT_EXPR. With that, we should call build_vec_init if needed while instantiating. Does that make any sense? Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- Since r9-6073 cxx_eval_store_expression preevaluates the value to be stored, and that revealed a crash where a template code (here, code=IMPLICIT_CONV_EXPR) leaks into cxx_eval*. It happens because we're performing build_vec_init while processing a template, which calls get_temp_regvar which creates an INIT_EXPR. This INIT_EXPR's RHS contains an rvalue conversion so we create an IMPLICIT_CONV_EXPR. Its operand is not type-dependent and the whole INIT_EXPR is not type-dependent. So we call build_non_dependent_expr which, with -fchecking=2, calls fold_non_dependent_expr. At this point the expression still has an IMPLICIT_CONV_EXPR, which ought to be handled in instantiate_non_dependent_expr_internal. However, tsubst_copy_and_build doesn't handle INIT_EXPR; it will just call tsubst_copy which does nothing when args is null. So we fail to replace the IMPLICIT_CONV_EXPR and ICE. The problem is that we call build_vec_init in a template in the first place. It should work to create an INIT_EXPR in a template and only perform build_vec_init when instantiating. PR c++/104284 gcc/cp/ChangeLog: * init.cc (build_aggr_init): Don't call build_vec_init in a template, create an INIT_EXPR instead. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/constexpr-104284-1.C: New test. * g++.dg/cpp1y/constexpr-104284-2.C: New test. * g++.dg/cpp1y/constexpr-104284-3.C: New test. * g++.dg/cpp1y/constexpr-104284-4.C: New test. --- gcc/cp/init.cc | 11 +++--- .../g++.dg/cpp1y/constexpr-104284-1.C | 34 ++++++++++++++++++ .../g++.dg/cpp1y/constexpr-104284-2.C | 33 +++++++++++++++++ .../g++.dg/cpp1y/constexpr-104284-3.C | 33 +++++++++++++++++ .../g++.dg/cpp1y/constexpr-104284-4.C | 35 +++++++++++++++++++ 5 files changed, 142 insertions(+), 4 deletions(-) create mode 100644 gcc/testsuite/g++.dg/cpp1y/constexpr-104284-1.C create mode 100644 gcc/testsuite/g++.dg/cpp1y/constexpr-104284-2.C create mode 100644 gcc/testsuite/g++.dg/cpp1y/constexpr-104284-3.C create mode 100644 gcc/testsuite/g++.dg/cpp1y/constexpr-104284-4.C diff --git a/gcc/cp/init.cc b/gcc/cp/init.cc index 7575597c8fd..58e66adbfe1 100644 --- a/gcc/cp/init.cc +++ b/gcc/cp/init.cc @@ -2006,10 +2006,13 @@ build_aggr_init (tree exp, tree init, int flags, tsubst_flags_t complain) } } - stmt_expr = build_vec_init (exp, NULL_TREE, init, - /*explicit_value_init_p=*/false, - from_array, - complain); + /* build_vec_init is not meant to be used in templates. */ + if (processing_template_decl) + stmt_expr = build2 (INIT_EXPR, itype, exp, init); + else + stmt_expr = build_vec_init (exp, NULL_TREE, init, + /*explicit_value_init_p=*/false, + from_array, complain); TREE_READONLY (exp) = was_const; TREE_THIS_VOLATILE (exp) = was_volatile; TREE_TYPE (exp) = type; diff --git a/gcc/testsuite/g++.dg/cpp1y/constexpr-104284-1.C b/gcc/testsuite/g++.dg/cpp1y/constexpr-104284-1.C new file mode 100644 index 00000000000..809c26a6161 --- /dev/null +++ b/gcc/testsuite/g++.dg/cpp1y/constexpr-104284-1.C @@ -0,0 +1,34 @@ +// PR c++/104284 +// { dg-do compile { target c++14 } } +// { dg-additional-options "-fchecking=2" } + +struct S { + char c{}; +}; + +auto x1 = [](auto) { constexpr S s[]{{}}; }; +auto x2 = [](auto) { constexpr S s[]{{'a'}}; }; +#if __cpp_designated_initializers >= 201707L +auto x3 = [](auto) { constexpr S s[]{{.c = 'a'}}; }; +#endif +auto x4 = [](auto) { constexpr S s[]{'a'}; }; +auto x5 = [](auto) { constexpr S s[]{{{}}}; }; + +template<class> +constexpr void g () +{ + constexpr S s1[]{{}}; + static_assert(s1[0].c == '\0', ""); + constexpr S s2[]{{'a'}}; + static_assert(s2[0].c == 'a', ""); +#if __cpp_designated_initializers >= 201707L + constexpr S s3[]{{.c = 'a'}}; + static_assert(s3[0].c == 'a', ""); +#endif + constexpr S s4[]{'a'}; + static_assert(s4[0].c == 'a', ""); + constexpr S s5[]{{{}}}; + static_assert(s5[0].c == '\0', ""); +} + +static_assert ((g<int>(), true), ""); diff --git a/gcc/testsuite/g++.dg/cpp1y/constexpr-104284-2.C b/gcc/testsuite/g++.dg/cpp1y/constexpr-104284-2.C new file mode 100644 index 00000000000..704d37de129 --- /dev/null +++ b/gcc/testsuite/g++.dg/cpp1y/constexpr-104284-2.C @@ -0,0 +1,33 @@ +// PR c++/104284 +// { dg-do compile { target c++14 } } +// { dg-additional-options "-fchecking=2" } + +struct S { + char a; + constexpr S() : a{'a'} { } + constexpr S(char a_) : a{a_} { } +}; + +auto x1 = [](auto) { constexpr S s[]{{}}; }; +auto x2 = [](auto) { constexpr S s[]{{'a'}}; }; +auto x3 = [](auto) { constexpr S s[]{'a'}; }; +auto x4 = [](auto) { constexpr S s[]{{{}}}; }; + +template<typename> +constexpr void g() +{ + constexpr S s1[]{{}}; + static_assert(s1[0].a == 'a', ""); + constexpr S s2[]{{'a'}}; + static_assert(s2[0].a == 'a', ""); + constexpr S s3[]{'a'}; + static_assert(s3[0].a == 'a', ""); + constexpr S s4[]{{{}}}; + static_assert(s4[0].a == '\0', ""); +} + +void +f () +{ + g<int>(); +} diff --git a/gcc/testsuite/g++.dg/cpp1y/constexpr-104284-3.C b/gcc/testsuite/g++.dg/cpp1y/constexpr-104284-3.C new file mode 100644 index 00000000000..6f23b255f9c --- /dev/null +++ b/gcc/testsuite/g++.dg/cpp1y/constexpr-104284-3.C @@ -0,0 +1,33 @@ +// PR c++/104284 +// { dg-do compile { target c++14 } } +// { dg-additional-options "-fchecking=2" } +// Like constexpr-104284.C, but the function template is not +// constexpr. In that case, we were still calling build_vec_init +// in a template, just not crashing. + +struct S { + char c{}; +}; + +template<class> +void g () +{ + constexpr S s1[]{{}}; + static_assert(s1[0].c == '\0', ""); + constexpr S s2[]{{'a'}}; + static_assert(s2[0].c == 'a', ""); +#if __cpp_designated_initializers >= 201707L + constexpr S s3[]{{.c = 'a'}}; + static_assert(s3[0].c == 'a', ""); +#endif + constexpr S s4[]{'a'}; + static_assert(s4[0].c == 'a', ""); + constexpr S s5[]{{{}}}; + static_assert(s5[0].c == '\0', ""); +} + +void +f () +{ + g<int>(); +} diff --git a/gcc/testsuite/g++.dg/cpp1y/constexpr-104284-4.C b/gcc/testsuite/g++.dg/cpp1y/constexpr-104284-4.C new file mode 100644 index 00000000000..a99d3255a47 --- /dev/null +++ b/gcc/testsuite/g++.dg/cpp1y/constexpr-104284-4.C @@ -0,0 +1,35 @@ +// PR c++/104284 +// { dg-do run { target c++14 } } +// { dg-additional-options "-fchecking=2" } + +struct S { + char c{}; +}; + +template<class> +constexpr void g () +{ + S s1[]{{}}; + if (s1[0].c != '\0') + __builtin_abort (); + S s2[]{{'a'}}; + if (s2[0].c != 'a') + __builtin_abort (); +#if __cpp_designated_initializers >= 201707L + S s3[]{{.c = 'a'}}; + if (s3[0].c != 'a') + __builtin_abort (); +#endif + S s4[]{'a'}; + if (s4[0].c != 'a') + __builtin_abort (); + S s5[]{{{}}}; + if (s5[0].c != '\0') + __builtin_abort (); +} + +int +main () +{ + g<int>(); +} base-commit: 0c016888ffd569c4b70722cf7df2efcc003f397b -- 2.35.1 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v2] c++: ICE with template code in constexpr [PR104284] 2022-03-18 21:55 ` [PATCH v2] " Marek Polacek @ 2022-03-24 15:40 ` Jason Merrill 2022-03-24 21:53 ` [PATCH v3] " Marek Polacek 0 siblings, 1 reply; 7+ messages in thread From: Jason Merrill @ 2022-03-24 15:40 UTC (permalink / raw) To: Marek Polacek; +Cc: GCC Patches On 3/18/22 17:55, Marek Polacek wrote: > On Fri, Mar 11, 2022 at 06:46:42PM -0500, Jason Merrill wrote: >> On 3/10/22 18:04, Marek Polacek wrote: >>> Since r9-6073 cxx_eval_store_expression preevaluates the value to >>> be stored, and that revealed a crash where a template code (here, >>> code=IMPLICIT_CONV_EXPR) leaks into cxx_eval*. >>> >>> It happens because we're performing build_vec_init while processing >>> a template >> >> Hmm, that seems like the bug. Where's that call coming from? > > From build_aggr_init. So we're handling e.g. > > template<class> > constexpr void g () { > constexpr S s2[]{{'a'}}; > } > > cp_finish_decl (decl=s2, init={{'a'}}) sees we're in processing_template_decl, > but also that we have a constexpr var which is not dependent, nor is its > initializer: > > else if (init > && (init_const_expr_p || DECL_DECLARED_CONSTEXPR_P (decl)) > && !TYPE_REF_P (type) > && decl_maybe_constant_var_p (decl) > && !(dep_init = value_dependent_init_p (init))) > { > /* This variable seems to be a non-dependent constant, so process > its initializer. If check_initializer returns non-null the > initialization wasn't constant after all. */ > tree init_code; > cleanups = make_tree_vector (); > init_code = check_initializer (decl, init, flags, &cleanups); > > so we call check_initializer, where we go down this path: > > init_code = build_aggr_init_full_exprs (decl, init, flags); > > build_aggr_init sees that the type of 's2' is ARRAY_TYPE, so it calls > build_vec_init. > > I now recall that we've discussed build_vec_init in a template in the > past, for example in the context of c++/93676. So I agree we ought to > make an effort to avoid calling build_vec_init in a template. Perhaps > like this: use an INIT_EXPR. With that, we should call build_vec_init > if needed while instantiating. Does that make any sense? Hmm. If we do that, then we get back to > if (TREE_CODE (init_code) == INIT_EXPR) in check_initializer, and pull out the same init again, and set LOOKUP_ALREADY_DIGESTED. But I think that's wrong, we haven't digested it yet. Maybe we could avoid entering the below block of check_initializer at all in this situation? > if (((type_build_ctor_call (type) || CLASS_TYPE_P (type)) > && !(flags & LOOKUP_ALREADY_DIGESTED) > && !(init && BRACE_ENCLOSED_INITIALIZER_P (init) > && CP_AGGREGATE_TYPE_P (type) > && (CLASS_TYPE_P (type) Maybe by adding || processing_template_decl here? > || !TYPE_NEEDS_CONSTRUCTING (type) > || type_has_extended_temps (type)))) > || (DECL_DECOMPOSITION_P (decl) && TREE_CODE (type) == ARRAY_TYPE)) Jason ^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH v3] c++: ICE with template code in constexpr [PR104284] 2022-03-24 15:40 ` Jason Merrill @ 2022-03-24 21:53 ` Marek Polacek 2022-03-24 22:14 ` Jason Merrill 0 siblings, 1 reply; 7+ messages in thread From: Marek Polacek @ 2022-03-24 21:53 UTC (permalink / raw) To: Jason Merrill; +Cc: GCC Patches On Thu, Mar 24, 2022 at 11:40:11AM -0400, Jason Merrill wrote: > On 3/18/22 17:55, Marek Polacek wrote: > > On Fri, Mar 11, 2022 at 06:46:42PM -0500, Jason Merrill wrote: > > > On 3/10/22 18:04, Marek Polacek wrote: > > > > Since r9-6073 cxx_eval_store_expression preevaluates the value to > > > > be stored, and that revealed a crash where a template code (here, > > > > code=IMPLICIT_CONV_EXPR) leaks into cxx_eval*. > > > > > > > > It happens because we're performing build_vec_init while processing > > > > a template > > > > > > Hmm, that seems like the bug. Where's that call coming from? > > > > From build_aggr_init. So we're handling e.g. > > > > template<class> > > constexpr void g () { > > constexpr S s2[]{{'a'}}; > > } > > > > cp_finish_decl (decl=s2, init={{'a'}}) sees we're in processing_template_decl, > > but also that we have a constexpr var which is not dependent, nor is its > > initializer: > > > > else if (init > > && (init_const_expr_p || DECL_DECLARED_CONSTEXPR_P (decl)) > > && !TYPE_REF_P (type) > > && decl_maybe_constant_var_p (decl) > > && !(dep_init = value_dependent_init_p (init))) > > { > > /* This variable seems to be a non-dependent constant, so process > > its initializer. If check_initializer returns non-null the > > initialization wasn't constant after all. */ > > tree init_code; > > cleanups = make_tree_vector (); > > init_code = check_initializer (decl, init, flags, &cleanups); > > > > so we call check_initializer, where we go down this path: > > > > init_code = build_aggr_init_full_exprs (decl, init, flags); > > > > build_aggr_init sees that the type of 's2' is ARRAY_TYPE, so it calls > > build_vec_init. > > > > I now recall that we've discussed build_vec_init in a template in the > > past, for example in the context of c++/93676. So I agree we ought to > > make an effort to avoid calling build_vec_init in a template. Perhaps > > like this: use an INIT_EXPR. With that, we should call build_vec_init > > if needed while instantiating. Does that make any sense? > > Hmm. If we do that, then we get back to > > > if (TREE_CODE (init_code) == INIT_EXPR) > > in check_initializer, and pull out the same init again, and set > LOOKUP_ALREADY_DIGESTED. But I think that's wrong, we haven't digested it > yet. Yeah, that's probably no good :( > Maybe we could avoid entering the below block of check_initializer at all in > this situation? > > > if (((type_build_ctor_call (type) || CLASS_TYPE_P (type)) > > && !(flags & LOOKUP_ALREADY_DIGESTED) > > && !(init && BRACE_ENCLOSED_INITIALIZER_P (init) > > && CP_AGGREGATE_TYPE_P (type) > > && (CLASS_TYPE_P (type) > > Maybe by adding || processing_template_decl here? That seems to work! Thanks. I've checked that we call build_vec_init when instantiating, so we shouldn't be losing any of its effects. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- Since r9-6073 cxx_eval_store_expression preevaluates the value to be stored, and that revealed a crash where a template code (here, code=IMPLICIT_CONV_EXPR) leaks into cxx_eval*. It happens because we're performing build_vec_init while processing a template, which calls get_temp_regvar which creates an INIT_EXPR. This INIT_EXPR's RHS contains an rvalue conversion so we create an IMPLICIT_CONV_EXPR. Its operand is not type-dependent and the whole INIT_EXPR is not type-dependent. So we call build_non_dependent_expr which, with -fchecking=2, calls fold_non_dependent_expr. At this point the expression still has an IMPLICIT_CONV_EXPR, which ought to be handled in instantiate_non_dependent_expr_internal. However, tsubst_copy_and_build doesn't handle INIT_EXPR; it will just call tsubst_copy which does nothing when args is null. So we fail to replace the IMPLICIT_CONV_EXPR and ICE. The problem is that we call build_vec_init in a template in the first place. We can avoid doing so by checking p_t_d before calling build_aggr_init in check_initializer. PR c++/104284 gcc/cp/ChangeLog: * decl.cc (check_initializer): Don't call build_aggr_init in a template. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/constexpr-104284-1.C: New test. * g++.dg/cpp1y/constexpr-104284-2.C: New test. * g++.dg/cpp1y/constexpr-104284-3.C: New test. * g++.dg/cpp1y/constexpr-104284-4.C: New test. --- gcc/cp/decl.cc | 4 +++ .../g++.dg/cpp1y/constexpr-104284-1.C | 34 ++++++++++++++++++ .../g++.dg/cpp1y/constexpr-104284-2.C | 33 +++++++++++++++++ .../g++.dg/cpp1y/constexpr-104284-3.C | 33 +++++++++++++++++ .../g++.dg/cpp1y/constexpr-104284-4.C | 35 +++++++++++++++++++ 5 files changed, 139 insertions(+) create mode 100644 gcc/testsuite/g++.dg/cpp1y/constexpr-104284-1.C create mode 100644 gcc/testsuite/g++.dg/cpp1y/constexpr-104284-2.C create mode 100644 gcc/testsuite/g++.dg/cpp1y/constexpr-104284-3.C create mode 100644 gcc/testsuite/g++.dg/cpp1y/constexpr-104284-4.C diff --git a/gcc/cp/decl.cc b/gcc/cp/decl.cc index 68741bbf5d2..69f60a6dc0f 100644 --- a/gcc/cp/decl.cc +++ b/gcc/cp/decl.cc @@ -7332,6 +7332,10 @@ check_initializer (tree decl, tree init, int flags, vec<tree, va_gc> **cleanups) && !(init && BRACE_ENCLOSED_INITIALIZER_P (init) && CP_AGGREGATE_TYPE_P (type) && (CLASS_TYPE_P (type) + /* The call to build_aggr_init below could end up + calling build_vec_init, which may break when we + are processing a template. */ + || processing_template_decl || !TYPE_NEEDS_CONSTRUCTING (type) || type_has_extended_temps (type)))) || (DECL_DECOMPOSITION_P (decl) && TREE_CODE (type) == ARRAY_TYPE)) diff --git a/gcc/testsuite/g++.dg/cpp1y/constexpr-104284-1.C b/gcc/testsuite/g++.dg/cpp1y/constexpr-104284-1.C new file mode 100644 index 00000000000..809c26a6161 --- /dev/null +++ b/gcc/testsuite/g++.dg/cpp1y/constexpr-104284-1.C @@ -0,0 +1,34 @@ +// PR c++/104284 +// { dg-do compile { target c++14 } } +// { dg-additional-options "-fchecking=2" } + +struct S { + char c{}; +}; + +auto x1 = [](auto) { constexpr S s[]{{}}; }; +auto x2 = [](auto) { constexpr S s[]{{'a'}}; }; +#if __cpp_designated_initializers >= 201707L +auto x3 = [](auto) { constexpr S s[]{{.c = 'a'}}; }; +#endif +auto x4 = [](auto) { constexpr S s[]{'a'}; }; +auto x5 = [](auto) { constexpr S s[]{{{}}}; }; + +template<class> +constexpr void g () +{ + constexpr S s1[]{{}}; + static_assert(s1[0].c == '\0', ""); + constexpr S s2[]{{'a'}}; + static_assert(s2[0].c == 'a', ""); +#if __cpp_designated_initializers >= 201707L + constexpr S s3[]{{.c = 'a'}}; + static_assert(s3[0].c == 'a', ""); +#endif + constexpr S s4[]{'a'}; + static_assert(s4[0].c == 'a', ""); + constexpr S s5[]{{{}}}; + static_assert(s5[0].c == '\0', ""); +} + +static_assert ((g<int>(), true), ""); diff --git a/gcc/testsuite/g++.dg/cpp1y/constexpr-104284-2.C b/gcc/testsuite/g++.dg/cpp1y/constexpr-104284-2.C new file mode 100644 index 00000000000..704d37de129 --- /dev/null +++ b/gcc/testsuite/g++.dg/cpp1y/constexpr-104284-2.C @@ -0,0 +1,33 @@ +// PR c++/104284 +// { dg-do compile { target c++14 } } +// { dg-additional-options "-fchecking=2" } + +struct S { + char a; + constexpr S() : a{'a'} { } + constexpr S(char a_) : a{a_} { } +}; + +auto x1 = [](auto) { constexpr S s[]{{}}; }; +auto x2 = [](auto) { constexpr S s[]{{'a'}}; }; +auto x3 = [](auto) { constexpr S s[]{'a'}; }; +auto x4 = [](auto) { constexpr S s[]{{{}}}; }; + +template<typename> +constexpr void g() +{ + constexpr S s1[]{{}}; + static_assert(s1[0].a == 'a', ""); + constexpr S s2[]{{'a'}}; + static_assert(s2[0].a == 'a', ""); + constexpr S s3[]{'a'}; + static_assert(s3[0].a == 'a', ""); + constexpr S s4[]{{{}}}; + static_assert(s4[0].a == '\0', ""); +} + +void +f () +{ + g<int>(); +} diff --git a/gcc/testsuite/g++.dg/cpp1y/constexpr-104284-3.C b/gcc/testsuite/g++.dg/cpp1y/constexpr-104284-3.C new file mode 100644 index 00000000000..6f23b255f9c --- /dev/null +++ b/gcc/testsuite/g++.dg/cpp1y/constexpr-104284-3.C @@ -0,0 +1,33 @@ +// PR c++/104284 +// { dg-do compile { target c++14 } } +// { dg-additional-options "-fchecking=2" } +// Like constexpr-104284.C, but the function template is not +// constexpr. In that case, we were still calling build_vec_init +// in a template, just not crashing. + +struct S { + char c{}; +}; + +template<class> +void g () +{ + constexpr S s1[]{{}}; + static_assert(s1[0].c == '\0', ""); + constexpr S s2[]{{'a'}}; + static_assert(s2[0].c == 'a', ""); +#if __cpp_designated_initializers >= 201707L + constexpr S s3[]{{.c = 'a'}}; + static_assert(s3[0].c == 'a', ""); +#endif + constexpr S s4[]{'a'}; + static_assert(s4[0].c == 'a', ""); + constexpr S s5[]{{{}}}; + static_assert(s5[0].c == '\0', ""); +} + +void +f () +{ + g<int>(); +} diff --git a/gcc/testsuite/g++.dg/cpp1y/constexpr-104284-4.C b/gcc/testsuite/g++.dg/cpp1y/constexpr-104284-4.C new file mode 100644 index 00000000000..a99d3255a47 --- /dev/null +++ b/gcc/testsuite/g++.dg/cpp1y/constexpr-104284-4.C @@ -0,0 +1,35 @@ +// PR c++/104284 +// { dg-do run { target c++14 } } +// { dg-additional-options "-fchecking=2" } + +struct S { + char c{}; +}; + +template<class> +constexpr void g () +{ + S s1[]{{}}; + if (s1[0].c != '\0') + __builtin_abort (); + S s2[]{{'a'}}; + if (s2[0].c != 'a') + __builtin_abort (); +#if __cpp_designated_initializers >= 201707L + S s3[]{{.c = 'a'}}; + if (s3[0].c != 'a') + __builtin_abort (); +#endif + S s4[]{'a'}; + if (s4[0].c != 'a') + __builtin_abort (); + S s5[]{{{}}}; + if (s5[0].c != '\0') + __builtin_abort (); +} + +int +main () +{ + g<int>(); +} base-commit: 346ab5a54a831ad9c78afcbd8dfe98e0e07e3070 -- 2.35.1 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v3] c++: ICE with template code in constexpr [PR104284] 2022-03-24 21:53 ` [PATCH v3] " Marek Polacek @ 2022-03-24 22:14 ` Jason Merrill 0 siblings, 0 replies; 7+ messages in thread From: Jason Merrill @ 2022-03-24 22:14 UTC (permalink / raw) To: Marek Polacek; +Cc: GCC Patches On 3/24/22 17:53, Marek Polacek wrote: > On Thu, Mar 24, 2022 at 11:40:11AM -0400, Jason Merrill wrote: >> On 3/18/22 17:55, Marek Polacek wrote: >>> On Fri, Mar 11, 2022 at 06:46:42PM -0500, Jason Merrill wrote: >>>> On 3/10/22 18:04, Marek Polacek wrote: >>>>> Since r9-6073 cxx_eval_store_expression preevaluates the value to >>>>> be stored, and that revealed a crash where a template code (here, >>>>> code=IMPLICIT_CONV_EXPR) leaks into cxx_eval*. >>>>> >>>>> It happens because we're performing build_vec_init while processing >>>>> a template >>>> >>>> Hmm, that seems like the bug. Where's that call coming from? >>> >>> From build_aggr_init. So we're handling e.g. >>> >>> template<class> >>> constexpr void g () { >>> constexpr S s2[]{{'a'}}; >>> } >>> >>> cp_finish_decl (decl=s2, init={{'a'}}) sees we're in processing_template_decl, >>> but also that we have a constexpr var which is not dependent, nor is its >>> initializer: >>> >>> else if (init >>> && (init_const_expr_p || DECL_DECLARED_CONSTEXPR_P (decl)) >>> && !TYPE_REF_P (type) >>> && decl_maybe_constant_var_p (decl) >>> && !(dep_init = value_dependent_init_p (init))) >>> { >>> /* This variable seems to be a non-dependent constant, so process >>> its initializer. If check_initializer returns non-null the >>> initialization wasn't constant after all. */ >>> tree init_code; >>> cleanups = make_tree_vector (); >>> init_code = check_initializer (decl, init, flags, &cleanups); >>> >>> so we call check_initializer, where we go down this path: >>> >>> init_code = build_aggr_init_full_exprs (decl, init, flags); >>> >>> build_aggr_init sees that the type of 's2' is ARRAY_TYPE, so it calls >>> build_vec_init. >>> >>> I now recall that we've discussed build_vec_init in a template in the >>> past, for example in the context of c++/93676. So I agree we ought to >>> make an effort to avoid calling build_vec_init in a template. Perhaps >>> like this: use an INIT_EXPR. With that, we should call build_vec_init >>> if needed while instantiating. Does that make any sense? >> >> Hmm. If we do that, then we get back to >> >>> if (TREE_CODE (init_code) == INIT_EXPR) >> >> in check_initializer, and pull out the same init again, and set >> LOOKUP_ALREADY_DIGESTED. But I think that's wrong, we haven't digested it >> yet. > > Yeah, that's probably no good :( > >> Maybe we could avoid entering the below block of check_initializer at all in >> this situation? >> >>> if (((type_build_ctor_call (type) || CLASS_TYPE_P (type)) >>> && !(flags & LOOKUP_ALREADY_DIGESTED) >>> && !(init && BRACE_ENCLOSED_INITIALIZER_P (init) >>> && CP_AGGREGATE_TYPE_P (type) >>> && (CLASS_TYPE_P (type) >> >> Maybe by adding || processing_template_decl here? > > That seems to work! Thanks. > > I've checked that we call build_vec_init when instantiating, so we > shouldn't be losing any of its effects. > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? OK. > -- >8 -- > Since r9-6073 cxx_eval_store_expression preevaluates the value to > be stored, and that revealed a crash where a template code (here, > code=IMPLICIT_CONV_EXPR) leaks into cxx_eval*. > > It happens because we're performing build_vec_init while processing > a template, which calls get_temp_regvar which creates an INIT_EXPR. > This INIT_EXPR's RHS contains an rvalue conversion so we create an > IMPLICIT_CONV_EXPR. Its operand is not type-dependent and the whole > INIT_EXPR is not type-dependent. So we call build_non_dependent_expr > which, with -fchecking=2, calls fold_non_dependent_expr. At this > point the expression still has an IMPLICIT_CONV_EXPR, which ought to > be handled in instantiate_non_dependent_expr_internal. However, > tsubst_copy_and_build doesn't handle INIT_EXPR; it will just call > tsubst_copy which does nothing when args is null. So we fail to > replace the IMPLICIT_CONV_EXPR and ICE. > > The problem is that we call build_vec_init in a template in the > first place. We can avoid doing so by checking p_t_d before > calling build_aggr_init in check_initializer. > > PR c++/104284 > > gcc/cp/ChangeLog: > > * decl.cc (check_initializer): Don't call build_aggr_init in > a template. > > gcc/testsuite/ChangeLog: > > * g++.dg/cpp1y/constexpr-104284-1.C: New test. > * g++.dg/cpp1y/constexpr-104284-2.C: New test. > * g++.dg/cpp1y/constexpr-104284-3.C: New test. > * g++.dg/cpp1y/constexpr-104284-4.C: New test. > --- > gcc/cp/decl.cc | 4 +++ > .../g++.dg/cpp1y/constexpr-104284-1.C | 34 ++++++++++++++++++ > .../g++.dg/cpp1y/constexpr-104284-2.C | 33 +++++++++++++++++ > .../g++.dg/cpp1y/constexpr-104284-3.C | 33 +++++++++++++++++ > .../g++.dg/cpp1y/constexpr-104284-4.C | 35 +++++++++++++++++++ > 5 files changed, 139 insertions(+) > create mode 100644 gcc/testsuite/g++.dg/cpp1y/constexpr-104284-1.C > create mode 100644 gcc/testsuite/g++.dg/cpp1y/constexpr-104284-2.C > create mode 100644 gcc/testsuite/g++.dg/cpp1y/constexpr-104284-3.C > create mode 100644 gcc/testsuite/g++.dg/cpp1y/constexpr-104284-4.C > > diff --git a/gcc/cp/decl.cc b/gcc/cp/decl.cc > index 68741bbf5d2..69f60a6dc0f 100644 > --- a/gcc/cp/decl.cc > +++ b/gcc/cp/decl.cc > @@ -7332,6 +7332,10 @@ check_initializer (tree decl, tree init, int flags, vec<tree, va_gc> **cleanups) > && !(init && BRACE_ENCLOSED_INITIALIZER_P (init) > && CP_AGGREGATE_TYPE_P (type) > && (CLASS_TYPE_P (type) > + /* The call to build_aggr_init below could end up > + calling build_vec_init, which may break when we > + are processing a template. */ > + || processing_template_decl > || !TYPE_NEEDS_CONSTRUCTING (type) > || type_has_extended_temps (type)))) > || (DECL_DECOMPOSITION_P (decl) && TREE_CODE (type) == ARRAY_TYPE)) > diff --git a/gcc/testsuite/g++.dg/cpp1y/constexpr-104284-1.C b/gcc/testsuite/g++.dg/cpp1y/constexpr-104284-1.C > new file mode 100644 > index 00000000000..809c26a6161 > --- /dev/null > +++ b/gcc/testsuite/g++.dg/cpp1y/constexpr-104284-1.C > @@ -0,0 +1,34 @@ > +// PR c++/104284 > +// { dg-do compile { target c++14 } } > +// { dg-additional-options "-fchecking=2" } > + > +struct S { > + char c{}; > +}; > + > +auto x1 = [](auto) { constexpr S s[]{{}}; }; > +auto x2 = [](auto) { constexpr S s[]{{'a'}}; }; > +#if __cpp_designated_initializers >= 201707L > +auto x3 = [](auto) { constexpr S s[]{{.c = 'a'}}; }; > +#endif > +auto x4 = [](auto) { constexpr S s[]{'a'}; }; > +auto x5 = [](auto) { constexpr S s[]{{{}}}; }; > + > +template<class> > +constexpr void g () > +{ > + constexpr S s1[]{{}}; > + static_assert(s1[0].c == '\0', ""); > + constexpr S s2[]{{'a'}}; > + static_assert(s2[0].c == 'a', ""); > +#if __cpp_designated_initializers >= 201707L > + constexpr S s3[]{{.c = 'a'}}; > + static_assert(s3[0].c == 'a', ""); > +#endif > + constexpr S s4[]{'a'}; > + static_assert(s4[0].c == 'a', ""); > + constexpr S s5[]{{{}}}; > + static_assert(s5[0].c == '\0', ""); > +} > + > +static_assert ((g<int>(), true), ""); > diff --git a/gcc/testsuite/g++.dg/cpp1y/constexpr-104284-2.C b/gcc/testsuite/g++.dg/cpp1y/constexpr-104284-2.C > new file mode 100644 > index 00000000000..704d37de129 > --- /dev/null > +++ b/gcc/testsuite/g++.dg/cpp1y/constexpr-104284-2.C > @@ -0,0 +1,33 @@ > +// PR c++/104284 > +// { dg-do compile { target c++14 } } > +// { dg-additional-options "-fchecking=2" } > + > +struct S { > + char a; > + constexpr S() : a{'a'} { } > + constexpr S(char a_) : a{a_} { } > +}; > + > +auto x1 = [](auto) { constexpr S s[]{{}}; }; > +auto x2 = [](auto) { constexpr S s[]{{'a'}}; }; > +auto x3 = [](auto) { constexpr S s[]{'a'}; }; > +auto x4 = [](auto) { constexpr S s[]{{{}}}; }; > + > +template<typename> > +constexpr void g() > +{ > + constexpr S s1[]{{}}; > + static_assert(s1[0].a == 'a', ""); > + constexpr S s2[]{{'a'}}; > + static_assert(s2[0].a == 'a', ""); > + constexpr S s3[]{'a'}; > + static_assert(s3[0].a == 'a', ""); > + constexpr S s4[]{{{}}}; > + static_assert(s4[0].a == '\0', ""); > +} > + > +void > +f () > +{ > + g<int>(); > +} > diff --git a/gcc/testsuite/g++.dg/cpp1y/constexpr-104284-3.C b/gcc/testsuite/g++.dg/cpp1y/constexpr-104284-3.C > new file mode 100644 > index 00000000000..6f23b255f9c > --- /dev/null > +++ b/gcc/testsuite/g++.dg/cpp1y/constexpr-104284-3.C > @@ -0,0 +1,33 @@ > +// PR c++/104284 > +// { dg-do compile { target c++14 } } > +// { dg-additional-options "-fchecking=2" } > +// Like constexpr-104284.C, but the function template is not > +// constexpr. In that case, we were still calling build_vec_init > +// in a template, just not crashing. > + > +struct S { > + char c{}; > +}; > + > +template<class> > +void g () > +{ > + constexpr S s1[]{{}}; > + static_assert(s1[0].c == '\0', ""); > + constexpr S s2[]{{'a'}}; > + static_assert(s2[0].c == 'a', ""); > +#if __cpp_designated_initializers >= 201707L > + constexpr S s3[]{{.c = 'a'}}; > + static_assert(s3[0].c == 'a', ""); > +#endif > + constexpr S s4[]{'a'}; > + static_assert(s4[0].c == 'a', ""); > + constexpr S s5[]{{{}}}; > + static_assert(s5[0].c == '\0', ""); > +} > + > +void > +f () > +{ > + g<int>(); > +} > diff --git a/gcc/testsuite/g++.dg/cpp1y/constexpr-104284-4.C b/gcc/testsuite/g++.dg/cpp1y/constexpr-104284-4.C > new file mode 100644 > index 00000000000..a99d3255a47 > --- /dev/null > +++ b/gcc/testsuite/g++.dg/cpp1y/constexpr-104284-4.C > @@ -0,0 +1,35 @@ > +// PR c++/104284 > +// { dg-do run { target c++14 } } > +// { dg-additional-options "-fchecking=2" } > + > +struct S { > + char c{}; > +}; > + > +template<class> > +constexpr void g () > +{ > + S s1[]{{}}; > + if (s1[0].c != '\0') > + __builtin_abort (); > + S s2[]{{'a'}}; > + if (s2[0].c != 'a') > + __builtin_abort (); > +#if __cpp_designated_initializers >= 201707L > + S s3[]{{.c = 'a'}}; > + if (s3[0].c != 'a') > + __builtin_abort (); > +#endif > + S s4[]{'a'}; > + if (s4[0].c != 'a') > + __builtin_abort (); > + S s5[]{{{}}}; > + if (s5[0].c != '\0') > + __builtin_abort (); > +} > + > +int > +main () > +{ > + g<int>(); > +} > > base-commit: 346ab5a54a831ad9c78afcbd8dfe98e0e07e3070 ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2022-03-24 22:14 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-03-10 22:04 [PATCH] c++: ICE with template code in constexpr [PR104284] Marek Polacek 2022-03-10 22:27 ` Marek Polacek 2022-03-11 23:46 ` Jason Merrill 2022-03-18 21:55 ` [PATCH v2] " Marek Polacek 2022-03-24 15:40 ` Jason Merrill 2022-03-24 21:53 ` [PATCH v3] " Marek Polacek 2022-03-24 22:14 ` Jason Merrill
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).