[Bug middle-end/81897] [6/7 Regression] spurious -Wmaybe-uninitialized warning

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81897

--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The problem is in the:
@@ -671,11 +669,9 @@
          e = one_cd_chain[j];
          guard_bb = e->src;
          gsi = gsi_last_bb (guard_bb);
-         if (gsi_end_p (gsi))
-           {
-             has_valid_pred = false;
-             break;
-           }
+         /* Ignore empty BBs as they're basically forwarder blocks.  */
+         if (empty_block_p (guard_bb) && single_succ_p (guard_bb))
+           continue;
          cond_stmt = gsi_stmt (gsi);
          if (is_gimple_call (cond_stmt) && EDGE_COUNT (e->src->succs) >= 2)
            /* Ignore EH edge.  Can add assertion on the other edge's flag.  */

hunk.  When guard_bb is a bb that contains one or more PHIs, but no other
statements, then gsi_stmt (gsi) returns NULL and is_gimple_call will ICE on it.
So, something like:
--- gcc/tree-ssa-uninit.c.jj    2018-01-07 20:28:14.894731685 +0100
+++ gcc/tree-ssa-uninit.c       2018-01-08 09:48:11.327325457 +0100
@@ -672,6 +672,11 @@ convert_control_dep_chain_into_preds (ve
          /* Ignore empty BBs as they're basically forwarder blocks.  */
          if (empty_block_p (guard_bb) && single_succ_p (guard_bb))
            continue;
+         if (gsi_end_p (gsi))
+           {
+             has_valid_pred = false;
+             break;
+           }
          cond_stmt = gsi_stmt (gsi);
          if (is_gimple_call (cond_stmt) && EDGE_COUNT (e->src->succs) >= 2)
            /* Ignore EH edge.  Can add assertion on the other edge's flag.  */
ought to fix it.  Also note that for -fcompare-debug, the guard_bb could
contain just one or more PHIs and one or more debug stmts and nothing else, in
that case gsi_last_bb returns an iterator with the debug stmt, so cond_stmt
will be a DEBUG_STMT etc. in current code and will do has_valid_pred = false;
break;
PHIs have non-trivial effect though, so not really sure we can ignore them, but
I could be wrong.  If we ignore them, we'd need to use gsi_last_nondebug_bb
though.