- ghc-tickets - Haskell.org

[GHC] #8996: mark more things as const in C codegen
by GHC 24 Apr '17

24 Apr '17

#8996: mark more things as const in C codegen -------------------------------------------+------------------------------- Reporter: slyfox | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (CodeGen) | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- Recently i've tried to build ghc-7.8.2 on ia64 and it overflows so called "short data" section. (it's where global 'static' variables live). I've looked at low-hanging fruits of squashing such global "variables". One source of them seems to be a string literal. Consider one-line module: {{{ module B (v) where v = "hello" }}} in '''-fvia-C''' (or unreg) mode it generates code like {{{ static char gibberish_str[] = "hello"; }}} It uselessly eats data section. The patch switches generator to emit: {{{ static const char gibberish_str[] = "hello"; }}} Some notes: 1. as far as I see native codegens already put ot to .rodata, thus it should be safe. 2. I likely didn't cover more cases, like - RelocatableReadOnlyData - and mysterious '''pprTop (CmmData _section (Statics lbl [CmmUninitialised size]))''' Size of unreg-stage2 on amd64 before and after the patch: {{{ $ size inplace/lib/bin/ghc-stage2 (unpatched) text data bss dec hex filename 81986382 20776344 44096 102806822 620b526 inplace/lib/bin/ghc-stage2 $ size inplace/lib/bin/ghc-stage2 (patched) text data bss dec hex filename 83648494 19062936 44096 102755526 61fecc6 inplace/lib/bin/ghc-stage2 }}} Text section increased for 1.6MBs (consts moved here, likely .rodata actually), data section decreased for 1.7MBs. I think with minor fiddling with linker flags we can merge equal constants later on. Thanks! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8996> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #13404: Derive instances for classes with associated types
by GHC 24 Apr '17

24 Apr '17

#13404: Derive instances for classes with associated types -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) 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: -------------------------------------+------------------------------------- When trying to derive an instance of a class with associated types {{{#!hs import Data.Distributive import Data.Functor.Rep data Pair a = a :# a deriving Functor instance Distributive Pair where distribute :: Functor f => f (Pair a) -> Pair (f a) distribute = distributeRep instance Representable Pair where type Rep Pair = Bool index :: Pair a -> (Bool -> a) index (a :# _) False = a index (_ :# b) True = b newtype PAIR a = PAIR (Pair a) deriving (Functor, Representable) instance Distributive PAIR where distribute = {- distributeRep -} }}} {{{ • Can't make a derived instance of ‘Representable PAIR’ (even with cunning GeneralizedNewtypeDeriving): the class has associated types • In the newtype declaration for ‘PAIR’ }}} But it could create an instance {{{#!hs instance Representable PAIR where type Rep PAIR = Bool index :: forall a. PAIR a -> (Bool -> a) index = coerce (index :: Pair a -> (Bool -> a)) }}} Same with complicated expressions like {{{#!hs infixr 9 · type (·) = Compose newtype P f g h a = P (Product (f·g·f) (h·f·g) a) deriving (Functor, Foldable, Traversable, Applicative, Alternative, Distributive) instance (Functor f, Functor g, Functor h, Representable f, Representable g, Representable h) => Distributive (P f g h) where distribute = distributeRep instance (Functor f, Functor g, Functor h, Representable f, Representable g, Representable h) => Representable (P f g h) where type Rep (P f g h) = Either (Rep f, (Rep g, Rep f)) (Rep h, (Rep f, Rep g)) index :: (P f g h) a -> (Either (Rep f, (Rep g, Rep f)) (Rep h, (Rep f, Rep g)) -> a) index = coerce (index @(Product (f·g·f) (h·f·g))) tabulate :: (Either (Rep f, (Rep g, Rep f)) (Rep h, (Rep f, Rep g)) -> a) -> (P f g h) a tabulate = coerce (tabulate @(Product (f·g·f) (h·f·g))) }}} Is this too limited to work on general -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13404> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11714: Kind of (->) type constructor is overly constrained
by GHC 24 Apr '17

24 Apr '17

#11714: Kind of (->) type constructor is overly constrained -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 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: -------------------------------------+------------------------------------- Currently the `(->)` type constructor has kind `* -> * -> *` (with some magic to make infix work for unlifted types. To quote the comment attached to `TysPrim.funTyCon`, > You might think that `(->)` should have type `?? -> ? -> *`, and you'd be right. But if we do that we get kind errors when saying > {{{ > instance Control.Arrow (->) > }}} > because the expected kind is `* -> * -> *`. The trouble is that the expected/actual stuff in the unifier does not go contra-variant, whereas the kind sub-typing does. Sigh. It really only matters if you use `(->)` in a prefix way, thus: `(->) Int# Int#`. And this is unusual. because they are never in scope in the source }}} This seems to imply that the restrictive kind arose out of the old subkinding story. Now that we have a more principled way of dealing with non-lifted kinds it seems we allow prefix uses to be as polymorphic as infix uses. Something like, {{{#!hs (->) :: forall (rep1 :: RuntimeRep) (rep2 :: RuntimeRep). TYPE rep1 -> TYPE rep2 -> * }}} Not only would this be a win for consistency, but it may also address some of the Core Lint issues that I'm seeing in #11011. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11714> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #13316: Bad inlining cascade leads to slow optimisation
by GHC 24 Apr '17

24 Apr '17

#13316: Bad inlining cascade leads to slow optimisation -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) 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: -------------------------------------+------------------------------------- Consider this simple program {{{ {-# INLINE [0] f #-} f x y = case y of True -> reverse x False -> reverse (reverse x) foo a b = let x = [a,a,a,a] in f x b }}} If you compile with -DDEBUG you'll see {{{ bash$ ghc-stage1 Foo.hs -O -fforce-recomp -c WARNING: file compiler/simplCore/SimplCore.hs, line 670 Simplifier bailing out after 4 iterations [17, 1, 1, 1] Size = {terms: 60, types: 49, coercions: 0, joins: 0/0}}}} }}} Yikes! One transformation per simplifier iteration! What is going on? Before inlining `f` we have {{{ (f [a,a,a,a] b) }}} Then, we inline, beta-reduce, and build let bindings thus {{{ let x1 = a : [] x2 = a : x1 x3 = a : x2 x4 = a : x3 in case b of True -> reverse x4 False -> reverse (reverse x4) }}} So far so good. But then, bizarrely, we do `postInlineUnconditionally` on `x4` (see comments in that function). But not on `x3` because its occ- info is "once inside lambda". Then in the next iteration we `postInlineUnconditionally` `x3`, and so on. Terrible, terrible. My thought: revisit these comments in `postInlineUnconditionally`: {{{ OneOcc { occ_in_lam = in_lam, occ_int_cxt = int_cxt } -- OneOcc => no code-duplication issue -> smallEnoughToInline dflags unfolding -- Small enough to dup -- ToDo: consider discount on smallEnoughToInline if int_cxt is true -- -- NB: Do NOT inline arbitrarily big things, even if one_br is True -- Reason: doing so risks exponential behaviour. We simplify a big -- expression, inline it, and simplify it again. But if the -- very same thing happens in the big expression, we get -- exponential cost! -- PRINCIPLE: when we've already simplified an expression once, -- make sure that we only inline it if it's reasonably small. && (not in_lam || -- Outside a lambda, we want to be reasonably aggressive -- about inlining into multiple branches of case -- e.g. let x = <non-value> -- in case y of { C1 -> ..x..; C2 -> ..x..; C3 -> ... } -- Inlining can be a big win if C3 is the hot- spot, even if -- the uses in C1, C2 are not 'interesting' -- An example that gets worse if you add int_cxt here is 'clausify' }}} What is particularly annoying in this case is that `x` is used in all code paths, so all this inlining simply duplicates code while gaining nothing. Moreover, if we had {{{ let x = blah in case y of A -> ...x... B -> ..x..x... C -> }}} then the multiple uses of `x` in the `B` branch would disable this entire `preInlineUnconditionally` thing, even though it might be a good idea to push the allocation of `x` into the `A` and `B` branches, to avoid the `C` code path. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13316> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13551: Support DEPRECATED and WARNING pragmas on Template Haskell
by GHC 24 Apr '17

24 Apr '17

#13551: Support DEPRECATED and WARNING pragmas on Template Haskell -------------------------------------+------------------------------------- Reporter: utdemir | Owner: (none) Type: feature | Status: new request | Priority: low | Milestone: Component: Template | Version: 8.0.1 Haskell | 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'm writing TH function from some JSON spec to Haskell data structures. Some fields are marked as deprecated in the spec, therefore I want to mark the accessors to those fields with DEPRECATED pragma, but as far as I can see, TH does not support this. I'm aware that module level DEPRECATED pragma is impossible in TH, but I still want to be able to tag top-level attributes as DEPRECATED. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13551> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13593: Unexpected behavior from Data.List.groupBy
by GHC 24 Apr '17

24 Apr '17

#13593: Unexpected behavior from Data.List.groupBy -------------------------------------+------------------------------------- Reporter: dsf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 8.0.1 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I was hoping that {{{#!hs let notBoth1 a b = not (a == 1 && b == 1) in groupBy notBoth1 [1,1,2,3,1,1,4,5,6,1] }}} would give me {{{ [[1],[1,2,3,1],[1,4,5,6,1]] }}} but instead I get {{{ [[1],[1,2,3],[1],[1,4,5,6],[1]] }}} It seems that groupBy assumes transitivity in the argument function. I have a new implementation that does not make this assumption. Of course, the implications of changing this function's behavior are troubling. {{{#!hs groupBy' :: (a -> a -> Bool) -> [a] -> [[a]] groupBy' p (x : xs) = go [x] xs where go (x : xs) (y : zs) | p x y = go (y : x : xs) zs go g (y : zs) = reverse g : go [y] zs go g [] = [reverse g] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13593> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

Re: [GHC] #5553: sendWakeup error in simple test program with MVars and killThread
by GHC 24 Apr '17

24 Apr '17

#5553: sendWakeup error in simple test program with MVars and killThread -------------------------------------+------------------------------------- Reporter: bit | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Incorrect result | Test Case: at runtime | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 7.4.2 => 8.2.2 Comment: We should fix this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5553#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5553: sendWakeup error in simple test program with MVars and killThread
by GHC 24 Apr '17

24 Apr '17

#5553: sendWakeup error in simple test program with MVars and killThread -------------------------------------+------------------------------------- Reporter: bit | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 7.4.2 Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Incorrect result | Test Case: at runtime | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Feuerbach): A few of us at nstack have been getting this error lately with ghc 8.0.2. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5553#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11384: Error says to fix incorrect return type
by GHC 24 Apr '17

24 Apr '17

#11384: Error says to fix incorrect return type -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: GADTs | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Defining a constructor that returns the wrong type (non-parent type). If the constructor is not fully-applied or over-saturated GHC reports an error, instead of telling the developer to change the return type: {{{ Prelude> data A Prelude> data B a where MkB :: A () <interactive>:2:23: error: • Expecting one fewer argument to ‘A’ Expected kind ‘* -> *’, but ‘A’ has kind ‘*’ • In the type ‘A ()’ In the definition of data constructor ‘MkB’ In the data declaration for ‘B’ }}} Expected: 1. Suggest GADTs: {{{ • Illegal generalised algebraic data declaration for ‘B’ (Use GADTs to allow GADTs) • In the data declaration for ‘B’ }}} 2. Complain about incorrect return type: {{{ • Data constructor ‘MkB’ returns type ‘A’ instead of an instance of its parent type ‘B a’ • In the definition of data constructor ‘MkB’ In the data type declaration for ‘B’ }}} It shouldn't suggest the user fix the incorrect return type -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11384> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #1330: Impredicativity bug: Church2 test gives a rather confusing error with the HEAD
by GHC 24 Apr '17

24 Apr '17

#1330: Impredicativity bug: Church2 test gives a rather confusing error with the HEAD -------------------------------------+------------------------------------- Reporter: igloo | Owner: simonpj Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler (Type | Version: 6.7 checker) | Keywords: Resolution: | TypeErrorMessages, | ImpredicativeTypes Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Church2 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: TypeErrorMessages => TypeErrorMessages, ImpredicativeTypes -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1330#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0