- ghc-tickets - Haskell.org

[GHC] #8901: (very) bad inline heuristics
by GHC 25 Jan '17

25 Jan '17

#8901: (very) bad inline heuristics ------------------------------------+------------------------------------- Reporter: heisenbug | 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: | ------------------------------------+------------------------------------- I observe a bad case for inlining blowup for the time library. Observed for 7.7, just checked in 7.9. The problem is so bad that the PowerPC32 assembler cannot resolve cross- routine references. (I have no error message at hand, but could try to get one.) Instead here are the stats for x86, with inlining and certain inlining suppressed. The architecture seems irrelevant. {{{ $ file ./libraries/time/dist-install/build/Data/Time/Format.o ./libraries/time/dist-install/build/Data/Time/Format.o: Mach-O object i386 $ ls -l ./libraries/time/dist-install/build/Data/Time/Format.* -rw-r--r-- 1 ggreif staff 61875 Mar 15 16:48 ./libraries/time/dist- install/build/Data/Time/Format.dyn_hi -rw-r--r-- 1 ggreif staff 450864 Mar 15 16:48 ./libraries/time/dist- install/build/Data/Time/Format.dyn_o -rw-r--r-- 1 ggreif staff 61863 Mar 15 16:48 ./libraries/time/dist- install/build/Data/Time/Format.hi -rw-r--r-- 1 ggreif staff 332216 Mar 15 16:48 ./libraries/time/dist- install/build/Data/Time/Format.o }}} With following patch applied: <https://github.com/ggreif/packages- time/commit/83f08b8896b950707a910fed4e30bddb7ee7f52f> I get: {{{ $ ls -l ./libraries/time/dist-install/build/Data/Time/Format.* -rw-r--r-- 1 ggreif staff 10554 Mar 16 00:08 ./libraries/time/dist- install/build/Data/Time/Format.dyn_hi -rw-r--r-- 1 ggreif staff 106832 Mar 16 00:08 ./libraries/time/dist- install/build/Data/Time/Format.dyn_o -rw-r--r-- 1 ggreif staff 10542 Mar 16 00:08 ./libraries/time/dist- install/build/Data/Time/Format.hi -rw-r--r-- 1 ggreif staff 78864 Mar 16 00:08 ./libraries/time/dist- install/build/Data/Time/Format.o }}} The factor is 4.2 for Format.o, Format.dyn_o and 5.8 for the .hi files. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8901> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #13179: Levity-polymorphic data types
by GHC 25 Jan '17

25 Jan '17

#13179: Levity-polymorphic data types -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Core | Version: 8.0.1 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #12708 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I don't know if this belongs as a part of [https://github.com/ghc- proposals/ghc-proposals/pull/30 levity-polymorphic type classes] (#12708) but many data types can be made levity-polymorphic, some have just been added to base: {{{#!hs -- Sum Array# Array# :: Type -> Type data Product :: forall rep. (k -> TYPE rep) -> (k -> TYPE rep) -> (k -> Type) where Pair :: f a -> g a -> (Product f g) a -- Sum Array# Array# :: Type -> Type data Sum :: forall rep. (k -> TYPE rep) -> (k -> TYPE rep) -> (k -> Type) where InL :: f a -> (Sum f g) a InR :: g a -> (Sum f g) a -- Compose Array# [] :: Type -> Type data Compose :: forall rep. (b -> TYPE rep) -> (a -> b) -> (a -> Type) where Compose :: f (g a) -> (Compose f g) a }}} Can you think of other examples? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13179> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12713: Bytes allocated statistic for T10858 differs between Windows and Linux
by GHC 25 Jan '17

25 Jan '17

#12713: Bytes allocated statistic for T10858 differs between Windows and Linux -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | 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: -------------------------------------+------------------------------------- Strangely `T10858` seems to pass without any trouble on 64-bit Linux with its current expected "bytes allocated" statistic of 241MB. Strangely, this test allocates 16% less on 64-bit Windows, {{{ bytes allocated value is too low: (If this is because you have improved GHC, please update the test so that GHC doesn't regress again) Expected T10858(normal) bytes allocated: 241655120 +/-8% Lower bound T10858(normal) bytes allocated: 222322710 Upper bound T10858(normal) bytes allocated: 260987530 Actual T10858(normal) bytes allocated: 203567896 Deviation T10858(normal) bytes allocated: -15.8 % *** unexpected stat test failure for T10858(normal) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12713> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13161: Unexpected error about untouchable variable
by GHC 25 Jan '17

25 Jan '17

#13161: Unexpected error about untouchable variable -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hello! I've got a strange error here. Let's consider the following code: {{{ {-# LANGUAGE RankNTypes #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE TypeFamilies #-} module Main where data X data Expr a = Expr Int type family Sum a b type instance Sum X X = X app :: Expr l -> (Expr l') -> m (Expr (Sum l l')) app = undefined finish :: Builder (Expr l) -> Builder (Expr X) finish = undefined type family Foo (m :: * -> *) :: * -> * class (Monad m, Foo (Foo m) ~ Foo m) => Ctx (m :: * -> *) newtype Builder a = Builder (forall m. Ctx m => m a) f :: Builder (Expr X) -> Builder (Expr X) -> Builder (Expr X) -> Builder (Expr X) f mop ma mb = finish $ Builder $ app (undefined :: (Expr X)) (undefined :: (Expr X)) main :: IO () main = return () }}} it results in error: {{{ UT.hs:24:34: error: • Couldn't match type ‘l0’ with ‘X’ ‘l0’ is untouchable inside the constraints: Ctx m bound by a type expected by the context: Ctx m => m (Expr l0) at UT.hs:24:24-84 Expected type: m (Expr l0) Actual type: m (Expr (Sum X X)) • In the second argument of ‘($)’, namely ‘app (undefined :: Expr X) (undefined :: Expr X)’ In the second argument of ‘($)’, namely ‘Builder $ app (undefined :: Expr X) (undefined :: Expr X)’ In the expression: finish $ Builder $ app (undefined :: Expr X) (undefined :: Expr X) }}} And that's very interesting, because it should (according to my knowledge) not happen. It is caused by the line: `finish $ Builder $ app (undefined :: (Expr X)) (undefined :: (Expr X))`. And we can observe here couple of things. First of all `app :: Expr l -> (Expr l') -> m (Expr (Sum l l'))` and `Sum X X = X`, so `app (undefined :: (Expr X)) (undefined :: (Expr X)) :: Expr X` - and GHC can clearly see it. What is more interesting is that if we put this signature explicitly it works! So If we change the error line to: {{{ ... f mop ma mb = finish $ (Builder $ app (undefined :: (Expr X)) (undefined :: (Expr X)) :: Builder (Expr X) }}} it compiles fine. Another interesting fact is that if I remove the constraint `Foo (Foo m) ~ Foo m` it also compiles fine, which is even more strange. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13161> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13026: RFC functions for sums and products
by GHC 25 Jan '17

25 Jan '17

#13026: RFC functions for sums and products -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: 8.0.1 libraries/base | 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'll ask on the libraries mailing list depending on feedback. Adding these to `Data.Functor.Sum`, `Data.Functor.Product` a la `Control.Arrow` {{{!hs (||||) :: (f a -> b) -> (g a -> b) -> ((Sum f g) a -> b) f |||| g = \case InL fa -> f fa InR ga -> g ga (&&&&) :: (a -> f b) -> (a -> g b) -> (a -> (Product f g) b) (f &&&& g) a = f a `Pair` g a }}} `||||` is used in "Monad transformers and modular algebraic effects: What binds them together" in section 2.4, the names are up for discussion -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13026> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #13123: Regression: TH splice requires TypeInType when it shouldn't
by GHC 24 Jan '17

24 Jan '17

#13123: Regression: TH splice requires TypeInType when it shouldn't -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.0.1 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I discovered this when debugging #13018. This code: {{{#!hs {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TemplateHaskell #-} module Bug where $([d| idProxy :: forall proxy (a :: k). proxy a -> proxy a idProxy x = x |]) }}} Used to compile on GHC 7.10.3: {{{ $ /opt/ghc/7.10.3/bin/ghci -ddump-splices Bug.hs GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:(6,3)-(8,5): Splicing declarations [d| idProxy_avY :: forall proxy_aw0 (a_aw1 :: k_avZ). proxy_aw0 a_aw1 -> proxy_aw0 a_aw1 idProxy_avY x_aw2 = x_aw2 |] ======> idProxy_a3yP :: forall proxy_a3yN (a_a3yO :: k_avZ). proxy_a3yN a_a3yO -> proxy_a3yN a_a3yO idProxy_a3yP x_a3yQ = x_a3yQ Ok, modules loaded: Bug. }}} But on GHC 8.0.2 and HEAD, it's spuriously rejected: {{{ $ /opt/ghc/8.0.2/bin/ghci -ddump-splices Bug.hs GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:(6,3)-(8,5): Splicing declarations [d| idProxy_a13B :: forall proxy_a13D (a_a13E :: k_a13C). proxy_a13D a_a13E -> proxy_a13D a_a13E idProxy_a13B x_a13F = x_a13F |] ======> idProxy_a3LN :: forall k_a3LK proxy_a3LL (a_a3LM :: k_a3LK). proxy_a3LL a_a3LM -> proxy_a3LL a_a3LM idProxy_a3LN x_a3LO = x_a3LO Bug.hs:6:3: error: Type variable ‘k_a3LK’ used in a kind. Did you mean to use TypeInType? the type signature for ‘idProxy_a3LN’ }}} Notice that in GHC 8.0.2, it's explicitly quantifying the `k`! This shouldn't happen, since in the source declaration it was implicit. The culprit is [http://git.haskell.org/ghc.git/blob/13a85211040f67977d2a2371f4087d1d2ebf4de… rep_wc_ty_sig]. It is always explicitly quantifying all type variables, both explicit and implicit. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13123> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #12979: -fspecialise-aggressively is not documented
by GHC 24 Jan '17

24 Jan '17

#12979: -fspecialise-aggressively is not documented -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: newcomer | 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 couldn't find any documentation for `-fspecialise-aggressively`. The flag is explained in `compiler/specialise/Specialise` in the note `[Specialise imported INLINABLE things]` but doesn't appear in the user manual! The flag was introduced in b9e49d3e9580e13d89efd1f779cb76f610e0d6e0. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12979> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #4960: Better inlining test in CoreUnfold
by GHC 24 Jan '17

24 Jan '17

#4960: Better inlining test in CoreUnfold -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.0.1 Resolution: | Keywords: newcomer, | Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Perhaps you could push a branch so that gipeda can pick it up? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4960#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4960: Better inlining test in CoreUnfold
by GHC 24 Jan '17

24 Jan '17

#4960: Better inlining test in CoreUnfold -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.0.1 Resolution: | Keywords: newcomer, | Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alexbiehl): I have refined the above patch in https://github.com/alexbiehl/ghc/commit/e29f88b5d952f2f40f68e2bb49f051b6684… and ran `./validate --testsuite-only --fast` on it It result in longer compile time (about 27-35%) for `T1969` and `T3294` I have no clue why. But both `haddock.base' and `haddock.Cabal` show ~30% less allocations and `T9203' even 57%. I think this is nice. I hope I am on the right track here. {{{ Unexpected stat failures: /var/folders/7n/mkhl20_55n95s7ytnm9b11lw0000gp/T/ghctest-jl0wiuid/test spaces/./perf/compiler/T1969.run T1969 [stat not good enough] (normal) /var/folders/7n/mkhl20_55n95s7ytnm9b11lw0000gp/T/ghctest-jl0wiuid/test spaces/./perf/compiler/T5631.run T5631 [stat too good] (normal) /var/folders/7n/mkhl20_55n95s7ytnm9b11lw0000gp/T/ghctest-jl0wiuid/test spaces/./perf/compiler/T3294.run T3294 [stat not good enough] (normal) /var/folders/7n/mkhl20_55n95s7ytnm9b11lw0000gp/T/ghctest-jl0wiuid/test spaces/./perf/haddock/haddock.base.run haddock.base [stat too good] (normal) /var/folders/7n/mkhl20_55n95s7ytnm9b11lw0000gp/T/ghctest-jl0wiuid/test spaces/./perf/haddock/haddock.Cabal.run haddock.Cabal [stat too good] (normal) /var/folders/7n/mkhl20_55n95s7ytnm9b11lw0000gp/T/ghctest-jl0wiuid/test spaces/./perf/should_run/T5205.run T5205 [stat too good] (normal) /var/folders/7n/mkhl20_55n95s7ytnm9b11lw0000gp/T/ghctest-jl0wiuid/test spaces/./perf/should_run/T9203.run T9203 [stat too good] (normal) peak_megabytes_allocated value is too high: Expected T1969(normal) peak_megabytes_allocated: 68 +/-20% Lower bound T1969(normal) peak_megabytes_allocated: 54 Upper bound T1969(normal) peak_megabytes_allocated: 82 Actual T1969(normal) peak_megabytes_allocated: 87 Deviation T1969(normal) peak_megabytes_allocated: 27.9 % max_bytes_used value is too high: Expected T1969(normal) max_bytes_used: 17285216 +/-15% Lower bound T1969(normal) max_bytes_used: 14692433 Upper bound T1969(normal) max_bytes_used: 19877999 Actual T1969(normal) max_bytes_used: 23225104 Deviation T1969(normal) max_bytes_used: 34.4 % *** unexpected stat test failure for T1969(normal) max_bytes_used value is too high: Expected T3294(normal) max_bytes_used: 52992688 +/-20% Lower bound T3294(normal) max_bytes_used: 42394150 Upper bound T3294(normal) max_bytes_used: 63591226 Actual T3294(normal) max_bytes_used: 64107552 Deviation T3294(normal) max_bytes_used: 21.0 % *** unexpected stat test failure for T3294(normal) bytes allocated value is too low: (If this is because you have improved GHC, please update the test so that GHC doesn't regress again) Expected T5631(normal) bytes allocated: 1077429456 +/-5% Lower bound T5631(normal) bytes allocated: 1023557983 Upper bound T5631(normal) bytes allocated: 1131300929 Actual T5631(normal) bytes allocated: 1006121416 Deviation T5631(normal) bytes allocated: -6.6 % *** unexpected stat test failure for T5631(normal) bytes allocated value is too low: (If this is because you have improved GHC, please update the test so that GHC doesn't regress again) Expected haddock.base(normal) bytes allocated: 32855223200 +/-5% Lower bound haddock.base(normal) bytes allocated: 31212462040 Upper bound haddock.base(normal) bytes allocated: 34497984360 Actual haddock.base(normal) bytes allocated: 22651400376 Deviation haddock.base(normal) bytes allocated: -31.1 % *** unexpected stat test failure for haddock.base(normal) bytes allocated value is too low: (If this is because you have improved GHC, please update the test so that GHC doesn't regress again) Expected haddock.Cabal(normal) bytes allocated: 25478853176 +/-5% Lower bound haddock.Cabal(normal) bytes allocated: 24204910517 Upper bound haddock.Cabal(normal) bytes allocated: 26752795835 Actual haddock.Cabal(normal) bytes allocated: 17772058640 Deviation haddock.Cabal(normal) bytes allocated: -30.2 % bytes allocated value is too low: (If this is because you have improved GHC, please update the test so that GHC doesn't regress again) Expected T5205(normal) bytes allocated: 56208 +/-5% Lower bound T5205(normal) bytes allocated: 53397 Upper bound T5205(normal) bytes allocated: 59019 Actual T5205(normal) bytes allocated: 53360 Deviation T5205(normal) bytes allocated: -5.1 % *** unexpected stat test failure for T5205(normal) bytes allocated value is too low: (If this is because you have improved GHC, please update the test so that GHC doesn't regress again) Expected T9203(normal) bytes allocated: 95451192 +/-5% Lower bound T9203(normal) bytes allocated: 90678632 Upper bound T9203(normal) bytes allocated: 100223752 Actual T9203(normal) bytes allocated: 40617752 Deviation T9203(normal) bytes allocated: -57.4 % *** unexpected stat test failure for T9203(normal) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4960#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13180: Confusing error when hs-boot abstract data implemented using synonym
by GHC 24 Jan '17

24 Jan '17

#13180: Confusing error when hs-boot abstract data implemented using synonym -------------------------------------+------------------------------------- Reporter: ezyang | Owner: 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: -------------------------------------+------------------------------------- This example is a little goofy (that's why I've marked it low priority), but here goes: {{{ -- A.hs-boot module A where data T f :: T -> T -- B.hs module B(f) where import {-# SOURCE #-} A -- A.hs module A(T, f) where import qualified B type T = Int f :: T -> T f x = B.f x }}} When compiled, we get a very interesting error: {{{ ezyang@sabre:~$ ghc-head --make A.hs -fforce-recomp [1 of 3] Compiling A[boot] ( A.hs-boot, A.o-boot ) [2 of 3] Compiling B ( B.hs, B.o ) [3 of 3] Compiling A ( A.hs, A.o ) A.hs-boot:2:1: error: Type constructor ‘T’ has conflicting definitions in the module and its hs-boot file Main module: type T = Int Boot file: abstract T | 2 | data T | ^^^^^^ A.hs-boot:3:1: error: Identifier ‘f’ has conflicting definitions in the module and its hs-boot file Main module: f :: T -> T Boot file: f :: T -> T The two types are different | 3 | f :: T -> T | ^^^^^^^^^^^ }}} The first error is legitimate, but the second is puzzling. I believe the problem has to do with the fact that when we load the hs-boot file for checking, we knot-tie it against itself. Thus, the T referenced in "Boot file" is the one WITHOUT the type synonym unfolding, while the main module *does* have the type synonym unfolding. Pretty-printing is horribly confusing in these situations, so it would be nice if we could give some better guidance here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13180> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0