From: Alastair B. <ala...@gm...> - 2010-05-22 12:56:37
|
On Sat, May 22, 2010 at 3:42 AM, Josh Elsasser <jo...@el...> wrote: > On Fri, May 21, 2010 at 07:29:58PM -0400, Alastair Bridgewater wrote: >> Hello, >> >> 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 foreign.test.sh. >> 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 <jo...@el...> 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 (SCALE-FLOAT-OVERFLOW BUG-372). >> 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 > this: > > http://www.elsasser.org/misc/jre-sbcl-ppc-foreign-test.diff 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. > Status: > 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, dynamic-extent.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. --Alastair Bridgewater |