[Bug sanitizer/80536] [6/7/8 Regression] UBSAN: compile time segfault

[jakub at gcc dot gnu.org]

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.