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.


  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: 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).