https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79232
--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Though the #c1 testcase actually tests something even different (the #c5
questions apply otherwise), because there is the [d], therefore it really
should be evaluated in the order: side-effects in e, side-effects in 0,
side-effects in b, side-effects in &c or in a, then side-effects in d and then
actually the value storing.
Looking at
char fn1 ();
int fn2 ();
int fn3 ();
char &fn4 ();
char &fn5 ();
int fn6 ();
void fna() { (fn3 () ? fn4 () : fn5 ()) = fn1 (); }
void fnb() { (fn2 (), fn3 () ? fn4 () : fn5 ()) = fn1 (); }
where the side-effects are more observable (and it still ICEs on fnb), it seems
COND_EXPR is actually handled properly:
TARGET_EXPR <D.2051, fn1 ()>;, if (fn3 () != 0)
{
(void) (*fn4 () = D.2051);
}
else
{
(void) (*fn5 () = D.2051);
}
So, perhaps at least for the case where after
tree lhs1 = lhs;
while (TREE_CODE (lhs1) == COMPOUND_EXPR)
lhs1 = TREE_OPERAND (lhs1, 1);
if (TREE_CODE (lhs1) == COND_EXPR)
we need to handle it like the normal COND_EXPR in there, except that instead of
lhs it would use this lhs1, and instead of TREE_OPERAND (lhs1, 0) it would
replace the COND_EXPR at the end of the COMPOUND_EXPR with just its condition
(likely would have to unshare the COMPOUND_EXPRs or recreate them).
Now the question is if COMPOUND_EXPR(s) with PRE{DEC,INC}REMENT_EXPR,
MODIFY_EXPR, {MIN,MAX}_EXPR shouldn't be treated similarly.
