On 10/22/2015 04:19 PM, Nick Clifton wrote:
It is in cfgrtl.c:fixup_reorder_chain()
nb = split_edge (e);
if (!INSN_P (BB_END (nb)))
BB_END (nb) = emit_insn_after_noloc (gen_nop (), BB_END (nb),
nb);
INSN_LOCATION (BB_END (nb)) = e->goto_locus;
That looks rather intentional. That code seems to be trying to make sure
that we can set a breakpoint anywhere we want by ensuring that an
instruction with the right location exists.
What's happening is that we enter with an edge
$6 = <edge 0x7ffff0730818 (13 -> 15)>
which has a corresponding goto_locus
$17 = {file = 0x7fffffffdd96 "loop-break.c", line = 34, column = 16,
data = 0x7ffff0840420, sysp = false}
which we compare to the location for the jump insn at the end, which is
however
$15 = {file = 0x7fffffffdd96 "loop-break.c", line = 34, column = 8,
data = 0x7ffff0840420, sysp = false}
Further investigation shows that we have enter expand_gimple_cond, which
calls set_curr_insn_location with the location of the condition (i.e.
$15), and all insns created by ix86_expand_branch get that location.
There is code in expand_gimple_cond to switch locations around, but at
that point true_edge->goto_locus and false_edge->goto_locus are equal,
and contain something different.
So I'm not entirely sure yet what's supposed to happen here, but I think
the problem could well be in the expansion phase. The proposed patch
can't be right, because the nop in question is apparently only generated
for the purpose of holding a location.
Bernd
