[Bug tree-optimization/59919] [4.9 Regression] ICE in process_assert_insertions_for, at tree-vrp.c:6096

[law at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59919

Jeffrey A. Law <law at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |law at redhat dot com

--- Comment #5 from Jeffrey A. Law <law at redhat dot com> ---
The problem here is we have a call to a non-returning function.  The caller
also calls setjmp.

This ultimately results in something like this prior to vrp:

;;   basic block 2, loop depth 0, count 0, freq 10000, maybe hot
;;    prev block 0, next block 3, flags: (NEW, REACHABLE)
;;    pred:       ENTRY [100.0%]  (FALLTHRU,EXECUTABLE)
  bar (p_3(D));
;;    succ:       3 [100.0%]  (ABNORMAL,EXECUTABLE)

;;   basic block 3, loop depth 0, count 0, freq 10000, maybe hot
;;   Invalid sum of incoming frequencies 15000, should be 10000
;;    prev block 2, next block 4, flags: (NEW, REACHABLE, IRREDUCIBLE_LOOP)
;;    pred:       2 [100.0%]  (ABNORMAL,EXECUTABLE)
;;                3 [50.0%]  (ABNORMAL,DFS_BACK,IRREDUCIBLE_LOOP,EXECUTABLE)
  setjmp (_4(D));
  _6 = &p_3(D)->i;
  foo (_6);
;;    succ:       3 [50.0%]  (ABNORMAL,DFS_BACK,IRREDUCIBLE_LOOP,EXECUTABLE)
;;                4 [50.0%]  (FALLTHRU,EXECUTABLE)

;;   basic block 4, loop depth 0, count 0, freq 5000, maybe hot
;;    prev block 3, next block 1, flags: (NEW, REACHABLE)
;;    pred:       3 [50.0%]  (FALLTHRU,EXECUTABLE)
  return;


Note that because "bar" is non-returning there is no normal outgoing edge from
BB2.  There is an abnormal edge because our CFG code isn't flow sensitive. 
Either way we have a single outgoing edge from BB2 that is abnormal.

We want to insert an assertion because of the non-null attribute.  But
process_edge_insertions_for never contemplated this particular situation and we
hit the gcc_unreachable.

Creating an ASSERT_EXPR here is wasteful and preventing that is one potential
solution.   Another is to have process_edge_insertions_for not trigger
gcc_unreachable here as it should be safe to just return false for this case.  
 I'll play a bit with both.