Re: [PATCH] PR c++/7503: Handle MAX_EXPR as target of MODIFY_EXPR

[Roger Sayle <roger at eyesopen dot com>]

On Mon, 13 Sep 2004, Mark Mitchell wrote:
> My objection was not to handling MIN_EXPR/MAX_EXPR in build_modify_expr
> so much as to the comment that said (paraphrasing) "we know these nodes
> are side-effect free".  I'd feel better if we did the stabilize_expr dan
> there, maybe...


Ah!  I appreciate this aspect of my solution requires an "a priori"
understanding of the problematic transformation in fold-const.c and
its dependence upon operand_equal_p's side-effect freeness.

My counter concern is that it may not be "safe" to stabilize these
operands via the usual mechanisms.  It isn't clear whether cp/tree.c's
stabilize_expr preserves the "lvalue" nature of an expression.  Consider
a tree such as "MAX_EXPR (a[i], a[j])", normally its the values in the
array that you care about and stabilize, for example, copying them to
temporaries is reasonable.  As an lvalue however, we compare the contents
of  the array, but are really interested in their lvalue addresses for
the assignment.  In this case, using the stabilized temporary as an
lvalue would be inappropriate.

Stabilization of their ADDR_EXPRs (REFERENCE_EXPRs?) might be possible...

So we'd transform

	max(a,b) = c;

into

	T *t1 = &a;
	T *t2 = &b;
	(*t1 >= *t2 ? *t1 : *t2) = c;

But given the choice between meddling with the subtleties of ADDR_EXPRs
and INDIRECT_REFs in the C++ front-end, vs. my "insider" knowledge that
a and b are always safe for re-evaluation, you can see why I took the
coward's (safe) way out.


Unless some kind soul could volunteer to help me with the stabilization
approach, the best that I think I could offer is to add a gcc_assert to
the relevant code that checked TREE_SIDE_EFFECTS of each operand.  This
would at least cause an ICE instead of "wrong-code", if ever a MIN_EXPR
or MAX_EXPR reached here via an unanticipated route.

Roger
--