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:
>> 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 <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
(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
|