- Glasgow-haskell-users

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 14 Oct '11

14 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 13 Oct '11

13 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

Unwanted eta-expansion
by Roman Cheplyaka 13 Oct '11

13 Oct '11

Suppose I want a foldl which is evaluated many times on the same list but with different folding functions. I would write something like this, to perform pattern-matching on the list only once: module F where myFoldl :: [a] -> (b -> a -> b) -> b -> b myFoldl [] = \f a -> a myFoldl (x:xs) = let y = myFoldl xs in \f a -> y f (f a x) However, for some reason GHC eta-expands it back. Here's what I see in the core: % ghc -O2 -ddump-simpl -fforce-recomp -dsuppress-module-prefixes \ -dsuppress-uniques -dsuppress-coercions F.hs ==================== Tidy Core ==================== Rec { myFoldl [Occ=LoopBreaker] :: forall a b. [a] -> (b -> a -> b) -> b -> b [GblId, Arity=3, Caf=NoCafRefs, Str=DmdType SLL] myFoldl = \ (@ a) (@ b) (ds :: [a]) (eta :: b -> a -> b) (eta1 :: b) -> case ds of _ { [] -> eta1; : x xs -> myFoldl @ a @ b xs eta (eta eta1 x) } end Rec } Why does it happen and can it be suppressed? This is GHC 7.0.4. -- Roman I. Cheplyaka :: http://ro-che.info/

4 7

GHC infinite loop when building vector program
by Bas van Dijk 12 Oct '11

12 Oct '11

Hello, When benchmarking my new vector-bytestring[1] package I discovered that building the following program causes GHC to go into, what seems to be, an infinite loop: import Data.Vector (Vector) import qualified Data.Vector.Generic as VG main = print $ VG.foldl f z (VG.fromList [] :: Vector Int) f = flip (:) z = [] I build it with: $ ghc --make vectorGHCloop.hs -O2 It compiles fine without the -O2 or if you specify -fno-enable-rewrite-rules. So it's probably a loop in a rule somewhere. Note that the program also builds fine when I change the 'f' and 'z' to: f = flip (:) z = [] I use vector-0.9 and ghc-7.2.1. Regards, Bas [1] https://github.com/basvandijk/vector-bytestring

2 3

Making a small GHC installation
by Iavor Diatchki 12 Oct '11

12 Oct '11

Hello, Does anyone have any advice about how I might make a smallish GHC installation? The context is that I need to make a demo VM, which has a limited amount of space, and I'd like to have GHC installed on the system but the default GHC installation (~700MB) does not fit. The installation does not need to be complete---I don't need documentation, or profiling, or Template Haskell---and I only need to install a fairly limited set of libraries, just enough to build my project. I'd be happy to build a custom version of GHC, if that's the easiest way to achieve the goal. So, if you have experience doing something similar, or you know of what might be the best way to approach the problem, advice would be most welcome! -Iavor

4 3

foldr oddity
by Frodo Chao 12 Oct '11

12 Oct '11

Hi, I came upon this when playing with foldr and filter. Compare the two definitions: testr n = foldr (\x y -> x && y) True [t | (_, t) <- zip [1 .. n] [True, True ..]] testr' n = foldr (\x y -> y && x) True [t | (_, t) <- zip [1 .. n] [True, True ..]] I tried these functions on ghci (The Glorious Glasgow Haskell Compilation System, version 7.0.3), and get the following results (with :set +s): testr 1000000 => True (0.01 secs, 7920832 bytes) testr' 1000000 => True (8.72 secs, 446585344 bytes) This bizarre (at least to me) behavior also applies to ||. Should I mind the orderings of the parameters (especially the accumulator) in the function passed to foldr? Thak you for reading. Sincerely yours, Frodo Chao

4 5

Fwd: Two Proposals
by Philip Wadler 12 Oct '11

12 Oct '11

George, Thanks very much for this. I like your suggestion, which fits the logical structure perfectly; and you've suggested a neat way around the ugliness of 'group groupBy'. I also note that if we aren't so worried about not introducing new keywords, that 'then group' could become 'group'. Yours, -- P On Mon, Oct 10, 2011 at 11:21 PM, George Giorgidze <giorgidze(a)gmail.com> wrote: > A quick thought that came to me after hoogling [a] -> [[a]]. > The first four functions in the search result are named after what they > return (noun in plural) rather than what they do (verb). I am talking about > inits, permutations, subsequence and tails. > So I thought the following syntax might work as well if (as it is already > common) grouping functions are named after what they return. > then f > then f by e > then group f > then group f by e > For example the following code fragments read well: > then group inits > then group permutations > then group subsequences > then group tails > Here we use the special identifier group as a verb. > I have not told you about the fifth result of the hoogling, the groupWith > function. The following really looks ugly: > then group groupWith by e > But following the aforementioned naming convention the groupWith function > could as well be named as equals. Now this reads well: > then group equals by e > Cheers, George -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

Re: Two Proposals
by Roman Leshchinskiy 11 Oct '11

11 Oct '11

Manuel M T Chakravarty wrote: > Roman Leshchinskiy: >> >> What data structures other than lists do we want to construct using list >> literals? I'm not really sure what the use cases are. > > Parallel arrays! (I want to get rid of our custom syntax.) Why? Don't you think it is useful to have a visual indication of which data structure you are using and what is going to be evaluated in parallel? In any case, if we want to get rid of the parallel array syntax, we have to overload list literals, enumerations and list comprehensions. We have the generic monadic desugaring for the latter but recovering an efficient DPH program from that sn't trivial. Roman

4 4