[Bug tree-optimization/113774] wrong code with _BitInt() arithmetics at -O2

["jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
unsigned long long a[32], b[32], v[32], r[32];

void
foo (unsigned int n)
{
  unsigned long long c = 0;
  for (unsigned long i = 0; i < n; i += 2)
    {
      unsigned long j = i + 1;
      b[i] = __builtin_addcll (b[i], v[i], c, &c);
      b[j] = __builtin_addcll (b[j], v[j], c, &c);
    }
  b[4] = __builtin_addcll (b[4] & 1, v[4] & 1, c, &c) & 1;
  c = 0;
  for (unsigned long i = 0; i < n; i += 2)
    {
      unsigned long j = i + 1;
      unsigned long long k = i < 3 ? a[i] : 0;
      r[i] = b[i] | __builtin_subcll (k, b[i], c, &c);
      unsigned long long l = b[j];
      if (j <= 3)
        {
          if (j == 3)
            k = a[3] & 0x7fffffffffffffffULL;
          else
            k = a[3];
        }
      else
        k = 0;
      r[j] = l | __builtin_subcll (k, b[j], c, &c);
    }
  r[4] = (b[4] | __builtin_subcll (0, b[4] & 1, c, &c)) & 1;
}

might help understand better what bitintlower emits there, except it uses
PARM_DECLs or automatic VAR_DECLs instead of the global ones (except for v) and
n is 4 (I've used function argument only to avoid VRP figuring out earlier that
certain paths are dead) and the var sizes is actually just 4 (for a) or 5 elts.
That said, even _134 in the #c2 testcase at -O2 in the PHI argument is fishy,
but the
point is that bb 6 is really dead but it isn't known to the compiler yet; it is
reached if _49 <= 2 is false, but given that _49 is incremented in increments
of 2 and the array size is 5 maybe PRE knows that _49 then would have to be 4.
bb 6 either jumps directly to bb 10 (if _140 (aka _49 + 1) > 3) or hops through
bb 8 to bb 10.