[Bug fortran/35892] gfortran lost memory blocks
jvdelisle at gcc dot gnu dot org
gcc-bugzilla@gcc.gnu.org
Sat Apr 19 21:12:00 GMT 2008
------- Comment #17 from jvdelisle at gcc dot gnu dot org 2008-04-19 21:12 -------
I am reopening this PR. In my further attempts to reduce the test case here to
help with the "apparent" problem with PR35154 I have discovered two things:
1. The test case can only be reduced slightly before the problem appears to go
away, meaning no ICE.
2. Valgrind shows significant problems with the test case even with the patch
to PR35154 reverted in trans-common.c
I have changed the title of this PR to reflect this. I will check this on 4.3
to see if this is a regression.
==4942== 106 bytes in 1 blocks are possibly lost in loss record 2 of 17
==4942== at 0x4A059F6: malloc (vg_replace_malloc.c:149)
==4942== by 0xB3A3C7: xmalloc (xmalloc.c:147)
==4942== by 0x446AF4: gfc_getmem (misc.c:37)
==4942== by 0x43A854: gfc_match_format (io.c:1020)
==4942== by 0x44F8E2: match_word (parse.c:64)
==4942== by 0x45056A: decode_statement (parse.c:370)
==4942== by 0x450F3A: next_statement (parse.c:653)
==4942== by 0x45217B: parse_executable (parse.c:2923)
==4942== by 0x4535C8: parse_progunit (parse.c:3240)
==4942== by 0x4538C8: parse_contained (parse.c:3157)
==4942== by 0x453EF2: gfc_parse_file (parse.c:3406)
==4942== by 0x47AA5D: gfc_be_parse_file (f95-lang.c:258)
==4942==
==4942==
==4942== 280 bytes in 35 blocks are definitely lost in loss record 5 of 17
==4942== at 0x4A059F6: malloc (vg_replace_malloc.c:149)
==4942== by 0x3FDCC07EF8: __gmp_default_allocate (in
/usr/lib64/libgmp.so.3.4.2)
==4942== by 0x3FDCC16FD7: __gmpz_init (in /usr/lib64/libgmp.so.3.4.2)
==4942== by 0x418746: top_val_list (decl.c:422)
==4942== by 0x41A3BC: gfc_match_data (decl.c:535)
==4942== by 0x44F8E2: match_word (parse.c:64)
==4942== by 0x450396: decode_statement (parse.c:348)
==4942== by 0x450F3A: next_statement (parse.c:653)
==4942== by 0x452DFB: parse_spec (parse.c:2167)
==4942== by 0x453C95: gfc_parse_file (parse.c:3397)
==4942== by 0x47AA5D: gfc_be_parse_file (f95-lang.c:258)
==4942== by 0x6DD570: toplev_main (toplev.c:962)
==4942==
==4942==
==4942== 1,580 bytes in 10 blocks are definitely lost in loss record 7 of 17
==4942== at 0x4A04D1F: calloc (vg_replace_malloc.c:279)
==4942== by 0xB3A37A: xcalloc (xmalloc.c:162)
==4942== by 0x555A27: init_emit (emit-rtl.c:5014)
==4942== by 0x5ED472: prepare_function_start (function.c:3906)
==4942== by 0x5EF4A8: init_function_start (function.c:3953)
==4942== by 0x48FACD: trans_function_start (trans-decl.c:1601)
==4942== by 0x49685D: gfc_generate_function_code (trans-decl.c:3106)
==4942== by 0x47DDA1: gfc_generate_module_code (trans.c:1208)
==4942== by 0x453D6B: gfc_parse_file (parse.c:3577)
==4942== by 0x47AA5D: gfc_be_parse_file (f95-lang.c:258)
==4942== by 0x6DD570: toplev_main (toplev.c:962)
==4942== by 0x3FF061E073: (below main) (libc-start.c:220)
==4942==
==4942==
==4942== 2,040 bytes in 15 blocks are definitely lost in loss record 8 of 17
==4942== at 0x4A059F6: malloc (vg_replace_malloc.c:149)
==4942== by 0xB3A33B: xrealloc (xmalloc.c:177)
==4942== by 0x8C7140: vec_heap_o_reserve_1 (vec.c:176)
==4942== by 0x50190D: insn_locators_alloc (vecprim.h:27)
==4942== by 0xA95D58: tree_expand_cfg (cfgexpand.c:1851)
==4942== by 0x661C68: execute_one_pass (passes.c:1136)
==4942== by 0x661E80: execute_pass_list (passes.c:1191)
==4942== by 0x742BA5: tree_rest_of_compilation (tree-optimize.c:420)
==4942== by 0x8FC121: cgraph_expand_function (cgraphunit.c:1157)
==4942== by 0x8FDF23: cgraph_assemble_pending_functions (cgraphunit.c:523)
==4942== by 0x8FD3F4: cgraph_finalize_function (cgraphunit.c:641)
==4942== by 0x497AED: gfc_generate_function_code (trans-decl.c:3371)
==4942==
==4942==
==4942== 3,680 bytes in 10 blocks are definitely lost in loss record 9 of 17
==4942== at 0x4A05AF7: realloc (vg_replace_malloc.c:306)
==4942== by 0xB3A32C: xrealloc (xmalloc.c:179)
==4942== by 0x8C7140: vec_heap_o_reserve_1 (vec.c:176)
==4942== by 0x501B2B: curr_insn_locator (vecprim.h:27)
==4942== by 0x556747: make_insn_raw (emit-rtl.c:3381)
==4942== by 0x5567B5: emit_insn (emit-rtl.c:4407)
==4942== by 0xA039DE: gen_movdi (i386.md:2088)
==4942== by 0x58AF92: emit_move_insn_1 (expr.c:3192)
==4942== by 0x58B302: emit_move_insn (expr.c:3417)
==4942== by 0x564085: force_reg (explow.c:647)
==4942== by 0x56479D: memory_address (explow.c:487)
==4942== by 0x57D951: expand_expr_real_1 (expr.c:7470)
==4942==
==4942==
==4942== 2,725,238 (690,656 direct, 2,034,582 indirect) bytes in 21,087 blocks
are definitely lost in loss record 16 of 17
==4942== at 0x4A059F6: malloc (vg_replace_malloc.c:149)
==4942== by 0xB3A3C7: xmalloc (xmalloc.c:147)
==4942== by 0x524A82: df_install_refs (df-scan.c:2448)
==4942== by 0x524D1A: df_refs_add_to_chains (df-scan.c:2574)
==4942== by 0x52652F: df_record_exit_block_uses (df-scan.c:3914)
==4942== by 0x527BF0: df_scan_blocks (df-scan.c:602)
==4942== by 0xACC3C6: rest_of_handle_global_alloc (global.c:1810)
==4942== by 0x661C68: execute_one_pass (passes.c:1136)
==4942== by 0x661E80: execute_pass_list (passes.c:1191)
==4942== by 0x661E94: execute_pass_list (passes.c:1192)
==4942== by 0x742BA5: tree_rest_of_compilation (tree-optimize.c:420)
==4942== by 0x8FC121: cgraph_expand_function (cgraphunit.c:1157)
==4942==
==4942== LEAK SUMMARY:
==4942== definitely lost: 698,236 bytes in 21,157 blocks.
==4942== indirectly lost: 2,034,582 bytes in 15,440 blocks.
==4942== possibly lost: 170 bytes in 3 blocks.
==4942== still reachable: 696,144 bytes in 3,488 blocks.
==4942== suppressed: 0 bytes in 0 blocks.
==4942== Reachable blocks (those to which a pointer was found) are not shown.
==4942== To see them, rerun with: --leak-check=full --show-reachable=yes
--
jvdelisle at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Keywords|ice-on-valid-code |
Resolution|FIXED |
Summary|[4.4 regression] gfortran |gfortran lost memory blocks
|dies on file containing |
|module and common |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35892
More information about the Gcc-bugs
mailing list