From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18774 invoked by alias); 14 Jul 2014 09:48:51 -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 18666 invoked by uid 48); 14 Jul 2014 09:48:43 -0000 From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/61757] [4.10 Regression] genmodes failure with enable-checking Date: Mon, 14 Jul 2014 09:48: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-Version: 4.10.0 X-Bugzilla-Keywords: build X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: REOPENED X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.10.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc 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-07/txt/msg00856.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |law at gcc dot gnu.org --- Comment #26 from Richard Biener --- DOM first rotates the loop by threading the entry over the first part of the conditional, producing if (i + 1 < n && q == a[i + 1].p) { ++i; do { if (q != a[i].p) break; ++i; if (i >= n) break; } while (1); the 2nd DOM pass then tries to complete the rotate but manages to record two threadings that are incompatible: Threaded jump 6 --> 12 to 13 Jump threading proved probability of edge 12->4 too small (it is 5114, should be 10000). Threaded jump 7 --> 12 to 14 the 2nd one over the loop entry would be ok, completing the rotate. But the first one is odd - and I can't see why we register it: Optimizing block #6 1>>> COND 1 = n_4(D) ge_expr i_12 1>>> COND 1 = n_4(D) ne_expr i_12 1>>> COND 1 = n_4(D) gt_expr i_12 1>>> COND 0 = n_4(D) le_expr i_12 Optimizing statement pretmp_11 = a[i_12].p; LKUP STMT pretmp_11 = a[i_12].p pretmp_11 = a[i_12].p; 2>>> STMT pretmp_11 = a[i_12].p pretmp_11 = a[i_12].p; Registering jump thread: (6, 12) incoming edge; (12, 4) normal; <<<< STMT pretmp_11 = a[i_12].p pretmp_11 = a[i_12].p; <<<< COND 0 = n_4(D) le_expr i_12 <<<< COND 1 = n_4(D) gt_expr i_12 <<<< COND 1 = n_4(D) ne_expr i_12 <<<< COND 1 = n_4(D) ge_expr i_12 bb6 is just : pretmp_11 = a[i_12].p; and its single predecessor : i_12 = i_9 + 1; if (n_4(D) > i_12) goto ; else goto ; with the record_equality change we now record q_8(D) == prephitmp_16 instead of the other way around: Optimizing block #4 0>>> COPY q_8(D) = prephitmp_16 1>>> COND 1 = q_8(D) le_expr prephitmp_16 1>>> COND 1 = q_8(D) ge_expr prephitmp_16 1>>> COND 1 = q_8(D) eq_expr prephitmp_16 1>>> COND 0 = q_8(D) ne_expr prephitmp_16 but when threading over the backedge this doesn't get invalidated. So this canonicalization happens to be a correctness issue (by accident? Jeff?)