++: 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  <jakub@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 --git a/gcc/cp/init.cc b/gcc/cp/init.cc
index 062a4938a44c7e63277f3ccdbd58af390d02d18b..80a37a14a80668acfc19028fba5273aeff340bbf 100644 (file)
--- 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?  */