r194288 - If a linkonce_odr dtor/ctor is identical to another one, just rauw.

David Blaikie dblaikie at gmail.com
Mon Nov 11 20:35:32 PST 2013


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 <
rafael.espindola at gmail.com> wrote:

> On 11 November 2013 11:18, David Blaikie <dblaikie at gmail.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131111/9255b07a/attachment.html>


More information about the cfe-commits mailing list