This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: C++ PATCH for c++/58678 (devirt vs. KDE)
- From: Jason Merrill <jason at redhat dot com>
- To: Jan Hubicka <hubicka at ucw dot cz>
- Cc: gcc-patches List <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 17 Mar 2014 10:07:13 -0400
- Subject: Re: C++ PATCH for c++/58678 (devirt vs. KDE)
- Authentication-results: sourceware.org; auth=none
- References: <5323528C dot 1080308 at redhat dot com> <20140317083913 dot GF20522 at kam dot mff dot cuni dot cz>
On 03/17/2014 04:39 AM, Jan Hubicka wrote:
Thank you! would preffer different marker than cxa_pure_virtual in the vtable,
most probably simply NULL.
The reason is that __cxa_pure_virtual will appear as a possible target in the
list and it will prevent devirtualization to happen when we end up with
__cxa_pure_virtual and real destructor in the list of possible targets.
Hmm? __cxa_pure_virtual is not considered likely, so why wouldn't
devirtualization choose the real function instead?
gimple_get_virt_method_for_vtable knows that lookup in vtable that do not
result in FUNCTION_DECL should be translated to BUILTIN_UNREACHABLE and
ipa-devirt drops these from list of targets, unlike __cxa_pure_virtual that
stays.
I don't see the reason for that distinction; either way you get
undefined behavior. The only purpose of __cxa_pure_virtual is to give a
friendly diagnostic before terminating the program.
Other problem with cxa_pure_virtual is that it needs external relocation.
I sort of wondered if we don't want to produce hidden comdat wrapper for
it, so C++ programs are easier to relocate.
Sure, that would make sense.
What do you think of the following patch that makes ipa-devirt to conclude
that destructor calls are never done on types in construction.
If effect of doing so is undefined, I think it is safe to drop them from
list of targets and that really helps to reduce lists down.
That looks good to me.
Jason