October 2016 - ghc-tickets

[GHC] #8107: need types to express constant argument for primop correctness
by GHC 22 Dec '16

22 Dec '16

#8107: need types to express constant argument for primop correctness ------------------------------------+------------------------------------- Reporter: carter | 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: | ------------------------------------+------------------------------------- (not sure if this is a bug or a feature request, or a task, or a dialogue, filing as a bug for now) a number of compiler intrinsics that GHC has started to support (prefetch) and will come to support (concurrent memory operations a la http://ghc.haskell.org/trac/ghc/ticket/7883) require certain arguments to be statically fixed at compile time {{{ primop PrefetchAddrOp "prefetchAddr#" GenPrimOp Addr# -> Int# -> Addr# with llvm_only = True }}} consider the specification on the llvm side for prefetch http://llvm.org/docs/LangRef.html#llvm-prefetch-intrinsic {{{ Syntax:¶ declare void @llvm.prefetch(i8* <address>, i32 <rw>, i32 <locality>, i32 <cache type>) Overview: The ‘llvm.prefetch‘ intrinsic is a hint to the code generator to insert a prefetch instruction if supported; otherwise, it is a noop. Prefetches have no effect on the behavior of the program but can change its performance characteristics. Arguments: address is the address to be prefetched, rw is the specifier determining if the fetch should be for a read (0) or write (1), and locality is a temporal locality specifier ranging from (0) - no locality, to (3) - extremely local keep in cache. The cache type specifies whether the prefetch is performed on the data (1) or instruction (0) cache. The rw, locality and cache type arguments must be constant integers. }}} the punch line is that we're starting add primops that REALLY require certain arguments to be compile time constants to work correctly, otherwise there will by definition be compiler errors after the c-- phase when operations are passed along to the llvm backend and friends. (for the atomicity ops, i'll be looking into adding them to the native code gen, but the point being it will likely trigger an error at code gen time). a strawman approach would look like adding a type {{{ ReallyActuallyConstant :: * or unliftedtype -> * unliftedtype}}} roughly, then prefetch could have the type {{{ primop PrefetchAddrOp "prefetchAddr#" GenPrimOp Addr# ->ReallyActuallyConstant Int# -> Addr# with llvm_only = True }}} a way of emulating something like this functionality now, would be some template haskell that lets you lift a compile time constant of type t into the type ReallyActuallyConstant t, and is the only way to build a value of that type "ReallyActuallyConstant t". That said, that approach seems like a bad way of providing type safetype for making sure primops actually compile! Point being, some sort of way of nicely enforcing that a value needs to be available at compile time, that doesn't require doing abusing template haskell, is the idea i'm pointing at. Might also be useful for other things, but for now, i'm merely remarking on an invariant these primops have -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8107> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #12485: -package-db flags now need to be sorted by dependency order
by GHC 21 Dec '16

21 Dec '16

#12485: -package-db flags now need to be sorted by dependency order -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Package | Version: 8.0.1 system | 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: -------------------------------------+------------------------------------- After 39b71e81ec1044518f065d0055676d713521e483 putting the -package-db flags in the wrong order will result in a compile error: {{{ <command line>: cannot satisfy -package-id b-1-XXX: b-1-XXX is unusable due to missing or recursive dependencies: a-1-XXX (use -v for more information) }}} See attached file for a repro. It's reproduces in 8.0.1 and HEAD. Doesn't reproduce in GHC 7.10.3 or after reverting the above mentioned commit. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12485> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 39

[GHC] #9509: No automatic specialization of inlinable imports in 7.8
by GHC 21 Dec '16

21 Dec '16

#9509: No automatic specialization of inlinable imports in 7.8 -------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Runtime Blocked By: | performance bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- According to the GHC manual, any uses of an imported definition that is overloaded and INLINABLE will automatically cause a SPECIALIZE to be generated for those uses, if appropriate. However, this no longer appears to be the case in 7.8(.3). Here is a simple test case: {{{#!hs module A (foo) where import Data.IORef foo :: Ord a => a -> IO a foo x = newIORef x >>= readIORef >>= \y -> case compare x y of LT -> return x ; _ -> return y {-# INLINABLE foo #-} }}} {{{#!hs module Main (main) where import A main = foo (5 :: Int) >>= print }}} `foo` is constructed to be long enough that GHC 7.8.3 will elect to not inline it. When compiling with 7.6.3, the core contains the following: {{{ Main.$sfoo1 :: GHC.Types.Int -> GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, GHC.Types.Int #) [GblId, Arity=2, Caf=NoCafRefs, Str=DmdType LL, Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=2, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [20 0] 55 30}] Main.$sfoo1 = \ (x_XkE :: GHC.Types.Int) (eta_B1 :: GHC.Prim.State# GHC.Prim.RealWorld) -> case GHC.Prim.newMutVar# @ GHC.Types.Int @ GHC.Prim.RealWorld x_XkE eta_B1 of _ { (# ipv_amT, ipv1_amU #) -> case GHC.Prim.readMutVar# @ GHC.Prim.RealWorld @ GHC.Types.Int ipv1_amU ipv_amT of ds1_amJ { (# ipv2_Xn8, ipv3_Xna #) -> case x_XkE of wild_axu { GHC.Types.I# x#_axw -> case ipv3_Xna of _ { GHC.Types.I# y#_axA -> case GHC.Prim.<# x#_axw y#_axA of _ { GHC.Types.False -> ds1_amJ; GHC.Types.True -> (# ipv2_Xn8, wild_axu #) } } } } } Main.$sfoo :: GHC.Types.Int -> GHC.Types.IO GHC.Types.Int [GblId, Arity=2, Caf=NoCafRefs, Str=DmdType LL, Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=0, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(unsat_ok=True,boring_ok=True)}] Main.$sfoo = Main.$sfoo1 `cast` (<GHC.Types.Int> -> Sym <(GHC.Types.NTCo:IO <GHC.Types.Int>)> :: (GHC.Types.Int -> GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, GHC.Types.Int #)) ~# (GHC.Types.Int -> GHC.Types.IO GHC.Types.Int)) ... ------ Local rules for imported ids -------- "SPEC A.foo [GHC.Types.Int]" [ALWAYS] forall ($dOrd_sxj :: GHC.Classes.Ord GHC.Types.Int) A.foo @ GHC.Types.Int $dOrd_sxj = Main.$sfoo }}} However, in 7.8.3 and newer (I'm actually using 7.9.20140725 for this particular output, but 7.8.3 is similar), we see the following: {{{ Main.main1 :: GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, () #) [GblId, Arity=1, Str=DmdType <L,U>, Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=1, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [0] 100 0}] Main.main1 = \ (s_aIb :: GHC.Prim.State# GHC.Prim.RealWorld) -> case ((A.foo @ GHC.Types.Int GHC.Classes.$fOrdInt Main.main2) `cast` (GHC.Types.NTCo:IO[0] <GHC.Types.Int>_R :: GHC.Types.IO GHC.Types.Int ~R# (GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, GHC.Types.Int #)))) s_aIb of _ [Occ=Dead] { (# ipv_aIe, ipv1_aIf #) -> GHC.IO.Handle.Text.hPutStr2 GHC.IO.Handle.FD.stdout (GHC.Show.$fShowInt_$cshow ipv1_aIf) GHC.Types.True ipv_aIe } }}} There is no local rules section in 7.8.3. Putting a manual SPECIALIZE pragma in the main module generates comparable code to 7.6.3, so it does not appear to be a failure at that level. Rather, GHC seems to just not be generating the SPECIALIZE equivalent. Presumably this is a regression, but even if not, the manual should be revised. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9509> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #11598: Cache coercion kinds and roles
by GHC 21 Dec '16

21 Dec '16

#11598: Cache coercion kinds and roles -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire 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: -------------------------------------+------------------------------------- Because we never inspect the structure of a coercion, it is easy to cache coercions' kinds and role at the top level, using something like this: {{{ data Coercion = MkCoercion { coercionKind :: Pair Type , coercionRole :: Role , coercionRep :: CoercionRep } data CoercionRep = -- the long, recursive datatype we have now }}} In the process, various role and type information currently stored in the recursive structure could be dropped. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11598> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12444: Regression: panic! on inaccessible code with constraint
by GHC 21 Dec '16

21 Dec '16

#12444: Regression: panic! on inaccessible code with constraint -------------------------------------+------------------------------------- Reporter: zilinc | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Running the following program with ghci-8.0.1: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} module Prove where data Nat = Zero | Succ Nat data SNat (n :: Nat) where SZero :: SNat Zero SSucc :: SNat n -> SNat (Succ n) type family (:+:) (a :: Nat) (b :: Nat) :: Nat where m :+: Zero = m m :+: (Succ n) = Succ (m :+: n) sadd :: ((Succ n1 :+: n) ~ Succ (n1 :+: n), (Succ n1) ~ m) => SNat m -> SNat n -> SNat (m :+: n) sadd SZero n = n }}} -ddump-tc-trace shows: {{{ ... dischargeFmv s_a9qV[fuv:4] = t_a9qW[tau:5] (1 kicked out) doTopReactFunEq (occurs) old_ev: [D] _ :: ((n1_a9qu[sk] :+: 'Succ s_a9qV[fuv:4]) :: Nat) GHC.Prim.~# (s_a9qV[fuv:4] :: Nat)ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): ctEvCoercion [D] _ :: (t_a9qW[tau:5] :: Nat) ~# ('Succ (n1_a9qu[sk] :+: s_a9qV[fuv:4]) :: Nat) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} It is rightly rejected by ghci-7.10.2: {{{ Prove.hs:42:6: Couldn't match type ‘'Succ n1’ with ‘'Zero’ Inaccessible code in a pattern with constructor SZero :: SNat 'Zero, in an equation for ‘sadd’ In the pattern: SZero In an equation for ‘sadd’: sadd SZero n = n Failed, modules loaded: none. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12444> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #11522: maxStkSize can overflow
by GHC 19 Dec '16

19 Dec '16

#11522: maxStkSize can overflow -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.8.4 System | 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 `maxStkSize` field of `GC_FLAGS` is a `nat`, or `unsigned int`. It's measured in words, but still 32G is not an unreasonable amount of memory by today's standards. Maybe it's unlikely that anyone would want to set the stack size limit to more than 32G. But if you happen to have just over 40G of physical memory then the default stack size limit will overflow to a value just above zero and then Bad Things would happen. If we want to actually enforce stack limits that are greater than 2^32^ words, we would need to increase the size of the `tot_stack_size` field of a TSO also. Simple test of overflow behavior: `ghci +RTS -K32.0001G` will exit with a stack overflow. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11522> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11502: Scrutinize use of 'long' in rts/
by GHC 19 Dec '16

19 Dec '16

#11502: Scrutinize use of 'long' in rts/ -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.10.3 System | 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: -------------------------------------+------------------------------------- In commit 53055bb5023e8cc145ad8a9cd36ac56cee4695b0 (#5656), several uses of `int` in the rts were replaced by `long`, to avoid potential overflows for some calculations. On Windows though, `int` and `long` have the same size (4 bytes). Carefully go through all uses of `long` in `rts/`, and replace by one of the types from `includes/stg/Types.h`: * `long` -> `StgInt` or `StgInt64` * `unsigned long` -> `StgWord` or `StgWord64` -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11502> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10007: Fix misattribution of Cost Centre profiles to lintAnnots
by GHC 19 Dec '16

19 Dec '16

#10007: Fix misattribution of Cost Centre profiles to lintAnnots -------------------------------------+------------------------------------- Reporter: | Owner: scpmw thoughtpolice | Status: new Type: bug | Milestone: 7.10.1 Priority: high | Version: 7.10.1-rc1 Component: Profiling | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect result Architecture: | at runtime Unknown/Multiple | Blocked By: Test Case: | Related Tickets: #9961 Blocking: | Differential Revisions: Phab:D616 | -------------------------------------+------------------------------------- Split off from #9961 - the profiling results while debugging erroneously reported that most cost centre profiles were a result of `lintAnnots`, as opposed to `CSE`. This is a bug. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10007> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #10723: Make declarations in signatures "weakly bound" until they are used
by GHC 17 Dec '16

17 Dec '16

#10723: Make declarations in signatures "weakly bound" until they are used -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Priority: normal | Milestone: Component: Package | Version: 7.11 system | Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Suppose you are the author of a library in a Backpack world, and you publish a signature package which defines the entire public facing interface of your library. The library `foo` which uses of your library decides to `include` the signature package for convenience, but actually only uses a small portion of the API. Later, you make a BC-breaking change in one part of the library and release a new signature package. The library `bar` which uses your library includes this NEW signature package, using a different portion of the API which was unaffected by the by the BC change. Now, a hapless user tries to use `foo` and `bar`, but Backpack complains that the requirements are not compatible. What's the problem here? The practice of writing reusable signature packages for people to use caused the requirements of `foo` and `bar` to become too large, since they included a lot of junk that these libraries didn't actually use. It would be far better if you could `include` a signature package, but only "require" the bits of it that you actually used! How can we achieve this? 1. We augment the `ModIface` of signature merges (#10690) to record whether or not a declaration was (transitively) used or not by some module. Used declarations must be filled, but unused ones are treated more flexibly: if they are merged with a different, incompatible but used requirement, they disappear, and we don't check if an implementing module actually implemented the declaration. (If two unused incompatible requirements are merged, we just erase the name.) 2. How do we compute the usage info? I think it will have to be done during shaping (which runs the renamer). We only need to annotate each declaration a signature with the transitive set of names from other signatures that it has used--this can be incrementally computed. (It's not necessary to annotate declarations in modules, since they are always assumed to use holes). Then whenever a declaration from a signature is used in a module, we mark its transitive set as used. This information can then be used later when constructing the merged `ModIface` which represents the "public requirement" of the package. So, for example, a package containing only signatures would contain all unused declarations (however, they may start being used by a package which includes them). Any unused declaration which isn't mixed with another incompatible declaration can be imported (causing it to be used), but we will complain if you try to use a name and we can't tell which declaration to use. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10723> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9601: Make the rewrite rule system more powerful
by GHC 16 Dec '16

16 Dec '16

#9601: Make the rewrite rule system more powerful -------------------------------------+------------------------------------- Reporter: spacekitteh | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Project (more | Type of failure: than a week) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- It would be amazing if the current RULES system could be upgraded to include various predicates, or even into a full-on strategic programming system. This would allow far far more optimisations to be possible, rather than the current conservative system where you have to make sure that the optimisations ALWAYS apply. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9601> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6