- ghc-tickets - Haskell.org

Re: [GHC] #910: --make should have a -j flag for parallel building
by GHC 01 Sep '13

01 Sep '13

#910: --make should have a -j flag for parallel building -------------------------------------+------------------------------------ Reporter: igloo | Owner: Type: feature request | Status: patch Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: N/A | Blocked By: 8184 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by rrnewton): Have you tested `cabal -j` on this branch? They *should* compose fine, and I'd love to see what kind of speedup one can get installing the Haskell Platform packages. Unfortunately, right now I get a whole bunch of undefined reference errors when I try something like this: time cabal-1.18.0 install -j30 --disable-library-profiling --disable- documentation HUnit --reinstall Btw, I see the same problem with cabal 1.16.0.2. But taking away the -j30 makes it work. I do NOT have the same problem on master (8c99e698476291c) presently, nor on earlier versions of HEAD from 2013.08.04. (Yet, this might have nothing to do with parcs patches, of course. There are another ~46 patches that are on master but not on the `ghc-parmakegsoc` branch. Fast forwarding the branch will be my next step.) Notice that, weirdly, this problem occurs even when `ghc -j` is not used (as above). For reference here is a sample of the errors: {{{ cabal-1.17.0-HEAD-20130802: Error: some packages failed to install: HUnit-1.2.5.2 failed during the configure step. The exception was: user error (/home/beehive/ryan_scratch/ghc-parGSOC2/libraries/Cabal/Cabal/dist- install/build/libHSCabal-1.18.0.a(Simple__64.o): In function `chbT_info': (.text+0x857): undefined reference to `rff5_info' /home/beehive/ryan_scratch/ghc-parGSOC2/libraries/Cabal/Cabal/dist- install/build/libHSCabal-1.18.0.a(Simple__64.o): In function `sg4L_info': ... }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/910#comment:41> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #910: --make should have a -j flag for parallel building
by GHC 01 Sep '13

01 Sep '13

#910: --make should have a -j flag for parallel building -------------------------------------+------------------------------------ Reporter: igloo | Owner: Type: feature request | Status: patch Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: N/A | Blocked By: 8184 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by akio): * cc: tkn.akio@… (added) Comment: #8209 might be related to the {{{setNumCapabilities}}} issue. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/910#comment:40> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7327: Inconsistent behavior for relative paths in runProcess
by GHC 01 Sep '13

01 Sep '13

#7327: Inconsistent behavior for relative paths in runProcess --------------------------------------+------------------------------------ Reporter: snoyberg | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: libraries/process | Version: 7.6.1 Resolution: worksforme | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by Blaisorblade): `runProcess` behavior is however still undocumented: http://hackage.haskell.org/packages/archive/process/latest/doc/html /System-Process.html#v:runProcess — should I open another bug for that? We're still observing symptoms, but the behavior might have been fixed in recent versions of libraries for Linux (different Linux machines, with different library versions, show different behavior in https://github.com/haskell/cabal/issues/1458#issuecomment-23616162) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7327#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7684: cgrun071 segfaults
by GHC 01 Sep '13

01 Sep '13

#7684: cgrun071 segfaults ----------------------------------+---------------------------------- Reporter: tibbe | Owner: leroux Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: cgrun071 | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by leroux): My fix is to simply apply a mask of n-bits to the word being passed to the fast population count function. After fixing the {{{popcnt8}}} test, I found that {{{popcnt16}}} also had the same problem, so I ended up applying the fix to 8, 16 and 32 bit word tests. {{{ test_popCnt8 = test (popcntMask 8 popcnt8) (slowPopcnt . wordMask 8) test_popCnt16 = test (popcntMask 16 popcnt16) (slowPopcnt . wordMask 16) test_popCnt32 = test (popcntMask 32 popcnt32) (slowPopcnt . wordMask 32) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7684#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7684: cgrun071 segfaults
by GHC 01 Sep '13

01 Sep '13

#7684: cgrun071 segfaults ----------------------------------+---------------------------------- Reporter: tibbe | Owner: leroux Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: cgrun071 | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Changes (by leroux): * status: new => patch * testcase: => cgrun071 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7684#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7684: cgrun071 segfaults
by GHC 01 Sep '13

01 Sep '13

#7684: cgrun071 segfaults ----------------------------------+---------------------------------- Reporter: tibbe | Owner: leroux Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Changes (by leroux): * owner: => leroux Comment: I've run into this same problem on OS X 10.8.4 x86_64. I dug into cgrun071 and found that it's a problem with {{{popcnt8}}}. Whenever {{{popcnt8}}} encounters very "large" numbers, it segaults. {{{ map (\x -> (x, popcnt8 x)) $ iterate (+1000) 1 }}} I ran this expression multiple times expecting it to segfault at the same point, but it did otherwise. Whenever it broke, I tested the integer and it would simply segfault. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7684#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #910: --make should have a -j flag for parallel building
by GHC 31 Aug '13

31 Aug '13

#910: --make should have a -j flag for parallel building -------------------------------------+------------------------------------ Reporter: igloo | Owner: Type: feature request | Status: patch Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: N/A | Blocked By: 8184 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by rrnewton): Ok, I'm trying to get a decent set of libraries installed to test this well. The very first thing I cabal installed ('text') did get a small speedup. However, I'm also seeing some excessive system time. This may have nothing to do with the parallel make approach and just be a function of the new IO manager. In fact, if I understand the design, worker threads in this model should either be running or blocked on MVars. (That's good for avoiding wasted user time as well, unlike work-stealing which burns cycles looking for work.) I'm running on a 32-core Intel Westmere machine, using this command to install `text` version 0.11.3.1: {{{ time cabal install text --ghc-options="-j24" --reinstall }}} Notice that in this simple test I am relying on the `setNumCapabilities` behavior. Here are the times: {{{ * 1 thread: real 1m20.028s user 1m17.921s sys 0m1.768s * 2 threads: real 1m7.417s user 1m22.818s sys 0m14.891s * 4 threads: real 0m59.528s user 1m29.110s sys 0m37.981s * 8 threads: real 0m57.219s user 1m54.461s sys 1m31.703s * 16 threads: real 1m6.225s user 4m46.976s sys 3m32.661s * 24 threads: real 1m16.501s user 9m53.254s sys 6m3.375s * 31 threads: real 1m27.445s user 17m0.314s sys 8m0.175s }}} Well, it's nice that final sequential time is not much worse than the one- threaded time! Finally, here is the fingerprint: {{{ .|4880dfaeafec1fc65568a5445a70ec4286949123 ghc-tarballs|f190b3ce329422e13cbe1b5dad030058ca4bdda7 libffi-tarballs|a0088d1da0e171849ddb47a46c869856037a01d1 libraries/Cabal|9f374ab45e62924506b992db9157c970c7259a03 libraries/Win32|3da00d80f2fd7d1032e3530e1af1b39fba79aac3 libraries/array|b5779026c4d760cc380ef1fc18403534dced55c1 libraries/base|1b725f6ada6c4ddb011172408291a64498d199cb libraries/binary|2799c25d85b4627200f2e4dcb30d2128488780c3 libraries/bytestring|7d5b516ad0937b7cdc29798db33a37a598123b6c libraries/containers|154cd539a22e4d82ff56fec2d8ad38855f78513a libraries/deepseq|420507ea418db8664a79aedaa6588b772e8c97c6 libraries/directory|571f32b2a0af7404a8483af5b1791361c5528ab6 libraries/filepath|8d34f787e06bf3a1802992246785939901dec8aa libraries/ghc-prim|84fed8933a53cd15e39123a8a0067369c060e69e libraries/haskeline|40bcd6ac30577d1d240166674d1e328ac52c1fd5 libraries/haskell2010|1c055868f748acb2945cb5652b3fdea6226e8862 libraries/haskell98|40300d61f29aa8d9953079d14fb5b2f1e5e04184 libraries/hoopl|8e0ef3b7bf6d25919209f74d65c4a77c6689934d libraries/hpc|a7231c6727de54d17ce14b1286cfe88c4db95783 libraries/integer-gmp|cfcd248c0921aafe599c8547022686c5289bf743 libraries/integer-simple|5d9c6565550fb5c9c38f69475f52a2ba1d3edf98 libraries/old-locale|df98c76b078de507ba2f7f23d4473c0ea09d5686 libraries/old-time|7e0df2eb500ce4381725b868440fde04fa139956 libraries/pretty|0b8eada2d4d62dd09ee361d8b6ca9b13e6573202 libraries/primitive|c6b1e204f0f2a1a0d6cb1df35fa60762b2fe3cdc libraries/process|5d47829c123c10711d14dd089b4d8d65f8289f3b libraries/random|4b68afd3356674f12a67a4e381fa9becd704fab2 libraries/template-haskell|ec6d5a7c9b0c9e2fb1ce10d776cff74548e17981 libraries/terminfo|116d3ee6840d52bab69c880d775ae290a20d64bc libraries/time|d4f019b2c6a332be5443b5bf88d0c7fef91523c6 libraries/transformers|a59fb93860f84ccd44178dcbbb82cfea7e02cd07 libraries/unix|ffdb844069497b276a719b0c89be35bd18095f22 libraries/vector|f27156970d9480806a5defcfea5367187c2a6997 libraries/xhtml|fb9e0bbb69e15873682a9f25d39652099a3ccac1 testsuite|5cad49d42e434130671c3d14692d73d56253fab8 utils/haddock|90ad0ea538d2fafed2047de8414c55627b94e879 utils/hsc2hs|46abf34f337dbc5fa638f06912e34966a9d1a147 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/910#comment:39> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8004: Applicative/Monad proposal related warnings (AMP phase 1)
by GHC 31 Aug '13

31 Aug '13

#8004: Applicative/Monad proposal related warnings (AMP phase 1) -------------------------------------+------------------------------------ Reporter: quchen | Owner: quchen Type: feature request | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by hvr): * cc: hvr (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8004#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8116: Segfault/panic of 32bit GHCi on Mac
by GHC 31 Aug '13

31 Aug '13

#8116: Segfault/panic of 32bit GHCi on Mac ------------------------------------+------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------- 32bit GHCi on Mac causes segfault/panic: With GHC 7.6.3: {{{ > :m Data.Complex [Prelude Data.Complex] > ((-2) :+ 0)**(1.5 :+ 0) zsh: segmentation fault ghci }}} With GHC head: {{{ > :m Data.Complex > ((-2) :+ 0)**(1.5 :+ 0) ghc: panic! (the 'impossible' happened) (GHC version 7.7.20130805 for i386-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/k0/548g5xg90jjfbrj5j09nvwv80000gq/T/ghc124_0/ghc124_0.dylib, 9): Library not loaded: /Users/kazu/work/ghc/libraries/base/dist- install/build/libHSbase-4.7.0.0-ghc7.7.20130805.dylib Referenced from: /var/folders/k0/548g5xg90jjfbrj5j09nvwv80000gq/T/ghc124_0/ghc124_0.dylib Reason: image not found Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} 64bit GHCi does not cause this problem. Any GHCi on Linux and FreeBSD do not cause this problem. If the code is compiled with 32bit GHC on Mac, it works fine. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8116> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #8195: Different floating point results with -msse2 on 32bit Linux
by GHC 31 Aug '13

31 Aug '13

#8195: Different floating point results with -msse2 on 32bit Linux --------------------------+------------------------------------------------ Reporter: | Owner: jstolarek | Status: new Type: bug | Milestone: Priority: normal | Version: 7.7 Component: | Operating System: Linux Compiler (NCG) | Type of failure: None/Unknown Keywords: | Test Case: perf/should_run/Conversions Architecture: x86 | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ I noticed strange behaviour of `Conversions` test on 32bit machines. Here's the code of this test: {{{ {-# LANGUAGE BangPatterns #-} -- | Tests that conversions between various primitive types (e.g. -- Word, Double, etc) doesn't allocate. module Main (main) where import Data.Word -- Repeatedly convert Words to Doubles loop :: Floating a => Word -> a loop n = go 0 0.0 where go i !acc | i < n = go (i+1) (acc + fromIntegral i) | otherwise = acc {-# SPECIALISE loop :: Word -> Float #-} {-# SPECIALISE loop :: Word -> Double #-} main :: IO () main = do print (loop 1000000 :: Float) print (loop 1000000 :: Double) }}} This test is expected to produce: {{{ [t-jastol@cam-05-unx : /5playpen/t-jastol/ghc-validate] inplace/bin/ghc- stage2 -O -fforce-recomp testsuite/tests/perf/should_run/Conversions.hs [1 of 1] Compiling Main ( testsuite/tests/perf/should_run/Conversions.hs, testsuite/tests/perf/should_run/Conversions.o ) Linking testsuite/tests/perf/should_run/Conversions ... [t-jastol@cam-05-unx : /5playpen/t-jastol/ghc-validate] ./testsuite/tests/perf/should_run/Conversions 4.9994036e11 4.999995e11 }}} My optimization of self-recursive tail loops (d61c3ac186c94021c851f7a2a6d20631e35fc1ba) broke that and now both `Float` and `Double` results are identical: {{{ 4.999995e11 4.999995e11 }}} I believe my optimisation shouldn't affect this, but clearly it does. Now here's the interesting part: if I generate SSE assembly by adding `-msse2` flag, then I get expected results: {{{ 4.9994036e11 4.999995e11 }}} I'm not sure if we should get different results for different instruction sets. I'm putting it up as a ticket so perhaps we could investigate this more one day if we consider it relevant. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8195> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5