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
