Custom Query (1030 matches)
Results (652 - 654 of 1030)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #347 | fixed | another IA-32 bignum bug | ||
| Description |
? (isqrt (expt 10 100)) > Error: DIVISION-BY-ZERO detected > While executing: CCL::%FLOOR-99, in process listener(1). |
|||
| #412 | fixed | another case where simple arithmetic is beyond our grasp. | ||
| Description |
I'm too lazy to submit another bug report, but (on x8664): ? (defun foo ()
(let* ((x most-negative-fixnum)
(y 1))
(- x y)))
FOO
? (foo)
1152921504606846975
?
Hmm. I expected something more ... negative. (This is broken on 1.2 as well. I haven't checked ppc64, but I'd be suspicious.) |
|||
| #968 | fixed | apparent GC issue on x8632 | ||
| Description |
See http://clozure.com/pipermail/openmcl-devel/2012-May/013568.html I was unable to reproduce this after doing: ? (progn
(egc nil)
(set-lisp-heap-gc-threshold (ash 512 20))
(gc))
before calling (RUN), even when TEST/RUN created threads and RUN ran for 2500 iterations instead of 25. That suggests pretty strongly that this is a GC bug (or that the code involved in BIGNUM * FIXNUM multiplication doesn't follow register conventions correctly and that the failure occurs when such code is interrupted by GC in another thread.) When a failure occurs, several words (in the "middle" of the result bignum) have incorrect values; the bignum is of the correct size and the words near both ends seem to be correct. This is also consistent with GC-related memory corruption. |
|||
