https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70147
--- Comment #29 from Jakub Jelinek ---
(In reply to Jason Merrill from comment #27)
> (In reply to Bernd Edlinger from comment #26)
> > I just fail to understand why we cannot just clobber the whole
> > object once in the in-charge constructor,
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70147
--- Comment #27 from Jason Merrill ---
(In reply to Bernd Edlinger from comment #26)
> I just fail to understand why we cannot just clobber the whole
> object once in the in-charge constructor,
> then if sanitizing vptrs initialize every vptr onc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70147
--- Comment #24 from Jakub Jelinek ---
Or do you consider this just harmless? If some ctor throws, even if dtor is
virtual, the dtor will change _vptr to what it expects before the rest of the
dtor body which could call virtual functions etc., a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70147
--- Comment #25 from Jakub Jelinek ---
(In reply to Jason Merrill from comment #20)
> I don't think that's a problem; the clobber only affects the as-base size of
> the class, which doesn't include any virtual bases unless they are primary,
> and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70147
--- Comment #28 from Jason Merrill ---
(In reply to Jason Merrill from comment #27)
> (In reply to Bernd Edlinger from comment #26)
> > I just fail to understand why we cannot just clobber the whole
> > object once in the in-charge constructor,
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70147
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70147
--- Comment #26 from Bernd Edlinger ---
I just fail to understand why we cannot just clobber the whole
object once in the in-charge constructor,
then if sanitizing vptrs initialize every vptr once to zero.
and skip all the clobber and vptr initia
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70147
--- Comment #23 from Jakub Jelinek ---
Consider:
// PR c++/70147
// { dg-do run }
// { dg-options "-fsanitize=vptr" }
static int ac, ad, bc, bd, cc, cd, dc, dd;
struct A { A () { ac++; } virtual void f () {} ~A () { ad++; }; };
struct D { D (int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70147
--- Comment #30 from Jason Merrill ---
Author: jason
Date: Fri Mar 18 15:31:35 2016
New Revision: 234335
URL: https://gcc.gnu.org/viewcvs?rev=234335&root=gcc&view=rev
Log:
PR c++/70147 - handle primary virtual bases
* class.c (v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70147
--- Comment #22 from Jakub Jelinek ---
Author: jakub
Date: Wed Mar 16 07:02:30 2016
New Revision: 234249
URL: https://gcc.gnu.org/viewcvs?rev=234249&root=gcc&view=rev
Log:
PR c++/70147
* cp-ubsan.c (cp_ubsan_dfs_initialize_vtbl_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70147
--- Comment #21 from Jakub Jelinek ---
Author: jakub
Date: Wed Mar 16 07:01:36 2016
New Revision: 234248
URL: https://gcc.gnu.org/viewcvs?rev=234248&root=gcc&view=rev
Log:
PR c++/70147
* cp-ubsan.c (cp_ubsan_maybe_initialize_vtbl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70147
--- Comment #20 from Jason Merrill ---
(In reply to Jakub Jelinek from comment #16)
> I am really concerned about the rest of the base object, because
> the constructor is only called once, and only in the in_charge
> ctor.
I don't think that's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70147
--- Comment #19 from Bernd Edlinger ---
(In reply to Jakub Jelinek from comment #18)
> (In reply to Bernd Edlinger from comment #17)
> >
> > Do you see a way, how to conditionalize the clobber on the in_charge?
>
> Very easily, by wrapping the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70147
--- Comment #18 from Jakub Jelinek ---
(In reply to Bernd Edlinger from comment #17)
> > As the compromise I meant this instead (incremental patch).
> > Though, in that case the -flifetime-dse=2 clobbers are also wrong in the
> > subobject ctors,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70147
--- Comment #17 from Bernd Edlinger ---
(In reply to Jakub Jelinek from comment #16)
> Created attachment 37965 [details]
> gcc6-pr70147-2.patch
>
this patch looks good to me.
Thanks.
> As the compromise I meant this instead (incremental patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70147
--- Comment #16 from Jakub Jelinek ---
Created attachment 37965
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37965&action=edit
gcc6-pr70147-2.patch
As the compromise I meant this instead (incremental patch).
Though, in that case the -fli
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70147
--- Comment #15 from Bernd Edlinger ---
Yep, maybe this would be a compromise:
Index: cp-ubsan.c
===
--- cp-ubsan.c (revision 234184)
+++ cp-ubsan.c (working copy)
@@ -285,6 +285,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70147
--- Comment #14 from Bernd Edlinger ---
Hi Jakub,
I played a bit with your proposed patch.
consider this test case:
cat test2.cc
struct A { ~A() {} A () {} A (int x) : a (x) {} virtual void f () {} virtual
int i () { return 0; } int a; };
stru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70147
--- Comment #13 from Jakub Jelinek ---
See my mail to gcc-patches. According to Jonathan, calling i() is invalid,
which your patch would not catch. And, the virtual vptrs should be at least
initialized in the in-chrg ctor even if we'd want to a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70147
--- Comment #12 from Bernd Edlinger ---
I think it is normal, that A's vptr is initialized first to
an A which means that f points to A::f and i points to A::i.
these overloads are usable while A's constructor runs.
The vptr is later changed to t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70147
Jakub Jelinek changed:
What|Removed |Added
CC||redi at gcc dot gnu.org
--- Comment #11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70147
--- Comment #10 from Bernd Edlinger ---
Created attachment 37959
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37959&action=edit
proposed patch
I don't think that it is necessary to initialize virtual base class vptrs
here, because it is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70147
--- Comment #9 from Martin Liška ---
(In reply to Volker Reichelt from comment #8)
> This is a regression that was introduced between the 20160228 snapshot and
> the 20160306 snapshot.
Yeah, it was introduced by Jakub's patch:
commit e968ff6d2e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70147
Volker Reichelt changed:
What|Removed |Added
CC||reichelt at gcc dot gnu.org
Known
24 matches
Mail list logo
