From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16407 invoked by alias); 20 Jul 2011 22:04:18 -0000 Received: (qmail 16399 invoked by uid 22791); 20 Jul 2011 22:04:18 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 20 Jul 2011 22:04:04 +0000 From: "ian at airs dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug bootstrap/49786] [4.7 Regression] bootstrap failed with bootstrap-profiled X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: bootstrap X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: ian at airs dot com X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: jamborm at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.7.0 X-Bugzilla-Changed-Fields: Status Last reconfirmed AssignedTo Ever Confirmed 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 Date: Wed, 20 Jul 2011 22:04:00 -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 X-SW-Source: 2011-07/txt/msg01707.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49786 Ian Lance Taylor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |ASSIGNED Last reconfirmed| |2011.07.20 22:03:04 AssignedTo|unassigned at gcc dot |jamborm at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #12 from Ian Lance Taylor 2011-07-20 22:03:04 UTC --- I was able to recreate the problem. The count is going negative at line 1926 of ipa-cp.c, the first line setting cs->count here: for (cs = new_node->callees; cs ; cs = cs->next_callee) if (cs->frequency) cs->count = cs->count * new_sum / orig_node_count; else cs->count = 0; In the test case, cs->count, new_sum, and orig_node_count all == 3870557758. Computing 3870557758 * 3870557758 overflows to a negative number. Dividing by 3870557758 leaves the number still negative. This then leads to the failure. For reference, profile_info->sum_max == 2619109064700. I don't know if these numbers are plausible. I think that this code probably needs to be written along the lines of scale_bbs_frequencies_gcov_type. I will leave this for Martin.