Roger Sayle wrote:
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:
I thought you were the person who introduced changes to fold that caused it to generate these expressions when the GNU source extension did not appear. Anyhow, who did what to whom isn't important. :-)
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".
The real root problem is that fold (a middle-end routine) is being called in the midst of front-end processing. You're definitely right that this problem has been around forever!
In the context of 4.0, we're not going to fix that. So, we have to see how best to keep the current house-of-cards standing. But, in terms of a long range fix, getting fold to run later is the right fix, on lots of levels.
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.
Actually, I think it's always been fixable. It's not a question of extra passes; it's just a question of ordering. We could have done fold at the end of a statement (rather than while building up a statement) even back in GCC 2.8, and that would have fixed the problem.
There's nothing wrong with having COND_EXPRs that are lvalues in the C++ front end; the problem only comes when the middle end starts trying to understand them. In fact, the C++ front end already contains code to massage these COND_EXPRs so that the back end doesn't see COND_EXPRs used as lvalues; it's just not getting a chance to run before fold!
-- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
