[Bug c++/19199] [3.3/3.4/4.0/4.1 Regression] Wrong warning about returning a reference to a temporary

Roger Sayle roger@eyesopen.com
Mon Mar 7 18:32:00 GMT 2005

On Mon, 7 Mar 2005, Mark Mitchell wrote:
> 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. :-)

I do appreciate the smiley, but I still feel unfairly maligned by such
accusations.  Once again, fold-const.c CVS version 1.1, converts
COND_EXPRs into MIN_EXPRs and MAX_EXPRs, though admittedly under the
control of "pedantic_lvalues".  I suspect that with the various
rearrangements of GCC's ANSI/ISO warnings since then, the distinction
got lost.

I agree "who did what to whom isn't important", but it is important
(to me) that neither subject nor object was me! :-)   I'm sure you'll
agree that its bad for the community, if the handful of people fixing
problems get blamed for causing them.  I've certainly been fixing
bugzilla PRs under the assumption that there'd be no stigma attached
to fixing wrong-code regressions.  If I only fixed problems caused by
me, I'd have an easy life.

> 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.

Depends upon your definition of a "pass".  fold isn't recursive, i.e.
it only rearranges the top-level node of the tree assuming that all of
it's subtrees/operands have already been folded.  Hence, to perform
"fold" at the end of a statement would still require an additional
post-order traversal of the entire tree.  Whether its done per statment,
per function or per compilation unit, isn't usually significant in the
definition of what constitutes a pass.

I still believe the issue is resolvable for 4.0, but I just haven't
completely figured out the safest, least-intrusive change to do it yet.


More information about the Gcc-patches mailing list