From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15707 invoked by alias); 19 Apr 2008 21:12:55 -0000 Received: (qmail 15562 invoked by uid 48); 19 Apr 2008 21:12:13 -0000 Date: Sat, 19 Apr 2008 21:12:00 -0000 Message-ID: <20080419211213.15561.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug fortran/35892] gfortran lost memory blocks In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "jvdelisle at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2008-04/txt/msg01360.txt.bz2 ------- 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