February 2017 - ghc-tickets

[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

Re: [GHC] #6087: Join points need strictness analysis
by GHC 01 Feb '17

01 Feb '17

#6087: Join points need strictness analysis -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: JoinPoints 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: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => infoneeded * milestone: => 8.2.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6087#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6087: Join points need strictness analysis
by GHC 01 Feb '17

01 Feb '17

#6087: Join points need strictness analysis -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Resolution: | Keywords: JoinPoints 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: | -------------------------------------+------------------------------------- Comment (by dfeuer): This does not seem to be an issue for this case after applying Luke's patch either (no join point and no problem). Are there reasons to suspect this is still an issue? If so, we need a new test case; otherwise I think we can close this ticket. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6087#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5302: Unused arguments in join points
by GHC 01 Feb '17

01 Feb '17

#5302: Unused arguments in join points -------------------------------------+------------------------------------- Reporter: reinerp | Owner: simonpj Type: bug | Status: new Priority: low | Milestone: 8.4.1 Component: Compiler | Version: 7.0.3 Resolution: | Keywords: JoinPoints 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: | -------------------------------------+------------------------------------- Changes (by dfeuer): * milestone: => 8.4.1 Comment: This does ''not'' appear to be fixed by the join point update. The second argument is still boxed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5302#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[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] #13217: configure script uses different CFLAGS from the actual build
by GHC 01 Feb '17

01 Feb '17

#13217: configure script uses different CFLAGS from the actual build -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.1 Keywords: autoconf | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `configure` fails to set `CFLAGS` to the value that will actually be used. This can result in checks giving wrong results. I discovered this when working on Phab:D2996, where it led to a build failure using Clang. Note that `-Werror` cannot be used during most checks in `configure`, but is necessary for `FP_CHECK_FLAG`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13217> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[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