| Message ID | 20170323112033.GA7314@x4 |
|---|---|
| State | New |
| Headers | show |
On Thu, Mar 23, 2017 at 12:20 PM, Markus Trippelsdorf <markus@trippelsdorf.de> wrote: > 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? Ok. Thanks, Richard. > 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
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; }