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

[Alexandre Oliva]

On Mar  4, 2005, Mark Mitchell <mark@codesourcery.com> wrote:

> Actually, looking at this more closely, I think that something is
> forgetting to call rationalize_conditional_expr, which is normally
> called from unary_complex_lvalue.  When the conditional expression is
> used in the lvalue context, something should be calling that.
> Normally, that happens because something calls build_unary_op
> (ADDR_EXPR, ...) on the COND_EXPR.

> It may be that I changed something to call build_addr (instead of
> build_unary_op) in a case where that's not safe.  Can you confirm or
> deny that hypothesis?

I'm not sure you're still talking about PR 20280, or about PR 19199,
that is marked as a blocker because it appears to be the same problem,
but AFAICT really isn't.

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.

Still testing on x86_64-linux-gnu.  Ok to install if it passes?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: fold-cond-expr-lvalue-to-min-expr-lvalue.patch
Type: text/x-patch
Size: 4069 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20050304/23de043f/attachment.bin>
-------------- next part --------------

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}