On Fri, Jan 11, 2008 at 11:30:12AM -0800, Jerry DeLisle wrote:
> With the Fortran test case I am using for PR34722. I did a valgrind check
> with the following command:
>
> valgrind --leak-check=full f951 inquire_12.f90
>
> The possible problem in mpfr has been around a while.
>
> The other two problems look like middle-end or back-end problems. Does
> this warrant a PR? Against what component?
>
> Using built-in specs.
> Target: x86_64-unknown-linux-gnu
> Configured with: ../gcc43/configure --prefix=/home/jerry/gcc/usr
> --enable-languages=c,fortran --disable-libmudflap --enable-libgomp
> --with-mpfr-lib=/home/jerry/gcc/usr/lib
> --with-mpfr-include=/home/jerry/gcc/usr/include --disable-bootstrap
> Thread model: posix
> gcc version 4.3.0 20080111 (experimental) [trunk revision 131004] (GCC)
>
> I get the following:
>
> ==14240== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 5 from 1)
> ==14240== malloc/free: in use at exit: 310,961 bytes in 1,036 blocks.
> ==14240== malloc/free: 2,207 allocs, 1,171 frees, 1,296,169 bytes allocated.
> ==14240== For counts of detected errors, rerun with: -v
> ==14240== searching for pointers to 1,036 not-freed blocks.
> ==14240== checked 2,346,928 bytes.
> ==14240==
> ==14240== 64 bytes in 2 blocks are possibly lost in loss record 1 of 8
> ==14240== at 0x4A059F6: malloc (vg_replace_malloc.c:149)
> ==14240== by 0xB2F778: __gmp_default_allocate (in /mnt/sdb2/obj43/gcc/f951)
> ==14240== by 0x4C2B62D: mpfr_init2 (init2.c:53)
> ==14240== by 0x4C34424: mpfr_cache (cache.c:57)
> ==14240== by 0x4C18E48: mpfr_log (log.c:133)
> ==14240== by 0x4C2A4D1: mpfr_log10 (log10.c:111)
> ==14240== by 0x40A29F: gfc_arith_init_1 (arith.c:165)
> ==14240== by 0x443BC2: gfc_init_1 (misc.c:259)
> ==14240== by 0x47684D: gfc_init (f95-lang.c:288)
> ==14240== by 0x6D74F4: toplev_main (toplev.c:2128)
> ==14240== by 0x3B7EC1E073: (below main) (in /lib64/libc-2.7.so)
> ==14240==
> ==14240==
> ==14240== 408 bytes in 3 blocks are definitely lost in loss record 2 of 8
> ==14240== at 0x4A059F6: malloc (vg_replace_malloc.c:149)
> ==14240== by 0xB1B4DB: xrealloc (xmalloc.c:177)
> ==14240== by 0x8B1265: vec_heap_o_reserve_1 (vec.c:176)
> ==14240== by 0x4FC09D: insn_locators_alloc (vecprim.h:27)
> ==14240== by 0xA759F8: tree_expand_cfg (cfgexpand.c:1862)
> ==14240== by 0x65C925: execute_one_pass (passes.c:1118)
> ==14240== by 0x65CAEB: execute_pass_list (passes.c:1171)
> ==14240== by 0x735345: tree_rest_of_compilation (tree-optimize.c:404)
> ==14240== by 0x8E55E1: cgraph_expand_function (cgraphunit.c:1152)
> ==14240== by 0x8E73C3: cgraph_assemble_pending_functions (cgraphunit.c:523)
> ==14240== by 0x8E6894: cgraph_finalize_function (cgraphunit.c:640)
> ==14240== by 0x49368B: gfc_generate_function_code (trans-decl.c:3403)
Didn't look, but perhaps something like this?
I don't see where locations_locators_locs and locations_locators_vals
are freed either, but they seem to still be in use after locators_finalize...
Index: gcc-4.3/gcc/cfglayout.c
===================================================================
--- gcc-4.3/gcc/cfglayout.c (revision 131470)
+++ gcc-4.3/gcc/cfglayout.c (working copy)
@@ -274,6 +274,9 @@ insn_locators_finalize (void)
if (curr_rtl_loc >= 0)
epilogue_locator = curr_insn_locator ();
curr_rtl_loc = -1;
+
+ VEC_free (int, heap, block_locators_locs);
+ VEC_free (tree, gc, block_locators_blocks);
}
/* Set current location. */
> ==14240==
> ==14240==
> ==14240== 5,672 (5,224 direct, 448 indirect) bytes in 71 blocks are
> definitely lost in loss record 4 of 8
> ==14240== at 0x4A059F6: malloc (vg_replace_malloc.c:149)
> ==14240== by 0xB1B567: xmalloc (xmalloc.c:147)
> ==14240== by 0x51E842: df_install_refs (df-scan.c:2425)
> ==14240== by 0x51EADA: df_refs_add_to_chains (df-scan.c:2551)
> ==14240== by 0x52029F: df_record_exit_block_uses (df-scan.c:3808)
> ==14240== by 0x5218D0: df_scan_blocks (df-scan.c:597)
> ==14240== by 0x51499D: rest_of_handle_df_initialize (df-core.c:742)
> ==14240== by 0x65C925: execute_one_pass (passes.c:1118)
> ==14240== by 0x65CAEB: execute_pass_list (passes.c:1171)
> ==14240== by 0x65CAFD: execute_pass_list (passes.c:1172)
> ==14240== by 0x735345: tree_rest_of_compilation (tree-optimize.c:404)
> ==14240== by 0x8E55E1: cgraph_expand_function (cgraphunit.c:1152)
> ==14240==
> ==14240== LEAK SUMMARY:
> ==14240== definitely lost: 5,632 bytes in 74 blocks.
> ==14240== indirectly lost: 448 bytes in 2 blocks.
> ==14240== possibly lost: 64 bytes in 2 blocks.
> ==14240== still reachable: 304,817 bytes in 958 blocks.
> ==14240== suppressed: 0 bytes in 0 blocks.
> ==14240== Reachable blocks (those to which a pointer was found) are not shown.
> ==14240== To see them, rerun with: --leak-check=full --show-reachable=yes
>
