On Sat, May 22, 2010 at 3:42 AM, Josh Elsasser <josh@...> wrote:
> On Fri, May 21, 2010 at 07:29:58PM -0400, Alastair Bridgewater wrote:
>> I've just put together the version of the patch that I'm planning to commit.
>> Unfortunately, I can't seem to access repo.or.cz right now, so I put the
>> patch at <http://www.lisphacker.com/temp/sbcl-openbsd-ppc.diff>. I made
>> a few tweaks here and there, but nothing too egregious.
> Thanks, looks fine to me aside from foreign.test.sh
Okay, so this much goes in, even if we don't have something we agree on for
>> Barring being told "no, no, it doesn't work now" or code-freeze, I intend to
>> commit this at some point on Sunday, the 23rd. If there's something else
>> I should be doing beyond adding a NEWS snippet, now would be the time
>> for another SBCL maintainer to mention it.
>> On Fri, May 21, 2010 at 10:16 AM, Josh Elsasser <josh@...> wrote:
>> > The failing NaN tests at least appear to be to be a problem with
>> > OpenBSD and need to be fixed there instead of in SBCL. I had been
>> > working on a fix but was sidetracked, I'll see if I can get it working
>> > soon.
>> I looked at these briefly earlier today, and it looks like the traps are being
>> disabled for some strange reason on my linux system, which worries me,
>> but indicates to me that it might be more an SBCL problem than a Linux
>> problem. Don't let my conclusions stop you from approaching it as an
>> OpenBSD problem, though.
> There certainly is an OpenBSD problem, but of course that doesn't mean
> there isn't also an SBCL problem.
Quite right, PPC/Linux has only expected failures in the test suite at this
point, indicating an OpenBSD problem... And an OpenBSD unproblem
>> What I didn't apply was the -fPIC thing for foreign.test.sh, as it doesn't
>> seem to be necessary for PPC/Linux. I'd be happier with a special case
>> similar to what is done for Darwin.
> Unpatched, foreign.test.sh fails quite spectacularly on
> OpenBSD/macppc. When you say special case, do you mean something like
Like that, but probably not that. At the same time, that should be enough
information for me to be able to come up with something I'd be happier with.
> For the record, here are my test results with sbcl-openbsd-ppc.diff
> and jre-sbcl-ppc-foreign-test.diff applied:
> Finished running tests.
> Unexpected success: float.pure.lisp / (SCALE-FLOAT-OVERFLOW BUG-372)
> Expected failure: float.pure.lisp / (ADDITION-OVERFLOW BUG-372)
> Failure: float.pure.lisp / NAN-COMPARISONS
> Expected failure: debug.impure.lisp / (UNDEFINED-FUNCTION BUG-346)
> Expected failure: debug.impure.lisp / (UNDEFINED-FUNCTION BUG-353)
> Expected failure: debug.impure.lisp / (TRACE ENCAPSULATE NIL)
> Expected failure: debug.impure.lisp / (TRACE-RECURSIVE ENCAPSULATE NIL)
> Expected failure: dynamic-extent.impure.lisp / (NO-CONSING DX-RAW-INSTANCES)
> Expected failure: dynamic-extent.impure.lisp / HANDLER-CASE-BOGUS-COMPILER-NOTE
> Expected failure: dynamic-extent.impure.lisp / DX-COMPILER-NOTES
> Expected failure: dynamic-extent.impure.lisp / HANDLER-CASE-EATING-STACK
> Expected failure: dynamic-extent.impure.lisp / RECHECK-NESTED-DX-BUG
> Expected failure: packages.impure.lisp / USE-PACKAGE-CONFLICT-SET
> Expected failure: packages.impure.lisp / IMPORT-SINGLE-CONFLICT
> Failure: timer.impure.lisp / (TIMER STRESS)
> Failure: timer.impure.lisp / (WITH-TIMEOUT TIMEOUT)
> test failed, expected 104 return code, got 1
So, float.pure.lisp is still different, the debug.impure.lisp,
and packages.impure.lisp stuff is at current PPC-normal,
timer.impure.lisp is at what
is apparently OpenBSD-normal, and the room.test.sh failure isn't
there, for which we
may as well blame differing heap locations or something. Looks good, though.