GCC-3.2.2 bootstrap FAILURE: 1 reduce/reduce conflict in objc-parse.y
Ziemowit Laski
zlaski@apple.com
Thu Jan 30 01:53:00 GMT 2003
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
More information about the Gcc-bugs
mailing list