This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][GIMPLE FE] Split out parser into separate file
- From: Trevor Saunders <tbsaunde at tbsaunde dot org>
- To: Richard Biener <rguenther at suse dot de>
- Cc: gcc-patches at gcc dot gnu dot org, prasad dot ghangal at gmail dot com, "Joseph S. Myers" <joseph at codesourcery dot com>
- Date: Thu, 27 Oct 2016 06:27:55 -0400
- Subject: Re: [PATCH][GIMPLE FE] Split out parser into separate file
- Authentication-results: sourceware.org; auth=none
- References: <alpine.LSU.2.11.1610251529280.5294@t29.fhfr.qr> <20161027041332.dfw6dsaoaroxccwo@ball> <alpine.LSU.2.11.1610270847260.5294@t29.fhfr.qr>
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.
> 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.
Trev