https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80536
--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to Marek Polacek from comment #13) > This is true, but it happens very rarely. It can happen e.g. when the > fold() call in save_expr() folds away the first operand of a COMPOUND_EXPR, > and the second operand is e.g. Can't it happen say if you have save_expr called with (0 * i) + (0 * j) + (0 * k) or whatever similar initially complex, but after folding very simple and obviously invariant? > But even if I add this to fold or c_fully_fold, we don't have any guarantees > that any of these will be called before gimplification, right? So most > likely we'd end up with the new SAVE_EXPR in the gimplifier, which, as you > point out, is not that bad. I think cp_fold should handle SAVE_EXPR (by cp_folding the operand, and if it is invariant or invariant after skipping simple arith, returning that folded operand, otherwise making sure to add the SAVE_EXPR into the fold_cache giving the SAVE_EXPR itself. Right now cp_fold ignores SAVE_EXPR, but cp_fold_r handles it, but that one doesn't do much good, because it cp_folds the operands only after folding the containing trees.