February 2016 - ghc-tickets

[GHC] #8763: forM_ [1..N] does not get fused (10 times slower than go function)
by GHC 12 Oct '18

12 Oct '18

#8763: forM_ [1..N] does not get fused (10 times slower than go function) ------------------------------+-------------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- Apparently idiomatic code like {{{forM_ [1.._N]}}} does not get fused away. This can give serious performance problems when unnoticed. {{{ -- Slow: forM_ [0.._N-1] $ \i -> do ... -- Around 10 times faster: loop _N $ \i -> do ... {-# INLINE loop #-} loop :: (Monad m) => Int -> (Int -> m ()) -> m () loop bex f = go 0 where go !n | n == bex = return () | otherwise = f n >> go (n+1) }}} Full code example: https://gist.github.com/nh2/8905997 - the relevant alternatives are commented. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8763> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 86

[GHC] #11368: Pattern synonym name is mangled when patterns are non-exhaustive
by GHC 10 Oct '18

10 Oct '18

#11368: Pattern synonym name is mangled when patterns are non-exhaustive ---------------------------------------+--------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.1 Keywords: PatternSynonyms | Operating System: Linux Architecture: x86 | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: #11367 Differential Rev(s): | Wiki Page: ---------------------------------------+--------------------------- {{{ pattern A n <- ... where A 0 = ... }}} When a pattern synonym is non-exhaustive its name is mangled: {{{ >>> A 3 "*** Exception: /tmp/tmp.t0h0pMgwWb.hs:(4,1)-(5,14): Non-exhaustive patterns in function $bA }}} “Non-exhaustive patterns in pattern synonym A” [https://ghc.haskell.org/trac/ghc/ticket/11367?replyto=5#comment:1 Comment] from ticket #11367. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11368> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10783: Partial type signatures should work with pattern synonym signatures
by GHC 10 Oct '18

10 Oct '18

#10783: Partial type signatures should work with pattern synonym signatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE PatternSynonyms #-} pattern MyJust :: _ pattern MyJust a = Just a }}} GHC can correctly infer the type for the pattern without the type signature so (to me) it is unexpected that this inferred type is not reported to me when using partial type signatures. It just seems to not be implemented currently. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10783> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8708: Kind annotation in tuple not parsed
by GHC 04 Oct '18

04 Oct '18

#8708: Kind annotation in tuple not parsed -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Consider this: {{{ {-# LANGUAGE KindSignatures #-} foo :: (Int, Int :: *) foo = undefined }}} HEAD reports {{{ /Users/rae/temp/Bug.hs:5:18: parse error on input ‛::’ }}} Changing the line to {{{ foo :: (Int, (Int :: *)) }}} fixes the problem. Note the extra parentheses. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8708> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11622: Annotating types in type familiy equations without parentheses
by GHC 04 Oct '18

04 Oct '18

#11622: Annotating types in type familiy equations without parentheses -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: 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: -------------------------------------+------------------------------------- When annotating types in right-hand side of type family equations parentheses are required: {{{#!hs type family F a where F _ = (Int :: Type) }}} instead of {{{#!hs type family F a where F _ = Int :: Type }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11622> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11251: isInstance does not work on Typeable with base-4.8 anymore
by GHC 04 Oct '18

04 Oct '18

#11251: isInstance does not work on Typeable with base-4.8 anymore -------------------------------------+------------------------------------- Reporter: songzh | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.10.1 libraries/base | Keywords: Typeable, | Operating System: Unknown/Multiple isInstance | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs > :set -XTemplateHaskell > :m +Data.Tyepable > :m +Language.Haskell.TH --- With GHC 7.8 or earlier versions of GHC (I only tried with GHC 7.6, but my friends tried on 7.8 and earlier versoin) > $(isInstance ''Typeable [ConT ''Char] >>= stringE.show) "True" --- With GHC 7.10.1 > $(isInstance ''Typeable [ConT ''Char] >>= stringE.show) "False" }}} I have noticed that standalone derivings of Typeable instances in Data.Typeable are disappared magically in base-4.8 of GHC 7.10,also one cannot query the instances of it by using `:i Typeable` in GHCi, however, obviously, I can use `typeOf` function in base-4.8 to get the TypeRep of Char. The problem is that `isInstance` in template-haskell library doesn't know Char and many other types are instances of Typeable anymore. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11251> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #9136: Constant folding in Core could be better
by GHC 02 Oct '18

02 Oct '18

#9136: Constant folding in Core could be better ------------------------------+-------------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- Constant folding in Core is still a bit feeble. For example, when staring at the code for `nofib/shootout/k-nucleotide` I saw this expression: {{{ (x +# 8) -# 1 }}} which would be relatively easy to optimise. The difficulty is knowing where to stop. What about `(8 +# x) -# 1`? Anyway, this ticket is to record the issue. Currently constant folding is done by the built-in RULES in `compiler/prelude/PrelRules`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9136> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 31

[GHC] #10791: Add a --disable-large-memory-space configure option
by GHC 02 Oct '18

02 Oct '18

#10791: Add a --disable-large-memory-space configure option -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: feature | Status: new request | Priority: normal | Milestone: 7.12.1 Component: Build | Version: 7.11 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- GHC recently started using large (1TB) address space on 64 bit systems. This feature is enabled by default but does not work on arm64-linux or amd64-solaris. Even just for testing, it would be nice to be able to disable this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10791> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10793: Incorrect blocked on MVar detection
by GHC 02 Oct '18

02 Oct '18

#10793: Incorrect blocked on MVar detection -------------------------------------+------------------------------------- Reporter: | Owner: simonmar NeilMitchell | Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.10.1 System | Keywords: | Operating System: Windows Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Given the code: {{{#!hs import Control.Concurrent main = do v <- newEmptyMVar forkFinally (putStrLn $ let x = x in x) (putMVar v) print =<< takeMVar v }}} The spawned thread should raise a {{{NonTermination}}} exception (assuming idle GC), then put it in the MVar {{{v}}}, which should cause the main thread to abort printing {{{Left <<loop>>}}}. However, in reality, the main thread aborts with {{{Exception: thread blocked indefinitely in an MVar operation}}}. My debugging shows that the spawned thread raises {{{NonTermination}}} and at the same time the main thread raises {{{BlockedIndefinitelyOnMVar}}}. Of course, the main thread is not really blocked on the exception, and after the finally bit runs, the MVar is filled. Adding tracing shows that the {{{putMVar}}} is called. Hypothesis is that the GC notices it can raise the non-termination exception, and then opportunistically excludes that thread from further GC scanning, and detects the MVar is unreferenced, raising the subsequent exception. Of course, given you can catch the exception, that isn't safe. Roman Leshchinskiy worries that in the wrong circumstances the MVar might really be being GC'd and thus could corrupt memory. This issue was detected while debugging an error in the Shake build system for GHC itself. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10793> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8226: Remove the old style -- # Haddock comments.
by GHC 01 Oct '18

01 Oct '18

#8226: Remove the old style -- # Haddock comments. ------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: task | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Haddock 0.x supported -- # style comments for Haddock pragma and while this seems to have been long forgotten and not documented, it's still kicking in the lexer. I think this is a good time to get rid of these all together. Relevant Haddock ticket http://trac.haskell.org/haddock/ticket/171 I'll hopefully send in patches removing these from the lexer/parser tomorrow, if all goes well (unless anyone feels eager to do it, then please, you're most welcome to do so!). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8226> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11