[Bug fortran/35892] New: gfortran dies on file containing module and common

[Bug fortran/35892] New: gfortran dies on file containing module and common

[KnowlesPJ at Cardiff dot ac dot uk]

Compilation with -O0 -g causes the compiler to crash:

/opt/gcc/bin/gfortran -c -fno-second-underscore -fdefault-integer-8 -m64 -g -O0
--save-temps f12_integrals.f
f12_integrals.f: In function 'f12_integrals_raw':
f12_integrals.f:980: internal compiler error: in expand_expr_real_1, at
expr.c:7258
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
Using built-in specs.
Target: i386-apple-darwin9.2.2
Configured with: ../configure --prefix=/opt/gcc --enable-languages=c,fortran :
(reconfigured) ../configure --prefix=/opt/gcc --enable-languages=c,fortran
--no-create --no-recursion
Thread model: posix
gcc version 4.4.0 20080409 (experimental) (GCC) 

Although gcc -v reports 'i386' this is in fact an x86_64. But compiling on a
true ia32 (and omitting -m64) produces the same crash.

With -g removed or -O1 the compiler completes. However we are getting wrong
results, so perhaps the place to start is with the crash and then try again?


-- 
           Summary: gfortran dies on file containing module and common
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: KnowlesPJ at Cardiff dot ac dot uk
  GCC host triplet: i386-apple-darwin9.2.2
GCC target triplet: i386-apple-darwin9.2.2


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

[Bug fortran/35892] gfortran dies on file containing module and common

[KnowlesPJ at Cardiff dot ac dot uk]

------- Comment #1 from KnowlesPJ at Cardiff dot ac dot uk  2008-04-09 17:24 -------
Created an attachment (id=15458)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15458&action=view)
Fortran source code


-- 


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

[Bug fortran/35892] [4.4 regression] gfortran dies on file containing module and common

[burnus at gcc dot gnu dot org]

------- Comment #2 from burnus at gcc dot gnu dot org  2008-04-09 18:31 -------
Confirm. Seems to be introduced between 2008-04-03-r133863 and
2008-03-27-r133632. I tried to reduce the test case -- and I failed. I think
somewhere the memory gets corrupted.


==1454== Invalid read of size 2
==1454==    at 0x5CEB69: fold_binary (fold-const.c:9920)
==1454==    by 0x5D8188: fold_build2_stat (fold-const.c:13441)
==1454==    by 0x4A7752: gfc_conv_expr_op (trans-expr.c:1229)
==1454==    by 0x4A6117: gfc_conv_expr_val (trans-expr.c:3612)
==1454==    by 0x4A986B: gfc_conv_intrinsic_function_args
(trans-intrinsic.c:193)
==1454==    by 0x4B13A0: gfc_conv_intrinsic_minmax (trans-intrinsic.c:1442)
==1454==    by 0x4B27F0: gfc_conv_intrinsic_function (trans-intrinsic.c:4309)


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   GCC host triplet|i386-apple-darwin9.2.2      |
 GCC target triplet|i386-apple-darwin9.2.2      |
           Keywords|                            |ice-on-valid-code
      Known to fail|                            |4.4.0
      Known to work|                            |4.3.0 4.2.3
           Priority|P3                          |P4
   Last reconfirmed|0000-00-00 00:00:00         |2008-04-09 18:31:35
               date|                            |
            Summary|gfortran dies on file       |[4.4 regression] gfortran
                   |containing module and common|dies on file containing
                   |                            |module and common
   Target Milestone|---                         |4.4.0


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

[Bug fortran/35892] [4.4 regression] gfortran dies on file containing module and common

[tkoenig at gcc dot gnu dot org]

------- Comment #3 from tkoenig at gcc dot gnu dot org  2008-04-13 20:45 -------
Interesting.  Running with valgrind produces an ICE:

$ valgrind  ~/libexec/gcc/i686-pc-linux-gnu/4.4.0/f951 foo.f90 
==3891== Memcheck, a memory error detector.
==3891== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==3891== Using LibVEX rev 1804, a library for dynamic binary translation.
==3891== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==3891== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation
framework.
==3891== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==3891== For more details, rerun with: -v
==3891== 
 MAIN__==3891== Invalid read of size 4
==3891==    at 0x80F3D8D: gfc_conv_expr_val (trans-expr.c:3611)
==3891==  Address 0x4 is not stack'd, malloc'd or (recently) free'd

foo.f90:4: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
==3891== 
==3891== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 15 from 1)
==3891== malloc/free: in use at exit: 249,564 bytes in 1,061 blocks.
==3891== malloc/free: 1,592 allocs, 531 frees, 289,234 bytes allocated.
==3891== For counts of detected errors, rerun with: -v
==3891== searching for pointers to 1,061 not-freed blocks.
==3891== checked 2,099,868 bytes.
==3891== 
==3891== LEAK SUMMARY:
==3891==    definitely lost: 108 bytes in 2 blocks.
==3891==      possibly lost: 176 bytes in 14 blocks.
==3891==    still reachable: 249,280 bytes in 1,045 blocks.
==3891==         suppressed: 0 bytes in 0 blocks.
==3891== Rerun with --leak-check=full to see details of leaked memory.

Running under gdb yields

(gdb) r -fdefault-integer-8 -g f12_integrals.f 
Starting program: /home/ig25/libexec/gcc/i686-pc-linux-gnu/4.4.0/f951
-fdefault-integer-8 -g f12_integrals.f
 df_fit_f12 tranop_f12 f12_unidom f12_listmo f12_integrals_jinv
f12_integrals_2idx f12_integrals_til f12_integrals_bar f12_integrals_srt {GC
5430k -> 2061k} f12_integrals_raw
Program received signal SIGSEGV, Segmentation fault.
0x08234a2c in fold_binary (code=MINUS_EXPR, type=0xb7b404b0, op0=0xb7baf688,
op1=0xb7bf6070) at ../../../gcc/trunk/gcc/fold-const.c:9920
9920              && !HONOR_SIGNED_ZEROS (TYPE_MODE (TREE_TYPE (arg0)))


-- 


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

[Bug fortran/35892] [4.4 regression] gfortran dies on file containing module and common

[jvdelisle at gcc dot gnu dot org]

------- Comment #4 from jvdelisle at gcc dot gnu dot org  2008-04-18 14:41 -------
Here is another attempt using valgrind:

==4137== 184 bytes in 23 blocks are definitely lost in loss record 2 of 13
==4137==    at 0x4A059F6: malloc (vg_replace_malloc.c:149)
==4137==    by 0x3FDCC07EF8: __gmp_default_allocate (in
/usr/lib64/libgmp.so.3.4.2)
==4137==    by 0x3FDCC18137: __gmpz_init_set_si (in /usr/lib64/libgmp.so.3.4.2)
==4137==    by 0x413CF9: gfc_assign_data_value (data.c:267)
==4137==    by 0x464667: traverse_data_var (resolve.c:8260)
==4137==    by 0x465F85: resolve_types (resolve.c:8442)
==4137==    by 0x46973C: gfc_resolve (resolve.c:9138)
==4137==    by 0x45996F: gfc_parse_file (parse.c:3566)
==4137==    by 0x484C1C: gfc_be_parse_file (f95-lang.c:258)
==4137==    by 0x6FE902: toplev_main (toplev.c:962)
==4137==    by 0x3FF061E073: (below main) (libc-start.c:220)
==4137== 


-- 


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

[Bug fortran/35892] [4.4 regression] gfortran dies on file containing module and common

[jvdelisle at gcc dot gnu dot org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 328 bytes --]



------- Comment #5 from jvdelisle at gcc dot gnu dot org  2008-04-18 15:09 -------
Some more info:

$ gfc -fno-range-check -fbounds-check pr35892.f
pr35892.f: In function ‘f12_integrals_jinv’:
pr35892.f:1397: internal compiler error: in convert_move, at expr.c:371


-- 


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

[Bug fortran/35892] [4.4 regression] gfortran dies on file containing module and common

[jvdelisle at gcc dot gnu dot org]

------- Comment #6 from jvdelisle at gcc dot gnu dot org  2008-04-18 16:23 -------
Regression hunt complete.  The offending patch is:

Revision 133801 - (view) (download) - [select for diffs]
Modified Tue Apr 1 21:23:36 2008 UTC (2 weeks, 2 days ago) by george
File length: 35842 byte(s)
Diff to previous 132592 (colored)

        * fortran/trans-common.c (create_common):  Add decl to function
        chain to preserve identifier scope in debug output.

--- trunk/gcc/fortran/trans-common.c    2008/02/24 16:43:23     132592
+++ trunk/gcc/fortran/trans-common.c    2008/04/01 21:23:36     133801
@@ -687,10 +687,7 @@
       /* This is a fake variable just for debugging purposes.  */
       TREE_ASM_WRITTEN (var_decl) = 1;

-      if (com)
-       var_decl = pushdecl_top_level (var_decl);
-      else
-       gfc_add_decl_to_function (var_decl);
+      gfc_add_decl_to_function (var_decl);

       SET_DECL_VALUE_EXPR (var_decl,
                           fold_build3 (COMPONENT_REF, TREE_TYPE (s->field),

I have cc'ed George on this.  Shall we revert?


-- 

jvdelisle at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |george at gcc dot gnu dot
                   |                            |org


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

[Bug fortran/35892] [4.4 regression] gfortran dies on file containing module and common

[kargl at gcc dot gnu dot org]

------- Comment #7 from kargl at gcc dot gnu dot org  2008-04-18 17:12 -------
(In reply to comment #6)
> Regression hunt complete.  The offending patch is:
> 
> Revision 133801 - (view) (download) - [select for diffs]
> Modified Tue Apr 1 21:23:36 2008 UTC (2 weeks, 2 days ago) by george
> File length: 35842 byte(s)
> Diff to previous 132592 (colored)
> 
>         * fortran/trans-common.c (create_common):  Add decl to function
>         chain to preserve identifier scope in debug output.
> 

(snipped)

> 
> I have cc'ed George on this.  Shall we revert?
> 

I can't locate in the mailing list archive who reviewed and who
approved this patch.  In fact of the patches that I could locate, 
those touched only g77 bit not gfortran.  It looks like a drive-by
commit and at least this portion needs to be reverted if George can't
properly fix it.


-- 


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

[Bug fortran/35892] [4.4 regression] gfortran dies on file containing module and common

[jvdelisle at gcc dot gnu dot org]

------- Comment #8 from jvdelisle at gcc dot gnu dot org  2008-04-18 17:44 -------
See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35154.


-- 


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

[Bug fortran/35892] [4.4 regression] gfortran dies on file containing module and common

[kargl at gcc dot gnu dot org]

------- Comment #9 from kargl at gcc dot gnu dot org  2008-04-18 19:48 -------
(In reply to comment #8)
> See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35154.
> 

This does not contain the patch nor a pointer to the patch
that contains the offending code in comment #7.


-- 


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

[Bug fortran/35892] [4.4 regression] gfortran dies on file containing module and common

[jvdelisle at gcc dot gnu dot org]

------- Comment #10 from jvdelisle at gcc dot gnu dot org  2008-04-18 20:58 -------
Agree, that bad hunk is not in the approved patch.  Since it obviously breaks
gfortran in a bad way, I am going to revert it and see what happens for
followup.


-- 


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

[Bug fortran/35892] [4.4 regression] gfortran dies on file containing module and common

[jvdelisle at gcc dot gnu dot org]

------- Comment #11 from jvdelisle at gcc dot gnu dot org  2008-04-18 21:31 -------
Reverting the patch breaks two test cases:

pr35154-dwarf2.f

pr35154-stabs.f


-- 


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

[Bug fortran/35892] [4.4 regression] gfortran dies on file containing module and common

[kargl at gcc dot gnu dot org]

------- Comment #12 from kargl at gcc dot gnu dot org  2008-04-18 22:14 -------
(In reply to comment #11)
> Reverting the patch breaks two test cases:
> 
> pr35154-dwarf2.f 
> pr35154-stabs.f
> 

These are part of the patch that broke the compiler, so I 
would certainly expect them to fail.


-- 


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

[Bug fortran/35892] [4.4 regression] gfortran dies on file containing module and common

[jvdelisle at gcc dot gnu dot org]

------- Comment #13 from jvdelisle at gcc dot gnu dot org  2008-04-19 06:43 -------
Subject: Bug 35892

Author: jvdelisle
Date: Sat Apr 19 06:42:42 2008
New Revision: 134465

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134465
Log:
2008-04-18  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

        PR fortran/35892
        * gfortran.dg/pr35154-dwarf2.f: Remove.
        * gfortran.dg/pr35154-stabs.f: Remove.

Removed:
    trunk/gcc/testsuite/gfortran.dg/debug/pr35154-dwarf2.f
    trunk/gcc/testsuite/gfortran.dg/debug/pr35154-stabs.f
Modified:
    trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/35892] [4.4 regression] gfortran dies on file containing module and common

[jvdelisle at gcc dot gnu dot org]

------- Comment #14 from jvdelisle at gcc dot gnu dot org  2008-04-19 06:51 -------
Subject: Bug 35724

Author: jvdelisle
Date: Sat Apr 19 06:34:12 2008
New Revision: 134464

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134464
Log:
2008-04-18  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

        PR fortran/35892
        * trans-common.c (create_common): Revert patch causing regression.

Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-common.c


-- 


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

[Bug fortran/35892] [4.4 regression] gfortran dies on file containing module and common

[jvdelisle at gcc dot gnu dot org]

------- Comment #15 from jvdelisle at gcc dot gnu dot org  2008-04-19 06:53 -------
Closing this PR as fixed.  See PR35154 which now needs to be reworked.


-- 

jvdelisle at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


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

[Bug fortran/35892] [4.4 regression] gfortran dies on file containing module and common

[george at gcc dot gnu dot org]

------- Comment #16 from george at gcc dot gnu dot org  2008-04-19 12:08 -------
Thanks for the report.  For the record, here is the approval for this patch:

http://gcc.gnu.org/ml/gcc-patches/2008-02/msg01011.html


-- 

george at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fxcoudert at gmail dot com


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

[Bug fortran/35892] gfortran lost memory blocks

[jvdelisle at gcc dot gnu dot org]

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

[Bug fortran/35892] gfortran lost memory blocks

[george at gcc dot gnu dot org]

------- Comment #18 from george at gcc dot gnu dot org  2008-04-24 08:29 -------
I've investigated the PR code further.  The relevant parts of the code are
structured like so:

module mod
  integer aa, bb
  common /oof/ aa,bb
contains
  subroutine sub
  i = max(0,aa-1)
  print *, i, aa, bb
  end subroutine sub

  subroutine subb
  common /oof/ ic,id
  print *, ic, id
  end subroutine subb
end module

program test
  use mod
  common /oof/ ii,jj

  ii = 42
  jj = ii / 2
  print *, ii, jj
  call sub
  call subb
end program test

(A main program isn't in the PR, but I added one for debugging.)  The COMMON
appears both in the module scope, and in the local scope of one of the
procedures in the module.  When the storage layout is made for the COMMON at
module scope, the decls get thrown away too early if they are chained to the
(non-existent) procedure scope; further references to those identifiers in
procedure sub are in peril.  Chaining the decls to the global scope for
module-scope COMMON seems to be appropriate here and fixes the segfault for the
PR code.

I will rework the patch to include this case.  There is still the outstanding
problem of lost memory blocks unrelated to the original patch.   Any further
progress on that?


-- 


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

[Bug fortran/35892] gfortran lost memory blocks

[KnowlesPJ at Cardiff dot ac dot uk]

------- Comment #19 from KnowlesPJ at Cardiff dot ac dot uk  2008-04-24 09:34 -------
As the originator of this report, I just wanted to add a context comment in
case it is helpful. This construction (common declared both in the module and
in subroutines (contained or external)) is horrible, but one of our developers
has found it to be the only reasonable way of dragging in a dusty deck.
Although the compiler crash was reported, this is not our main interest, since
the compiler seems to crash only with -g. Without -g, at any optimization
level, we are getting wrong numbers at run time. Abstracting that from the 1.5
million line code for a reasonable test case to report will not be easy, so we
are hoping that the fix to the compiler crash will be the silver bullet.


-- 


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

[Bug fortran/35892] gfortran lost memory blocks

[jvdelisle at gcc dot gnu dot org]

------- Comment #20 from jvdelisle at gcc dot gnu dot org  2008-04-24 19:05 -------
The part that was causing the crash has been reverted.  Can you try with
current latest trunk version 4.4.0 and see if it really is the silver bullet? 
and report back here.


-- 


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

[Bug fortran/35892] gfortran lost memory blocks

[jvdelisle at gcc dot gnu dot org]

------- Comment #21 from jvdelisle at gcc dot gnu dot org  2008-04-24 19:10 -------
Reply to comment #18.  I have not had time to dig further on these memory
issues.  I think after George has a revamped patch in, I will explore some more
on this.  We are probably just not freeing some memory after it is used. (I
hope)


-- 


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

[Bug fortran/35892] gfortran lost memory blocks

[KnowlesPJ at Cardiff dot ac dot uk]

------- Comment #22 from KnowlesPJ at Cardiff dot ac dot uk  2008-04-25 08:10 -------
Yes, this was the silver bullet. With

Using built-in specs.
Target: i386-apple-darwin9.2.2
Configured with: ../configure --prefix=/opt/gcc
Thread model: posix
gcc version 4.4.0 20080424 (experimental) (GCC) 

we now get through the regression tests on our code that were failing before.

Thank you to those who have contributed to this - the final piece that was
needed for our code (http://www.molpro.net) to work with gfortran on both linux
and mac.


-- 


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

[Bug fortran/35892] gfortran lost memory blocks

[george at gcc dot gnu dot org]

------- Comment #23 from george at gcc dot gnu dot org  2008-04-26 09:46 -------
Subject: Bug 35892

Author: george
Date: Sat Apr 26 09:46:01 2008
New Revision: 134696

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134696
Log:
2008-04-26  George Helffrich <george@gcc.gnu.org>

        PR fortran/35892
        PR fortran/35154
        * fortran/trans-common.c (create_common):  Add decl to function
        chain (if inside one) to preserve identifier scope in debug output.

        * testsuite/gfortran.dg/debug/pr35154-stabs.f:  New test case for
        .stabs functionality.
        * testsuite/gfortran.dg/debug/pr35154-dwarf2.f:  New test case for
        DWARF functionality.


Added:
    trunk/gcc/testsuite/gfortran.dg/debug/pr35154-dwarf2.f
    trunk/gcc/testsuite/gfortran.dg/debug/pr35154-stabs.f
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-common.c
    trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/35892] gfortran lost memory blocks

[george at gcc dot gnu dot org]

------- Comment #24 from george at gcc dot gnu dot org  2008-04-26 10:18 -------
ICE/segfault on test case eliminated by rev. 134696.

Memory leaks unrelated to original patch still unresolved.


-- 


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

[Bug fortran/35892] gfortran lost memory blocks

[jvdelisle at gcc dot gnu dot org]

------- Comment #25 from jvdelisle at gcc dot gnu dot org  2008-04-27 01:08 -------
Memory leaks are now gone.  Not sure why, but no complaints here


-- 

jvdelisle at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |FIXED


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