Re: [gimplefe] Construction of individual gimple statements for gimple_cond and gimple_label
On Tue, Jul 10, 2012 at 10:21 PM, Sandeep Soni wrote:
> -static void
> +static tree
> gp_parse_expect_false_label (gimple_parser *parser)
> {
>gl_consume_expected_token (parser->lexer, CPP_LESS);
>gl_consume_expected_token (parser->lexer, CPP_NAME);
>gl_consume_expected_token (parser->lexer, CPP_GREATER);
>gl_consume_expected_token (parser->lexer, CPP_GREATER);
> + return create_artificial_label (UNKNOWN_LOCATION);
You don't need to use UNKNOWN_LOCATION here. You can use the location
from gl_peek_token(parser->lexer)->location.
OK with that change.
Diego.
Re: [gimplefe] Construction of individual gimple statements for gimple_cond and gimple_label
On Tue, Jul 17, 2012 at 6:16 PM, Diego Novillo wrote: > > Not so much, anymore > (http://gcc.gnu.org/codingconventions.html#Variable). When gimplefe > is merged into trunk, we will be using the C++ conventions which now > allow this. > > No need to change anything, Sandy. Ah..Saved by the skin of my teeth. Thanks! -- Cheers Sandy
Re: [gimplefe] Construction of individual gimple statements for gimple_cond and gimple_label
On Tue, Jul 17, 2012 at 11:01 AM, Sandeep Soni wrote: > On Tue, Jul 17, 2012 at 1:22 PM, Bernhard Reutner-Fischer > wrote: >> >> I'm curious if the coding conventions were relaxed to allow for variable >> declarations that are not at the beginning of a function or scope? >> >> You seem to do this pretty often in the gimplefe.. >> >> cheers, > > Not really. I guess, I am the one at fault for this. I will ensure the > existing code is fixed so that the conventions are followed. Thanks > for pointing it out. Not so much, anymore (http://gcc.gnu.org/codingconventions.html#Variable). When gimplefe is merged into trunk, we will be using the C++ conventions which now allow this. No need to change anything, Sandy. Diego.
Re: [gimplefe] Construction of individual gimple statements for gimple_cond and gimple_label
On Tue, Jul 17, 2012 at 1:22 PM, Bernhard Reutner-Fischer wrote: > > I'm curious if the coding conventions were relaxed to allow for variable > declarations that are not at the beginning of a function or scope? > > You seem to do this pretty often in the gimplefe.. > > cheers, Not really. I guess, I am the one at fault for this. I will ensure the existing code is fixed so that the conventions are followed. Thanks for pointing it out. -- Cheers Sandy
Re: [gimplefe] Construction of individual gimple statements for gimple_cond and gimple_label
On Wed, Jul 11, 2012 at 10:51:02AM +0530, Sandeep Soni wrote:
>The patch adds support for creating individual gimple statements for
>the gimple_cond and gimple_label statements.
>
>Diego, I need your help in generalizing to include all possible cases
>of these statements.
>
>Here is the ChangeLog
>
>2012-07-10 Sandeep Soni
>
> * parser.c (gp_parse_expect_op1): Tidy. Returns tree operand.
> Update all callers.
> (gp_parse_expect_op2): Likewise.
> (gp_parse_expect_true_label): Tidy. Returns a label.
> Update all callers.
> (gp_parse_expect_false_label): Likewise.
> (gp_parse_cond_stmt): Tidy. Creates and returns a gimple cond
> statement.
> (gp_parse_label_stmt): Creates and returns the gimple label statement.
>
>
>And the patch
>Index: gcc/gimple/parser.c
>===
>--- gcc/gimple/parser.c(revision 188546)
>+++ gcc/gimple/parser.c(working copy)
>
>-static void
>+static tree
> gp_parse_expect_op1 (gimple_parser *parser)
> {
> const gimple_token *next_token;
> next_token = gl_consume_token (parser->lexer);
>+ tree op1 = NULL_TREE;
I'm curious if the coding conventions were relaxed to allow for variable
declarations that are not at the beginning of a function or scope?
You seem to do this pretty often in the gimplefe..
cheers,
