On Sat, 2013-08-31 at 11:57 +0200, Richard Biener wrote: > Diego Novillo <dnovi...@google.com> wrote: > > > >Yes. Lawrence and I thought about moving gengtype inside g++. That > >seemed like a promising approach. > > > What do you do during stage1? Have a collector that never collects?
We could imagine that the successor of gengtype would be some GCC plugin (which would generate C++ code for marking and GC and PCH purposes, perhaps using ad-hoc attributes and pragmas) Then for bootstrapping purposes, we could put the generated C++ code in the source repository (like we already do for configure, or fixincludes/fixincl.x etc...). Hence stage1 would be buildable with the generated C++ code in the repository. A more difficult issue is that the set of GTY-ed types is target specific and depends upon the .../configure argument at build time. Perhaps we could consider processing all of it (i.e. every GTY-ed class declaration), and have our gengtype successor plugin emit appropriate #if in the generated C++ code. Of course having gengtype replaced by a plugin requires such a plugin to be developed and GCC maintainers to have access to some gcc... 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} ***