September 2013 - ghc-tickets

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): > is the test using the fallback version (written in C?) or the slowpopcount one in the test itself? The test is comparing the `hs_popcnt*` C implementation in ghc-prim with the `slowPopcnt` in the test itself. I don't see why `slowPopcnt` would segfault so probably we're generating the wrong call sequence to `hs_popcnt*` in the native code generator (I assume llvm isn't being used). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7684#comment:23> 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 carter): ok, so I think we've narrowed it down to "the code generator version is correct, our fallback isnt"? so @leroux's patch on the native code generator isn't relevant... its that the fall back is wrong? is the test using the fallback version (written in C?) or the slowpopcount one in the test itself? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7684#comment:22> 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): 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