not specific to 4.5, also fails with
gcc version 4.4.0 20090414 (prerelease) [gcc-4_4-branch revision 146034] (GCC)

also 4.3.3. fails

with gfortran -c -O0 --param ggc-min-heapsize=3200000 CP2K_2009-05-01.f90 things compile file (and need some 6Gb of memory).

(In reply to comment #3)
> with gfortran -c -O0 --param ggc-min-heapsize=3200000 CP2K_2009-05-01.f90
> things compile file (and need some 6Gb of memory).
> 

Joost,

Do you have any idea of what change to g2k might have caused this?  Even with no optimization, it brings my Core 2 Quad to a complete halt. The fact that it is garbage handling is worrying and maybe indicates that it may be something other than the fortran frontend.

Cheers

Paul

Does it work if you increase the default stack limit?  ulimit -s unlimited

(In reply to comment #4)
> Do you have any idea of what change to g2k might have caused this?  Even with
> no optimization, it brings my Core 2 Quad to a complete halt. The fact that it
> is garbage handling is worrying and maybe indicates that it may be something
> other than the fortran frontend.

No idea what change in CP2K could have triggered this. I have been using a similar  test based on CP2K_2007_06, and that thus not seem to trigger this error. I think it is a front-end issue, as it definitely still has not yet finished writing the .mod files.

(In reply to comment #5)
> Does it work if you increase the default stack limit?  ulimit -s unlimited

trunk does indeed pass with ulimit -s .... and 4.4.0 as well.

This is not a new problem - our recursive GC manages to do this in some cases.

What helps sometimes is to adjust the way structures are linked to avoid too
deep recursion.  Maybe the GFortran FE trees are not optimized for that?

Thus, the question is what are we recursing on here?  type.next_variant
if my sources are matching yours (look at gt-fortran-f95-lang.h:337).

What type do we have so many variants of?

(In reply to comment #8)
> Thus, the question is what are we recursing on here?  type.next_variant
> if my sources are matching yours (look at gt-fortran-f95-lang.h:337).

gt_ggc_m_9tree_node ((*x).generic.type.next_variant);

This is the outermost stack trace to the segfault (with default 8M stack), shows the depth of the recursion, and the location:

#174699 0x0000000000528487 in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:337
#174700 0x0000000000528487 in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:337
#174701 0x0000000000528487 in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:337
#174702 0x0000000000528487 in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:337
#174703 0x0000000000528487 in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:337
#174704 0x0000000000528487 in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:337
#174705 0x000000000052884d in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:213
#174706 0x00000000005283e7 in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:315
#174707 0x0000000000528831 in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:211
#174708 0x00000000005283e7 in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:315
#174709 0x00000000005283d9 in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:314
#174710 0x00000000005283d9 in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:314
#174711 0x0000000000528041 in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:457
#174712 0x00000000005283e7 in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:315
#174713 0x0000000000528519 in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:291
#174714 0x00000000006f6955 in gt_ggc_mx_cgraph_node (x_p=<value optimized out>) at gtype-desc.c:228
#174715 0x00000000006f6a76 in gt_ggc_m_P11cgraph_node4htab (x_p=<value optimized out>) at gtype-desc.c:2142
#174716 0x00000000006c0bce in ggc_mark_roots () at /data03/vondele/gcc_trunk/gcc/gcc/ggc-common.c:107
#174717 0x0000000000572108 in ggc_collect () at /data03/vondele/gcc_trunk/gcc/gcc/ggc-page.c:1941
#174718 0x0000000000543253 in gfc_generate_function_code (ns=0x3603e890) at /data03/vondele/gcc_trunk/gcc/gcc/fortran/trans-decl.c:4140
#174719 0x00000000005298eb in gfc_generate_module_code (ns=<value optimized out>)
    at /data03/vondele/gcc_trunk/gcc/gcc/fortran/trans.c:1322
#174720 0x00000000004f6404 in gfc_parse_file () at /data03/vondele/gcc_trunk/gcc/gcc/fortran/parse.c:3865
#174721 0x0000000000526bbd in gfc_be_parse_file (set_yydebug=<value optimized out>)
    at /data03/vondele/gcc_trunk/gcc/gcc/fortran/f95-lang.c:236
#174722 0x00000000007f39b4 in toplev_main (argc=13, argv=0x7fff5db02a88) at /data03/vondele/gcc_trunk/gcc/gcc/toplev.c:977
#174723 0x00007f9454765436 in __libc_start_main () from /lib64/libc.so.6
#174724 0x0000000000499679 in _start ()

I have a gdb session open, but I'm rather clueless. I have this:

(gdb) print (*x).generic.type
$5 = {common = {base = {code = RECORD_TYPE, side_effects_flag = 0, constant_flag = 0, addressable_flag = 0, volatile_flag = 0,
      readonly_flag = 0, unsigned_flag = 0, asm_written_flag = 0, nowarning_flag = 0, used_flag = 0, nothrow_flag = 0,
      static_flag = 0, public_flag = 0, private_flag = 0, protected_flag = 0, deprecated_flag = 0, saturating_flag = 0,
      default_def_flag = 0, lang_flag_0 = 0, lang_flag_1 = 0, lang_flag_2 = 0, lang_flag_3 = 0, lang_flag_4 = 0, lang_flag_5 = 0,
      lang_flag_6 = 0, visited = 0, spare = 0, ann = 0x0}, chain = 0x0, type = 0x0}, values = 0x7f94536c6780, size = 0x7f9453fada80,
  size_unit = 0x7f9453e43cc0, attributes = 0x0, uid = 769447, precision = 0, mode = BLKmode, string_flag = 0, no_force_blk_flag = 0,
  needs_constructing_flag = 0, transparent_union_flag = 0, packed_flag = 0, restrict_flag = 0, contains_placeholder_bits = 0,
  lang_flag_0 = 0, lang_flag_1 = 1, lang_flag_2 = 0, lang_flag_3 = 0, lang_flag_4 = 0, lang_flag_5 = 0, lang_flag_6 = 0,
  user_align = 0, align = 64, alias_set = -1, pointer_to = 0x0, reference_to = 0x0, symtab = {address = 0, pointer = 0x0, die = 0x0},
  name = 0x7f9452151150, minval = 0x0, maxval = 0x0, next_variant = 0x7f941d7c60c0, main_variant = 0x7f9453d66e40, binfo = 0x0,
  context = 0x0, canonical = 0x7f9453d66e40, lang_specific = 0x7f941d7c7600}

but  the following fails:

(gdb) call debug_tree((*x).generic.type.next_variant)
Cannot access memory at address 0x7fff5d302f78

(In reply to comment #11)
> I have a gdb session open, but I'm rather clueless. I have this:
> but  the following fails:
> 
> (gdb) call debug_tree((*x).generic.type.next_variant)
> Cannot access memory at address 0x7fff5d302f78

That is because gdb uses the same stack as the program when doing a call so of course that will fail :).

Is there a self contained (one file) source that I could use? Gfortran is known to emit a lot of blocks inside blocks and I wonder if this is the cause.  And the GC is only setup to do chaining through the sibling blocks not the subblocks.

(In reply to comment #13)
> Is there a self contained (one file) source that I could use? Gfortran is known
> to emit a lot of blocks inside blocks and I wonder if this is the cause.  And
> the GC is only setup to do chaining through the sibling blocks not the
> subblocks.

yes, please, see the link in the first comment of the PR.

(In reply to comment #13)
> Is there a self contained (one file) source that I could use? 

have you had a chance to look into the issue / is there anything I can help with ? I'd like to get this ready for -fwhole-file compilation :-)

tried once running under valgrind, but that doesn't give more info, no errors till the point of the stack overflow:

GNU Fortran (GCC) version 4.5.0 20090509 (experimental) [trunk revision 147317] (x86_64-unknown-linux-gnu)
        compiled by GNU C version 4.5.0 20090509 (experimental) [trunk revision 147317], GMP version 4.2.2, MPFR version 2.3.1.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
==27399== Stack overflow in thread 1: can't grow stack to 0x7FE801FF8
==27399== Can't extend stack to 0x7FE801700 during signal delivery for thread 1:
==27399==   no stack segment
==27399==
==27399== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==27399==  Access not within mapped region at address 0x7FE801700
==27399==    at 0x529DC8: gt_ggc_mx_lang_tree_node (gt-fortran-f95-lang.h:46)

Yes I am going to be still looking into this.  I just had other things to do first.

*** Bug 38814 has been marked as a duplicate of this bug. ***

still fails with gcc version 4.5.0 20090721 (experimental) [trunk revision 149846] (GCC)

As noticed in PR40011,

All of gfortran.h seems to be ignorant of the GC - which means we may
not garbage collect while the FE is still running, so all calls to
cgraph_finalize_function should have true as their 2nd argument.

(In reply to comment #20)
> As noticed in PR40011,
> 
> All of gfortran.h seems to be ignorant of the GC - which means we may
> not garbage collect while the FE is still running, so all calls to
> cgraph_finalize_function should have true as their 2nd argument.
>
Richard,

I tried this change, and now it segfaults later, I guess past the frontend.

#174670 0x0000000000530d51 in gt_ggc_mx_lang_tree_node (
    x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:461
#174671 0x0000000000531127 in gt_ggc_mx_lang_tree_node (
    x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:320
#174672 0x0000000000531259 in gt_ggc_mx_lang_tree_node (
    x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:295
#174673 0x00000000006fb2d5 in gt_ggc_mx_cgraph_node (x_p=<value optimized out>)
    at gtype-desc.c:264
#174674 0x00000000006fb43e in gt_ggc_m_P11cgraph_node4htab (
    x_p=<value optimized out>) at gtype-desc.c:2207
#174675 0x00000000006c396f in ggc_mark_roots ()
---Type <return> to continue, or q <return> to quit---
    at /data03/vondele/gcc_trunk/gcc/gcc/ggc-common.c:137
#174676 0x000000000057e636 in ggc_collect ()
    at /data03/vondele/gcc_trunk/gcc/gcc/ggc-page.c:1944
#174677 0x0000000000756de5 in execute_todo (flags=19)
    at /data03/vondele/gcc_trunk/gcc/gcc/passes.c:1057
#174678 0x0000000000757083 in execute_one_pass (pass=0x11c9640)
    at /data03/vondele/gcc_trunk/gcc/gcc/passes.c:1309
#174679 0x0000000000757255 in execute_pass_list (pass=0x11c9640)
    at /data03/vondele/gcc_trunk/gcc/gcc/passes.c:1335
#174680 0x000000000084adb9 in tree_lowering_passes (fn=<value optimized out>)
    at /data03/vondele/gcc_trunk/gcc/gcc/tree-optimize.c:345
#174681 0x00000000009ae512 in cgraph_lower_function (node=0x7f2d97042600)
    at /data03/vondele/gcc_trunk/gcc/gcc/cgraphunit.c:501
#174682 0x00000000009aed7b in cgraph_analyze_function (node=0x7f2d97042600)
    at /data03/vondele/gcc_trunk/gcc/gcc/cgraphunit.c:814
#174683 0x00000000009b14e6 in cgraph_analyze_functions ()
    at /data03/vondele/gcc_trunk/gcc/gcc/cgraphunit.c:953
#174684 0x00000000009b1840 in cgraph_finalize_compilation_unit ()
    at /data03/vondele/gcc_trunk/gcc/gcc/cgraphunit.c:1039
#174685 0x000000000071c44d in write_global_declarations ()
    at /data03/vondele/gcc_trunk/gcc/gcc/langhooks.c:314
#174686 0x00000000007fa0db in toplev_main (argc=13, argv=0x7fff001a91b8)
    at /data03/vondele/gcc_trunk/gcc/gcc/toplev.c:1039
---Type <return> to continue, or q <return> to quit---
#174687 0x00007f2df6e0e436 in __libc_start_main () from /lib64/libc.so.6
#174688 0x000000000049b2f9 in _start ()

Just for reference:

Index: trans-decl.c
===================================================================
--- trans-decl.c        (revision 149846)
+++ trans-decl.c        (working copy)
@@ -2023,7 +2023,7 @@

       current_function_decl = NULL_TREE;

-      cgraph_finalize_function (thunk_fndecl, false);
+      cgraph_finalize_function (thunk_fndecl, true);

       /* We share the symbols in the formal argument list with other entry
         points and the master function.  Clear them so that they are
@@ -4104,7 +4104,7 @@
   /* Output the GENERIC tree.  */
   dump_function (TDI_original, ftn_main);

-  cgraph_finalize_function (ftn_main, false);
+  cgraph_finalize_function (ftn_main, true);

   if (old_context)
     {
@@ -4375,7 +4375,7 @@
        added to our parent's nested function list.  */
     (void) cgraph_node (fndecl);
   else
-    cgraph_finalize_function (fndecl, false);
+    cgraph_finalize_function (fndecl, true);

   gfc_trans_use_stmts (ns);
   gfc_traverse_ns (ns, gfc_emit_parameter_debug_info);

Can you run it in a debugging session and do

(gdb) break ggc_collect
(gdb) break cgraph_finalize_compilation_unit

and see if ggc_collect is reached before cgraph_finalize_compilation_unit?

Thanks.

(In reply to comment #22)
> Can you run it in a debugging session and do
> 
> (gdb) break ggc_collect
> (gdb) break cgraph_finalize_compilation_unit
> 
> and see if ggc_collect is reached before cgraph_finalize_compilation_unit?
> 

cgraph_finalize_compilation_unit is reached first. After a continue gcc_collect is reached quickly, and an additional cont leads to the segfault.

Ok, that confirms this bug is unrelated to the GC issue in the other PR.

Ah, btw I remember that the Fortran FE creates a new type copy for each
array descriptor and links them in the type variant chains (wtf?).

Can you try

Index: gcc/fortran/trans-types.c
===================================================================
--- gcc/fortran/trans-types.c.orig	2009-07-24 17:54:08.000000000 +0200
+++ gcc/fortran/trans-types.c	2009-07-24 17:53:51.000000000 +0200
@@ -1602,7 +1602,7 @@ gfc_get_array_type_bounds (tree etype, i
   int n;
 
   base_type = gfc_get_array_descriptor_base (dimen);
-  fat_type = build_variant_type_copy (base_type);
+  fat_type = build_distinct_type_copy (base_type);
 
   tmp = TYPE_NAME (etype);
   if (tmp && TREE_CODE (tmp) == TYPE_DECL)

?

(In reply to comment #24)
> Ok, that confirms this bug is unrelated to the GC issue in the other PR.
Well, there are two bugs. The first one is gone with your 'cgraph_finalize_function (ftn_main, true)' change

(In reply to comment #25)
> Ah, btw I remember that the Fortran FE creates a new type copy for each
> array descriptor and links them in the type variant chains (wtf?).
> 
> Can you try

this fixes the segfault, but I now get:


 gfortran -c CP2K_2009-05-01.f90
CP2K_2009-05-01.f90: In function ‘debug_ewald_multipole_low’:
CP2K_2009-05-01.f90:632848:0: error: non-trivial conversion at assignment
struct array2_integer(kind=4)
struct array2_integer(kind=4)
list = neighbor_kind_pair->list;

CP2K_2009-05-01.f90:632848:0: internal compiler error: verify_gimple failed
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

Add

  TYPE_CANONICAL (fat_type) = base_type;

after the build_distinct_type_copy call.

(In reply to comment #28)
> Add
> 
>   TYPE_CANONICAL (fat_type) = base_type;
> 
> after the build_distinct_type_copy call.
> 

Yep... goes fine now

arghh... further testing on standard sources (-g?) reveals:

/data03/vondele/clean/cp2k/src/../src/util.F: In function ‘sort_cm’:
/data03/vondele/clean/cp2k/src/../src/util.F:204:0: internal compiler error: in splice_child_die, at dwarf2out.c:6983
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

Hmm, that looks unrelated ...?

(In reply to comment #30)
> Hmm, that looks unrelated ...?
> 

doesn't seem to happen on a clean trunk ( a few days more recent ). This is a reduced testcase for this failure:

> gfortran -g bug.f90
bug.f90: In function ‘str_search’:
bug.f90:32:0: internal compiler error: in splice_child_die, at dwarf2out.c:6983
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

> cat bug.f90
MODULE string_utilities
CONTAINS
  SUBROUTINE xstring(string,ia,ib)

    CHARACTER(LEN=*), INTENT(IN)             :: string
    INTEGER, INTENT(OUT)                     :: ia, ib

    ia = 1
    ib = LEN_TRIM(string)
    IF (ib>0) THEN
       DO WHILE (string(ia:ia)==' ')
          ia = ia + 1
       END DO
    END IF

  END SUBROUTINE xstring
  FUNCTION str_comp(str1,str2) RESULT (equal)

    CHARACTER(LEN=*), INTENT(IN)             :: str1, str2
    LOGICAL                                  :: equal

    INTEGER                                  :: i1, i2, j1, j2

    i1 = 0
    i2 = 0
    j1 = 0
    j2 = 0
    CALL xstring(str1,i1,i2)
    CALL xstring(str2,j1,j2)
    equal = (str1(i1:i2)==str2(j1:j2))
  END FUNCTION str_comp
  FUNCTION str_search(str1,n,str2) RESULT (pos)
    CHARACTER(LEN=*), INTENT(IN)             :: str1( : )
    INTEGER, INTENT(IN)                      :: n
    CHARACTER(LEN=*), INTENT(IN)             :: str2
    INTEGER                                  :: pos

    INTEGER                                  :: i

    pos = 0
    DO i = 1, n
       IF (str_comp(str1(i),str2)) THEN
          pos = i
          EXIT
       END IF
    END DO
  END FUNCTION str_search
END MODULE string_utilities

(In reply to comment #31)
> doesn't seem to happen on a clean trunk ( a few days more recent )

it is definitely caused by the current patch (i.e. reverting it fixes the issue):

Index: trans-types.c
===================================================================
--- trans-types.c       (revision 149846)
+++ trans-types.c       (working copy)
@@ -1602,7 +1602,8 @@
   int n;

   base_type = gfc_get_array_descriptor_base (dimen);
-  fat_type = build_variant_type_copy (base_type);
+  fat_type = build_distinct_type_copy (base_type);
+  TYPE_CANONICAL (fat_type) = base_type;

   tmp = TYPE_NAME (etype);
   if (tmp && TREE_CODE (tmp) == TYPE_DECL)
Index: trans-decl.c
===================================================================
--- trans-decl.c        (revision 149846)
+++ trans-decl.c        (working copy)
@@ -2023,7 +2023,7 @@

       current_function_decl = NULL_TREE;

-      cgraph_finalize_function (thunk_fndecl, false);
+      cgraph_finalize_function (thunk_fndecl, true);

       /* We share the symbols in the formal argument list with other entry
         points and the master function.  Clear them so that they are
@@ -4104,7 +4104,7 @@
   /* Output the GENERIC tree.  */
   dump_function (TDI_original, ftn_main);

-  cgraph_finalize_function (ftn_main, false);
+  cgraph_finalize_function (ftn_main, true);

   if (old_context)
     {
@@ -4375,7 +4375,7 @@
        added to our parent's nested function list.  */
     (void) cgraph_node (fndecl);
   else
-    cgraph_finalize_function (fndecl, false);
+    cgraph_finalize_function (fndecl, true);

   gfc_trans_use_stmts (ns);
   gfc_traverse_ns (ns, gfc_emit_parameter_debug_info);

Yeah, it's caused by the change.  We don't generate a real proper copy (we
don't copy the fields so their context is wrong).  Previously only a single
debug-info copy was emitted via using TYPE_MAIN_VARIANT.

We can work around this by also doing

  TYPE_MAIN_VARIANT (fat_type) = base_type;

though that's a bit hairy ... (does it still solve your oroginal problem then?)

(In reply to comment #33)
> We can work around this by also doing
> 
>   TYPE_MAIN_VARIANT (fat_type) = base_type;
> 
> though that's a bit hairy ... (does it still solve your oroginal problem then?)

yes, the original still compiles fine, and a couple of different CP2K builds also pass.

Ok, less hacky is the following.

Index: gcc/fortran/trans-types.c
===================================================================
--- gcc/fortran/trans-types.c.orig	2009-07-24 21:13:28.000000000 +0200
+++ gcc/fortran/trans-types.c	2009-07-24 21:13:05.000000000 +0200
@@ -1602,7 +1602,9 @@ gfc_get_array_type_bounds (tree etype, i
   int n;
 
   base_type = gfc_get_array_descriptor_base (dimen);
-  fat_type = build_variant_type_copy (base_type);
+  fat_type = build_distinct_type_copy (base_type);
+  TYPE_CANONICAL (fat_type) = base_type;
+  TYPE_STUB_DECL (fat_type) = TYPE_STUB_DECL (base_type);
 
   tmp = TYPE_NAME (etype);
   if (tmp && TREE_CODE (tmp) == TYPE_DECL)


I think that is the right thing to do (together with the GC patch).  So
if it passes bootstrap & testing ...

Created attachment 18252 [details]
patch fixing this PR

I've checked that Richard's latest version still fixes this PR, works fine with CP2K, and bootstraps (but I can't run make check because of missing dejagnu here).

I'm running bootstrap and regtests now.

Subject: Bug 40005

Author: rguenth
Date: Sat Jul 25 13:44:57 2009
New Revision: 150079

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150079
Log:
2009-07-25  Richard Guenther  <rguenther@suse.de>

	PR fortran/40005
	* trans-types.c (gfc_get_array_type_bounds): Use
	build_distinct_type_copy with a proper TYPE_CANONICAL and
	re-use the type-decl of the original type.
	* trans-decl.c (build_entry_thunks): Signal cgraph we may not
	garbage collect.
	(create_main_function): Likewise.
	(gfc_generate_function_code): Likewise.
	* trans-expr.c (gfc_trans_subcomponent_assign): Do not use
	fold_convert on record types.

Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-decl.c
    trunk/gcc/fortran/trans-expr.c
    trunk/gcc/fortran/trans-types.c

Fixed.