Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!news.linkpendium.com!news.linkpendium.com!news.iecc.com!nerds-end From: George Neuner Newsgroups: comp.compilers Subject: Re: bison c-parse.y:1115.19-20: $$ for the midrule at $4 of `structsp' has no declared type Date: Mon, 07 Nov 2011 03:18:16 -0500 Organization: A noiseless patient Spider Lines: 75 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <11-11-029@comp.compilers> References: <11-10-020@comp.compilers> <11-11-013@comp.compilers> <11-11-022@comp.compilers> <11-11-026@comp.compilers> NNTP-Posting-Host: news.iecc.com X-Trace: leila.iecc.com 1320687157 89616 64.57.183.58 (7 Nov 2011 17:32:37 GMT) X-Complaints-To: abuse@iecc.com NNTP-Posting-Date: Mon, 7 Nov 2011 17:32:37 +0000 (UTC) Keywords: bison, parse, debug Posted-Date: 07 Nov 2011 12:32:37 EST X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: x330-a1.tempe.blueboxinc.net comp.compilers:331 On Sun, 06 Nov 2011 19:24:32 +0100, Alessandro Basili 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