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