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