I'm working off HEAD, so this is good info to know. Cheers, Edward

I get the same error for the other branch too. Cheers, Edward

I haven't looked at these branches for a fair few weeks, the problem when they fail to build usually is because all the libraries are just set to follow HEAD, they're not actually branched themselves, just the ghc compiler. So there are probably some patches from ghc HEAD that need to be pulled in to sync the compiler with the libs again. If you want to do some work on the new codegen the first step is to try to pull in all the patches from ghc HEAD, synchronise the branch. Its not a fun job but GHC HQ wants to try to merge in all the new codegen stuff to HEAD asap. On 4 December 2010 23:45, Edward Z. Yang wrote:

Excerpts from David Terei's message of Fri Dec 03 23:44:33 -0500 2010:

...

http://darcs.haskell.org/ghc-cmm-03Sep10/

This branch fails to build for me:

"inplace/bin/ghc-stage1" -M -dep-makefile libraries/dph/dph-par/dist-install/build/.depend-v.haskell.tmp  -include-pkg-deps -H64m -O -fasm -package-name dph-par-0.5 -hide-all-packages -i -ilibraries/dph/dph-par/../dph-common -ilibraries/dph/dph-par/dist-install/build -ilibraries/dph/dph-par/dist-install/build/autogen -Ilibraries/dph/dph-par/dist-install/build -Ilibraries/dph/dph-par/dist-install/build/autogen -Ilibraries/dph/dph-par/. -optP-include -optPlibraries/dph/dph-par/dist-install/build/autogen/cabal_macros.h -package array-0.3.0.2 -package base-4.3.0.0 -package dph-base-0.5 -package dph-prim-par-0.5 -package ghc-7.1.20101126 -package ghc-prim-0.2.0.0 -package random-1.0.0.3 -package template-haskell-2.5.0.0 -Odph -funbox-strict-fields -fcpr-off -fdph-this -package-name dph-par -XTypeFamilies -XGADTs -XRankNTypes -XBangPatterns -XMagicHash -XUnboxedTuples -XTypeOperators -no-user-package-conf -rtsopts -O -dcore-lint -odir libraries/dph/dph-par/dist-install/build -hidir libraries/dph/dph-par/dist-install/build -stubdir libraries/dph/dph-par/dist-install/build -hisuf hi -osuf o -hcsuf hc  libraries/dph/dph-par/../dph-common/Data/Array/Parallel.hs  libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Lifted.hs  libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Prelude.hs  libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Prelude/Int.hs  libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Prelude/Word8.hs  libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Prelude/Float.hs  libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Prelude/Double.hs  libraries/dph/dph-par/../dph-common/Data/Array/Parallel/PArray.hs  libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Lifted/PArray.hs  libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Lifted/Unboxed.hs  libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Lifted/Scalar.hs  libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Lifted/TH/Repr.hs  libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Lifted/Repr.hs  l!  ibraries /dph/dph-par/../dph-common/Data/Array/Parallel/Lifted/Closure.hs  libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Lifted/Instances.hs  libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Lifted/Combinators.hs  libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Prelude/Base/Int.hs  libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Prelude/Base/Word8.hs  libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Prelude/Base/Float.hs  libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Prelude/Base/Double.hs  libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Prelude/Base/Bool.hs  libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Prelude/Base/PArr.hs  libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Prelude/Base/Tuple.hs  libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Prelude/Base.hs  libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Prelude/Bool.hs

libraries/dph/dph-par/../dph-common/Data/Array/Parallel.hs:1:14:    Unsupported extension: ParallelArrays make[1]: *** [libraries/dph/dph-par/dist-install/build/.depend-v.haskell] Error 1 make: *** [all] Error 2

I can debug this further if you want me to.

Edward

I did a bit more merging of your branch. My current state is here: http://darcs.haskell.org/ghc-cmm-15Sep10/ it doesn't actually build, but the failure is somewhere in hoopl I think. This branch is 400-odd patches behind the current HEAD. I don't think I borked anything too badly during the merge, so it should be safe to start from here. Cheers, Simon On 06/12/2010 02:19, David Terei wrote:

I haven't looked at these branches for a fair few weeks, the problem when they fail to build usually is because all the libraries are just set to follow HEAD, they're not actually branched themselves, just the ghc compiler. So there are probably some patches from ghc HEAD that need to be pulled in to sync the compiler with the libs again. If you want to do some work on the new codegen the first step is to try to pull in all the patches from ghc HEAD, synchronise the branch. Its not a fun job but GHC HQ wants to try to merge in all the new codegen stuff to HEAD asap.

On 4 December 2010 23:45, Edward Z. Yang wrote:

...

Excerpts from David Terei's message of Fri Dec 03 23:44:33 -0500 2010:

...

http://darcs.haskell.org/ghc-cmm-03Sep10/

This branch fails to build for me:

"inplace/bin/ghc-stage1" -M -dep-makefile libraries/dph/dph-par/dist-install/build/.depend-v.haskell.tmp -include-pkg-deps -H64m -O -fasm -package-name dph-par-0.5 -hide-all-packages -i -ilibraries/dph/dph-par/../dph-common -ilibraries/dph/dph-par/dist-install/build -ilibraries/dph/dph-par/dist-install/build/autogen -Ilibraries/dph/dph-par/dist-install/build -Ilibraries/dph/dph-par/dist-install/build/autogen -Ilibraries/dph/dph-par/. -optP-include -optPlibraries/dph/dph-par/dist-install/build/autogen/cabal_macros.h -package array-0.3.0.2 -package base-4.3.0.0 -package dph-base-0.5 -package dph-prim-par-0.5 -package ghc-7.1.20101126 -package ghc-prim-0.2.0.0 -package random-1.0.0.3 -package template-haskell-2.5.0.0 -Odph -funbox-strict-fields -fcpr-off -fdph-this -package-name dph-par -XTypeFamilies -XGADTs -XRankNTypes -XBangPatterns -XMagicHash -XUnboxedTuples -XTypeOperators -no-user-package-conf -rtsopts -O -dcore-lint -odir libraries/dph/dph-par/dist-install/build -h idir libraries/dph/dph-par/dist-install/build -stubdir libraries/dph/dph-par/dist-install/build -hisuf hi -osuf o -hcsuf hc libraries/dph/dph-par/../dph-common/Data/Array/Parallel.hs libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Lifted.hs libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Prelude.hs libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Prelude/Int.hs libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Prelude/Word8.hs libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Prelude/Float.hs libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Prelude/Double.hs libraries/dph/dph-par/../dph-common/Data/Array/Parallel/PArray.hs libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Lifted/PArray.hs libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Lifted/Unboxed.hs libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Lifted/Scalar.hs libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Lifted/TH/Repr.hs libraries/ dph/dph-par/../dph-common/Data/Array/Parallel/Lifted/Repr.hs l! ibraries /dph/dph-par/../dph-common/Data/Array/Parallel/Lifted/Closure.hs libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Lifted/Instances.hs libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Lifted/Combinators.hs libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Prelude/Base/Int.hs libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Prelude/Base/Word8.hs libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Prelude/Base/Float.hs libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Prelude/Base/Double.hs libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Prelude/Base/Bool.hs libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Prelude/Base/PArr.hs libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Prelude/Base/Tuple.hs libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Prelude/Base.hs libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Prelude/Bool.hs

libraries/dph/dph-par/../dph-common/Data/Array/Parallel.hs:1:14: Unsupported extension: ParallelArrays make[1]: *** [libraries/dph/dph-par/dist-install/build/.depend-v.haskell] Error 1 make: *** [all] Error 2

I can debug this further if you want me to.

Edward

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Ian, I'd love a little guidance with this patch: Thu Oct 21 13:08:53 BST 2010 Ian Lynagh * Use takeUniqFromSupply in emitProcWithConvention We were using the supply's unique, and then passing the same supply to initUs_, which sounds like a bug waiting to happen. { hunk ./compiler/codeGen/StgCmmMonad.hs 607 - ; let (offset, entry) = mkEntry (mkBlockId $ uniqFromSupply us) conv args - blks = initUs_ us $ lgraphOfAGraph $ entry <*> blocks + ; let (uniq, us') = takeUniqFromSupply us + (offset, entry) = mkEntry (mkBlockId uniq) conv args + blks = initUs_ us' $ lgraphOfAGraph $ entry <*> blocks } The new codegen has this hunk instead: ; let (offset, entry) = mkCallEntry conv args blks = initUs_ us $ lgraphOfAGraph $ entry <*> blocks and it's not clear to me if this circumvents the previous bug or mkCallEntry needs to be modified to expose the new supply. Edward

Final status report for tonight, before I crash in bed; I've managed to make it compile all the way to hoopl. It seems like hoopl doesn't typecheck anymore? I haven't been following the typechecker changes too closely so some guidance would be appreciated. libraries/hoopl/src/Compiler/Hoopl/Util.hs:190:37: Could not deduce (e ~ block C C) from the context (NonLocal block, LabelsPtr e) `e' is a rigid type variable bound by the type signature for `postorder_dfs_from_except' at libraries/hoopl/src/Compiler/Hoopl/Util.hs:179:43 In the first argument of `get_children', namely `block' In the first argument of `vchildren', namely `(get_children block)' In the expression: vchildren (get_children block) cont' acc (setInsert id visited) libraries/hoopl/src/Compiler/Hoopl/Util.hs:220:41: Could not deduce (e ~ block C C) from the context (NonLocal block, LabelsPtr e) `e' is a rigid type variable bound by the type signature for `preorder_dfs_from_except' at libraries/hoopl/src/Compiler/Hoopl/Util.hs:217:42 In the first argument of `get_children', namely `b' In the first argument of `children', namely `(get_children b)' In the first argument of `unVM', namely `(children (get_children b))' libraries/hoopl/src/Compiler/Hoopl/Util.hs:256:45: Couldn't match type `O' with `C' In the first argument of `addTargets', namely `b' In the expression: addTargets b setEmpty In an equation for `entryTargets': entryTargets (JustO b) = addTargets b setEmpty make[1]: *** [libraries/hoopl/dist-install/build/Compiler/Hoopl/Util.o] Error 1 make: *** [all] Error 2 Cheers, Edward

Is it safe to consider type families and associated type families extensions for ghc as stable ? Wich related extensions (flexible contexts, undecidable instanses and so on) may be deprecated or changed in near (2-3 years) future and wich may not?

FWIW, I am forgoing functional dependencies and going straight to type families/associated types in jhc. They are easier to implement and much cleaner IMHO. John On Mon, Dec 13, 2010 at 12:29 AM, Simon Peyton-Jones wrote:

Yes, I think type families are here to stay.

There is no formal policy about GHC extensions.  Generally speaking, I regard GHC as a "laboratory" in which to test ideas, which militates in favour of putting things in so that people can try them.  Once in they are hard to take out again (linear implicit parameters is a rare exception) because some come to rely on them.

If there's anything in particular you need, ask.  The main thing that is scheduled for an overhaul is the "derivable type class" mechanism, for which Pedro is working on a replacemement.

Simon

| -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell- | users-bounces@haskell.org] On Behalf Of Permjacov Evgeniy | Sent: 10 December 2010 19:42 | To: glasgow-haskell-users@haskell.org | Subject: Type families status | | Is it safe to consider type families and associated type families | extensions for ghc as stable ? Wich related extensions (flexible | contexts, undecidable instanses and so on) may be deprecated or changed | in near (2-3 years) future and wich may not? | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Oh, that explains the co error! Thanks a bunch. Cheers, Edward

Ok, looking at 4030, which is this simple program: main = do tid <- block $ forkIO $ let x = x in x killThread tid It segfaults in stg_BLACKHOLE_info when attempting to dereference... something (I haven't quite figured out what yet; what's usually stored in 0x4(%esi) on 32-bit x86 when entering _info blocks?) 0x822a6e0 : jmp 0x822a620 0x822a620 : mov 0x4(%esi),%eax 0x822a623 : test $0x3,%eax 0x822a628 : jne 0x822a663 0x822a62a : mov (%eax),%ecx -- SEGFAULT! Registers right at the segfault: eax 0x0 0 ecx 0x28 40 edx 0xb7a7e008 -1213734904 ebx 0x8289acc 136878796 esp 0xbfffcd98 0xbfffcd98 ebp 0xb7a808f8 0xb7a808f8 esi 0xb7a7f108 -1213730552 edi 0xb7a7f10c -1213730548 eip 0x822a62a 0x822a62a I believe this is because the code generator didn't write out the value to the heap, as seen comparing the correct and incorrect C-- (irrelevant stack/heap overflow checks elided): Correct: Hp = Hp + 8; if (Hp > I32[BaseReg + 92]) goto coY; I32[Hp - 4] = stg_CAF_BLACKHOLE_info; I32[Hp + 0] = I32[BaseReg + 96]; foreign "ccall" newCAF((BaseReg, PtrHint), (R1, PtrHint))[_unsafe_call_]; I32[R1 + 4] = Hp - 4; I32[R1] = stg_IND_STATIC_info; I32[Sp - 8] = stg_bh_upd_frame_info; I32[Sp - 4] = Hp - 4; Incorrect: _r7::I32 = R1; Sp = Sp + 4; Hp = Hp + 8; // outOfLine should follow: // allocDynClosure I32[Hp - 4] = stg_CAF_BLACKHOLE_info; _cpa::I32 = Hp - 4; // XXX: I32[Hp + 0] is never written!! I32[Sp - 16] = _cpa::I32; foreign "ccall" newCAF((BaseReg, PtrHint), (R1, PtrHint))[_unsafe_call_]; _cpa::I32 = I32[Sp - 16]; I32[R1 + 4] = _cpa::I32; I32[R1] = stg_IND_STATIC_info; _cpa::I32 = I32[Sp - 16]; // Hp - 4 I32[Sp - 8] = _cpa::I32; I32[Sp - 12] = stg_upd_frame_info; It's not clear to me where in the code generator to look to fix this though. Any pointers? Cheers, Edward

Hello Simon, Have you gotten a chance to look at these two hunks? (see below) Thanks, Edward Excerpts from Edward Z. Yang's message of Fri Dec 10 10:59:26 -0500 2010:

Ok, I've got a patch that fixes this segfault. In the process I looked at all patches to Cg* modules after Nov 2009 and looked for changes that weren't applied to the new codegen. I skipped the LLVM patch, but picked up the rest of the blackhole changes. There are, however, two hunks that I am not 100% sure how to translate.

hunk ./compiler/codeGen/CgClosure.lhs 477 - stmtC (CmmStore (CmmReg nodeReg) bh_info) + stmtsC [ + CmmStore (cmmOffsetW (CmmReg nodeReg) fixedHdrSize) + (CmmReg (CmmGlobal CurrentTSO)), + CmmCall (CmmPrim MO_WriteBarrier) [] [] CmmUnsafe CmmMayReturn, + CmmStore (CmmReg nodeReg) bh_info + ]

(the new code uses emits and a different format)

hunk ./compiler/codeGen/CgStackery.lhs 20 - pushUpdateFrame, emitPushUpdateFrame, + pushUpdateFrame, pushBHUpdateFrame, emitPushUpdateFrame,

A new pushBHUpdateFrame function was added, but I'm not sure how to translate this because the new codegenerator only reads out the offset from the FCode monad and there's no label to speak of.

Edward

With further poking, I think the new codegen is actually tickling an existing bug in the native code generator optimizations, since the cmmz output looks ok: cSH: _sQR::I32 = I32[_sRi::I32 + 3]; // CmmAssign _sQS::I32 = I32[_sRi::I32 + 7]; // CmmAssign _sQT::I32 = I32[_sRi::I32 + 11]; // CmmAssign _sQU::I32 = I32[_sRi::I32 + 15]; // CmmAssign (_sR1::I32) = call "ccall" arg hints: [`signed', PtrHint,] result hints: [] (_sQR::I32 & (-4))(_sQS::I32, _sQT::I32, _sQU::I32); // CmmUnsafeForeignCall And the only change is that in the original code generator, the assignment to _sQR is elided. _cSn::I32 = I32[R1 + 7]; _cSp::I32 = I32[R1 + 11]; _cSr::I32 = I32[R1 + 15]; (_sR1::I32,) = foreign "ccall" I32[R1 + 3]((_cSn::I32, `signed'), (_cSp::I32, PtrHint), (_cSr::I32,))[_unsafe_call_]; I further verified that there was no problem if I used -fvia-C. On closer inspection, the fact that _sQR is referenced nowhere in this dump should have raised alarms (I think the register allocater happened to assign it to the same register as _sRi, which is why the assembly looked vaguely plausible.) I'm still not sure where a fix might lie, but if I take another crack at it tomorrow I will probably figure it out. Cheers, Edward Excerpts from Edward Z. Yang's message of Wed Jan 12 17:10:11 -0500 2011:

I appear to have tracked down the bug for ffi021: the new code generator doesn't appear to clear the tag bit for the pointer to heap before:

// outOfLine should follow: (_sR1::I32,) = foreign "ccall" _sQR::I32((I32[_sRi::I32 + 7], `signed'), (I32[_sRi::I32 + 11], PtrHint), (I32[_sRi::I32 + 15],))[_unsafe_call_]; // emitReturn: Sequel: Assign ;

(gdb) disas Dump of assembler code for function sRi_info: => 0x0804aa6c <+0>: mov %esi,%eax 0x0804aa6e <+2>: lea 0x0(%ebp),%ecx 0x0804aa71 <+5>: cmp 0x54(%ebx),%ecx 0x0804aa74 <+8>: jb 0x804aab3 0x0804aa76 <+10>: add $0x4,%ebp 0x0804aa79 <+13>: add $0x8,%edi 0x0804aa7c <+16>: cmp 0x5c(%ebx),%edi 0x0804aa7f <+19>: ja 0x804aaa4 0x0804aa81 <+21>: pushl 0xf(%eax) 0x0804aa84 <+24>: pushl 0xb(%eax) 0x0804aa87 <+27>: pushl 0x7(%eax) 0x0804aa8a <+30>: call *%eax

The pushes to the stack properly untag eax, but then we just call the tagged pointer, which seems pretty wrong to me. Here is the old C--:

(_sR1::I32,) = foreign "ccall" I32[R1 + 3]((_cSc::I32, `signed'), (_cSe::I32, PtrHint), (_cSg::I32,))[_unsafe_call_];

Unfortunately, I can't figure out where this +3 is supposed to be happening, so I don't have a patch. Some guidance here would be appreciated.

Cheers, Edward

Yep, switching

inlineStmt u a (CmmCall target regs es srt ret) = CmmCall (infn target) regs es' srt ret where infn (CmmCallee fn cconv) = CmmCallee fn cconv infn (CmmPrim p) = CmmPrim p es' = [ (CmmHinted (inlineExpr u a e) hint) | (CmmHinted e hint) <- es

to

inlineStmt u a (CmmCall target regs es srt ret) = CmmCall (infn target) regs es' srt ret where infn (CmmCallee fn cconv) = CmmCallee (inlineExpr u a fn) cconv infn (CmmPrim p) = CmmPrim p es' = [ (CmmHinted (inlineExpr u a e) hint) | (CmmHinted e hint) <- es

Fixes it. Shall I submit a patch? Cheers, Edward

On 13/01/2011 19:29, Edward Z. Yang wrote:

*you feel a sudden sense of deja vu*

Here is my current play on things:

- I can probably get a devel2 build with the new codegen turned on for everything. This list of errors is from that build. However, this build was originally failing, so I'm going to do a fresh devel2 build and see if I've just got some weird Franken-GHC set up.

- I can't seem to get a devel1 build with the new codegen turned on for everything built: the first invocation to the stage2 compiler segfaults.

I've been debugging 4030, since I looked at it previously to resolve the black hole problems. Doing so has given me a sense of deja vu, but I think the failure mode this time is different. The resulting executable segfaults with -O and does not segfault with -O -fno-full-laziness (strangely enough, -O0 -ffull-laziness does not segfault). The failure crops up if you do -fnew-codegen or -fno-new-codegen.

In the debugger, I've tracked the bug down to this incorrect block of assembly:

Dump of assembler code for function c2Po_info: 0x08285ac4<+0>: mov 0x48(%ebx),%eax 0x08285ac7<+3>: mov 0x4c(%ebx),%ecx 0x08285aca<+6>: mov %eax,-0x4(%ebp) 0x08285acd<+9>: mov %ecx,0x0(%ebp) 0x08285ad0<+12>: add $0x4,%ebp 0x08285ad3<+15>: add $0xfffffff8,%ebp => 0x08285ad6<+18>: jmp 0x8285ad8

which fails to initialize the top two elements of the stack after increasing the stack by a word:

(gdb) pstk 0xb7a7d4c4: 0xb7a7f01c 0xb7a7d4c0: 0x5 0xb7a7d4bc: 0x7 0xb7a7d4b8: 0x8 0xb7a7d4b4: 0x8285d58 0xb7a7d4b0: 0xb7a82db8 0xb7a7d4ac: 0x2065832e 0xb7a7d4a8: 0x2065832e 0xb7a7d4a4: 0xb7a82de4 0xb7a7d4a0: 0x45 0xb7a7d49c: 0xdeadbeef 0xb7a7d498: 0x82812e0 0xb7a7d494: 0x2065832e 0xb7a7d490: 0x2065832e 0xb7a7d48c: 0x0 0xb7a7d488: 0x7a5d52b<- bogus

Perhaps I'm misunderstanding, but the above code looks fine (if a bit stupid). It looks like this C--: x = W_[R1 + 0x48] y = W_[R1 + 0x4c] Sp[-4] = x Sp[0] = y Sp = Sp + 4 Sp = Sp - 8 So you should end up with ... Sp[4] [R1 + 0x4c] Sp[0] [R1 + 0x48] perhaps check what R1 points to?

But I don't know where c2Po_info is coming from; it's not in the C-- dump of the program itself, so I assume it's in some library (but then why is it affected by optimizations?). Can I easily get C-- dumps of all the librarise?

It must be in a library - this is why -fno-new-codegen doesn't affect it, because the library is already compiled. You can grep for the symbol in the library .o files, and then compile the offending module with -ddump-cmm (the symbol name might change, so you might have to recompile and debug the program again to get the new symbol name). Cheers, Simon

I suspect that I should actually do the full (and not just fast) test suite on the stage2-new-codegen build to squirrel out more of these optimization bugs, since debugging a buggy stage2 compiler produced by a buggy stage1 compiler... does not seem like fun at all.

I might suspend this work until I'm back in town and we can have a chat in person. I guess I should put my repository somewhere :-)

Cheers, Edward

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users