On Thu, 26 Nov 2015, Marek Polacek wrote: > My worry was of course C_MAYBE_CONST_EXPR_PRE. But it seems we'll never have > any at that point, since it's already been processed and transformed to a > COMPOUND_EXPR. But do I like this patch? No.
It's not obvious to me that it will always have been transformed - if a C_MAYBE_CONST_EXPR has escaped to gimplification, why shouldn't it be one with C_MAYBE_CONST_EXPR_PRE? Also, on further consideration: the folding via c_fully_fold is relied upon to get information about whether an expression contains anything that cannot occur in an evaluated part of a constant expression / outside sizeof in a constant expression in C90 mode. So if a SAVE_EXPR is created by language-independent code, c_fully_fold doesn't see inside it and you lose that information. What that says to me is that maybe a better interim solution would be a lang hook for the folders to use to call c_save_expr instead of save_expr. And then longer term: (a) maybe any folding that involves duplicating expressions and so needs to create SAVE_EXPRs would better be done only at the GIMPLE level, and (b) folding for conversions should be delayed as much as possible like other folding (and optimizations of conversions should move from convert.c to match.pd). -- Joseph S. Myers jos...@codesourcery.com
