[Openmcl-devel] more bugs on Linux/AMD64
gb at clozure.com
Thu Jul 13 22:12:27 UTC 2006
On Thu, 13 Jul 2006, Eric Marsden wrote:
> SBCL still doesn't build with OpenMCL on AMD64, for some obscure
> reason that I haven't figured out. Here are some bugs extracted from
> Paul Dietz's ansi-test suite, that is distributed with GCL.
> * (code-char 256) signals an error but should return NIL
(CODE-CHAR CHAR-CODE-LIMIT) signals an error in about half of the
implementations I tested (including some fairly recent versions of
SBCL, so I'd be surprised if building it depends on not signaling
an error in that case.)
I believe that this test is misguided; the spec says that CODE-CHAR
accepts an argument that's a "character code", and the glossary
defines a "character code" as being "an unsigned integer less than
Some character encodings are sparse, and it makes sense to define
CODE-CHAR to return NIL for codes that don't denote characters in a
particular encoding. (For instance, Only about 96K of 1.1M Unicode
code points are currently defined, IIRC). It does not make sense (to
me, at least) for CODE-CHAR to be required to quietly accept invalid
arguments, and an integer >= CHAR-CODE-LIMIT is not a valid argument.
> * (>= (sqrt 682223840097443425701178572245775373)
> (isqrt 682223840097443425701178572245775373))
> returns NIL but should be T. (Also true for certain other bignums.)
I remember some similar test failures; the general pattern was that
coercing from a single float to an integer and back again lost
information (and the same case didn't on the PPC.) It sounds like
a case where the wrong type of rounding happens, but I haven't
found the cause yet.
> * (typep (make-sequence '(vector (signed-byte 33)) 1 :initial-element 0)
> '(vector (signed-byte 33)))
> returns NIL but should be T.
Recently introduced (type system needs to know more about FIXNUM arrays.)
Fixed in CVS.
> * (macrolet ((%m (&whole (m a b) c d) `(quote (,m ,a ,b ,c ,d))))
> (%m 1 2))
> should return (%m 1 2 1 2) but signals an error (see 18.104.22.168.2)
Also a bug, but (since it's been there forever) not likely to be
the cause of any problems you're having.
> * I notice that floating point overflow and underflow detection
> default to off, at least on my system. Should stuff be expected to
> break if (set-fpu-mode :underflow t) is used?
Overflow detection should be on by default, and it is in the 060705
image that I have here.
Historically (in MCL at some point in the past) something did break
if underflow was signaled; I'm not sure if that something still exists,
or if the effect of disabling underflow detection is exactly the same
on x86-64 as it has been on PPC.
The best answer that I can give ("maybe something will break, but I
don't remember what") isn't a very good answer. My recollection is
that whatever that something is, it could probably disable/restore
the overflow-enable bit on a local basis.
> Eric Marsden
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
More information about the Openmcl-devel