[Bug tree-optimization/47679] [4.8/4.9/5 Regression] Strange uninitialized warning after SRA

[law at redhat dot com]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |law at redhat dot com

--- Comment #17 from Jeffrey A. Law <law at redhat dot com> ---
Couldn't this be seen as a failure to thread jumps?  In the rs676361 testcase
we have the following relevant blocks after DOM2:

;;   basic block 2, loop depth 0
;;    pred:       ENTRY
  aOldItem = getitem (); [return slot optimization]
  aNewItem_19 = 0;
  _9 = MEM[(bool *)this_4(D)];
  if (_9 != 0)
    goto <bb 3>;
  else
    goto <bb 4>;
;;    succ:       3
;;                4

;;   basic block 3, loop depth 0
;;    pred:       2
  aNewItem$8_22 = MEM[(const long unsigned int &)this_4(D) + 8];
  aNewItem$8_20 = aNewItem$8_22;
  aNewItem_21 = 1;
;;    succ:       4

;;   basic block 4, loop depth 0
;;    pred:       3
;;                2
  # aNewItem_24 = PHI <1(3), 0(2)>
  # aNewItem$8_23 = PHI <aNewItem$8_22(3), aNewItem$8_6(D)(2)>
  _5 = MEM[(bool *)&aOldItem];
  _10 = ~_5;
  _11 = VIEW_CONVERT_EXPR<const bool>(aNewItem_24);
  _12 = ~_11;
  if (_10 == _12)
    goto <bb 5>;
  else
    goto <bb 7>;
;;    succ:       5
;;                7

;;   basic block 5, loop depth 0
;;    pred:       4
  if (_10 != 0)
    goto <bb 7>;
  else
    goto <bb 6>;
;;    succ:       7
;;                6

;;   basic block 6, loop depth 0
;;    pred:       5
  _13 = MEM[(const long unsigned int &)&aOldItem + 8];
  aNewItem$8_14 = aNewItem$8_23;
  iftmp.4_15 = _13 == aNewItem$8_23;
  _16 = ~iftmp.4_15;
  _17 = (int) _16;
;;    succ:       7


The key here is that we know the value of _12 depending on how we reach block
#4.  If BB4 then transfers control to block #5 we'll also know the value of _10
which would allow us to thread jumps and I believe simplifies things enough to
avoid the false positive, at least on the reduced case.  I haven't tried case
from Sergey yet.

This appears to be caused by a few deficiencies in jump threading.  None appear
to be major issues though.