On Fri, May 6, 2016 at 12:10 PM, Martin Liška <mli...@suse.cz> wrote: > Hi. > > I've spotted couple of occurrences of following memory leak seen by valgrind: > > malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) > operator new(unsigned long) (new_op.cc:50) > remap_dependence_clique(copy_body_data*, unsigned short) (tree-inline.c:845) > remap_gimple_op_r(tree_node**, int*, void*) (tree-inline.c:954) > walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*), void*, > hash_set<tree_node*, default_hash_traits<tree_node*> >*, tree_node* > (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*, > hash_set<tree_node*, default_hash_traits<tree_node*> >*)) (tree.c:11498) > walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*), void*, > hash_set<tree_node*, default_hash_traits<tree_node*> >*, tree_node* > (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*, > hash_set<tree_node*, default_hash_traits<tree_node*> >*)) (tree.c:11815) > walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*), void*, > hash_set<tree_node*, default_hash_traits<tree_node*> >*, tree_node* > (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*, > hash_set<tree_node*, default_hash_traits<tree_node*> >*)) (tree.c:11815) > walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*), void*, > hash_set<tree_node*, default_hash_traits<tree_node*> >*, tree_node* > (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*, > hash_set<tree_node*, default_hash_traits<tree_node*> >*)) (tree.c:11815) > copy_debug_stmt (tree-inline.c:2869) > copy_debug_stmts (tree-inline.c:2927) > copy_body(copy_body_data*, long, int, basic_block_def*, basic_block_def*, > basic_block_def*) (tree-inline.c:2961) > tree_function_versioning(tree_node*, tree_node*, vec<ipa_replace_map*, > va_gc, vl_embed>*, bool, bitmap_head*, bool, bitmap_head*, basic_block_def*) > (tree-inline.c:5907) > save_inline_function_body (ipa-inline-transform.c:485) > inline_transform(cgraph_node*) (ipa-inline-transform.c:541) > > Problem is that the id->dependence_map is released before copy_debug_stmts is > called. > > Patch can bootstrap and survives regression tests on x86_64-linux-gnu. > Ready for trunk?
Hmmm. But this means debug stmt remapping calls remap_dependence_clique which may end up bumping cfun->last_clique and thus may change code generation. So what debug stmts contain MEM_REFs? If you put an assert processing_debug_stmt == 0 in remap_dependence_clique I'd like to see a testcase that triggers it. Richard. > Martin
