Bug 10349 - testsuite failure in g++.dg/parse/stack1.C
Summary: testsuite failure in g++.dg/parse/stack1.C
Status: RESOLVED WONTFIX
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 3.3
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: ice-on-valid-code
Depends on: 12454
Blocks:
  Show dependency treegraph
 
Reported: 2003-04-08 15:56 UTC by Kaveh Ghazi
Modified: 2023-12-31 18:30 UTC (History)
4 users (show)

See Also:
Host: sparc64-sun-solaris2.7
Target: sparc64-sun-solaris2.7
Build: sparc64-sun-solaris2.7
Known to work:
Known to fail:
Last reconfirmed: 2005-12-18 20:06:24


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kaveh Ghazi 2003-04-08 15:56:00 UTC
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
}
Comment 1 Dara Hazeghi 2003-05-26 08:53:25 UTC
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
Comment 2 Eric Botcazou 2003-05-26 11:21:50 UTC
On branch to as of 05/22.
Comment 3 Andrew Pinski 2003-12-29 21:41:53 UTC
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 ***
Comment 4 Kaveh Ghazi 2004-01-01 07:10:18 UTC
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
Comment 5 Kaveh Ghazi 2004-01-01 07:12:52 UTC
Bug really isn't fixed as noted.
Comment 6 Andrew Pinski 2004-01-01 07:13:47 UTC
Minor as checking causes it.  I want to say it is caused by RTL checking.
Comment 7 Andrew Pinski 2004-01-01 07:16:26 UTC
Actually is an enhancement really because it does not ICE with regular checking on the mainline so 
it is caused by RTL checking.
Comment 8 Kaveh Ghazi 2004-01-01 08:17:25 UTC
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.
Comment 9 Andrew Pinski 2004-01-01 08:25:00 UTC
Okay fine what is the back trace, maybe I can get this fixed.
Comment 10 Kaveh Ghazi 2004-01-01 16:17:54 UTC
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}
Comment 11 Eric Botcazou 2004-01-01 16:26:20 UTC
>I used sparc32 because gdb doesn't support sparc64 AFAICT.

It does, when configured specifically for SPARC64.
Comment 12 Andrew Pinski 2004-01-01 16:31:33 UTC
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.
Comment 13 Andrew Pinski 2004-10-27 03:50:34 UTC
#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

Comment 14 Andrew Pinski 2004-11-28 21:10:22 UTC
#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
Comment 15 Eric Botcazou 2006-01-10 12:35:25 UTC
Not really a GCC problem.