aboutsummaryrefslogtreecommitdiff
path: root/libgcc
diff options
context:
space:
mode:
authorMarek Polacek <polacek@redhat.com>2024-03-25 15:32:20 -0400
committerMarek Polacek <polacek@redhat.com>2024-03-25 18:19:50 -0400
commitde0886d48032332d10e4acb5d15c8789b281b6fe (patch)
tree59597463cea782d5bf2ce22b1186ac669268eaa0 /libgcc
parenta89fb3ae7bb56d4674fb9fdd0c73bb2667ad51a9 (diff)
downloadgcc-de0886d48032332d10e4acb5d15c8789b281b6fe.zip
gcc-de0886d48032332d10e4acb5d15c8789b281b6fe.tar.gz
gcc-de0886d48032332d10e4acb5d15c8789b281b6fe.tar.bz2
c++: broken direct-init with trailing array member [PR114439]
can_init_array_with_p is wrongly saying that the init for 's' here: struct S { int *list = arr; int arr[]; }; struct A { A() {} S s[2]{}; }; is invalid. But as process_init_constructor_array says, for "non-constant initialization of trailing elements with no explicit initializers" we use a VEC_INIT_EXPR wrapped in a TARGET_EXPR, built in process_init_constructor. Unfortunately we didn't have a test for this scenario so I didn't realize can_init_array_with_p must handle it. PR c++/114439 gcc/cp/ChangeLog: * init.cc (can_init_array_with_p): Return true for a VEC_INIT_EXPR wrapped in a TARGET_EXPR. gcc/testsuite/ChangeLog: * g++.dg/init/array65.C: New test.
Diffstat (limited to 'libgcc')
0 files changed, 0 insertions, 0 deletions