<div dir="ltr">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?)?<br><br>The usual "What does GCC do?" might be helpful - do they ever do this? Do they do it only > -O0?</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Nov 11, 2013 at 8:29 PM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 11 November 2013 11:18, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br>

> This seems to have broken the GDB bot:<br>
> <a href="http://lab.llvm.org:8011/builders/clang-x86_64-ubuntu-gdb-75/builds/10344" target="_blank">http://lab.llvm.org:8011/builders/clang-x86_64-ubuntu-gdb-75/builds/10344</a> (<br>
> <a href="http://lab.llvm.org:8011/builders/clang-x86_64-ubuntu-gdb-75/builds/10344/steps/gdb-75-check/logs/gdb.cp__destrprint.exp" target="_blank">http://lab.llvm.org:8011/builders/clang-x86_64-ubuntu-gdb-75/builds/10344/steps/gdb-75-check/logs/gdb.cp__destrprint.exp</a><br>

> )<br>
><br>
> I haven't looked too closely at the failure yet, but let me know if you need<br>
> a hand understanding it or deciding if it's a true/false positive.<br>
><br>
> I suspect, while the optimization you've implemented is legitimate, it will<br>
> reduce -O0 debuggability somewhat (as COMDAT/function deduplication tends<br>
> to) - if it does so too severely we might want to enable it only in -O1 and<br>
> above. (times like these it might be nice to have -Og)<br>
<br>
</div>The issue seems to be us replacing a derived destructor with a base<br>
one. We were not using aliases since we could not guarantee we would<br>
get the same comdat in every file, but with rauw that is legal. We<br>
would have exactly the same issue with older clangs if the classes had<br>
out of line destructors.<br>
<br>
With the new clang we get:<br>
<br>
#0  Base::~Base (this=0x7fffffffde50) at<br>
/home/espindola/llvm/cte/gdb/testsuite/gdb.cp/destrprint.cc:14<br>
#1  0x00000000004007cf in main () at<br>
/home/espindola/llvm/cte/gdb/testsuite/gdb.cp/destrprint.cc:35<br>
<br>
By disabling the optimization we get<br>
<br>
#0  Base::~Base (this=0x7fffffffde50) at<br>
/home/espindola/llvm/cte/gdb/testsuite/gdb.cp/destrprint.cc:14<br>
#1  0x0000000000400835 in Derived::~Derived (this=0x7fffffffde50) at<br>
/home/espindola/llvm/cte/gdb/testsuite/gdb.cp/destrprint.cc:28<br>
#2  0x0000000000400815 in Derived::~Derived (this=0x7fffffffde50) at<br>
/home/espindola/llvm/cte/gdb/testsuite/gdb.cp/destrprint.cc:27<br>
#3  0x00000000004007cf in main () at<br>
/home/espindola/llvm/cte/gdb/testsuite/gdb.cp/destrprint.cc:3<br>
<br>
I don't know enough dwarf to say if we could represent this in the<br>
debug info. If not, should we just disable this opimization (derived<br>
to base alias/rauw) at -O0?<br>
<br>
Cheers,<br>
Rafael<br>
</blockquote></div><br></div>