aboutsummaryrefslogtreecommitdiff
path: root/libada
diff options
context:
space:
mode:
authorJason Merrill <jason@redhat.com>2022-12-06 18:10:48 -0500
committerJason Merrill <jason@redhat.com>2023-06-12 04:56:27 -0400
commit2764335bd336f2360d465ffcaa8f2c33f7321ab4 (patch)
treed72e3420669e9fb6a9d431bf4bf855b334f96310 /libada
parentff83d1b47aadcdaf80a4fda84b0dc00bb2cd3641 (diff)
downloadgcc-2764335bd336f2360d465ffcaa8f2c33f7321ab4.zip
gcc-2764335bd336f2360d465ffcaa8f2c33f7321ab4.tar.gz
gcc-2764335bd336f2360d465ffcaa8f2c33f7321ab4.tar.bz2
c++: build initializer_list<string> in a loop [PR105838]
I previously applied this change in r13-4565 but reverted it due to PR108071. That PR was then fixed by r13-4712, but I didn't re-apply this change then because we weren't making the array static; since r14-1500 for PR110070 we now make the initializer array static, so let's bring this back. In situations where the maybe_init_list_as_range optimization isn't viable, we can build an initializer_list<string> with a loop over a constant array of string literals. This is represented using a VEC_INIT_EXPR, which required adjusting a couple of places that expected the initializer array to have the same type as the target array and fixing build_vec_init not to undo our efforts. PR c++/105838 gcc/cp/ChangeLog: * call.cc (convert_like_internal) [ck_list]: Use maybe_init_list_as_array. * constexpr.cc (cxx_eval_vec_init_1): Init might have a different type. * tree.cc (build_vec_init_elt): Likewise. * init.cc (build_vec_init): Handle from_array from a TARGET_EXPR. Retain TARGET_EXPR of a different type. gcc/testsuite/ChangeLog: * g++.dg/tree-ssa/initlist-opt5.C: New test.
Diffstat (limited to 'libada')
0 files changed, 0 insertions, 0 deletions