[Bug debug/36060] [4.3/4.4 Regression] Too big stack requirements of cc1plus during GC

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2008-04-28 09:51 ---
Subject: Bug 36060

Author: jakub
Date: Mon Apr 28 09:50:31 2008
New Revision: 134751

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134751
Log:
PR debug/36060
* dwarf2out.c (struct die_struct): Mark as chain_circular through
die_sub field.
* gengtype.c (walk_type, write_func_for_structure): Handle
chain_circular.
* doc/gty.texi: Document chain_circular.

Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/doc/gty.texi
branches/gcc-4_3-branch/gcc/dwarf2out.c
branches/gcc-4_3-branch/gcc/gengtype.c


-- 


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

[Bug debug/36060] [4.3/4.4 Regression] Too big stack requirements of cc1plus during GC

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2008-04-28 09:46 ---
Subject: Bug 36060

Author: jakub
Date: Mon Apr 28 09:45:26 2008
New Revision: 134750

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134750
Log:
PR debug/36060
* dwarf2out.c (struct die_struct): Mark as chain_circular through
die_sub field.
* gengtype.c (walk_type, write_func_for_structure): Handle
chain_circular.
* doc/gty.texi: Document chain_circular.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/gty.texi
trunk/gcc/dwarf2out.c
trunk/gcc/fortran/ChangeLog
trunk/gcc/gengtype.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug debug/36060] [4.3/4.4 Regression] Too big stack requirements of cc1plus during GC

[jakub at gcc dot gnu dot org]

--- Comment #7 from jakub at gcc dot gnu dot org  2008-04-28 09:52 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug debug/36060] [4.3/4.4 Regression] Too big stack requirements of cc1plus during GC

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-04-27 10:59:40
   date||
   Target Milestone|--- |4.3.1


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

[Bug debug/36060] [4.3/4.4 Regression] Too big stack requirements of cc1plus during GC

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2008-04-27 11:00 ---
Created an attachment (id=15534)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15534action=view)
1.ii.bz2

Preprocessed file from openvrml.


-- 


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

[Bug debug/36060] [4.3/4.4 Regression] Too big stack requirements of cc1plus during GC

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2008-04-27 11:06 ---
As most of the nested calls are due to following die_sib, out of the first
almost 46000 frames I've uped, there were:
20273  gt_ggc_m_10die_struct ((*x).die_sib);
 8878  gt_ggc_m_19VEC_dw_attr_node_gc ((*x).die_attr);
 8877  gt_ggc_m_10die_struct ((*x).base.vec[i0].dw_attr_val.v.val_die_ref.die);
 7220  gt_ggc_m_10die_struct ((*x).die_child);
the best fix is IMHO to mark die_sib as chain_next.  Unfortunately, the DIEs
are linked circularly through the die_sib field, so chain_next doesn't work
properly for that.  I'll post a patch which introduces chain_circular
alternative to chain_next.  With this patch, cc1plus with this testcase on
ppc64-linux native
compiles even with ulimit -s 500, which is 28 times lower stack usage than
before.


-- 


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

[Bug debug/36060] [4.3/4.4 Regression] Too big stack requirements of cc1plus during GC

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2008-04-27 13:08 ---
Similar to PR35204 shouldn't we simply lift soft stack limits at the start of
gcc?


-- 


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

[Bug debug/36060] [4.3/4.4 Regression] Too big stack requirements of cc1plus during GC

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2008-04-27 13:33 ---
You can't always do that, sometimes the stack limit is a hard limit.
Additionally, often on Linux setrlimit RLIMIT_STACK after exec is already
too late (as in topdown memory layout things are often mapped already close to
the stack bottom limit) and doing RLIMIT_STACK RLIM_INFINITY in the driver
would result in less desirable VM layout.  So, perhaps the driver could try to
silently up the soft limit to say 256MB or so, but relying on that in gcc is
still risky.


-- 


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

[Bug debug/36060] [4.3/4.4 Regression] Too big stack requirements of cc1plus during GC

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2


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