June 2015 - ghc-tickets

[GHC] #10491: Simplifier explosion with Accelerate
by GHC 28 Jun '15

28 Jun '15

#10491: Simplifier explosion with Accelerate -------------------------------------+------------------------------------- Reporter: robertce | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- In [https://github.com/AccelerateHS/accelerate Accelerate] we are encountering problems with the simplifier exploding the number of terms, which consequently cause huge compile times. This has only happened since the release of 7.10.1 and it appears to still be happening in the ghc-7.10 branch. In the attached Slice.hs you can see what is about the worst case example. Trying to compile this with `-O2` yields {{{ [1 of 1] Compiling Data.Array.Accelerate.CUDA.Array.Slice ( Slice.hs, Slice.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.1.20150602 for x86_64-apple-darwin): Simplifier ticks exhausted When trying UnfoldingDone $j_s1FRp 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: 1668604 }}} Bumping the tick factor to 150 stops this from happening, but at that point the simplifier blows up. See output.txt for the output of `ghc -v`. After half an hour we end up with ~4 million terms. At this point ghc takes up about 9GB of memory and I have to kill it. In order to reproduce this, you will need the `accelerate` package and all its various dependencies. The one on hackage works fine. I will try to come up with a test case that is not so heavy on dependencies, but I wanted to ensure this was raised before 7.10.2 is released. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10491> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 48

Re: [GHC] #7478: setSessionDynFlags does not always work
by GHC 27 Jun '15

27 Jun '15

#7478: setSessionDynFlags does not always work -------------------------------------+------------------------------------- Reporter: edsko | Owner: bherzog Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: ghc- Related Tickets: | api/T7478 | Blocking: | Differential Revisions: Phab:D1017 -------------------------------------+------------------------------------- Changes (by bherzog): * differential: => Phab:D1017 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7478#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7478: setSessionDynFlags does not always work
by GHC 27 Jun '15

27 Jun '15

#7478: setSessionDynFlags does not always work -------------------------------------+------------------------------------- Reporter: edsko | Owner: bherzog Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: ghc- Related Tickets: | api/T7478 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bherzog): * owner: => bherzog -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7478#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7662: Improve GC of mutable objects
by GHC 27 Jun '15

27 Jun '15

#7662: Improve GC of mutable objects -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by lelf): * cc: lelf (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7662#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10545: Deadlock in the threaded RTS
by GHC 26 Jun '15

26 Jun '15

#10545: Deadlock in the threaded RTS -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Runtime | Version: 7.10.1 System | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The following program deadlocks with high probability: {{{ -- ghc -rtsopts -threaded -debug performGC.hs -- ./performGC 1000 +RTS -qg -N2 -- -qg turns off parallel GC, needed to trigger the bug -- -N2 or greater is needed module Main (main) where import System.Environment import Control.Concurrent import Control.Exception import Control.Monad import System.Random import System.Mem import qualified Data.Set as Set main = do [n] <- getArgs forkIO $ doSomeWork forM [1..read n] $ \n -> do print n; threadDelay 1000; performMinorGC doSomeWork :: IO () doSomeWork = forever $ do ns <- replicateM 10000 randomIO :: IO [Int] ms <- replicateM 1000 randomIO let set = Set.fromList ns elems = filter (`Set.member` set) ms evaluate $ sum elems }}} There are a few ways that this bug can be triggered: * At shutdown, when there are other threads still running. This is how we first encountered it. * Using `performGC`, as above. I think it's necessary to call it from a bound thread (e.g. the main thread) to get bad things to happen. * I think `forkProcess` might also trigger it, but I haven't observed it. I'm working on a fix. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10545> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10521: Wrong results in strict Word8 storage on x64
by GHC 26 Jun '15

26 Jun '15

#10521: Wrong results in strict Word8 storage on x64 -------------------------------------+------------------------------------- Reporter: | Owner: VincentBerthoux2 | Status: new Type: bug | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect result Architecture: x86_64 | at runtime (amd64) | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The following snippet produce two different results in function of the compiler platform used: {{{#!hs import Data.Word( Word8 ) -- removing the bang patterns on V definition makes -- the problem go away. data V = V !Word8 !Word8 deriving Show toV :: Float -> V toV d = V (truncate $ d * coeff) (fromIntegral $ exponent d + 128) where coeff = significand d * 255.9999 / d main :: IO () main = print $ map toV [ 3.56158e-2, 0.7415215, 0.5383201, 0.1289829, 0.45520145 ] }}} On GHC 7.10.1 x86 (under windows and Linux) the output is: {{{ [V 145 124,V 189 128,V 137 128,V 132 126,V 233 127] }}} On GHC 7.10.1 x64 (under windows and Linux), the (invalid) output is: {{{ [V 0 124,V 0 128,V 0 128,V 0 126,V 0 127] }}} The bug appear at the following optimisation levels: - {{{-O1}}} - {{{-O2}}} - {{{-O3}}} the results are the same at {{{-O0}}} This bug was discovered in a bug report in the library JuicyPixels [https://github.com/Twinside/Juicy.Pixels/issues/98] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10521> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

Re: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so.
by GHC 26 Jun '15

26 Jun '15

#7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. -------------------------------------+------------------------------------- Reporter: jpbernardy | Owner: osa1 Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving, Operating System: Unknown/Multiple | newcomer Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D978 -------------------------------------+------------------------------------- Comment (by rwbarton): I created a separate ticket #10577 for the issue of how to define the derived instances of empty types. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7401#comment:39> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10385: Annotation restriction is not respected while generating Annotation via TH
by GHC 26 Jun '15

26 Jun '15

#10385: Annotation restriction is not respected while generating Annotation via TH -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Magesh B [https://mail.haskell.org/pipermail/ghc-devs/2015-May/008910.html writes]: As per user guide one of the restriction in annotating value is ''the binder being annotated must be declared in the current module''. But when I use TH to generate the annotation above restriction is not respected. Below is the minimal test case to reproduce the issue {{{ ---- Ann.hs {-# LANGUAGE TemplateHaskell #-} module Ann where import Language.Haskell.TH -- {-# Ann id "Orphan Ann for id" #-} -- Rightly produces error "Not in scope: ‘id’" $(pragAnnD (ValueAnnotation 'id) [|"Orphan Ann for id"|] >>= return . return) -- Ideally this should have produced same error as above ---- End of Ann.hs ---- Main.hs {-# LANGUAGE TemplateHaskell #-} module Main where import Ann () import Language.Haskell.TH ann :: [String] ann = $((reifyAnnotations (AnnLookupName 'id) :: Q [String]) >>= (\anns -> [|anns|])) --err = 'a' && True -- Uncomment to introduce compile error main :: IO () main = print ann ---- End of Main.hs }}} Also there is another bug in reifying the Orphan Annotations. In the above example `Main.hs` depends on `Ann.hs` which defines Annotation for `id` When `Main.hs` compiles fine in the first go, its is able to retrieve the annotation for `id` Instead, if `Ann.hs` compiled successfully and `Main.hs` failed to compile and when you later fix the `Main.hs` error, it is not able to retrieve that annotation without recompiling `Ann.hs` -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10385> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so.
by GHC 26 Jun '15

26 Jun '15

#7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. -------------------------------------+------------------------------------- Reporter: jpbernardy | Owner: osa1 Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving, Operating System: Unknown/Multiple | newcomer Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D978 -------------------------------------+------------------------------------- Comment (by osa1): One thing to note is we need to use current implementation at least for methods like `mempty :: Monoid a => a`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7401#comment:38> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so.
by GHC 26 Jun '15

26 Jun '15

#7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. -------------------------------------+------------------------------------- Reporter: jpbernardy | Owner: osa1 Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving, Operating System: Unknown/Multiple | newcomer Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D978 -------------------------------------+------------------------------------- Comment (by osa1): > but I assume the same code is used to actually generate the instances in those two cases, right? Right, the whole point is to make those work the same. Either way(e.g. empty case or error) works for me. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7401#comment:37> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0