From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-66971-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 2974 invoked by alias); 28 Jan 2003 12:30:25 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 2963 invoked from network); 28 Jan 2003 12:30:24 -0000
Received: from unknown (HELO mail.polimi.it) (131.175.12.67)
  by 172.16.49.205 with SMTP; 28 Jan 2003 12:30:24 -0000
Received: from nero (paolob@nero.rett.polimi.it [131.175.6.122])
	by mail.polimi.it (Switch-2.2.4/Switch-2.2.4) with ESMTP id h0SCUL523872
	for <gcc@gcc.gnu.org>; Tue, 28 Jan 2003 13:30:22 +0100 (MET)
Content-Type: text/plain;
  charset="us-ascii"
From: Paolo Bonzini <paolo.bonzini@polimi.it>
Reply-To: bonzini@gnu.org
To: gcc@gcc.gnu.org
Subject: Re: GCC-3.2.2 bootstrap FAILURE: 1 reduce/reduce conflict in objc-parse.y
Date: Tue, 28 Jan 2003 14:04:00 -0000
User-Agent: KMail/1.4.2
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Message-Id: <200301281328.02790.paolo.bonzini@polimi.it>
X-SW-Source: 2003-01/txt/msg01452.txt.bz2

> I'm not the maintainer, but the patch is wrong.  One cannot replace
> 'protocolrefs' with 'non_empty_protocolrefs', as they are optional.

Right. Then the solution is to add a special non-terminal to identify an
identifier_list of at least two identifiers.

!       /* The @protocol forward-declaration production introduces a
!          reduce/reduce conflict on ';', which should be resolved in
!          favor of the production 'identifier_list -> identifier'.  */
!       | PROTOCOL identifier_list ';'
!               {
!                 objc_declare_protocols ($2);
!               }

This is never reduced if identifier_list is a single identifier.

The 3.2 and 3.3 branch solution might be simply to remove %expect, but=20
something else should be done on mainline (possibly 3.3 too).

While I agree in principle that reduce/reduce conflicts are bugs,
they are often (like in this case) problems in the language spec
which is not really LR(1).  Bison should have an option for
"%expect" to specify the count of RR conflicts in the grammar;
new Bisons use a Bison grammar and the change should be
quite simple.

Paolo