From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31420 invoked by alias); 10 Jan 2013 16:59:16 -0000 Received: (qmail 31294 invoked by uid 48); 10 Jan 2013 16:58:42 -0000 From: "jamborm at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/55683] [4.8 Regression] ICE in inline_call, at ipa-inline-transform.c:270 Date: Thu, 10 Jan 2013 16:59:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: jamborm at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.8.0 X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 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 X-SW-Source: 2013-01/txt/msg00962.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55683 --- Comment #15 from Martin Jambor 2013-01-10 16:58:35 UTC --- (In reply to comment #13) > The acutal ICE should be fixed. Martinj, I will leave the PR open > just to make you to double check that ipa-cp is doing properly the > translation from constants to binfos, too. At -O2, IPA-CP does not even consider cloning C::c1 because it is not allowed to grow code by creating clones. At -O3 (or with -fipa-cp-clone), IPA-CP discovers that cloning for &c would lead to devirtualization but because the target of the devirtualized call is not analyzed, it gets only minimal bonus for that. Eventually the cloning opportunity gets score 437 (cloning threshold is 500) and thus it is dropped. This is as it should be. > I would expect this testcase to be caught by ipa-cp prior inlining. Also I > think that when merging values, we should go from constant to binfo when > constants differs but their binfos match (so when method is called with > multiple static instances of the same object we will get devirtualization). I > don't see ipa-cp doing that. Well, the problem with that of course is that we do not merge stuff now, we accumulate all possible constants. So what we perhaps should do instead is (if ipcp_param_lattices->virt_call is true) to try to see if a number of ADDR_EXPR constants yield the same binfo and if so, consider that new value first, before any real constants.