Custom Query (1030 matches)
Results (460 - 462 of 1030)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #654 | invalid | TYPE-OF incorrect for bignums | ||
| Description |
CL-USER> (lisp-implementation-version) "Version 1.5-dev-r13405M-trunk (LinuxX8664)" CL-USER> (type-of (expt 2 64)) (INTEGER 1152921504606846976) CL-USER> (type-of (expt 2 100)) (INTEGER 1152921504606846976) CL-USER> (type-of (expt 2 1000)) (INTEGER 1152921504606846976) CL-USER> (type-of (expt 2 10000)) (INTEGER 1152921504606846976) |
|||
| #290 | fixed | THE typechecking and evaluation order | ||
| Description |
This should already be fixed in r9331, but for the record and in case it rears its ugly head again. The TYPED-FORM acode operation (basically, the acode representation of THE) now takes an extra argument indicating whether or not a runtime typecheck should occur; this is set to T by the frontend at high SAFETY levels. Historically, a TYPED-FORM acode operation was considered "simple and side-effect free" if its operand was and could therefore be evaluated out-of-order, but this is no longer true if typehecking is involved. (Since that typechecking can involve function calls and a lot of register shuffling, a typechecking TYPED-FORM should be viewed as something that has unknown side-effects and which can at least change register contents.) |
|||
| #621 | fixed | THE chokes on VALUES type specifiers | ||
| Description |
http://clozure.com/pipermail/openmcl-devel/2009-October/010672.html |
|||
