From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31724 invoked by alias); 28 Feb 2014 20:32:34 -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 31689 invoked by uid 48); 28 Feb 2014 20:32:31 -0000 From: "hubicka at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug ipa/60306] [4.9 Regression] Incorrect devirtualization "pure virtual method called" Date: Fri, 28 Feb 2014 20:32: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: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: hubicka at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: hubicka at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.9.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created 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-02/txt/msg02868.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60306 --- Comment #8 from Jan Hubicka --- Created attachment 32235 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32235&action=edit Better WIP patch Yep, ignoring the calls also surprised me. I spent some time trying to think of and produce more evil testcases to this issue, but rest of Martin's reasoning seems right. The code really just mixes up the case where it knows something on all understood places with the case it knows something on all possible paths through the code. It implements the first but wants the second. I also tried to give up on all calls first. That makes the intraprocedural and part of inter-procedural devirt to give up almost always. Except for trivial cases that are handled by SCCVN you almost always have a call in a way, so testsuite is not really happy about it. Other option is to simply give up on recording anything when type change is seen. This also fixes the bug, perhaps with less fallout. Third option is to record if walk ever reached top of function and if it did give up when type change is seen. This seems to be simple addition to ao walker, we just need some interface for it. Fourth option is to be smarter about the calls defining type that is something I would like to do for next stage1, patch attached. It is ortoghonal to 1/2/3, if we have it we will just understand more paths (and currently I punt if I see some not understood path) I can get some data on difference in between options 1,2,3 for mainline, or do we just want to give up?