Re: RFC: migrating to git
On 12/01/2011 22:22, Iavor Diatchki wrote: Hello, On Wed, Jan 12, 2011 at 11:44 AM, Roman Leshchinskiy r...@cse.unsw.edu.au mailto:r...@cse.unsw.edu.au wrote: On 12/01/2011, at 09:22, Simon Marlow wrote: On 11/01/2011 23:11, Roman Leshchinskiy wrote: A quick look at the docs seems to indicate that we'd need to do git pull git submodule update which doesn't look like a win over darcs-all. Also, I completely fail to understand what git submodule update does. It doesn't seem to pull all patches from the master repo. The git submodule docs are even worse than the rest of the git docs which is rather discouraging. True, however the build system could automatically check whether you had missed this step, because it could check the hashes. That would be an improvement. How do you pull submodule patches which the main repo doesn't depend on, though? Out of curiousity, has anyone here used submodules for something similar to what we would need? A submodule is basically a pointer to a particular state of a remote repo. So when you do git pull in GHC, you get changes to the code, and also changes to this pointer, but it won't automatically modify your local version of the sub-module repo. So at this point, if you started git gui you'd see that there is a mismatch between your local copy of the sub-module and the expected version. When you issue the command git submodule update, you are telling git to advance the sub-module repo to the expected version (i.e., where the pointer points to). The reason this does not happen automatically is that you might have also made changes to the submodule, so you might want to do some merging there, instead of just pulling. One thing to note is that if we were to set things up with sub-modules, then every now and then we would have to advance the GHC's expected pointer for various libraries to the latest (or a newer) version. Of course, we could have a script do this but, at least in theory, when someone makes a commit which updates the version of a sub-module, they are asserting that they things ought to work with the newer version of the sub-module. -Iavor PS: I've only used sub-module on what project at work. At first I too was quite confused about what was going on, but I've come to think that submodules are a pretty reasonable way to deal with a situation which is inherently complex. I spent quite some time yesterday playing with submodules to see if they would work for GHC. I'm fairly sure there are no fundamental reasons that we couldn't use them, but there are enough gotchas to put me off. I wrote down what I discovered here: http://hackage.haskell.org/trac/ghc/wiki/DarcsConversion#Submodules The workflow is quite involved - more steps than are required with darcs-all (understandable, because we're storing more information). However, git isn't particularly helpful if you make a mistake or forget to do something. I forsee spending a lot of time digging myself and Simon out of bizarre repository states. I discovered that Google have this tool called repo which is their darcs-all for the Android source tree. That might be worth looking at as an alternative in the future: https://sites.google.com/a/android.com/opensource/download/using-repo If we go with git, I suggest we stick with sync-all for the time being and think about either submodules or repo as possibilities for the future. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: migrating to git
On 12 Jan 2011, at 23:31, Edward Z. Yang ezy...@mit.edu wrote: Excerpts from Roman Leshchinskiy's message of Wed Jan 12 18:20:25 -0500 2011: How would we get the current functionality of darcs-all pull? Is it even possible? Here is the rebase-y workflow. Thank you making things clearer! # pull the latest patches for GHC, and sticks your patchset on top git pull --rebase # resolve any conflicts that occured during rebase # register any new submodules (if any) git submodule init # make your submodules reflect the latest version GHC has git submodule update --rebase This doesn't pull in all base patches, though, just the ones that GHC depends on, right? How would I get all base patches? Roman ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: migrating to git
On 13 January 2011 08:54, Roman Leshchinskiy r...@cse.unsw.edu.au wrote: On 12 Jan 2011, at 23:31, Edward Z. Yang ezy...@mit.edu wrote: Excerpts from Roman Leshchinskiy's message of Wed Jan 12 18:20:25 -0500 2011: How would we get the current functionality of darcs-all pull? Is it even possible? Here is the rebase-y workflow. Thank you making things clearer! # pull the latest patches for GHC, and sticks your patchset on top git pull --rebase # resolve any conflicts that occured during rebase # register any new submodules (if any) git submodule init # make your submodules reflect the latest version GHC has git submodule update --rebase This doesn't pull in all base patches, though, just the ones that GHC depends on, right? How would I get all base patches? cd libraries/base git pull [--rebase] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: New codegen failing test-cases
I think the bug might be here: 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 (from cmm/CmmOpt.hs) Note that it isn't substituting inside the 'fn' argument to CmmCallee, and it should be. This bug has been around for ages. Cheers, Simon On 13/01/2011 04:34, Edward Z. Yang wrote: 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: lea0x0(%ebp),%ecx 0x0804aa71+5: cmp0x54(%ebx),%ecx 0x0804aa74+8: jb 0x804aab3sRi_info+71 0x0804aa76+10:add$0x4,%ebp 0x0804aa79+13:add$0x8,%edi 0x0804aa7c+16:cmp0x5c(%ebx),%edi 0x0804aa7f+19:ja 0x804aaa4sRi_info+56 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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ti ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: migrating to git
On Wed, 12 Jan 2011, Claus Reinke wrote: What happens after the merges? Does one maintain the branches somehow, or does one lose the (in-)dependency information? Remember that a branch in git is just a name for a point in the revision graph. When you commit to a branch the name is updated to point to the new commit. Names are local to a particular repository. When you do a merge, you do it on a particular branch which is updated to point to the merge commit. The other branches that were merged in (there's usually one but you can create octopus merges if you want) remain as they were. The merge commit contains un-named pointers to its parent commits for use by git, and conventionally records the names of the brances that were merged in the commit message for the convenience of humans. You can commit to the other branches to extend them, or delete and reconstruct them differently, without affecting the state represented by the merge. Have a look the way topic branches are used in the maintenance of git itself as an example of how to deal with a collection of independent patches. http://git.kernel.org/?p=git/git.git;a=blob;f=MaintNotes;hb=refs/heads/todo Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: New codegen failing test-cases
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: New codegen failing test-cases
On 13/01/2011 12:51, Edward Z. Yang wrote: 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? Please do, yes. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
git repos for testing (was: Re: RFC: migrating to git)
I've made git mirrors of the current GHC HEAD repos (all of them), so people can try out their workflows with git. Hopefully this should work: git clone http://darcs.haskell.org/ghc-git/ghc.git cd ghc perl sync-all get You have to use sync-all instead of darcs-all, but the syntax is the same. e.g. to pull from upstream: perl sync-all pull Local clones should work: git clone local-ghc-repo cd ghc perl sync-all get and then a future 'perl sync-all pull' will pull fron the source, or you can pull from upstream with perl sync-all -r http://darcs.haskell.org/ghc-git pull The -r flag takes a remote or local repository, and works with push/pull/get, just like darcs-all. Note that sync-all is not executable, which is why I used perl sync-all rather than ./sync-all. You can chmod it, but the chmod will be seen as a local change by git which will get in the way of future pulls, and you'll need to stash or merge or rebase the change (welcome to git :-). The mirroring is manual right now. I might make it automatic, but it's not cheap (a few minutes CPU time each time it is invoked). The GHC repo is missing a few tags, I'm currently trying to sort that out. I haven't set up .gitignore yet, that's also on the todo list. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: git repos for testing (was: Re: RFC: migrating to git)
On Thu, Jan 13, 2011 at 4:03 PM, Simon Marlow marlo...@gmail.com wrote: I've made git mirrors of the current GHC HEAD repos (all of them), so people can try out their workflows with git. Poking around in the different repos works for me and is fast. For example: Find new files in base: $ cd libraries/base $ git status Find the definition and uses of threadWaitRead and skip git metadata $ git grep threadWaitRead See when threadWaitRead was added (and introduced in different files): $ git -SthreadWaitRead log (In 2001, by Simon M). Note that sync-all is not executable, which is why I used perl sync-all rather than ./sync-all. You can chmod it, but the chmod will be seen as a local change by git which will get in the way of future pulls, and you'll need to stash or merge or rebase the change (welcome to git :-). This particular problem is due to darcs (which we are mirroring) does not supporting executable permissions on files. We can just set the executable bit on the file and commit it. We should set up a git daemon at some point as it's much more efficient that pulling over HTTP. Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: git repos for testing (was: Re: RFC: migrating to git)
On 13 January 2011 15:30, Johan Tibell johan.tib...@gmail.com wrote: We should set up a git daemon at some point as it's much more efficient that pulling over HTTP. As of version 1.6.6, Git is much more efficient over HTTP than it used to be. http://progit.org/2010/03/04/smart-http.html In fact, GitHub are now using it as their default transport; they mention it in this blog post. https://github.com/blog/767-recent-services-interruptions Benedict. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: migrating to git
Hi, Just as a point of information, the following rules can help avoid some of the gotchas: - Treat submodules are read-only (i.e., don't make commits there). The reason for this is that a submodule is usually not on a branch, and so making a commit would result in a detached head. - When you pull (or change branches) use git submodule update to move the submodules to their correct versions (yes, it's annoying that one has to do that). - Changes to a sub-module should be done in a separate repo (not GHC's submodule). This is where you switch hats and become a base developer rather then a GHC developer for a bit, and use whatever workflow you normally use for development. - Every now and then you update the sub-module pointer of your GHC branch to a newer versions of the sub-module. You do this by setting the sub-module to the desired version (e.g., by a pull from its repo), and then committing the change to the submodule version (perhaps with other GHC changes). I agree with Simon's assessment that it is probably a good idea to start without submodules, at least until all developers are comfortable with the rest of git's model. -Iavor On Thu, Jan 13, 2011 at 12:49 AM, Simon Marlow marlo...@gmail.com wrote: On 12/01/2011 22:22, Iavor Diatchki wrote: Hello, On Wed, Jan 12, 2011 at 11:44 AM, Roman Leshchinskiy r...@cse.unsw.edu.au mailto:r...@cse.unsw.edu.au wrote: On 12/01/2011, at 09:22, Simon Marlow wrote: On 11/01/2011 23:11, Roman Leshchinskiy wrote: A quick look at the docs seems to indicate that we'd need to do git pull git submodule update which doesn't look like a win over darcs-all. Also, I completely fail to understand what git submodule update does. It doesn't seem to pull all patches from the master repo. The git submodule docs are even worse than the rest of the git docs which is rather discouraging. True, however the build system could automatically check whether you had missed this step, because it could check the hashes. That would be an improvement. How do you pull submodule patches which the main repo doesn't depend on, though? Out of curiousity, has anyone here used submodules for something similar to what we would need? A submodule is basically a pointer to a particular state of a remote repo. So when you do git pull in GHC, you get changes to the code, and also changes to this pointer, but it won't automatically modify your local version of the sub-module repo. So at this point, if you started git gui you'd see that there is a mismatch between your local copy of the sub-module and the expected version. When you issue the command git submodule update, you are telling git to advance the sub-module repo to the expected version (i.e., where the pointer points to). The reason this does not happen automatically is that you might have also made changes to the submodule, so you might want to do some merging there, instead of just pulling. One thing to note is that if we were to set things up with sub-modules, then every now and then we would have to advance the GHC's expected pointer for various libraries to the latest (or a newer) version. Of course, we could have a script do this but, at least in theory, when someone makes a commit which updates the version of a sub-module, they are asserting that they things ought to work with the newer version of the sub-module. -Iavor PS: I've only used sub-module on what project at work. At first I too was quite confused about what was going on, but I've come to think that submodules are a pretty reasonable way to deal with a situation which is inherently complex. I spent quite some time yesterday playing with submodules to see if they would work for GHC. I'm fairly sure there are no fundamental reasons that we couldn't use them, but there are enough gotchas to put me off. I wrote down what I discovered here: http://hackage.haskell.org/trac/ghc/wiki/DarcsConversion#Submodules The workflow is quite involved - more steps than are required with darcs-all (understandable, because we're storing more information). However, git isn't particularly helpful if you make a mistake or forget to do something. I forsee spending a lot of time digging myself and Simon out of bizarre repository states. I discovered that Google have this tool called repo which is their darcs-all for the Android source tree. That might be worth looking at as an alternative in the future: https://sites.google.com/a/android.com/opensource/download/using-repo If we go with git, I suggest we stick with sync-all for the time being and think about either submodules or repo as possibilities for the future. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: migrating to git
On 12 January 2011 22:13, Claus Reinke claus.rei...@talk21.com wrote: You can emulate darcs's patch re-ordering in git if you put each independent sequence of patches on a separate branch. Then you can re-merge the branches in whatever order you want. This is a fairly common git workflow. What happens after the merges? Does one maintain the branches somehow, or does one lose the (in-)dependency information? If you are interested in this approach. you can check out Iolaus, which is David Roundy's attempt at getting Darcs-style revision control in Git: https://github.com/droundy/iolaus. I think that it relies on you, the user, to accurately specify which patches a new one of your own depends on, which is a bit of a limitation. Cheers, Max ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: migrating to git
On Thu, Jan 13 2011, Simon Marlow wrote: I discovered that Google have this tool called repo which is their darcs-all for the Android source tree. That might be worth looking at as an alternative in the future: https://sites.google.com/a/android.com/opensource/download/using-repo If we go with git, I suggest we stick with sync-all for the time being and think about either submodules or repo as possibilities for the future. The author of Gerrit/Repo has stated that he intends to have better integration between repo and git submodules, but so far he hasn't been putting all that much effort into it. If that were completed, repo would just be a much better way of managing submodules. David ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: git repos for testing (was: Re: RFC: migrating to git)
On Thu, Jan 13 2011, Benedict Eastaugh wrote: On 13 January 2011 15:30, Johan Tibell johan.tib...@gmail.com wrote: We should set up a git daemon at some point as it's much more efficient that pulling over HTTP. As of version 1.6.6, Git is much more efficient over HTTP than it used to be. http://progit.org/2010/03/04/smart-http.html You do have to install the git smart-http plugin in the server, or it only uses the dumb HTTP protocol. David ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: New codegen failing test-cases
Ok, I have a stage2 compiler built with the new codegen all the way, and here are the new failing cases: 1372(normal) 2047(normal) 4030(normal) OldException001(normal) async001(normal) bug1465(normal) cabal01(normal) cabal03(normal) cgrun016(normal) cgrun045(normal) copyFile002(normal) dsrun005(normal) dsrun008(normal) exceptionsrun002(normal) ffi008(normal) getDirContents002(normal) hGetLine002(normal) hSeek004(normal) hTell002(normal) hash001(normal) ioeGetHandle001(normal) openFile002(normal) process003(normal) readwrite002(normal) simplrun010(optc) strun002(optc) Based on the composition of these bugs, my guess is that maybe the foreign function call part of the generator is still a little mushy. Cheers, Edward ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: migrating to git
On 01/13/2011 12:49 AM, Simon Marlow wrote: I spent quite some time yesterday playing with submodules to see if they would work for GHC. I'm fairly sure there are no fundamental reasons that we couldn't use them, but there are enough gotchas to put me off. I wrote down what I discovered here: http://hackage.haskell.org/trac/ghc/wiki/DarcsConversion#Submodules I think the what works section of there is already pretty compelling -- for example, it's an annoyance that darcs-all diff produces a diff file which mashes together all the subrepos and can't be applied at the top level. It's another annoyance that darcs diff doesn't produce unified diffs by default, what's the point of a diff that can't be |patch-ed? It seems from your discussion that subrepos are intended for your category the rest of libraries (e.g. filepath, containers, bytestring, editline) i.e. things that you expect to passively track and occasionally pick up new patches from. What's the argument against using subrepos for those? To me, the major gotcha is git submodule update detaching the changes, however changing the default to be a --merge would fix that for me. What about that don't you like? Would you rather want a git submodule update --just-complain-and-exit? The last 2 drawbacks you mention (pushing to submodules first and needing to commit to GHC for every subrepo commit) is IMHO the price to pay for a guarantee that you're always able to check out a coherent set of changes. If that's too onerous, maybe some of those libraries just belong in the main GHC repo. I'm another interested bystander who thinks that git would be a step forward, btw. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: New codegen failing test-cases
*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: mov0x48(%ebx),%eax 0x08285ac7 +3: mov0x4c(%ebx),%ecx 0x08285aca +6: mov%eax,-0x4(%ebp) 0x08285acd +9: mov%ecx,0x0(%ebp) 0x08285ad0 +12:add$0x4,%ebp 0x08285ad3 +15:add$0xfff8,%ebp = 0x08285ad6 +18:jmp0x8285ad8 c2PT_entry 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 c2M9_info 0xb7a7d4b0: 0xb7a82db8 0xb7a7d4ac: 0x2065832e 0xb7a7d4a8: 0x2065832e 0xb7a7d4a4: 0xb7a82de4 0xb7a7d4a0: 0x45 0xb7a7d49c: 0xdeadbeef 0xb7a7d498: 0x82812e0 c4i4_info 0xb7a7d494: 0x2065832e 0xb7a7d490: 0x2065832e 0xb7a7d48c: 0x0 0xb7a7d488: 0x7a5d52b - bogus 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? 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
Re: [Haskell] ANN: extcore 1.0
On 2011-01-13 14:45, Tim Chevalier wrote: Documentation for the External Core format itself lives at http://www.haskell.org/ghc/docs/latest/html/ext-core/core.pdf Didn't find it there, but did find it at http://www.haskell.org/ghc/docs/latest/core.pdf ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: git repos for testing
Hello Simon, I've made git mirrors of the current GHC HEAD repos (all of them), so people can try out their workflows with git. Hopefully this should work: git clone http://darcs.haskell.org/ghc-git/ghc.git cd ghc perl sync-all get Thank you for this work. I cloned the git repository and tried to compile GHC. But perl boot does not work. % perl boot Unpacking time Failed to open stamp file: No such file or directory at boot-pkgs line 41. Running boot-pkgs failed: 512 at boot line 23. How can I create the configure script with GHC from this repository? --Kazu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
