- ghc-tickets - Haskell.org

[GHC] #13223: Core Prep sometimes generates case of type lambda
by GHC 02 Feb '17

02 Feb '17

#13223: Core Prep sometimes generates case of type lambda -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: -------------------------------------+------------------------------------- Found something odd when updating the test case for T13156: Core Prep will turn {{{ let f = \@a -> case ... in case f @ Any of ... }}} into {{{ case (\@a -> case ...) of f { __DEFAULT -> case f @ Any of ... }}} because `f` is demanded and not an HNF. Seems like this is turning a lazy binding into a strict one since that \@a is about to be erased, but I haven't investigated. (Assigning to myself to put together a proper test case at least.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13223> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #1311: newtypes of unboxed types disallowed - documentation bug and/or feature request
by GHC 02 Feb '17

02 Feb '17

#1311: newtypes of unboxed types disallowed - documentation bug and/or feature request -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: osa1 Type: feature request | Status: new Priority: low | Milestone: ⊥ Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alexbiehl): I'm sorry, I falsely implied the context of this thread. I think the general idea is described in https://ghc.haskell.org/trac/ghc/wiki/UnliftedDataTypes. I noticed the conversation here got stalled so I picked up and experimented where osa1 left: https://ghc.haskell.org/trac/ghc/ticket/1311#comment:12 describes a construct like the following: {{{ type Unlifted = TYPE 'UnliftedRep newtype Blah :: TYPE 'IntRep where Blah :: Int# -> Blah data T :: Unlifted where T :: Int -> Int -> T }}} Which allows: 1. newtype declaration over unlifted types 2. data declarations which are represented through an unlifted pointer (do not contain bottom) The approach mentioned on `UnliftedDataTypes` page introduces a new keyword `unlifted`. This approach differs in that we give the unlifted representation through an explicit kind signature on the newtype/data type instead of a new syntax. And that is what the patch allows in https://ghc.haskell.org/trac/ghc/ticket/1311#comment:18 enables us to write. I can formulate a proposal next week. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1311#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1311: newtypes of unboxed types disallowed - documentation bug and/or feature request
by GHC 02 Feb '17

02 Feb '17

#1311: newtypes of unboxed types disallowed - documentation bug and/or feature request -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: osa1 Type: feature request | Status: new Priority: low | Milestone: ⊥ Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > I would really like a wiki page to describe the design, please. Maybe it's a simple page -- if so, so much the better. Alex, it's great that you have made a patch but I can't even begin to look at it until I know precisely what it is intended to achieve. Specification before implementation. You might also (perhaps in parallel) want to formulate a [https://github.com/ghc-proposals/ghc-proposals GHC Proposal]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1311#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

02 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: | -------------------------------------+------------------------------------- Comment (by simonpj): > The second argument is still boxed Even with -O2 (which does a second demand/absence analysis pass? I think, though I have not dug into it, that the absence may only show up late. Even if that's true, we should just check to ensure that there's no way it could have been caught in the first pass. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5302#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[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

Re: [GHC] #1311: newtypes of unboxed types disallowed - documentation bug and/or feature request
by GHC 02 Feb '17

02 Feb '17

#1311: newtypes of unboxed types disallowed - documentation bug and/or feature request -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: osa1 Type: feature request | Status: new Priority: low | Milestone: ⊥ Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alexbiehl): I have put together a proof of concept [https://github.com/alexbiehl/ghc/commit/57a1a3506c90f2b8f75014ca71ca6b67306… here]. It supports newtypes over unlifted data *and* unlifted data types (with unpacking). This is done without much knowledge about what is a right or wrong thing to do. But I would be happy if we could discuss it and maybe make it a patch we all agree with. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1311#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[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 02 Feb '17

02 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 02 Feb '17

02 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 02 Feb '17

02 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