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

[Mark Mitchell <mark at codesourcery dot com>]

Roger Sayle wrote:

> On Mon, 13 Sep 2004, Mark Mitchell wrote:
>  
>
> > Hmm.  I like that this bug is being fixed, of course, but I'm not happy
> > about the fact that build_modify_expr would now be relying on the highly
> > non-local property that the only way it can see a MIN_EXPR is from a
> > COND_EXPR passing through fold.  Perhaps we should just not call fold in
> > the case that is_lvalue holds for the COND_EXPR.  This is not a common
> > idiom, so I'm not very worried about pessimizing slightly in this case...
> >    
>
> Hence the question about how much the c++ parser knows about where it
> is in an expression.
>
>  int a, b, c;
>
>  (a < b? a : b) = c;
>
> vs.
>
>  c = (a < b? a : b);
>
> in both cases all of the operands of the COND_EXPR are potentially
> lvalues, so locally from the tree expression these two cases appear
> indistinguishable
True.  We really want to have additional structure (as Joseph has 
independently discovered for the C front end) that we maintain only 
while parsing a single expression, so that we can know about these kinds 
of things.  We also really want to delay calling fold at all, as Nathan 
has been advocating.  But, here it is Stage 3, so I'll get real. :-)

> I agree it's awkward either way.  The proposed approach of just
> considering MIN_EXPR and MAX_EXPR as canonical forms of COND_EXPRs,
> matches similar representation normalization issues like "X - -1"
> being represented as "X + 1", or "if (var)" becoming "if (var != 0)".
> Its really no different to gimplification where equivalent expressions
> are lowered to the same "simple" form.
>  
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...

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