January 2017 - ghc-tickets

[GHC] #10746: No non-exhaustive pattern match warning given for empty case analysis
by GHC 02 Feb '17

02 Feb '17

#10746: No non-exhaustive pattern match warning given for empty case analysis -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- I would expect GHC to warn of a non-exhaustive pattern match at compile- time when faced with this, {{{#!hs {-# LANGUAGE EmptyCase #-} module Test where test :: Bool -> Int test a = case a of }}} Yet it happily accepts this without complaint. If one attempts to evaluate, e.g., `test True` the expected "Non-exhaustive patterns in case" error is thrown at runtime. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10746> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 29

[GHC] #12988: Join points
by GHC 02 Feb '17

02 Feb '17

#12988: Join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): D2853 | Wiki Page: SequentCore -------------------------------------+------------------------------------- Master ticket for the `wip/join-points` branch. For details, see SequentCore. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12988> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11836: Hello World Bug - silent stdout errors
by GHC 02 Feb '17

02 Feb '17

#11836: Hello World Bug - silent stdout errors -------------------------------------+------------------------------------- Reporter: bit | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- == Background This entertaining talk explains the issue: https://www.irill.org/events /ghm-gnu-hackers-meeting/videos/jim-meyering-goodbye-world-the-perils-of- relying-on-output-streams-in-c == hello.hs {{{#!hs main = putStrLn "Hello world" }}} == Run it {{{ $ runhaskell hello.hs > /dev/full ; echo $? hello.hs: <stdout>: hPutChar: resource exhausted (No space left on device) 1 }}} That looks good! We tried to save the output to a file but the disk was full, so we got an error message, and a process exit code indicating failure. == Run it compiled {{{ $ ghc hello.hs $ ./hello > /dev/full ; echo $? 0 }}} Not good! The error was silently ignored, and additionally the process lied when it reported a successful exit status. Why did it behave differently when compiled? When `runhaskell` is used, the buffering of stdout is `NoBuffering` therefore the putStrLn call fails. But when compiled, stdout is in `LineBuffering` mode and therefore the putStrLn call succeeds. The fix: == hello2.hs {{{#!hs import System.IO main = do putStrLn "Hello world" hClose stdout }}} == Run it compiled {{{ $ ghc hello2.hs $ ./hello2 > /dev/full ; echo $? hello: <stdout>: hClose: resource exhausted (No space left on device) 1 }}} Looks good! But there's a catch: {{{ $ runhaskell hello2.hs ; echo $? Hello world ghc: <stdout>: hFlush: illegal operation (handle is closed) 1 }}} Now our program fails to run correctly with `runhaskell` :( It seems that `runhaskell` is running some hidden code after main finished. It is not clear to me how to write a correct "Hello World" that works both compiled and with `runhaskell`. == Summary One of the greatest things about Haskell is that short, clear and concise programs can also be correct. It is my opinion that the original "hello.hs" should Just Work™. Haskell programmers shouldn't have to know that they need to always close stdout before exiting. Especially since it's not even clear how to do it properly... Thank you! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11836> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13188: COMPLETE pragma causes compilation to hang forever under certain scenarios
by GHC 01 Feb '17

01 Feb '17

#13188: COMPLETE pragma causes compilation to hang forever under certain scenarios -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is a really bizarre one. If you have the following program: {{{#!hs {-# LANGUAGE PatternSynonyms #-} {-# LANGUAGE ViewPatterns #-} module Main where class LL f where go :: f a -> () instance LL [] where go _ = () pattern GoLL :: LL f => f a pattern GoLL <- (go -> ()) {-# COMPLETE GoLL :: [] #-} goLLEx :: [a] -> Int goLLEx GoLL = 5 main :: IO () main = return () }}} And you compile it with GHC HEAD in just the right way, GHC hangs forever! {{{ $ ~/Software/ghc3/inplace/bin/ghc-stage2 -no-link Bug.hs [1 of 1] Compiling Main ( Bug.hs, Bug.o ) $ ~/Software/ghc3/inplace/bin/ghc-stage2 Bug.hs # Hangs forever here }}} That `-no-link` part is crucial, since if you compile it straight from a source file, it works. Also worth noting: * I can reproduce this in GHC HEAD, but not in GHC 8.0.2. * The `COMPLETE` pragma is critical for triggering this bug. If you comment it out, then the issue disappears. Note that `cabal-install` installs executables using this `-no-link` strategy, so this bug effectively prevents me from using `cabal-install` with code that involves `COMPLETE` pragmas. Marking as high priority. I have //no// idea where to start looking for this one. Matthew, do you have any idea what might be happening here? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13188> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11568: Regression in nofib/shootout/k-nucleotide
by GHC 01 Feb '17

01 Feb '17

#11568: Regression in nofib/shootout/k-nucleotide -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Fixing the `sizeExpr` bug in #11564 caused a regression in `nofib/shootout/k-nucleotide`. We don't know yet exactly which function was affected. See Phab:D1900 for details and some `-ddump-simpl` and `-ticky` dumps. We should investigate this before merging Phab:D1900 into a release. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11568> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #12817: Degraded performance with constraint synonyms
by GHC 01 Feb '17

01 Feb '17

#12817: Degraded performance with constraint synonyms -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The attached bug demonstrates how using constraint synonyms can negatively impact performance. I have two functions which are identical, except that one uses a constraint synonym: {{{ type CElt r = (Num r, Eq r) fooSlow :: (CElt r) => Bar r -> Bar r {-# INLINABLE fooSlow #-} fooSlow (C1 u) = either (fromEitherBar . eitherFoo) (fromEitherBar . eitherFoo) u fooSlow (C2 c) = C2 $ fooSlow c fooFast :: (Num r, Eq r) => Bar r -> Bar r {-# INLINABLE fooFast #-} fooFast (C1 u) = either (fromEitherBar . eitherFoo) (fromEitherBar . eitherFoo) u fooFast (C2 c) = C2 $ fooFast c }}} Using criterion, `fooSlow` is about 3x slower than `fooFast`. Main.hs needs `criterion` and `deepseq`, but the problem should be evident just from inspecting the core of Bar.hs, which only relies on `base`. Code was compiled with GHC-8.0.1 with `-O2`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12817> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13056: Deriving Foldable causes GHC to take a long time (GHC 8.0 ONLY)
by GHC 01 Feb '17

01 Feb '17

#13056: Deriving Foldable causes GHC to take a long time (GHC 8.0 ONLY) -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This file never finishes compiling on GHC 8.0.1, and GHC 8.0.2 (dated 20161213): {{{ {-# LANGUAGE DeriveDataTypeable #-} {-# LANGUAGE DeriveGeneric #-} {-# LANGUAGE DeriveFunctor #-} {-# LANGUAGE DeriveFoldable #-} module Bug where import Data.Typeable import GHC.Generics import Data.Data data Condition v = Condition deriving (Functor, Foldable) data CondTree v c a = CondNode { condTreeData :: a , condTreeConstraints :: c , condTreeComponents :: [CondBranch v c a] } deriving (Functor, Foldable) data CondBranch v c a = CondBranch { condBranchCondition :: Condition v , condBranchIfTrue :: CondTree v c a , condBranchIfFalse :: Maybe (CondTree v c a) } deriving (Functor, Foldable) }}} The problem seems to be fixed in HEAD but I haven't looked for the commit that fixed it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13056> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #13213: Lifting thunks out of thunks to reduce their size.
by GHC 01 Feb '17

01 Feb '17

#13213: Lifting thunks out of thunks to reduce their size. -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is a spin off of this thread: ticket:10980#comment:12 The idea is to add a transformation to STG (or Core) that replaces {{{ let t1 = let t2 = e1 in e2 in e3 }}} with {{{ let t2 = e1 t1 = e2 in e3 }}} Can we give an easy criterion when this transformation is beneficial? The problem is that this will increase allocation in the case when `t1` is not called, as it is more space efficient to pack the union of the free variables of `e1` and `e2` into one closure, instead of having one for the free variables of `e1` and one for those of `e2`. We could say “Do this transformation if the free variables of `e2` and `e1`” are disjoint. Then we’d allocate two extra words (one for the info table of `t2`, and one pointer to that in the closure for `t1`), but have some nice gains if `t1` is indeed called. But this rule would not fire in the [ticket:10980#comment:12 original example], because the `Num a` dictionary is also a free variable, which would now have to be copied into both closures! I guess one could try and see whether real-world programs benefit from this transformation, and how many shared free variables between `e1` and `e2` are heuristically ok. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13213> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13198: incorrect links and file names in GHC user's guide
by GHC 31 Jan '17

31 Jan '17

#13198: incorrect links and file names in GHC user's guide -------------------------------------+------------------------------------- Reporter: takenobu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- There are some incorrect links and file names in GHC user's guide. * docs/users_guide/glasgow_exts.rst - GHC/Base.lhs - GHC/List.lhs * docs/users_guide/ffi-chap.rst - :base-ref:`Foreign` - :base-ref:`Control.Concurrent` I'll send the patch soon on phab. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13198> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10052: Panic (something to do with floatExpr?)
by GHC 31 Jan '17

31 Jan '17

#10052: Panic (something to do with floatExpr?) -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Loading {{{ main = let (x :: String) = "hello" in putStrLn x }}} using a very simple driver for the GHC API (see T145.hs) causes a ghc panic: {{{ [1 of 1] Compiling Main ( T145-input.hs, interpreted ) T145: T145: panic! (the 'impossible' happened) (GHC version 7.10.0.20150128 for x86_64-apple-darwin): floatExpr tick <<details unavailable>> Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} This panic is arising in our test case for #8333, so it may be related to that bug. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10052> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20