On Thu, Jul 04, 2019 at 02:56:47PM +0200, Paolo Carlini wrote:
> --- cp/call.c (revision 273076)
> +++ cp/call.c (working copy)
> @@ -9845,17 +9852,6 @@ build_new_method_call_1 (tree instance, tree fns,
>
> if (call != error_mark_node)
> {
> - /* Optimize away vtable l
On 7/4/19 8:56 AM, Paolo Carlini wrote:
Hi,
On 27/06/19 23:19, Jason Merrill wrote:
Ah, thanks. Then perhaps we want to change the CLASSTYPE_FINAL in
build_over_call to resolves_to_fixed_type_p (arg), to also handle the
other reasons we might know the dynamic type of the argument, and
remove
Hi,
On 27/06/19 23:19, Jason Merrill wrote:
Ah, thanks. Then perhaps we want to change the CLASSTYPE_FINAL in
build_over_call to resolves_to_fixed_type_p (arg), to also handle the
other reasons we might know the dynamic type of the argument, and
remove the related code from build_new_method_c
On 6/24/19 4:52 AM, Paolo Carlini wrote:
Hi,
On 23/06/19 19:45, Jason Merrill wrote:
On 6/23/19 7:53 AM, Paolo Carlini wrote:
... hi again ;)
The other day I was having a look at using declarations for this
issue and noticed that only a few lines below the de-virtualization
check we have to
Hi,
On 23/06/19 19:45, Jason Merrill wrote:
On 6/23/19 7:53 AM, Paolo Carlini wrote:
... hi again ;)
The other day I was having a look at using declarations for this
issue and noticed that only a few lines below the de-virtualization
check we have to handle functions found by a using declara
On 6/23/19 7:53 AM, Paolo Carlini wrote:
... hi again ;)
The other day I was having a look at using declarations for this issue
and noticed that only a few lines below the de-virtualization check we
have to handle functions found by a using declaration, for various
reasons. In particular, we
... hi again ;)
The other day I was having a look at using declarations for this issue
and noticed that only a few lines below the de-virtualization check we
have to handle functions found by a using declaration, for various
reasons. In particular, we know whether we found a function fn where
... so, now that I see the issue more clearly, I'm adding to the
testsuite the below too.
Thanks, Paolo.
Index: final7.C
===
--- final7.C(nonexistent)
+++ final7.C(working copy)
@@ -0,0 +1,11 @@
+
and...
By the way, if S1:.f is not pure virtual, just a virtual declaration -
all the rest being the same - the code doesn't link: undefined
references to vtable and typeinfo for S1. The same happens with
current clang and icc. I don't know if this detail helps us in the
short term
... t
Hi,
On 21/06/19 21:27, Paolo Carlini wrote:
Hi,
On 21/06/19 20:50, Jason Merrill wrote:
On 6/20/19 12:24 AM, Paolo Carlini wrote:
Hi,
this bug notices that the more aggressive de-virtualization check
that we have now in place (fixed c++/67184) doesn't work correctly
for the below reproduce
Hi,
On 21/06/19 20:50, Jason Merrill wrote:
On 6/20/19 12:24 AM, Paolo Carlini wrote:
Hi,
this bug notices that the more aggressive de-virtualization check
that we have now in place (fixed c++/67184) doesn't work correctly
for the below reproducer, which involves a pure virtual: we
de-virtu
On 6/20/19 12:24 AM, Paolo Carlini wrote:
Hi,
this bug notices that the more aggressive de-virtualization check that
we have now in place (fixed c++/67184) doesn't work correctly for the
below reproducer, which involves a pure virtual: we de-virtualize and
the build fails at link-time. To cur
Hi,
this bug notices that the more aggressive de-virtualization check that
we have now in place (fixed c++/67184) doesn't work correctly for the
below reproducer, which involves a pure virtual: we de-virtualize and
the build fails at link-time. To cure this I believe we simply want an
additio
13 matches
Mail list logo
