Hi!

I've noticed that in the last few days we leak memory.
The problem is that vr_values ctor allocates 2 vectors, but
~vr_values doesn't free them, only verifies they aren't empty, they are
released by the cleanup_edges_and_switches method.
Some evrp walker users do call that method, but others like the sprintf time
that use evrp only in a read-only way, without ever calling
simplify_stmt_using_ranges, don't.  In that latter case they don't push
anything to the vectors though.
The following patch just makes those vectors empty in the ctor, doesn't
allocate anything, which is better for memory-wise for the sprintf pass as
well as functions that don't contain any switches, or don't have any
switches that can be actually optimized using ranges, those vectors will be
allocated only during safe_push when actually needed.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2018-09-25  Jakub Jelinek  <ja...@redhat.com>

        * vr-values.c (vr_values::vr_values): Initialize to_remove_edges and
        to_update_switch_stmts to vNULL instead of calling create on them
        immediately.

--- gcc/vr-values.c.jj  2018-09-24 10:36:54.556016724 +0200
+++ gcc/vr-values.c     2018-09-24 22:48:59.358094832 +0200
@@ -1919,8 +1919,8 @@ vr_values::vr_values () : vrp_value_rang
   vr_value = XCNEWVEC (value_range *, num_vr_values);
   vr_phi_edge_counts = XCNEWVEC (int, num_ssa_names);
   bitmap_obstack_initialize (&vrp_equiv_obstack);
-  to_remove_edges.create (10);
-  to_update_switch_stmts.create (5);
+  to_remove_edges = vNULL;
+  to_update_switch_stmts = vNULL;
 }
 
 /* Free VRP lattice.  */

        Jakub

Reply via email to