October 2011 - Glasgow-haskell-users

ANN: GhciExt 0.7
by Peter Hercek 20 Oct '11

20 Oct '11

I finally moved to GHC 7.0.3, a rather late update :) I updated GhciExt for it and if you want to script ghci commands a bit you can grab it as an example and use. It probably works well enough. I was lucky and did not use debugger a lot lately, so I'm not sure. http://www.hck.sk/users/peter/pub/ghciext-0.7.tar.gz It redefines some standard commands (like e.g. :break to output hit count) and adds some new commands (the most useful are probably :grep and :watch (conditional breakpoint)). Here is the list of the added commands: Prelude> :defs long :. <file> -- source commands from <file> :* <count> <cmd>... -- run <cmd> <count> times :x <cmd>... -- run <cmd> with stdout suppressed :output -- restore ghci output (stdout and stderr) back Restores stdout and stderr of ghci as it was during startup. You should not ever need this command. It is here only if something would go wrong in ghciExt and you need to recover (console) manually. :redir <var> <cmd>... -- execute <cmd> redirecting stdout to <var> :grep <args> < <cmd>... -- run grep <args> on <cmd> output Runs grep from your OS on the output of <cmd>. This means all the options of your OS grep are available. '<' separates grep options from the command. :find <cmd> [-]<var> -- step with <cmd> until <var> is found Prepend variable name with '-' to disable printing of its value. :locate <cmd> <bpArgs> -- step with <cmd> until location <bpArgs> is hit :repeat <cmd> <cond> -- repeat <cmd> until <cond> is true :inject <cc> <c> <sc> -- at location run <c> if <cc> and stop if <sc> There are two special identifiers which can be used in the breakpoint code (<c>) and the breakpoint stop condition (<sc>); but which are not usable in the breakpoint code condition (<cc>). These are: - ġė_BpId - macro name; translates to breakpoint id - ġė_HitCnt - macro name; translates to breakpoint hit count :strobe [&<c>] -- at location show hit count if <c> :monitor [&<c>] <e> -- :force expression <e> at location if <c> :watch <cond> <bpArgs> -- break at location <bpArgs> when <cond> is True :count [<R>]<N> [<bp>] -- count/stop execution at <bp> or query bp hits There are four ways how to use this command: - :count 0 <bp> - never stops; counts hits and extends trace history - :count N <bp> - stops when location <bp> is hit N-th time - :count RN <bp> - stops when hitCount@bp is in Ord relation R with N - :count N - shows hit count of a ghciExt breakpoint with number N. :class <classId> -- show class methods :defs [long] -- list user commands (possibly with long help) General information for all GhciExt commands: - Most arguments may be in quotation marks (to allow spaces in them). - Instead of a regular quotation mark, @x can be used to start a string argument too. In such a case the argument is finished when character x appears again after `@x' string. Use any character in place of x. - Most commands can have an end-line comment. The comment starts with this sequence: "d--", where d is the argument delimiter; i.e. it is '"', the x after '@' or whitespace based on the previous argument. - GhciExt calls :init any time GHCi may have cleared your top level symbols. Redefine :init to reintroduce the symbols you want always available. Prelude>

1 0

RE: FW: Two Proposals
by Simon Peyton-Jones 19 Oct '11

19 Oct '11

[adding ghc-users] It's not easy, Phil. Do you have any ideas? For the 'then' case the name of the function serves as the verb. One might say then take 4 or then takeWhile by salary > 40 For grouping one might like to say the same thing, such as then groupBy by salary but the typing rule is quite different, so we really need a different keyword. We chose the compound keyword "then group" to avoid needing a whole new keyword ("group" is treated specially only in tthis context). So you write then group by salary using groupBy Using this order of the pieces for the sorting case is harder. What would one say? "then process"? Like this? then process by salary > 40 using takeWhile Not very nice. One could use a new keyword for grouping "theng" say, thus: theng groupBy by salary But that is hardly beautiful either. So the current story is not great, but it's the best I could think of. Improvements welcome. Simon | -----Original Message----- | From: Philip Wadler [mailto:wadler@inf.ed.ac.uk] | Sent: 04 October 2011 18:15 | To: Simon Peyton-Jones; George Giorgidze | Subject: Re: FW: Two Proposals | | George, | | Nice proposal. I like the idea of symmetry, but don't at all like the | idea that f comes before e for 'then' but f comes after e for 'then | group'. Can you rethink it and come up with something even more | symmetric? | | Yours, -- P | | | On Tue, Oct 4, 2011 at 9:23 AM, Simon Peyton-Jones | <simonpj(a)microsoft.com> wrote: | > FYI | > | > -----Original Message----- | > From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell- | users-bounces(a)haskell.org] On Behalf Of George Giorgidze | > Sent: 30 September 2011 18:28 | > To: glasgow-haskell-users(a)haskell.org | > Subject: Two Proposals | > | > GHC Users, | > | > I would like to make to the following two proposals: | > * Eliminate the default grouping close from SQL-like comprehensions | > * Introduce a GHC extension for list literal overloading | > | > OK, let me start with the first proposal. | > | > Currently, the SQL-like comprehension notation (both in its list comprehension | and monad comprehension variants) features the following five clauses: | > | > then f | > then f by e | > then group by e | > then group using f | > then group by e using f | > | > The first two clauses are used for specifying transformations of type [a] -> [a] | (or Monad m => m a-> m a for monad comprehensions). The following three | clauses are used for specifying transformations of type [a] -> [[a]] (or Monad m, | Functor f => m a -> m (f a) for monad comprehensions). See [1] for further | details. | > | > Note that the third clause does not mention which function is used for grouping. | In this case GHC.Exts.groupWith function is used as a default for list | comprehensions and the mgroupWith function from the MonadGroup class is used | as a default for monad comprehensions. | > | > I would like to suggest to remove the third clause for the following reasons: | > * Currently the syntax is asymmetrical. Note that there is the default case for | the 'then group' clause and not for the 'then' clause. | > * In the current notation it is not clear which grouping function is used in the | default case | > * For many monads including lists it is not clear which function should be | selected as a default (e.g., the groupWith function also does sorting and it is not | clear to me why this should be the default) | > * Gets rid of the MonadGroup class. Currently the sole purpose of this class is to | introduce a default grouping function for monad comprehensions. | > * Explicit mention of the grouping function would make monad/list | comprehensions much easier to read by making it immediately apparent which | function is used for grouping. | > | > My second proposal is to introduce the OverloadedLists extension that overloads | list literals. See Section 5.2 in [1] for details. | > | > Basically the idea is to treat list literals like: | > | > [1,2,3] | > | > as | > | > fromList [1,2,3] | > | > where | > | > class IsList l where | > type Item l | > fromList :: [Item l] -> l | > | > In the following I give useful instances of the IsList class. | > | > instance IsList [a] where | > type Item [a] = a | > fromList = id | > | > instance (Ord a) => IsList (Set a) where | > type Item (Set a) = a | > fromList = Set.fromList | > | > instance (Ord k) => IsList (Map k v) where | > type Item (Map k v) = (k,v) | > fromList = Map.fromList | > | > instance IsList (IntMap v) where | > type Item (IntMap v) = (Int,v) | > fromList = IntMap.fromList | > | > instance IsList Text where | > type Item Text = Char | > fromList = Text.pack | > | > As you can see the extension would allow list literals to be used for sets, maps | and integer maps. In addition the suggested OverloadedLists extension would | subsume OverloadedStrings extension (see the instance for Text, for example). | Having said that, for now, I am not suggesting to remove the OverloadedStrings | extension as it appears to be widely used. | > | > This extension could also be used for giving data-parallel array literals instead of | the special syntax used currently. | > | > Unless there is a vocal opposition to the aforementioned two proposals, I would | like to implement them in GHC. Both changes appear to be straightforward to | implement. | > | > Thanks in advance for your feedback. | > | > Cheers, George | > | > [1] http://www-db.informatik.uni-tuebingen.de/files/giorgidze/haskell2011.pdf | > _______________________________________________ | > Glasgow-haskell-users mailing list | > Glasgow-haskell-users(a)haskell.org | > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users | > | > | > | | | | -- | .\ Philip Wadler, Professor of Theoretical Computer Science | ./\ School of Informatics, University of Edinburgh | / \ http://homepages.inf.ed.ac.uk/wadler/ | | The University of Edinburgh is a charitable body, registered in | Scotland, with registration number SC005336. |

3 3

Implementing a new Primop, stage1 panic
by Paul Monday 18 Oct '11

18 Oct '11

(Reposting since this got cross-posted sort of oddly and I wasn't subscribed yet) I'm having an odd problem as I try to define my own primop, it seems that some docs may be out of date with respect to all of the touch points for a simple primop addition. I've followed what the various wiki pages have to offer (primarily http://hackage.haskell.org/trac/ghc/wiki/AddingNewPrimitiveOperations and http://hackage.haskell.org/trac/ghc/wiki/Commentary/PrimOps) without success. I even unraveled my PrimOp to be, basically, an exact copy of another PrimOp without luck. The primop I'm attempting to add is now very, very simple and copies FloatAddOp exactly so there must be an additional file I have to modify before the primop is "completely" added. Here are my simple modifications: ./compiler/prelude/primops.txt.pp primop FloatVAddOp "plusFloatVec#" Dyadic Float# -> Float# -> Float# with commutable = True ./compiler/codeGen/CgPrimOp.hs translateOp FloatVAddOp = Just (MO_F_Add W32) The compiler error is below. I have the feeling that an interface is not being built somewhere … this must be a simple one but I can't find any references to this error anywhere … has anyone seen this one before????? "inplace/bin/ghc-stage1" -H64m -O0 -fasm -package-name ghc-7.3.20111007 -hide-all-packages -i -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage2/build -icompiler/stage2/build/autogen -Icompiler/stage2/build -Icompiler/stage2/build/autogen -Icompiler/../libffi/build/include -Icompiler/stage2 -Icompiler/../libraries/base/cbits -Icompiler/../libraries/base/include -Icompiler/. -Icompiler/parser -Icompiler/utils -optP-DGHCI -optP-include -optPcompiler/stage2/build/autogen/cabal_macros.h -package Cabal-1.11.2 -package array-0.3.0.3 -package base-4.4.0.0 -package bin-package-db-0.0.0.0 -package bytestring-0.9.2.0 -package containers-0.4.2.0 -package directory-1.1.0.1 -package filepath-1.2.0.1 -package hoopl-3.8.7.2 -package hpc-0.5.1.0 -package old-time-1.0.0.7 -package process-1.1.0.0 -package template-haskell-2.6.0.0 -package unix-2.5.0.0 -Wall -fno-warn-name-shadowing -fno-warn-orphans -XHaskell98 -XNondecreasingIndentation -XCPP -XMagicHash -XUnboxedTuples -XPatternGuards -XForeignFunctionInterface -XEmptyDataDecls -XTypeSynonymInstances -XMultiParamTypeClasses -XFlexibleInstances -XRank2Types -XScopedTypeVariables -XDeriveDataTypeable -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -O0 -fasm -no-user-package-conf -rtsopts -odir compiler/stage2/build -hidir compiler/stage2/build -stubdir compiler/stage2/build -hisuf hi -osuf o -hcsuf hc -c compiler/iface/BinIface.hs -o compiler/stage2/build/BinIface.o ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.3.20111007 for x86_64-unknown-linux): applyTypeToArgs ghc-prim:GHC.Prim.sizeofMutableArray#{(w) v 91V} [gid[PrimOp]] @ e{tv i4L2} [tv] ds{v i4Lc} [lid] i#{v i4Lg} [lid] forall a{tv 12} [tv]. ghc-prim:GHC.Prim.MutableArray#{(w) tc 31m} e{tv i4L2} [tv] a{tv 12} [tv] -> ghc-prim:GHC.Prim.Int#{(w) tc 3G} Paul Monday Parallel Scientific, LLC. paul.monday(a)parsci.com

3 3

Fwd: GHC, Clang & XCode 4.2
by Manuel M T Chakravarty 17 Oct '11

17 Oct '11

I think, you meant to reply to the list and not just to me. > Von: "B. Scott Michel" <scooter.phd(a)gmail.com> > Betreff: Re: GHC, Clang & XCode 4.2 > Datum: 15 October 2011 12:32:36 > An: Manuel M T Chakravarty <chak(a)cse.unsw.edu.au> > Antwort an: scooter.phd(a)gmail.com > > Simon: > > What are the performance penalties, specifically? I ask because I might still have commit privs to llvm from the errors of a misspent post-doc era, so could probably help push a patch to llvm if needed. > > That said, though, FreeBSD moved to llvm because itKs not GPL and it generates better code. > > -scooter > Sent from my Verizon Wireless BlackBerry > > -----Original Message----- > From: Manuel M T Chakravarty <chak(a)cse.unsw.edu.au> > Sender: glasgow-haskell-users-bounces(a)haskell.org > Date: Thu, 13 Oct 2011 13:11:40 > To: Simon Marlow<marlowsd(a)gmail.com> > Cc: GHC Users Mailing List<glasgow-haskell-users(a)haskell.org> > Subject: Re: GHC, Clang & XCode 4.2 > > Just FYI, Xcode 4.2 is live in the Mac App Store now, and it has some nice goodies (i.e., many who develop for iOS and probably also OS X will probably adopt it soon). > > Manuel > > PS: Sorry for not having participated in the discussion on how to solve this, but I have too many loose ends right now. > > > Simon Marlow: >> On 11/10/2011 18:45, David Peixotto wrote: >>> Ok, I have attached a set of patches to support building the GHC >>> runtime with llvm-gcc. The patches are based off of commit >>> 29a97fded4010bd01aa0a17945c84258e285d421 which was last Friday's HEAD. >>> These patches are also available from my github repository on the >>> llvm-gcc branch at >>> >>> git://github.com/dmpots/ghc.git >>> >>> There are three patches: >>> >>> 0001- Uses pthread_getspecific and pthread_setspecfic to >>> access gct when the `llvm_CC_FLAVOR` CPP macro is >>> set >>> >>> 0002- Modifies the configure scripts to set the >>> `llvm_CC_FLAVOR` macro when compiling with an llvm >>> based compile (either llvm-gcc or clang) >>> >>> 0003- Passes the gct variable as a parameter in the GC. This >>> change is parameterized with CPP macros so that it >>> is only in effect when compiling for an llvm-based >>> compiler. >>> >>> The patches 0001 and 0002 provide the minimal support needed to build >>> GHC with llvm-gcc. The 0003 patch is there to limit the performance >>> hit we get by going through pthread functions to access the gct. I >>> think the 0001 and 0002 patches should not be very controversial, but >>> the 0003 patch is a more invasive change and perhaps Simon Marlow will >>> want to clean it up before it is applied. >> >> Thanks, I'll take a look at these soon. >> >> Just a thought, but someone might want to write a blog post about how Apple's choice to move to llvm-gcc is imposing a performance penalty on us here, and get it up on Reddit. That would give the issue some publicity (they love that sort of thing on Reddit), and might result in some action. I'd be happy to proof read a blog post before publication. Some simple benchmarks would be needed - one option is to use GHC itself with the various combinations of compilers + RTS changes, or there are a small set of GC benchmarks in nofib/gc. >> >> Cheers, >> Simon >> >> >> >>> I ran a validate with the patches, and found one additional failure >>> when going through an llvm-based compiler. There were no additional >>> failures when using a gcc compiler even with my patches applied. The >>> additional failure is the cgrun071 test which tests the popCnt >>> primitives. I'm going to look into why that test fails, but I think >>> the patches should be safe to apply as it would only show up when >>> compiling with llvm-gcc, which is currently impossible without these >>> patches. >>> >>> -David >>> >>> >>> >>> >>> >>> >>> On Oct 7, 2011, at 10:30 AM, David Peixotto wrote: >>> >>>> >>>> On Oct 6, 2011, at 7:32 AM, Simon Marlow wrote: >>>> >>>>> On 05/10/2011 09:46, austin seipp wrote: >>>>>> There has been recent discussion on the Homebrew bug tracker >>>>>> concerning the upcoming XCode 4.2 release by Apple, which has >>>>>> apparently just gone GM (meaning they're going to make a real release >>>>>> on the app store Real Soon Now.) >>>>>> >>>>>> The primary concern is that XCode will no longer ship GCC 4.2 at all, >>>>>> it seems. XCode 4.0& 4.1 merely set 'llvm-gcc' as the default >>>>>> compiler, and GHC's `configure` script was adjusted to find the >>>>>> `gcc-4.2` binary. If you have old XCode's installed, then you may have >>>>>> the binaries laying around, but I doubt they'll be on your $PATH, and >>>>>> anybody doing a fresh install is SOL. >>>>>> >>>>>> It seems Clang 3.0 will now be the default compiler, with llvm-gcc as >>>>>> a deprecated option, probably removed in XCode 4.3. It doesn't matter >>>>>> really, because both of them do not work with GHC, because of its use >>>>>> of either A) Global register variables of any kind, or B) the __thread >>>>>> storage modifier. >>>>>> >>>>>> David Peixotto did some work on this not too long ago as the issue of >>>>>> compiling with Clang was raised. His branches include changes which >>>>>> make the 'gct' variable use pthread_getspecific rather than __thread >>>>>> for TLS and then as an optimization use inline ASM to grab the value >>>>>> out of the variable, with an impact of about 9% it seems, but that's >>>>>> on nofib and I don't know if it was -threaded. He also included a >>>>>> version which passes the 'gct' around as a parameter to all GCC >>>>>> functions which is a bit uglier but may give some better performance I >>>>>> guess. (The discussion is from here IIRC.) I suppose the real perf >>>>>> killer here is probably -threaded code. >>>>>> >>>>>> https://github.com/dmpots/ghc >>>>>> >>>>>> Was there ever any decision on which route to take for this issue? The >>>>>> parameter passing solution looks quite uglier IMO but it may be >>>>>> necessary for performance. >>>>> >>>>> I'm happy to incorporate the parameter-passing changes if necessary. I think it should only be important in the inner loop of the GC (scavenge_block/evacuate and the functions called from there). If someone sends me a working patch, I can clean it up as much as possible. >>>> >>>> I will take a look at getting the patches to work with GHC head. To support llvm-gcc we need two basic things: >>>> >>>> 1. autoconf support to detect when we are compiling with llvm-gcc >>>> 2. a work-around for tls in the gc >>>> >>>> My old patches take care of both 1 and 2. For #2 the easy approach is using pthread_getspecific which is a pretty small change. Passing gct as a parameter is much uglier more invasive change, but I had it working at some point. It could perhaps be made less ugly by only passing it around in the "important" functions. >>>> >>>> Supporting clang is going to require more changes. The last time I tried there were problems with the preprocessor that made it not work. I just tried again yesterday and ran into a problem generating makefile dependencies because apparently clang does not allow both the -MM and -MF flags (http://llvm.org/bugs/show_bug.cgi?id=8312) >>>> >>>> >>>>> Note that some of the overhead measured by David is coming from using the LLVM backend to gcc instead of gcc's own backend. In my own measurements a few months ago I found LLVM generated slower (but smaller) code for the GC. Maybe this will change over time. It's also possible that the current GC code is tuned for gcc - at various times in the past I've gone through and tweaked the code to get good assembly out (much as we teak Haskell to get good Core :-). >>>>> >>>>> Cheers, >>>>> Simon >>>>> >>>>> >>>>>> I'm just posting this here as a reminder as this is probably going to >>>>>> become a problem pretty quickly for anybody who uses Lion or modern >>>>>> XCode and also likes using GHC, so it should probably be sorted out. >>>>>> :) I'm still on SL using XCode 4 so it's not an issue for me, but it >>>>>> will be for any future Mac endeavors. Hopefully they get support for >>>>>> __thread or something equivalent soon, because nobody likes >>>>>> performance hits, but it doesn't seem like we have a choice. >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Glasgow-haskell-users mailing list >>>>> Glasgow-haskell-users(a)haskell.org >>>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Glasgow-haskell-users mailing list >>>> Glasgow-haskell-users(a)haskell.org >>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >>>> >>> >> >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users(a)haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

Problems building 7.2.1
by David Beacham 16 Oct '11

16 Oct '11

I'm attempting to install ghc-7.2.1 from source on to a remote machine (so I have no control on upgrading tools/libraries), but running into a problem that I don't know how/if I can resolve: ===--- building phase 0 make -r --no-print-directory -f ghc.mk phase=0 phase_0_builds make[1]: Nothing to be done for `phase_0_builds'. ===--- building phase 1 make -r --no-print-directory -f ghc.mk phase=1 phase_1_builds make[1]: Nothing to be done for `phase_1_builds'. ===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all "rm" -f rts/dist/build/libHSrts-ghc7.2.1.so "inplace/bin/ghc-stage1" -package-name rts -shared -dynamic -dynload deploy -no-auto-link-packages `cat rts/libs.depend` rts/dist/build/Adjustor.dyn_o rts/dist/build/Arena.dyn_o rts/dist/build/Capability.dyn_o rts/dist/build/ClosureFlags.dyn_o rts/dist/build/Disassembler.dyn_o rts/dist/build/FrontPanel.dyn_o rts/dist/build/Globals.dyn_o rts/dist/build/Hash.dyn_o rts/dist/build/Hpc.dyn_o rts/dist/build/HsFFI.dyn_o rts/dist/build/Inlines.dyn_o rts/dist/build/Interpreter.dyn_o rts/dist/build/LdvProfile.dyn_o rts/dist/build/Linker.dyn_o rts/dist/build/Messages.dyn_o rts/dist/build/Papi.dyn_o rts/dist/build/Printer.dyn_o rts/dist/build/ProfHeap.dyn_o rts/dist/build/Profiling.dyn_o rts/dist/build/Proftimer.dyn_o rts/dist/build/RaiseAsync.dyn_o rts/dist/build/RetainerProfile.dyn_o rts/dist/build/RetainerSet.dyn_o rts/dist/build/RtsAPI.dyn_o rts/dist/build/RtsDllMain.dyn_o rts/dist/build/RtsFlags.dyn_o rts/dist/build/RtsMain.dyn_o rts/dist/build/RtsMessages.dyn_o rts/dist/build/RtsStartup.dyn_o rts/dist/build/RtsUtils.dyn_o rts/dist/build/Schedule.dyn_o rts/dist/build/Sparks.dyn_o rts/dist/build/Stable.dyn_o rts/dist/build/Stats.dyn_o rts/dist/build/StgCRun.dyn_o rts/dist/build/StgPrimFloat.dyn_o rts/dist/build/STM.dyn_o rts/dist/build/Task.dyn_o rts/dist/build/ThreadLabels.dyn_o rts/dist/build/ThreadPaused.dyn_o rts/dist/build/Threads.dyn_o rts/dist/build/Ticky.dyn_o rts/dist/build/Timer.dyn_o rts/dist/build/Trace.dyn_o rts/dist/build/Weak.dyn_o rts/dist/build/WSDeque.dyn_o rts/dist/build/hooks/FlagDefaults.dyn_o rts/dist/build/hooks/MallocFail.dyn_o rts/dist/build/hooks/OnExit.dyn_o rts/dist/build/hooks/OutOfHeap.dyn_o rts/dist/build/hooks/RtsOpts.dyn_o rts/dist/build/hooks/RtsOptsEnabled.dyn_o rts/dist/build/hooks/StackOverflow.dyn_o rts/dist/build/parallel/0Hash.dyn_o rts/dist/build/parallel/0Unpack.dyn_o rts/dist/build/parallel/Dist.dyn_o rts/dist/build/parallel/Global.dyn_o rts/dist/build/parallel/GranSim.dyn_o rts/dist/build/parallel/HLComms.dyn_o rts/dist/build/parallel/LLComms.dyn_o rts/dist/build/parallel/Pack.dyn_o rts/dist/build/parallel/Parallel.dyn_o rts/dist/build/parallel/ParallelDebug.dyn_o rts/dist/build/parallel/ParInit.dyn_o rts/dist/build/parallel/ParTicky.dyn_o rts/dist/build/parallel/RBH.dyn_o rts/dist/build/sm/BlockAlloc.dyn_o rts/dist/build/sm/Compact.dyn_o rts/dist/build/sm/Evac.dyn_o rts/dist/build/sm/GCAux.dyn_o rts/dist/build/sm/GC.dyn_o rts/dist/build/sm/GCUtils.dyn_o rts/dist/build/sm/MarkWeak.dyn_o rts/dist/build/sm/MBlock.dyn_o rts/dist/build/sm/Sanity.dyn_o rts/dist/build/sm/Scav.dyn_o rts/dist/build/sm/Storage.dyn_o rts/dist/build/sm/Sweep.dyn_o rts/dist/build/eventlog/EventLog.dyn_o rts/dist/build/posix/FileLock.dyn_o rts/dist/build/posix/GetEnv.dyn_o rts/dist/build/posix/GetTime.dyn_o rts/dist/build/posix/Itimer.dyn_o rts/dist/build/posix/OSMem.dyn_o rts/dist/build/posix/OSThreads.dyn_o rts/dist/build/posix/Select.dyn_o rts/dist/build/posix/Signals.dyn_o rts/dist/build/posix/TTY.dyn_o rts/dist/build/Apply.dyn_o rts/dist/build/Exception.dyn_o rts/dist/build/HeapStackCheck.dyn_o rts/dist/build/PrimOps.dyn_o rts/dist/build/StgMiscClosures.dyn_o rts/dist/build/StgStartup.dyn_o rts/dist/build/StgStdThunks.dyn_o rts/dist/build/Updates.dyn_o rts/dist/build/AutoApply.dyn_o -o rts/dist/build/libHSrts-ghc7.2.1.so /usr/bin/ld: rts/dist/build/Schedule.dyn_o: relocation R_X86_64_PC32 against `StgRun' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status I'm trying to build it with (let me know if you need anything else): gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-51) GNU ld version 2.17.50.0.6-14.el5 20061020 The Glorious Glasgow Haskell Compilation System, version 6.12.3 I can't install from the binary packages because I only have glibc-2.5 available on the machine I'm trying to build it on and it appears that the binaries have been built with or at least require glibc-2.7. Thanks for any help, David.

1 0

Re: [Haskell-cafe] Implementing a New primop
by Antoine Latter 14 Oct '11

14 Oct '11

Hi Paul, The ghc-users list might get you a quicker response to this sort of question. Maybe a good start would be to give us a listing of which files you've modified so far. Antoine On Fri, Oct 14, 2011 at 4:49 PM, Paul Monday <paul.monday(a)parsci.com> wrote: > Alright, I wandered through some primtype issues, but I'm having another odd > problem as I try to define my own primop. I've followed what the various > wiki pages have to offer > (primarily http://hackage.haskell.org/trac/ghc/wiki/AddingNewPrimitiveOperations and http://hackage.haskell.org/trac/ghc/wiki/Commentary/PrimOps) > without success. I even unraveled my PrimOp to be, basically, an exact copy > of another PrimOp without luck. > The primop I'm attempting to add is now very, very simple and copies > FloatAddOp exactly so there must be an additional file I have to modify > before the primop is "completely" added. > ./compiler/prelude/primops.txt.pp > primop FloatVAddOp "plusFloatVec#" Dyadic > Float# -> Float# -> Float# > with commutable = True > ./compiler/codeGen/CgPrimOp.hs > translateOp FloatVAddOp = Just (MO_F_Add W32) > The compiler error is below. I have the feeling that an interface is not > being built somewhere … this must be a simple one but I can't find any > references to this error anywhere … has anyone seen this one before????? > "inplace/bin/ghc-stage1" -H64m -O0 -fasm -package-name ghc-7.3.20111007 > -hide-all-packages -i -icompiler/basicTypes -icompiler/cmm > -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci > -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main > -icompiler/nativeGen -icompiler/parser -icompiler/prelude > -icompiler/profiling -icompiler/rename -icompiler/simplCore > -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn > -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils > -icompiler/vectorise -icompiler/stage2/build -icompiler/stage2/build/autogen > -Icompiler/stage2/build -Icompiler/stage2/build/autogen > -Icompiler/../libffi/build/include -Icompiler/stage2 > -Icompiler/../libraries/base/cbits -Icompiler/../libraries/base/include > -Icompiler/. -Icompiler/parser -Icompiler/utils -optP-DGHCI -optP-include > -optPcompiler/stage2/build/autogen/cabal_macros.h -package Cabal-1.11.2 > -package array-0.3.0.3 -package base-4.4.0.0 -package bin-package-db-0.0.0.0 > -package bytestring-0.9.2.0 -package containers-0.4.2.0 -package > directory-1.1.0.1 -package filepath-1.2.0.1 -package hoopl-3.8.7.2 -package > hpc-0.5.1.0 -package old-time-1.0.0.7 -package process-1.1.0.0 -package > template-haskell-2.6.0.0 -package unix-2.5.0.0 -Wall > -fno-warn-name-shadowing -fno-warn-orphans -XHaskell98 > -XNondecreasingIndentation -XCPP -XMagicHash -XUnboxedTuples -XPatternGuards > -XForeignFunctionInterface -XEmptyDataDecls -XTypeSynonymInstances > -XMultiParamTypeClasses -XFlexibleInstances -XRank2Types > -XScopedTypeVariables -XDeriveDataTypeable -DGHCI_TABLES_NEXT_TO_CODE > -DSTAGE=2 -O0 -fasm -no-user-package-conf -rtsopts -odir > compiler/stage2/build -hidir compiler/stage2/build -stubdir > compiler/stage2/build -hisuf hi -osuf o -hcsuf hc -c > compiler/iface/BinIface.hs -o compiler/stage2/build/BinIface.o > ghc-stage1: panic! (the 'impossible' happened) > (GHC version 7.3.20111007 for x86_64-unknown-linux): > applyTypeToArgs > ghc-prim:GHC.Prim.sizeofMutableArray#{(w) v 91V} [gid[PrimOp]] > @ e{tv i4L2} [tv] ds{v i4Lc} [lid] i#{v i4Lg} [lid] > forall a{tv 12} [tv]. > ghc-prim:GHC.Prim.MutableArray#{(w) tc 31m} > e{tv i4L2} [tv] a{tv 12} [tv] > -> ghc-prim:GHC.Prim.Int#{(w) tc 3G} > > Paul Monday > Parallel Scientific, LLC. > paul.monday(a)parsci.com > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > >

2 1

Is this a concurrency bug in base?
by Jean-Marie Gaillourdet 14 Oct '11

14 Oct '11

Hi, I am working on a library I'd like to release to hackage very soon, but I've found a problem with supporting GHC 6.12 and GHC 7.0. Consider the following program: import Control.Concurrent import Data.Typeable main :: IO () main = do { fin1 <- newEmptyMVar ; fin2 <- newEmptyMVar ; forkIO $ typeRepKey (typeOf ()) >>= print >> putMVar fin1 () ; forkIO $ typeRepKey (typeOf ()) >>= print >> putMVar fin2 () ; () <- takeMVar fin1 ; () <- takeMVar fin2 ; putStrLn "---" ; return () } When compiled with GHC 7.0.x or GHC 6.12.x, it should print two identical numbers. Sometimes it does not. To reproduce this compile and execute as follows: $ ghc-7.0.3 -rtsopts -threaded TypeRepKey.hs -o TypeRepKey $ while true ; do ./TypeRepKey +RTS -N ; done 0 0 --- 0 0 --- 0 0 --- 0 1 --- 0 0 --- … Ideally you should get an infinite number of zeros but once in a while you have a single(!) one in between. The two numbers of one program run should be identical, but their values may be arbitrary. But it should not be possible to have single outliers. This only happens when executed with more than one thread. I've also a somewhat larger program which seems to indicate that fromDynamic fails occasionally. I can post it as well if it helps. This seems to be a Heisenbug as it is extremely fragile, when adding a "| grep 1" to the while loop it seems to disappears. At least on my computers. All this was done on several Macs running the latest OS X Lion with ghc 7.0.3 from the binary distribution on the GHC download page. Actually, I am trying to find a method to use a "type" as key in a map which works before GHC 7.2. I'd be glad to get any ideas on how to achieve that, given that typeRepKey seems to buggy. I'd be happy to get any comments on this matter. Regards, Jean

7 22

Building GHC for Mac OS X 10.5
by Sean Leather 13 Oct '11

13 Oct '11

After many years, I have once again attempted to build GHC from source. The experience went much easier than in the past. This time, my system is running the now-old 10.5 (Leopard) using Xcode 3.1.4. I'm probably the only one who wants to build on 10.5, but I still appreciate the fact that GHC can be built on a variety of systems, allowing more people (like me) to hack on it. I ran into a few minor issues when building. (1) I had a problem with gmp. No surprise, and I didn't want to fight it, so I built with integer-simple by adding INTEGER_LIBRARY=integer-simple to ./mk/build.mk . (2) It appears that integer-simple has a copy-paste bug that was easy to fix: $ cd libraries/integer-simple/ $ git diff diff --git a/GHC/Integer/Type.hs b/GHC/Integer/Type.hs index 02eeef2..f620e67 100644 --- a/GHC/Integer/Type.hs +++ b/GHC/Integer/Type.hs @@ -97,8 +97,8 @@ integerToInt i = word2Int# (integerToWord i) integerToWord64 :: Integer -> Word64# integerToWord64 i = int64ToWord64# (integerToInt64 i) -{-# NOINLINE word64ToInteger:: #-} -word64ToInteger:: Word64# -> Integer +{-# NOINLINE word64ToInteger #-} +word64ToInteger :: Word64# -> Integer word64ToInteger w = if w `eqWord64#` wordToWord64# 0## then Naught else Positive (word64ToPositive w) (3) A linker flag was added for Xcode 4 that is not available in 3.1. $ git diff diff --git a/compiler/main/DriverPipeline.hs b/compiler/main/DriverPipeline.hs index b655425..ec8024d 100644 --- a/compiler/main/DriverPipeline.hs +++ b/compiler/main/DriverPipeline.hs @@ -1682,10 +1682,12 @@ linkBinary dflags o_files dep_packages = do -- like -- ld: warning: could not create compact unwind for .LFB3: non-standard register 5 -- on x86. +{- ++ (if platformOS (targetPlatform dflags) == OSDarwin && platformArch (targetPlatform dflags) `elem` [ArchX86, ArchX86_64] then ["-Wl,-no_compact_unwind"] else []) +-} -- '-Wl,-read_only_relocs,suppress' -- ld gives loads of warnings like: I think the fix to integer-simple should be applied, since it's an obvious improvement. I suspect the last issue might be controversial, since it seems to involve an apparently incompatible difference between the older and newer Xcode versions. Of course, I would like to see the older version still supported, but, as I said, I may be among a very small minority in this vote. Regards, Sean

2 1

[GHC API] How to retrieve the result of a statement evaluation ?
by Alain Cremieux 13 Oct '11

13 Oct '11

Hi, I am trying to move to GHC 7.2.1, and have problems replacing 'hint', which is not available anymore (and is overkill for what I need to do). So I decided to use GHC API instead, but I can't make it work exactly as I'd like. I need to evaluate simple statements, like ["xx" ++ show i | i <- [1..3]] I use something like : res <- runStmt src RunToCompletion (after loading the Prelude, and putting the statement in the String src), but it prints (correctly) the result, and I don't find a way to retrieve it in my program. The variable 'it' is bound, but I can't get its value. Am I missing something obvious ? Should I redirect the output somewhere, and how ? Thanks, Alain

1 0

Re: GHC, Clang & XCode 4.2
by Simon Marlow 12 Oct '11

12 Oct '11

On 11/10/2011 18:45, David Peixotto wrote: > Ok, I have attached a set of patches to support building the GHC > runtime with llvm-gcc. The patches are based off of commit > 29a97fded4010bd01aa0a17945c84258e285d421 which was last Friday's HEAD. > These patches are also available from my github repository on the > llvm-gcc branch at > > git://github.com/dmpots/ghc.git > > There are three patches: > > 0001- Uses pthread_getspecific and pthread_setspecfic to > access gct when the `llvm_CC_FLAVOR` CPP macro is > set > > 0002- Modifies the configure scripts to set the > `llvm_CC_FLAVOR` macro when compiling with an llvm > based compile (either llvm-gcc or clang) > > 0003- Passes the gct variable as a parameter in the GC. This > change is parameterized with CPP macros so that it > is only in effect when compiling for an llvm-based > compiler. > > The patches 0001 and 0002 provide the minimal support needed to build > GHC with llvm-gcc. The 0003 patch is there to limit the performance > hit we get by going through pthread functions to access the gct. I > think the 0001 and 0002 patches should not be very controversial, but > the 0003 patch is a more invasive change and perhaps Simon Marlow will > want to clean it up before it is applied. Thanks, I'll take a look at these soon. Just a thought, but someone might want to write a blog post about how Apple's choice to move to llvm-gcc is imposing a performance penalty on us here, and get it up on Reddit. That would give the issue some publicity (they love that sort of thing on Reddit), and might result in some action. I'd be happy to proof read a blog post before publication. Some simple benchmarks would be needed - one option is to use GHC itself with the various combinations of compilers + RTS changes, or there are a small set of GC benchmarks in nofib/gc. Cheers, Simon > I ran a validate with the patches, and found one additional failure > when going through an llvm-based compiler. There were no additional > failures when using a gcc compiler even with my patches applied. The > additional failure is the cgrun071 test which tests the popCnt > primitives. I'm going to look into why that test fails, but I think > the patches should be safe to apply as it would only show up when > compiling with llvm-gcc, which is currently impossible without these > patches. > > -David > > > > > > > On Oct 7, 2011, at 10:30 AM, David Peixotto wrote: > >> >> On Oct 6, 2011, at 7:32 AM, Simon Marlow wrote: >> >>> On 05/10/2011 09:46, austin seipp wrote: >>>> There has been recent discussion on the Homebrew bug tracker >>>> concerning the upcoming XCode 4.2 release by Apple, which has >>>> apparently just gone GM (meaning they're going to make a real release >>>> on the app store Real Soon Now.) >>>> >>>> The primary concern is that XCode will no longer ship GCC 4.2 at all, >>>> it seems. XCode 4.0& 4.1 merely set 'llvm-gcc' as the default >>>> compiler, and GHC's `configure` script was adjusted to find the >>>> `gcc-4.2` binary. If you have old XCode's installed, then you may have >>>> the binaries laying around, but I doubt they'll be on your $PATH, and >>>> anybody doing a fresh install is SOL. >>>> >>>> It seems Clang 3.0 will now be the default compiler, with llvm-gcc as >>>> a deprecated option, probably removed in XCode 4.3. It doesn't matter >>>> really, because both of them do not work with GHC, because of its use >>>> of either A) Global register variables of any kind, or B) the __thread >>>> storage modifier. >>>> >>>> David Peixotto did some work on this not too long ago as the issue of >>>> compiling with Clang was raised. His branches include changes which >>>> make the 'gct' variable use pthread_getspecific rather than __thread >>>> for TLS and then as an optimization use inline ASM to grab the value >>>> out of the variable, with an impact of about 9% it seems, but that's >>>> on nofib and I don't know if it was -threaded. He also included a >>>> version which passes the 'gct' around as a parameter to all GCC >>>> functions which is a bit uglier but may give some better performance I >>>> guess. (The discussion is from here IIRC.) I suppose the real perf >>>> killer here is probably -threaded code. >>>> >>>> https://github.com/dmpots/ghc >>>> >>>> Was there ever any decision on which route to take for this issue? The >>>> parameter passing solution looks quite uglier IMO but it may be >>>> necessary for performance. >>> >>> I'm happy to incorporate the parameter-passing changes if necessary. I think it should only be important in the inner loop of the GC (scavenge_block/evacuate and the functions called from there). If someone sends me a working patch, I can clean it up as much as possible. >> >> I will take a look at getting the patches to work with GHC head. To support llvm-gcc we need two basic things: >> >> 1. autoconf support to detect when we are compiling with llvm-gcc >> 2. a work-around for tls in the gc >> >> My old patches take care of both 1 and 2. For #2 the easy approach is using pthread_getspecific which is a pretty small change. Passing gct as a parameter is much uglier more invasive change, but I had it working at some point. It could perhaps be made less ugly by only passing it around in the "important" functions. >> >> Supporting clang is going to require more changes. The last time I tried there were problems with the preprocessor that made it not work. I just tried again yesterday and ran into a problem generating makefile dependencies because apparently clang does not allow both the -MM and -MF flags (http://llvm.org/bugs/show_bug.cgi?id=8312) >> >> >>> Note that some of the overhead measured by David is coming from using the LLVM backend to gcc instead of gcc's own backend. In my own measurements a few months ago I found LLVM generated slower (but smaller) code for the GC. Maybe this will change over time. It's also possible that the current GC code is tuned for gcc - at various times in the past I've gone through and tweaked the code to get good assembly out (much as we teak Haskell to get good Core :-). >>> >>> Cheers, >>> Simon >>> >>> >>>> I'm just posting this here as a reminder as this is probably going to >>>> become a problem pretty quickly for anybody who uses Lion or modern >>>> XCode and also likes using GHC, so it should probably be sorted out. >>>> :) I'm still on SL using XCode 4 so it's not an issue for me, but it >>>> will be for any future Mac endeavors. Hopefully they get support for >>>> __thread or something equivalent soon, because nobody likes >>>> performance hits, but it doesn't seem like we have a choice. >>>> >>> >>> >>> _______________________________________________ >>> Glasgow-haskell-users mailing list >>> Glasgow-haskell-users(a)haskell.org >>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >>> >> >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users(a)haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> >

3 2