On Wed, 10 Aug 2005, Joel E. Denny wrote:
> On Fri, 29 Jul 2005, Joel E. Denny wrote:
>
> > On Tue, 19 Jul 2005, Joel E. Denny wrote:
> >
> > > I am attempting to use bison's %glr-parser and %merge to construct parse
> > > forests. I'm getting duplicate representations of some trees within the
> > > forest. Both bison 1.875 and 2.0 give the same results.
>
> I haven't seen any response to my posts last month on problems I'm having
> with bison GLR:
>
> http://lists.gnu.org/archive/html/help-bison/2005-07/msg00013.html
> http://lists.gnu.org/archive/html/help-bison/2005-07/msg00040.html
> http://lists.gnu.org/archive/html/help-bison/2005-07/msg00017.html
>
> Were my explanations unclear? Am I correct that this is unintended
> behavior? Should I post these to bug-bison instead?
>
> I need these problems resolved for my work, so I may start exploring
> bison's source myself. However, I don't want to waste my time moving in
I finally got around to this yesterday. I spent some time exploring
"data/glr.c" from bison-2.0b, and I'm now fairly certain the redundant
parse tree problem is due to a bug in bison. I haven't explored the other
issues yet.
resolveValue() invokes mergeOptionSets() but doesn't remove the merged
SemanticOption's. Thus, within `if (yymerge)', resolveAction() and
userMerge() are invoked for each of several identical SemanticOption's.
This produces the redundant trees.
Attached is a patch to "data/glr.c" from bison-2.0b. It seems to solve
the problem for my test cases. I have not wrapped my head around your
code completely, so I'm not fully confident that there are no adverse
side-effects. However, after applying this patch, I found that make check
produced no test failures. I plan to test much more extensively and will
follow up if I discover problems.
If you would like to add a new test case to ensure this bug does not crop
up again, I posted one earlier on this thread at help-bison.
Joel Denny
1609a1610
> yySemanticOption** yypp;
1614c1615
< for (yyp = yyoptionList->yynext; yyp != NULL; yyp = yyp->yynext)
---
> for (yypp = &yyoptionList->yynext; *yypp != NULL;)
1616,1617c1617,1621
< if (yyidenticalOptions (yybest, yyp))
< yymergeOptionSets (yybest, yyp);
---
> if (yyidenticalOptions (yybest, *yypp))
> {
> yymergeOptionSets (yybest, *yypp);
> *yypp = (*yypp)->yynext;
> }
1619,1633c1623,1640
< switch (yypreference (yybest, yyp))
< {
< case 0:
< yyreportAmbiguity (yybest, yyp, yystack]b4_pure_args[);
< break;
< case 1:
< yymerge = yytrue;
< break;
< case 2:
< break;
< case 3:
< yybest = yyp;
< yymerge = yyfalse;
< break;
< }
---
> {
> switch (yypreference (yybest, *yypp))
> {
> case 0:
> yyreportAmbiguity (yybest, *yypp, yystack]b4_pure_args[);
> break;
> case 1:
> yymerge = yytrue;
> break;
> case 2:
> break;
> case 3:
> yybest = *yypp;
> yymerge = yyfalse;
> break;
> }
> yypp = &(*yypp)->yynext;
> }
_______________________________________________
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
