This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

cp/parse.y:2120: invalid value: $3


A recent fix in CVS Bison results in its refusing the current G++
grammar.  It chokes on the following snippet (CVS gcc/cp/parse.y,
around line 2117):

| 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); }
| 	;

Bison now says:

% bison parse.y
parse.y:2120: invalid value: $3

The problem is serious: the assignment violates POSIX (it should read
$<ttype>$), and anyway, could not have worked properly: the first
thing the parser does after having executed this action is replacing
the current slot (which turns out to be exactly that of $3) with $$,
which is uninitialized (well, actually, it's $1).

As far as Bison is concerned, I'd like the GCC team to tell me what
they would prefer:

1. I release this Bison as is, fixed, and it will die on current G++.

2. I introduce a temporary hack to accept this grammar, and still
   produce the old broken code.

3. I introduce a temporary hack to accept this grammar, and produce
   the *intended* code.  I will put a warning though.

Of course, I prefer 1.  Option 3 is tempting, but given that this code
is probably old, making it work might making it fail.  Or maybe it's
just dead code, I don't know.  In any case, I suppose the code should
be audited.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]