On Fri, 2013-10-25 at 17:37 -0400, David Malcolm wrote: > This patch addresses various forms of failure described in > http://gcc.gnu.org/ml/gcc-patches/2013-10/msg01974.html > > It adds a "default: gcc_unreachable();" to the autogenerated switch() > statement in the routines for a base class, converting various kinds of > tag errors from leading to silent lack-of-field traversal into giving > run-time assertion failures (addressing (F) and (G)) > > It also issues an error within gengtype itself for a missing "desc" > (failure "B"), turning this into an error message from gengtype. > > I found another potential failure mode: > > (H) If you had: > > class GTY((desc("%0.kind"), tag("0"))) foo > { > public: > int kind; > tree p; > }; > > class GTY((tag("1"))) bar : public foo > { > public: > tree q; > }; > > static GTY(()) foo *dummy_foo; > > and there are no explicit pointers to "bar" in the code, gengtype > treated it as unused, and silently omitted the case for it from > foo's marking routine. > > I've updated set_gc_type_used so that it propagates usage down into > subclasses (which recurses), fixing this issue. > > To do this efficiently we need to track subclasses in within gengtype, > so the patch also adds that, and uses it to eliminate an O(N^2). > > Note that for error (G), if a class within the hierarchy omits a GTY > marker, gengtype doesn't parse it at all, and so doesn't parse the > inheritance information - so we can't issue a warning about this. > However, the lack of a tag will trigger a run-time assertion failure > due to hitting the "default: gcc_unreachable();" in the switch. > The patch also adds a paragraph to the docs, spelling out the need > for evary class in such a hierarchy to have a GTY marker. > > I believe this addresses all of the silent-lack-of-field-traversal > issues, converting them to gengtype errors or runtime assertions. > It also adds a handler for (E), turning this from a failure to > compile bogus C to a specific error in gengtype. > > I'm bootstrapping/regtesting now. > OK for trunk if that passes?
I don't have the power to approve this patch, but I hope it will get accepted. Cheers. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mine, sont seulement les miennes} ***
