- ghc-tickets - Haskell.org

Re: [GHC] #5835: Make better use of known dictionaries
by GHC 08 Dec '16

08 Dec '16

#5835: Make better use of known dictionaries -------------------------------------+------------------------------------- Reporter: rl | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.5 Resolution: | 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: | -------------------------------------+------------------------------------- Changes (by nfrisby): * cc: nfrisby (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5835#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3384: Add HsSyn prettyprinter tests
by GHC 08 Dec '16

08 Dec '16

#3384: Add HsSyn prettyprinter tests -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: task | Status: patch Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2752 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Alan Zimmerman <alan.zimm@…>): In [changeset:"499e43824bda967546ebf95ee33ec1f84a114a7c/ghc" 499e438/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="499e43824bda967546ebf95ee33ec1f84a114a7c" Add HsSyn prettyprinter tests Summary: Add prettyprinter tests, which take a file, parse it, pretty print it, re-parse the pretty printed version and then compare the original and new ASTs (ignoring locations) Updates haddock submodule to match the AST changes. There are three issues outstanding 1. Extra parens around a context are not reproduced. This will require an AST change and will be done in a separate patch. 2. Currently if an `HsTickPragma` is found, this is not pretty-printed, to prevent noise in the output. I am not sure what the desired behaviour in this case is, so have left it as before. Test Ppr047 is marked as expected fail for this. 3. Apart from in a context, the ParsedSource AST keeps all the parens from the original source. Something is happening in the renamer to remove the parens around visible type application, causing T12530 to fail, as the dumped splice decl is after the renamer. This needs to be fixed by keeping the parens, but I do not know where they are being removed. I have amended the test to pass, by removing the parens in the expected output. Test Plan: ./validate Reviewers: goldfire, mpickering, simonpj, bgamari, austin Reviewed By: simonpj, bgamari Subscribers: simonpj, goldfire, thomie, mpickering Differential Revision: https://phabricator.haskell.org/D2752 GHC Trac Issues: #3384 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3384#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9320: Inlining regression/strangeness in 7.8
by GHC 08 Dec '16

08 Dec '16

#9320: Inlining regression/strangeness in 7.8 -------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Differential Revisions: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- A couple days ago, it was reported to me that vector-algorithms had a significant performance regression (~20x) on GHC 7.8.2. The problem stems from a lack of inlining and specialization of some of the functions that were previously handled in 7.6 and earlier. The following is a reduced test case (the vector and primitive packages are required): {{{ module A (test) where import Control.Monad.ST import Control.Monad import Control.Monad.Primitive import Data.Vector.Generic.Mutable as U test :: (PrimMonad m, MVector v a, Num a) => Int -> v (PrimState m) a -> m a -- test :: (MVector v a, Num a) => Int -> v s a -> ST s a test 0 v = liftM (+1) $ unsafeRead v 0 test n v = do long1 v test (n-1) v {-# INLINABLE test #-} long1, long2, long3, long4 :: (PrimMonad m, MVector v a) => v (PrimState m) a -> m () long1 v = long2 v >> long2 v >> long2 v >> long2 v long2 v = long3 v >> long3 v >> long3 v >> long3 v long3 v = long4 v >> long4 v >> long4 v >> long4 v long4 v = unsafeRead v 0 >>= unsafeWrite v 0 {-# INLINE long1 #-} {-# INLINE long2 #-} {-# INLINE long3 #-} {-# INLINE long4 #-} }}} {{{ module Main (main) where import Control.Monad.ST import Data.Vector.Unboxed.Mutable as U hiding (read) import System.Environment import Unsafe.Coerce import GHC.Prim import A test0 :: Int -> MVector s Int -> ST s Int test0 n v = test n v {-# NOINLINE test0 #-} test1' :: Int -> MVector Any Int -> ST Any Int test1' n v = test n v {-# NOINLINE test1 #-} test1 :: Int -> MVector a Int -> ST a Int test1 = unsafeCoerce test1' main = getArgs >>= \(n:b:_) -> print $ runST $ do v <- new 1 write v 0 0 (if read b then test0 else test1) (read n) v }}} Module `A` exports a single function, `test`. This function is engineered to be quite large, by inlining several other functions into it, and it is itself marked INLINABLE. Then the `Main` module uses this function in two different ways: * `test0` uses `test` at a type that is compatible with `runST` * `test1'` uses `test` at a completely monomorphic type, which is then coerced to a `runST` compatible type in `test1` On 7.6 I believe (though have not checked) that there will be little or no performance difference between `test0` and `test1`. However, on 7.8.2 (and, I have been assured, 7.8.3), there is a massive speed pentalty for `test0`; about 70x on my machine. This seems to be due to no inining or specialization for its use of `test`, which can be seen from `-ddump- simpl`. However, if one changes the type of `test` in `A` to be specific to `ST s` rather than using `PrimMonad`, there is no performance difference, even on 7.8.2. So, the choice to inline and specialize seems to hinge on the instantiation of all the class constraints to monomorphic types containing no variables, rather than just types that resolve all overloading. I myself did not notice this problem, because my benchmark suite uses `IO`, which is a concrete instantiation of the type, and doesn't exhibit this problem. I have temporarily 'fixed' vector-algorithms by moving back to `INLINE` pragmas, but `INLINABLE` is actually preferable in that case, because it generates faster code than `INLINE` when the optimizations actually fire. My test case here does not illustrate that well, though. Is it safe to assume that this was not an intentional change? It's a rather weird rule (to me) if it was. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9320> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8668: SPECIALIZE silently fails to apply
by GHC 08 Dec '16

08 Dec '16

#8668: SPECIALIZE silently fails to apply ----------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+------------------------------------- I have a small example where GHC refuses to specialize a call to `(+)`, compiling with -O2. The two files are Foo.hs (http://lpaste.net/98464) and Main.hs (http://lpaste.net/98342) There seem to be two problems: 1. The active `SPECIALIZE` pragma should be applied, but isn't. This can be seen by comparing the core and runtimes of `fcTest` (slow) vs `vtTest` (fast). I need this version of the pragma in my real code as the phantom type `m` is reified, so I need to specialize the vector code without specifying the phantom type. 2. I can get `fcTest` to run fast if I use the commented-out `SPECIALIZE` pragma instead. However, that pragma seems very straightforward to me (all types are concrete). The docs indicate that GHC should automatically specialize in most cases, why does it not specialize to the commented-out signature automatically? This problem is also posted here: http://stackoverflow.com/questions/21071706/specialization-with- constraints -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8668> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 26

[GHC] #12866: GHC internal error while building darcsden
by GHC 08 Dec '16

08 Dec '16

#12866: GHC internal error while building darcsden -------------------------------------+------------------------------------- Reporter: simonmic | Owner: Type: bug | Status: new Priority: normal | 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: -------------------------------------+------------------------------------- I get an internal error while building darcsden with GHC 8.0.1: $ darcs get hub.darcs.net:simon/darcsden-ghc8 $ cd darcsden-ghc8 $ stack --stack-yaml=stack-ghc8.yaml build ... [12 of 56] Compiling DarcsDen.Backend.Transient ( src/DarcsDen/Backend/Transient.hs, .stack- work/dist/i386-linux/Cabal-1.24.0.0/build/DarcsDen/Backend/Transient.o ) /home/simon/src/darcsden/src/DarcsDen/Backend/Transient.hs:10:33: error: • GHC internal error: ‘BackendTransientM’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [ajE2 :-> Type variable ‘bt’ = bt] • In the first argument of ‘MonadIO’, namely ‘BackendTransientM bt’ In the type ‘(BT bt, MonadIO (BackendTransientM bt))’ In the type declaration for ‘BTIO’ /home/simon/src/darcsden/src/DarcsDen/Backend/Transient.hs:44:1: error: • Non type-variable argument in the constraint: Functor (BackendTransientM bt) (Use FlexibleContexts to permit this) • In the context: (Functor (BackendTransientM bt), Monad (BackendTransientM bt)) While checking the super-classes of class ‘BackendTransient’ In the class declaration for ‘BackendTransient’ -- While building package darcsden-1.1.99 using: /home/simon/.stack/setup-exe-cache/i386-linux/setup-Simple- Cabal-1.24.0.0-ghc-8.0.1 --builddir=.stack- work/dist/i386-linux/Cabal-1.24.0.0 build lib:darcsden exe:darcsden exe :darcsden-post-hook exe:da... Process exited with code: ExitFailure 1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12866> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #314: #line pragmas not respected inside nested comments
by GHC 08 Dec '16

08 Dec '16

#314: #line pragmas not respected inside nested comments -------------------------------------+------------------------------------- Reporter: nobody | Owner: Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 6.4 (Parser) | Resolution: None | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: read032 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: This won't get fixed for 8.2. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/314#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7782: flag to run the demand analysis a second time
by GHC 08 Dec '16

08 Dec '16

#7782: flag to run the demand analysis a second time -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: Type: task | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4941, #5302, | Differential Rev(s): #6087, #4962 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => closed * resolution: => fixed Comment: Looks like it! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7782#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7782: flag to run the demand analysis a second time
by GHC 08 Dec '16

08 Dec '16

#7782: flag to run the demand analysis a second time -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: Type: task | Status: new Priority: high | Milestone: 8.2.1 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: #4941, #5302, | Differential Rev(s): #6087, #4962 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: nomeata (added) Comment: nomeata, is this perhaps addressed by f4fd98c717a7f68d76a3054021b3be65d1ebad82? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7782#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12652: Type checker no longer accepting code using function composition and rank-n types
by GHC 08 Dec '16

08 Dec '16

#12652: Type checker no longer accepting code using function composition and rank-n types -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | 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: -------------------------------------+------------------------------------- The following program (reduced from Cabal code that uses HasCallStack) typechecks in GHC 8.0, but not on HEAD: {{{ {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ImplicitParams #-} module Foo where type T a = (?x :: Int) => a type M a = T (IO a) f :: T (T a -> a) f x = x g :: Int -> M () g = undefined h :: Int -> M () -- h x = f (g x) -- works on HEAD h = f . g -- fails on HEAD, works on GHC 8.0 }}} It's possible that this is just fall out from the recent impredicativity changes but I just wanted to make sure that this was on purpose. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12652> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #11703: Segmentation fault/internal error: evacuate: strange closure type 15 with GHC.Generics
by GHC 08 Dec '16

08 Dec '16

#11703: Segmentation fault/internal error: evacuate: strange closure type 15 with GHC.Generics -------------------------------------+------------------------------------- Reporter: NathanWaivio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.10.3 System | Keywords: Segmentation | Operating System: Unknown/Multiple Fault, Generics, Runtime error | Architecture: x86_64 | Type of failure: Runtime crash (amd64) | Test Case: attached | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Reproduced issue on both Windows-7/GHC-7.10.3 and Linux-4.1.15/GHC-7.8.4 Seems to probably be a problem with GHC.Generics and the runtime. Windows/GHC-7.10.3 states: internal error: evacuate: strange closure type 15 (GHC version 7.10.3 for x86_64_unkown_mingw32) Please report this as a GHC bug: httpL//www.haskell.org/ghc/reportabug This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. Linux/GHC-7.8.4 states: Segmentation fault Behavior varies based on CSV input file size, a CSV file with header with 1 to 4 rows works. A CSV with a header and more than 10 rows segmentation faults imediatly. Inbetween 4 to 10 sometimes runs forever, works, or segmentation faults. The test case uses Cassava and GHC.Generics and some derived instances to read a CSV file with a record data type with many fields. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11703> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5