On Thu, 26 Nov 2015, Marek Polacek wrote: > I had a go at this, but I'm now skeptical about removing c_save_expr. > save_expr calls fold (), so we need to ensure that we don't pass any > C_MAYBE_CONST_EXPRs into it, meaning that we'd need to call c_fully_fold > before > save_expr anyway... > > So maybe go the "remove C_MAYBE_CONST_EXPRs in SAVE_EXPRs in c_gimplify_expr" > way?
I believe it should be safe for gimplification to process C_MAYBE_CONST_EXPR in the same way c_fully_fold_internal does. That is, this should not affect correctness. If a C_MAYBE_CONST_EXPR got through to gimplification, in some cases it may mean that something did not get properly folded with c_fully_fold as it should have done - but if the move to match.pd means all optimizations currently done with fold end up working on GIMPLE as well, any missed optimizations from this should disappear (and if we can solve the diagnostics issues, eventually fewer calls to c_fully_fold should be needed and they should be more about checking what can occur in constant expressions and less about folding for optimization). The general principle of delaying folding also means that we should move away from convert_* folding things. -- Joseph S. Myers jos...@codesourcery.com