On Mon, 7 Mar 2005, Mark Mitchell wrote:
> 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.
I truly hope you're not trying to suggest that it was me that introduced
the concept of MIN_EXPR and MAX_EXPR as lvalues into the C++ front-end:
cvs annotate -r1.1 cp/tree.c
1.1 (law 11-Aug-97): int
1.1 (law 11-Aug-97): real_lvalue_p (ref)
1.1 (law 11-Aug-97): tree ref;
1.1 (law 11-Aug-97): {
...
1.1 (law 11-Aug-97): switch (TREE_CODE (ref))
1.1 (law 11-Aug-97): {
...
1.1 (law 11-Aug-97): case MAX_EXPR:
1.1 (law 11-Aug-97): case MIN_EXPR:
1.1 (law 11-Aug-97): return (real_lvalue_p (TREE_OPERAND
(ref, 0))
1.1 (law 11-Aug-97): && real_lvalue_p (TREE_OPERAND
(ref, 1)));
I'm just a guy trying to sort out the mess. Clearly, a fraction of the
compiler currently supports the use of COND_EXPR, MIN_EXPR and MAX_EXPR
as lvalues and another fraction doesn't. This issue predates CVS revision
1.1 (a.k.a. the dawn of time).
The very simple decision that we face is whether to change the compiler
consistently to allow lvalue COND_EXPRs everywhere, or to consistently
disallow them everywhere. Most of this decision making to date, has
been on how easy C++ is to parse/how well constructed the C++ parser is.
Disabling compiler optimizations to workaround a few instances of this
problem isn't a "fix".
Getting us out of this mess has only become possible with the advent
of tree-ssa, and tree walking passes between parsing and RTL expansion.
Roger
--
