February 2013 - ghc-devs

GHC failing to build due to errors in DPH?
by Iavor Diatchki 15 Feb '13

15 Feb '13

Hello, I am trying to build GHC head and get the following error: libraries/dph/dph-lifted-base/Data/Array/Parallel/PArray/Reference.hs:50:11: Ambiguous occurrence `fromList' It could refer to either `Data.Array.Parallel.PArray.Reference.fromList', defined at libraries/dph/dph-lifted-base/Data/Array This is using the stage 2 compiler and, I am guessing, is due to an interaction with the overloaded lists extension. I just deleted dph completely, and used `sync-all get` to get a fresh copy, but I get the same error. It looks like the nightly builds are working, so am I doing something wrong? More generally, I don't really need DPH, so is there an easy way to disable building it? -Iavor

5 4

RE: GHC failing to build due to errors in DPH?
by Simon Peyton-Jones 15 Feb '13

15 Feb '13

Sorry about that... I don’t know haw my validate worked. Anyway all good. Simon From: Ian Lynagh Sent: ‎15‎ ‎February‎ ‎2013 ‎20‎:‎10 To: Iavor Diatchki CC: ghc-devs(a)haskell.org Subject: Re: GHC failing to build due to errors in DPH? On Fri, Feb 15, 2013 at 11:09:33AM -0800, Iavor Diatchki wrote: > > I am trying to build GHC head and get the following error: > > libraries/dph/dph-lifted-base/Data/Array/Parallel/PArray/Reference.hs:50:11: > Ambiguous occurrence `fromList' > It could refer to either > `Data.Array.Parallel.PArray.Reference.fromList', > defined at > libraries/dph/dph-lifted-base/Data/Array I've just pushed a fix for this. Thanks Ian _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

1 0

RE: OverloadedLists
by Simon Peyton-Jones 15 Feb '13

15 Feb '13

| Finally I managed to build again (don't know what's wrong with my | system, I built on a virtual machine instead now), and the tests pass. I | attached the four patches, they were created with git diff --no-prefix, | and their name specifies the submodule they are to be applied to. I hope | it isn't to late to include them in 7.8. Should I publish them somewhere | else also, or is this fine? Great. It's done! Thanks for all your work on this. Would you like to update the wiki page? http://hackage.haskell.org/trac/ghc/wiki/OverloadedLists You probably don't want to mention your repo any more; and please just check the rest to make sure it's accurate. I did quite a bit of refactoring, especially to the type checking of arithmetic sequences, which had lots of duplication; fixed the documentation which was out of date; fixed various error message changes in the main testsuite; and committed. Simon commit 3234a4ade7204c4206831b4c1dc4a8b23624cc6b Author: Simon Peyton Jones <simonpj(a)microsoft.com> Date: Thu Feb 14 13:04:14 2013 +0000 Add OverloadedLists, allowing list syntax to be overloaded This work was all done by Achim Krause <achim.t.krause(a)gmail.com> George Giorgidze <giorgidze(a)gmail.com> Weijers Jeroen <jeroen.weijers(a)uni-tuebingen.de> It allows list syntax, such as [a,b], [a..b] and so on, to be overloaded so that it works for a variety of types. The design is described here: http://hackage.haskell.org/trac/ghc/wiki/OverloadedLists Eg. you can use it for maps, so that [(1,"foo"), (4,"bar")] :: Map Int String The main changes * The ExplicitList constructor of HsExpr gets witness field * Ditto ArithSeq constructor * Ditto the ListPat constructor of HsPat Everything else flows from this. compiler/deSugar/Check.lhs | 15 ++-- compiler/deSugar/Coverage.lhs | 16 +++- compiler/deSugar/DsArrows.lhs | 2 +- compiler/deSugar/DsExpr.lhs | 42 +++++++---- compiler/deSugar/DsMeta.hs | 7 +- compiler/deSugar/Match.lhs | 31 ++++++-- compiler/hsSyn/Convert.lhs | 6 +- compiler/hsSyn/HsExpr.lhs | 12 ++- compiler/hsSyn/HsPat.lhs | 12 ++- compiler/hsSyn/HsUtils.lhs | 6 +- compiler/main/DynFlags.hs | 2 + compiler/parser/Parser.y.pp | 12 ++-- compiler/parser/RdrHsSyn.lhs | 4 +- compiler/prelude/PrelNames.lhs | 26 ++++++- compiler/prelude/TysWiredIn.lhs | 2 +- compiler/rename/RnEnv.lhs | 18 +++-- compiler/rename/RnExpr.lhs | 45 +++++++---- compiler/rename/RnPat.lhs | 21 ++++- compiler/typecheck/TcExpr.lhs | 111 ++++++++++++++++---------- compiler/typecheck/TcHsSyn.lhs | 30 ++++++-- compiler/typecheck/TcHsType.lhs | 2 +- compiler/typecheck/TcPat.lhs | 14 +++- compiler/typecheck/TcRnDriver.lhs | 2 +- compiler/typecheck/TcRnTypes.lhs | 2 + compiler/utils/Outputable.lhs | 4 +- docs/users_guide/flags.xml | 7 ++ docs/users_guide/glasgow_exts.xml | 157 +++++++++++++++++++++++++++++++++++++ 27 files changed, 469 insertions(+), 139 deletions(-)

4 5

Re: [commit: ghc] master: Find LLVM tools when version number at end (e.g., llc-3.0) (#7661) (64aaaa1)
by Ian Lynagh 15 Feb '13

15 Feb '13

On Fri, Feb 15, 2013 at 07:21:54PM +0100, Karel Gardas wrote: > On 02/15/13 07:03 PM, Ian Lynagh wrote: > >>+ $1=`${FindCmd} ${GOOD_PATH} -type f -perm +111 -maxdepth 1 -regex '.*/$3-[[0-9]]\.[[0-9]]' | ${SortCmd} -n | tail -1` > > > >This feels rather unpleasant to me. Is it likely that someone will have > >programs called llc-3.0 etc, but no llc? > > Yes, Ubuntu 12.04 LTS installs LLVM 3.0 package in a way that, the > package binaries are installed into /usr/lib/llvm-3.0 directory and > inside /usr/bin there are llc-3.0 and opt-3.0 links created linking > to ../lib/llvm-3.0/bin/{llc|opt}. > > So David is fixing real-world issue here. But if you install 'llvm' (rather than 'llvm-3.0') then you get a /usr/bin/llc Analogously, on ubuntu, if you install 'gcc' then you get /usr/bin/gcc, but if you install 'gcc-4.6' then you get /usr/bin/gcc-4.6; but we don't search for gcc-* executables. Thanks Ian

2 1

Re: [commit: ghc] simd: Fixup stack spills when generating AVX instructions. (b787b5d)
by David Terei 15 Feb '13

15 Feb '13

Do we have a longer term solution for this? I love the SIMD work, so please don't take this as a complaint, I agree with getting it done for now with the mangler and truth is it's doubtful we'll et around to adding TNTC support to LLVM anytime soon, so mangler is here to stay for now. BUT. I would like to see some thought about how in an ideal world with lots of free time to hack on GHC we'd kill the mangler. Do we know that plan for this patch? If so it may be nice to document it somewhere and perhaps create a trac ticket. On 14 February 2013 23:16, Geoffrey Mainland <gmainlan(a)microsoft.com> wrote: > Repository : ssh://darcs.haskell.org//srv/darcs/ghc > > On branch : simd > > http://hackage.haskell.org/trac/ghc/changeset/b787b5d1e687fb28643cdd6a847cc… > >>--------------------------------------------------------------- > > commit b787b5d1e687fb28643cdd6a847ccc26bb014a79 > Author: Geoffrey Mainland <gmainlan(a)microsoft.com> > Date: Sat Nov 26 12:45:23 2011 +0000 > > Fixup stack spills when generating AVX instructions. > > LLVM uses aligned AVX moves to spill values onto the stack, which requires > 32-bye aligned stacks. Since the stack in only 16-byte aligned, LLVM inserts > extra instructions that munge the stack pointer. This is very very bad for the > GHC calling convention, so we tell LLVM to assume the stack is 32-byte > aligned. This patch rewrites the spill instructions that LLVM generates so they > do not require an aligned stack. > >>--------------------------------------------------------------- > > compiler/llvmGen/LlvmMangler.hs | 38 ++++++++++++++++++++++++++++++++++++++ > 1 files changed, 38 insertions(+), 0 deletions(-) > > diff --git a/compiler/llvmGen/LlvmMangler.hs b/compiler/llvmGen/LlvmMangler.hs > index 83a2be7..745dcc6 100644 > --- a/compiler/llvmGen/LlvmMangler.hs > +++ b/compiler/llvmGen/LlvmMangler.hs > @@ -20,6 +20,10 @@ import System.IO > import Data.List ( sortBy ) > import Data.Function ( on ) > > +#if x86_64_TARGET_ARCH > +#define REWRITE_AVX > +#endif > + > -- Magic Strings > secStmt, infoSec, newLine, textStmt, dataStmt, syntaxUnified :: B.ByteString > secStmt = B.pack "\t.section\t" > @@ -47,6 +51,7 @@ llvmFixupAsm dflags f1 f2 = {-# SCC "llvm_mangler" #-} do > w <- openBinaryFile f2 WriteMode > ss <- readSections r w > hClose r > + let fixed = (map rewriteAVX . fixTables) ss > let fixed = fixTables ss > mapM_ (writeSection w) fixed > hClose w > @@ -90,6 +95,39 @@ writeSection w (hdr, cts) = do > B.hPutStrLn w hdr > B.hPutStrLn w cts > > +#if REWRITE_AVX > +rewriteAVX :: Section -> Section > +rewriteAVX = rewriteVmovaps . rewriteVmovdqa > + > +rewriteVmovdqa :: Section -> Section > +rewriteVmovdqa = rewriteInstructions vmovdqa vmovdqu > + where > + vmovdqa, vmovdqu :: B.ByteString > + vmovdqa = B.pack "vmovdqa" > + vmovdqu = B.pack "vmovdqu" > + > +rewriteVmovap :: Section -> Section > +rewriteVmovap = rewriteInstructions vmovap vmovup > + where > + vmovap, vmovup :: B.ByteString > + vmovap = B.pack "vmovap" > + vmovup = B.pack "vmovup" > + > +rewriteInstructions :: B.ByteString -> B.ByteString -> Section -> Section > +rewriteInstructions matchBS replaceBS (hdr, cts) = > + (hdr, loop cts) > + where > + loop :: B.ByteString -> B.ByteString > + loop cts = > + case B.breakSubstring cts matchBS of > + (hd,tl) | B.null tl -> hd > + | otherwise -> hd `B.append` replaceBS `B.append` > + loop (B.drop (B.length matchBS) tl) > +#else /* !REWRITE_AVX */ > +rewriteAVX :: Section -> Section > +rewriteAVX = id > +#endif /* !REWRITE_SSE */ > + > -- | Reorder and convert sections so info tables end up next to the > -- code. Also does stack fixups. > fixTables :: [Section] -> [Section] > > > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits

2 2

Advice needed: programmatically generating primops?
by Geoffrey Mainland 15 Feb '13

15 Feb '13

Hi All, There is a huge amount of boilerplate involved in adding a full complement of vector primops to GHC. I would like to reduce this boilerplate by programmatically generating the vector primops. My plan is to add utils/genvecprimops and #include its output into primops.txt.pp. Does this sound reasonable? Any objections? While I'm at it, is there any related cleanup I could undertake? Thanks, Geoff

5 6

Re: takeOneMVar?
by Alexander Kjeldaas 15 Feb '13

15 Feb '13

On Fri, Feb 15, 2013 at 8:54 AM, Edward Z. Yang <ezyang(a)mit.edu> wrote: > Apologies for the kibitzing. > > If anyone, it's me proposing weird stuff :-) > > -- This will fail if the MVarGroup is not associated with the current > > process (if the MVarGroup's TSO is not the current TSO)! > > I'm not super keen about this requirement. What if I want to create an > MVarGroup > but pass it to another thread? > > Our emails crossed each other :-). As you can see, I think this is solvable. Alexander > Edward >

2 2

takeOneMVar?
by Alexander Kjeldaas 15 Feb '13

15 Feb '13

Hi, I ended up staring at the PrimOps.cmm file today, and porting tryPutMVar to C so it can be used from the RTS. During my staring, it occurred to me that it should be possible to implement a wait-on-multiple MVars with mostly no overhead. I am guessing that this would be desirable, but I am not sure. My rough idea is like this: -- wait for all MVars, return the value of one of them, and the corresponding index takeOneMVar :: [MVar a] -> IO (a, Int) This is implemented by this change: typedef struct StgMVarTSOQueue_ { StgHeader header; struct StgMVarTSOQueue_ *link; * // The group_head and group_link are used when a TSO is waiting on* * // multiple MVars. Multiple StgMVarTSOQueue objects* * // are created, one for each MVar, and they are linked using the* * // group_link pointer. group_head always points to the first* * // element. The tso pointer will always be the same in this case.* * // The group head acts as a synchronization element for the whole group.* * // When the group head lock is acquired, the owner can invalidate the group* * struct StgMVarTSOQueue *group_head;* * struct StgMVarTSOQueue *group_link;* struct StgTSO_ *tso; } StgMVarTSOQueue; Now, whenever a TSO should be woken up by the MVar code, if ... putMVar(...) { ... queue = mvar->queue... loop: if (end_of_queue(queue) { return 0; } * if (marked_as_invalid(queue) { // invalid = (queue->group_head == NULL) for example* * queue = queue->link;* * goto loop;* * }* * if (queue->group_head != queue) {* * // Try to win race to wake up the TSO with *our* MVar. * * won = TryLock(queue->group_head);* * if (!won) {* * // ignore this queue element for now, we can't get the lock, * * // and it will be marked_as_invalid at some point in the future anyways.* * queue = queue->link;* * goto loop; // try next* * }* * if (won) {* * for all in group, mark them as "invalid"* * Unlock(queue->group_head);* * goto wake_up_tso;* * } else { * * // Did not win* * goto loop;* * }* } else { ..what is currently done.. wake_up_tso: ... do wake up Alexander

2 3

Re: [commit: ghc] master: Add OverloadedLists, allowing list syntax to be overloaded (3234a4a)
by Johan Tibell 14 Feb '13

14 Feb '13

Did we end up supporting a length hint so we can efficiently create e.g. vectors that need upfront allocation of the space before writing the elements? Or is the plan to do like we for String and have literals desugar to e.g. fromIntList# :: Int# -> Ptr Int# -> [Int] intList# :: Ptr Int# intList# = [1,2,3,4]# myliteral = fromList (fromIntList# 4 intList#) On Thu, Feb 14, 2013 at 6:56 AM, Simon Peyton Jones <simonpj(a)microsoft.com>wrote: > Repository : ssh://darcs.haskell.org//srv/darcs/ghc > > On branch : master > > > http://hackage.haskell.org/trac/ghc/changeset/3234a4ade7204c4206831b4c1dc4a… > > >--------------------------------------------------------------- > > commit 3234a4ade7204c4206831b4c1dc4a8b23624cc6b > Author: Simon Peyton Jones <simonpj(a)microsoft.com> > Date: Thu Feb 14 13:04:14 2013 +0000 > > Add OverloadedLists, allowing list syntax to be overloaded > > This work was all done by > Achim Krause <achim.t.krause(a)gmail.com> > George Giorgidze <giorgidze(a)gmail.com> > Weijers Jeroen <jeroen.weijers(a)uni-tuebingen.de> > > It allows list syntax, such as [a,b], [a..b] and so on, to be > overloaded so that it works for a variety of types. > > The design is described here: > http://hackage.haskell.org/trac/ghc/wiki/OverloadedLists > > Eg. you can use it for maps, so that > [(1,"foo"), (4,"bar")] :: Map Int String > > The main changes > * The ExplicitList constructor of HsExpr gets witness field > * Ditto ArithSeq constructor > * Ditto the ListPat constructor of HsPat > > Everything else flows from this. > > compiler/deSugar/Check.lhs | 15 ++-- > compiler/deSugar/Coverage.lhs | 16 +++- > compiler/deSugar/DsArrows.lhs | 2 +- > compiler/deSugar/DsExpr.lhs | 42 +++++++---- > compiler/deSugar/DsMeta.hs | 7 +- > compiler/deSugar/Match.lhs | 31 ++++++-- > compiler/hsSyn/Convert.lhs | 6 +- > compiler/hsSyn/HsExpr.lhs | 12 ++- > compiler/hsSyn/HsPat.lhs | 12 ++- > compiler/hsSyn/HsUtils.lhs | 6 +- > compiler/main/DynFlags.hs | 2 + > compiler/parser/Parser.y.pp | 12 ++-- > compiler/parser/RdrHsSyn.lhs | 4 +- > compiler/prelude/PrelNames.lhs | 26 ++++++- > compiler/prelude/TysWiredIn.lhs | 2 +- > compiler/rename/RnEnv.lhs | 18 +++-- > compiler/rename/RnExpr.lhs | 45 +++++++---- > compiler/rename/RnPat.lhs | 21 ++++- > compiler/typecheck/TcExpr.lhs | 111 ++++++++++++++++---------- > compiler/typecheck/TcHsSyn.lhs | 30 ++++++-- > compiler/typecheck/TcHsType.lhs | 2 +- > compiler/typecheck/TcPat.lhs | 14 +++- > compiler/typecheck/TcRnDriver.lhs | 2 +- > compiler/typecheck/TcRnTypes.lhs | 2 + > compiler/utils/Outputable.lhs | 4 +- > docs/users_guide/flags.xml | 7 ++ > docs/users_guide/glasgow_exts.xml | 157 > +++++++++++++++++++++++++++++++++++++ > 27 files changed, 469 insertions(+), 139 deletions(-) > > > Diff suppressed because of size. To see it, use: > > git show 3234a4ade7204c4206831b4c1dc4a8b23624cc6b > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits >

2 1

Today's validate failures
by Simon Marlow 14 Feb '13

14 Feb '13

On x86_64/Linux: Unexpected passes: perf/should_run T149 (normal) Unexpected failures: perf/compiler T3064 [stat too good] (normal) perf/haddock haddock.Cabal [stat not good enough] (normal) perf/haddock haddock.base [stat not good enough] (normal) simplCore/should_compile T3717 [stderr mismatch] (optasm) simplCore/should_compile T3772 [bad stdout] (normal) simplCore/should_compile T4908 [stderr mismatch] (optasm) simplCore/should_compile T4930 [stderr mismatch] (optasm) simplCore/should_compile T7360 [stderr mismatch] (optasm) simplCore/should_compile spec-inline [stderr mismatch] (optasm)

3 2