[PATCH] Fix memory leak in identify_jump_threads()

[Markus Trippelsdorf]

Valgrind shows:

==553== 391,488 bytes in 24 blocks are possibly lost in loss record 4,339 of 4,342
==553==    at 0x4030C15: calloc (vg_replace_malloc.c:711)
==553==    by 0x1607CA0: xcalloc (xmalloc.c:162)
==553==    by 0x1004A81: data_alloc (hash-table.h:263)
==553==    by 0x1004A81: alloc_entries (hash-table.h:650)
==553==    by 0x1004A81: hash_table (hash-table.h:586)
==553==    by 0x1004A81: identify_jump_threads (tree-vrp.c:11009)
==553==    by 0x1004A81: execute_vrp (tree-vrp.c:11684)
==553==    by 0x1004A81: (anonymous namespace)::pass_vrp::execute(function*) (tree-vrp.c:11777)
==553==    by 0xC80AA2: execute_one_pass(opt_pass*) (passes.c:2465)
==553==    by 0xC81370: execute_pass_list_1(opt_pass*) (passes.c:2554)
==553==    by 0xC81382: execute_pass_list_1(opt_pass*) (passes.c:2555)
==553==    by 0xC813CC: execute_pass_list(function*, opt_pass*) (passes.c:2565)
==553==    by 0x9409DC: cgraph_node::expand() (cgraphunit.c:2038)
==553==    by 0x94217B: expand_all_functions (cgraphunit.c:2174)
==553==    by 0x94217B: symbol_table::compile() [clone .part.51] (cgraphunit.c:2531)
==553==    by 0x9448C4: compile (cgraphunit.c:2624)
==553==    by 0x9448C4: symbol_table::finalize_compilation_unit() (cgraphunit.c:2621)
==553==    by 0xD57C82: compile_file() (toplev.c:492)
==553==    by 0x5B8DFF: do_compile (toplev.c:2000)
==553==    by 0x5B8DFF: toplev::main(int, char**) (toplev.c:2134)
==553==
==553== 606,520 (2,976 direct, 603,544 indirect) bytes in 62 blocks are definitely lost in loss record 4,342 of 4,342
==553==    at 0x402F26F: operator new(unsigned long) (vg_replace_malloc.c:334)
==553==    by 0x1004A37: identify_jump_threads (tree-vrp.c:11009)
==553==    by 0x1004A37: execute_vrp (tree-vrp.c:11684)
==553==    by 0x1004A37: (anonymous namespace)::pass_vrp::execute(function*) (tree-vrp.c:11777)
==553==    by 0xC80AA2: execute_one_pass(opt_pass*) (passes.c:2465)
==553==    by 0xC81370: execute_pass_list_1(opt_pass*) (passes.c:2554)
==553==    by 0xC81382: execute_pass_list_1(opt_pass*) (passes.c:2555)
==553==    by 0xC813CC: execute_pass_list(function*, opt_pass*) (passes.c:2565)
==553==    by 0x9409DC: cgraph_node::expand() (cgraphunit.c:2038)
==553==    by 0x94217B: expand_all_functions (cgraphunit.c:2174)
==553==    by 0x94217B: symbol_table::compile() [clone .part.51] (cgraphunit.c:2531)
==553==    by 0x9448C4: compile (cgraphunit.c:2624)
==553==    by 0x9448C4: symbol_table::finalize_compilation_unit() (cgraphunit.c:2621)
==553==    by 0xD57C82: compile_file() (toplev.c:492)
==553==    by 0x5B8DFF: do_compile (toplev.c:2000)
==553==    by 0x5B8DFF: toplev::main(int, char**) (toplev.c:2134)
==553==    by 0x5BB0DD: main (main.c:39)

The fix is trivial. Tested on ppc64le,
OK for trunk?

Longer term it would be nice to have a smart pointer available in gcc to
avoid those ugly and error-prone naked news.
Pedro committed a solution for binutils-gdb last year:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=da804164742b83965b487bbff5b6334f2e63fe91

	* tree-vrp.c (identify_jump_threads): Delete avail_exprs.

diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c
index 26652e3b048a..28d9c175dcd4 100644
--- a/gcc/tree-vrp.c
+++ b/gcc/tree-vrp.c
@@ -11021,6 +11021,7 @@ identify_jump_threads (void)
      ASSERT_EXPRs are still in the IL and cfg cleanup code does not yet
      handle ASSERT_EXPRs gracefully.  */
   delete equiv_stack;
+  delete avail_exprs;
   delete avail_exprs_stack;
 }
 
-- 
Markus