Re: (gcc 2.95 & 3.2) Internal compiler error (very short code)

[Zack Weinberg <zack at codesourcery dot com>]

On Thu, Oct 10, 2002 at 09:26:11PM +0200, Lukasz Pankowski wrote:
> I did not thought I find when it happens, so I submitted full code
> (sorry), but few lines are enough (also attachment as file).
> 
> Circumstances when the error appears (a beat bizarre):
> * class definition has now ending semicolon
> * constructor is defined twice: inside and outside of the class
> * the inside constructor has a function declaration in it
>   (which I wanted to be method call -- a copy-and-paste method:))
> 
> 
>         class A
>         {
>                 A() {
>                         void f();
>                 }
>         }
> 
>         A::A()
>         {
>         }

Oh ho! This will make nailing the bug *much* easier.  Thank you.  So
we don't lose it, would you mind re-reporting this through GNATS,
using the form at <http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=create>?
Use the category 'C++' and the class 'ice-on-illegal-code', since this
is ill-formed C++.

Anyhow, by using mudflap I managed to get the bug to manifest itself
as something other than total stack corruption.

Program received signal SIGSEGV, Segmentation fault.
0x0812b85a in yyparse () at parse.y:3110
3110                      got_scope = $$ = TREE_TYPE ($$);
(gdb) l 
3105                    }
3106            | SELFNAME SCOPE
3107                    {
3108                      if (TREE_CODE ($1) == IDENTIFIER_NODE)
3109                        $$ = lastiddecl;
3110                      got_scope = $$ = TREE_TYPE ($$);
3111                    }
3112            | NSNAME SCOPE
3113                    {
3114                      if (TREE_CODE ($$) == IDENTIFIER_NODE)
(gdb) p lastiddecl
$1 = 0x0
(gdb) p yyvsp[-1].ttype->common.code
$2 = IDENTIFIER_NODE

Presumably the syntax errors are what cause lastiddecl to be NULL
here, when it shouldn't.

lastiddecl is a global state variable used to communicate between the
lexer and the parser.  I suspect it will be difficult to find out why
it isn't set here and yet we reach a point where it's expected to be.
Since this is a long-standing bug and does not cause problems for
correct code, my inclination is to leave it unfixed until the new
parser (which will not have to play silly buggers with global state
communication between the lexer and the parser) comes in.  That will
hopefully happen in 3.4.

C++ front end gurus please feel free to jump in and show me it's
actually easy to fix this, though.

zw