As noted here: http://gcc.gnu.org/ml/gcc-testresults/2003-04/msg00483.html I'm getting testsuite failures in gcc-3.3 on sparc64-sun-solaris2.7 for g++.dg/parse/stack1.C. The compiler crashes with a segmentation fault compiling the testcase. After some investigation I determined that the problem is that it is running out of stack space. Solaris2.7 (and 2.8) seem to come configured with stacksize set to 8192K. When I raise it to 16384K the testcase compiles. That seems like an excessively large amount of stack space consumption, given that the regular v7 sparc compiles it in as low as 2048K stack. It's not affected by the GC tuning parameters, i.e. large and small RAM systems get the same crash at stacksize 8192K. A fix for the original problem was applied (see PR2161) but I'm getting failures in this configuration. Release: gcc version 3.3 20030408 (prerelease) Environment: sparc64-sun-solaris2.7 How-To-Repeat: The original PR fix involved bison to some degree. I'm using bison 1.75 if that matters. I cannot get the testcase to fail in a 32->64 cross compiler. A native sparc64-sun-solaris2.7 build with stacksize set to 8192 (the default I believe on solaris2.7) seems to be required. You might be able to get it to fail on other sparc64 platforms with limited stacksize, I can't say for sure. Simply compile stack1.C with -S and note the compiler crash. Change stacksize to 16384K and it succeeds. /* PR c/2161: parser stack overflow. */ /* { dg-do compile } */ #define ONE else if (0) { } #define TEN ONE ONE ONE ONE ONE ONE ONE ONE ONE ONE #define HUN TEN TEN TEN TEN TEN TEN TEN TEN TEN TEN #define THOU HUN HUN HUN HUN HUN HUN HUN HUN HUN HUN void foo() { if (0) { } /* 11,000 else if's. */ THOU THOU THOU THOU THOU THOU THOU THOU THOU THOU THOU }
Hello, according to gcc-testresults, this problem is still occuring on mainline (http://gcc.gnu.org/ml/ gcc-testresults/2003-05/msg01389.html) and possibly on branch. Dara
On branch to as of 05/22.
This is fixed for 3.3.3, as this is a dup of bug 10060. *** This bug has been marked as a duplicate of 10060 ***
Subject: Re: testsuite failure in g++.dg/parse/stack1.C This PR is not fixed for 3.3.3, when I configure with checking enabled, I still get the error. (I thought it was noted in the PR that some enable checking parameter is required to trigger, but now I don't see it). Anyway, see: http://gcc.gnu.org/ml/gcc-testresults/2004-01/msg00013.html I used --enable-checking=misc,tree,rtl,rtlflag,gc I'm not sure which one exposes the bug. Please reopen the PR. Thanks, --Kaveh
Bug really isn't fixed as noted.
Minor as checking causes it. I want to say it is caused by RTL checking.
Actually is an enhancement really because it does not ICE with regular checking on the mainline so it is caused by RTL checking.
Don't be so dismissive of the bug. It still occurs on mainline and does not require RTL checking. All you need to do is increase the else-if count in the testcase from 11k to 100k (or more.) At some point you'll get a crash.
Okay fine what is the back trace, maybe I can get this fixed.
Subject: Re: testsuite failure in g++.dg/parse/stack1.C With gdb I can't get a good trace, perhaps because the stack overflowed. Also given that it crashes in the parser, the 3.4 bug might be different than the 3.3.x one. Or maybe not. Note this was 3.4 configured with no special options on sparc-sun-solaris2.7, (i.e. sparc64, listed in the initial report, is not necessary given a larger number of "else-ifs". Though the crash still happens on sparc64 also.) I used sparc32 because gdb doesn't support sparc64 AFAICT. GNU gdb 5.3 [...] (gdb) run -fpreprocessed stack2.ii -quiet -dumpbase stack2.C -mcpu=v7 -auxbase stack2 -version -o stack2.s Starting program: /teal/tmpdisk/ghazi/gcc-testing/34/build/gcc/cc1plus -fpreprocessed stack2.ii -quiet -dumpbase stack2.C -mcpu=v7 -auxbase stack2 -version -o stack2.s GNU C++ version 3.4.0 20040101 (experimental) (sparc-sun-solaris2.7) compiled by GNU C version 3.4.0 20040101 (experimental). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Program received signal SIGSEGV, Segmentation fault. 0x000ed7e8 in cp_parser_type_name (parser=0xff10ff80) at ../../egcc-CVS20040101/gcc/cp/parser.c:8752 8752 type_decl = cp_parser_class_name (parser, (gdb) bt #0 0x000ed7e8 in cp_parser_type_name (parser=0xff10ff80) at ../../egcc-CVS20040101/gcc/cp/parser.c:8752 Cannot access memory at address 0xff3eff54 (gdb) list 8752 type_decl = cp_parser_class_name (parser, 8753 /*typename_keyword_p=*/false, 8754 /*template_keyword_p=*/false, 8755 /*type_p=*/false, 8756 /*check_dependency_p=*/true, 8757 /*class_head_p=*/false, 8758 /*is_declaration=*/false); 8759 /* If it's not a class-name, keep looking. */ 8760 if (!cp_parser_parse_definitely (parser)) 8761 { (gdb) p *parser $2 = {lexer = 0x3b6c0000, scope = 0xfd068320, object_scope = 0x500660, qualifying_scope = 0x10, context = 0x2e6c0000, allow_gnu_extensions_p = false, greater_than_is_operator_p = false, default_arg_ok_p = false, integral_constant_expression_p = false, allow_non_integral_constant_expression_p = false, non_integral_constant_expression_p = 80, in_offsetof_p = 6, local_variables_forbidden_p = 96, in_unbraced_linkage_specification_p = false, in_declarator_p = false, in_template_argument_list_p = false, in_iteration_statement_p = 16, in_switch_statement_p = 71, type_definition_forbidden_message = 0xff390180 "", unparsed_functions_queues = 0x500660, num_classes_being_defined = 16, num_template_parameter_lists = 1193410560}
>I used sparc32 because gdb doesn't support sparc64 AFAICT. It does, when configured specifically for SPARC64.
One issue is that the following code is not sibcalled: 6073 /* Otherwise, we simply parse the statement directly. */ 6074 else 6075 statement = cp_parser_compound_statement (parser, false); 6076 6077 /* Return the statement. */ 6078 return statement; I know that is fixed on the tree-ssa (but there is already another problem on the tree-ssa see bug 12454), there might be other problems too.
#1251 0x000ae778 in cp_parser_implicitly_scoped_statement (parser=0x4178ec40) at /Users/pinskia/ src/local/gcc/gcc/cp/parser.c:6541 #1252 0x0009dba4 in cp_parser_statement (parser=0x4178ec40, in_statement_expr=0x0) at /Users/ pinskia/src/local/gcc/gcc/cp/parser.c:6115 #1253 0x000ae778 in cp_parser_implicitly_scoped_statement (parser=0x4178ec40) at /Users/pinskia/ src/local/gcc/gcc/cp/parser.c:6541
#1138 0x0005d820 in cp_parser_implicitly_scoped_statement (parser=0x424b6c40) at /Users/pinskia/ src/local3/gcc/gcc/cp/parser.c:6541 #1139 0x00053100 in cp_parser_statement (parser=0x424b6c40, in_statement_expr=0x0) at /Users/ pinskia/src/local3/gcc/gcc/cp/parser.c:6115
Not really a GCC problem.