http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58678
--- Comment #19 from Jason Merrill <jason at gcc dot gnu.org> --- I think it would make sense to suppress speculative devirtualization of a DECL_ARTIFICIAL destructor, since that seems to be the problem here (and in 53808). I think it's better to address this in devirtualization rather than inlining so that an explicitly non-virtual call (e.g. from a destructor to a base destructor) can still be inlined. This doesn't address user-declared inline destructors, including those declared as =default in the class body, but I'm comfortable saying that people who do that should expect it to be inlined, whereas people who don't mention a destructor at all can be forgiven for being surprised that we inline the destructor they weren't thinking about. I think I'm also inclined to allow non-speculative devirtualization, since in cases where we know the type of the object we presumably have access to the vtable in the current shared object. Do you have an opinion about whether this restriction should apply to virtual operator= as well? I think that's much less likely to occur, but it probably makes most sense to handle it the same way. Testing a patch now.
