[PR c++/19199] don't turn cond_expr lvalue into min_expr rvalue (continued from PR c++/20280)

[Mark Mitchell]

Alexandre Oliva wrote:

> Here's a patch that fixes PR c++/19199, by avoiding the transformation
> from:
> 
> <cond <lt <nop(int) <parm a> > <nop(int) <parm b> > >
>       <parm a> <parm b> >
> 
> into:
> 
> <nop(enum) <min <nop(int) <parm a> > <nop(int) <parm b> > >
> 
> since the latter is clearly not an lvalue, and
> rationalize_conditional_expr doesn't manage to turn it back into one
> (I don't think it should).  I realize we might miss some optimization
> opportunities because of this change in C, because the optimization
> would be valid there, but I suppose we could arrange for cond_expr
> operands in C to be forced into rvalues.

Roger has objected to this change in the past.  As I noted in the audit 
trail for 19199, there's stuff in build_modify_expr to handle 
MIN_EXPR/MAX_EXPR as lvalues -- but, if Roger wants to stick with that 
approach, it needs to be spread throughout the C++ front end.  I'd be 
happier with your approach overall, in part because I think fold is 
doing too much, too early, in general, but I don't feel comfortable 
approving the patch.

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