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

Aldy Hernandez <aldyh at gcc dot gnu.org> changed:

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

--- Comment #1 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
We should've elided the call to foo() in the 8->3 edge.  This is the IL in
vrp-thread1 dump:

int main ()
{
  int h;
  int g;
  int _3;
  _Bool _5;
  int _6;
  char iftmp.4_11;
  int _12;
  int _19;
  int _21;
  char iftmp.4_22;
  int d.0_25;
  _Bool _26;
  int _27;
  int c.2_28;
  char _29;
  int _30;
  int _42;
  char iftmp.4_43;
  int _48;
  int _50;
  _Bool _53;
  int _56;
  int _59;
  char iftmp.4_60;
  int _62;

  <bb 2> [local count: 134197598]:
  c = 2;
  goto <bb 5>; [100.00%]

  <bb 3> [local count: 88583700]:
  foo ();

  <bb 4> [local count: 268435457]:
  g_18 = g_10 + 1;

  <bb 5> [local count: 402633054]:
  # g_10 = PHI <0(2), g_18(4)>
  if (g_10 != 2)
    goto <bb 6>; [66.67%]
  else
    goto <bb 9>; [33.33%]

  <bb 6> [local count: 268435456]:
  d.0_25 = d;
  _26 = d.0_25 == 0;
  _27 = (int) _26;
  c.2_28 = c;
  _29 = (char) c.2_28;
  _30 = (int) _29;
  if (_29 >= 0)
    goto <bb 8>; [59.00%]
  else
    goto <bb 7>; [41.00%]

  <bb 7> [local count: 110058536]:
  # iftmp.4_11 = PHI <_29(6)>
  _12 = (int) iftmp.4_11;
  d = _12;
  _48 = (int) _29;
  d = _48;
  _19 = (int) _29;
  d = _19;
  goto <bb 4>; [100.00%]

  <bb 8> [local count: 158376920]:
  _42 = _30 >> _27;
  iftmp.4_43 = (char) _42;
  _50 = _42;
  d = _50;
  _53 = _50 == 0;
  _56 = (int) _53;
  _21 = _30 >> _56;
  iftmp.4_22 = (char) _21;
  _3 = _21;
  d = _3;
  _5 = _3 == 0;
  _6 = (int) _5;
  _59 = _30 >> _6;
  iftmp.4_60 = (char) _59;
  _62 = _59;
  d = _62;
  if (_62 == 0)
    goto <bb 3>; [66.33%]
  else
    goto <bb 4>; [33.67%]

  <bb 9> [local count: 134197598]:
  return 0;

}

So, presumably _62 == 0 cannot be true.  If _62 == 0, then

    0 = _30 >> _6;

But that cannot happen because _30 is 2 if you follow the series of copies from
the "c" global.

There is no way 0 = 2 >> x can ever be true.

There's probably a couple things missing here.  Maybe
operator_rshift::op1_range needs to be taught that ~[0,0] = x >> y implies x is
non-zero.  But also, we can't see through the load from the c=2 global. 
Shouldn't that c=2 have been propagated by someone at this point?  (VRP1?)

Reply via email to