public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "hubicka at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/58585] [4.9 Regression] ICE in ipa with virtual inheritance Date: Thu, 03 Oct 2013 15:52:00 -0000 [thread overview] Message-ID: <bug-58585-4-nY5Tf0maf3@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-58585-4@http.gcc.gnu.org/bugzilla/> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58585 Jan Hubicka <hubicka at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jason at redhat dot com Blocks| |58252 --- Comment #3 from Jan Hubicka <hubicka at gcc dot gnu.org> --- Thanks for nice testcase. The problem here is that record_binfos and get_binfo_at_offset do not agree. I think it may be the same problem as in PR58252. Here we have class C with one (virtual) base B that has one (virtual) base A. record_binfos starts walk in binfo of C and it looks at base B. It passes two binfos around. type_binfo is binfo pointing to a virtual table to use, while binfo is the BINFo being walked. For non-virtual inheritance the first base share virtual table with outer class and its BINFO has no pointer to any vtable. So there is a conditional setting type_binfo to the base only if its vtable is non-NULL. Now for virtual inheritance, B have its own table defined, so we switch to B and eventually we look into vtable assigned to A. get_binfo_at_offset works slightly differently. It first walks fields of the structure identifying the field at proper offset. If it is abstract it is considered to represent base type. Then if offset is non-0 it uses BINFO of the base, while otherwise it stays on BINFO of outer type. For the testcase get_binfo_at_offsets is called with offset 0 and it makes lookup in the vtable pointed by BINFO of C that contains a thunk, while record_binfos looks into vtable pointer by BINFO representing base A within C that has directly method foo. Obviously both functions must be made to agree. C::C seems to be compiled as: _ZN1CC1Ev: .LFB12: .cfi_startproc .cfi_personality 0x3,__gxx_personality_v0 movq _ZTT1C+24(%rip), %rax movq _ZTT1C+32(%rip), %rdx movq -32(%rax), %rax movq %rdx, 8(%rdi,%rax) movq $_ZTV1C+88, 8(%rdi) movq $_ZTV1C+40, (%rdi) movq _ZTV1C+40(%rip), %rax jmp *%rax and _ZTV1C: .quad 0 .quad 8 .quad 8 .quad 0 .quad _ZTI1C .quad _ZTv0_n24_N1B3fooEv so we really call thunk here and probably record_binfos is incorrect. I can fix it by also waking fields and handling fields at offset 0 specially, but I would hope there is direct way how to do so via BASE_BINFOs walk.... I tried to change conditional in record_binfos to only switch type_binfo if BINFO_OFFSET != 0, but in this case it is 8. This also seems incorect to me... Jason, any ideas about the proper fix? Honza
next prev parent reply other threads:[~2013-10-03 15:52 UTC|newest] Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-09-30 21:50 [Bug middle-end/58585] New: " reichelt at gcc dot gnu.org 2013-10-02 15:48 ` [Bug middle-end/58585] " hubicka at gcc dot gnu.org 2013-10-03 15:52 ` hubicka at gcc dot gnu.org [this message] 2013-10-03 16:11 ` hubicka at gcc dot gnu.org 2013-10-03 21:46 ` hubicka at ucw dot cz 2013-10-04 1:50 ` jason at gcc dot gnu.org 2013-10-04 10:33 ` hubicka at ucw dot cz 2013-11-05 14:46 ` rguenth at gcc dot gnu.org 2013-12-06 11:29 ` octoploid at yandex dot com 2013-12-15 20:50 ` hubicka at gcc dot gnu.org 2014-01-07 9:09 ` hubicka at gcc dot gnu.org 2014-01-07 9:34 ` hubicka at gcc dot gnu.org 2014-01-07 10:50 ` trippels at gcc dot gnu.org 2014-01-07 11:07 ` trippels at gcc dot gnu.org 2014-01-07 13:07 ` hubicka at ucw dot cz 2014-01-07 17:31 ` hubicka at gcc dot gnu.org 2014-01-08 17:41 ` hubicka at gcc dot gnu.org 2014-01-08 17:53 ` trippels at gcc dot gnu.org 2014-01-10 9:40 ` hubicka at gcc dot gnu.org 2014-01-10 13:21 ` hubicka at gcc dot gnu.org 2014-01-10 21:35 ` hubicka at gcc dot gnu.org 2014-01-11 11:01 ` hubicka at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-58585-4-nY5Tf0maf3@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).