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