> Le 11 nov. 2020 à 19:03, Valentin Tolmer <[email protected]> a écrit : > > Hi Akim,
Hi Valentin! > Thanks for the example, and sorry for the late reply, got swamped with work > and the bug was less than easy to track... I had the pleasure of discovering > the joys of `rr` for a time-traveling GDB, but I would have hoped it wouldn't > come to that. Never had to use it so far... > Anyway, I pushed a patch to the glr2_cc branch on my github if you want to > have a look (https://github.com/nitnelave/bison/tree/glr2_cc). It was a > combination of a memory corruption when accessing the wrong field of an > union, and a badly translated loop from glr.c. I'm afraid there is probably more. I removed the exit 77 from the test itself, and the test suite still fails. On "T (x) + y;" it aborts in getState : frame #3: 0x0000000100001f6d c++-types`glr_stack_item::getState(this=0x0000000101000190) at c++-types.cc:1099:5 1096 1097 glr_state& getState () 1098 { -> 1099 YYDASSERT (is_state ()); 1100 void *yyp = raw_; 1101 return *static_cast<glr_state*> (yyp); 1102 } And on "T (x);", it does not terminate. I have installed none of your other commits, to make sure we don't add more problems on top of this one. But I read them, and LGTM, so I doubt they actually make things worse. Besides, we have the very same failures without these commits. I'm not fond of the "glr2.cc: remove goto from yytnamerr_" commit (https://github.com/nitnelave/bison/commit/a65094511f8e2a6b51493b64fbb93db3220a47d9): I think it is much more complex than the original approach, and now too different from the approach taken in the other skeletons. I agree gotos should be avoided, but they are valid in the implementation of state machine, which is what this function is about. Cheers!
