Alexey Dejneka <adejneka@...> writes:
> Here is a list of known to me Paul's reports and their status as of
> 0.8.3.73. Sorry, if it duplicates what you already know. Any
> corrections or additions are welcome.
Your list, as far as I know, is accurate as of now. I've been running
the random tester myself on some co-opted hardware (i.e. faster than
mine :-), and 70000 iterations or so have gone past without a hit.
Maybe it's worth summarizing the results of the regular test suite,
All platforms currently fail 11 out of 14016 total tests:
THE.20, SHARED-INITIALIZE.ERROR.3, SHARED-INITIALIZE.ERROR.4,
CHANGE-CLASS.ERROR.3, MAKE-INSTANCE.ERROR.2, DEFGENERIC.ERROR.20,
CALL-NEXT-METHOD.ERROR.2, IMAGPART.4, RATIONALIZE.1.
Of these, I believe that all but IMAGPART.4 and THE.20 are fixed in
cmucl. (I have my qualms about IMAGPART.4; I don't think that it's
clear that the intent is that (* 0 x) be used as the computation,
particularly given the TYPE-OF stuff noted. Do we have a numerical
analyst here who would express a preference of where the real line
lies in IMAGPART terms?)
/.ERROR.5, /.ERROR.6, /.ERROR.7, /.ERROR.8
(because of unimplemented floating point exceptions decoding,
throwing a WARNING. I'm not sure that this is actually a bug in
(a backend bug somewhere, probably in call.lisp; passing in too
high a value directly to an instruction, leading to an internal
RATIONALIZE.3, EPSILONS.1, EPSILONS.2, EPSILONS.8, EPSILONS.9,
(yay for x86 floating point)
SPARC/Sunos and PPC/Linux fail no additional tests.
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)