April 2015 - ghc-tickets

[GHC] #8178: Need TypeRep for Symbol and numeric type literals; and Typeable instances
by GHC 08 Aug '15

08 Aug '15

#8178: Need TypeRep for Symbol and numeric type literals; and Typeable instances ------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | 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: | ------------------------------------+------------------------------------- Nicolas Trangez points out that we don't have a `TypeRep` for types involving literal strings or numerics. E.g. what is `(typeRep (undefined :: Proxy "foo"))`? Here is Nicolas's example: {{{ {-# LANGUAGE DataKinds, KindSignatures, DeriveFunctor, DeriveDataTypeable #-} module Main where import Data.Typeable import GHC.TypeLits data NoSymbol n a b = NoSymbol a b deriving (Typeable) data WithSymbol (n :: Symbol) a b = WithSymbol a b deriving (Typeable) data Sym deriving (Typeable) main :: IO () main = do print $ typeOf (undefined :: NoSymbol Sym Int Int) let d = undefined :: WithSymbol "sym" Int Int {- print $ typeOf d No instance for (Typeable Symbol "sym") arising from a use of ‛typeOf’ -} return () }}} Just as types contain literal strings and natural numbers, so too must `TypeRep`, in some way. Once we have a suitable `TypeRep` we can make built-in instance for `Typeable` that return the appropriate representation. At the moment we have (in `Data.Typeable.Internals`): {{{ data TypeRep = TypeRep {-# UNPACK #-} !Fingerprint TyCon [TypeRep] data TyCon = TyCon { tyConHash :: {-# UNPACK #-} !Fingerprint, tyConPackage :: String, tyConModule :: String, tyConName :: String } }}} with instances for Eq and Ord. Perhaps we need {{{ data TypeRep = TcApp {-# UNPACK #-} !Fingerprint TyCon [TypeRep] | TcSym String | TcNat Integer }}} or something like that? I'm not certain. I think Iavor is going to think about it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8178> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9853: Stateful transformation causes non-termination in Hoopl analysis.
by GHC 08 Aug '15

08 Aug '15

#9853: Stateful transformation causes non-termination in Hoopl analysis. -------------------------------------+------------------------------------- Reporter: AndreasVoellmy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/hoopl | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Incorrect Blocked By: | result at runtime Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- It seems that Hoopl's analyses may apply rewrites to nodes multiple times without invoking the `restart` function between applications. This causes havoc for code transformations that have side-effects, for example a transformation that introduces a new variable to hold some intermediate result. In such an analysis, a transformation may introduce a new variable, which leads to a changed fact. Later the transformation may be run again, leading to a new fact, and so on (when there is a loop in the control flow. The attached example illustrates this problem. This example modifies the constant propagation pass provided in the testing directory of the hoopl library. The example added a new instruction called "Funny" that gets rewritten to an unconditional branch instruction and introduces a new variable. The main program P1 performs the analysis on a particular program that has a loop in the control flow graph and causes the hoopl analysis to run forever. Is this a bug in Hoopl? Ie. should analyses that have side-effects involving checkpointed state be supported? If not, could it be changed to support these analyses? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9853> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10067: The Read Integer instance is too slow
by GHC 07 Aug '15

07 Aug '15

#10067: The Read Integer instance is too slow -------------------------------------+------------------------------------- Reporter: redneb | Owner: Type: feature | Status: new request | Milestone: Priority: low | Version: 7.11 Component: | Operating System: Unknown/Multiple libraries/base | Type of failure: Runtime Keywords: | performance bug Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The current implementation of the Read Integer instance has quadratic complexity and thus performs badly on large inputs. On my system, it takes 65 seconds to perform the following: {{{#!hs read (take 1000000 $ cycle "1234567890") :: Integer }}} Note that we already provide an ad-hoc instance for Show Integer, so maybe we can do the same for Read Integer. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10067> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #10340: Type inference regression with Any
by GHC 07 Aug '15

07 Aug '15

#10340: Type inference regression with Any -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 (Type checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: | valid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The following module typechecks with GHC 7.8.3, but GHC 7.10.1 gives an error: {{{#!hs {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FlexibleInstances #-} module Foo where import GHC.Exts (Any) class MonadState s m where get :: m s newtype State s a = State (s -> (s, a)) instance MonadState s (State s) where get = State $ \s -> (s, s) foo :: State Any Any foo = get }}} {{{ [1 of 1] Compiling Foo ( any.hs, any.o ) any.hs:15:7: No instance for (MonadState Any (State Any)) arising from a use of ‘get’ In the expression: get In an equation for ‘foo’: foo = get }}} If I replace the uses of `Any` with `Int`, the problem goes away. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10340> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9953: Pattern synonyms don't work with GADTs
by GHC 06 Aug '15

06 Aug '15

#9953: Pattern synonyms don't work with GADTs -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Consider this variant of test `T8968-1`: {{{ {-# LANGUAGE GADTs, KindSignatures, PatternSynonyms #-} module ShouldCompile where data X :: * -> * where Y :: a -> X (Maybe a) pattern C :: a -> X (Maybe a) pattern C x = Y x foo :: X t -> t foo (C x) = Just x }}} * If we had `(Y x)` instead of `(C x)` in the LHS of `foo`, then this is an ordinary GADT program and typechecks fine. * If we omit the pattern signature, it typechecks fine, and `:info C` says {{{ pattern C :: t ~ Maybe a => a -> X t -- Defined in ‘ShouldCompile’ }}} * But as written, it fails with {{{ Foo.hs:11:6: Couldn't match type ‘t’ with ‘Maybe a0’ ‘t’ is a rigid type variable bound by the type signature for: foo :: X t -> t at Foo.hs:10:8 Expected type: X t Actual type: X (Maybe a0) Relevant bindings include foo :: X t -> t (bound at Foo.hs:11:1) In the pattern: C x In an equation for ‘foo’: foo (C x) = Just x }}} Moreover, `:info C` says {{{ pattern C :: a -> X (Maybe a) -- Defined at Foo.hs:8:9 }}} Do you see the difference? In the former, the "prov_theta" equality constraint is explicit, but in the latter it's implicit. The exact thing happens for `DataCons`. It's handled via the `dcEqSpec` field. Essentially `PatSyn` should have a new field for the implicit equality constraints. And, just as for data consructors, we need to generate the equality constraints, and the existentials that are needed, when we process the signature. Use the code in `TcTyClsDecls.rejigConRes` (perhaps needs a better name). This is all pretty serious. Without fixing it, GADT-style pattern signatures are all but useless. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9953> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23

[GHC] #9848: List.all does not fuse
by GHC 05 Aug '15

05 Aug '15

#9848: List.all does not fuse -------------------------------------+------------------------------------- Reporter: klapaucius | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.9 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: Runtime Difficulty: Easy (less than 1 | performance bug hour) | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- {{{ primes = 2:3:filter isPrime [5,7..] :: [Int] isPrime x = all (/= 0) . map (x `rem`) . takeWhile ((<= x) . (^2)) $ primes main = print . length . takeWhile (<= 2^24) $ primes }}} {{{ 12,133,812,164 bytes allocated in the heap 53,433,372 bytes copied during GC 14,235,488 bytes maximum residency (7 sample(s)) 1,110,916 bytes maximum slop 30 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 56357 colls, 0 par 0.094s 0.125s 0.0000s 0.0001s Gen 1 7 colls, 0 par 0.031s 0.034s 0.0049s 0.0154s INIT time 0.000s ( 0.000s elapsed) MUT time 8.094s ( 8.069s elapsed) GC time 0.125s ( 0.159s elapsed) EXIT time 0.000s ( 0.003s elapsed) Total time 8.219s ( 8.231s elapsed) %GC time 1.5% (1.9% elapsed) Alloc rate 1,499,158,259 bytes per MUT second Productivity 98.5% of total user, 98.3% of total elapsed }}} {{{ Rec { $sgo1_r2RE :: GHC.Prim.Int# -> [Int] -> Data.Monoid.All [GblId, Arity=2, Caf=NoCafRefs, Str=DmdType <L,U><L,U>] $sgo1_r2RE = \ (sc_s2PS :: GHC.Prim.Int#) (sc1_s2PT :: [Int]) -> case sc_s2PS of _ [Occ=Dead] { __DEFAULT -> go_r2RF sc1_s2PT; 0 -> GHC.Types.False `cast` (Sym Data.Monoid.NTCo:All[0] :: Bool ~R# Data.Monoid.All) } go_r2RF :: [Int] -> Data.Monoid.All [GblId, Arity=1, Caf=NoCafRefs, Str=DmdType <S,1*U>] go_r2RF = \ (ds_a1YK :: [Int]) -> case ds_a1YK of _ [Occ=Dead] { [] -> GHC.Types.True `cast` (Sym Data.Monoid.NTCo:All[0] :: Bool ~R# Data.Monoid.All); : y_a1YP ys_a1YQ -> case y_a1YP of _ [Occ=Dead] { GHC.Types.I# x_a1Tk -> case x_a1Tk of _ [Occ=Dead] { __DEFAULT -> go_r2RF ys_a1YQ; 0 -> GHC.Types.False `cast` (Sym Data.Monoid.NTCo:All[0] :: Bool ~R# Data.Monoid.All) } } } end Rec } lvl4_r2RG :: Int -> Data.Monoid.All [GblId, Arity=1, Str=DmdType] lvl4_r2RG = \ (x_aqY [OS=ProbOneShot] :: Int) -> case x_aqY of _ [Occ=Dead] { GHC.Types.I# y_a1Uc -> case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.<=# 4 y_a1Uc) of _ [Occ=Dead] { False -> GHC.Types.True `cast` (Sym Data.Monoid.NTCo:All[0] :: Bool ~R# Data.Monoid.All); True -> $sgo1_r2RE (GHC.Prim.remInt# y_a1Uc 2) (letrec { go1_a1S5 [Occ=LoopBreaker] :: [Int] -> [Int] [LclId, Arity=1, Str=DmdType <S,1*U>] go1_a1S5 = \ (ds_a1S6 :: [Int]) -> case ds_a1S6 of _ [Occ=Dead] { [] -> GHC.Types.[] @ Int; : y1_X1T4 ys_X1T6 -> case y1_X1T4 of _ [Occ=Dead] { GHC.Types.I# x1_X1VM -> case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.<=# (GHC.Prim.*# x1_X1VM x1_X1VM) y_a1Uc) of _ [Occ=Dead] { False -> GHC.Types.[] @ Int; True -> GHC.Types.: @ Int (case x1_X1VM of wild5_a1TE { __DEFAULT -> case GHC.Prim.remInt# y_a1Uc wild5_a1TE of wild6_a1TJ { __DEFAULT -> GHC.Types.I# wild6_a1TJ }; (-1) -> GHC.Real.$fIntegralInt1; 0 -> GHC.Real.divZeroError @ Int }) (go1_a1S5 ys_X1T6) } } }; } in go1_a1S5 Main.main3) } } }}} foldr, however, fuse just fine: {{{ primes = 2:3:filter isPrime [5,7..] :: [Int] isPrime x = foldr (&&) True . map (/= 0) . map (x `rem`) . takeWhile ((<= x) . (^2)) $ primes main = print . length . takeWhile (<= 2^24) $ primes }}} {{{ 365,770,752 bytes allocated in the heap 48,197,488 bytes copied during GC 13,031,232 bytes maximum residency (7 sample(s)) 1,570,524 bytes maximum slop 28 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 694 colls, 0 par 0.016s 0.029s 0.0000s 0.0005s Gen 1 7 colls, 0 par 0.031s 0.032s 0.0046s 0.0146s INIT time 0.000s ( 0.000s elapsed) MUT time 3.438s ( 3.439s elapsed) GC time 0.047s ( 0.062s elapsed) EXIT time 0.000s ( 0.003s elapsed) Total time 3.484s ( 3.504s elapsed) %GC time 1.3% (1.8% elapsed) Alloc rate 106,406,036 bytes per MUT second Productivity 98.7% of total user, 98.1% of total elapsed }}} {{{ lvl4_r2qr :: Int -> Bool [GblId, Arity=1, Str=DmdType] lvl4_r2qr = \ (x_aqW [OS=ProbOneShot] :: Int) -> case x_aqW of _ [Occ=Dead] { GHC.Types.I# y_a1tq -> case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.<=# 4 y_a1tq) of _ [Occ=Dead] { False -> GHC.Types.True; True -> case GHC.Prim.remInt# y_a1tq 2 of _ [Occ=Dead] { __DEFAULT -> letrec { go_a1ud [Occ=LoopBreaker] :: [Int] -> Bool [LclId, Arity=1, Str=DmdType <S,1*U>] go_a1ud = \ (ds_a1ue :: [Int]) -> case ds_a1ue of _ [Occ=Dead] { [] -> GHC.Types.True; : y1_X1vf ys_X1vh -> case y1_X1vf of _ [Occ=Dead] { GHC.Types.I# x1_X1x9 -> case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.<=# (GHC.Prim.*# x1_X1x9 x1_X1x9) y_a1tq) of _ [Occ=Dead] { False -> GHC.Types.True; True -> case x1_X1x9 of wild6_X1x3 { __DEFAULT -> case GHC.Prim.remInt# y_a1tq wild6_X1x3 of _ [Occ=Dead] { __DEFAULT -> go_a1ud ys_X1vh; 0 -> GHC.Types.False }; (-1) -> GHC.Types.False; 0 -> case GHC.Real.divZeroError of wild7_00 { } } } } }; } in go_a1ud Main.main3; 0 -> GHC.Types.False } } } }}} And List.all from ghc 7.8 base library does fuse, so this is regression. Windows 8.1 x64, ghc --info: {{{ [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv") ,("C compiler command","$topdir/../mingw/bin/gcc.exe") ,("C compiler flags"," -U__i686 -march=i686 -fno-stack-protector") ,("C compiler link flags","") ,("Haskell CPP command","$topdir/../mingw/bin/gcc.exe") ,("Haskell CPP flags","-E -undef -traditional ") ,("ld command","$topdir/../mingw/bin/ld.exe") ,("ld flags","") ,("ld supports compact unwind","YES") ,("ld supports build-id","NO") ,("ld supports filelist","NO") ,("ld is GNU ld","YES") ,("ar command","$topdir/../mingw/bin/ar.exe") ,("ar flags","q") ,("ar supports at file","YES") ,("touch command","$topdir/touchy.exe") ,("dllwrap command","$topdir/../mingw/bin/dllwrap.exe") ,("windres command","$topdir/../mingw/bin/windres.exe") ,("libtool command","") ,("perl command","$topdir/../perl/perl.exe") ,("target os","OSMinGW32") ,("target arch","ArchX86") ,("target word size","4") ,("target has GNU nonexec stack","False") ,("target has .ident directive","True") ,("target has subsections via symbols","False") ,("Unregisterised","NO") ,("LLVM llc command","llc") ,("LLVM opt command","opt") ,("Project version","7.9.20141129") ,("Project Git commit id","447f592697fef04d1e19a2045ec707cfcd1eb59f") ,("Booter version","7.8.3") ,("Stage","2") ,("Build platform","i386-unknown-mingw32") ,("Host platform","i386-unknown-mingw32") ,("Target platform","i386-unknown-mingw32") ,("Have interpreter","YES") ,("Object splitting supported","YES") ,("Have native code generator","YES") ,("Support SMP","YES") ,("Tables next to code","YES") ,("RTS ways","l debug thr thr_debug thr_l thr_p ") ,("Support dynamic-too","NO") ,("Support parallel --make","YES") ,("Support reexported-modules","YES") ,("Support thinning and renaming package flags","YES") ,("Uses package keys","YES") ,("Dynamic by default","NO") ,("GHC Dynamic","NO") ,("Leading underscore","YES") ,("Debug on","False") ,("LibDir","D:\\msys32\\usr\\local\\lib") ,("Global Package DB","D:\\msys32\\usr\\local\\lib\\package.conf.d") ] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9848> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #9430: implement more arithmetic operations natively in the LLVM backend
by GHC 05 Aug '15

05 Aug '15

#9430: implement more arithmetic operations natively in the LLVM backend -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less | Type of failure: Runtime than a day) | performance bug Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- There are a number of arithmetic operations that have native implementations on x86 but use the generic fallback on LLVM. Implementing these with LLVM intrinsics could improve small Integer performance on ARM substantially! {{{ MO_Add2 @llvm.uadd.with.overflow.* MO_AddIntC @llvm.sadd.with.overflow.* MO_SubIntC @llvm.ssub.with.overflow.* MO_U_Mul2 mul i64/i128? MO_U_QuotRem2 udiv i64/i128? }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9430> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #9233: Compiler performance regression
by GHC 04 Aug '15

04 Aug '15

#9233: Compiler performance regression ------------------------------------+--------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+--------------------------------- Compiling all of our Haskell modules (about 1300 modules, 310 kLOC) takes about 30% longer with ghc 7.8 than it did with ghc 7.2. (Using 32-bit Windows.) Sorry, I can't really provide any simple test case. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9233> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 28

[GHC] #10134: Pattern Matching Causes Infinite Type Error
by GHC 03 Aug '15

03 Aug '15

#10134: Pattern Matching Causes Infinite Type Error -------------------------------------+------------------------------------- Reporter: dongen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Howsagoin, This is a report about ghci (7.8.4) with CLaSH 0.4.1 I have a collection of modules that show an odd error. I don't want to send them to the list but I can send them to the developers if they think the described behaviour is definitely an error, which I suspect it is. When I write: > (a,b) = expression I get a type error about an occurs check: cannot construct infinite type: t0 ~ (t0 + 1) -1. The error message doesn't mention t0. However, when I leave out the pattern matching on the tuple and write > var = expression > a = fst var > b = snd var where var is a fresh variable, everything is fine. This is odd, because all I did was stripping off the pattern matching. To make sure, I also tried > var = expression > (a,b) = var This also gave the same type checking error. If there's anybody willing to have a look at this, please feel free to contact me by email. If you think I should produce a small example, also please let me know, but please note that it already took me several hours before I found that leaving out the pattern matching solved the problem:-( TIA for your time. Marc van Dongen dongen(a)cs.ucc.ie -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10134> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 25

[GHC] #10155: [PATCH] Possibly incorrect stack pointer usage in StgRun() on x86_64
by GHC 03 Aug '15

03 Aug '15

#10155: [PATCH] Possibly incorrect stack pointer usage in StgRun() on x86_64 -------------------------------------+------------------------------------- Reporter: stengel | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.8.1 System | Operating System: Unknown/Multiple Keywords: | Type of failure: Other Architecture: x86_64 | Blocked By: (amd64) | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The STG_RETURN code from StgCRun.c is incorrect for x86_64 variants where the ABI doesn't impose a mandatory red zone for the stack, like on Windows or Xen/HaLVM. The current implementation restores the stack pointer first, which effectively marks the area with the saved registers as reusable. Later, the CPU registers are restored from this "free" area. This ordering happens to work by accident on operating systems that strictly adhere to the System V ABI, because any interrupt/signal delivery is guaranteed to leave the first 128 bytes past the stack pointer untouched (red zone). On other systems this might result in corrupted CPU registers if an interruption happens just after restoring the stack pointer. The red zone is usually only used by small leaf functions to avoid updates to the stack pointer and exploiting it doesn't give us any advantage in this case. The attached patch reorders the register access, so that the stack pointer is restored last. It's also shorter by one instruction. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10155> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4