From: Christophe R. <cs...@ca...> - 2012-04-16 20:21:49
|
"Bruce O'Neel" <ec...@pc...> 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 |