------- Additional Comments From mark at codesourcery dot com 2005-03-06 00:14
-------
Subject: Re: [PR c++/19199] don't turn cond_expr lvalue into min_expr rvalue
(continued from PR c++/20280)
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.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19199
