Jason Merrill ja...@redhat.com writes:
diff --git a/gcc/testsuite/g++.dg/opt/devirt4.C
b/gcc/testsuite/g++.dg/opt/devirt4.C
new file mode 100644
index 000..26e8ee6
--- /dev/null
+++ b/gcc/testsuite/g++.dg/opt/devirt4.C
@@ -0,0 +1,16 @@
+// PR c++/53808
+// Devirtualization +
Hmm, I wonder why we aren't devirtualizing that call on ia64. Does it
work with -O3?
Jason
Jason Merrill ja...@redhat.com writes:
Hmm, I wonder why we aren't devirtualizing that call on ia64. Does it
work with -O3?
That doesn't change anything fundamentally.
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA
On Thu, Feb 27, 2014 at 2:53 PM, Andreas Schwab sch...@suse.de wrote:
Jason Merrill ja...@redhat.com writes:
Hmm, I wonder why we aren't devirtualizing that call on ia64. Does it
work with -O3?
That doesn't change anything fundamentally.
I think the vtable lookup sequence is different and
On 02/27/2014 09:03 AM, Richard Biener wrote:
Jason Merrill ja...@redhat.com writes:
Hmm, I wonder why we aren't devirtualizing that call on ia64.
I think the vtable lookup sequence is different and nobody cared to adjust
the gimple matcher to also match the ia64 sequence.
Ah. So xfail on
On Thu, Feb 27, 2014 at 3:51 PM, Jason Merrill ja...@redhat.com wrote:
On 02/27/2014 09:03 AM, Richard Biener wrote:
Jason Merrill ja...@redhat.com writes:
Hmm, I wonder why we aren't devirtualizing that call on ia64.
I think the vtable lookup sequence is different and nobody cared to
On Thu, Feb 27, 2014 at 04:00:22PM +0100, Richard Biener wrote:
On Thu, Feb 27, 2014 at 3:51 PM, Jason Merrill ja...@redhat.com wrote:
On 02/27/2014 09:03 AM, Richard Biener wrote:
Jason Merrill ja...@redhat.com writes:
Hmm, I wonder why we aren't devirtualizing that call on ia64.
I
On Thu, Feb 27, 2014 at 2:53 PM, Andreas Schwab sch...@suse.de wrote:
Jason Merrill ja...@redhat.com writes:
Hmm, I wonder why we aren't devirtualizing that call on ia64. Does it
work with -O3?
That doesn't change anything fundamentally.
I think the vtable lookup sequence is
On 02/25/2014 01:53 PM, Jason Merrill wrote:
The primary bug under discussion in 53808 has been fixed separately, but
it also pointed out that once devirtualization resolves the delete to
use the bar destructor, we ought to be able to inline that destructor.
So if we're devirtualizing, always
But this caused bug 60347: turns out that we shouldn't do this
unless the vtable (and thus the contents of the vtable) are used.
The ipa-devirt type inheritance builder will use any vtable it finds in
DECL_BINFO
of types that it knows about. It starts with types of virtual methods and
virtual
The primary bug under discussion in 53808 has been fixed separately, but
it also pointed out that once devirtualization resolves the delete to
use the bar destructor, we ought to be able to inline that destructor.
So if we're devirtualizing, always add a virtual defaulted dtor to the
list of
11 matches
Mail list logo
