Lifetime bug in temporaries

Gabriel Dos Reis
Wed Mar 25 09:58:00 GMT 1998

>>>>> «Marc», Marc Espie <> wrote:

Marc> /*
Marc> for those of you familiar with Blitz++, this should appear
Marc> as evident.

Marc> However, it crashes (SEGV) with a cvs-current egcs, compiled with 
Marc> enabled-haifa, on either dec-osf or solaris.

Even without haifa enable it crashes.

Marc> I've investigated it further with gdb-4.16.85.
Marc> The crash occurs in SumExpr<..>::operator[]()
Marc> It appears that b has been overwritten with a 0.
Marc> Setting up a watchpoint, it appears that the overwriting occurs
Marc> in 
Marc> 	for (size_t i = 0; i < SIZE; i++)
Marc> (in Vector::operator=)
Marc> Apparently, the compiler uses the same location for my temporary
Marc> as per i. Indeed, if I declare i to be static, everything works fine.

Marc> My understanding though, is that the SumExpr<..>  temporary should
Marc> still be alive at this point.

I experienced this problem when writing class valarray<>. I told
Ulrich Drepper about it, but finally I decided to use a
workaround. The problem is not specific to SumExpr but it lies in
class Expr : an object of class Expr stores a *reference* to a
temporary object which will desappear as soon as the function
make_expr() exits. What I did is to store an *object* that is given to
a Expr and not a reference to it.   

I think the problem is similar, perhaps more complicated, to this one

class A {

A& make_A() 
{ return A(); }  // what is the behaviour after exiting make_A()?
	         // it depends a lot on what you do with the result of
	         // make_A().

Marc> Am I missing something, or is g++ lifetime of temporaries still not in
Marc> tune with what it should be ?
Marc> */

That is the question.

Note that this problem does not show up when optimisation is on.

-- Gaby
"One reason that life is complex is that it has a 
real part and imaginary part." -- Andrew Koenig

More information about the Gcc-bugs mailing list