- ghc-devs - Haskell.org

worker-wrapper correctness
by Joachim Breitner 28 Nov '13

28 Nov '13

Hi, I first planned to post this to https://ghc.haskell.org/trac/ghc/ticket/1600 but it might be of wider interest, and is not only related to CPR. SPJ pointed me to this¹ paper by Graham Hutton (thanks for that). It lists three sufficient conditions for the w/w-wrapper to be semantically correct: (1) wrap ◦ unwrap = id (2) wrap ◦ unwrap ◦ body = body (3) fix (wrap ◦ unwrap ◦ body) = fix body The first one is often not true when we do w/w in GHC. The third one seems to be out of reach: Arguing about a recursive function in this way smells like solving the halting problem. So it seems that we should be aiming for (2) wrap ◦ unwrap ◦ body = body With this in mind, setting the CPR info of recursive things to ⊤, i.e. “we don’t know anything” _when analyzing their RHS_ should do the right thing: If we assume nothing about the argument of `body`, the result will hold for all, which precisely is `wrap ◦ unwrap ◦ body = body`. And this should be the case not only for CPR, but for anything that does a w/w-transformation, i.e. Demand analysis as well. But what about strictness analysis? Clearly, for f :: Int -> Int -> Int f n m = if n == 0 then m else f (n-1) m we want to know (as we do in 7.6. and in HEAD) that it is strict in m... Interesting fact here: GHC-7.6 will find this worker signature wf :: Int# -> Int -> Int (which is compatible with condition (2)), but GHC HEAD will do wf :: Int# -> Int# -> Int# where equation (2) is no longer holds. In this case (3) happens to hold (at least wrt to a semantics that does not distinguish non-termination of other kinds of ⊥). Conclusion: The correctness of GHC’s w/w-transformation is currently not formally well supported, and it only works due to delicate and non-obvious² interaction between the analysis and the transformation (see comment 20 of #1600 for an example how easily it breaks). But if we systematically ensure the correctness, by always guaranteeing (2), we are losing existing chances for optimization. Some more less consistent thoughts: There seems to be a conceptual difference between the CPR w/w-transformation and the others: Unboxing arguments pulls work out of the worker to be done _before_ it is being called. Clearly, this will never make the recursive call to the work diverge, unless it would diverge anyways. And if the work pulled out diverges (e.g. if m = undefined in the example above), then either the worker would have diverged (but that is fine) or, assuming the analysis is correct, would have performed the work. So for these transformations it is ok to use the full information in the recursive case. But the CPR transformation is different: The w/w transformation forces the evaluation of the result of the recursive call and in that sense moves work into it. And if this again triggers work to be moved into the next recursive calls, we can cause divergence. So by this handwavy argument, we are fine for unboxing arguments and strictness analysis, but for CPR we really should forget what we know about the f when analyzing f’s body. Thanks for your attention, Joachim ¹ http://www.cs.nott.ac.uk/~gmh/wrapper.pdf ² to me at least – I might be missing something -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nomeata(a)debian.org

1 0

RTS warnings
by Gabor Greif 27 Nov '13

27 Nov '13

Hi all! I spottes these warnings in today's $ make INTEGER_LIBRARY=integer-simple V=0 build: rts/Stats.c: In function 'stat_exit': rts/Stats.c:695:0: warning: format '%16zu' expects type 'size_t', but argument 2 has type 'unsigned int' rts/sm/Storage.c: In function 'flushExec': rts/sm/Storage.c:1294:0: warning: implicit declaration of function '__builtin___clear_cache' rts/sm/Storage.c:1294:0: warning: nested extern declaration of '__builtin___clear_cache' this is my "GCC": ggreif$ gcc --version i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00) Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Cheers, Gabor PS: there is also this low-hanging fruit: libraries/containers/Data/IntSet/Base.hs:1196:17: Warning: In the use of 'bitSize' (imported from Data.Bits): Deprecated: "Use bitSizeMaybe or finiteBitSize instead"

2 1

Cannot instantiate unification variable
by Kazu Yamamoto 26 Nov '13

26 Nov '13

Hi, Recent GHC head on 32bit Linux cannot build conduit-1.0.9.2. (See the attached log.) A while ago, GHC head on 32bit Linux could build it. The same GHC head on 64bit Linux can build it. Michael Snoyman suggested me to add ImpredicativeTypes. When I added it to the Internal.hs, GHC head on 32bit Linux can build it. And he said to other released GHCs can build it. Actually, GHC 7.4.2 on 32bit Linux can build it. He believes that this is a bug of GHC head (on 32bit Linux). Any information? Note that conduit-1.0.9.3 already includes ImpredicativeTypes. --Kazu Building conduit-1.0.9.2... Preprocessing library conduit-1.0.9.2... [2 of 8] Compiling Data.Conduit.Internal ( Data/Conduit/Internal.hs, dist/build/Dat a/Conduit/Internal.o ) Data/Conduit/Internal.hs:211:105: Cannot instantiate unification variable ‛b0’ with a type involving foralls: (forall a. m1 a -> n1 a) -> ConduitM i o m1 b1 -> ConduitM i o n1 b1 Perhaps you want ImpredicativeTypes In the expression: GHC.Exts.coerce (hoist :: (forall (a :: *). m a -> n a) -> Pipe i i o () m b -> Pipe i i o () n b) :: forall (m :: * -> *) (b :: *) (n :: * -> *). Monad m => (forall (a :: *). m a -> n a) -> ConduitM i o m b -> ConduitM i o n b In an equation for ‛hoist’: hoist = GHC.Exts.coerce (hoist :: (forall (a :: *). m a -> n a) -> Pipe i i o () m b -> Pipe i i o () n b) :: forall (m :: * -> *) (b :: *) (n :: * -> *). Monad m => (forall (a :: *). m a -> n a) -> ConduitM i o m b -> ConduitM i o n b

2 1

Link error with head Re: [commit: ghc] master: GHCi: Properly generate jump code for ARM (#8380) (5bab1a5)
by Amos Robinson 26 Nov '13

26 Nov '13

Hi, I'm having trouble linking with head: > [1 of 1] Compiling Main ( bindisttest/HelloWorld.lhs, bindisttest/HelloWorld.o ) > Linking bindisttest/HelloWorld ... > Undefined symbols for architecture x86_64: > "___builtin___clear_cache", referenced from: > _flushExec in libHSrts.a(Storage.o) > ld: symbol(s) not found for architecture x86_64 > collect2: ld returned 1 exit status This is on OSX 10.8.5, where gcc --version gives me > i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00) I get the impression that this commit is related. Is it the case that Apple switched from gcc to clang recently? Could that be why ___builtin__clear_cache is missing? I'm sorry, I don't really know anything about the runtime system, so am kind of stuck. On Sat, Nov 23, 2013 at 1:22 AM, <git(a)git.haskell.org> wrote: > Repository : ssh://git@git.haskell.org/ghc > > On branch : master > Link : http://ghc.haskell.org/trac/ghc/changeset/5bab1a57f572e29dfdffd6d1ce8e53a27… > >>--------------------------------------------------------------- > > commit 5bab1a57f572e29dfdffd6d1ce8e53a2772b18fd > Author: Austin Seipp <austin(a)well-typed.com> > Date: Mon Nov 11 10:26:03 2013 -0600 > > GHCi: Properly generate jump code for ARM (#8380) > > This adds code for jumping to given addresses for ARM, written by Ben > Gamari. > > However, when allocating new infotables for bytecode (which is where > this jump code occurs), we need to be sure to flush the cache on the > execute pointer returned from allocateExec() - on systems like ARM, the > processor won't reliably read back code or automatically cache flush, > where x86 will. > > So we add a new flushExec primitive to call out to GCC's > __builtin___clear_cache primitive, which will properly generate the > correct code (nothing on x86, and a call to libgcc's __clear_cache on > ARM) and make sure we use it after writing the code out. > > Authored-by: Ben Gamari <bgamari.foss(a)gmail.com> > Authored-by: Austin Seipp <austin(a)well-typed.com> > Signed-off-by: Austin Seipp <austin(a)well-typed.com> > > >>--------------------------------------------------------------- > > 5bab1a57f572e29dfdffd6d1ce8e53a2772b18fd > compiler/ghci/ByteCodeItbls.lhs | 21 ++++++++++++++++++++- > includes/rts/storage/GC.h | 1 + > rts/Linker.c | 1 + > rts/sm/Storage.c | 27 +++++++++++++++++++++++++++ > 4 files changed, 49 insertions(+), 1 deletion(-) > > diff --git a/compiler/ghci/ByteCodeItbls.lhs b/compiler/ghci/ByteCodeItbls.lhs > index 0d07be5..2180f87 100644 > --- a/compiler/ghci/ByteCodeItbls.lhs > +++ b/compiler/ghci/ByteCodeItbls.lhs > @@ -227,6 +227,20 @@ mkJumpToAddr dflags a = case platformArch (targetPlatform dflags) of > , fromIntegral (w64 .&. 0x0000FFFF) > , fromIntegral ((w64 `shiftR` 32) .&. 0x0000FFFF) ] > > + ArchARM { } -> > + -- Generates Thumb sequence, > + -- ldr r1, [pc, #0] > + -- bx r1 > + -- > + -- which looks like: > + -- 00000000 <.addr-0x8>: > + -- 0: 4900 ldr r1, [pc] ; 8 <.addr> > + -- 4: 4708 bx r1 > + let w32 = fromIntegral (ptrToInt a) :: Word32 > + in Left [ 0x49, 0x00 > + , 0x47, 0x08 > + , byte0 w32, byte1 w32, byte2 w32, byte3 w32] > + > arch -> > panic ("mkJumpToAddr not defined for " ++ show arch) > > @@ -374,11 +388,16 @@ load = do addr <- advance > newExecConItbl :: DynFlags -> StgConInfoTable -> IO (FunPtr ()) > newExecConItbl dflags obj > = alloca $ \pcode -> do > - wr_ptr <- _allocateExec (fromIntegral (sizeOfConItbl dflags obj)) pcode > + let sz = fromIntegral (sizeOfConItbl dflags obj) > + wr_ptr <- _allocateExec sz pcode > ex_ptr <- peek pcode > pokeConItbl dflags wr_ptr ex_ptr obj > + _flushExec sz ex_ptr -- Cache flush (if needed) > return (castPtrToFunPtr ex_ptr) > > foreign import ccall unsafe "allocateExec" > _allocateExec :: CUInt -> Ptr (Ptr a) -> IO (Ptr a) > + > +foreign import ccall unsafe "flushExec" > + _flushExec :: CUInt -> Ptr a -> IO () > \end{code} > diff --git a/includes/rts/storage/GC.h b/includes/rts/storage/GC.h > index 8133496..f8b8afe 100644 > --- a/includes/rts/storage/GC.h > +++ b/includes/rts/storage/GC.h > @@ -161,6 +161,7 @@ typedef void* AdjustorWritable; > typedef void* AdjustorExecutable; > > AdjustorWritable allocateExec(W_ len, AdjustorExecutable *exec_addr); > +void flushExec(W_ len, AdjustorExecutable exec_addr); > #if defined(ios_HOST_OS) > AdjustorWritable execToWritable(AdjustorExecutable exec); > #endif > diff --git a/rts/Linker.c b/rts/Linker.c > index 77943a5..14ebac3 100644 > --- a/rts/Linker.c > +++ b/rts/Linker.c > @@ -1350,6 +1350,7 @@ typedef struct _RtsSymbolVal { > SymI_HasProto(g0) \ > SymI_HasProto(allocate) \ > SymI_HasProto(allocateExec) \ > + SymI_HasProto(flushExec) \ > SymI_HasProto(freeExec) \ > SymI_HasProto(getAllocations) \ > SymI_HasProto(revertCAFs) \ > diff --git a/rts/sm/Storage.c b/rts/sm/Storage.c > index 112ad83..c1a1a5a 100644 > --- a/rts/sm/Storage.c > +++ b/rts/sm/Storage.c > @@ -1152,6 +1152,15 @@ AdjustorWritable allocateExec (W_ bytes, AdjustorExecutable *exec_ret) > return (ret + 1); > } > > +void flushExec (W_ len, AdjustorExecutable exec_addr) > +{ > + /* On ARM and other platforms, we need to flush the cache after > + writing code into memory, so the processor reliably sees it. */ > + unsigned char* begin = (unsigned char*)exec_addr; > + unsigned char* end = begin + len; > + __builtin___clear_cache(begin, end); > +} > + > // freeExec gets passed the executable address, not the writable address. > void freeExec (AdjustorExecutable addr) > { > @@ -1198,6 +1207,15 @@ AdjustorWritable execToWritable(AdjustorExecutable exec) > return writ; > } > > +void flushExec (W_ len, AdjustorExecutable exec_addr) > +{ > + /* On ARM and other platforms, we need to flush the cache after > + writing code into memory, so the processor reliably sees it. */ > + unsigned char* begin = (unsigned char*)exec_addr; > + unsigned char* end = begin + len; > + __builtin___clear_cache(begin, end); > +} > + > void freeExec(AdjustorExecutable exec) > { > AdjustorWritable writ; > @@ -1251,6 +1269,15 @@ AdjustorWritable allocateExec (W_ bytes, AdjustorExecutable *exec_ret) > return ret; > } > > +void flushExec (W_ len, AdjustorExecutable exec_addr) > +{ > + /* On ARM and other platforms, we need to flush the cache after > + writing code into memory, so the processor reliably sees it. */ > + unsigned char* begin = (unsigned char*)exec_addr; > + unsigned char* end = begin + len; > + __builtin___clear_cache(begin, end); > +} > + > void freeExec (void *addr) > { > StgPtr p = (StgPtr)addr - 1; > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits

2 6

Cannot build tagged with HEAD
by Edsko de Vries 25 Nov '13

25 Nov '13

I'm getting the errors below if I try to build tagged with head: src/Data/Tagged.hs:57:5: 'Tagged' is applied to too many type arguments In an expression type signature: Tagged k s b -> Tagged k s b -> Bool In the expression: ghc-prim:GHC.Prim.coerce ((==) :: b -> b -> Bool) :: Tagged k s b -> Tagged k s b -> Bool In an equation for '==': (==) = ghc-prim:GHC.Prim.coerce ((==) :: b -> b -> Bool) :: Tagged k s b -> Tagged k s b -> Bool src/Data/Tagged.hs:57:9: 'Tagged' is applied to too many type arguments In an expression type signature: Tagged k s b -> Tagged k s b -> Ordering In the expression: ghc-prim:GHC.Prim.coerce (compare :: b -> b -> Ordering) :: Tagged k s b -> Tagged k s b -> Ordering In an equation for 'compare': compare = ghc-prim:GHC.Prim.coerce (compare :: b -> b -> Ordering) :: Tagged k s b -> Tagged k s b -> Ordering src/Data/Tagged.hs:57:14: 'Tagged' is applied to too many type arguments In an expression type signature: (,) (Tagged k s b) (Tagged k s b) -> [] (Tagged k s b) In the expression: ghc-prim:GHC.Prim.coerce (range :: (,) b b -> [] b) :: (,) (Tagged k s b) (Tagged k s b) -> [] (Tagged k s b) In an equation for 'range': range = ghc-prim:GHC.Prim.coerce (range :: (,) b b -> [] b) :: (,) (Tagged k s b) (Tagged k s b) -> [] (Tagged k s b) src/Data/Tagged.hs:57:18: 'Tagged' is applied to too many type arguments In an expression type signature: Tagged k s b In the expression: ghc-prim:GHC.Prim.coerce (minBound :: b) :: Tagged k s b In an equation for 'minBound': minBound = ghc-prim:GHC.Prim.coerce (minBound :: b) :: Tagged k s b Line 57 is the "(" in newtype Tagged s b = Tagged { unTagged :: b } deriving ( Eq, Ord, Ix, Bounded #if __GLASGOW_HASKELL__ >= 707 , Typeable #endif ) Anyone any ideas what's going on? -E

3 3

RE: bundle panic
by Simon Peyton-Jones 22 Nov '13

22 Nov '13

I've looked into this myself. I don't think it's actually anything wrong in gmp-wrappers. It's because CmmBuildInfoTables expects all the info tables in the (CmmProc info_tbls lbl g) to be defined in the graph g. But Jan's new optimisation to the stack overflow check (Note [Always false stack check] in CmmLayoutStack) ends up dropping a conditional branch, so a call to gc is eliminated, and hence a proc point is eliminated, and we end up with an unused thing in info_tbls, which confuses CmmBuildInfoTables Sigh. I don't know why this only happens on Windows. I'm looking into a fix Simon From: Simon Peyton-Jones Sent: 15 November 2013 22:18 To: ghc-devs(a)haskell.org Subject: bundle panic Windows build is failing again in a new way. It was fine a couple of days ago. Does this ring any bells? ghc-stage1.exe: panic! (the 'impossible' happened) (GHC version 7.7.20131107 for i386-unknown-mingw32): bundle Simon "inplace/bin/ghc-stage1.exe" -static -H32m -O -Werror -Wall -H64m -O0 -package-name integer-gmp-0.5.1.0 -hide-all-packages -i -ilibraries/integer-gmp/. -ilibraries/integer-gmp/dist-install/build -ilibraries/integer-gmp/dist-install/build/autogen -Ilibraries/integer-gmp/dist-install/build -Ilibraries/integer-gmp/dist-install/build/autogen -Ilibraries/integer-gmp/. -optP-include -optPlibraries/integer-gmp/dist-install/build/autogen/cabal_macros.h -package ghc-prim-0.3.1.0 -Wall -package-name integer-gmp -XHaskell2010 -dcore-lint -no-user-package-db -rtsopts -Ilibraries/integer-gmp/mkGmpDerivedConstants/dist -c libraries/integer-gmp/cbits/gmp-wrappers.cmm -o libraries/integer-gmp/dist-install/build/cbits/gmp-wrappers.o ghc-stage1.exe: panic! (the 'impossible' happened) (GHC version 7.7.20131107 for i386-unknown-mingw32): bundle c8 integer_cmm_importIntegerFromByteArrayzh [(c8, label: block{v c8}_info rep:StackRep [False, True, True, True]), (cg, label: block{v cg}_info rep:StackRep [False, True, True, True])] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug HEAD (master)$

3 3

Travis now also tests with -DDEBUG
by Joachim Breitner 21 Nov '13

21 Nov '13

Hi, after I got confused by panics in the testsuite that were not caused by my changes I configured travis to build GHC (stage2) with and without -DDEBUG. The current result can be viewed here: https://travis-ci.org/nomeata/ghc-complete/builds/14332594 You see that it works without -DDEBUG (this is also what vanilla validate does), but fails with (due to http://ghc.haskell.org/trac/ghc/ticket/8553) I hope this will make such issues known sooner. Again: I believe someone is working or planning on a proper infrastructure to do GHC QA, this is a crutch until then. Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nomeata(a)debian.org

1 0

RE: Too many symbols
by Simon Peyton-Jones 21 Nov '13

21 Nov '13

Right GhcLibWays=v did the job, thanks Simon | -----Original Message----- | From: Austin Seipp [mailto:aseipp@pobox.com] | Sent: 21 November 2013 12:13 | To: Simon Peyton-Jones | Cc: ghc-devs(a)haskell.org Devs | Subject: Re: Too many symbols | | Hi Simon, | | I believe I've found the problem. The issue is that even with | DYNAMIC_* variables set, GhcLibWays still contains the 'dyn' way as | opposed to just the 'vanilla' way. If you do: | | $ make show VALUE=GhcLibWays | | in your build tree, it will probably say "v dyn", indicating it'll | build the GHC DLL as well as vanilla objects. This makes sense since | we rebuild using different ways in a lot of cases - dynamic-too is | just a special case, and the other variables (DYNAMIC_TOO, | DYNAMIC_GHC_PROGRAMS and DYNAMIC_BY_DEFAULT) don't make a difference | here. | | In the short term, you can hardcode GhcLibWays=v in your build | settings, but the default templates should perhaps expose something | more sensible. (They should also precisely document the impact of | these variables too.) | | On Wed, Nov 20, 2013 at 3:11 PM, Simon Peyton-Jones | <simonpj(a)microsoft.com> wrote: | > Friends | > | > I’m getting the dreaded “Too many symbols in DLL” problem on Windows | (see | > below). | > | > I believe I can get round it by using static linking only, yes? But | how do | > I do that? I have | > | > DYNAMIC_BY_DEFAULT = NO | > | > DYNAMIC_GHC_PROGRAMS = NO | > | > in my validate.mk, but it still happens. Static only will do me | fine! | > | > Thanks! | > | > Simon | > | > | > | > Number of symbols in | > compiler/stage2/build/libHSghc-7.7.20131119-0-ghc7.7.20131119.dll: | 69595 | > | > case `C:/code/HEAD/inplace/mingw/bin/objdump.exe -p | > compiler/stage2/build/libHSghc-7.7.20131119-0-ghc7.7.20131119.dll | | sed -n | > "1,/^.Ordinal\/Name Pointer/ D; p; /^$/ q" | grep "\[ *0\]" | wc -l` | in 1) | > echo DLL compiler/stage2/build/libHSghc-7.7.20131119-0- | ghc7.7.20131119.dll | > OK;; 0) echo No symbols in DLL | > compiler/stage2/build/libHSghc-7.7.20131119-0-ghc7.7.20131119.dll; | exit 1;; | > [0-9]*) echo Too many symbols in DLL | > compiler/stage2/build/libHSghc-7.7.20131119-0-ghc7.7.20131119.dll; | > C:/code/HEAD/inplace/mingw/bin/objdump.exe -p | > compiler/stage2/build/libHSghc-7.7.20131119-0-ghc7.7.20131119.dll | | sed -n | > "1,/^.Ordinal\/Name Pointer/ D; p; /^$/ q" | tail; exit 1;; *) echo | bad DLL | > compiler/stage2/build/libHSghc-7.7.20131119-0-ghc7.7.20131119.dll; | exit 1;; | > esac | > | > Too many symbols in DLL | > compiler/stage2/build/libHSghc-7.7.20131119-0-ghc7.7.20131119.dll | > | > [4050] ghczm7zi7zi20131119_Var_zdfUniquableVar_closure | > | > [4051] ghczm7zi7zi20131119_Var_zdfUniquableVar_info | > | > [4052] ghczm7zi7zi20131119_Var_zdwsetVarUnique_closure | > | > [4053] ghczm7zi7zi20131119_Var_zdwsetVarUnique_info | > | > [4054] ghczm7zi7zi20131119_Var_zdwupdateTyVarKindM_closure | > | > [4055] ghczm7zi7zi20131119_Var_zdwupdateTyVarKindM_info | > | > [4056] ghczm7zi7zi20131119_Var_zdwzdcgmapMp_closure | > | > [4057] ghczm7zi7zi20131119_Var_zdwzdcgmapMp_info | > | > [4058] setHeapSize | > | > | > | > compiler/ghc.mk:472: recipe for target | > 'compiler/stage2/build/libHSghc-7.7.20131119-0-ghc7.7.20131119.dll' | failed | > | > make[1]: *** | > [compiler/stage2/build/libHSghc-7.7.20131119-0-ghc7.7.20131119.dll] | Error 1 | > | > make[1]: *** Deleting file | > 'compiler/stage2/build/libHSghc-7.7.20131119-0-ghc7.7.20131119.dll' | > | > Makefile:64: recipe for target 'all' failed | > | > make: *** [all] Error 2 | > | > HEAD $ | > | > | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs(a)haskell.org | > http://www.haskell.org/mailman/listinfo/ghc-devs | > | | | | -- | Regards, | Austin - PGP: 4096R/0x91384671

1 0

Too many symbols
by Simon Peyton-Jones 21 Nov '13

21 Nov '13

Friends I'm getting the dreaded "Too many symbols in DLL" problem on Windows (see below). I believe I can get round it by using static linking only, yes? But how do I do that? I have DYNAMIC_BY_DEFAULT = NO DYNAMIC_GHC_PROGRAMS = NO in my validate.mk, but it still happens. Static only will do me fine! Thanks! Simon Number of symbols in compiler/stage2/build/libHSghc-7.7.20131119-0-ghc7.7.20131119.dll: 69595 case `C:/code/HEAD/inplace/mingw/bin/objdump.exe -p compiler/stage2/build/libHSghc-7.7.20131119-0-ghc7.7.20131119.dll | sed -n "1,/^.Ordinal\/Name Pointer/ D; p; /^$/ q" | grep "\[ *0\]" | wc -l` in 1) echo DLL compiler/stage2/build/libHSghc-7.7.20131119-0-ghc7.7.20131119.dll OK;; 0) echo No symbols in DLL compiler/stage2/build/libHSghc-7.7.20131119-0-ghc7.7.20131119.dll; exit 1;; [0-9]*) echo Too many symbols in DLL compiler/stage2/build/libHSghc-7.7.20131119-0-ghc7.7.20131119.dll; C:/code/HEAD/inplace/mingw/bin/objdump.exe -p compiler/stage2/build/libHSghc-7.7.20131119-0-ghc7.7.20131119.dll | sed -n "1,/^.Ordinal\/Name Pointer/ D; p; /^$/ q" | tail; exit 1;; *) echo bad DLL compiler/stage2/build/libHSghc-7.7.20131119-0-ghc7.7.20131119.dll; exit 1;; esac Too many symbols in DLL compiler/stage2/build/libHSghc-7.7.20131119-0-ghc7.7.20131119.dll [4050] ghczm7zi7zi20131119_Var_zdfUniquableVar_closure [4051] ghczm7zi7zi20131119_Var_zdfUniquableVar_info [4052] ghczm7zi7zi20131119_Var_zdwsetVarUnique_closure [4053] ghczm7zi7zi20131119_Var_zdwsetVarUnique_info [4054] ghczm7zi7zi20131119_Var_zdwupdateTyVarKindM_closure [4055] ghczm7zi7zi20131119_Var_zdwupdateTyVarKindM_info [4056] ghczm7zi7zi20131119_Var_zdwzdcgmapMp_closure [4057] ghczm7zi7zi20131119_Var_zdwzdcgmapMp_info [4058] setHeapSize compiler/ghc.mk:472: recipe for target 'compiler/stage2/build/libHSghc-7.7.20131119-0-ghc7.7.20131119.dll' failed make[1]: *** [compiler/stage2/build/libHSghc-7.7.20131119-0-ghc7.7.20131119.dll] Error 1 make[1]: *** Deleting file 'compiler/stage2/build/libHSghc-7.7.20131119-0-ghc7.7.20131119.dll' Makefile:64: recipe for target 'all' failed make: *** [all] Error 2 HEAD $

2 1

[PATCH] Fix typo in User's Guide
by Pedro Rodrigues 21 Nov '13

21 Nov '13

--- docs/users_guide/glasgow_exts.xml | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/docs/users_guide/glasgow_exts.xml b/docs/users_guide/glasgow_exts.xml index ce07806..d61ff7a 100644 --- a/docs/users_guide/glasgow_exts.xml +++ b/docs/users_guide/glasgow_exts.xml @@ -8673,7 +8673,7 @@ proc (x,y) -> which is translated to <screen> arr (\ (x,y) -> if f x y then Left x else Right y) >>> - (arr (\x -> x+1) >>> f) ||| (arr (\y -> y+2) >>> g) + (arr (\x -> x+1) >>> g) ||| (arr (\y -> y+2) >>> h) </screen> Since the translation uses <function>|||</function>, the arrow concerned must belong to the <literal>ArrowChoice</literal> class. -- 1.7.4.1

5 6