[Bug c++/91987] -fstrict-eval-order issues

[jakub at gcc dot gnu.org]

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?