Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ - O0 -w -fno-show-column -c -o limits-exprparen.o /test/gnu/gcc/gcc/gcc/testsuit e/gcc.c-torture/compile/limits-exprparen.c (timeout = 300) ^M Pid 2297 received a SIGSEGV for stack growth failure.^M Possble causes: insufficient memory or swap space,^M or stack size exceeded maxssiz. ^M xgcc: Internal error: Segmentation fault (program cc1) Fails at all optimizations. -bash-2.05b$ ./xgcc -B./ -v Reading specs from ./specs Target: hppa64-hp-hpux11.11 Configured with: ../gcc/configure --with-gnu-as --with-as=/opt/gnu64/bin/as --with-ld=/usr/ccs/bin/ld --enable-shared --disable-nls --with-local-prefix=/opt/gnu64 --prefix=/opt/gnu64/gcc/gcc-4.3.0 --host=hppa64-hp-hpux11.11 --enable-threads=posix --disable-libmudflap --with-gmp=/opt/gnu64/gcc/gcc-4.3.0 --enable-languages=c,c++,fortran,objc,obj-c++,java Thread model: posix gcc version 4.3.0 20070503 (experimental)
I see this also on powerpc64 with a cross to spu-elf.
I am not sure what, if anything, we should do with this bug report. The compiler is working as designed, the test case has a very large number of nested parenthesis which causes the parser to recurse over and over as it parses through the expression. If you have enough stack space (and swap space) the test seems to compile fine in a reasonable amount of time. If you run out of stack space or run out of swap space then the test fails. This test runs fine on my IA64 HP-UX and Linux boxes and on my HPPA HP-UX boxes where I have increased the stack size. If I change the test case to do more nesting, I can get it to fail.
Subject: Re: limits-exprparen.c: Pid 2297 received a SIGSEGV for stack growth failure > This test runs fine on my IA64 HP-UX and Linux boxes and on my HPPA HP-UX boxes > where I have increased the stack size. If I change the test case to do more > nesting, I can get it to fail. For the record, these are the limits on the machine where I saw the failure: -bash-2.05b$ ulimit -a core file size (blocks, -c) 2097151 data seg size (kbytes, -d) 786432 file size (blocks, -f) unlimited max memory size (kbytes, -m) unlimited open files (-n) 256 pipe size (512 bytes, -p) 16 stack size (kbytes, -s) 16384 cpu time (seconds, -t) unlimited max user processes (-u) 76 virtual memory (kbytes, -v) unlimited I believe the stack size limit is double the default value. The machine has 7 GB of memory, so I doubt swap is an issue. It's my personal belief that nesting routines to great depths is bad design. It makes debugging nearly impossible. It's possible we are hurt on hppa64 because the argument pointer isn't a fixed register and this prevents the sibcall optimization from occurring. Dave
*** Bug 38605 has been marked as a duplicate of this bug. ***
Confirmed.
This happens also with default settings on CentOS 5.3 x86_64 and F11 x86_64, current mainline gcc-4.5.0.
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.
Created attachment 18953 [details] 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.
The patch is not enough for mainline because some functions have a bigger stack frame. With the patch, mainline aborts after 9827 recursive calls.
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
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.
(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?
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.
(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!
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?
Created attachment 23576 [details] 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).
Created attachment 23578 [details] 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.
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
Was this patch ever committed? If so, can this PR be closed now?
(In reply to comment #19) > Was this patch ever committed? If so, can this PR be closed now? Yes and yes.