Re: [Sbcl-devel] Recent breakage in OpenBSD/PPC

"Bruce O'Neel" <ecl@...> writes:
> Hi,
>
> The change below breaks OpenBSD/PPC. It does not break Darwin/PPC, nor OpenBSD/x86 or OpenBSD/AMD64.
>
> I've attached a log from a broken build. I've also attached the world's silliest patch since all it
> does is remove part of the commit below.
>
> If someone has an idea I'm happy to debug and explore more. I don't understand the bit of code
> that is broken and haven't gotten very far to understand why it is broken.
It's always possible that it's my patch that is broken, but it's also
possible that something else is broken somewhere, which has been exposed
by what I think this fixes, either directly or just because of random
movement of stuff. That said, could someone familiar with IR1 and
modular arithmetic please check the bisected commit?
52b1041d3a14eaa4e45f6d8edfbdc0dec4292239 is the decreed culprit.
The new bit in this commit is that, in code of the form
(logand (logfoo ...) <some bignum>)
where the compiler can /prove/ that the result of the logand is always
some kind of machine integer, the <some bignum> is truncated to the
appropriate machine integer width. (Since the higher bits were proven
to be irrelevant to the computation, they might as well be thrown away).
The commit might be wrong. There is probably a reason that Alexey
didn't do it way back when. But I am surprised by this, and the fact
that's it's broken (I presume deterministically) on just one platform
suggests to me that it's more likely that something else is the matter.
(If this were a problem with the patch, I'd expect this to show up more
or less deterministically on every platform, because it is
platform-agnostic).
The point at which it breaks is also the point at which, I believe, the
lisp side does its first call to open() -- it's successfully executed
the first few forms in make-target-2.lisp, as you can see from the
echoed output at the end of the build log, and then dies before doing
anything much at all of the (load "src/cold/warm.lisp") form. If the
ABI details were wrong, for example stack alignment, that could show up
as memory corruption at this point, for example if the return value from
open() isn't where the lisp expects it to be.
Any other ideas?
Cheers,
Christophe