http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61058
Jeffrey A. Law <law at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2014-05-05
Ever confirmed|0 |1
--- Comment #3 from Jeffrey A. Law <law at redhat dot com> ---
What do you need me to confirm? I can confirm that you're not supposed to have
BARRIERS in the middle of a block.
THe RTL in question:
.file "j.c"
.text
.globl foo
.type foo, @function
foo:
pushq %rbp
(note 1 0 3 NOTE_INSN_DELETED)
(note 3 1 9 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(insn/f 9 3 10 2 (set (mem:DI (pre_dec:DI (reg/f:DI 7 sp)) [0 S8 A8])
(reg/f:DI 6 bp)) j.c:2 65 {*pushdi2_rex64}
(nil))
(insn/f 10 9 5 2 (set (reg/f:DI 6 bp)
(reg/f:DI 7 sp)) j.c:2 89 {*movdi_internal}
(nil))
(barrier 5 10 11)
(note 11 5 2 2 NOTE_INSN_PROLOGUE_END)
(note 2 11 8 2 NOTE_INSN_FUNCTION_BEG)
(note 8 2 0 NOTE_INSN_DELETED)
We're in distance_agu_use_in_bb. We're passing it insn 10 as INSN and the
BARRIER as START. We try to look at BLOCK_FOR_INSN (start), after that, we're
well into undefined territory.
But this really looks like x86 backend breakage. Refer to the above RTL and
look at this call site:
17976 if (insn != BB_END (bb))
17977 distance = distance_agu_use_in_bb (regno0, insn, distance,
17978 NEXT_INSN (insn),
17979 &found, &redefined);
Clearly if NEXT_INSN (insn) is a BARRIER, then nothing good can happen.
