On Thu, 27 Oct 2016, Trevor Saunders wrote: > On Thu, Oct 27, 2016 at 09:28:31AM +0200, Richard Biener wrote: > > On Thu, 27 Oct 2016, Trevor Saunders wrote: > > > > > On Tue, Oct 25, 2016 at 03:33:36PM +0200, Richard Biener wrote: > > > > > > > > Hi, > > > > > > > > so I did the massaging to split out the GIMPLE parsing routines out > > > > to a separate file (quite tricky to get the gengtype issues correctly > > > > so I thought to help out here and get things started). > > > > > > actually it looks like you didn't get the gengtype issues quiet right :( > > > stage 1 is fine, but when doing a bootstrap stage 2 dies trying to build > > > cc1obj. That's because objc pulls in c-parser.o, but not c-lang.o which > > > means that the gengtype routines for c_parser which are in > > > gt-c-c-parser.h (included by c-parser.c) are included in cc1obj, but the > > > routines for vec<c_token_, va_gc> are not because they get put in > > > gengtype-c.h which is included in c-lang.c. Unfortunately I'm not sure > > > how to fix that off hand. > > > > Hohumm. I've only bootstrapped with --enable-languages=c but indeed > > I can reproduce this... > > > > Indeed this was also the reason I had to add c-parser.h as #include > > to c-lang.c ... > > > > > Killing pch and moving c_parser out of gc memory would of course be one > > > answer, but that's a rather massive hammer to use. > > > > Yeah... > > The more I think about it the more I think gc causes so much trouble pch > has to go and we can try replace it with something better when possible, > but gcc 8 at this point.
Yeah, well ... > > So the only thing I came up with was to privatize c_parser again > > and provide some extra abstraction for accessing ->error and ->tokens_buf. > > yuk, but I don't have anything better still. The other idea was to simply force the equivalent into gtype-objc.h but I failed to do that by simply including c-parser.h from objc. Or hack gengtype (or in the first place try to understand why it does it the way it does...) Richard.
