January 2014 - ghc-tickets

[GHC] #8147: Exponential behavior in instance resolution on fixpoint-of-sum
by GHC 07 Aug '17

07 Aug '17

#8147: Exponential behavior in instance resolution on fixpoint-of-sum -------------------------+------------------------------------------------- Reporter: | Owner: jkoppel | Status: new Type: bug | Milestone: Priority: | Version: 7.6.3 normal | Operating System: Unknown/Multiple Component: | Type of failure: Compile-time performance bug Compiler | Test Case: Keywords: | Blocking: performance, | Architecture: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- Doing instance resolution on a fixpoint-of-sum type takes a very long time. This is possibly the same issue as issue #5642. These are the numbers I see for various n: {{{ 10 : 0.329s 20 : 0.479s 40 : 0.935s 80 : 2.821s 160 : 11.694s 320 : 1m30.39s 640: Ran for over 1 hour without terminating }}} This uses a couple of attached support files. Apologies for not being able to reduce further. {{{ -- Test.hs {-# LANGUAGE MultiParamTypeClasses, FlexibleInstances, UndecidableInstances, OverlappingInstances, TypeOperators, DeriveFunctor, TemplateHaskell #-} module Test where import Control.Monad import Lib import TH {- With n=3, produces data X1 e = X1 e deriving (Functor) data X2 e = X2 e deriving (Functor) data X3 e = X3 e deriving (Functor) type X = X1 :+: X2 :+: X3 -} $(let n = 320 in liftM concat $ sequence [liftM concat $ mapM mkDec $ map (('X':).show) [1..n] , makeSumType "X" (map (('X':).show) [1..n])]) data Y0 e = Y0 e deriving ( Functor ) type X' = Y0 :+: X class Lift f g where lift' :: f (Fix g) -> Fix g instance (Lift f g, Lift f' g) => Lift (f :+: f') g where lift' x = case x of L e -> lift' e R e -> lift' e instance (Functor f, f :<: g) => Lift f g where lift' = In . inj cata :: (Functor f) => (f a -> a) -> Fix f -> a cata f = f . fmap (cata f) . out lift :: Fix X -> Fix X' lift = cata lift' }}} Virtually all the time is spent in compiling lift. For example, with n=640, commenting out lift makes it compile in around 2 seconds. Interestingly, when I add the following code, compilation times only increase by 10-20%. In the original code where I encountered this issue, doing so doubles compilation time. {{{ instance Lift Y0 X where lift' = undefined lower :: Fix X' -> Fix X lower = cata lift' }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8147> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8631: Need ImpredicativeTypes for GeneralizedNewtypeDeriving?
by GHC 01 Aug '17

01 Aug '17

#8631: Need ImpredicativeTypes for GeneralizedNewtypeDeriving? ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: | ------------------------------------+------------------------------------- Nathan Howell posts this code: {{{ {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE RankNTypes #-} -- Uncomment to compile on GHC 7.8 -- {-# LANGUAGE ImpredicativeTypes #-} module Repro where import Control.Monad.Trans.Cont import Control.Monad.Trans.State.Lazy newtype AnyContT m a = AnyContT { unAnyContT :: forall r . ContT r m a } class MonadAnyCont b m where anyContToM :: (forall r . (a -> b r) -> b r) -> m a instance MonadAnyCont b (AnyContT m) where anyContToM _ = error "foo" data DecodeState = DecodeState newtype DecodeAST a = DecodeAST { unDecodeAST :: AnyContT (StateT DecodeState IO) a } deriving (MonadAnyCont IO) }}} Compiling on HEAD produces {{{ [1 of 1] Compiling Repro ( repro.hs, interpreted ) repro.hs:24:13: Cannot instantiate unification variable ‛b0’ with a type involving foralls: (forall r. (a1 -> IO r) -> IO r) -> DecodeAST a1 Perhaps you want ImpredicativeTypes In the expression: GHC.Prim.coerce (anyContToM :: (forall (r :: *). (a -> IO r) -> IO r) -> AnyContT (StateT DecodeState IO) a) :: forall (a :: *). (forall (r :: *). (a -> IO r) -> IO r) -> DecodeAST a In an equation for ‛anyContToM’: anyContToM = GHC.Prim.coerce (anyContToM :: (forall (r :: *). (a -> IO r) -> IO r) -> AnyContT (StateT DecodeState IO) a) :: forall (a :: *). (forall (r :: *). (a -> IO r) -> IO r) -> DecodeAST a Failed, modules loaded: none. }}} Two questions: 1. Should we require users to specify !ImpredicativeTypes here? Or, should the !GeneralizedNewtypeDeriving mechanism (which sometimes is impredicative) just assume the extension? 2. Can we improve the error message? I'd like to note that the original example really ''does'' require impredicativity -- the question is whether and how to bother the user with this technicality. Small program note: I've done a lot of stuff with !GeneralizedNewtypeDeriving lately but am on holiday until Jan. 6, so don't expect responses! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8631> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #8346: Rank 1 type signature still requires RankNTypes
by GHC 11 Jul '17

11 Jul '17

#8346: Rank 1 type signature still requires RankNTypes ----------------------------+---------------------------------------------- Reporter: | Owner: tinctorius | Status: new Type: bug | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects valid program Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: #2605 | ----------------------------+---------------------------------------------- When trying to figure out which type variable names are *actually* bound in `ScopedTypeVariables`, I tried floating `forall`s into the covariant argument of the function type. Essentially, I ran into the problem that programs like the following are rejected: {{{ #!hs {-# LANGUAGE ExplicitForAll #-} tuple :: forall a. a -> (forall b. b -> (a, b)) tuple = (,) }}} The message is as follows: {{{ Main.hs:2:10: Illegal polymorphic or qualified type: forall b. b -> (a, b) Perhaps you intended to use -XRankNTypes or -XRank2Types In the type signature for `tuple': tuple :: forall a. a -> (forall b. b -> (a, b)) }}} As far as I know, the rank of a type is defined by how deep quantifiers are nested in contravariant parts of that type. Or something like that. Also, as far as I know, `forall a. a -> (forall b. b -> (a, b))` is equivalent to `forall a b. a -> b -> (a, b)`, and more importantly, both are rank-1 polymorphic. There should be no need to use extensions that allow higher-ranked polymorphism. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8346> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8697: Type rationals
by GHC 16 Jun '17

16 Jun '17

#8697: Type rationals ------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I've used GHC's Type Nats to implement my own type level rationals (code below). This works fine, but the syntax is a little funky because you have to write out the number as a fraction. For example, you must write 13/10 instead of 1.3; or even worse, 13/1 instead of 13. It would be nice to just write the decimal notation. I only see one potential problem with this feature: the dot in the decimal notation could interfere with the dot in forall statements. I guess this can be parsed unambiguously, but maybe not. {{{ data Frac = Frac Nat Nat data instance Sing (n::Frac) = SFrac Integer Integer instance (SingI a, SingI b) => SingI ('Frac a b) where sing = SFrac (fromSing (sing :: Sing a)) (fromSing (sing :: Sing b)) instance Fractional r => SingE (Kind :: Frac) r where fromSing (SFrac a b) = fromIntegral a/fromIntegral b type (/) a b = 'Frac a b }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8697> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #8703: Use guard pages rather than heap checks
by GHC 07 Jun '17

07 Jun '17

#8703: Use guard pages rather than heap checks ------------------------------------+------------------------------------- Reporter: schyler | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- By mmap'ing memory using MAP_ANONYMOUS (or /dev/zero) as PROT_NONE (Windows has an equivalent functionality with VirtualAlloc), it's possible to create a page that will fault when read or written to. It may be possible to remove the heap checks in the runtime, speeding up allocations, and instead expand the heap when a fault is raised. This is likely cheaper for large pages full of many small allocations than the cost of the heap checking branch. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8703> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #8048: Register spilling produces ineffecient/highly contending code
by GHC 21 May '17

21 May '17

#8048: Register spilling produces ineffecient/highly contending code -------------------------------------+------------------------------------- Reporter: schyler | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 7.6.3 Keywords: register | Operating System: Unknown/Multiple allocator spill | Type of failure: Runtime Architecture: Unknown/Multiple | performance bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- The native codegen and llvm both produce ineffecient code for functions using structures with many strict fields or unboxed values. Consider the following program: {{{ {-# LANGUAGE BangPatterns #-} module Spill where import GHC.Exts data S = S !Int !Int !Int !Int !Int !Int !Int !Int !Int spill :: S -> S -> S -> S spill (S !a !b !c !d !e !f !g !h !i) (S !j !k !l !m !n !o !p !q !r) (S !s !t !u !v !w !x !y !z _) = S (a + j + s) (b + c) (k + r) (a + b + c + d + e + f + g + h + i) (j + k + l + m + n + o + p + q + r) (s + t + u + v + w + x + y + z) (a + b + c) (j + k + l) (s + t + u) }}} Parts of the code produced for this (which is identical regardless of -funbox-strict-fields) looks like: {{{ _cnc: addq $80,%r12 cmpq 144(%r13),%r12 ja _cni movq $Spill.S_con_info,-72(%r12) movq 32(%rbp),%rax movq %rax,-64(%r12) movq 24(%rbp),%rax movq %rax,-56(%r12) movq 16(%rbp),%rax movq %rax,-48(%r12) movq 8(%rbp),%rax movq %rax,-40(%r12) movq 40(%rbp),%rax movq %rax,-32(%r12) movq 48(%rbp),%rax movq %rax,-24(%r12) movq 56(%rbp),%rax movq %rax,-16(%r12) movq 64(%rbp),%rax movq %rax,-8(%r12) movq 7(%rbx),%rax movq %rax,0(%r12) leaq -71(%r12),%rbx addq $72,%rbp jmp *0(%rbp) }}} {{{ _csv: movq 63(%rbx),%rax movq %rax,-56(%rbp) movq 55(%rbx),%rax movq %rax,-48(%rbp) movq 47(%rbx),%rax movq %rax,-40(%rbp) movq 39(%rbx),%rax movq %rax,-32(%rbp) movq 31(%rbx),%rax movq %rax,-24(%rbp) movq 23(%rbx),%rax movq %rax,-16(%rbp) movq 71(%rbx),%rax movq %rax,-8(%rbp) movq 15(%rbx),%rax movq %rax,0(%rbp) }}} And likewise for LLVM: {{{ .LBB10_1: # %coZ movq 7(%rbx), %rcx movq $Spill_S_con_info, 8(%rax) movq 8(%rbp), %rdx movq %rdx, 16(%rax) movq 16(%rbp), %rdx movq %rdx, 24(%rax) movq 24(%rbp), %rdx movq %rdx, 32(%rax) movq 32(%rbp), %rdx movq %rdx, 40(%rax) movq 40(%rbp), %rdx movq %rdx, 48(%rax) movq 48(%rbp), %rdx movq %rdx, 56(%rax) movq 56(%rbp), %rdx movq %rdx, 64(%rax) movq 64(%rbp), %rdx movq %rdx, 72(%rax) movq %rcx, (%r12) movq 72(%rbp), %rax leaq 72(%rbp), %rbp leaq -71(%r12), %rbx jmpq *%rax # TAILCALL }}} Quoting from #ghc "the [register allocator] core algo is '96 vintage". Improvements are needed; * Take into consideration pipelining and handle spills less dramatically, attempting to reduce register contention * Sink memory reads in order to reduce register pressure -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8048> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #8721: Testsuite not reporting errors for DYN way on OS X
by GHC 18 May '17

18 May '17

#8721: Testsuite not reporting errors for DYN way on OS X ------------------------------------+---------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.6.3 Keywords: dynamic linking | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+---------------------------- Using GHC 7.6.3, on OS X 10.8.5, for the program: `main = putStrLn "Hello World"`, compiling with `ghc --make -dynamic Main.hs`, I get: {{{ ~/Documents/devel/test$ ./Main dyld: Library not loaded: /usr/local/lib/ghc-7.6.3/base-4.6.0.1/libHSbase-4.6.0.1-ghc7.6.3.dylib Referenced from: /Users/christiaan/Documents/devel/test/./Main Reason: image not found Trace/BPT trap: 5 }}} The reason for this is that: * I installed GHC in: `/opt/ghc/7.6.3` instead of the default `/usr/local`. * GHC-bundled libraries get an OS X `install_name` with a prefix of `/usr/local/` instead of `/opt/ghc/7.6.3/`, meaning that the runtime linker will be looking in the wrong place. So, I wondered why this bug never showed in the testsuite and decided to test: {{{ /opt/ghc/7.6.3/src/ghc/testsuite (ghc-7.6)$ make WAY=dyn TEST=10queens … =====> 10queens(dyn) 1834 of 3403 [0, 0, 0] cd ./programs/10queens && '/opt/ghc/7.6.3/src/ghc/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package- db -rtsopts -fno-ghci-history --make -o 10queens Main -O -dynamic >10queens.comp.stderr 2>&1 cd ./programs/10queens && ./10queens </dev/null >10queens.run.stdout 2>10queens.run.stderr OVERALL SUMMARY for test run started at Fri Jan 31 09:42:45 CET 2014 3403 total tests, which gave rise to 13561 test cases, of which 0 caused framework failures 13560 were skipped 1 expected passes 0 had missing libraries 0 expected failures 0 unexpected passes 0 unexpected failures }}} However, when I run the `10queens` program myself: {{{ /opt/ghc/7.6.3/src/ghc/testsuite (ghc-7.6)$ tests/programs/10queens/10queens dyld: Library not loaded: /usr/local/lib/ghc-7.6.3.20130421/base-4.6.0.1/libHSbase-4.6.0.1-ghc7.6.3.20130421.dylib Referenced from: /opt/ghc/7.6.3/src/ghc/testsuite/tests/programs/10queens/10queens Reason: image not found Trace/BPT trap: 5 }}} I get a similar error as the one reported above. Due to commit f7be53ac9dac85b83e7fe5ecede01b98a572ba48, these errors will no longer show in GHC 7.8. However, I feel that the testsuite is now giving a false sense of security in terms of dynamic linking. Obviously dynamic linking was broken in 7.6, but the testsuite did not catch it! Sadly, this behaviour can now only be verified in the 7.6 branch, and not in 7.8 or HEAD. Hopefully somebody more knowledgeable of the testsuite can comment why dynamic linking worked when an executable was run "within" the testsuite, whilst being broken when run normally. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8721> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8396: cleanup / refactor native code gens
by GHC 10 May '17

10 May '17

#8396: cleanup / refactor native code gens ----------------------------------------+---------------------------------- Reporter: carter | Owner: Type: feature request | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: None/Unknown Blocked By: | Test Case: Related Tickets: #8299 , #8287 ,#8272 | Blocking: ----------------------------------------+---------------------------------- the native code gen could use some cleanup / love. 1. Catchup with feature parity of the llvm a. this includes adding SIMD support on applicable native code gen architectures, starting with x86_64 2. make it easier to extend / modify experiment with the native code gen 3. make it easier to add new primops (maybe even a magic inline asm primop?!) 4. other things i'm overlooking right now this also overlaps with a number of related tickets i've been adding to trac. a more ambitious strategic goal that won't be the initial goal, that simon marlow suggested when i chatted with him at ICFP, is to make the native code gen codebase a sort of "mini-llvm". I think thats a bit ambitious for the near term, but maybe thats the point on the horizon we may want to aim towards. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8396> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8573: "evacuate: strange closure type 0" when creating large array
by GHC 10 May '17

10 May '17

#8573: "evacuate: strange closure type 0" when creating large array ----------------------------+---------------------------------- Reporter: nad | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+---------------------------------- Consider the following code: {{{ module Main where import Data.Array xs :: [Int] xs = [0 .. 64988] crash :: Int -> IO () crash m = array (0, m) [ (x, x) | x <- xs ] `seq` return () strangeClosureType = do print (sum xs) crash (maxBound - 1) segFault1 = crash (maxBound - 1) segFault2 = do print (sum xs) crash (maxBound - 2) }}} If I compile the program using `ghc --make Main.hs -O -main-is strangeClosureType`, then I get the following error message: {{{ Main: internal error: evacuate: strange closure type 0 (GHC version 7.6.3 for i386_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) }}} If I don't use `-O`, or if I let `segFault1` or `segFault2` be `main`, then I get the following error message instead: {{{ Segmentation fault (core dumped) }}} If the number `30000` is replaced by some other number, then the strange closure error may be replaced by a segfault, or even no error at all. Perhaps this is another instance of bug #7762; I have only tested using GHC 7.6.3. I am using base 4.6.0.1 and array 0.4.0.1. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8573> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8082: Ordering of assembly blocks affects performance
by GHC 10 May '17

10 May '17

#8082: Ordering of assembly blocks affects performance ----------------------------------+--------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------- During my work on #6135 I noticed that performance of reverse-complem benchmark in nofib depends highly on the order in which assembly block are laid out. With my patches I am consistently getting a 18-20% speed-up. In theory my patches should not impact performance of existing programs, but for some reason they affect the ordering of generated assembly blocks. On of the earlier versions of my patch I noticed that kahan benchmark suffered a 16% performance hit and again the only difference I noticed in the generated assembly was ordering of blocks. I did a more in-depth investigation in case of kahan and it turned out that this difference results from the way Core is generated: the difference between HEAD and my patches was that a worker function had its three parameters passed in different order. I did not investigate this for reverse-complem because Core is considerably larger, but I could spend some time on it if it might be relevant. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8082> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8