- ghc-tickets - Haskell.org

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

05 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: cgrun071 | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by tibbe): As you can see from the assembly the `POPCNT` instruction is never used and can't thus be the cause of the segfault. Besides, if I remember correctly incorrect instructions give an "illegal instruction" crash on OS X, not a segfault. The ghc-prim function is called {{{ call hs_popcnt16 }}} so the issue is most likely to do with that call (e.g. narrowing). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7684#comment:21> 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 05 Sep '13

05 Sep '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 bgamari): * cc: bgamari@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8004#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

05 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: cgrun071 | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by tibbe): I'm confused. The test isn't compiled with -msse42 and thus the popcnt instruction should never be omitted (check the output assembly to make sure) so it seems more likely that the failure has to do with narrowing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7684#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8191: Do not trim type environment when reporting type holes
by GHC 05 Sep '13

05 Sep '13

#8191: Do not trim type environment when reporting type holes ------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Andres writes: I've just started playing with `TypeHoles`. (I'm writing some Haskell course materials and would like to use them from the very beginning once they become available.) However, I must say that I don't understand the current notion of "relevance" that seems to determine whether local bindings are included or not. The current rule seems to be that bindings are included only if the intersection between the type variables their types involve and the type variables in the whole is non-empty. However, I think this is confusing. Let's look at a number of examples: {{{ > f1 :: Int -> Int -> Int > f1 x y = _ Found hole ‛_’ with type: Int In the expression: _ In an equation for ‛f1’: f1 x y = _ }}} No bindings are shown. {{{ > f2 :: a -> a -> a > f2 x y = _ Found hole ‛_’ with type: a Where: ‛a’ is a rigid type variable bound by the type signature for f2 :: a -> a -> a at List.hs:6:7 Relevant bindings include f2 :: a -> a -> a (bound at List.hs:7:1) x :: a (bound at List.hs:7:4) y :: a (bound at List.hs:7:6) In the expression: _ In an equation for ‛f2’: f2 x y = _ }}} Both `x` and `y` (and `f2`) are shown. Why should this be treated differently from `f1`? {{{ > f3 :: Int -> (Int -> a) -> a > f3 x y = _ Found hole ‛_’ with type: a Where: ‛a’ is a rigid type variable bound by the type signature for f3 :: Int -> (Int -> a) -> a at List.hs:9:7 Relevant bindings include f3 :: Int -> (Int -> a) -> a (bound at List.hs:10:1) y :: Int -> a (bound at List.hs:10:6) In the expression: _ In an equation for ‛f3’: f3 x y = _ }}} Here, `y` is shown, but `x` isn't, even though `y` has to be applied to an Int in order to produce an `a`. Of course, it's possible to obtain an `Int` from elsewhere ... {{{ f4 :: a -> (a -> b) -> b f4 x y = _ Found hole ‛_’ with type: b Where: ‛b’ is a rigid type variable bound by the type signature for f4 :: a -> (a -> b) -> b at List.hs:12:7 Relevant bindings include f4 :: a -> (a -> b) -> b (bound at List.hs:13:1) y :: a -> b (bound at List.hs:13:6) In the expression: _ In an equation for ‛f4’: f4 x y = _ }}} Again, only `y` is shown, and `x` isn't. But here, the only sane way of filling the hole is by applying `y` to `x`. Why is one more relevant than the other? {{{ f5 x y = _ Found hole ‛_’ with type: t2 Where: ‛t2’ is a rigid type variable bound by the inferred type of f5 :: t -> t1 -> t2 at List.hs:15:1 Relevant bindings include f5 :: t -> t1 -> t2 (bound at List.hs:15:1) In the expression: _ In an equation for ‛f5’: f5 x y = _ }}} Neither `x` and `y` are included without a type signature. Even though all of the above types are admissible, which would convince GHC that one or even all may be relevant. IMHO, this isn't worth it. It's a confusing rule. Just include all local bindings in the output, always. That's potentially verbose, but easy to understand. It's also potentially really helpful, because it trains beginning programmers to see what types local variables get, and it's a way to obtain complex types of locally bound variables for expert programmers. It's also much easier to explain. It should be easier to implement, too :) Could we please change it? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8191> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

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

05 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: cgrun071 | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by leroux): The problem has been pinpointed to the fact that apple-gcc42 does not support SSE4 instructions. After carter suggested that it may be a problem with apple-gcc42, I rebuilt ghc with gcc48 and cgrun071 passed both the normal and llvm ways. It seems that carter's theory was right in that gcc 4.2 does not have support for SSE4 instructions. In fact, support for SSE4 was added in with the release of gcc43. http://gcc.gnu.org/gcc-4.3/changes.html It may be that SSE42 support isn't being detected properly by nativeGen. https://github.com/ghc/ghc/blob/master/compiler/nativeGen/X86/CodeGen.hs#L1… When reproducing this, #8148 may get in the way. carter's helpful fix is to simply symlink to `gcc-4.8` as `gcc` and, add it to your PATH, then build ghc as normal. {{{ $ mkdir ~/bin $ ln -s `which gcc-4.8` ~/bin/gcc $ export PATH=~/bin:$PATH $ # reload your shell and `gcc -v` should show 4.8 or whatever. }}} Should we switch to calling the "slower" popCount for this certain case? https://github.com/ghc/testsuite/blob/master/tests/codeGen/should_run/cgrun… {{{ slowPopcnt :: Word -> Word slowPopcnt x = count' (bitSize x) x 0 where count' 0 _ !acc = acc count' n x acc = count' (n-1) (x `shiftR` 1) (acc + if x .&. 1 == 1 then 1 else 0) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7684#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 1

[GHC] #8209: Race condition in setNumCapabilities
by GHC 05 Sep '13

05 Sep '13

#8209: Race condition in setNumCapabilities ----------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+------------------------------------- In HEAD, the following program sometimes deadlocks (about 1/10 of the time). {{{ import Control.Concurrent import Control.Monad import GHC.Conc main = do mainTid <- myThreadId labelThread mainTid "main" forM_ [0..0] $ \i -> forkIO $ do subTid <- myThreadId labelThread subTid $ "sub " ++ show i forM_ [0..100000000] $ \j -> putStrLn $ "sub " ++ show i ++ ": " ++ show j yield setNumCapabilities 2 }}} The problem seems to be that there is a race condition between setNumCapabilites and a Task returning from a foreign call. Specifically, a sequence of events like the following can happen: 1. Task 0 makes a foreign call. 2. Task 1 calls setNumCapabilities() 3. The call on task 0 returns; it reads task->cap from the memory. 4. Task 1 moves the Capabilities, invalidating all pointers to them. 5. Task 0 takes over the invalidated Capability. The attached patch adds an ASSERT to the RTS to demonstrate the problem (it does not fix the problem). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8209> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

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

05 Sep '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 DaniilFrumin): * cc: difrumin@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8004#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8230: GHCi 7.6.2 Crashes with GADT + DataKinds
by GHC 05 Sep '13

05 Sep '13

#8230: GHCi 7.6.2 Crashes with GADT + DataKinds ------------------------------------+------------------------------------- Reporter: jozefg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Keywords: GADT | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The following snippet caused GHCi to die {-# LANGUAGE GADTs, DataKinds #-} data A n where A :: A 0 with the following error message ghc: panic! (the 'impossible' happened) (GHC version 7.6.2 for x86_64-unknown-linux): lookupVers2 <<details unavailable>> Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8230> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8231: Haskell's Run Time System doesn't save electricity
by GHC 05 Sep '13

05 Sep '13

#8231: Haskell's Run Time System doesn't save electricity --------------------------+------------------------------------------------ Reporter: | Owner: UnixJunkie | Status: new Type: bug | Milestone: Priority: normal | Version: 7.4.1 Component: | Operating System: Linux Runtime System | Type of failure: None/Unknown Keywords: energy | Test Case: provided in the description saving | Blocking: Architecture: x86_64 | (amd64) | Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ Someone provided me with a sequential implementation of the fibonacci function. Out of curiosity, it was compiled with -threaded and we played with the -N option of the runtime. That same someone noticed some suspicious behavior. I notice the same and so report about it: all cores specified by $np are fully used while there is no change in the wallclock time spent by the program. The code: --- {{{ import Text.Printf fib :: Int -> Int fib 0 = 0 fib 1 = 1 fib n = fib (n - 1) + fib (n - 2) i = 44 main = printf "n=%d => %d\n" i (fib i) }}} --- The build: --- {{{ ghc -threaded -O2 sequential_fib.hs }}} --- The run (on an eight cores machine), shell is Bash: --- {{{ for np in `seq 1 8` ; do time ./sequential_fib +RTS -N$np ; done }}} --- The output: --- {{{ n=44 => 701408733 real 0m10.838s user 0m10.817s sys 0m0.000s n=44 => 701408733 real 0m10.762s user 0m12.009s sys 0m9.165s n=44 => 701408733 real 0m10.774s user 0m24.846s sys 0m6.800s n=44 => 701408733 real 0m10.769s user 0m33.654s sys 0m8.413s n=44 => 701408733 real 0m11.222s user 0m47.427s sys 0m7.336s n=44 => 701408733 real 0m11.217s user 0m57.872s sys 0m7.752s n=44 => 701408733 real 0m11.208s user 1m9.172s sys 0m7.112s n=44 => 701408733 real 0m11.204s user 1m18.909s sys 0m7.768s }}} --- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8231> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

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

05 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: cgrun071 | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by carter): someone who's got a ghc clang build working or using a different flavor of gcc newer than 4.2 on their mac should try and run this test case. (my theory could be completely wrong though) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7684#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0