...
AI says it is BigInt32, but at runtime, we are returning HeapBigInt!
Created attachment 397169 [details] Patch
Created attachment 397170 [details] Patch
Comment on attachment 397170 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=397170&action=review > Source/JavaScriptCore/ChangeLog:12 > + And we found that FTL BigInt32 predicate is not correctly checking state. This patch fixes it too. You should say what the test for this was. A JSValue number might have any lower bits set. > Source/JavaScriptCore/dfg/DFGAbstractInterpreterInlines.h:546 > + // FIXME: We should have inlined implementation that always returns BigInt32. link to a bug > Source/JavaScriptCore/jit/JITOperations.cpp:3152 > +void JIT_OPERATION operationDataLog(EncodedJSValue value) > +{ > + dataLogLn(JSValue::decode(value)); > +} why? Let's remove IMO
Comment on attachment 397170 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=397170&action=review >> Source/JavaScriptCore/ChangeLog:12 >> + And we found that FTL BigInt32 predicate is not correctly checking state. This patch fixes it too. > > You should say what the test for this was. A JSValue number might have any lower bits set. Yes, I'm hitting this bug with JSTests/stress/v8-bigint32-sar.js's CompareStrictEq. >> Source/JavaScriptCore/dfg/DFGAbstractInterpreterInlines.h:546 >> + // FIXME: We should have inlined implementation that always returns BigInt32. > > link to a bug Fixed. >> Source/JavaScriptCore/jit/JITOperations.cpp:3152 >> +} > > why? Let's remove IMO Removed.
Created attachment 397172 [details] Patch for landing
Committed r260512: <https://trac.webkit.org/changeset/260512>
<rdar://problem/62187118>
https://bugs.webkit.org/show_bug.cgi?id=210860