public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "vries at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/51271] ICE in in maybe_record_trace_start, at dwarf2cfi.c:2244 Date: Wed, 23 Nov 2011 14:12:00 -0000 [thread overview] Message-ID: <bug-51271-4-2GlQLUppdn@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-51271-4@http.gcc.gnu.org/bugzilla/> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51271 --- Comment #7 from vries at gcc dot gnu.org 2011-11-23 13:35:13 UTC --- triggering assert: gcc_checking_assert (cfi_row_equal_p (cur_row, ti->beg_row)); relevant values: ... (gdb) call debug_cfi_row (cur_row) .cfi_def_cfa 29, 16 (gdb) call debug_cfi_row (ti->beg_row) .cfi_def_cfa 29, 16 .cfi_offset 28, -8 ... The cur_row is the state belonging to the current transition, which is 'saw edge from trace 2 to 3 (via fallthru 0)' meaning the fallthru from bb 7 to bb 8. The ti->beg_row is the state at the start of trace 3, which was generated by 'saw edge from trace 1 to 3 (via jump_insn 156)' meaning the jump from block 5 to block 8. So we've got: ... block 7 -> block 8 .cfi_def_cfa 29, 16 block 5 -> block 8 .cfi_def_cfa 29, 16 .cfi_offset 28, -8 ... This difference seems related to epilogue insn 141: ... (insn 141 155 142 (set (reg:DI 28 $28) (mem/c:DI (plus:SI (reg/f:SI 29 $sp) (const_int 8 [0x8])) [4 S8 A64])) res_hconf.c:11 278 {*movdi_64bit} (nil)) ... Insn 141 is copied by pass_mach (probably by dbr_schedule) to: - the delay slot of jump_insn 63 in bb 4, and to - the delay slot of jump_insn 75 in bb 6. jump_insn 63 is an annuling jump (jump_insn/u) and insn 141 is only executed then the branch is taken (insn/s), so it does not disturb the fallthru path. ... (insn 177 62 65 (sequence [ (jump_insn/u 63 62 141 (set (pc) (if_then_else (eq (reg:SI 4 $4 [orig:242 D.2240 ] [242]) (reg:SI 3 $3 [256])) (label_ref:SI 176) (pc))) res_hconf.c:8 434 {*branch_equalitysi} (expr_list:REG_BR_PRED (const_int 48 [0x30]) (expr_list:REG_DEAD (reg:SI 4 $4 [orig:242 D.2240 ] [242]) (expr_list:REG_DEAD (reg:SI 3 $3 [256]) (expr_list:REG_EQUAL (if_then_else (eq (reg:SI 4 $4 [orig:242 D.2240 ] [242]) (const_int 44 [0x2c])) (label_ref:SI 176) (pc)) (expr_list:REG_BR_PROB (const_int 300 [0x12c]) (nil)))))) -> 176) (insn/s 141 63 65 (set (reg:DI 28 $28) (mem/c:DI (plus:SI (reg/f:SI 29 $sp) (const_int 8 [0x8])) [4 S8 A64])) 278 {*movdi_64bit} (nil)) ]) res_hconf.c:8 -1 (nil)) ... jump_insn 75 is an normal jump and insn 141 is executed on either branch or fallthru path. ... (insn 178 74 76 (sequence [ (jump_insn 75 74 141 (set (pc) (if_then_else (eq (reg:SI 4 $4 [orig:259 *D.2245_8 ] [259]) (const_int 0 [0])) (label_ref:SI 176) (pc))) res_hconf.c:7 434 {*branch_equalitysi} (expr_list:REG_BR_PRED (const_int 48 [0x30]) (expr_list:REG_DEAD (reg:SI 4 $4 [orig:259 *D.2245_8 ] [259]) (expr_list:REG_BR_PROB (const_int 300 [0x12c]) (nil)))) -> 176) (insn 141 75 76 (set (reg:DI 28 $28) (mem/c:DI (plus:SI (reg/f:SI 29 $sp) (const_int 8 [0x8])) [4 S8 A64])) 278 {*movdi_64bit} (nil)) ]) res_hconf.c:7 -1 (nil)) ... The execution of insn 141 in bb 6 on the fallthru path causes the difference in cfa state at the entry of bb8, which causes the assert. Disregarding cfa info, the branch delay scheduling looks correct to me. I guess we need analyze why the epilogue insn is not handled more conservative by branch delay scheduling, and fix that.
next prev parent reply other threads:[~2011-11-23 13:35 UTC|newest] Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-11-22 15:51 [Bug rtl-optimization/51271] New: " vries at gcc dot gnu.org 2011-11-23 2:13 ` [Bug rtl-optimization/51271] " vries at gcc dot gnu.org 2011-11-23 2:26 ` pinskia at gcc dot gnu.org 2011-11-23 11:43 ` vries at gcc dot gnu.org 2011-11-23 11:46 ` vries at gcc dot gnu.org 2011-11-23 12:05 ` vries at gcc dot gnu.org 2011-11-23 12:15 ` vries at gcc dot gnu.org 2011-11-23 14:12 ` vries at gcc dot gnu.org [this message] 2011-11-28 9:14 ` gcc@Denis-Excoffier.org 2011-11-28 9:25 ` gcc@Denis-Excoffier.org 2011-11-30 12:52 ` vries at gcc dot gnu.org 2011-11-30 16:48 ` vries at gcc dot gnu.org 2011-11-30 20:47 ` gcc@Denis-Excoffier.org 2011-12-15 0:05 ` pinskia at gcc dot gnu.org 2011-12-15 0:07 ` [Bug rtl-optimization/51271] [4.7 Regression] " pinskia at gcc dot gnu.org 2011-12-17 13:21 ` vries at gcc dot gnu.org 2011-12-19 13:24 ` vries at gcc dot gnu.org 2012-01-04 13:37 ` rguenth at gcc dot gnu.org 2012-01-08 14:13 ` vries at gcc dot gnu.org 2012-01-10 8:51 ` vries at gcc dot gnu.org 2012-01-10 8:54 ` vries 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-51271-4-2GlQLUppdn@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: linkBe 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).