I have encountered a bug which I'm not sure if it should be attributed to gcc or gdb. Example code is below. Inside Foo::operator+, gdb will on some systems have the wrong location for the variable "res" such that looking at res.top in gdb shows a bogus number. The actual code execution is fine. I then have 2 "workarounds" to make gdb see the correct location for res. The first workaround is to make the return variable of operator+ not compile-time deterministic (add -DGDB_HAPPY to compile line). The second workaround is to remove my empty destructor (-DGDB_HAPPY_ALT). I can make guesses on why the first case matters. I have no clue on the second case. Without the workarounds, I've found the following systems to work or not: Ubuntu 9.04, gcc 4.3.3, gdb 6.8 - Buggy Ubuntu 9.04, gcc 4.2.4, gdb 6.8 - Works Ubuntu 9.04, gcc 4.1.3, gdb 6.8 - Works Mac Snow Leopard, gcc 4.2.1, gdb 6.3.50-20050815 (Apple version gdb-1346) - Works Centos 5.2, gcc 4.1.2, gdb 6.5-37.el5_r.2rh - Buggy (tried both 32-bit and 64-bit) Gentoo, gcc 4.3.4, gdb 6.6, - Buggy I've found an old (but still open) gdb bug which may be related: 8761 "if gdb cannot find function return value location, random unitialized [sic] value is used" Given different results on Ubuntu using the same gdb, I'm not convinced its gdb. Is this the known gdb bug, and how should I be proceeding? ---- code ---- // Compiled with "g++ -o cpptest cpptest.cpp -g" fails on some systems // Works with "g++ -o cpptest cpptest.cpp -g -DGDB_HAPPY" // or with "g++ -o cpptest cpptest.cpp -g -DGDB_HAPPY_ALT" class Foo { public: Foo(int x=0) { this->top = (x)?1:0; } #ifndef GDB_HAPPY_ALT ~Foo() {}; #endif Foo operator+(const Foo& rhs) const; protected: int top; }; Foo Foo::operator+(const Foo& rhs) const { Foo dummy1, res, dummy2; int i = 0; i++; /* Look at res HERE in gdb. res.top should be 0 */ #ifdef GDB_HAPPY if (rhs.top) { return res; } else { return dummy1; } #else return res; #endif } int main(int argc, char* argv[]) { Foo A(1), B(2), C; C = A + B; return 0; }