libg++ won't build with latest snapshots

Mike Stump
Fri Jan 7 13:03:00 GMT 2000

> To: Mark Mitchell <>
> From: Alexandre Oliva <>
> Date: 07 Jan 2000 09:09:59 -0200

> > Actually, the thing that provides equivalent optimization is the
> > return-value optimization.  That's certainly feasible, now that we can
> > operate on trees, but I'm not sure when it will get done.

> For some reason, I was thinking tree inlining would unify the return
> value of inlined function with the returned variable, but, thinking
> some more about it, it really doesn't make much sense to expect it
> to come up as a side effect of tree inlining.

Yes.  There is a well known optimization that is possible that we
don't do (with rtl).  With trees, it will be trivial to do it.  It is
not only possible, but desirable.  Imagine:

template <class T>
T foo(T f) { return f; }

main() {
       int f = foo(foo(foo(1)));
       printf("f is %d\n, f);

in C.  When optimized, one notices that what is left is just a call to
printf with a constant.  Not, if we place the int in a class and wrap
it up with all the right constructors and operators, we find that
there is a `penalty' for doing this.  Lots of people call this the
abstraction penalty.  The goal is to make nice C++ as cheap as plain
C, or put another way, to reduce or totally eliminate all the variable
abstraction penalties.

If you already knew all this, pardon me, I just misread your message.  :-)

More information about the Gcc-bugs mailing list