From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4654 invoked by alias); 4 Oct 2013 10:33:36 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 4570 invoked by uid 55); 4 Oct 2013 10:33:33 -0000 From: "hubicka at ucw dot cz" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/58585] [4.9 Regression] ICE in ipa with virtual inheritance Date: Fri, 04 Oct 2013 10:33:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Version: 4.9.0 X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: hubicka at ucw dot cz X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: hubicka at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.9.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2013-10/txt/msg00216.txt.bz2 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 > rather than to B because A is a primary base of C and not of B-in-C. BINFO_INHERITANCE_CHAIN is cleared by free_lang_data, so it is not available to me. It would not be hard to change this and add streaming of this pointer. I have bit problem to interpret the comment: /* The BINFO_INHERITANCE_CHAIN points at the binfo for the base inheriting this base for non-virtual bases. For virtual bases it points either to the binfo for which this is a primary binfo, or to the binfo of the most derived type. */ So basically given a BINFO I walk I can look at BINFO_INHERITANCE_CHAIN and if my offset is the same as offset of BINFO_INHERITANCE_CHAIN I will take its virtual table and if not, I will take virutal table of BINFO that will always be non-NULL? Will this work in a case of non-virtual multiple inheritance? I.e A / \ B C / \ D E where I think A+B share vtable and C+D share vtable? I need D BINFO_INHERITANCE_CHAIN to point to C instead of A, but in the case of virtual inheritance I need it to point to A instead of C. It is not big deal to change record_binfos to walk the fields instead of base list and perhaps it would end up being easier than the above. However I am not sure about get_binfo_at_offset implementation either. it does 1) walk fields and find corresponding filed 2) a) if field is not artificial then it switches to new binfo otherwise: b) if offset is non-0 it walks bases to look up BINFO corresponding to the field. What will hapen in the case of multiple virtual inheritance? Assume the example above has all bases virtual. Here I think D will be field of A with non-0 offset but it will not be in list of bases of A. So I think get_binfo_at_offset will fail in b) and will return NULL. I think we do not hit this problem only because devirt machinery do not understand virtual inheritance lookup - it basically never gets into the outer type. Honza