Dear SBCL developers,
the VOP mentioned in the subject is used to test whether a value known
to be an (UNSIGNED-BYTE 64) is a FIXNUM. The test wrongly succeeds for
values that are larger than MOST-POSITIVE-FIXNUM and smaller than
(* 2 (1+ MOST-POSITIVE-FIXNUM)) since the right shift that the test uses
shifts by one bit too far.
While the code generated by this VOP occurs hundreds of times in the
SBCL runtime (just grep through the disassembly for "SHR ..., 61"), no
harm seems to have been done. Most of the occurrences are in type checks
for array indexes, either for the type FIXNUM or for the type INDEX --
which is defined as (INTEGER 0 (#.MOST-POSITIVE-FIXNUM)) and where a
following comparison with (1- MOST-POSITIVE-FIXNUM) masks the fault --
where numbers so large don't occur anyway.
Here is the patch (with a test case):