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

[Mark Mitchell]

>Does the g++ parser know whether or not a ternary operator could
>potentially be an lvalue at the point its' processed?
>  
>
No.  Eventually, I would like it to know that -- but at present it does not.

>The following patch has been tested on i686-pc-linux-gnu with a full
>"make bootstrap", all default languages, and regression tested with a
>top-level "make -k check" with no new failures.  The testcase ICEs on
>mainline, but with this patch and my change to fold-const.c yesterday,
>we now generate the correct code.
>
>Ok for mainline?
>  
>
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...

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