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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91987

            Bug ID: 91987
           Summary: -fstrict-eval-order issues
           Product: gcc
           Version: 10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jakub at gcc dot gnu.org
                CC: barry.revzin at gmail dot com, jakub at gcc dot gnu.org,
                    webrown.cpp at gmail dot com
        Depends on: 91974
  Target Milestone: ---

+++ This bug was initially created as a clone of Bug #91974 +++

I wonder if we don't need to double check all the C++17 evaluation rules for
similar problems as the above bug for call expressions.

At least:
int
foo (void)
{
  int x = 5;
  return x << (x = 3, 2);
}

int
main ()
{
  if (foo () != (5 << 2))
    __builtin_abort ();
}

fails when compiled with g++ trunk and icpc 19, but succeeds with clang++.
The problem is similar, we gimplify_expr the left operand before right operand
in this case and think it is enough, but because it is gimplified to a VAR_DECL
which satisfies the predicate, yet is a user variable that can be overwritten
in the expression that needs to be sequenced after it, we don't actually
enforce the language rules.
Not sure what is the right way to deal with this.
Depend on flag_strong_eval_order (which is in c-family/c.opt!) in the
gimplifier and use different predicates in that case that will enforce it (how
to distinguish between fresh gimplifier temporaries that aren't problematic vs.
variables that can be overwritten?  Is DECL_ARTIFICIAL usable for this, or can
we have DECL_ARTIFICAL vars that can be overwritten?  Or wrap the operands in
NON_LVALUE_EXPR or similar?


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91974
[Bug 91974] function not sequenced before function argument