- ghc-tickets - Haskell.org

[GHC] #10830: maximumBy has a space leak
by GHC 05 Mar '17

05 Mar '17

#10830: maximumBy has a space leak -------------------------------------+------------------------------------- Reporter: | Owner: NeilMitchell | Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.10.2 libraries/base | Keywords: | Operating System: Windows Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Given the program: {{{#!hs import Data.List main = print $ maximumBy compare [1..10000] }}} Compiling with {{{-O2}}}, on GHC 7.8.3 this runs in constant stack space (works fine with {{{+RTS -K1K}}}). With GHC 7.10.2 I get: {{{ $ ghc --make Test.hs -O2 -rtsopts [1 of 1] Compiling Main ( Test.hs, Test.o ) Linking Test.exe ... $ Test +RTS -K100K Stack space overflow: current size 33680 bytes. Use `+RTS -Ksize -RTS' to increase it. }}} Not sure why it's failing at 33K instead of 100K, but it's certainly taking more than 1K as GHC 7.8.3 did. See #3416 for previous discussion of this issue. My guess is that in older versions of GHC the strictness analysis managed to kick in and optimise things. With the burnt bridges that no longer works. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10830> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 33

[GHC] #13353: foldr/nil rule not applied consistently
by GHC 05 Mar '17

05 Mar '17

#13353: foldr/nil rule not applied consistently -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I just had a project where it made a difference whether I add {{{ {-# RULES "foldr/nil" forall k n . GHC.Base.foldr k n [] = n #-} }}} to my file or not, despite this rule already being present in the library. I tried to minimize the problem and came up with this: {{{#!hs foo1 (f, fs) (x, xs) = (f x, map ($x) fs ++ map f xs) foo2 f fs x xs = (f x, map ($x) fs ++ map f xs) test1 x xs = foo1 (id, []) (x, xs) test2 x xs = foo2 id [] x xs test3 x xs = (id x, map ($x) [] ++ map id xs) }}} `test2` and `test3` nicely optimize the `map … [] ++` away, but `test` does not. (In this minimized example, adding the rule again locally does *not* help, but there is still something fishy.) Also, in all cases, `map id` remains, which should not be the case. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13353> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13374: Let exprSize ignore case analysis
by GHC 05 Mar '17

05 Mar '17

#13374: Let exprSize ignore case analysis -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 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: -------------------------------------+------------------------------------- This came out of a discussion at #1335, where Simon says: > > So it seems that after splitting the function into two pieces, it is small enough(?) so that both pieces inline? > > Yes that is galling I agree. > > * Part of the trouble is that strictness analysis does a deep semantic analysis, pulls all the evals to the top, inlines them unconditionally, leaving behind a worker that may now be a lot smaller. The sizeExpr code in CoreUnfold is necessarily much simpler. > > * The discount we award for a scrutinised argument is computed in size_up here: > > {{{ > alts_size (SizeIs tot tot_disc tot_scrut) > -- Size of all alternatives > (SizeIs max _ _) > -- Size of biggest alternative > = SizeIs tot (unitBag (v, 20 + tot - max) > `unionBags` tot_disc) tot_scrut > }}} > > For a single-alternative case (and you have a tuple arg here) tot = max, so there's fixed discount of 20. You could make that into a controllable flag and try varying it. > > * Idea. If a function starts with case x of blah (even if wrapped in lets) we know that the strictness analyser will find it strict in x. So we know it'll generate a wrapper, and the wrapper will inline. So in the end it'll be as if that case cost nothing at all. It would not be hard to make sizeExpr simply count zero for the cost of such cases; including nested. (Certainly for single-alternative ones.) > > Worth a try? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13374> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11421: adding a PartialTypeSignatures to a binding affected by MonoLocalBinds leads compile-time failure
by GHC 04 Mar '17

04 Mar '17

#11421: adding a PartialTypeSignatures to a binding affected by MonoLocalBinds leads compile-time failure -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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: -------------------------------------+------------------------------------- See attached file. I think both type signatures for xs should work. The ghci error unfortunately doesn't show up on :reload, but it shows up when trying to run an unrelated function (main here). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11421> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13340: Core top-level bindings no longer deduplicated
by GHC 04 Mar '17

04 Mar '17

#13340: Core top-level bindings no longer deduplicated -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: new Priority: high | 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: -------------------------------------+------------------------------------- This module {{{#!hs module Two where f :: Int -> Int f n = n + 1 + 1 g :: Int -> Int g n = n + 1 + 1 }}} used to (in 8.0) optimize to a definition of `g` plus `f = g`. The Common sub-expression phase noticed `f` and `g` were equal. That doesn't happen any more in HEAD and we end up with two copies of the code. The Common sub-expression pass apparently still runs, it just doesn't succeed in removing one of the bindings. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13340> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #12441: Conflicting definitions error does not print explicit quantifiers when necessary
by GHC 04 Mar '17

04 Mar '17

#12441: Conflicting definitions error does not print explicit quantifiers when necessary -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- {{{ -- Y.hs-boot {-# LANGUAGE ScopedTypeVariables #-} module Y where f :: forall a b. (a, b) -- YY.hs module YY where import {-# SOURCE #-} Y -- Y.hs {-# LANGUAGE ScopedTypeVariables #-} module Y where import YY f :: forall b a. (a, b) f = undefined }}} I get the following unhelpful error: {{{ ezyang@sabre:~$ ghc-8.0 --make Y.hs -fforce-recomp [1 of 3] Compiling Y[boot] ( Y.hs-boot, Y.o-boot ) [2 of 3] Compiling YY ( YY.hs, YY.o ) [3 of 3] Compiling Y ( Y.hs, Y.o ) Y.hs-boot:3:1: error: Identifier ‘f’ has conflicting definitions in the module and its hs-boot file Main module: f :: (a, b) Boot file: f :: (a, b) The two types are different }}} Yes this example is purposely shooting itself in the foot, but in the wild I encountered an un-annotated type which inferred a different quantifier ordering than what I expected, and I subsequently spent a while puzzling over the error message. `-fprint-explicit-foralls` is a sufficient workaround. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12441> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] Trac email verification for user: dmm
by GHC 03 Mar '17

03 Mar '17

Please visit the following URL to confirm your email address. Verification URL: <http://ghc.haskell.org/trac/ghc/verify_email?verify=1&token=Z0ffZZV7> Username: dmm Verification Token: Z0ffZZV7 -- GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12429: Pattern synonym parse error should recommend enabling extension
by GHC 03 Mar '17

03 Mar '17

#12429: Pattern synonym parse error should recommend enabling extension -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.3 Keywords: pattern | Operating System: Unknown/Multiple synonym error messages | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently, if you try to use pattern synonyms in a module without -XPatternSynonyms, you can get a very uninformative parse error. For example: {{{#!hs module X where import Data.Text (pattern Y) x = 3 }}} Yields, when compiled on GHC 7.10, {{{ test.hs:3:27: parse error on input "Y" }}} It would be helpful if in addition to the error, the message suggested to the user to enable the PatternSynonyms extension, as many other error messages already do. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12429> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #12811: GHC tells me to use RankNTypes when it's already enabled
by GHC 03 Mar '17

03 Mar '17

#12811: GHC tells me to use RankNTypes when it's already enabled -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I was stumped for a while today because GHC kept telling me to turn on `RankNTypes` even when it was already enabled! I eventually realized this was the problem: {{{#!hs {-# LANGUAGE RankNTypes #-} module Bug where foo :: foral a. a -> a foo x = x }}} {{{ $ ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:4:15: error: Illegal symbol '.' in type Perhaps you intended to use RankNTypes or a similar language extension to enable explicit-forall syntax: forall <tvs>. <type> }}} That is, the real culprit was misspelling `forall` as `foral`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12811> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #13347: Abstract classes in hs-boot should not be treated as injective
by GHC 03 Mar '17

03 Mar '17

#13347: Abstract classes in hs-boot should not be treated as injective -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: hs-boot | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- They could be implemented by a newtype (see `mkClass`), making them non- injective. Fortunately, this doesn't seem to cause any unsoundness, because the *constructor* for the newtype corresponding to a class is never in scope, so we are never allowed to unwrap "class newtypes". Phew! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13347> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3