[Bug fortran/34828] ICE: GNU MP: Cannot reallocate memory for gfortran.dg/parameter_array_init_3.f90

["jvdelisle at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #17 from jvdelisle at gcc dot gnu dot org  2008-05-26 17:05 -------
With the test case in comment#16 on x86-64-linux-gnu, I see this:

==11143== 416 bytes in 52 blocks are definitely lost in loss record 5 of 14
==11143==    at 0x4A059F6: malloc (vg_replace_malloc.c:149)
==11143==    by 0x3FDCC07EF8: __gmp_default_allocate (in
/usr/lib64/libgmp.so.3.4.2)
==11143==    by 0x3FDCC18050: __gmpz_init_set (in /usr/lib64/libgmp.so.3.4.2)
==11143==    by 0x4232A7: gfc_copy_shape (expr.c:338)
==11143==    by 0x42331D: gfc_copy_expr (expr.c:515)
==11143==    by 0x425266: simplify_parameter_variable (expr.c:1526)
==11143==    by 0x425003: gfc_simplify_expr (expr.c:1641)
==11143==    by 0x409F2F: expand_constructor (array.c:1437)
==11143==    by 0x40A063: gfc_get_array_element (array.c:1791)
==11143==    by 0x40B2FE: gfc_expand_constructor (array.c:1462)
==11143==    by 0x45DBC9: gfc_resolve_expr (resolve.c:4337)
==11143==    by 0x40B1CA: gfc_resolve_array_constructor (array.c:1572)
==11143== 
==11143== 
==11143== 632 bytes in 4 blocks are definitely lost in loss record 6 of 14
==11143==    at 0x4A04D1F: calloc (vg_replace_malloc.c:279)
==11143==    by 0xB4304A: xcalloc (xmalloc.c:162)
==11143==    by 0x55B877: init_emit (emit-rtl.c:5012)
==11143==    by 0x5F3E62: prepare_function_start (function.c:3906)
==11143==    by 0x5F5E98: init_function_start (function.c:3953)
==11143==    by 0x492BDD: trans_function_start (trans-decl.c:1618)
==11143==    by 0x499D6D: gfc_generate_function_code (trans-decl.c:3218)
==11143==    by 0x45570B: gfc_parse_file (parse.c:3585)
==11143==    by 0x47D81D: gfc_be_parse_file (f95-lang.c:258)
==11143==    by 0x6E49F1: toplev_main (toplev.c:965)
==11143==    by 0x3FF061E073: (below main) (libc-start.c:220)
==11143== 
==11143== 
==11143== 1,224 bytes in 9 blocks are definitely lost in loss record 8 of 14
==11143==    at 0x4A059F6: malloc (vg_replace_malloc.c:149)
==11143==    by 0xB4300B: xrealloc (xmalloc.c:177)
==11143==    by 0x8CAC80: vec_heap_o_reserve_1 (vec.c:176)
==11143==    by 0x50609D: insn_locators_alloc (vecprim.h:27)
==11143==    by 0xA9C778: tree_expand_cfg (cfgexpand.c:1850)
==11143==    by 0x6686D6: execute_one_pass (passes.c:1284)
==11143==    by 0x6688D0: execute_pass_list (passes.c:1334)
==11143==    by 0x74A705: tree_rest_of_compilation (tree-optimize.c:421)
==11143==    by 0x8FA841: cgraph_expand_function (cgraphunit.c:1148)
==11143==    by 0x8FC5E3: cgraph_assemble_pending_functions (cgraphunit.c:514)
==11143==    by 0x8FBB34: cgraph_finalize_function (cgraphunit.c:632)
==11143==    by 0x49AFF5: gfc_generate_function_code (trans-decl.c:3481)
==11143== 
==11143== 
==11143== 62,028 (26,528 direct, 35,500 indirect) bytes in 348 blocks are
definitely lost in loss record 12 of 14
==11143==    at 0x4A059F6: malloc (vg_replace_malloc.c:149)
==11143==    by 0xB43097: xmalloc (xmalloc.c:147)
==11143==    by 0x52A7F2: df_install_refs (df-scan.c:2454)
==11143==    by 0x52AA8D: df_refs_add_to_chains (df-scan.c:2580)
==11143==    by 0x52E0CF: df_record_exit_block_uses (df-scan.c:3950)
==11143==    by 0x52F5E0: df_scan_blocks (df-scan.c:604)
==11143==    by 0x51EF4D: rest_of_handle_df_initialize (df-core.c:743)
==11143==    by 0x6686D6: execute_one_pass (passes.c:1284)
==11143==    by 0x6688D0: execute_pass_list (passes.c:1334)
==11143==    by 0x6688E4: execute_pass_list (passes.c:1335)
==11143==    by 0x74A705: tree_rest_of_compilation (tree-optimize.c:421)
==11143==    by 0x8FA841: cgraph_expand_function (cgraphunit.c:1148)
==11143== 
==11143== LEAK SUMMARY:
==11143==    definitely lost: 28,800 bytes in 413 blocks.
==11143==    indirectly lost: 35,500 bytes in 347 blocks.
==11143==      possibly lost: 64 bytes in 2 blocks.
==11143==    still reachable: 298,303 bytes in 1,048 blocks.
==11143==         suppressed: 0 bytes in 0 blocks.

Notice the similarity in the second trace hunk to that found in pr36214.  Also,
the first trace hunk shown here, I have not seen before and involves
simplify_parameter_variable.  This may be the clue we need.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34828