Bug in cp/parse.y in 3.1 branch

David O'Brien obrien@FreeBSD.org
Tue Apr 23 12:35:00 GMT 2002


On Tue, Apr 23, 2002 at 02:52:03PM -0400, Jakub Jelinek wrote:
> On Tue, Apr 23, 2002 at 11:27:45AM -0700, David O'Brien wrote:
> > yacc: w - line 2120 of "gcc-3_1-branch/gcc/cp/parse.y", $3 references beyond the end of the current rule
> > yacc: 33 shift/reduce conflicts
> > yacc: 58 reduce/reduce conflicts
> > 
> > 
> > The YACC rule for this is:
> > 
> >     nomods_initdcl0:
> >               notype_declarator maybeasm
> >                 { /* Set things up as initdcl0_innards expects.  */
> >               $<ttype>3 = $2;
> >               $2 = $1;
> >                   $<ftype>1.t = NULL_TREE;
> >               $<ftype>1.lookups = NULL_TREE; }
> >               initdcl0_innards
> >                 {}
> >         | constructor_declarator maybeasm maybe_attribute
> >             { tree d = parse_decl0 ($1, NULL_TREE, NULL_TREE, $3, 0);
> >               parse_end_decl (d, NULL_TREE, $2); }
> >         ;
> > 
> > 
> > There is not match for the "$<ttype>3" pseudo-variable above.
> 
> It is assigned into $3, not read.

So?  What is it being assigned into then?  There is no 3rd RHS rule in
         nomods_initdcl0: notype_declarator maybeasm

Is this working around a bug in Bison, or utilizing a Bison extension?
cc1plus built with a Byacc produced parse.c will not accept all valid C++
code.


> The whole purpose of the above code
> is to move things one slot up, so that it matches what
> initdcl0_innards expects (this is described above initdcl0_innards):
>         /* This rule assumes a certain configuration of the parser stack.
>            In particular, $0, the element directly before the beginning of
>            this rule on the stack, must be a maybeasm.  $-1 must be a
>            declarator or notype_declarator.  And $-2 must be some declmods
>            or declspecs.  We can't move the maybeasm into this rule because
>            we need that reduce so we prefer fn.def1 when appropriate.  */
> If you revert my patch, you end up violating these assumptions.
> 
> 	Jakub

-- 
-- David  (obrien@FreeBSD.org)
          Disclaimer: Not speaking for FreeBSD, just expressing my own opinion.



More information about the Gcc-bugs mailing list