[Bug middle-end/31827] limits-exprparen.c: Pid 2297 received a SIGSEGV for stack growth failure

[Bug middle-end/31827] limits-exprparen.c: Pid 2297 received a SIGSEGV for stack growth failure

[davek at gcc dot gnu.org]

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

Dave Korn <davek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |davek at gcc dot gnu.org
      Known to fail|                            |4.6.0

--- Comment #10 from Dave Korn <davek at gcc dot gnu.org> 2010-11-13 00:58:39 UTC ---
Also failing on i686 cygwin and on i686 and x86_64 linux at the moment.  See,
e.g.

http://gcc.gnu.org/ml/gcc-testresults/2010-11/msg01011.html
http://gcc.gnu.org/ml/gcc-testresults/2010-11/msg01008.html
http://gcc.gnu.org/ml/gcc-testresults/2010-11/msg01006.html

[Bug middle-end/31827] limits-exprparen.c: Pid 2297 received a SIGSEGV for stack growth failure

[davek at gcc dot gnu.org]

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

--- Comment #12 from Dave Korn <davek at gcc dot gnu.org> 2011-02-01 04:03:02 UTC ---
(In reply to comment #11)
> Recreated this on linux x86_64 with gcc 4.6-20110129. Running ulimit -a shows
> me that the default stack limit is 8192 and increasing this to 18000 allows the
> test to complete at all optimization levels that are tested by make check.
> Running at 17000 fails.

  This has gotten worse over the past couple of months; I fixed it on cygwin a
while ago by turning up the stack size, finding that it needed somewhere
between 10MB and 12MB on that target; now it's just started failing again.

  I don't know at what point we should consider this a compile-time performance
regression.  Paolo, even a 30% reduction seems like a good idea to me; why not
submit that patch you developed?

[Bug middle-end/31827] limits-exprparen.c: Pid 2297 received a SIGSEGV for stack growth failure

[joseph at codesourcery dot com]

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

--- Comment #13 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2011-02-01 17:00:26 UTC ---
Out of interest, does compiling GCC with -fsplit-stack help avoid this 
problem?  This obviously has limitations at present regarding supported 
hosts, and the need for gold as host linker to avoid problems when calling 
code built without that option, but it seems like something that option 
ought to help with.

[Bug middle-end/31827] limits-exprparen.c: Pid 2297 received a SIGSEGV for stack growth failure

[davek at gcc dot gnu.org]

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

--- Comment #14 from Dave Korn <davek at gcc dot gnu.org> 2011-02-01 17:37:08 UTC ---
(In reply to comment #13)
> [ ... ] -fsplit-stack [ ... ] need for gold as host linker [ ... ]

One of the ELF guys will have to answer that one for you!

[Bug middle-end/31827] limits-exprparen.c: Pid 2297 received a SIGSEGV for stack growth failure

[gseanmcg at gmail dot com]

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

Sean McGovern <gseanmcg at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ro at gcc dot gnu.org

--- Comment #15 from Sean McGovern <gseanmcg at gmail dot com> 2011-03-07 19:54:39 UTC ---
Cc'ing Rainer as this is also happening on Solaris 10 x86 and SPARC.

As indicated in comment 3, this can be remedied by bumping stack size from
defaults. Is there any way to instrument the test to bump it automatically, and
if so, what is an agreeable value?

[Bug middle-end/31827] limits-exprparen.c: Pid 2297 received a SIGSEGV for stack growth failure

[jakub at gcc dot gnu.org]

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

--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-03-07 20:41:12 UTC ---
Created attachment 23576
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23576
hack

The c_parser_binary_expression stack impact could be decreased, either through
a hack like this (forcefully split the function, so that when calling the first
cast expression it will use smaller amount of stack, unfortunately the call
isn't then tail callable and thus for an actual binary expression needs more
stack), or stack/sp perhaps could be handled separately (global stack vector).

[Bug middle-end/31827] limits-exprparen.c: Pid 2297 received a SIGSEGV for stack growth failure

[jakub at gcc dot gnu.org]

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

--- Comment #17 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-03-07 21:35:24 UTC ---
Created attachment 23578
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23578
Implement stack in c_parser_binary_operation as VEC

And here is the alternative to use global VEC as c_parser_binary_expression
stack.  The stack size in my case for c_parser_binary_expression decreases from
sub $0x218, %rsp to sub $0x78, %rsp.

Paolo's patch is clearly better than my first patch, sorry for not reading it
first.

[Bug middle-end/31827] limits-exprparen.c: Pid 2297 received a SIGSEGV for stack growth failure

[ubizjak at gmail dot com]

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

--- Comment #18 from Uros Bizjak <ubizjak at gmail dot com> 2011-07-22 15:50:58 UTC ---
The patch that increased RLIMIT_STACK in the driver as well as compiler (PR
c++/49756) [1] fixed this on linux targets.

Jakub, you have a patch pending in Comment #17. Do you plan to commit it?

Can we close this PR?

[1] http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01766.html

[Bug middle-end/31827] limits-exprparen.c: Pid 2297 received a SIGSEGV for stack growth failure

[gseanmcg at gmail dot com]

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

--- Comment #19 from Sean McGovern <gseanmcg at gmail dot com> 2011-11-25 16:17:03 UTC ---
Was this patch ever committed? If so, can this PR be closed now?

[Bug middle-end/31827] limits-exprparen.c: Pid 2297 received a SIGSEGV for stack growth failure

[ubizjak at gmail dot com]

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

Uros Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
                URL|                            |http://gcc.gnu.org/ml/gcc-p
                   |                            |atches/2011-07/msg01766.htm
                   |                            |l
               Host|hppa64-hp-hpux11.11         |
         Resolution|                            |FIXED
   Target Milestone|---                         |4.7.0

--- Comment #20 from Uros Bizjak <ubizjak at gmail dot com> 2011-11-25 16:34:14 UTC ---
(In reply to comment #19)
> Was this patch ever committed? If so, can this PR be closed now?

Yes and yes.

[Bug middle-end/31827] limits-exprparen.c: Pid 2297 received a SIGSEGV for stack growth failure

[bonzini at gnu dot org]

------- Comment #9 from bonzini at gnu dot org  2009-11-03 18:58 -------
The patch is not enough for mainline because some functions have a bigger stack
frame.  With the patch, mainline aborts after 9827 recursive calls.


-- 

bonzini at gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ra


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

[Bug middle-end/31827] limits-exprparen.c: Pid 2297 received a SIGSEGV for stack growth failure

[bonzini at gnu dot org]

------- Comment #8 from bonzini at gnu dot org  2009-11-03 12:23 -------
Created an attachment (id=18953)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18953&action=view)
patch to fix the bug

The attached patches together reduce the stack usage of expression parsing by
~30%.  On a 64-bit machine with 8 MB the parsing now fails after 10300
recursions instead of 7100.

This still means that one pair of parentheses consumes about 100 words on the
stack.


-- 


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

[Bug middle-end/31827] limits-exprparen.c: Pid 2297 received a SIGSEGV for stack growth failure

[bonzini at gnu dot org]

------- Comment #7 from bonzini at gnu dot org  2009-11-03 10:23 -------
Part of the problem is that for each open parenthesis we go through

c_parser_postfix_expression
c_parser_expression
c_parser_expr_no_commas
c_parser_conditional_expression
c_parser_binary_expression
c_parser_cast_expression
c_parser_unary_expression

and back to c_parser_postfix_expression.  c_parser_binary_expression has a
_huge_ stack impact, this should be fixed.


-- 

bonzini at gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |bonzini at gnu dot org
                   |dot org                     |
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2008-12-29 07:24:07         |2009-11-03 10:23:32
               date|                            |


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

[Bug middle-end/31827] limits-exprparen.c: Pid 2297 received a SIGSEGV for stack growth failure

[ubizjak at gmail dot com]

------- Comment #6 from ubizjak at gmail dot com  2009-07-23 06:52 -------
This happens also with default settings on CentOS 5.3 x86_64 and F11 x86_64,
current mainline gcc-4.5.0.


-- 

ubizjak at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ubizjak at gmail dot com
      Known to fail|                            |4.5.0


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

[Bug middle-end/31827] limits-exprparen.c: Pid 2297 received a SIGSEGV for stack growth failure

[pinskia at gcc dot gnu dot org]

------- Comment #5 from pinskia at gcc dot gnu dot org  2008-12-29 07:24 -------
Confirmed.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
          Component|other                       |middle-end
     Ever Confirmed|0                           |1
           Keywords|                            |ice-on-valid-code
   Last reconfirmed|0000-00-00 00:00:00         |2008-12-29 07:24:07
               date|                            |


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