June 2013 - ghc-tickets

[GHC] #7974: Panic on a context with additional variable
by GHC 11 Jun '13

11 Jun '13

#7974: Panic on a context with additional variable -------------------------------+-------------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Compile-time crash | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- File: {{{ {-# LANGUAGE GADTs #-} data X a where N :: (a ~ b) => X a k :: X a -> X b k N = N }}} Result with HEAD: {{{ X.hs:6:7: Couldn't match type ‛b’ with ‛b1’ ‛b’ is untouchable inside the constraints (a ~ b) bound by a pattern with constructor N :: forall a. a ~ b => X a, in an equation for ‛k’ at X.hs:6:3ghc: panic! (the 'impossible' happened) (GHC version 7.7.20130608 for x86_64-unknown-linux): No skolem info: b{tv ae1} [sk] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I got it by attempting to compile [http://hackage.haskell.org/package /data-category data-category] with HEAD. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7974> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #7272: PolyKinds and mutually recursive modules
by GHC 11 Jun '13

11 Jun '13

#7272: PolyKinds and mutually recursive modules -------------------------------+-------------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: closed Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.6.1 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: polykinds/T7272 | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Comment(by simonpj@…): commit 0239d783bcda0fb0e45df7b40159d6ad29bfab63 {{{ Author: Simon Peyton Jones <simonpj(a)microsoft.com> Date: Mon Jun 10 11:57:06 2013 +0100 Fix egregious typo in cmpTypeX Reported in Trac #7272. "tv1" should be "tv2"! However, things weren't as simple as they sound, because treating (x:Open) as different from (x:*) gave rise to new failures; see Note [Comparison with OpenTypeKind] in Type. My hacky solution is to treat OpenKind as equal to * and #, at least in Core etc. Hence the faff in Type.cmpTc. I do not like this. But it seems like another messy consequence of including sub-kinding. Sigh. compiler/typecheck/TcSimplify.lhs | 6 ++---- compiler/types/Kind.lhs | 14 +++++++++----- compiler/types/Type.lhs | 28 ++++++++++++++++++++++++---- 3 files changed, 35 insertions(+), 13 deletions(-) }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7272#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7973: Simplifier introduces unbound kind variables (caught by -dcore-lint)
by GHC 10 Jun '13

10 Jun '13

#7973: Simplifier introduces unbound kind variables (caught by -dcore-lint) -----------------------------+---------------------------------------------- Reporter: diatchki | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- I encountered a problem in GHC (happens with 7.6.3 and HEAD), where compiling with optimizations (-O2) results in invalid core (unbound kind variable). I managed to reduce my example to the following: {{{ {-# LANGUAGE DataKinds, PolyKinds, KindSignatures #-} {-# LANGUAGE ExistentialQuantification, UndecidableInstances, TypeFamilies #-} module Test where -- Kind-level proxies. data {-kind-} K (a :: *) = KP -- A type with 1 kind-polymorphic type argument. data T (n :: k) -- A type with 1 kind argument. data F (kp :: K k) -- A class with 1 kind argument. class (kp ~ KP) => C (kp :: K k) where f :: T (a :: k) -> F kp -- A type with 1 kind argument. -- Contains an existentially quantified type-variable of this kind. data SomeT (kp :: K k) = forall (n :: k). Mk (T n) -- Show `SomeT` by converting it to `F`, using `C`. instance (C kp, Show (F kp)) => Show (SomeT kp) where show (Mk x) = show (f x) }}} I compiled it with these flags: {{{ ghc-stage2 -c -O2 -dcore-lint test.hs }}} Part of the core-lint complaint is: {{{ *** Core Lint errors : in result of Simplifier *** <no location info>: Warning: In the expression: ww_snF @ n_akd (x_aie `cast` (Sym (Nth:0 ((forall (a_ai7 :: k_aj7). <Test.T k_ajF a_ai7> -> Test.F <k_ajF> cobox_dkK)@n_akd)) :: Test.T k_ajF n_akd ~# Test.T k_ajF n_akd)) @ (k_aj7 :: BOX) is out of scope }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7973> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #7964: GADTs in Haskell98 style
by GHC 10 Jun '13

10 Jun '13

#7964: GADTs in Haskell98 style -----------------------------+---------------------------------------------- Reporter: wvv | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler (Type checker) Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Other | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- it would be nice if it is possible to write GADTs in Haskell98 style, like this: {{{ data Expr a = I Int :: Expr Int | B Bool :: Expr Bool | Add (Expr Int) (Expr Int) :: Expr Int | Mul (Expr Int) (Expr Int) :: Expr Int | Eq (Expr Int) (Expr Int) :: Expr Bool | Magic (Expr a) (Expr a) }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7964> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #7860: Add more bit fiddling functions to 'integer-gmp'
by GHC 10 Jun '13

10 Jun '13

#7860: Add more bit fiddling functions to 'integer-gmp' -----------------------------+---------------------------------------------- Reporter: lebedev | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 7.6.3 | Keywords: gmp Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: 3489 -----------------------------+---------------------------------------------- Current implementation of 'integer-gmp' uses only a subset of "bit fiddling" features, [http://gmplib.org/manual/Integer-Logic-and-Bit- Fiddling.html provided] by the GMP library. The ones missing are: {{{ * mpz_popcount * mpz_setbit * mpz_clrbit }}} I think it would be nice to add these functions in addition to 'testBitInteger'. Would you accept a patch? -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7860> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 10

[GHC] #7971: doesDirectoryExist description differs from its behavior
by GHC 09 Jun '13

09 Jun '13

#7971: doesDirectoryExist description differs from its behavior ----------------------------------------+----------------------------------- Reporter: dsf | Owner: Type: bug | Status: new Priority: normal | Component: libraries/directory Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Incorrect result at runtime | Blockedby: Blocking: | Related: ----------------------------------------+----------------------------------- The documentation for doesDirectoryExist should read: The operation 'doesDirectoryExist' returns 'True' if the argument file exists and is either a directory '''or a symbolic link to a directory''', and 'False' otherwise. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7971> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

Re: [GHC] #5687: Friendly Interface for auto-completion of GHCi
by GHC 09 Jun '13

09 Jun '13

#5687: Friendly Interface for auto-completion of GHCi -------------------------------+-------------------------------------------- Reporter: linsumang | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.6.2 Component: GHCi | Version: 7.2.1 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Changes (by igloo): * status: patch => new Comment: hvr says he knows of no standard. He'll add some docs for the user guide, and is also working on an implementation of the emacs side. hvr: I wonder if it would be better to use your own String-showing function rather than using Show, so as to make it possible to correctly use simpler parsing on the emacs side. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5687#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7718: ios patch no 8: adjustor pools
by GHC 09 Jun '13

09 Jun '13

#7718: ios patch no 8: adjustor pools ------------------------------+--------------------------------------------- Reporter: StephenBlackheath | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Other | Architecture: arm Failure: None/Unknown | Blockedby: Blocking: | Related: ------------------------------+--------------------------------------------- "Adjustor" is the term used for a C function pointer that allows C code to call back to Haskell. Normally these are generated at runtime. However, the iOS kernel doesn't allow self-modifying code. So, on iOS we use a pool of precompiled adjustors of a fixed size, and this patch is the implementation for that. It consists of three parts: 1. A POOLSIZE pragma, that is used like this: foreign import ccall safe "wrapper" {-# POOLSIZE 100 #-} mkDelegate :: IO () -> IO (FunPtr (IO ())) This patch makes this pragma work on all platforms, but it'll have no effect on platforms other than iOS. I am not sure what the procedure is for additions of pragmas. Do pragmas require {-# LANGUAGE xx #-} ? Anyway, please review whether the approach taken here is acceptable. 2. The Haskell code in the compiler to generate the stubs for the pooled adjustors. 3. The runtime system's implementation of pooled adjustors in C. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7718> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 24

[GHC] #7972: Simplifier introduces unbound kind variables (caught by -dcore-lint)
by GHC 09 Jun '13

09 Jun '13

#7972: Simplifier introduces unbound kind variables (caught by -dcore-lint) -----------------------------+---------------------------------------------- Reporter: diatchki | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- I encountered a problem in GHC (happens with 7.6.3 and HEAD), where compiling with optimizations (-O2) results in invalid core (unbound kind variable). I managed to reduce my example to the following: {{{ {-# LANGUAGE DataKinds, PolyKinds, KindSignatures #-} {-# LANGUAGE ExistentialQuantification, UndecidableInstances, TypeFamilies #-} module Test where -- Kind-level proxies. data {-kind-} K (a :: *) = KP -- A type with 1 kind-polymorphic type argument. data T (n :: k) -- A type with 1 kind argument. data F (kp :: K k) -- A class with 1 kind argument. class (kp ~ KP) => C (kp :: K k) where f :: T (a :: k) -> F kp -- A type with 1 kind argument. -- Contains an existentially quantified type-variable of this kind. data SomeT (kp :: K k) = forall (n :: k). Mk (T n) -- Show `SomeT` by converting it to `F`, using `C`. instance (C kp, Show (F kp)) => Show (SomeT kp) where show (Mk x) = show (f x) }}} I compiled it with these flags: {{{ ghc-stage2 -c -O2 -dcore-lint test.hs }}} Part of the cire-lint complaint is: {{{ *** Core Lint errors : in result of Simplifier *** <no location info>: Warning: In the expression: ww_snF @ n_akd (x_aie `cast` (Sym (Nth:0 ((forall (a_ai7 :: k_aj7). <Test.T k_ajF a_ai7> -> Test.F <k_ajF> cobox_dkK)@n_akd)) :: Test.T k_ajF n_akd ~# Test.T k_ajF n_akd)) @ (k_aj7 :: BOX) is out of scope }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7972> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #7850: Strangely high memory usage on optimized Ackermann function
by GHC 09 Jun '13

09 Jun '13

#7850: Strangely high memory usage on optimized Ackermann function ------------------------------------+--------------------------------------- Reporter: dolio | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: Runtime performance bug | Blockedby: Blocking: | Related: ------------------------------------+--------------------------------------- Greetings. The following post on stack overflow demonstrates some strange behavior in, at least, recent GHC versions (7.4.2 on): [http://stackoverflow.com/questions/16115815/ackermann-very-inefficient- with-haskell-ghc] The program in question is simple: {{{ main = print $ ack 4 1 ack :: Int -> Int -> Int ack 0 !n = n+1 ack m 0 = ack (m-1) 1 ack m n = ack (m-1) $ ack m (n-1) }}} Here are the properties I've been able to deduce so far: 1) When compiled without optimizations, the program uses almost no memory, but of course takes a while. 2) When compiled with optimizations (-O and above), the program eats memory at a staggering rate. It easily freezes my machine in a matter of seconds. 3) -ddump-simpl reveals that the loop is completely unboxed, operating only on Int#. -ddump-prep also shows no lets where allocation would presumably happen. 4) Setting a maximum heap size typically seems to have no effect. When I set it to the minimum heap size with -M4096, even the optimized program seems to run in constant space most of the time. However, using something like -M1000000 seems to result in the outrageous memory usage, and the RTS never catches that far more than 1 megabyte of memory is being used. I had to convince myself that the flag actually does something with another test program. 5) The standard bounded stack also does nothing. So, we seem to have a program that is allocating vast amounts of (ostensibly) non-heap, non-stack memory; but only when optimized. I believe I once set the maximum heap to 40960B, and killed the program before it killed my machine. On exiting, I got a heap overflow error. So, my initial stab would be that the completely unboxed loop somehow ''is'' allocating in the heap, but somehow not in a way that ever allows the garbage collector or heap overflow check to run (similar to how a non- allocating loop can block any thread preemption). That's a wild guess, though. I'm unable to easily investigate the behavior on older GHC versions, unfortunately. So I'm unsure how far back this behavior goes. If I've missed something obvious, I apologize, but this seems like very odd behavior to me. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7850> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 30