http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58585
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58585
--- Comment #21 from Jan Hubicka ---
Author: hubicka
Date: Fri Jan 10 21:34:37 2014
New Revision: 206543
URL: http://gcc.gnu.org/viewcvs?rev=206543&root=gcc&view=rev
Log:
PR ipa/58585
* ipa-devirt.c (build_type_inheritance_graph): Also a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58585
--- Comment #20 from Jan Hubicka ---
Looking even deeper, there are two problems. The first is that we miss C in
type hiearchy graph.
C however may be defined in other unit. We do mistake already while walking B.
There are two variants of B::fo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58585
--- Comment #19 from Jan Hubicka ---
Fix for PR58252 and PR59226 fixed first two problems contributing to the ICE on
the testcase. The last remaining problem is that our type inheritance graph is
incomplete, it misses the class C.
The reason is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58585
--- Comment #18 from Markus Trippelsdorf ---
(In reply to Jan Hubicka from comment #17)
> The patch seems to work and it seems to give correct answers for various
> cases of multiple inheritance I can think of. I would welcome testing on
> the or
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58585
--- Comment #17 from Jan Hubicka ---
The patch seems to work and it seems to give correct answers for various cases
of multiple inheritance I can think of. I would welcome testing on the
original sources and if it looks fine, I will go ahead with
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58585
--- Comment #16 from Jan Hubicka ---
Created attachment 31766
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31766&action=edit
Proposed fix 3
Hi,
it is still lightly tested due lack of time, but fixes the previous issue with
missing vtable.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58585
--- Comment #15 from Jan Hubicka ---
> markus@x4 gcc % cat test.ii
> class A {
> void m();
> };
> void A::m() {}
>
> markus@x4 gcc % /var/tmp/gcc_build_dir_/./prev-gcc/xg++
> -B/var/tmp/gcc_build_dir_/./prev-gcc/ -r -nostdlib -flto -O2 -pipe te
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58585
--- Comment #14 from Markus Trippelsdorf ---
Hmm,
markus@x4 gcc % cat test.ii
class A {
void m();
};
void A::m() {}
markus@x4 gcc % /var/tmp/gcc_build_dir_/./prev-gcc/xg++
-B/var/tmp/gcc_build_dir_/./prev-gcc/ -r -nostdlib -flto -O2 -pipe test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58585
Markus Trippelsdorf changed:
What|Removed |Added
CC||trippels at gcc dot gnu.org
--- Com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58585
--- Comment #12 from Jan Hubicka ---
Created attachment 31763
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31763&action=edit
Proposed fix 2
It turns out that in the case of multiple inheritance we may miss vtables on
certain paths when it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58585
--- Comment #11 from Jan Hubicka ---
Created attachment 31762
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31762&action=edit
Proposed fix
Hi,
this patch makes us to look harder for correct virtual table. I walk the stack
of binfos with vt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58585
--- Comment #10 from Jan Hubicka ---
Seems we got stuck on solving the virtual vtable representation issues. Here
are some of my experiments.
I think we have two problems, the first one is manifested by this testcase.
Here record_targets_from_bi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58585
Markus Trippelsdorf changed:
What|Removed |Added
CC||octoploid at yandex dot com
--- Com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58585
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58585
--- Comment #8 from Jan Hubicka ---
> Ah, right. We don't have an A binfo in C's base list.
>
> I believe you can distinguish this case by looking at the
> BINFO_INHERITANCE_CHAIN of the A binfo; in this case, it should point back to
> C
> rath
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58585
--- Comment #7 from Jason Merrill ---
(In reply to Jan Hubicka from comment #6)
> It does not fix the problem, unfortunately. This is what happens:
Ah, right. We don't have an A binfo in C's base list.
I believe you can distinguish this case b
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58585
--- Comment #6 from Jan Hubicka ---
> > Is there way how to keep track of the vtables w/o doing the walk based on
> > fields instead of BINFO_BASEs?
>
> There should be. Your code change makes sense to me; a primary base will
> always be at offs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58585
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #5 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58585
--- Comment #4 from Jan Hubicka ---
This is the code I am playing with:
/* Walk bases. */
for (i = 0; BINFO_BASE_ITERATE (binfo, i, base_binfo); i++)
/* Walking bases that have no virtual method is pointless excercise. */
if (polymor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58585
Jan Hubicka changed:
What|Removed |Added
CC||jason at redhat dot com
Blocks|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58585
Jan Hubicka changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58585
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58585
Richard Biener changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
Target Mile
24 matches
Mail list logo
