This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Roger Sayle wrote:

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.


Yes, I considered this approach, and it's certainly better than nothing, especially if there's a nice detailed comment about what's going on. But, what's to keep us from getting a straight-up MIN_EXPR from the usual GNU minimum oeprator? I see that the versions of G++ I have already accept:

int a, b;

void f() {
 (a <? b) = 3;
}

so, can we get in trouble in that way?

Perhaps we should just not fold to {MIN,MAX}_EXPR in C++?

--
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]