[PATCH][1/2] GIMPLE Frontend, C FE parts (and GIMPLE parser)

Richard Biener rguenther@suse.de
Mon Nov 7 10:24:00 GMT 2016


On Fri, 4 Nov 2016, Jakub Jelinek wrote:

> Hi!
> 
> Just 2 nits:
> 
> On Fri, Oct 28, 2016 at 01:46:57PM +0200, Richard Biener wrote:
> > +/* Return a pointer to the Nth token in PARERs tokens_buf.  */
> 
> PARSERs ?

Fixed.

> > @@ -454,7 +423,7 @@ c_lex_one_token (c_parser *parser, c_token *token)
> >  /* Return a pointer to the next token from PARSER, reading it in if
> >     necessary.  */
> >  
> > -static inline c_token *
> > +c_token *
> >  c_parser_peek_token (c_parser *parser)
> >  {
> >    if (parser->tokens_avail == 0)
> 
> I wonder if turning all of these into non-inlines is a good idea.
> Can't you move them to the common header instead?

The issue with moving is that I failed to export the definition of
c_parser in c-parser.h due to gengtype putting vec <c_token, va_gc>
handlers into gtype-c.h but not gtype-objc.h and thus objc bootstrap
fails :/

I believe (well, I hope) that code generation for the C parser
should be mostly unaffected (inlining is still done as determined
useful) and the performance of the GIMPLE parser shouldn't be
too important.

If anybody feels like digging into the gengtype issue, I gave up
after trying for half a day to trick it to do what I want
(like for example also putting it in gtype-objc.h).

> The rest I defer to Joseph or Marek.

Thanks,
Richard.



More information about the Gcc-patches mailing list