Sorry for the wide distribution.
Some of you have heard about problems the new/next SBCL has building
SBCL. Good news is that this is not a deep compiler bug. Bad news
is that this is a QRES problem. Silver lining is that the problem
is not widespread, though it is fairly subtle.
Gory details follow, QUUX and QUAKE/crypto hackers take notice.
CAST-TO is up to no good. It uses TRULY-THE in an attempt
to "reinterpret" bits in an object.
Problem 1: lying to the compiler messes up the type derivation:
in POINTER-TO-ALIGNED-POINTER you have something like this:
(truly-the fixnum (ash (the (unsigned-byte 32) x) -2)
Where the compiler derives the result of ASH as an (unsigned-byte 30),
looks at the promise of the TRULY-THE, and ends up with the intersection
(unsigned-byte 29). OOPS.
This type derivation has always been going on. The new thing is that
under certain circumstances (one of which is crypto.lisp) the compiler
can now end up emitting the assertion for the (unsigned-byte 29), which
all negative numbers will fail. OOPS.
(I'm not yet sure why the type-check is emitted, since the compiler
should really be trusting its reasoning here. Part of the reason that
this took so long to figure out was that most of the things I did
when tracking this down ended up making the compiler elide the check,
and hence mask the bug...)
Problem 2: it really can reinterpret the bits, but you should not
rely on that.
If the high bit of X is set, the result will indeed be negative
in this case, but it is possible to construct code where that will
Now that I know what is wrong I'll think about what to do to fix it,
but I can already tell that TRULY-THE has no part in it...