Re: GCC-3.2.2 bootstrap FAILURE: 1 reduce/reduce conflict in objc-parse.y

Re: GCC-3.2.2 bootstrap FAILURE: 1 reduce/reduce conflict in objc-parse.y

[Paolo Bonzini]

> 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 
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

Re: GCC-3.2.2 bootstrap FAILURE: 1 reduce/reduce conflict in objc-parse.y

[Paolo Bonzini]

> 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:

It is easy to fix this particular RR conflict, see

http://gcc.gnu.org/ml/gcc/2003-01/msg01443.html

Paolo

GCC-3.2.2 bootstrap FAILURE: 1 reduce/reduce conflict in objc-parse.y

[Gabriel Dos_Reis]

A fresh checkout of 3.2.2 branch fails to bootstrap on an i686-pc-linux.  
The failure happens for Objective-C as a reduce/reduce conflict in
objc-parse.y.  I can't locate a recent change to  that file.  So I
guess it must be something having to do my settings.  I'm using Bison
1.875.  Is anyone seeing this failure?

(I'm running another bootstrap on a different machine)

-- Gaby
[...]

stage1/xgcc -Bstage1/ -B/u/molotova/0/galaad/gdosreis/.target/i686-pc-linux-gnu/i686-pc-linux-gnu/bin/ -DIN_GCC    -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long  -DHAVE_CONFIG_H    -I. -I. -I/u/molotova/0/galaad/gdosreis/src/redhat/gcc-3.2/gcc -I/u/molotova/0/galaad/gdosreis/src/redhat/gcc-3.2/gcc/. -I/u/molotova/0/galaad/gdosreis/src/redhat/gcc-3.2/gcc/config -I/u/molotova/0/galaad/gdosreis/src/redhat/gcc-3.2/gcc/../include -I/u/molotova/0/galaad/gdosreis/src/redhat/gcc-3.2/gcc/objc \
-c /u/molotova/0/galaad/gdosreis/src/redhat/gcc-3.2/gcc/objc/objc-lang.c -o objc-lang.o
cd /u/molotova/0/galaad/gdosreis/src/redhat/gcc-3.2/gcc/objc; \
if bison  -o op$$.c objc-parse.y ; then \
  test -f op$$.output && mv -f op$$.output objc-parse.output ; \
  mv -f op$$.c objc-parse.c ; \
else \
  rm -f op$$.* ; \
  false ; \
fi
objc-parse.y: conflicts: 31 shift/reduce, 1 reduce/reduce
objc-parse.y: expected 0 reduce/reduce conflicts
make[2]: *** [/u/molotova/0/galaad/gdosreis/src/redhat/gcc-3.2/gcc/objc/objc-parse.c] Error 1
make[2]: Leaving directory `/0/var/tmp/gdr/gcc/gcc'
make[1]: *** [stage2_build] Error 2
make[1]: Leaving directory `/0/var/tmp/gdr/gcc/gcc'
make: *** [bootstrap] Error 2

Re: GCC-3.2.2 bootstrap FAILURE: 1 reduce/reduce conflict in objc-parse.y

[Gabriel Dos Reis]

Gabriel Dos_Reis <gdosreis@sophia.inria.fr> writes:

| A fresh checkout of 3.2.2 branch fails to bootstrap on an i686-pc-linux.  
| The failure happens for Objective-C as a reduce/reduce conflict in
| objc-parse.y.  I can't locate a recent change to  that file.  So I
| guess it must be something having to do my settings.  I'm using Bison
| 1.875.  Is anyone seeing this failure?
| 
| (I'm running another bootstrap on a different machine)

I can confirm that using Bison 1.33 I was able to bootstrap objc.

Could anyone bootstrap with Bison 1.875?

Thanks,

-- Gaby
 

Re: GCC-3.2.2 bootstrap FAILURE: 1 reduce/reduce conflict in objc-parse.y

[Paolo Carlini]

Gabriel Dos Reis wrote:

>Could anyone bootstrap with Bison 1.875?
>
Just tried for you, Gaby: definitely Bison 1.875 is not ok for Objc!

Paolo.

Re: GCC-3.2.2 bootstrap FAILURE: 1 reduce/reduce conflict in objc-parse.y

[Gabriel Dos Reis]

Paolo Carlini <pcarlini@unitus.it> writes:

| Gabriel Dos Reis wrote:
| 
| >Could anyone bootstrap with Bison 1.875?
| >
| Just tried for you, Gaby: definitely Bison 1.875 is not ok for Objc!

Thanks!

I don't know whether this is a bug in objc-parse.y or a bug in Bison
1.875. I'll make a release note unless someone comes with a fix.

-- Gaby

Re: GCC-3.2.2 bootstrap FAILURE: 1 reduce/reduce conflict in objc-parse.y

[Raja R Harinath]

Hi,

Gabriel Dos Reis <gdr@integrable-solutions.net> writes:

> Paolo Carlini <pcarlini@unitus.it> writes:
>
> | Gabriel Dos Reis wrote:
> | 
> | >Could anyone bootstrap with Bison 1.875?
> | >
> | Just tried for you, Gaby: definitely Bison 1.875 is not ok for Objc!
>
> Thanks!
>
> I don't know whether this is a bug in objc-parse.y or a bug in Bison
> 1.875. I'll make a release note unless someone comes with a fix.

See 

  objc/9267: bison 1.875 doesn't like reduce/reduce errors with %expect N

It is a bug in 'objc-parse.y' (a misuse of %expect).  There has
been a reduce/reduce conflict in that file for quite some time.  The
comment even says so (c-parse.in):

  ifobjc
  %expect 32 /* shift/reduce conflicts, and 1 reduce/reduce conflict.  */
  end ifobjc

However, %expect, among other things, means "exactly 0 reduce/reduce
conflicts".

Older versions of bison correctly warned about finding reduce/reduce
conflicts -- thus defeating the only purpose of the %expect: avoid
warnings.

Bison 1.875 escalated the warning to an error.  The CVS version of
bison has de-escalated this back to a warning.

The correct fix to the bug: kill the %expect line in objc-parse.y.
This will have no functional change.  There was a warning before, and
there'll be a warning now, when you process objc-parse.y.  Only now,
you aren't claiming things that aren't true.

- Hari
-- 
Raja R Harinath ------------------------------ harinath@cs.umn.edu

Re: GCC-3.2.2 bootstrap FAILURE: 1 reduce/reduce conflict in objc-parse.y

[Gabriel Dos Reis]

Raja R Harinath <harinath@cs.umn.edu> writes:

| Hi,
| 
| Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
| 
| > Paolo Carlini <pcarlini@unitus.it> writes:
| >
| > | Gabriel Dos Reis wrote:
| > | 
| > | >Could anyone bootstrap with Bison 1.875?
| > | >
| > | Just tried for you, Gaby: definitely Bison 1.875 is not ok for Objc!
| >
| > Thanks!
| >
| > I don't know whether this is a bug in objc-parse.y or a bug in Bison
| > 1.875. I'll make a release note unless someone comes with a fix.
| 
| See 
| 
|   objc/9267: bison 1.875 doesn't like reduce/reduce errors with %expect N

Aha, thanks.

| It is a bug in 'objc-parse.y' (a misuse of %expect).  There has
| been a reduce/reduce conflict in that file for quite some time.  The
| comment even says so (c-parse.in):
| 
|   ifobjc
|   %expect 32 /* shift/reduce conflicts, and 1 reduce/reduce conflict.  */
|   end ifobjc

Interestingly, that number is 31 in my local copy of objc-parse.y.
The fix you propose sounds sensible to me.  An Objective-C maintainer
cares to comment before I make that change? 

-- Gaby

Re: GCC-3.2.2 bootstrap FAILURE: 1 reduce/reduce conflict in objc-parse.y

[Joseph S. Myers]

On Mon, 27 Jan 2003, Gabriel Dos_Reis wrote:

> A fresh checkout of 3.2.2 branch fails to bootstrap on an i686-pc-linux.  
> The failure happens for Objective-C as a reduce/reduce conflict in
> objc-parse.y.  I can't locate a recent change to  that file.  So I
> guess it must be something having to do my settings.  I'm using Bison
> 1.875.  Is anyone seeing this failure?

An objc maintainer needs to review
<http://gcc.gnu.org/ml/gcc-bugs/2003-01/msg00900.html>.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: GCC-3.2.2 bootstrap FAILURE: 1 reduce/reduce conflict in objc-parse.y

[Gabriel Dos Reis]

"Joseph S. Myers" <jsm28@cam.ac.uk> writes:

| On Mon, 27 Jan 2003, Gabriel Dos_Reis wrote:
| 
| > A fresh checkout of 3.2.2 branch fails to bootstrap on an i686-pc-linux.  
| > The failure happens for Objective-C as a reduce/reduce conflict in
| > objc-parse.y.  I can't locate a recent change to  that file.  So I
| > guess it must be something having to do my settings.  I'm using Bison
| > 1.875.  Is anyone seeing this failure?
| 
| An objc maintainer needs to review
| <http://gcc.gnu.org/ml/gcc-bugs/2003-01/msg00900.html>.

Ah, I wasn't aware a fix was proposed by the guy next the wall ;-)

Thanks,

-- Gaby

Re: GCC-3.2.2 bootstrap FAILURE: 1 reduce/reduce conflict in objc-parse.y

[Ziemowit Laski]

On Monday, Jan 27, 2003, at 14:02 US/Pacific, Joseph S. Myers wrote:

> On Mon, 27 Jan 2003, Gabriel Dos_Reis wrote:
>
>> A fresh checkout of 3.2.2 branch fails to bootstrap on an 
>> i686-pc-linux.
>> The failure happens for Objective-C as a reduce/reduce conflict in
>> objc-parse.y.  I can't locate a recent change to  that file.  So I
>> guess it must be something having to do my settings.  I'm using Bison
>> 1.875.  Is anyone seeing this failure?
>
> An objc maintainer needs to review
> <http://gcc.gnu.org/ml/gcc-bugs/2003-01/msg00900.html>.

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

--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

Re: GCC-3.2.2 bootstrap FAILURE: 1 reduce/reduce conflict in objc-parse.y

[Gabriel Dos_Reis]

| On Monday, Jan 27, 2003, at 14:02 US/Pacific, Joseph S. Myers wrote:
| 
| > On Mon, 27 Jan 2003, Gabriel Dos_Reis wrote:
| >
| >> A fresh checkout of 3.2.2 branch fails to bootstrap on an 
| >> i686-pc-linux.
| >> The failure happens for Objective-C as a reduce/reduce conflict in
| >> objc-parse.y.  I can't locate a recent change to  that file.  So I
| >> guess it must be something having to do my settings.  I'm using Bison
| >> 1.875.  Is anyone seeing this failure?
| >
| > An objc maintainer needs to review
| > <http://gcc.gnu.org/ml/gcc-bugs/2003-01/msg00900.html>.
| 
| I'm not the maintainer, but the patch is wrong.  One cannot replace
| 'protocolrefs' with 'non_empty_protocolrefs', as they are optional.

Thanks for the review.  

I went with the fix that consists in removing the "%expect" directive.

Thanks,

-- Gaby

Re: GCC-3.2.2 bootstrap FAILURE: 1 reduce/reduce conflict in objc-parse.y

[Joseph S. Myers]

On Mon, 27 Jan 2003, Ziemowit Laski wrote:

> > An objc maintainer needs to review
> > <http://gcc.gnu.org/ml/gcc-bugs/2003-01/msg00900.html>.
> 
> I'm not the maintainer, but the patch is wrong.  One cannot replace
> 'protocolrefs' with 'non_empty_protocolrefs', as they are optional.

A reduce/reduce conflict is still a bug, even if the fix is more
complicated.  Removing %expect is only a workaround.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: GCC-3.2.2 bootstrap FAILURE: 1 reduce/reduce conflict in objc-parse.y

[Gabriel Dos Reis]

"Joseph S. Myers" <jsm28@cam.ac.uk> writes:

| On Mon, 27 Jan 2003, Ziemowit Laski wrote:
| 
| > > An objc maintainer needs to review
| > > <http://gcc.gnu.org/ml/gcc-bugs/2003-01/msg00900.html>.
| > 
| > I'm not the maintainer, but the patch is wrong.  One cannot replace
| > 'protocolrefs' with 'non_empty_protocolrefs', as they are optional.
| 
| A reduce/reduce conflict is still a bug, even if the fix is more
| complicated.  Removing %expect is only a workaround.

It appears that even if the '%expect' directive is left there, then
the compiler could still be build with  a version of Bison that does not
turn the warning into an error.  That is the case for every version of
Bison since 1.28 except 1.875.

Re: GCC-3.2.2 bootstrap FAILURE: 1 reduce/reduce conflict in objc-parse.y

[Ziemowit Laski]

On Monday, Jan 27, 2003, at 23:16 US/Pacific, Joseph S. Myers wrote:

> On Mon, 27 Jan 2003, Ziemowit Laski wrote:
>
>>> An objc maintainer needs to review
>>> <http://gcc.gnu.org/ml/gcc-bugs/2003-01/msg00900.html>.
>>
>> I'm not the maintainer, but the patch is wrong.  One cannot replace
>> 'protocolrefs' with 'non_empty_protocolrefs', as they are optional.
>
> A reduce/reduce conflict is still a bug, even if the fix is more
> complicated.  Removing %expect is only a workaround.

A reduce/reduce conflict is certainly an annoyance, but it is not a bug 
-- bison has a deterministic, POSIX-annointed method for dealing with 
it, which the grammar writer knows and expects.

A slightly better way, IMHO, would be to allow %expect to take an 
optional second argument

   %expect sr_conflicts [, rr_conflicts]

so that the grammar writer could state her intent more clearly.  
However, since this mechanism doesn't exist, whacking the %expect 
altogether is a sensible approach.

--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

Re: GCC-3.2.2 bootstrap FAILURE: 1 reduce/reduce conflict in objc-parse.y

[Joseph S. Myers]

On Tue, 28 Jan 2003, Ziemowit Laski wrote:

> A reduce/reduce conflict is certainly an annoyance, but it is not a bug 
> -- bison has a deterministic, POSIX-annointed method for dealing with 
> it, which the grammar writer knows and expects.

It is, at very least, very bad grammar style, as discussed in the Bison
manual.  The grammar should be changed (even though this may make it more
complicated) to avoid the conflict.

(The number of shift/reduce conflicts not involving error recovery should
also be minimised, with each one individually analysed and justified to
show it does parse correctly.  %expect is not meant to be used to shut up
Bison by putting in the number of conflicts it says there are until it's
been verified that those conflicts are correct.)

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: GCC-3.2.2 bootstrap FAILURE: 1 reduce/reduce conflict in objc-parse.y

[Ziemowit Laski]

On Tuesday, Jan 28, 2003, at 15:08 US/Pacific, Joseph S. Myers wrote:

> On Tue, 28 Jan 2003, Ziemowit Laski wrote:
>
>> A reduce/reduce conflict is certainly an annoyance, but it is not a 
>> bug
>> -- bison has a deterministic, POSIX-annointed method for dealing with 
>> it, which the grammar writer knows and expects.
>
> It is, at very least, very bad grammar style, as discussed in the Bison
> manual.  The grammar should be changed (even though this may make it 
> more
> complicated) to avoid the conflict.

Yes, but style is inherently aesthetic -- and hence subjective -- in 
nature.
If you can find an equivalent grammar that is both intuitive to the 
reader
and conflict-free, then by all means do so.  But if your conflict-free 
grammar
has more to do with Chomsky Normal Form than the language it describes, 
then
I respectfully part company. :-)  The grammar must, first and foremost, 
be
readable and maintainable.  Why else would one use a parser generator in
the first place?

--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

Re: GCC-3.2.2 bootstrap FAILURE: 1 reduce/reduce conflict in objc-parse.y

[Joseph S. Myers]

On Tue, 28 Jan 2003, Ziemowit Laski wrote:

> I respectfully part company. :-)  The grammar must, first and
> foremost, be readable and maintainable.  Why else would one use a
> parser generator in the first place?

Maintainability is the reason to avoid parser conflicts.  Every change to
a parser that changes the number of conflicts requires all the conflicts
to be examined carefully to ensure that the parser will parse correctly in
each case and that no conflicts have been added without good reason.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: GCC-3.2.2 bootstrap FAILURE: 1 reduce/reduce conflict in objc-parse.y

[Stan Shebs]

Joseph S. Myers wrote:

>On Tue, 28 Jan 2003, Ziemowit Laski wrote:
>
>
>>I respectfully part company. :-)  The grammar must, first and
>>foremost, be readable and maintainable.  Why else would one use a
>>parser generator in the first place?
>>
>
>Maintainability is the reason to avoid parser conflicts.  Every change to
>a parser that changes the number of conflicts requires all the conflicts
>to be examined carefully to ensure that the parser will parse correctly in
>each case and that no conflicts have been added without good reason.
>
It's been on my wishlist to tweak the grammar to make Bison's complaints go
away, mostly because I don't trust it not to change randomly in some way
that causes s/r and r/r cases to come out differently.  It's just that it's
crushingly dull work, and more fun to think about adding ObjC to the new
recursive descent parser... :-)

Stan

>

Re: GCC-3.2.2 bootstrap FAILURE: 1 reduce/reduce conflict in objc-parse.y

[Joe Buck]

On Tue, Jan 28, 2003 at 04:41:21PM -0800, Stan Shebs wrote:
> It's been on my wishlist to tweak the grammar to make Bison's complaints go
> away, mostly because I don't trust it not to change randomly in some way
> that causes s/r and r/r cases to come out differently.  It's just that it's
> crushingly dull work, and more fun to think about adding ObjC to the new
> recursive descent parser... :-)

Precisely because we will be wanting to implement Objective-C++ on top of
Mark's new parser, I don't see why we should waste resources on the old
parser.

Re: GCC-3.2.2 bootstrap FAILURE: 1 reduce/reduce conflict in objc-parse.y

[Ziemowit Laski]

On Tuesday, Jan 28, 2003, at 15:38 US/Pacific, Joseph S. Myers wrote:

> On Tue, 28 Jan 2003, Ziemowit Laski wrote:
>
>> I respectfully part company. :-)  The grammar must, first and
>> foremost, be readable and maintainable.  Why else would one use a
>> parser generator in the first place?
>
> Maintainability is the reason to avoid parser conflicts.  Every change 
> to
> a parser that changes the number of conflicts requires all the 
> conflicts
> to be examined carefully to ensure that the parser will parse 
> correctly in
> each case and that no conflicts have been added without good reason.

If one's _adding_ a new conflict, then I agree that one must be careful.
Ensuring that the "parser will parse correctly in each case" has a 
slight
"halting problem" flavor to it (esp. since we don't know if it parsed
things correctly to begin with); still, one should at least add a 
comment
in the grammar explaining what the conflict is and how it _should_ be
be resolved (lest the user move around the rules!).

In the case at hand, though, the reduce/reduce conflict has been there
for generations... :-)

--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

Re: GCC-3.2.2 bootstrap FAILURE: 1 reduce/reduce conflict in objc-parse.y

[Joe Buck]

On Tue, 28 Jan 2003, Ziemowit Laski wrote:
> > A reduce/reduce conflict is certainly an annoyance, but it is not a bug 
> > -- bison has a deterministic, POSIX-annointed method for dealing with 
> > it, which the grammar writer knows and expects.
 
On Tue, Jan 28, 2003 at 11:08:03PM +0000, Joseph S. Myers wrote:
> It is, at very least, very bad grammar style, as discussed in the Bison
> manual.  The grammar should be changed (even though this may make it more
> complicated) to avoid the conflict.

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.

My position would be different if we had a large team of active Objective-C
maintainers, but we don't.  Changing a grammar that has worked for years
for the sake of purity isn't a good idea, unless someone can demonstrate
that any proposed "fixed" grammar does not introduce any new breakage. 

Re: GCC-3.2.2 bootstrap FAILURE: 1 reduce/reduce conflict in objc-parse.y

[Joseph S. Myers]

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.

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.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: GCC-3.2.2 bootstrap FAILURE: 1 reduce/reduce conflict in objc-parse.y

[Joe Buck]

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.
 
On Wed, Jan 29, 2003 at 11:17:54PM +0000, Joseph S. Myers wrote:
> 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.

Agreed; if a substantially new parser is made, reduce/reduce conflicts
should be avoided or fixed.  But if we're just maintaining the existing
parser, it's not worth messing with.
 

Re: GCC-3.2.2 bootstrap FAILURE: 1 reduce/reduce conflict in objc-parse.y

[Ziemowit Laski]

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

Re: GCC-3.2.2 bootstrap FAILURE: 1 reduce/reduce conflict in objc-parse.y

[Joseph S. Myers]

On Wed, 29 Jan 2003, Ziemowit Laski wrote:

> What does "Neil's parser" refer to, exactly?  I apologize for being
> out of the loop on this...

The recursive descent C parser Neil Booth is writing.

> 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.

I'll expect such an analysis (with the conflicts being resolved explicitly
where possible) for any merger of the existing parsers into one parser
that decides at runtime.  (I don't care about conflicts only involved in
error recovery.)  C at present has just one conflict not involving error
recovery.

There used to be a comment at the top of c-parse.in listing the conflicts
- which was removed as very out of date and not maintained.  If the
conflicts get genuinely minimised then writing a new such comment would be
worthwhile.

The reduce/reduce conflict meaning being unable to use %expect leads to an
increased risk that it won't be noticed (in the absence of %expect) that
parser changes add conflicts they shouldn't.  This is maintenance risk for
C in the presence of a single parser with such a conflict.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: GCC-3.2.2 bootstrap FAILURE: 1 reduce/reduce conflict in objc-parse.y

[Ziemowit Laski]

On Wednesday, Jan 29, 2003, at 16:54 US/Pacific, Joseph S. Myers wrote:

> On Wed, 29 Jan 2003, Ziemowit Laski wrote:
>
>> What does "Neil's parser" refer to, exactly?  I apologize for being
>> out of the loop on this...
>
> The recursive descent C parser Neil Booth is writing.

Ok, thanks.  So this will be separate from Mark's C++ parser?  I kind of
thought it would be nice if we could eventually teach the 
recursive-descent C++
parser how to handle C and Objective-C (and thereby get Objective-C++ 
for free
-- well, almost).  This way, we could wind up with my beloved Grand 
Unified
Front-End (or GUFE). :-)  Has this been considered/explored?

>
>> 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.
>
> I'll expect such an analysis (with the conflicts being resolved 
> explicitly
> where possible) for any merger of the existing parsers into one parser
> that decides at runtime.  (I don't care about conflicts only involved 
> in
> error recovery.)  C at present has just one conflict not involving 
> error
> recovery.

What do you mean, "decides at runtime"?

>
> There used to be a comment at the top of c-parse.in listing the 
> conflicts
> - which was removed as very out of date and not maintained.  If the
> conflicts get genuinely minimised then writing a new such comment 
> would be
> worthwhile.
>
> The reduce/reduce conflict meaning being unable to use %expect leads 
> to an
> increased risk that it won't be noticed (in the absence of %expect) 
> that
> parser changes add conflicts they shouldn't.  This is maintenance risk 
> for
> C in the presence of a single parser with such a conflict.

Agreed, but this is really a limitation of Yacc/Bison (i.e., not being 
able
to tell it, either via a second argument to %expect or some %prec-like
notation, that the reduce/reduce conflict is "ok").

--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

Re: GCC-3.2.2 bootstrap FAILURE: 1 reduce/reduce conflict in objc-parse.y

[Neil Booth]

Ziemowit Laski wrote:-

> >The recursive descent C parser Neil Booth is writing.
> 
> Ok, thanks.  So this will be separate from Mark's C++ parser?  I kind of
> thought it would be nice if we could eventually teach the 
> recursive-descent C++
> parser how to handle C and Objective-C (and thereby get Objective-C++ 
> for free
> -- well, almost).  This way, we could wind up with my beloved Grand 
> Unified
> Front-End (or GUFE). :-)  Has this been considered/explored?

See subthread starting around 9 Jan 03 in thread ANSIfy cp/parser.c if
you're genuinely curious.  There's no guarantee of delivery, and there's
no consensus whether one or two parsers is a good thing.

Neil.

Re: GCC-3.2.2 bootstrap FAILURE: 1 reduce/reduce conflict in objc-parse.y

[Mark Mitchell]

--On Wednesday, January 29, 2003 05:44:10 PM -0800 Ziemowit Laski 
<zlaski@apple.com> wrote:

> -- well, almost).  This way, we could wind up with my beloved Grand
> Unified Front-End (or GUFE). :-)  Has this been considered/explored?

Yes, and that's what I think we should do.  It's sort of a race between
us and Neil, and Neil's winning. :-)

Seriously, Neil knows that his work might or might not be accepted; it
was decided that we would all decide later.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: GCC-3.2.2 bootstrap FAILURE: 1 reduce/reduce conflict in objc-parse.y

[Neil Booth]

Mark Mitchell wrote:-

> >-- well, almost).  This way, we could wind up with my beloved Grand
> >Unified Front-End (or GUFE). :-)  Has this been considered/explored?
> 
> Yes, and that's what I think we should do.  It's sort of a race between
> us and Neil, and Neil's winning. :-)

I'm not as sure about that as you are 8-)  I estimate as long as 6
months from now before something CVS-able.  At present I don't have
much time outside weekends.  I'm simultaneously doing my best to have
much improved diagnostics, and doing that slows development down.

Neil.

Re: GCC-3.2.2 bootstrap FAILURE: 1 reduce/reduce conflict in objc-parse.y

[Ziemowit Laski]

On Thursday, Jan 30, 2003, at 00:14 US/Pacific, Mark Mitchell wrote:

>
>
> --On Wednesday, January 29, 2003 05:44:10 PM -0800 Ziemowit Laski 
> <zlaski@apple.com> wrote:
>
>> -- well, almost).  This way, we could wind up with my beloved Grand
>> Unified Front-End (or GUFE). :-)  Has this been considered/explored?
>
> Yes, and that's what I think we should do.  It's sort of a race between
> us and Neil, and Neil's winning. :-)

Mark,

I looked back over the thread and I agree with you and with your 
reasoning.
Unfortunately, I don't think I have a leg to stand on in arguing this 
case,
since I don't know if/when my employer would allocate the resources 
needed
for me or others to do this work. :-(

--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

Re: GCC-3.2.2 bootstrap FAILURE: 1 reduce/reduce conflict in objc-parse.y

[Joseph S. Myers]

On Thu, 30 Jan 2003, Ziemowit Laski wrote:

> I looked back over the thread and I agree with you and with your
> reasoning. Unfortunately, I don't think I have a leg to stand on in
> arguing this case, since I don't know if/when my employer would
> allocate the resources needed for me or others to do this work. :-(

You do not need large time allocations to do incremental development as I
proposed.  You can unify one function at a time between front ends with a
fairly small amount of time for each function, and every such merge has an
immediate benefit.

The toplevel autoconfiscation is an excellent example of how large
changes, which overall achieve a substantial reorganisation, can and
should be done incrementally.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: GCC-3.2.2 bootstrap FAILURE: 1 reduce/reduce conflict in objc-parse.y

[Ziemowit Laski]

On Friday, Jan 31, 2003, at 02:44 US/Pacific, Joseph S. Myers wrote:

> On Thu, 30 Jan 2003, Ziemowit Laski wrote:
>
>> I looked back over the thread and I agree with you and with your
>> reasoning. Unfortunately, I don't think I have a leg to stand on in
>> arguing this case, since I don't know if/when my employer would
>> allocate the resources needed for me or others to do this work. :-(
>
> You do not need large time allocations to do incremental development 
> as I
> proposed.  You can unify one function at a time between front ends 
> with a
> fairly small amount of time for each function, and every such merge 
> has an
> immediate benefit.

You are absolutely right in principle; however, even an incremental 
effort
on our (i.e., Apple's) part would require a diversion of resources which
may not be forthcoming.

--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