]> git.ipfire.org Git - thirdparty/gcc.git/commit
c++: direct-init of an array of class type [PR59465]
authorMarek Polacek <polacek@redhat.com>
Thu, 22 Feb 2024 23:49:08 +0000 (18:49 -0500)
committerMarek Polacek <polacek@redhat.com>
Fri, 22 Mar 2024 14:40:50 +0000 (10:40 -0400)
commitd1d8fd2884b44598d80de1038b086eec41519d4b
tree5aa1a9f0bcf70acf2541c9745116e9a4770ffc36
parente4e02c07d93559a037608c73e8153549b5104fbb
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.
gcc/cp/init.cc
gcc/testsuite/g++.dg/init/array62.C [new file with mode: 0644]
gcc/testsuite/g++.dg/init/array63.C [new file with mode: 0644]
gcc/testsuite/g++.dg/init/array64.C [new file with mode: 0644]