This optimization fires if the derived dtor has no work to do (and thus without the optimization Clang emits a derived dtor that simply contains a call to the base dtor?)?
The usual "What does GCC do?" might be helpful - do they ever do this? Do they do it only > -O0? On Mon, Nov 11, 2013 at 8:29 PM, Rafael Espíndola < [email protected]> wrote: > On 11 November 2013 11:18, David Blaikie <[email protected]> wrote: > > This seems to have broken the GDB bot: > > > http://lab.llvm.org:8011/builders/clang-x86_64-ubuntu-gdb-75/builds/10344( > > > http://lab.llvm.org:8011/builders/clang-x86_64-ubuntu-gdb-75/builds/10344/steps/gdb-75-check/logs/gdb.cp__destrprint.exp > > ) > > > > I haven't looked too closely at the failure yet, but let me know if you > need > > a hand understanding it or deciding if it's a true/false positive. > > > > I suspect, while the optimization you've implemented is legitimate, it > will > > reduce -O0 debuggability somewhat (as COMDAT/function deduplication tends > > to) - if it does so too severely we might want to enable it only in -O1 > and > > above. (times like these it might be nice to have -Og) > > The issue seems to be us replacing a derived destructor with a base > one. We were not using aliases since we could not guarantee we would > get the same comdat in every file, but with rauw that is legal. We > would have exactly the same issue with older clangs if the classes had > out of line destructors. > > With the new clang we get: > > #0 Base::~Base (this=0x7fffffffde50) at > /home/espindola/llvm/cte/gdb/testsuite/gdb.cp/destrprint.cc:14 > #1 0x00000000004007cf in main () at > /home/espindola/llvm/cte/gdb/testsuite/gdb.cp/destrprint.cc:35 > > By disabling the optimization we get > > #0 Base::~Base (this=0x7fffffffde50) at > /home/espindola/llvm/cte/gdb/testsuite/gdb.cp/destrprint.cc:14 > #1 0x0000000000400835 in Derived::~Derived (this=0x7fffffffde50) at > /home/espindola/llvm/cte/gdb/testsuite/gdb.cp/destrprint.cc:28 > #2 0x0000000000400815 in Derived::~Derived (this=0x7fffffffde50) at > /home/espindola/llvm/cte/gdb/testsuite/gdb.cp/destrprint.cc:27 > #3 0x00000000004007cf in main () at > /home/espindola/llvm/cte/gdb/testsuite/gdb.cp/destrprint.cc:3 > > I don't know enough dwarf to say if we could represent this in the > debug info. If not, should we just disable this opimization (derived > to base alias/rauw) at -O0? > > Cheers, > Rafael >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
