I saw your (sadly, unanswered) message on the OpenBSD ppc list. I had a few minutes to poke at it today and I wonder if this doucment doesn't help.
Down in section 1.4 (FPSCR) they say that in general the status bits are sticky and you have to clear them. I'll poke around with this and see if this helps. I wonder if your test just didn't start looping constantly delivering SIGFPEs over and over again since the bits weren't cleared.
I do have this on my list of things to do, but, I've not gotten there yet.
> 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 . I made
> a few tweaks here and there, but nothing too egregious.
Thanks, looks fine to me aside from 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 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.
> > I suppose as far as changes to SBCL are concerned, that patch is
> > pretty good. The XXX comment in src/compiler/ppc/parms.lisp can be
> > removed, if it ever becomes an issue then I or someone else can fix it
> > then.
> I rewrote it as a FIXME comment with a bit of the background explanation.
Works for me, it's not like anyone will ever run into it unless the
default macppc MAXDSIZ changes.
> > Something better should probably be done about that
> > handler-case-bogus-compiler-note test in dynamic-extent.impure.lisp
> > which hangs SBCL, unless the recent test infrastructure changes
> > already took care of it.
> They did. The problem was that a COMPILER-NOTE isn't an ERROR, so
> it slipped through the usual net.
> 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
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
Ex! pected 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