[Openmcl-devel] more bugs on Linux/AMD64

[Gary Byers]

On Thu, 13 Jul 2006, Eric Marsden wrote:

> Hi,
>
> 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
CHAR-CODE-LIMIT."

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 3.4.4.1.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.


>
>
> Thanks,
>
> -- 
> Eric Marsden
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>