[Bug c++/59465] [11/12/13/14 Regression] g++ allows direct-initialization of an array of class type from another array in a mem-initializer

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59465

--- Comment #7 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The trunk branch has been updated by Marek Polacek <mpola...@gcc.gnu.org>:

https://gcc.gnu.org/g:d1d8fd2884b44598d80de1038b086eec41519d4b

commit r14-9622-gd1d8fd2884b44598d80de1038b086eec41519d4b
Author: Marek Polacek <pola...@redhat.com>
Date:   Thu Feb 22 18:49:08 2024 -0500

    c++: direct-init of an array of class type [PR59465]

    ...from another array in a mem-initializer should not be accepted.

    We already reject

      struct string {} a[1];
      string x[1](a);

    but

      struct pair {
        string s[1];
        pair() : s(a) {}
      };

    is wrongly accepted.

    It started to be accepted with r0-110915-ga034826198b771:
    <https://gcc.gnu.org/pipermail/gcc-patches/2011-August/320236.html>
    which was supposed to be a cleanup, not a deliberate change to start
    accepting the code.  The build_vec_init_expr code was added in r165976:
    <https://gcc.gnu.org/pipermail/gcc-patches/2010-October/297582.html>.

    It appears that we do the magic copy array when we have a defaulted
    constructor and we generate code for its mem-initializer which
    initializes an array.  I also see that we go that path for compound
    literals.  So when initializing an array member, we can limit building
    up a VEC_INIT_EXPR to those special cases.

            PR c++/59465

    gcc/cp/ChangeLog:

            * init.cc (can_init_array_with_p): New.
            (perform_member_init): Check it.

    gcc/testsuite/ChangeLog:

            * g++.dg/init/array62.C: New test.
            * g++.dg/init/array63.C: New test.
            * g++.dg/init/array64.C: New test.