Thanks for review. I actually noticed your introduction of
cp_build_fold_indirect_ref after I installed my patch.
I'm testing following fix.
Martin
>From 63d9cff5c183f3614cff527ff991e1586a9efa5b Mon Sep 17 00:00:00 2001
From: marxin
Date: Wed, 15 Nov 2017 10:01:51 +0100
Subject: [PATCH] Fix fall
OK.
On Mon, Nov 6, 2017 at 3:27 AM, Martin Liška wrote:
> On 11/03/2017 04:21 PM, Jason Merrill wrote:
>> On Fri, Nov 3, 2017 at 10:25 AM, Martin Liška wrote:
>>> On 10/27/2017 09:44 PM, Nathan Sidwell wrote:
On 10/27/2017 02:34 PM, Jakub Jelinek wrote:
> But when singly inheriting
PING^1
On 11/06/2017 09:27 AM, Martin Liška wrote:
On 11/03/2017 04:21 PM, Jason Merrill wrote:
On Fri, Nov 3, 2017 at 10:25 AM, Martin Liška wrote:
On 10/27/2017 09:44 PM, Nathan Sidwell wrote:
On 10/27/2017 02:34 PM, Jakub Jelinek wrote:
But when singly inheriting a polymorphic base and
;
>>
>> Hello.
>>
>> I'm sending v2 which only zeros vptr of object.
>>
>> Ready to be installed after finishing tests?
>
> Surely we also want to check TYPE_CONTAINS_VPTR_P.
>
> Jason
>
Done that in attached patch.
Patch can bootstrap on ppc
On 11/03/2017 03:31 PM, Marek Polacek wrote:
I think the last dg-output shouldn't have any regexps at the end, so:
// { dg-output "0x\[0-9a-fA-F]*: note: object has invalid vptr" }
Thanks for that.
I'll fix it.
Martin
On Fri, Nov 3, 2017 at 10:25 AM, Martin Liška wrote:
> On 10/27/2017 09:44 PM, Nathan Sidwell wrote:
>> On 10/27/2017 02:34 PM, Jakub Jelinek wrote:
>>
>>> But when singly inheriting a polymorphic base and thus mapped to the same
>>> vptr all but the last dtor will not be in charge, right?
>>
>> C
> Ready to be installed after finishing tests?
> Martin
> From 098932be5472656c834b402038accb0b861afcc1 Mon Sep 17 00:00:00 2001
> From: marxin
> Date: Thu, 19 Oct 2017 11:10:19 +0200
> Subject: [PATCH] Zero vptr in dtor for -fsanitize=vptr.
>
> gcc/cp/ChangeLog:
>
atch to see if in chargeness was signficant)
>
> nathan
>
Hello.
I'm sending v2 which only zeros vptr of object.
Ready to be installed after finishing tests?
Martin
>From 098932be5472656c834b402038accb0b861afcc1 Mon Sep 17 00:00:00 2001
From: marxin
Date: Thu, 19 Oct 2017 11:10:19
On 10/27/2017 02:34 PM, Jakub Jelinek wrote:
But when singly inheriting a polymorphic base and thus mapped to the same
vptr all but the last dtor will not be in charge, right?
Correct.
So, if using build_clobber_this for this, instead of clobbering what we
clobber we'd just clear the single
On Fri, Oct 27, 2017 at 02:30:39PM -0400, Nathan Sidwell wrote:
> On 10/27/2017 02:18 PM, Jakub Jelinek wrote:
> > On Fri, Oct 27, 2017 at 02:10:10PM -0400, Jason Merrill wrote:
>
> > > If the point is to clear the vptr, why are you also clearing the rest
> > > of the object?
> >
> > Can there be
On 10/27/2017 02:18 PM, Jakub Jelinek wrote:
On Fri, Oct 27, 2017 at 02:10:10PM -0400, Jason Merrill wrote:
If the point is to clear the vptr, why are you also clearing the rest
of the object?
Can there be multiple vptr pointers in the object or is there just one?
Even if there can be multip
On Fri, Oct 27, 2017 at 02:10:10PM -0400, Jason Merrill wrote:
> On Fri, Oct 27, 2017 at 9:52 AM, Jakub Jelinek wrote:
> > On Fri, Oct 27, 2017 at 03:48:41PM +0200, Martin Liška wrote:
> >> --- a/gcc/cp/decl.c
> >> +++ b/gcc/cp/decl.c
> >> @@ -14639,8 +14639,12 @@ implicit_default_ctor_p (tree fn)
On Fri, Oct 27, 2017 at 9:52 AM, Jakub Jelinek wrote:
> On Fri, Oct 27, 2017 at 03:48:41PM +0200, Martin Liška wrote:
>> --- a/gcc/cp/decl.c
>> +++ b/gcc/cp/decl.c
>> @@ -14639,8 +14639,12 @@ implicit_default_ctor_p (tree fn)
>> /* Clobber the contents of *this to let the back end know that the o
On Fri, Oct 27, 2017 at 03:48:41PM +0200, Martin Liška wrote:
> --- a/gcc/cp/decl.c
> +++ b/gcc/cp/decl.c
> @@ -14639,8 +14639,12 @@ implicit_default_ctor_p (tree fn)
> /* Clobber the contents of *this to let the back end know that the object
> storage is dead when we enter the constructor or
point to an object of type
'MyClass'(\n|\r\n|\r)" }
+// { dg-output "0x\[0-9a-fA-F]*: note: object has invalid vptr(\n|\r\n|\r)" }
+
Unnecessary empty line at end.
Likewise.
Martin
Jakub
>From b1da5f4de8b630f284627f422b902d28cd1d408b Mon Sep 17 00:00:
On Fri, Oct 27, 2017 at 01:16:08PM +0200, Martin Liška wrote:
> On 10/27/2017 12:52 PM, Jakub Jelinek wrote:
> > The decl.c change seems to be only incremental change from a not publicly
> > posted patch rather than the full diff against trunk.
>
> Sorry for that. Sending full patch.
Thanks.
> -
rom: marxin
Date: Thu, 19 Oct 2017 11:10:19 +0200
Subject: [PATCH] Zero vptr in dtor for -fsanitize=vptr.
gcc/cp/ChangeLog:
2017-10-27 Martin Liska
* decl.c (begin_destructor_body): In case of disabled recovery,
we can zero object in order to catch virtual calls after
an object lifetime.
On Fri, Oct 27, 2017 at 12:47:12PM +0200, Martin Liška wrote:
> Hello.
>
> This is small improvement that can catch a virtual call after a lifetime
> scope of an object.
>
>
> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
>
> Ready to be installed?
The decl.c chang
Hello.
This is small improvement that can catch a virtual call after a lifetime
scope of an object.
Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
Ready to be installed?
Martin
gcc/cp/ChangeLog:
2017-10-27 Martin Liska
* decl.c (begin_destructor_body):
19 matches
Mail list logo