December 2014 - ghc-tickets

[GHC] #9882: Kind mismatch with singleton [Nat]
by GHC 15 Dec '14

15 Dec '14

#9882: Kind mismatch with singleton [Nat] -------------------------------------+------------------------------------- Reporter: Roel van Dijk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: GHC Difficulty: Unknown | rejects valid program Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE TypeOperators #-} import GHC.TypeLits ( Nat ) data Foo (n :: [Nat]) = Foo x :: Foo ('(:) 42 '[]) x = Foo y :: Foo (42 ': '[]) y = Foo z :: Foo [42] z = Foo }}} {{{ Expected kind ‘*’, but ‘42’ has kind ‘Nat’ In the type signature for ‘z’: z :: Foo [42] }}} I would expected z to be identical to both x and y. The error occurs in both GHCi and GHC. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9882> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9857: GHC 7.9 panics (simplifier ticks exhausted) on `half-0.2`
by GHC 15 Dec '14

15 Dec '14

#9857: GHC 7.9 panics (simplifier ticks exhausted) on `half-0.2` -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Compile- Blocked By: | time crash Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Compiling hackage:half-0.2 results in a GHC Panic: {{{ $ ghc --version && ghc --print-project-git-commit-id The Glorious Glasgow Haskell Compilation System, version 7.9.20141202 bf2d75417b5be7e8a79a26ee57a81e00682dabd4 $ cabal get half-0.2 && cd half-0.2/src/Numeric/ Unpacking to half-0.2/ $ ghc -Wall -O -fforce-recomp -c Half.hs ghc: panic! (the 'impossible' happened) (GHC version 7.9.20141202 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone lvl_s5yo To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 125160 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9857> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9353: prefetch primops are not currently useful
by GHC 15 Dec '14

15 Dec '14

#9353: prefetch primops are not currently useful -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I wanted to use GHC's new prefetch primops to speed up a cover tree data structure I've been working on. The current implementation, however, is insufficient. The pure primops do not work at all. I propose an alternative using a seq-like syntax. ------- **The problem** Consider the function: {{{ prefetchAddr3# :: Addr# -> Int# -> Addr# }}} It is used like: {{{ -- addr# :: Addr# let prefetchAddr# = prefetchAddr3# addr# 0 ... do some stuff not involving addr# doRealWork prefetchAddr# }}} The problem is that we want the prefetch operation to get inserted at the let statement before "do some stuff...", but it doesn't get inserted there. It gets inserted directly before the call to doRealWork. This doesn't give the prefetch enough time to actually put the memory in cache, and so we still get a cache miss. I made several attempts to get around this, but they all failed due to dead code elimination. The `prefetchMutableByteArray#` functions solve this problem by incorporating an explicit state parameter. This forces the compiler to insert the prefetch operation at the location it is actually called in the code. This function, however, can only be used within the ST and IO monads, so it is of limited use. ------ ** The solution** The solution is to restructure the pure primops to use a seq-like format. For example, the prefetchAddr3# function above would become: {{{ prefetchAddr3# :: Addr# -> a -> a }}} Then we would call the function like: {{{ prefetchAddr3# addr# someOtherOp ... do some stuff not involving addr# doRealWork prefetchAddr# }}} This would correctly insert the prefetch instruction at the location it appears in the haskell code. In particular, the prefetch will occur whenever the second parameter is evaluated. This format has the advantage that it can work in non-monadic code. In my cover tree structure, I've implemented searching the tree as a `fold` operation. Every time the fold branches, only one of the branches is guaranteed to be in the cache. So I get a cache miss when I go down the other branches. I want to use the prefetch primop to prefetch the next branch the fold will go down. The fold function is pure, and I don't want to have to wedge it into the ST monad just for prefetching. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9353> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #9132: takeWhile&C. still not fusible
by GHC 15 Dec '14

15 Dec '14

#9132: takeWhile&C. still not fusible -------------------------------------+------------------------------------- Reporter: Blaisorblade | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Keywords: fusion | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Runtime Difficulty: Moderate (less | performance bug than a day) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- takeWhile is not still fusible, 2 1/2 years after this report: http://www.haskell.org/pipermail/glasgow-haskell- users/2011-December/021299.html The discussion suggests making takeWhile a good producer/consumer with foldr/build fusion: takeWhile' :: (a -> Bool) -> [a] -> [a] takeWhile' p xs = build $ \c n -> foldr (takeWhileF p c n) n xs {-# INLINE takeWhile' #-} takeWhileF p c n x xs = if p x then x `c` xs else n Furthermore, the discussion suggests having rewrite rules to go to this version and then rewrite back (if fusion fails). The report also mentions concatMap (which is a separate known problem). It also mentions drop and dropWhile, but I don't see when they perform allocations, so I think that's an erroneous request. I experienced the bug on GHC 7.6.3, but it seems still there in base-4.7.0.0, judging from the source: http://hackage.haskell.org/package/base-4.7.0.0/docs/src/GHC- List.html#takeWhile -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9132> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 26

[GHC] #9169: Add mkWeakTMVar to Control.Concurrent.STM.TMVar
by GHC 15 Dec '14

15 Dec '14

#9169: Add mkWeakTMVar to Control.Concurrent.STM.TMVar -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 7.8.2 Keywords: stm | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- I just needed a Weak pointer to a TMVar: {{{ -- | Make a 'Weak' pointer to a 'TMVar', using the second argument as -- a finalizer to run when 'TMVar' is garbage-collected. mkWeakTMVar :: TMVar a -> IO () -> IO (Weak (TMVar a)) mkWeakTMVar tmv@(TMVar (TVar t#)) f = IO $ \s -> case mkWeak# t# tmv f s of (# s1, w #) -> (# s1, Weak w #) }}} It might make sense to add a similar function for TSem as well. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9169> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9393: execvpe should handle ENOTDIR
by GHC 15 Dec '14

15 Dec '14

#9393: execvpe should handle ENOTDIR -------------------------------------+------------------------------------- Reporter: iquiw | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/unix | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- If PATH environment variable contains non directory component, execvpe fails by ENOTDIR. For example, if "/tmp/foo" is a regular file, the following program fails with PATH contains "/tmp/foo". {{{ module Main where import System.Environment import System.Posix.Process main :: IO () main = do env <- getEnvironment executeFile "echo" True [] (Just env) return () }}} {{{ $ PATH=/tmp/foo:$PATH runghc a.hs a.hs: echo: executeFile: inappropriate type (Not a directory) }}} See for example, https://github.com/haskell/cabal/issues/1723 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9393> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #4896: Deriving Data does not work for attached code
by GHC 15 Dec '14

15 Dec '14

#4896: Deriving Data does not work for attached code -------------------------------------+------------------------------------- Reporter: mitar | Owner: Type: bug | Status: closed Priority: low | Milestone: 7.10.1 Component: Compiler | Version: 7.1 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | deriving/should_compile/T4896 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: infoneeded => closed * resolution: => fixed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4896#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4428: Local functions lose their unfoldings
by GHC 15 Dec '14

15 Dec '14

#4428: Local functions lose their unfoldings -------------------------------------+------------------------------------- Reporter: rl | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: Compiler | Version: 7.1 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: infoneeded => closed * resolution: => fixed * milestone: 7.10.1 => -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4428#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8778: Typeable TypeNats
by GHC 15 Dec '14

15 Dec '14

#8778: Typeable TypeNats -------------------------------------------+------------------------------- Reporter: dmcclean | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler (Type checker) | Version: 7.8.1-rc1 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: 4385 | Test Case: | Blocking: -------------------------------------------+------------------------------- It would be useful (the case I have at hand is for some scenarios involving checking of physical dimensions) to be able to combine the Data.Dynamic story with the GHC.TypeLits story. A Typeable instance for every Nat is the sticking point. (I do not know if this is even theoretically possible.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8778> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 28

Re: [GHC] #7143: ghc-7.6.0.20120810-x86_64-windows.exe -> ghc can't figure out LLVM version
by GHC 15 Dec '14

15 Dec '14

#7143: ghc-7.6.0.20120810-x86_64-windows.exe -> ghc can't figure out LLVM version -------------------------------------+------------------------------------- Reporter: cetinsert | Owner: Fanael Type: bug | Status: closed Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.6.1-rc1 (LLVM) | Keywords: llvm Resolution: fixed | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: Incorrect | Blocked By: warning at compile-time | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D190 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed * milestone: 7.10.1 => 7.8.4 Comment: Merged to 7.8.4. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7143#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0