Bernhard Fischer wrote:
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. */
No, this does not fix it.
Jerry
