May 2013 - ghc-tickets

[GHC] #7875: Unhelpful IncoherentInstances suggestion with FunctionalDependencies
by GHC 03 May '13

03 May '13

#7875: Unhelpful IncoherentInstances suggestion with FunctionalDependencies -----------------------------+---------------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- Consider the following program (simplified from http://hpaste.org/86928) {{{ {-# LANGUAGE FlexibleContexts , FlexibleInstances , FunctionalDependencies , MultiParamTypeClasses , KindSignatures , UndecidableInstances #-} class Het a b | a -> b where het :: m (f c) -> a -> m b class GHet (a :: * -> *) (b :: * -> *) | a -> b instance GHet (K a) (K [a]) instance Het a b => GHet (K a) (K b) data A a = A (A a) data K x a = K x instance Het (A a) (A [a]) where het = het1 het1 :: (GHet (K a) (K b)) => m (f c) -> a -> m b het1 = undefined }}} In HEAD, it gives rise to the following error: {{{ Overlapping instances for GHet (K (A a)) (K (A [a])) arising from a use of ‛het1’ Matching instances: instance Het a b => GHet (K a) (K b) -- Defined at Bug.hs:14:10 There exists a (perhaps superclass) match: (The choice depends on the instantiation of ‛a’ To pick the first instance above, use -XIncoherentInstances when compiling the other instance declarations) In the expression: het1 In an equation for ‛het’: het = het1 In the instance declaration for ‛Het (A a) (A [a])’ }}} It's already strange that it says multiple instances match, but it only lists one. Furthermore, enabling `-XIncoherentInstances`, as suggested, does not change the error message. #7150 and #7171 might be related. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7875> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #7872: :info does not display "forall" for a synonym
by GHC 03 May '13

03 May '13

#7872: :info does not display "forall" for a synonym ----------------------------------------------+----------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Incorrect warning at compile-time | Blockedby: Blocking: | Related: ----------------------------------------------+----------------------------- Define: {{{ data A = A (forall a. a) type B = forall a. a }}} and in ghci we see: {{{ Prelude> :i A data A = A (forall a. a) -- OK Prelude> :i B type B = a -- "forall" missing }}} This is a minor issue, but since "type B = a" is not valid Haskell I'm reporting it. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7872> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #5567: LLVM: Improve alias analysis / performance
by GHC 02 May '13

02 May '13

#5567: LLVM: Improve alias analysis / performance ---------------------------------+------------------------------------------ Reporter: dterei | Owner: dterei Type: task | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime performance bug Difficulty: | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by carter): ok, I'd be interested in spending some time on this ticket sometime in the next month or so. (or more realistically some part of the early summer, given how busy i am with work right now.) I may try and dig into some simpler related tasks first, as a warm up/ improve my familiarity with some of the relevant bits, such as the task I just proposed in http://hackage.haskell.org/trac/ghc/ticket/7883 -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5567#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7882: #line with empty filename leads to crash
by GHC 02 May '13

02 May '13

#7882: #line with empty filename leads to crash -------------------------------+-------------------------------------------- Reporter: Spivey | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.4.2 | Keywords: Os: Linux | Architecture: x86 Failure: Compile-time crash | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- It's trivial, but a directive #line 3 "" leads to a GHC crash with Prelude.head: empty list. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7882> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #149: missed CSE opportunity
by GHC 02 May '13

02 May '13

#149: missed CSE opportunity --------------------------------------+------------------------------------- Reporter: nobody | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 5.04.2 Resolution: None | Keywords: optimisations Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime performance bug | Difficulty: Moderate (less than a day) Testcase: T149 | Blockedby: Blocking: | Related: --------------------------------------+------------------------------------- Comment(by nfrisby): As of my fix for #7796, commit hash c7d80c6524390551b64e9c1d651e1a03ed3c7617, this test is passing again. I made no changes to CSE, though. So it needs to be further robustified. It's on my todo list, but not near the top. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/149#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1012: ghc panic with mutually recursive modules and template haskell
by GHC 02 May '13

02 May '13

#1012: ghc panic with mutually recursive modules and template haskell -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: lowest | Milestone: 7.6.2 Component: Template Haskell | Version: 6.8.2 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: TH_import_loop | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Changes (by ozgura): * cc: ozgurakgun@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1012#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7861: deferred type error with rankNTypes
by GHC 02 May '13

02 May '13

#7861: deferred type error with rankNTypes -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: Compile-time crash | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- {-# LANGUAGE RankNTypes #-} type A a = forall b. (a -> b) -> b doA :: (a -> b) -> A a -> b doA f l = l f -- f :: A a -> [a] -> [a] -- correct type f :: A a -> a -- wrong type f = doA (:) main = return () -- compiled with wrong type and -fdefer-type-errors -- gives ghc panic -- F.hs:10:5: Warning: -- Occurs check: cannot construct the infinite type: a0 = [a0] -> [a0] -- Expected type: A a -> a -- Actual type: A a0 -> a -- In the return type of a call of `doA' -- In the expression: doA (:) -- In an equation for `f': f = doA (:) -- -- F.hs:10:9: Warning: -- Couldn't match type `a' with `[a0] -> [a0]' -- `a' is a rigid type variable bound by -- the type signature for f :: A a -> a at F.hs:9:6 -- Expected type: a0 -> a -- Actual type: a0 -> [a0] -> [a0] -- In the first argument of `doA', namely `(:)' -- In the expression: doA (:) -- In an equation for `f': f = doA (:) -- ghc: panic! (the 'impossible' happened) -- (GHC version 7.6.2 for x86_64-unknown-linux): -- evTermCoercion -- error @ghc-prim:GHC.Prim.Any{(w) tc 31N} -- ghc-prim:GHC.Prim.*{(w) tc 34d} -- ghc-prim:GHC.Types.~{(w) tc 31Q} ([ghc-prim:GHC.Prim.Any{(w) tc 31N} -- ghc-prim:GHC.Prim.*{(w) tc 34d}] -- -> [ghc- prim:GHC.Prim.Any{(w) tc 31N} -- ghc- prim:GHC.Prim.*{(w) tc 34d}]) -- F.hs:10:5: -- Occurs check: cannot construct the infinite type: a0 = [a0] -> [a0] -- Expected type: A a -> a -- Actual type: A a0 -> a -- In the return type of a call of `doA' -- In the expression: doA (:) -- In an equation for `f': f = doA (:) -- (deferred type error) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7861> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #5902: Cannot tell from an exception handler whether the exception was asynchronous
by GHC 02 May '13

02 May '13

#5902: Cannot tell from an exception handler whether the exception was asynchronous ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by igloo): * priority: normal => high * milestone: 7.6.2 => 7.8.1 Comment: I think we've been running into problems with this when using the GHC API, with the same async exception being caught multiple times. Here's a small testcase of what I think is going on: {{{ import Control.Concurrent import Control.Exception import System.IO.Error import System.IO.Unsafe -- Our code: main = do tid <- myThreadId forkIO $ do threadDelay 1000 throwTo tid UserInterrupt print i `catch` \e -> putStrLn ("Got " ++ show (e :: AsyncException)) print i `catch` \e -> putStrLn ("Got " ++ show (e :: AsyncException)) -- A small simulation of the GHC API: f :: IO Integer f = (return $! sum [1..10000000]) `catchIOError` \_ -> return 3 i :: Integer i = unsafePerformIO f }}} Although we only throw `UserInterrupt` once, we catch it twice: {{{ $ ghc -O --make exc $ ./exc Got user interrupt Got user interrupt }}} Unfortunately, I can't see a workaround if you want to use async exceptions with the GHC API. Once you throw one, there's a chance that an `unsafePerformIO` thunk somewhere inside the GHC API will end up containing it as a synchronous exception, and then any call to the GHC API that uses that thunk will just throw that exception. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5902#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5567: LLVM: Improve alias analysis / performance
by GHC 02 May '13

02 May '13

#5567: LLVM: Improve alias analysis / performance ---------------------------------+------------------------------------------ Reporter: dterei | Owner: dterei Type: task | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime performance bug Difficulty: | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by dterei): No, no one has. Depends on how 'low' you want the fruit. I think we have a number of ideas that are worth trying. They are discussed on the wiki page and the tickets it links to: http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/LLVM/… Those ideas aren't too hard to implement and while we don't know, we do suspect they can be a big win in some situations. Finding someone with the time, knowledge and motivation to tackle them is hard though. It is a solid week or two of work probably to try them out properly. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5567#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7877: hSetBuffering002(ghci) and hSetBuffering004(ghci) fail on OS X
by GHC 01 May '13

01 May '13

#7877: hSetBuffering002(ghci) and hSetBuffering004(ghci) fail on OS X ----------------------------------------+----------------------------------- Reporter: nfrisby | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 7.6.3 | Keywords: Os: MacOS X | Architecture: Unknown/Multiple Failure: Incorrect result at runtime | Blockedby: Blocking: | Related: ----------------------------------------+----------------------------------- {{{ $ make TESTS="hSetBuffering002 hSetBuffering004" # ... snip ... Unexpected failures: ../../libraries/base/tests/IO hSetBuffering002 [bad exit code] (ghci) ../../libraries/base/tests/IO hSetBuffering004 [bad stdout or stderr] (ghci) }}} For 002, there's a stderror message: `<stdin>: hGetLine: illegal operation (handle is closed)` For 004, it seems like ghci is trying to parse the part of the .genscript file that the program is supposed to use as stdin. I'm on OS X 10.7.5 {{{ ghc : ade1ae97ed52c493ec415c1601dace39b64071dd testsuite : 743cab5865ae0b9820dadc33a692511e0e467b9b base : b3387abfbc94b69e977c232386acad4dde7597e8 }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7877> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0