[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]

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. ]