public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "aldyh at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/103226] [12 Regression] Recent change to copy-headers causes execution failure for gcc.dg/torture/pr80974
Date: Thu, 18 Nov 2021 13:28:02 +0000	[thread overview]
Message-ID: <bug-103226-4-geenISmYqU@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-103226-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226

--- Comment #19 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
This looks like a target or RTL problem.

The .optimized dumps between x86-64 and bfin-elf look the same for:

-O2 -fno-tree-vrp -fno-tree-vectorize -fno-thread-jumps -fno-ivopts
-fno-tree-pre -fdisable-tree-pre -fdisable-tree-cunrolli -fdisable-tree-cunroll
-fdisable-tree-ivcanon 

and yet bfin-elf hangs.

The problem is this loop:

       e = !f && (n = 5);
       if (e)
         for (h = 0; h < 9; h++)
           for (i = 0; i < 6; i++)
             if (a)
               g[h] = 4;

The register holding &g[h] overflows past the end and writes 4 to f, causing an
infinite loop.

Ultimately this boils down to:

        cc = (a == 0)
<snip>
<snip>
        R1 = 4 (X);
        P5 = 9 (X);
        LSETUP (.L5, .L25) LC1 = P5;
.L5:
        P2 = I0;                ;; p2 = &g
        P0 = P2 + (P4 << 2);    ;; p0 = &g[h]
        P2 = 6 (X);             ;; i = 6
.L7:
        if cc jump .L6 (bp);    ;; <<<< BOO HISS!!!!! <<<<<
        [P0] = R1;              ;; *(p0) = 4
.L6:
        P2 += -1;               ;; i--
        cc =P2==0;
        if !cc jump .L7;        ;; if (i==0) goto .L7
.L25:
        P4 += 1;

The first time we check CC, it's the a==0 gate skipping the write to g[h]. 
Then we overwrite CC with the inner loop latch (i==0) and jump back to L7 where
the check against CC is no longer related to "a", and false.  So we overrwrite
[P0] with 4.  This write is incorrect, but it's the eventual overflow of P0
into &f that causes a write to 4, and an infinite loop because if(e) will
always be false.

My RTL knowledge is very old and probably incorrect, but by *.alignments we
have:

;; THIS IS A CHECK FOR if(a)
(code_label 41 143 29 8 7 (nil) [1 uses])
(jump_insn 31 29 32 8 (set (pc)
        (if_then_else (ne (reg:BI 34 CC [89])
                (const_int 0 [0]))
            (label_ref:SI 38)
            (pc))) "j.c":19:10 124 {cbranchbi4}
     (int_list:REG_BR_PROB 536870916 (nil))
 -> 38)

<snip>
<snip>

;; HERE WE SET PC BUT DONT CLOBBER CC
(code_label 38 37 39 10 6 (nil) [1 uses])
(note 39 38 142 10 [bb 10] NOTE_INSN_BASIC_BLOCK)
(jump_insn 142 39 46 10 (parallel [
            (set (pc)
                (if_then_else (ne (reg:SI 10 P2 [98])
                        (const_int 1 [0x1]))
                    (label_ref:SI 41)
                    (pc)))
            (set (reg:SI 10 P2 [98])
                (plus:SI (reg:SI 10 P2 [98])
                    (const_int -1 [0xffffffffffffffff])))
            (unspec [
                    (const_int 0 [0])
                ] 10)
            (clobber (scratch:SI))
        ]) "j.c":18:19 96 {loop_end}
     (int_list:REG_BR_PROB 920304124 (nil))
 -> 41)

And in the *.reorg pass we clobber the CC and end up with the problematic
sequence:

(code_label 41 143 29 8 7 (nil) [1 uses])

(note 29 41 31 8 [bb 8] NOTE_INSN_BASIC_BLOCK)

(jump_insn:TI 31 29 32 8 (set (pc)
        (if_then_else (ne (reg:BI 34 CC [89])
                (const_int 0 [0]))
            (label_ref:SI 38)
            (pc))) "j.c":19:10 124 {cbranchbi4}
     (int_list:REG_BR_PROB 536870916 (nil))
 -> 38)

(note 32 31 37 9 [bb 9] NOTE_INSN_BASIC_BLOCK)

(insn:TI 37 32 38 9 (set (mem:SI (reg/f:SI 8 P0 [92]) [1 g[h_33]+0 S4 A32])
        (reg:SI 1 R1 [93])) "j.c":20:14 19 {*movsi_insn}
     (nil))

(code_label 38 37 39 10 6 (nil) [1 uses])

(note 39 38 218 10 [bb 10] NOTE_INSN_BASIC_BLOCK)

(insn 218 39 219 10 (set (reg:SI 10 P2 [98])
        (plus:SI (reg:SI 10 P2 [98])
            (const_int -1 [0xffffffffffffffff]))) "j.c":18:19 50 {addsi3}
     (nil))

(insn 219 218 220 10 (set (reg:BI 34 CC)
        (eq:BI (reg:SI 10 P2 [98])
            (const_int 0 [0]))) "j.c":18:19 118 {compare_eq}
     (nil))

(jump_insn 220 219 46 10 (set (pc)
        (if_then_else (eq (reg:BI 34 CC)
                (const_int 0 [0]))
            (label_ref 41)
            (pc))) "j.c":18:19 124 {cbranchbi4}
     (nil)
 -> 41)

  parent reply	other threads:[~2021-11-18 13:28 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-13 20:39 [Bug tree-optimization/103226] New: " law at gcc dot gnu.org
2021-11-14 10:59 ` [Bug tree-optimization/103226] " aldyh at gcc dot gnu.org
2021-11-15  9:03 ` rguenth at gcc dot gnu.org
2021-11-16  2:30 ` law at gcc dot gnu.org
2021-11-17 11:14 ` aldyh at gcc dot gnu.org
2021-11-17 11:32 ` aldyh at gcc dot gnu.org
2021-11-17 15:00 ` tnfchris at gcc dot gnu.org
2021-11-17 15:02 ` tnfchris at gcc dot gnu.org
2021-11-17 15:53 ` aldyh at gcc dot gnu.org
2021-11-17 16:09 ` tnfchris at gcc dot gnu.org
2021-11-17 16:28 ` law at gcc dot gnu.org
2021-11-17 16:29 ` law at gcc dot gnu.org
2021-11-17 16:31 ` aldyh at gcc dot gnu.org
2021-11-17 17:18 ` aldyh at gcc dot gnu.org
2021-11-17 17:54 ` tnfchris at gcc dot gnu.org
2021-11-17 18:31 ` law at gcc dot gnu.org
2021-11-17 18:43 ` aldyh at gcc dot gnu.org
2021-11-17 19:26 ` aldyh at gcc dot gnu.org
2021-11-17 20:02 ` aldyh at gcc dot gnu.org
2021-11-18 13:28 ` aldyh at gcc dot gnu.org [this message]
2021-11-20  7:10 ` law at gcc dot gnu.org
2021-11-20  7:23 ` aldyh at gcc dot gnu.org
2021-11-20 16:30 ` cvs-commit at gcc dot gnu.org
2021-11-20 16:31 ` law at gcc dot gnu.org
2021-12-02 14:55 ` hp at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-103226-4-geenISmYqU@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).