[Bug gcov-profile/81442] New: error: verify_flow_info: REG_BR_PROB is set but cfg probability is not during RTL pass: outof_cfglayout
vries at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Fri Jul 14 09:11:00 GMT 2017
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81442
Bug ID: 81442
Summary: error: verify_flow_info: REG_BR_PROB is set but cfg
probability is not during RTL pass: outof_cfglayout
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
I.
At r250114, I run into the following ICE in
libgomp.oacc-c-c++-common/reduction-5.c:
...
libgomp/testsuite/libgomp.oacc-c/../libgomp.oacc-c-c++-common/reduction-5.c: In
function 'main._omp_fn.2':
libgomp/testsuite/libgomp.oacc-c/../libgomp.oacc-c-c++-common/reduction-5.c:52:9:
error: verify_flow_info: REG_BR_PROB is set but cfg probability is not
during RTL pass: outof_cfglayout
libgomp/testsuite/libgomp.oacc-c/../libgomp.oacc-c-c++-common/reduction-5.c:52:9:
internal compiler error: verify_flow_info failed
0x6511e9 verify_flow_info()
gcc/cfghooks.c:259
0x66b0c5 execute
gcc/cfgrtl.c:3581
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
...
This is with an x86_64 compiler with nvptx accelerator, in lto1 when compiling
for the nvptx target.
The error occurs during the call to checking_verify_flow_info at the end of
cfg_layout_finalize.
The jump_insn that is complained about is the last insn of bb2:
...
(jump_insn 18 17 32 2 (set (pc)
(if_then_else (eq (reg:BI 83)
(const_int 0 [0]))
(label_ref:DI 33)
(pc))) "reduction-5.c":52 105 {br_false}
(expr_list:REG_DEAD (reg:BI 83)
(int_list:REG_BR_PROB 0 (nil)))
-> 33)
...
The two edges are to bbs 3 and 4:
...
(gdb) p
cfun->cfg->x_basic_block_info.m_vecdata[2].succs.m_vecdata[0].dest.index
$31 = 3
(gdb) p
cfun->cfg->x_basic_block_info.m_vecdata[2].succs.m_vecdata[1].dest.index
$32 = 4
...
With these probabilities:
...
(gdb) p
cfun->cfg->x_basic_block_info.m_vecdata[2].succs.m_vecdata[0].probability
$28 = {static n_bits = 30, static max_probability = 10000, static
uninitialized_probability = 1073741823,
m_val = 10000, m_quality = profile_precise}
(gdb) p
cfun->cfg->x_basic_block_info.m_vecdata[2].succs.m_vecdata[1].probability
$29 = {static n_bits = 30, static max_probability = 10000, static
uninitialized_probability = 1073741823,
m_val = 1073741823, m_quality = profile_guessed}
...
The branch edge is to bb4, because bb4 is the one starting with:
...
(gdb) call debug_bb_n (4)
(code_label 33 5 34 4 25 (nil) [1 uses])
(note 34 33 35 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
...
So:
- the fallthru edge to bb3 has probability 10000.
- the branch edge to bb 4 has uninitialized probability
- the REG_BR_PROB 0 claims the branch edge has probability 0.
The assert happens because of the difference between the last two.
II.
Before fixup_reorder_chain in cfg_layout_finalize, we have:
...
(jump_insn 18 17 31 2 (set (pc)
(if_then_else (ne (reg:BI 83)
(const_int 0 [0]))
(label_ref 31)
(pc))) "reduction-5.c":52 104 {br_true}
(expr_list:REG_DEAD (reg:BI 83)
(int_list:REG_BR_PROB 10000 (nil)))
-> 31)
...
So, the jump condition is the inverse, as is the REG_BR_PROB.
The branch edge is to bb3, is the one starting with:
...
(gdb) call debug_bb_n(3)
(code_label 31 18 32 3 24 (nil) [1 uses])
(note 32 31 4 3 [bb 3] NOTE_INSN_BASIC_BLOCK)
...
So that is also inverted
The edge destinations are the same:
...
$39 = (basic_block_def *) 0x7ffff749b068
(gdb) p
cfun->cfg->x_basic_block_info.m_vecdata[2].succs.m_vecdata[0].dest.index
$40 = 3
(gdb) p
cfun->cfg->x_basic_block_info.m_vecdata[2].succs.m_vecdata[1].dest.index
$41 = 4
...
As are the edge probabilities:
...
(gdb) p
cfun->cfg->x_basic_block_info.m_vecdata[2].succs.m_vecdata[0].probability
$42 = {static n_bits = 30, static max_probability = 10000, static
uninitialized_probability = 1073741823,
m_val = 10000, m_quality = profile_precise}
(gdb) p
cfun->cfg->x_basic_block_info.m_vecdata[2].succs.m_vecdata[1].probability
$43 = {static n_bits = 30, static max_probability = 10000, static
uninitialized_probability = 1073741823,
m_val = 1073741823, m_quality = profile_guessed}
...
So here we have:
- the fallthru edge is to bb4, which has uninitialized probability.
- the branch edge to bb 3, which has probability 10000
- the REG_BR_PROB 10000 claims the branch edge has probability 10000.
In this case, the last two are in agreement.
III.
This bit in fixup_reorder_chain does the jump inversion:
...
/* Otherwise we can try to invert the jump. This will
basically never fail, however, keep up the pretense. */
else if (invert_jump (bb_end_jump,
(e_fall->dest
== EXIT_BLOCK_PTR_FOR_FN (cfun)
? NULL_RTX
: label_for_bb (e_fall->dest)), 0))
{
e_fall->flags &= ~EDGE_FALLTHRU;
gcc_checking_assert (could_fall_through
(e_taken->src, e_taken->dest));
e_taken->flags |= EDGE_FALLTHRU;
update_br_prob_note (bb);
if (LABEL_NUSES (ret_label) == 0
&& single_pred_p (e_taken->dest))
delete_insn (as_a<rtx_insn *> (ret_label));
continue;
}
...
[ We see that update_br_prob_note is called, but that has no effect. The
inversion of the note is already done by invert_jump, during
invert_br_probabilities is called. ]
More information about the Gcc-bugs
mailing list