Re: [Bug c++/19199] [3.3/3.4/4.0/4.1 Regression] Wrong warning aboutreturning a reference to a temporary

[Mark Mitchell <mark at codesourcery dot com>]

Roger Sayle wrote:

> For example, I believe that Alex's proposed solution to PR c++/19199
> isn't an appropriate fix.  It's perfectly reasonable for fold to convert
> a C++ COND_EXPR into a MIN_EXPR or MAX_EXPR, as according to the C++
> front-end all three of these tree nodes are valid lvalues.  Hence it's
> not this transformation in fold that's in error.

Only sort-of: you added the support for MIN_EXPR/MAX_EXPR as lvalues in 
build_modify, but not the same kind of back-to-COND_EXPR transformation 
elsewhere.

> The first is to see if in the C++ parser provides enough information
> such that it knows we're if parsing an lvalue or an rvalue. 

I don't think that's going to be totally convenient to do.  It's a good 
idea, as I said when we discussed this before, and probably a bit easier 
now than then, but I still think it's going to take a fair amount of 
work.  You'd want to have an extra return value from every 
expression-parsing routine saying whether the expression you've got is 
an lvalue.  And that would require threading that information through 
the front end, and maybe even parts of the middle end.  Then, before a 
patch like that went in, I'd want to see the current lvalue_p_1 routine 
completely eliminated; we should have just one way of figuring out 
whether or not something is an lvalue.

Furthermore, in the case of COND_EXPR, what you really want to know is 
not whether the expression is an lvalue, but whether it's going to be 
used as an lvalue.  For example, given:

 int i, j, k;

 k = ((i > j) ? i : j);

The fact that the RHS is an lvalue is irrelevant; it's being used an 
rvalue.  But, if the conditional appears as an argument to a function, 
you won't know until overload resolution, which is going to happen later 
than where we are now.

This is why Nathan and I consider the current fold design broken; 
folding should happen later (at gimplification time) not early, as you 
say here:

> If the parser can't be used to provide useful context, we could
> potentially postpone the calling of "fold" for C++ COND_EXPRs during
> parsing, but call "fold" on COND_EXPRs while lowering to gimple, where
> we'll always know whether we're expecting lvalues/rvalues.

We should do that for *all* calls to fold.  A patch to do that would be 
most welcome!

> An improvement on this approach is for the C++ front-end never to create
> COND_EXPR, MIN_EXPR or MAX_EXPR as the target of MODIFY_EXPRs, and lower
> them itself upon creation.  

Upon gimplification would be fine.  Before that would be preventing the 
C++ front end from representing the language in the most natural way.

> Finally, the third approach would be to introduce new tree codes for
> LCOND_EXPR, LMIN_EXPR and LMAX_EXPR that reflect the subtley different
> semantics of these operators when uses as lvalues.  

Swee above; I don't think you can now this at the time at which the 
front end is presently calling fold.

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