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.

Diff:
---
 gcc/cp/init.cc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gcc/cp/init.cc b/gcc/cp/init.cc
index 062a4938a44c..80a37a14a806 100644
--- a/gcc/cp/init.cc
+++ b/gcc/cp/init.cc
@@ -4747,7 +4747,8 @@ build_vec_init (tree base, tree maxindex, tree init,
         itself.  But that breaks when gimplify_target_expr adds a clobber
         cleanup that runs before the build_vec_init cleanup.  */
       if (cleanup_flags)
-       vec_safe_push (*cleanup_flags, build_tree_list (iterator, maxindex));
+       vec_safe_push (*cleanup_flags,
+                      build_tree_list (rval, build_zero_cst (ptype)));
     }
 
   /* Should we try to create a constant initializer?  */

Reply via email to