https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117827
--- Comment #12 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jakub Jelinek <ja...@gcc.gnu.org>: https://gcc.gnu.org/g:c6efdffa7d5c68a14aa5de3a426a44ee05aaa1b9 commit r16-343-gc6efdffa7d5c68a14aa5de3a426a44ee05aaa1b9 Author: Jakub Jelinek <ja...@redhat.com> Date: Fri May 2 09:16:27 2025 +0200 ++: Small build_vec_init improvement [PR117827] As discussed in the https://gcc.gnu.org/pipermail/gcc-patches/2025-January/674492.html thread, the following patch attempts to improve build_vec_init generated code. E.g. on g++.dg/eh/aggregate1.C test the patch has differences like: D.2988 = &D.2950->e1; D.2989 = D.2988; D.2990 = 1; try { goto <D.2996>; <D.2997>: A::A (D.2989); D.2990 = D.2990 + -1; D.2989 = D.2989 + 1; <D.2996>: if (D.2990 >= 0) goto <D.2997>; else goto <D.2995>; <D.2995>: retval.4 = D.2988; _13 = &D.2950->e2; A::A (_13); - D.2990 = 1; + D.2988 = 0B; D.2951 = D.2951 + -1; } catch { { struct A * D.2991; if (D.2988 != 0B) goto <D.3028>; else goto <D.3029>; <D.3028>: _11 = 1 - D.2990; _12 = (sizetype) _11; D.2991 = D.2988 + _12; <D.3030>: if (D.2991 == D.2988) goto <D.3031>; else goto <D.3032>; <D.3032>: D.2991 = D.2991 + 18446744073709551615; A::~A (D.2991); goto <D.3030>; <D.3031>: goto <D.3033>; <D.3029>: <D.3033>: } } in 3 spots. As you can see, both setting D.2990 (i.e. iterator) to maxindex and setting D.2988 (i.e. rval) to nullptr have the same effect of not actually destructing anything anymore in the cleanup, the advantage of clearing rval is that setting something to zero is often less expensive than potentially huge maxindex and that the cleanup tests that value first. 2025-05-02 Jakub Jelinek <ja...@redhat.com> PR c++/117827 * init.cc (build_vec_init): Push to *cleanup_flags clearing of rval instead of setting of iterator to maxindex.
