August 2013 - ghc-devs

Re: Building on windows
by Kyle Van Berendonck 23 Aug '13

23 Aug '13

Additionally, if you're using the latest MinGW it ships with GCC 4.7 and fails with an error I reported and thoughtpolice replied here; http://ghc.haskell.org/trac/ghc/ticket/7056#comment:9 There's a patch that (with some hacking, namely, fixing the missing bracket) will bring GHC to build. It later faults again, though. http://lpaste.net/92097 Windows needs some love :(

1 0

HEADS UP: interface file change
by Austin Seipp 23 Aug '13

23 Aug '13

Hi all, I merged patches from #8144 into HEAD to fix nasty recompilation-checking behavior. As a result, the interface format has changed, so you'll need to clean your tree the next time you sync up. -- Regards, Austin - PGP: 4096R/0x91384671

1 0

Reproducible build recipes for GHC development VMs?
by Ryan Newton 23 Aug '13

23 Aug '13

Hi all, Returning to the topic discussed by Simon M. and others here: http://projects.haskell.org/pipermail/haskell-platform/2009-July/000572.html This is my attempt at a script for bootstrapping a GHC-validating VM: http://parfunk.blogspot.com/2013/08/zero-to-ghc-development-in-ubuntu-vm-in… Let me know if there's a better way, or if you'd like to help get this kind of thing into an even more accessible form (Amazon AMI, Chef recipe, etc). Cheers, -Ryan

4 6

how to checkout proper submodules
by Kazu Yamamoto 23 Aug '13

23 Aug '13

Hi, Andreas and I found that the new IO manager is not working properly in the current GHC head. I'm sure that it worked well at least on May 7. We need to narrow the range of commits, so I did: % git checkout bb2795db36b36966697c228315ae20767c4a8753 % git submodule update But this does not checkout proper submodules. For instance, libraries/base has newer commits. And of cource, building fails. Please tell us how to checkout proper submodules against a specific GHC tree. --Kazu

21 43

Active Branches
by Austin Seipp 23 Aug '13

23 Aug '13

All, A while back, Nicolas Frisby compiled a small list of the currently active branches in the GHC tree. I would like to clean up a lot of the existing branches which are effectively dead (by deleting them.) At the same time, it's nice to take inventory and see what's currently out there, or 'in limbo'. http://ghc.haskell.org/trac/ghc/wiki/ActiveBranches I have kept up with *most* of the branches, and filled out a bunch of details above, greatly expanding the list. However, several are light on details and I'm not sure what's up with all of them, so I'd appreciate your input if you own a branch. I do however, believe all the 'dead' branches are accurate. If you're working on a branch, please note it here. I'd like for people to keep better track of this with a small note on this page; perhaps putting a link on the front of the wiki is a good idea. I'd like to be able to delete a lot of the defunct branches sometime soon, so just let me know in the mean time. -- Regards, Austin - PGP: 4096R/0x91384671

2 1

Re: [commit: testsuite] master: linker_unload fails when using dynamic GHCi. (a5875c4)
by Simon Marlow 23 Aug '13

23 Aug '13

On 22/08/13 19:24, git(a)git.haskell.org wrote: > Repository : ssh://git@git.haskell.org/testsuite > > On branch : master > Link : http://ghc.haskell.org/trac/ghc/changeset/a5875c4e4fb83993142c8e8294b47516a… > >> --------------------------------------------------------------- > > commit a5875c4e4fb83993142c8e8294b47516adf6a77f > Author: Austin Seipp <aseipp(a)pobox.com> > Date: Thu Aug 22 13:22:22 2013 -0500 > > linker_unload fails when using dynamic GHCi. > > This is because dynamic GHCi can't load archive files, and linker_unload > explicitly does this via loadArchive(). Sigh. I've no idea why the linker has an explicit check for this, there's no reason why it can't work. I'll fix it. Cheers, Simon

2 1

Validate failures
by Austin Seipp 23 Aug '13

23 Aug '13

Simon, While validating the changes for #8144, I noticed there were several failures that seem like a result of your recent commits (amd64/Linux): Unexpected failures: . T4059 [bad stderr] (normal) . T4850 [bad stderr] (normal) . T5423 [bad stderr] (normal) . T7037 [bad stderr] (normal) . atomicinc [exit code non-0] (normal) . outofmem [bad stderr] (normal) . outofmem2 [bad stderr] (normal) I see several of the these fail, like: =====> T7037(normal) 1205 of 3760 [0, 6, 0] cd ./rts && $MAKE -s --no-print-directory T7037 </dev/null >T7037.run.stdout 2>T7037.run.stderr Actual stderr output differs from expected: --- /dev/null 2013-08-15 19:58:16.771097011 -0500 +++ ./rts/T7037.run.stderr 2013-08-22 13:27:33.531638515 -0500 @@ -0,0 +1 @@ +Makefile:74: xxx/home/a/ghc/ghc-pristine/libraries/base/dist-install/buildxxx *** unexpected failure for T7037(normal) This is because in 269c89062dd5b6d2b8bc4d41e5dca0eca2308d02, you added: +$(warning xxx$(BASE_DIR)xxx) Which I presume is perhaps left-over debugging cruft? I also see this failure: $ make TEST="atomicinc" ... =====> atomicinc(normal) 15 of 41 [0, 0, 0] cd . && '/home/a/ghc/ghc-pristine/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -o atomicinc atomicinc.c -no-hs-main >atomicinc.comp.stderr 2>&1 Compile failed (status 256) errors were: Warning: -rtsopts and -with-rtsopts have no effect with -no-hs-main. Call hs_init_ghc() from your main() function to set these options. atomicinc.o: In function `main': atomicinc.c:(.text+0x20): undefined reference to `atomic_inc' atomicinc.c:(.text+0x60): undefined reference to `atomic_dec' collect2: error: ld returned 1 exit status But I'm not sure what's causing it, since this hasn't been touched in a while. -- Regards, Austin - PGP: 4096R/0x91384671

2 3

DPH tests
by Jan Stolarek 22 Aug '13

22 Aug '13

When I do full testsuite run (either with 'make fulltest' or './validate --slow') there is a bunch of DPH tests which take Very Long Time to run (approx. half of the time needed to run testsuite, if not more). These tests are consistently failing. What would DPH team and others say to disabling these tests temporarily? I think that since February there hasn't been much going on in the DPH repository and compiler/vectorize folder. We'd have thhese tests enabled again when work on DPH picks up again. Janek

3 4

can't build head: parser file name / module name conflict
by Carter Schonwald 22 Aug '13

22 Aug '13

hey all, i'm trying to build head to test out some stuff, and i'm hitting the following error message (http://ghc.haskell.org/trac/ghc/ticket/8143 ) compiler/stage1/build/Parser.hs:1:1: File name does not match module name: Saw: `Main' Expected: `Parser' make[1]: *** [compiler/stage1/build/.depend-v.haskell] Error 1 any thoughts?

3 2

What are the current rules about object duplication during GC?
by Ryan Newton 22 Aug '13

22 Aug '13

Is the status quo still the same as it was in this paper? http://research.microsoft.com/en-us/um/people/simonpj/papers/parallel-gc/pa… That is, there is a low-probability that a race will result in immutable objects being duplicated, but not mutable objects. But that leaves me wondering exactly which types are currently included in the duplicatable vs. "take the lock" category [2]. The reason I'm asking is because *defeating GHC compile-time and runtime optimizations* is precisely the goal of the recent work to make a safe/reliable infrastructure for CAS-based lockfree data structures in GHC. For example, the atomic-primops package uses the Any kind and type coercions to store objects (pointers) in a form that makes them opaque to the compiler, preventing them from being unboxed and reboxed (changing pointer identity). Actually, the current policy of this library that false negatives (failing CAS) must be tolerated, which is *usually* not an onerous obligation. So if the heap objects in question CAN be duplicated, that is still ok, but I would like to know if it is the case, that is, if Any is treated any differently than, say, Int. My guess is *no, *but I'd like to confirm this. That is, it seems that Anyeffects the compiler (which promises not to enter the pointer<http://www.haskell.org/ghc/docs/7.6.3/html/libraries/ghc-prim-0.3.0.0/GHC-P…>), but the physical representation of a thunk or function doesn't change, and thus the GC must treat those objects exactly as it would if they were *not*coerced to Any. Sound right? Cheers, -Ryan [1] P.S. The places I checked before asking on this list were here: http://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/GC And here: http://ghc.haskell.org/trac/ghc/wiki/GarbageCollectorNotes If there is newer documentation for the GC, please let me know. [2] One hint is on line 531 of StgMiscClosures.cmm<https://github.com/ghc/ghc/blob/d61c623ed6b2d352474a7497a65015dbf6a72e12/rt…> : // PRIM rather than CONSTR, because PRIM objects cannot be duplicated by the GC. Yet there are 62 different types of objects in ClosureTypes.hs, so I'm not sure what all the rules are.

2 1