https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96282
--- Comment #8 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The releases/gcc-10 branch has been updated by Patrick Palka <ppa...@gcc.gnu.org>: https://gcc.gnu.org/g:f426e4f63451e937c943606d3142b1ac6b70467a commit r10-9331-gf426e4f63451e937c943606d3142b1ac6b70467a Author: Patrick Palka <ppa...@redhat.com> Date: Wed Aug 5 15:05:30 2020 -0400 c++: cxx_eval_vec_init after zero-initialization [PR96282] In the first testcase below, expand_aggr_init_1 sets up t's default constructor such that the ctor first zero-initializes the entire base b, followed by calling b's default constructor, the latter of which just default-initializes the array member b::m via a VEC_INIT_EXPR. So upon constexpr evaluation of this latter VEC_INIT_EXPR, ctx->ctor is nonempty due to the prior zero-initialization, and we proceed in cxx_eval_vec_init to append new constructor_elts to the end of ctx->ctor without first checking if a matching constructor_elt already exists. This leads to ctx->ctor having two matching constructor_elts for each index. This patch fixes this issue by truncating a zero-initialized array CONSTRUCTOR in cxx_eval_vec_init_1 before we begin appending array elements to it. We propagate its zeroed out state during evaluation by clearing CONSTRUCTOR_NO_CLEARING on each new appended aggregate element. gcc/cp/ChangeLog: PR c++/96282 * constexpr.c (cxx_eval_vec_init_1): Truncate ctx->ctor and then clear CONSTRUCTOR_NO_CLEARING on each appended element initializer if we're initializing a previously zero-initialized array object. gcc/testsuite/ChangeLog: PR c++/96282 * g++.dg/cpp0x/constexpr-array26.C: New test. * g++.dg/cpp0x/constexpr-array27.C: New test. * g++.dg/cpp2a/constexpr-init18.C: New test. Co-authored-by: Jason Merrill <ja...@redhat.com> (cherry picked from commit d21252de6c81ed236d8981d47b9a57dc4f1c6d57)
