From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27320 invoked by alias); 21 Mar 2014 14:41:39 -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 27271 invoked by uid 48); 21 Mar 2014 14:41:35 -0000 From: "jamborm at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug ipa/60600] [4.9 Regression] ICE in ipa_get_indirect_edge_target_1 Date: Fri, 21 Mar 2014 14:41:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: ipa X-Bugzilla-Version: 4.9.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jamborm at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: unassigned 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: 2014-03/txt/msg01971.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60600 --- Comment #2 from Martin Jambor --- Well, this is ICE on code with undefined behavior. Function test calls itself with a parameter which is a reference to an object of type child2 and then static_casts it to a reference to child1. These are non-PODs, neither of these types is an ancestor of the other and thus the use of static_cast is not allowed by the C++ standard. ipa-prop based devirtualization does not see the cast, it thinks the object is of type child2, and therefore the virtual method it looks up is intermediate::topf. Then it does a consistency check to see whether type hierarchy based devirtualization has that function among its possible targets. However, this devirtualization starts with child1 as its outer type and thus it concludes the only possible target is top::topf. The consistency check fails and we get an ICE on assert. The assert has to go but I wonder whether we want to give up when possible_polymorphic_call_target_p returns false so that we don't try to optimize such undefined cases. We might even give a warning, although making the warning useful to the user might require some effort.