https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71104
--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
C11 6.5.16/3 suggests that the LHS "operand" is evaluated in unspecified order.
6.5.2.2/10 says function argument "operands" are evaluated before the actual
call (which denotes a sequence point) and the rest are "indeterminately
sequenced"
with respect to the call.
This means that the following patch should be valid (not requiring to spill
the load of the pointer would improve code-gen as well). Let's see if it
passes testing.
Index: gcc/gimplify.c
===================================================================
--- gcc/gimplify.c (revision 236309)
+++ gcc/gimplify.c (working copy)
@@ -4708,10 +4708,6 @@ gimplify_modify_expr (tree *expr_p, gimp
that is what we must do here. */
maybe_with_size_expr (from_p);
- ret = gimplify_expr (to_p, pre_p, post_p, is_gimple_lvalue, fb_lvalue);
- if (ret == GS_ERROR)
- return ret;
-
/* As a special case, we have to temporarily allow for assignments
with a CALL_EXPR on the RHS. Since in GIMPLE a function call is
a toplevel statement, when gimplifying the GENERIC expression
@@ -4729,6 +4725,10 @@ gimplify_modify_expr (tree *expr_p, gimp
if (ret == GS_ERROR)
return ret;
+ ret = gimplify_expr (to_p, pre_p, post_p, is_gimple_lvalue, fb_lvalue);
+ if (ret == GS_ERROR)
+ return ret;
+
/* In case of va_arg internal fn wrappped in a WITH_SIZE_EXPR, add the type
size as argument to the call. */
if (TREE_CODE (*from_p) == WITH_SIZE_EXPR)
