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)
==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
