diff options
author | Jason Merrill <jason@redhat.com> | 2022-12-06 18:10:48 -0500 |
---|---|---|
committer | Jason Merrill <jason@redhat.com> | 2023-06-12 04:56:27 -0400 |
commit | 2764335bd336f2360d465ffcaa8f2c33f7321ab4 (patch) | |
tree | d72e3420669e9fb6a9d431bf4bf855b334f96310 /libobjc/encoding.c | |
parent | ff83d1b47aadcdaf80a4fda84b0dc00bb2cd3641 (diff) | |
download | gcc-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 'libobjc/encoding.c')
0 files changed, 0 insertions, 0 deletions