From: Christophe Rhodes <csr21@ca...>  20120324 22:06:28

Paul Dietz <paul.dietz@...> writes: > (resending this after subscribing to sbclbugs) Welcome back! > After a hiatus I've been running the random lisp tester on SBCL. > There are some regressions from the last time I did this, some years > ago. > > All tests were run on SBCL 1.0.55, i686 32 bit, Linux. > > I've attached files illustrating four apparently different bugs. ;; Illustration of bug in SBCL 1.0.55 (32 bit i686, Linux) (defun f1 (c) (declare (type (integer 53 86) c)) (declare (optimize (speed 1) (space 1) (safety 2) (debug 0) (compilationspeed 3))) (logand (+ c 1032791128) 11007078467)) (defun f2 (c) (declare (optimize (speed 2) (space 3) (safety 0) (debug 0) (compilationspeed 0))) (logand (+ c 1032791128) 11007078467)) (defun doit () (let ((c 61)) (list (f1 c) (f2 c)))) ;; f1 is incorrect, f2 is correct ;; (doit) ==> (11005992961 268574721) This one, I think, is my fault; I haven't bisected, but I think I probably introduced a bug over four years ago in modular arithmetic, thinking that one can use a signed modular arithmetic implementation of an unsigned computation, if the width is smaller. Unfortunately, that's not quite true; here, SBCL successfully derives that the result of F1 will be a positive fixnum, but it then computes the addition using signed modular arithmetic, which has rather more 1 bits than either the true or the unsigned modular arithmetic version. I think this would be correct if the constant here were cut to the correct (unsigned) width, or more generally if the LOGAND optimizer were to wrap itself in another, simply masking, LOGAND. Cheers, Christophe 