The following testcase crashes on mozilla-central revision 20210112-b97f7d02c912 (build with --enable-debug, run with --fuzzing-safe --no-threads --ion-warmup-threshold=0 --baseline-warmup-threshold=0):

function testMathyFunction (f, inputs) {
  for (var j = 0; j < inputs.length; ++j) 
    for (var k = 0; k < inputs.length; ++k) 
      f(inputs[j], inputs[k])
}
mathy3=(function(x) { 
  x >> (Math.fround(x) >>> 0)
});
testMathyFunction(mathy3, [-8,-Number,-Number, 3, 3])

Backtrace:

received signal SIGSEGV, Segmentation fault.
#0  0x000055555793cf09 in js::jit::WarpOracle::createSnapshot() ()
#1  0x00005555578dc7b6 in js::jit::CreateWarpSnapshot(JSContext*, js::jit::MIRGenerator*, JS::Handle<JSScript*>) ()
#2  0x00005555578dc109 in js::jit::IonCompile(JSContext*, JS::Handle<JSScript*>, js::jit::BaselineFrame*, unsigned int, unsigned char*, bool, js::jit::OptimizationLevel) ()
#3  0x00005555578bc487 in js::jit::Compile(JSContext*, JS::Handle<JSScript*>, js::jit::BaselineFrame*, unsigned int, unsigned char*, bool) ()
#4  0x00005555578bccd5 in IonCompileScriptForBaseline(JSContext*, js::jit::BaselineFrame*, unsigned int, unsigned char*) ()
#5  0x00000e2f1da02055 in ?? ()
#6  0x0000000000000000 in ?? ()
rax	0x55555572f6ef	93824994178799
rbx	0x7ffff6024000	140737320730624
rcx	0x555557ff0018	93825036910616
rdx	0x0	0
rsi	0x7ffff7105770	140737338431344
rdi	0x7ffff7104540	140737338426688
rbp	0x7fffffffae10	140737488334352
rsp	0x7fffffffad70	140737488334192
r8	0x7ffff7105770	140737338431344
r9	0x7ffff7f998c0	140737353717952
r10	0x58	88
r11	0x7ffff6dac7a0	140737334921120
r12	0x7ffff6089900	140737321146624
r13	0x7fffffffae30	140737488334384
r14	0x7ffff5e2c478	140737318667384
r15	0x4cdbeaf3	1289480947
rip	0x55555793cf09 <js::jit::WarpOracle::createSnapshot()+1737>
=> 0x55555793cf09 <_ZN2js3jit10WarpOracle14createSnapshotEv+1737>:	movl   $0xbe,0x0
   0x55555793cf14 <_ZN2js3jit10WarpOracle14createSnapshotEv+1748>:	callq  0x555556a97c60 <abort>

Recent regression happening highly frequently right now, marking fuzzblocker.

Bugmon Analysis:
Verified bug as reproducible on mozilla-central 20210112095256-a91c74c24d25.
The bug appears to have been introduced in the following build range:

Start: f4af0087a1b49c221f54143a10b7bebca35db49c (20210111195436)
End: febd0fad07331284c49334bab4d9c653f2c80275 (20210111195806)
Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=f4af0087a1b49c221f54143a10b7bebca35db49c&tochange=febd0fad07331284c49334bab4d9c653f2c80275

Iain, could you look into this bug it seems to be possibly caused one of your recent pushes

This is caused by a divergence between the implementations of JSOp::Ursh in baseline and Warp. Here's a simplified testcase:

function f(x, y) {
    x >> (y >>> 0)
}

with ({}) {}

f(-1, -1)
f(1.5, 0)
for (var i = 0; i < 25; i++) {
    f(0, 0);
}

The two initial calls to f create stubs with the following CacheIR:

  WarpCacheIR (offset 22, JSOp::Ursh)
      GuardIsNumber                 inputId 0
      TruncateDoubleToUInt32        inputId 0, resultId 2
      GuardToInt32                  inputId 1
      Int32URightShiftResult        lhsId 2, rhsId 1, allowDouble true
      ReturnFromIC                  

  WarpCacheIR (offset 23, JSOp::Rsh)
      GuardIsNumber                 inputId 0
      TruncateDoubleToUInt32        inputId 0, resultId 2
      GuardToInt32                  inputId 1
      Int32RightShiftResult         lhsId 2, rhsId 1
      ReturnFromIC         

In baseline, Int32URightShiftResult will return an Int32Value if the result fits, and a DoubleValue if it would overflow. That value is used as the rhs of the subsequent Rsh; because it's an Int32Value, GuardToInt32 succeeds.

In Warp, Int32URightShiftResult will return an Int32Value if allowDouble is false, and a DoubleValue if allowDouble is true, regardless of the actual value of the result. When the resulting DoubleValue is used as the rhs of the Rsh, the GuardToInt32 fails and bails out.

Warp and Baseline disagree about whether a >>> b should return a double or an Int32 when allowDouble is true and the result fits in Int32. This can cause a bailout loop if the result feeds into a GuardToInt32.

https://hg.mozilla.org/mozilla-central/rev/4804a5163d0e

Bugmon Analysis:
Verified bug as fixed on rev mozilla-central 20210114083245-cf6956a5ec8e.
Removing bugmon keyword as no further action possible.
Please review the bug and re-add the keyword for further analysis.

https://hg.mozilla.org/mozilla-central/rev/4804a5163d0e