Re: [PATCH] Add save_expr langhook (PR c/68513)

[Marek Polacek <polacek@redhat.com>]

On Fri, Nov 27, 2015 at 10:43:42PM +0000, Joseph Myers wrote:
> On Fri, 27 Nov 2015, Marek Polacek wrote:
> 
> > I didn't know where to put setting of in_late_processing.  With the current
> > placement, we won't (for valid programs) call c_save_expr from c_genericize
> > or c_gimplify_expr.
> 
> Well, the placement in this patch (in c_parser_compound_statement) is 
> certainly wrong.  It doesn't even save and restore, so after one compound 
> statement inside another, parsing would continue with in_late_processing 
> wrongly set.  And c_save_expr is logically right for any parsing outside 
> compound statements as well (arbitrary expressions can occur in sizeof 
> outside functions and in VLA parameter sizes and should follow the normal 
> rules for what's a constant expression - there's a known bug that 
> statement expressions are wrongly rejected in such contexts).
 
Indeed.  I don't know what I was thinking. :/

> Starting from first principles: parsing takes place from within 
> c_parse_file as the sole external entry point to the parser.  So you could 
> have a parsing_input variable that starts off as false, and where 
> c_parse_file saves it, sets to true, and restores the saved value at the 
> end.  Then you'd use c_save_expr if parsing_input && !in_late_binary_op.
> 
> If that doesn't work, it means there are cases where the hook gets called 
> from folding that takes place during parsing, on expressions that will not 
> subsequently go through c_fully_fold, but without in_late_binary_op set.  
> Knowing what those cases are might help work out any fix for them that is 
> needed.

I'm not sanguine about doing this reliably in stage3.  I think I'll try the
other approach mentioned later in this thread.
 
> > I suppose I should also modify save_expr in fold-const.c to call it via the
> > langhook, if this approach is sane.  Dunno.
> 
> That's a complication.  When the folding is taking place from within 
> c_fully_fold (and so the sub-expressions have already been folded, and had 
> their C_MAYBE_CONST_EXPRs removed, and the result of folding will not be 
> re-folded), it should be using save_expr not c_save_expr.  So maybe the 
> hook needs to say: use c_save_expr, if parsing, not in_late_binary_op and 
> not folding from within c_fully_fold.
 
Oh, I see :(.

> Again long term we should aim for the representation during parsing not to 
> need SAVE_EXPRs and for the folding that creates them (and the other 
> folding for optimization in general) to happen only after parsing....

Yeah, let's strike that for gcc7.

Thanks,

	Marek