This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: GCC-3.2.2 bootstrap FAILURE: 1 reduce/reduce conflict in objc-parse.y
- From: Ziemowit Laski <zlaski at apple dot com>
- To: "Joseph S. Myers" <jsm28 at cam dot ac dot uk>
- Cc: Joe Buck <jbuck at synopsys dot com>, Gabriel Dos_Reis <gdosreis at sophia dot inria dot fr>, gcc-bugs at gcc dot gnu dot org, gcc at gcc dot gnu dot org
- Date: Wed, 29 Jan 2003 16:39:30 -0800
- Subject: Re: GCC-3.2.2 bootstrap FAILURE: 1 reduce/reduce conflict in objc-parse.y
On Wednesday, Jan 29, 2003, at 15:17 US/Pacific, Joseph S. Myers wrote:
On Wed, 29 Jan 2003, Joe Buck wrote:
I disagree. For languages that have a natural LALR(1) grammar, you
are
correct, but Objective-C is not necessarily such a language. If the
current
parser works, it is wrong to risk breaking it.
Hear, hear! :-)
It has been suggested that cc1obj should be merged into cc1 (making
Objective-C a runtime dialect choice). If this is done before Neil's
parser is available, and if it isn't done by embedding two separate
Bison
parsers in one executable, then these conflicts get introduced in the C
grammar and risk breaking that.
What does "Neil's parser" refer to, exactly? I apologize for being
out of the loop on this...
As far as ObjC conflicts breaking the C grammar, this is possible iff
the
ObjC-conflict-prone state can be reached from "pure C" states.
This probably holds true for some of the shift/reduce conflicts,
but these can be analyzed one-by-one and resolved via appropriate %prec
annotations.
Unfortunately, bison/yacc does not have a notation which says,
"I want you to resolve this reduce/reduce conflict as follows, and I
know
what I'm doing; trust me." However, the 1 reduce/reduce conflict we
currently have occurs in the state with the following kernel:
identifier_list : identifier . (581)
protocoldef : PROTOCOL identifier . protocolrefs $$52
methodprotolist END (605)
protocolrefs : . (607)
which is reachable _only_ from the following state:
protocoldef : PROTOCOL . identifier protocolrefs $$52
methodprotolist END (605)
protocoldef : PROTOCOL . identifier_list ';' (606)
In other words, you must be parsing a @protocol declaration or
definition to
even stumble upon this. If you're compiling straight C code, you will
never get
here. (Perhaps we can put a comment to this effect in c-parse.in?)
--Zem
--------------------------------------------------------------
Ziemowit Laski 1 Infinite Loop, MS 301-2K
Mac OS X Compiler Group Cupertino, CA USA 95014-2083
Apple Computer, Inc. +1.408.974.6229 Fax .5477