[Bug middle-end/56461] New: [4.8 Regression] GCC is leaking lots of memory

[Bug middle-end/56461] New: [4.8 Regression] GCC is leaking lots of memory

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461

             Bug #: 56461
           Summary: [4.8 Regression] GCC is leaking lots of memory
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
        AssignedTo: jakub@gcc.gnu.org
        ReportedBy: jakub@gcc.gnu.org


On ARMDisassembler.cpp from llvm at -O2 (first larger *.ii file I tried it on)
cc1plus leaks lots of memory, in many cases clear regressions from 4.7.

[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-02-26 15:53:22 UTC ---
Created attachment 29541
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29541
gcc48-pr56461.patch

The biggest leak there is:
==31825== 1,491,200 bytes in 11,650 blocks are definitely lost in loss record
2,736 of 2,737
==31825==    at 0x4A0881C: malloc (vg_replace_malloc.c:270)
==31825==    by 0x131514F: xrealloc (xmalloc.c:177)
==31825==    by 0xE13FA4: void
va_heap::reserve<_edge_var_map>(vec<_edge_var_map, va_heap, vl_embed>*&,
unsigned int, bool) (vec.h:300)
==31825==    by 0xE13DF9: vec<_edge_var_map, va_heap, vl_ptr>::reserve(unsigned
int, bool) (vec.h:1468)
==31825==    by 0xE13D9A: vec<_edge_var_map, va_heap,
vl_ptr>::reserve_exact(unsigned int) (vec.h:1482)
==31825==    by 0xE13CEE: vec<_edge_var_map, va_heap, vl_ptr>::create(unsigned
int) (vec.h:1497)
==31825==    by 0xE0D5BE: redirect_edge_var_map_add(edge_def*, tree_node*,
tree_node*, unsigned int) (tree-ssa.c:64)
==31825==    by 0xE0D8A5: ssa_redirect_edge(edge_def*, basic_block_def*)
(tree-ssa.c:198)
==31825==    by 0xC7862B: gimple_redirect_edge_and_branch(edge_def*,
basic_block_def*) (tree-cfg.c:5304)
==31825==    by 0x85EC9A: redirect_edge_and_branch(edge_def*, basic_block_def*)
(cfghooks.c:333)
==31825==    by 0xC6F03D: gimple_split_edge(edge_def*) (tree-cfg.c:2475)
==31825==    by 0x85F51A: split_edge(edge_def*) (cfghooks.c:592)
==31825== 
==31825== 2,430,848 bytes in 18,991 blocks are definitely lost in loss record
2,737 of 2,737
==31825==    at 0x4A0881C: malloc (vg_replace_malloc.c:270)
==31825==    by 0x131514F: xrealloc (xmalloc.c:177)
==31825==    by 0xE13FA4: void
va_heap::reserve<_edge_var_map>(vec<_edge_var_map, va_heap, vl_embed>*&,
unsigned int, bool) (vec.h:300)
==31825==    by 0xE13DF9: vec<_edge_var_map, va_heap, vl_ptr>::reserve(unsigned
int, bool) (vec.h:1468)
==31825==    by 0xE13D9A: vec<_edge_var_map, va_heap,
vl_ptr>::reserve_exact(unsigned int) (vec.h:1482)
==31825==    by 0xE13CEE: vec<_edge_var_map, va_heap, vl_ptr>::create(unsigned
int) (vec.h:1497)
==31825==    by 0xE0D5BE: redirect_edge_var_map_add(edge_def*, tree_node*,
tree_node*, unsigned int) (tree-ssa.c:64)
==31825==    by 0xE0D8A5: ssa_redirect_edge(edge_def*, basic_block_def*)
(tree-ssa.c:198)
==31825==    by 0xC7862B: gimple_redirect_edge_and_branch(edge_def*,
basic_block_def*) (tree-cfg.c:5304)
==31825==    by 0x85EC9A: redirect_edge_and_branch(edge_def*, basic_block_def*)
(cfghooks.c:333)
==31825==    by 0xE00E36: ssa_redirect_edges(redirection_data**,
ssa_local_info_t*) (tree-ssa-threadupdate.c:527)
==31825==    by 0xE02F85: void hash_table<redirection_data,
xcallocator>::traverse_noresize<ssa_local_info_t*,
&(ssa_redirect_edges(redirection_data**,
ssa_local_info_t*))>(ssa_local_info_t*) (hash-table.h:859)

Untested fix attached, I think it is a mistake to use a space efficient vector
here (as that means extra heap allocation of void * sized object) and
furthermore the code doesn't care to actually free what it points to.

[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dnovillo at gcc dot gnu.org
   Target Milestone|---                         |4.8.0

[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-02-26 15:58:34 UTC ---
Created attachment 29542
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29542
opts* memory leak fixes

Another thing, something that bothered me for a while and clutters valgrind
--leak-check=full dumps all the time is options handling.  Leaks like:
==1284== 222 bytes in 10 blocks are definitely lost in loss record 393 of 479
==1284==    at 0x4A0881C: malloc (vg_replace_malloc.c:270)
==1284==    by 0x111C627: xmalloc (xmalloc.c:147)
==1284==    by 0x10CC7F9: generate_canonical_option(unsigned long, char const*,
int, cl_decoded_option*) (opts-common.c:279)
==1284==    by 0x10CE089: generate_option(unsigned long, char const*, int,
unsigned int, cl_decoded_option*) (opts-common.c:926)
==1284==    by 0x10CDFA4: handle_generated_option(gcc_options*, gcc_options*,
unsigned long, char const*, int, unsigned int, int, unsigned int, cl_
option_handlers const*, diagnostic_context*) (opts-common.c:903)
==1284==    by 0x10C8846: maybe_default_option(gcc_options*, gcc_options*,
default_options const*, int, bool, bool, bool, unsigned int, cl_option_h
andlers const*, unsigned int, diagnostic_context*) (opts.c:388)
==1284==    by 0x10C88D7: maybe_default_options(gcc_options*, gcc_options*,
default_options const*, int, bool, bool, bool, unsigned int, cl_option_
handlers const*, unsigned int, diagnostic_context*) (opts.c:411)
==1284==    by 0x10C8BA6: default_options_optimization(gcc_options*,
gcc_options*, cl_decoded_option*, unsigned int, unsigned int, unsigned int,
cl_option_handlers const*, diagnostic_context*) (opts.c:590)
==1284==    by 0x95DC47: decode_options(gcc_options*, gcc_options*,
cl_decoded_option*, unsigned int, unsigned int, diagnostic_context*)
(opts-global.c:332)
==1284==    by 0xA50AF4: toplev_main(int, char**) (toplev.c:1936)
==1284==    by 0x10C220F: main (main.c:36)

The attached patch (untested) attempts to deal with that by using an obstack
for the option string allocation where we know we don't want to bother with
figuring out how the strings are allocated.  Using obstack should be tiny bit
faster and more importantly, all the allocated strings will be still reachable,
so valgrind won't complain about them.

[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-02-26 16:00:32 UTC ---
Created attachment 29543
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29543
incpath.c leak fixes

Another place which leaks memory all the time is incpath.c.  Untested fix.

[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-02-26 16:32:18 UTC ---
Created attachment 29544
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29544
gcc48-pr56461-2.patch

Another leak fix, this time in lra.

==31825== 161,960 bytes in 32 blocks are definitely lost in loss record 2,722
of 2,737
==31825==    at 0x4A0881C: malloc (vg_replace_malloc.c:270)
==31825==    by 0x13150A7: xmalloc (xmalloc.c:147)
==31825==    by 0xB09EF3: lra_spill() (lra-spills.c:531)
==31825==    by 0xAEC826: lra(_IO_FILE*) (lra.c:2325)
==31825==    by 0xAA1C98: do_reload() (ira.c:4619)
==31825==    by 0xAA1E9C: rest_of_handle_reload() (ira.c:4731)
==31825==    by 0xB5BB85: execute_one_pass(opt_pass*) (passes.c:2330)
==31825==    by 0xB5BD79: execute_pass_list(opt_pass*) (passes.c:2378)
==31825==    by 0xB5BDAA: execute_pass_list(opt_pass*) (passes.c:2379)
==31825==    by 0x887CC5: expand_function(cgraph_node*) (cgraphunit.c:1640)
==31825==    by 0x888180: expand_all_functions() (cgraphunit.c:1744)
==31825==    by 0x888C0A: compile() (cgraphunit.c:2042)


I see another issue in LRA, but don't have a fix for it yet:
==31825== 1,424 bytes in 1 blocks are definitely lost in loss record 2,273 of
2,737
==31825==    at 0x4A0881C: malloc (vg_replace_malloc.c:270)
==31825==    by 0x131514F: xrealloc (xmalloc.c:177)
==31825==    by 0x5FA554: void va_heap::reserve<int>(vec<int, va_heap,
vl_embed>*&, unsigned int, bool) (vec.h:300)
==31825==    by 0x5FA205: vec<int, va_heap, vl_ptr>::reserve(unsigned int,
bool) (vec.h:1468)
==31825==    by 0x84B952: vec<int, va_heap, vl_ptr>::reserve_exact(unsigned
int) (vec.h:1482)
==31825==    by 0x84B904: vec<int, va_heap, vl_ptr>::create(unsigned int)
(vec.h:1497)
==31825==    by 0xB082A9: lra_create_live_ranges(bool) (lra-lives.c:976)
==31825==    by 0xAEC77E: lra(_IO_FILE*) (lra.c:2295)
==31825==    by 0xAA1C98: do_reload() (ira.c:4619)
==31825==    by 0xAA1E9C: rest_of_handle_reload() (ira.c:4731)
==31825==    by 0xB5BB85: execute_one_pass(opt_pass*) (passes.c:2330)
==31825==    by 0xB5BD79: execute_pass_list(opt_pass*) (passes.c:2378)

I wonder if we shouldn't call
  if (live_p)
    lra_clear_live_ranges ();
before the lra_create_live_ranges (true); call in lra.c (lra), and also call it
when setting live_p to false.  Vlad?

[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory

[vmakarov at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461

--- Comment #5 from Vladimir Makarov <vmakarov at gcc dot gnu.org> 2013-02-26 20:45:57 UTC ---
(In reply to comment #4)
> Created attachment 29544 [details]
> gcc48-pr56461-2.patch
> 

Sorry, I should have checked on leaks when I submitted LRA first time.
The patch is ok.

> Another leak fix, this time in lra.
> 
> ==31825== 161,960 bytes in 32 blocks are definitely lost in loss record 2,722
> of 2,737
> ==31825==    at 0x4A0881C: malloc (vg_replace_malloc.c:270)
> ==31825==    by 0x13150A7: xmalloc (xmalloc.c:147)
> ==31825==    by 0xB09EF3: lra_spill() (lra-spills.c:531)
> ==31825==    by 0xAEC826: lra(_IO_FILE*) (lra.c:2325)
> ==31825==    by 0xAA1C98: do_reload() (ira.c:4619)
> ==31825==    by 0xAA1E9C: rest_of_handle_reload() (ira.c:4731)
> ==31825==    by 0xB5BB85: execute_one_pass(opt_pass*) (passes.c:2330)
> ==31825==    by 0xB5BD79: execute_pass_list(opt_pass*) (passes.c:2378)
> ==31825==    by 0xB5BDAA: execute_pass_list(opt_pass*) (passes.c:2379)
> ==31825==    by 0x887CC5: expand_function(cgraph_node*) (cgraphunit.c:1640)
> ==31825==    by 0x888180: expand_all_functions() (cgraphunit.c:1744)
> ==31825==    by 0x888C0A: compile() (cgraphunit.c:2042)
> 
> 
> I see another issue in LRA, but don't have a fix for it yet:
> ==31825== 1,424 bytes in 1 blocks are definitely lost in loss record 2,273 of
> 2,737
> ==31825==    at 0x4A0881C: malloc (vg_replace_malloc.c:270)
> ==31825==    by 0x131514F: xrealloc (xmalloc.c:177)
> ==31825==    by 0x5FA554: void va_heap::reserve<int>(vec<int, va_heap,
> vl_embed>*&, unsigned int, bool) (vec.h:300)
> ==31825==    by 0x5FA205: vec<int, va_heap, vl_ptr>::reserve(unsigned int,
> bool) (vec.h:1468)
> ==31825==    by 0x84B952: vec<int, va_heap, vl_ptr>::reserve_exact(unsigned
> int) (vec.h:1482)
> ==31825==    by 0x84B904: vec<int, va_heap, vl_ptr>::create(unsigned int)
> (vec.h:1497)
> ==31825==    by 0xB082A9: lra_create_live_ranges(bool) (lra-lives.c:976)
> ==31825==    by 0xAEC77E: lra(_IO_FILE*) (lra.c:2295)
> ==31825==    by 0xAA1C98: do_reload() (ira.c:4619)
> ==31825==    by 0xAA1E9C: rest_of_handle_reload() (ira.c:4731)
> ==31825==    by 0xB5BB85: execute_one_pass(opt_pass*) (passes.c:2330)
> ==31825==    by 0xB5BD79: execute_pass_list(opt_pass*) (passes.c:2378)
> 
> I wonder if we shouldn't call
>   if (live_p)
>     lra_clear_live_ranges ();
> before the lra_create_live_ranges (true); call in lra.c (lra), and also call it
> when setting live_p to false.  Vlad?

Yes, it (the two lines) should be added before  lra_create_live_ranges (true)
otherwise it might be a big leak as live-ranges sometimes big.

Thanks for working on this, Jakub.

[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-02-26 21:13:36 UTC ---
Author: jakub
Date: Tue Feb 26 21:13:27 2013
New Revision: 196294

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196294
Log:
    PR middle-end/56461
    * lra-spills.c (lra_spill): Free spill_hard_reg at the end.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/lra-spills.c

[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-02-27 14:01:20 UTC ---
Author: jakub
Date: Wed Feb 27 14:01:08 2013
New Revision: 196313

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196313
Log:
    PR middle-end/56461
    * tree-flow.h (edge_var_map_vector): Change into va_heap, vl_embed
    vector.
    * tree-ssa.c (redirect_edge_var_map_add): Use vec_safe_reserve and
    vec_safe_push, always update *slot.
    (redirect_edge_var_map_clear): Use vec_free.
    (redirect_edge_var_map_dup): Use vec_safe_copy and vec_safe_reserve.
    (free_var_map_entry): Use vec_free.
    * tree-cfgcleanup.c (remove_forwarder_block_with_phi): Use
    FOR_EACH_VEC_SAFE_ELT instead of FOR_EACH_VEC_ELT.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/tree-cfgcleanup.c
    trunk/gcc/tree-flow.h
    trunk/gcc/tree-ssa.c

[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-02-27 17:25:10 UTC ---
Some more patches have been posted to gcc-patches and I'm going to post even
more.

There are two issues I don't have a solution for if anybody is interested.

Testcase:
cd gcc/testsuite/gcc.dg/vect
valgrind --leak-check=full /usr/src/gcc/obj/gcc/cc1 -O3 -mavx -ftree-vectorize
\ -isystem /usr/src/gcc/obj/gcc/include/ -quiet -o slp-reduc-6.c

==4841== 368 bytes in 2 blocks are definitely lost in loss record 533 of 626
==4841==    at 0x4A06B0F: calloc (vg_replace_malloc.c:593)
==4841==    by 0x111D788: xcalloc (xmalloc.c:162)
==4841==    by 0xC4742D: new_stmt_vec_info(gimple_statement_d*,
_loop_vec_info*, _bb_vec_info*) (tree-vect-stmts.c:5930)
==4841==    by 0xC5452B: vect_create_epilog_for_reduction(vec<tree_node*,
va_heap, vl_ptr>, gimple_statement_d*, int, tree_code, vec<gimple_statement_d*,
va_heap, vl_ptr>, int, bool, _slp_tree*) (tree-vect-loop.c:3867)
==4841==    by 0xC57FDB: vectorizable_reduction(gimple_statement_d*,
gimple_stmt_iterator*, gimple_statement_d**, _slp_tree*)
(tree-vect-loop.c:5209)
==4841==    by 0xC470D1: vect_transform_stmt(gimple_statement_d*,
gimple_stmt_iterator*, bool*, _slp_tree*, _slp_instance*)
(tree-vect-stmts.c:5823)
==4841==    by 0xC594F1: vect_transform_loop(_loop_vec_info*)
(tree-vect-loop.c:5736)
==4841==    by 0xC6B249: vectorize_loops() (tree-vectorizer.c:123)
==4841==    by 0xB91101: tree_vectorize() (tree-ssa-loop.c:222)
==4841==    by 0x963835: execute_one_pass(opt_pass*) (passes.c:2330)
==4841==    by 0x963A29: execute_pass_list(opt_pass*) (passes.c:2378)
==4841==    by 0x963A5A: execute_pass_list(opt_pass*) (passes.c:2379)
==4841== 
==4841== 13,678 bytes in 1 blocks are definitely lost in loss record 619 of 626
==4841==    at 0x4A0881C: malloc (vg_replace_malloc.c:270)
==4841==    by 0x111D747: xmalloc (xmalloc.c:147)
==4841==    by 0x10E6CD4: read_file(cpp_reader*, _cpp_file*) (files.c:693)
==4841==    by 0x10E787A: _cpp_stack_file (files.c:794)
==4841==    by 0x10DF510: do_include_common(cpp_reader*, include_type)
(directives.c:793)
==4841==    by 0x10E0320: _cpp_handle_directive (directives.c:492)
==4841==    by 0x10ECC6C: _cpp_lex_token (lex.c:1990)
==4841==    by 0x10F1967: cpp_get_token_1(cpp_reader*, unsigned int*)
(macro.c:2355)
==4841==    by 0x5CE3AA: c_lex_with_flags(tree_node**, unsigned int*, unsigned
char*, int) (c-lex.c:300)
==4841==    by 0x568908: c_lex_one_token(c_parser*, c_token*) (c-parser.c:218)
==4841==    by 0x568D07: c_parser_peek_token(c_parser*) (c-parser.c:398)
==4841==    by 0x568D32: c_parser_next_token_is(c_parser*, cpp_ttype)
(c-parser.c:410)

[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory

[steven at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461

Steven Bosscher <steven at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-02-27
     Ever Confirmed|0                           |1

[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-02-27 21:33:28 UTC ---
Author: jakub
Date: Wed Feb 27 21:33:20 2013
New Revision: 196319

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196319
Log:
    PR middle-end/56461
    * ipa-reference.c (propagate): Free node_info even for alias nodes.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/ipa-reference.c

[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-02-27 21:34:35 UTC ---
Author: jakub
Date: Wed Feb 27 21:34:27 2013
New Revision: 196320

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196320
Log:
    PR middle-end/56461
    * ipa-cp.c (decide_whether_version_node): Call vec_free on
    known_aggs[i].items and release known_aggs vector.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/ipa-cp.c

[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-02-27 21:35:17 UTC ---
Author: jakub
Date: Wed Feb 27 21:35:06 2013
New Revision: 196321

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196321
Log:
    PR middle-end/56461
    * df-scan.c (df_insn_delete): Use df_scan_free_mws_vec before
    pool_free.
    (df_insn_rescan_debug_internal): Use df_scan_free_mws_vec before
    overwriting it.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/df-scan.c

[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-02-27 21:36:09 UTC ---
Author: jakub
Date: Wed Feb 27 21:35:53 2013
New Revision: 196322

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196322
Log:
    PR middle-end/56461
    * ipa-pure-const.c (propagate): Use FOR_EACH_FUNCTION instead of
    FOR_EACH_DEFINED_FUNCTION when freeing state.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/ipa-pure-const.c

[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461

--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-02-27 21:41:03 UTC ---
Author: jakub
Date: Wed Feb 27 21:40:53 2013
New Revision: 196323

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196323
Log:
    PR middle-end/56461
    * tree-vect-loop.c (vectorizable_reduction): Release vect_defs
    vector.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/tree-vect-loop.c

[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461

--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-02-27 22:05:46 UTC ---
Author: jakub
Date: Wed Feb 27 22:05:33 2013
New Revision: 196324

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196324
Log:
    PR middle-end/56461
    * tree-ssa-loop-niter.c (maybe_lower_iteration_bound): Call
    pointer_set_destroy on not_executed_last_iteration.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/tree-ssa-loop-niter.c

[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461

--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-02-27 22:06:39 UTC ---
Author: jakub
Date: Wed Feb 27 22:06:21 2013
New Revision: 196325

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196325
Log:
    PR middle-end/56461
    * tree-vect-data-refs.c (vect_permute_load_chain): Avoid using copy
    method on dr_chain and result_chain.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/tree-vect-data-refs.c

[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461

--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-02-28 21:20:34 UTC ---
Author: jakub
Date: Thu Feb 28 21:20:26 2013
New Revision: 196360

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196360
Log:
    PR middle-end/56461
    * tree-vectorizer.h (vect_get_slp_defs): Change 3rd argument
    type to vec<vec<tree> > *.
    * tree-vect-slp.c (vect_get_slp_defs): Likewise.  Change vec_defs
    to be vec<tree> instead of vec<tree> *, set vec_defs
    to vNULL and call vec_defs.create (number_of_vects), adjust other
    uses of vec_defs.
    * tree-vect-stmts.c (vect_get_vec_defs, vectorizable_call,
    vectorizable_condition): Adjust vect_get_slp_defs callers.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/tree-vect-slp.c
    trunk/gcc/tree-vect-stmts.c
    trunk/gcc/tree-vectorizer.h

[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461

--- Comment #17 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-03-01 20:59:07 UTC ---
Author: jakub
Date: Fri Mar  1 20:58:59 2013
New Revision: 196393

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196393
Log:
    PR middle-end/56461
    * tree-vect-stmts.c (vect_create_vectorized_promotion_stmts): Call
    vec_oprnds0->release (); rather than vec_oprnds0->truncate (0)
    before overwriting it.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/tree-vect-stmts.c

[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461

--- Comment #18 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-03-01 21:06:13 UTC ---
Author: jakub
Date: Fri Mar  1 21:06:04 2013
New Revision: 196394

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196394
Log:
    PR middle-end/56461
    * files.c (_cpp_save_file_entries): Free result at the end.
    * pch.c (cpp_string_free): New function.
    (cpp_save_state): Use it in htab_create call.
    (cpp_write_pch_deps): Free ss->defs.  Destroy ss->definedhash.

Modified:
    trunk/libcpp/ChangeLog
    trunk/libcpp/files.c
    trunk/libcpp/pch.c

[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461

--- Comment #19 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-03-01 22:54:46 UTC ---
Author: jakub
Date: Fri Mar  1 22:54:39 2013
New Revision: 196396

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196396
Log:
    PR middle-end/56461
    * tree-vect-data-refs.c (vect_permute_store_chain): Avoid using copy
    method on dr_chain and result_chain.
    * tree-vect-stmts.c (vectorizable_store): Only call
    result_chain.create if j == 0.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/tree-vect-data-refs.c
    trunk/gcc/tree-vect-stmts.c

[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461

--- Comment #20 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-03-01 22:55:38 UTC ---
Author: jakub
Date: Fri Mar  1 22:55:26 2013
New Revision: 196397

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196397
Log:
    PR middle-end/56461
    * ira-build.c (ira_loop_nodes_count): New variable.
    (create_loop_tree_nodes): Initialize it.
    (finish_loop_tree_nodes): Use it instead of looking at current_loops.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/ira-build.c

[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461

--- Comment #21 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-03-01 22:56:34 UTC ---
Author: jakub
Date: Fri Mar  1 22:56:18 2013
New Revision: 196398

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196398
Log:
    PR middle-end/56461
    * tree-ssa-loop-ivcanon.c (tree_estimate_loop_size): Release path
    vector even when returning true.  Fix up function comment formatting.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/tree-ssa-loop-ivcanon.c

[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461

--- Comment #22 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-03-04 10:02:36 UTC ---
Author: jakub
Date: Mon Mar  4 10:02:26 2013
New Revision: 196424

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196424
Log:
    PR middle-end/56461
    * tree-vect-loop.c (destroy_loop_vec_info): For !clean_stmts, just
    set nbbs to 0 instead of having separate code path.
    (vect_analyze_loop_form): Call destroy_loop_vec_info with true
    instead of false as last argument if returning NULL.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/tree-vect-loop.c

[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461

--- Comment #23 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-03-04 10:06:27 UTC ---
Author: jakub
Date: Mon Mar  4 10:06:22 2013
New Revision: 196425

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196425
Log:
    PR middle-end/56461
    * tree-vect-stmts.c (vectorizable_shift): Don't call create methods
    on vec_oprnds0 or vec_oprnds1 before loop, only call it on
    vec_oprnds1 right before pushing anything to it for
    scalar_shift_arg.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/tree-vect-stmts.c

[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461

--- Comment #24 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-03-04 10:08:05 UTC ---
Author: jakub
Date: Mon Mar  4 10:08:01 2013
New Revision: 196426

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196426
Log:
    PR middle-end/56461
    * tree-vect-stmts.c (vectorizable_conversion): Don't call
    vec_oprnds0.create (1) for modifier == NONE.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/tree-vect-stmts.c

[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461

--- Comment #25 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-03-04 10:09:05 UTC ---
Author: jakub
Date: Mon Mar  4 10:08:57 2013
New Revision: 196427

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196427
Log:
    PR middle-end/56461
    * tree-loop-distribution.c (ldist_gen): Call partition_free after each
    partitions.ordered_remove.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/tree-loop-distribution.c

[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461

--- Comment #26 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-03-04 21:52:15 UTC ---
Author: jakub
Date: Mon Mar  4 21:52:08 2013
New Revision: 196445

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196445
Log:
    PR middle-end/56461
    * diagnostic.c (diagnostic_append_note): Save and restore old prefix.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/diagnostic.c

[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461

--- Comment #27 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-03-05 06:02:46 UTC ---
Author: jakub
Date: Tue Mar  5 06:02:36 2013
New Revision: 196450

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196450
Log:
    PR middle-end/56461
    * sel-sched-ir.c (free_sched_pools): Release
    succs_info_pool.stack[succs_info_pool.max_top] vectors too
    if succs_info_pool.max_top isn't -1.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/sel-sched-ir.c

[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461

--- Comment #28 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-03-05 09:38:03 UTC ---
Author: jakub
Date: Tue Mar  5 09:37:56 2013
New Revision: 196453

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196453
Log:
    PR middle-end/56461
    * tree-vect-stmts.c (free_stmt_vec_info_vec): Call
    free_stmt_vec_info on any left-over stmt_vec_info in the vector.
    * tree-vect-loop.c (vect_create_epilog_for_reduction): Release
    inner_phis vector.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/tree-vect-loop.c
    trunk/gcc/tree-vect-stmts.c

[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461

--- Comment #30 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-03-05 09:39:49 UTC ---
Author: jakub
Date: Tue Mar  5 09:39:43 2013
New Revision: 196455

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196455
Log:
    PR middle-end/56461
    * tree-vect-slp.c (vect_supported_load_permutation_p): Free
    load_index sbitmap even if some bit in it isn't set.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/tree-vect-slp.c

[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461

--- Comment #29 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-03-05 09:38:52 UTC ---
Author: jakub
Date: Tue Mar  5 09:38:48 2013
New Revision: 196454

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196454
Log:
    PR middle-end/56461
    * tree-ssa-loop-niter.c (bb_queue): Remove typedef.
    (discover_iteration_bound_by_body_walk): Change queues to
    vec<vec<basic_block> > and queue to vec<basic_block>.  Fix up
    spelling in comment.  Call safe_push on queues[bound_index] directly.
    Release queues[queue_index] in every iteration unconditionally.
    Release bounds vector.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/tree-ssa-loop-niter.c

[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #31 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-03-05 12:01:44 UTC ---
I'm going to close this now, the lots has certainly decreased.
I have still
http://gcc.gnu.org/ml/gcc-patches/2013-02/msg01197.html
http://gcc.gnu.org/ml/gcc-patches/2013-02/msg01239.html
http://gcc.gnu.org/ml/gcc-patches/2013-02/msg01341.html
http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00044.html
memory leak fixes waiting for review, but with those and what is already in
trunk e.g. none of the gcc.dg/vect/*.c tests leak any memory on x86_64-linux
with -O3 -mavx.

[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461

--- Comment #32 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-03-05 15:49:55 UTC ---
Author: jakub
Date: Tue Mar  5 15:49:43 2013
New Revision: 196467

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196467
Log:
    PR middle-end/56461
    * sched-deps.c (delete_dep_node): Free DEP_REPLACE.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/sched-deps.c

[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461

--- Comment #34 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-03-05 15:52:02 UTC ---
Author: jakub
Date: Tue Mar  5 15:51:48 2013
New Revision: 196469

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196469
Log:
    PR middle-end/56461
    * ggc-common.c (gt_pch_save): For ENABLE_VALGRIND_CHECKING,
    if VALGRIND_GET_VBITS is defined, temporarily make object
    memory all defined, and restore previous valgrind addressability
    and definability afterwards.  Free this_object at the end.

    * c-pch.c (pch_init): Free target_validity at the end.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/c-family/ChangeLog
    trunk/gcc/c-family/c-pch.c
    trunk/gcc/ggc-common.c

[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461

--- Comment #33 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-03-05 15:50:52 UTC ---
Author: jakub
Date: Tue Mar  5 15:50:38 2013
New Revision: 196468

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196468
Log:
    PR middle-end/56461
    * lra.c (lra): Call lra_clear_live_ranges if live_p,
    right before calling lra_create_live_ranges, also call it
    when clearing live_p.  Only call lra_clear_live_ranges
    at the end if live_p.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/lra.c

[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461

--- Comment #35 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-03-06 16:18:51 UTC ---
Author: jakub
Date: Wed Mar  6 16:18:40 2013
New Revision: 196497

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196497
Log:
    PR middle-end/56461
    * internal.h (struct cpp_buffer): Add to_free field.
    (_cpp_pop_file_buffer): Add third argument.
    * files.c (_cpp_stack_file): Set buffer->to_free.
    (_cpp_pop_file_buffer): Add to_free argument.  Free to_free
    if non-NULL, and if equal to file->buffer_start, also clear
    file->buffer{,_start,_valid}.
    * directives.c (_cpp_pop_buffer): Pass buffer->to_free
    to _cpp_pop_file_buffer.

Modified:
    trunk/libcpp/ChangeLog
    trunk/libcpp/directives.c
    trunk/libcpp/files.c
    trunk/libcpp/internal.h