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

[Joseph Myers <joseph@codesourcery.com>]

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).

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 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.

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....

-- 
Joseph S. Myers
joseph@codesourcery.com