quick followup
> [...]
>
>> Failure: unicode-misc.pure.lisp / (CL-CASE-INVERTIBILITY)
>
> (loop for i from 0 below char-code-limit
> for char = (code-char i)
> do
> (when (upper-case-p char)
> (assert (char= char (char-upcase (char-downcase char)))))
> (when (lower-case-p char)
> (assert (char= char (char-downcase (char-upcase char))))))
>
> This fails with char being #\WARANG_CITI_CAPITAL_LETTER_VIYO, or
> U+118BF. I asked a friend on linux to test and there:
>
> (char= #\WARANG_CITI_CAPITAL_LETTER_VIYO
> (char-upcase (char-downcase #\WARANG_CITI_CAPITAL_LETTER_VIYO)))
> ; => t
>
> This could be a real bug, probably in the unicode data.
iswupper(3) and iswlower(3) return the correct thing (0) for that
character so it isn't a problem in base. sbcl' UPPER/LOWER-CASE-P works
by inspecting a database of unicode data produced during the build in
${WRKDIR}/output/ucd* so the bug must be there, but I'm still not sure
how it's generated.
It'd be nice to report this and the other failure upstream. I don't
have an account at launchpad, but if nobody else wants to report them I
guess I can create one and try to.
> [...]
>
>> Expected failure: float.impure.lisp / (RANGE-REDUCTION PRECISE-PI)
>
> this is actually an improvement: it's expected to fail openbsd but it
> works now :)
nope, I mis-interpreted the regress suite output, this is still broken.
> Inaccurate result for (SIN 4.611686018427388d18):
> expected -0.7029224436192089d0,
> got -0.7071329274527789d0
FWIW it's been broken for eight years:
https://bugs.launchpad.net/sbcl/+bug/1137924
