https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118355
--- Comment #7 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The releases/gcc-13 branch has been updated by Marek Polacek <mpola...@gcc.gnu.org>: https://gcc.gnu.org/g:445203466749b8bdd17590fe7dd37d72d8b570c0 commit r13-9354-g445203466749b8bdd17590fe7dd37d72d8b570c0 Author: Marek Polacek <pola...@redhat.com> Date: Mon Jan 13 15:09:14 2025 -0500 c++: re-enable NSDMI CONSTRUCTOR folding [PR118355] In c++/102990 we had a problem where massage_init_elt got {}, digest_nsdmi_init turned that {} into { .value = (int) 1.0e+0 }, and we crashed in the call to fold_non_dependent_init because a FIX_TRUNC_EXPR/FLOAT_EXPR got into tsubst*. So we avoided calling fold_non_dependent_init for a CONSTRUCTOR. But that broke the following test, where we no longer fold the CONST_DECL in { .type = ZERO } to { .type = 0 } and then process_init_constructor_array does: if (next != error_mark_node && (initializer_constant_valid_p (next, TREE_TYPE (next)) != null_pointer_node)) { /* Use VEC_INIT_EXPR for non-constant initialization of trailing elements with no explicit initializers. */ picflags |= PICFLAG_VEC_INIT; because { .type = ZERO } isn't initializer_constant_valid_p. Then we create a VEC_INIT_EXPR and say we can't convert the argument. So we have to fold the elements of the CONSTRUCTOR. We just can't instantiate the elements in a template. This also fixes c++/118047. PR c++/118047 PR c++/118355 gcc/cp/ChangeLog: * typeck2.cc (massage_init_elt): Call fold_non_dependent_init unless for a CONSTRUCTOR in a template. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/nsdmi-list10.C: New test. * g++.dg/cpp0x/nsdmi-list9.C: New test. Reviewed-by: Jason Merrill <ja...@redhat.com> (cherry picked from commit e939005c496dfd4058fa57b6860bfadcabe4a111)
