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

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


>On 11/4/2011 5:56 PM, George Neuner wrote:
>
>> 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've worked with the SHARC 2106x, but not with g21k ... I used the
newer VisualDSP compiler, which is not based on GCC but is instead an
AKC derivative. VisualDSP is not free, however.




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


Not necessarily. Shift/reduce conflicts happen when there is a
potential for immediate reduction and also the potential to recognize
a longer expression. The classic example is the "dangling ELSE"
construct.


In C: if ( expr )
                      if ( expr )
                      :
                  else
                      :


Should this be parsed as (IF (IF ELSE)) or (IF (IF) ELSE)?


Without scoping braces the parser can't tell. Indentation may make it
clear to the programmer, but the C language doesn't recognize
indentation as being significant. And what if the code were all on
one line?


You get a different answer depending on whether the parser reduces the
inner IF immediately - attaching the ELSE to the outer IF, or shifts
the ELSE, attaching it to the inner IF.


In such cases - and unless told otherwise - Bison defaults to shifting
to try to match the longest sequence and issues a warning about the
ambiguity.


So a shift/reduce conflict is not necessarily an error. But, at the
same time, it is something more than a warning because it identifies
ambiguous syntax that potentially may be confusing for the *user* of
the language.




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


The parsers created by Bison actually have well developed theory
behind them. But that doesn't mean that the grammar correctly
reflects the semantics of the language as intended by the developer.
In other words, grammars can have bugs. Developer tools also can have
bugs and Bison is no exception. At this point, Bison is pretty well
shaken out and what bugs it has tend to be esoteric ... but they still
can bite the unwary developer who attempts something clever.




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


George

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