https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91987
--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> --- So for the shifts we'd need additionally: --- gcc/fold-const.c.jj 2019-09-02 15:29:34.548515139 +0200 +++ gcc/fold-const.c 2019-10-04 10:44:23.319883187 +0200 @@ -9447,16 +9447,23 @@ fold_binary_loc (location_t loc, enum tr if (TREE_CODE (arg0) == COMPOUND_EXPR) { tem = fold_build2_loc (loc, code, type, - fold_convert_loc (loc, TREE_TYPE (op0), - TREE_OPERAND (arg0, 1)), op1); + fold_convert_loc (loc, TREE_TYPE (op0), + TREE_OPERAND (arg0, 1)), + op1); return build2_loc (loc, COMPOUND_EXPR, type, TREE_OPERAND (arg0, 0), tem); } - if (TREE_CODE (arg1) == COMPOUND_EXPR) + if (TREE_CODE (arg1) == COMPOUND_EXPR + && (flag_strong_eval_order != 2 + /* C++17 disallows this canonicalization for shifts. */ + || (code != LSHIFT_EXPR + && code != RSHIFT_EXPR + && code != LROTATE_EXPR + && code != RROTATE_EXPR))) { tem = fold_build2_loc (loc, code, type, op0, - fold_convert_loc (loc, TREE_TYPE (op1), - TREE_OPERAND (arg1, 1))); + fold_convert_loc (loc, TREE_TYPE (op1), + TREE_OPERAND (arg1, 1))); return build2_loc (loc, COMPOUND_EXPR, type, TREE_OPERAND (arg1, 0), tem); } One thing I'm worried about are the special cases where we enforce some argument order, evaluate one argument before the other or vice versa. For is_gimple_reg_type args it can be just a matter of forcing it into an SSA_NAME or a new VAR_DECL, but if a function argument is a structure, struct S { int a, b; } c = { 1, 2 }; fun (c, (c.b = 3, 5); and fun is one of the magic one that enforce operand ordering and the first argument needs to be sequenced before the second, what can we do?