the goal is to test if an integer value can fit in a 61bits Small Integer or not. We check that most significant 4 bits are all 0 or all 1. Unfortunately, the JIT have it right once:
but wrong once:
64 should be 63, or we only test highest 3 bits... Fortunately, this is only used in genPrimitiveDivide... That's not the first time that this bug happens, I already reported it in the past, but it seems that we did not capitalize this test case (or it is not jitted?).
then force the jitter with a bench:
then you'll trigger it... — |
The failures are unrelated, we can close — |
In reply to this post by David T Lewis
Closed #415. — |
In reply to this post by David T Lewis
For the sake of archeology, I detected similar bug in 2012 for legacy interpreter — |
On Sat, Aug 24, 2019 at 02:44:01PM -0700, Nicolas Cellier wrote: > > For the sake of archeology, I detected similar bug in 2012 for legacy interpreter > See thread **[Vm-dev] 3 Bugs in LargeInteger primitives** > http://lists.squeakfoundation.org/pipermail/vm-dev/2012-August/011161.html > Thanks for these archeology links, it is very helpful. Sorry I don't recall the history of this issue, but the bugs that you identified in 2012 for legacy interpreter do not seem to be present in the interpreter VM today. I am assuming this is because you fixed those issues in VMMaker afterwards, is that right? Here is what I see on my system today (interpreter VM, Ubuntu Linux, gcc compiler): ((1<<63) negated quo: -1) hex. => '16r8000000000000000' ((1<<63) negated / -1) hex. => '16r8000000000000000' ((1<<63) negated * -1) hex. => '16r8000000000000000' ((1<<63) negated // -1) hex. => '16r8000000000000000' Dave |
Free forum by Nabble | Edit this page |