This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Bug c++/19199] [3.3/3.4/4.0/4.1 Regression] Wrong warning aboutreturning a reference to a temporary
- From: Mark Mitchell <mark at codesourcery dot com>
- To: Roger Sayle <roger at eyesopen dot com>
- Cc: Alexandre Oliva <aoliva at redhat dot com>, gcc-patches at gcc dot gnu dot org, gcc at gcc dot gnu dot org
- Date: Mon, 07 Mar 2005 09:58:12 -0800
- Subject: Re: [Bug c++/19199] [3.3/3.4/4.0/4.1 Regression] Wrong warning aboutreturning a reference to a temporary
- Organization: CodeSourcery, LLC
- References: <Pine.LNX.4.44.0503070934490.6071-100000@www.eyesopen.com>
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
mark@codesourcery.com
(916) 791-8304