Re: bison c-parse.y:1115.19-20: $$ for the midrule at $4 of `structsp' has no declared type

Alessandro Basili <alessandro.basili@cern.ch>
Sun, 06 Nov 2011 19:24:32 +0100

          From comp.compilers

Related articles
bison c-parse.y:1115.19-20: $$ for the midrule at $4 of `structsp' has alessandro.basili@cern.ch (Alessandro Basili) (2011-10-31)
Re: bison c-parse.y:1115.19-20: $$ for the midrule at $4 of `structsp' haberg-news@telia.com (Hans Aberg) (2011-10-31)
Re: bison c-parse.y:1115.19-20: $$ for the midrule at $4 of `structsp' alessandro.basili@cern.ch (Alessandro Basili) (2011-11-02)
Re: bison c-parse.y:1115.19-20: $$ for the midrule at $4 of `structsp' gneuner2@comcast.net (George Neuner) (2011-11-02)
Re: bison c-parse.y:1115.19-20: $$ for the midrule at $4 of `structsp' gneuner2@comcast.net (George Neuner) (2011-11-04)
Re: bison c-parse.y:1115.19-20: $$ for the midrule at $4 of `structsp' alessandro.basili@cern.ch (Alessandro Basili) (2011-11-06)
Re: bison c-parse.y:1115.19-20: $$ for the midrule at $4 of `structsp' gah@ugcs.caltech.edu (glen herrmannsfeldt) (2011-11-07)
Re: bison c-parse.y:1115.19-20: $$ for the midrule at $4 of `structsp' gneuner2@comcast.net (George Neuner) (2011-11-07)
| List of all articles for this month |
From: Alessandro Basili <alessandro.basili@cern.ch>
Newsgroups: comp.compilers
Date: Sun, 06 Nov 2011 19:24:32 +0100
Organization: Compilers Central
References: 11-10-020 11-11-013 11-11-022
Keywords: bison, parse
Posted-Date: 06 Nov 2011 23:50:59 EST

On 11/4/2011 5:56 PM, George Neuner wrote:
> On Wed, 02 Nov 2011 12:33:46 -0400, George Neuner
> <gneuner2@comcast.net> wrote:
>
> Someone commented offline that my rewrite might not work *if* the
> mid-rule start_struct call was needed for recursive structure
> definitions. I had looked at the code for start_struct before posting
> and it looks like it should handle that situation, but it's difficult
> to be sure without building the whole compiler.


I'm trying to get the fixes done in order to build the compiler under
gcc-4.4.1. And indeed I got rid of all the errors and warnings except
for two types:


warning: left shift count >= width of type
warning: assignment from incompatible pointer type


and should get rid of those very soon.


>
[...]
>
> The second version passes the state through the token for the opening
> brace in case mid-rule results are somehow broken.


I realize I'm not able to follow, maybe I need to study some
fundamentals before go ahead and make changes to something I have no
idea what it is about.


>
> Remember, though, that just because bison is happy does not mean the
> generated C code will work.


That's another key point it worries me a lot. My goal is not to fix the
compiler, but start using it to build my program for the aforementioned
architecture. I would assume the shift/reduce conflicts is resulting
from an incorrect description of the language, but if I can be able to
understand what kind of construct of the language will trigger the
conflict I can probably avoid to use it in my program.


To be honest I never doubted the correctness of the compiler I was using
(how naive??) and now that I'm trying to build one I realize the
complexity behind and how shaky are the pillars on which my applications
are built upon.


>
> Hope this ... doesn't confuse the issue more.


I will give it a try, restoring the %expected to 8, but even if that
works I'm not sure I should stop understanding what are the shift/reduce
conflicts and how should I avoid those conflicts when I program.


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.