Bugzilla

I think this is just a bug in the arm32 simulator.

In an arm32 build with `--arm-hwcap=vfp`, we call `__aeabi_idivmod` to compute `9 % -1`. The result is an int64_t containing -9 (9 / -1) in the low 32 bits, and 0 (9 % - 1) in the high 32 bits: 0x00000000fffffff7. We return to [this code](https://searchfox.org/mozilla-central/source/__GENERATED__/js/src/jit/ABIFunctionTypeGenerated.h#641-648):

```
case js::jit::Args_General2: {
  auto target = reinterpret_cast<Prototype_General2>(external);
  intptr_t ret;
  ret = target(a0, a1);
  scratchVolatileRegisters((void*)target); 
  setCallResult(ret);
  break;
}
```
This stores the result in an `intptr_t`, which is 32-bit because this is a 32-bit build. When we call `setCallResult`, we convert from intptr_t to int64_t by sign-extending, giving us `0xfffffffffffffff7`. This sets r1 to -1 instead of 0, which we catch because of `--ion-check-range-analysis`.

Here's a reduced testcase:
```
// |jit-test| --fast-warmup; --no-threads; --ion-check-range-analysis; --arm-hwcap=vfp
function foo(x) { return x % -1; }

with ({}) {}
for (var i = 0; i < 1000; i++) {
  foo(i);
}
```
Ryan, is this a bug in the generated ABIFunctionType code?

I think this is just a bug in the arm32 simulator.

In an arm32 build with `--arm-hwcap=vfp`, we call `__aeabi_idivmod` to compute `9 % -1`. The result is an int64_t containing -9 (9 / -1) in the low 32 bits, and 0 (9 % - 1) in the high 32 bits: `0x00000000fffffff7`. We return to [this code](https://searchfox.org/mozilla-central/source/__GENERATED__/js/src/jit/ABIFunctionTypeGenerated.h#641-648):

```
case js::jit::Args_General2: {
  auto target = reinterpret_cast<Prototype_General2>(external);
  intptr_t ret;
  ret = target(a0, a1);
  scratchVolatileRegisters((void*)target); 
  setCallResult(ret);
  break;
}
```
This stores the result in an `intptr_t`, which truncates to `0xfffffff7` because this is a 32-bit build. When we call `setCallResult`, we convert from intptr_t to int64_t by sign-extending, giving us `0xfffffffffffffff7`. This sets r1 to -1 instead of 0, which we catch because of `--ion-check-range-analysis`.

Here's a reduced testcase:
```
// |jit-test| --fast-warmup; --no-threads; --ion-check-range-analysis; --arm-hwcap=vfp
function foo(x) { return x % -1; }

with ({}) {}
for (var i = 0; i < 1000; i++) {
  foo(i);
}
```
Ryan, is this a bug in the generated ABIFunctionType code?