From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-416252-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 26470 invoked by alias); 26 Feb 2013 00:32:33 -0000
Received: (qmail 26427 invoked by uid 48); 26 Feb 2013 00:32:09 -0000
From: "kkojima at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/56451] [4.8 regression] Wrong code for gcc.c-torture/execute/941015-1.c on SH
Date: Tue, 26 Feb 2013 00:32:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: kkojima at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields:
Message-ID: <bug-56451-4-y9ITZwm2sB@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-56451-4@http.gcc.gnu.org/bugzilla/>
References: <bug-56451-4@http.gcc.gnu.org/bugzilla/>
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: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
X-SW-Source: 2013-02/txt/msg02417.txt.bz2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56451

--- Comment #1 from Kazumoto Kojima <kkojima at gcc dot gnu.org> 2013-02-26 00:32:07 UTC ---
Before dbr_schedule, the insns look like:

    r1 := 0xc0000000
(A)    if (r5 > r1) goto L0
(B)    if (r5 < r1) goto L1
    r1 := 0x80000000
(C)    if (r4 >= r1) goto L0
L1:    r0 := 1
    goto L2
L0:    r0 := 2
L2:

On SH, insns (A),(B),(C) can have delayed slot. dbr_schedule fills
a slot of (A) first:

    r1 := 0xc0000000
(A)    [if (r5 > r1) goto L2 | r0 := 2]
(B)    if (r5 < r1) goto L1
    r1 := 0x80000000
(C)    if (r4 >= r1) goto L0
L1:    r0 := 1
    goto L2
L0:    r0 := 2
L2:

Curiously, in the problematic case, dbr_schedule tries (C) next and
redundant_insn checks that r0 := 2 is whether redundant or not with
scanning insns backward from (C).  It finds the insn in the slot of
(A) and deletes the insn r0 := 2 at L0 as an unnecessary one.

    r1 := 0xc0000000
(A)    [if (r5 > r1) goto L2 | r0 := 2]
(B)    if (r5 < r1) goto L1
    r1 := 0x80000000
(C)    if (r4 >= r1) goto L0
L1:    r0 := 1
    goto L2
L0:
L2:

Then dbr_schedule fills the slot of (B):

    r1 := 0xc0000000
(A)    [if (r5 > r1) goto L2 | r0 := 2]
(B)    [if (r5 < r1) goto L2 | r0 := 1]
    r1 := 0x80000000
(C)    if (r4 >= r1) goto L0
L1:    r0 := 1
    goto L2
L0:
L2:

Now (C) and r0 := 1 at L1 are useless because r0 is 1 before (C).
It seems to me that the above is an unexpected scenario to redundant_insn,
i.e. dbr_schedule uses it unsafely somewhere, though I gave up to find
where problematic use occurs.  An easy patch below might be a bit
overkill but it fixes the problem for me.

--- ORIG/trunk/gcc/reorg.c    2013-01-11 11:35:58.000000000 +0900
+++ trunk/gcc/reorg.c    2013-02-25 17:17:34.000000000 +0900
@@ -1514,7 +1514,7 @@ redundant_insn (rtx insn, rtx target, rt
        trial && insns_to_search > 0;
        trial = PREV_INSN (trial))
     {
-      if (LABEL_P (trial))
+      if (LABEL_P (trial) || JUMP_P (trial))
     return 0;

       if (!INSN_P (trial))