michael@0: function foo()
michael@0: {
michael@0:   // Range analysis incorrectly computes a range for the multiplication.  Once
michael@0:   // that incorrect range is computed, the goal is to compute a new value whose
michael@0:   // range analysis *thinks* is in int32_t range, but which goes past it using
michael@0:   // JS semantics.
michael@0:   //
michael@0:   // On the final iteration, in JS semantics, the multiplication produces 0, and
michael@0:   // the next addition 0x7fffffff.  Adding any positive integer to that goes
michael@0:   // past int32_t range: here, (0x7fffffff + 5) or 2147483652.
michael@0:   //
michael@0:   // Range analysis instead thinks the multiplication produces a value in the
michael@0:   // range [INT32_MIN, INT32_MIN], and the next addition a value in the range
michael@0:   // [-1, -1].  Adding any positive value to that doesn't overflow int32_t range
michael@0:   // but *does* overflow the actual range in JS semantics.  Thus omitting
michael@0:   // overflow checks produces the value 0x80000004, which interpreting as signed
michael@0:   // is (INT32_MIN + 4) or -2147483644.
michael@0:   //
michael@0:   // For this test to trigger the bug it was supposed to trigger:
michael@0:   //
michael@0:   //   * 0x7fffffff must be the LHS, not RHS, of the addition in the loop, and
michael@0:   //   * i must not be incremented using ++
michael@0:   //
michael@0:   // The first is required because JM LoopState doesn't treat *both* V + mul and
michael@0:   // mul + V as not overflowing, when V is known to be int32_t -- only V + mul.
michael@0:   // (JM pessimally assumes V's type might change before it's evaluated.  This
michael@0:   // obviously can't happen if V is a constant, but JM's puny little mind
michael@0:   // doesn't detect this possibility now.)
michael@0:   //
michael@0:   // The second is required because JM LoopState only ignores integer overflow
michael@0:   // on multiplications if the enclosing loop is a "constrainedLoop" (the name
michael@0:   // of the relevant field).  Loops become unconstrained when unhandled ops are
michael@0:   // found in the loop.  Increment operators generate a DUP op, which is not
michael@0:   // presently a handled op, causing the loop to become unconstrained.
michael@0:   for (var i = 0; i < 15; i = i + 1) {
michael@0:     var y = (0x7fffffff + ((i & 1) * -2147483648)) + 5;
michael@0:   }
michael@0:   return y;
michael@0: }
michael@0: assertEq(foo(), (0x7fffffff + ((14 & 1) * -2147483648)) + 5);
michael@0: 
michael@0: function bar()
michael@0: {
michael@0:   // Variation on the theme of the above test with -1 as the other half of the
michael@0:   // INT32_MIN multiplication, which *should* result in -INT32_MIN on multiply
michael@0:   // (exceeding int32_t range).
michael@0:   //
michael@0:   // Here, range analysis again thinks the range of the multiplication is
michael@0:   // INT32_MIN.  We'd overflow-check except that adding zero (on the LHS, see
michael@0:   // above) prevents overflow checking, so range analysis thinks the range is
michael@0:   // [INT32_MIN, INT32_MIN] when -INT32_MIN is actually possible.  This direct
michael@0:   // result of the multiplication is already out of int32_t range, so no need to
michael@0:   // add anything to bias it outside int32_t range to get a wrong result.
michael@0:   for (var i = 0; i < 17; i = i + 1) {
michael@0:     var y = (0 + ((-1 + (i & 1)) * -2147483648));
michael@0:   }
michael@0:   return y;
michael@0: }
michael@0: assertEq(bar(), (0 + ((-1 + (16 & 1)) * -2147483648)));