
On 04/05/14 16:45, Sergei Trofimovich wrote:
On Sun, 4 May 2014 09:34:16 +0100 William Kenyon
wrote: I tested my patch on an old 32 bit laptop over night and it didn't work. I think it's best to revert Simon's patch and let him fix it when he gets chance.
On 3 May 2014 12:59, William Kenyon
wrote: I think this should fix the problem. It certainly doesn't break anything on a 64 bit machine, and should fix the problem on a 32 bit machine (although I can't test that)
To be more precise the patch hits codegen limitation:
"inplace/bin/ghc-stage1" -static -H32m -O -optc-march=i686 -opta-march=i686 -optl-Wl,-O1 -optl-Wl,--as-needed -optl-Wl,--hash-style=gnu -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -package-name rts -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -c rts/PrimOps.cmm -o rts/dist/build/PrimOps.o ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.9.20140504 for i386-unknown-linux): iselExpr64(i386) I64[_cfk::P32 + 60] - %MO_SS_Conv_W32_W64((Hp + 4) - I32[_cfl::I32])
Does it make sense to have 64-bit alloc_limit on 32-bit box?
Sorry about this, just validating a revert patch to fix the builds while I figure out how to fix the breakage on 32-bit machines. The alloc limit needs to be 64 bits, even on 32-bit machines. Cheers, Simon