[Bug-openmcl] ansi-tests

[Gary Byers]

I'd been been able to whittle down the failure total over the last
few days (it's hard to know whether to count the failures I introduced
over the last few days, but the net total was down some, I think.)

There are other things that fail (ARRAY-DISPLACEMENT for one), but
it's kind of hard to see what's going on for all of the SUBTYPEP
failures (SUBTYPEP has difficulty giving definitive answers,
especially when (NOT type) is involved.)  Christophe Rhodes (and
possibly others) has put a lot of work into improving SUBTYPEP in
SBCL, which (like OpenMCL) uses type system code that originated in
CMUCL.  I merged some of that code from a fairly recent CMUCL into
OpenMCL and got that to the point where the lisp would compile itself
a few times over; several of the bootstrapping problems I had before
getting to that point manifested themselves as infinite loops and
general chaos, and I haven't tried to exercise the new code beyond the
stuff that the lisp needs to compile itself.  (I'd be especially
suspicious of its treatment of unknown type-specifiers at this point.)

All of this is in bleeding-edge CVS and there's a heap image in
/pub/testing.  It may or may not be a step forward ...

One of the bugs that the test suite found has been present in 0.14 for
a long time.  In compiled code,

(ASH M N)

- where M and N are fixnums and N was negative - right-shifted M by
(MOD N 32) bits (just like the PPC manual says it does.)  The
-function- ASH did the right thing, but the compiler generates code
that calls a little assembly-language routine to handle the "easy"
cases and only call ASH on the hard cases.  This was supposed to be
one of the easy cases ...

On Sun, 11 Jan 2004, bryan o'connor wrote:

> instead of sending each minor compliance bug and patch
> to the list, i've just been collecting them on my website.
> to be honest, most of them will be quicker to fix by hand
> than to downlaod and apply the patch.
>
> some of the patches i feel reasonably confident about, but
> others (eg. changing fixnum restriction to integer) might
> be affecting internals in dangerous ways.  for those, the
> explanation of the problem should hopefully be helpful.
>
> i've also been chatting with pfdietz regularly on #lisp
> to clarify issues.  (eg. imagpart.4 failure)
>
> http://www.lunch.org/~bryan/openmcl/ansi-tests/
>
>
> 					...bryan
>
> _______________________________________________
> Bug-openmcl mailing list
> Bug-openmcl at clozure.com
> http://clozure.com/mailman/listinfo/bug-openmcl
>
>