October 2018 - ghc-tickets

[GHC] #15304: Huge increase of compile time and memory use from 8.0.2 to 8.2.2 or 8.4.2
by GHC 06 Oct '18

06 Oct '18

#15304: Huge increase of compile time and memory use from 8.0.2 to 8.2.2 or 8.4.2 -------------------------------------+------------------------------------- Reporter: NathanWaivio | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: Compile-time (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I am the author of the cl3 library on Hackage. I have noticed a huge increase of compile time and memory use when testing 8.2.2 and 8.4.2. ghc-8.0.2 compiled in 4:17.33 using 3.5 GB. ghc-8.2.2 compiled in 26:40.15 using 32.8 GB. This is an increase of 6x in time and 9x in memory. This is not all bad, my nbody benchmark has improved about 35% between ghc-8.0.2 and ghc-8.4.2 so the increased compilation time and memory usage are producing much better runtime performance. I am interested if you could suggest some workarounds to help others compile on systems with less resources. I have 64GB memory in my system and would like to test out some -fno-* GHC Options. Could you point me in the right direction? The library is almost entirely pure functions. I am also interested in other options, like if there are ways to rewrite things to make it easier on the compiler or using NOINLINE on a trouble spot and how to find that trouble spot. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15304> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #12469: Memory fence on writeIORef missing on ARM
by GHC 06 Oct '18

06 Oct '18

#12469: Memory fence on writeIORef missing on ARM ------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Keywords: memory model | Operating System: Unknown/Multiple Architecture: arm | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ------------------------------------+------------------------------------- The memory model question has been debated now and again. his thread from ten years back (https://mail.haskell.org/pipermail/haskell-prime/2006-April/001237.html) lays out the basic situation with thunk update, writeIORef, and memory fences. But we recently began experimenting with GHC on ARM platforms, and it seems to lack a memory fence that the participants in the cited thread expect it to have. Here's an attempt to construct a program which writes fields of a data structure, and then writes the pointer to that structure to an IORef, without the proper fence inbetween: ```Haskell import Data.IORef import Control.Concurrent data Foo = Foo Int deriving Show {-# NOINLINE mkfoo #-} mkfoo x = Foo x {-# NOINLINE dowrite #-} dowrite r n = writeIORef r $! mkfoo n main = do r <- newIORef (Foo 3) forkIO (dowrite r 4) x <- readIORef r print x ``` Here's the relevant bits of the CMM that results when compiled on an ARM 64 machine: ```C mkfoo_rn1_entry() // [] { [] } {offset c40i: P64[MainCapability+872] = P64[MainCapability+872] + 16; if (P64[MainCapability+872] > I64[MainCapability+880]) goto c40m; else goto c40l; c40m: I64[MainCapability+928] = 16; P64[MainCapability+24] = mkfoo_rn1_closure; call (I64[MainCapability+16])(R1) args: 16, res: 0, upd: 8; c40l: I64[P64[MainCapability+872] - 8] = Foo_con_info; P64[P64[MainCapability+872]] = P64[I64[MainCapability+856]]; P64[MainCapability+24] = P64[MainCapability+872] - 7; I64[MainCapability+856] = I64[MainCapability+856] + 8; call (I64[P64[I64[MainCapability+856]]])(R1) args: 8, res: 0, upd: 8; } } ``` ```C dowrite_entry() // [] { [] } {offset c44j: call a_r3Dy_entry() args: 24, res: 0, upd: 8; } } a_r3Dy_entry() // [R1] { [] } {offset c41D: if (I64[MainCapability+856] - 16 < I64[MainCapability+864]) goto c41H; else goto c41I; c41H: P64[MainCapability+24] = a_r3Dy_closure; call (I64[MainCapability+16])(R1) args: 24, res: 0, upd: 8; c41I: I64[I64[MainCapability+856] - 8] = block_c41B_info; P64[I64[MainCapability+856] - 16] = P64[I64[MainCapability+856] + 8]; I64[MainCapability+856] = I64[MainCapability+856] - 16; call mkfoo_rn1_entry() args: 16, res: 8, upd: 8; } } block_c41B_entry() // [R1] { [] } {offset c41B: _s3Ep::P64 = P64[I64[MainCapability+856] + 8]; I64[I64[MainCapability+856] + 8] = block_c41G_info; _s3Es::P64 = P64[MainCapability+24]; P64[MainCapability+24] = _s3Ep::P64; P64[I64[MainCapability+856] + 16] = _s3Es::P64; I64[MainCapability+856] = I64[MainCapability+856] + 8; if (P64[MainCapability+24] & 7 != 0) goto u41S; else goto c41K; u41S: call block_c41G_entry(R1) args: 0, res: 0, upd: 0; c41K: call (I64[I64[P64[MainCapability+24]]])(R1) args: 8, res: 8, upd: 8; } } block_c41G_entry() // [R1] { [] } {offset c41G: _s3Ev::P64 = P64[P64[MainCapability+24] + 7]; P64[_s3Ev::P64 + 8] = P64[I64[MainCapability+856] + 8]; call "ccall" arg hints: [PtrHint, PtrHint] result hints: [] dirty_MUT_VAR(MainCapability+24, _s3Ev::P64); P64[MainCapability+24] = ()_closure+1; I64[MainCapability+856] = I64[MainCapability+856] + 16; call (I64[P64[I64[MainCapability+856]]])(R1) args: 8, res: 0, upd: 8; } } ``` The fence should happen before the write of the pointer into the IORef. I can't find the fence, and can't find a codepath in the compiler that would insert it (i.e. with MO_WriteBarrier). `dirty_MUT_VAR` is actually too late to perform the fence, but it doesn't either: ```C void dirty_MUT_VAR(StgRegTable *reg, StgClosure *p) { Capability *cap = regTableToCapability(reg); if (p->header.info == &stg_MUT_VAR_CLEAN_info) { p->header.info = &stg_MUT_VAR_DIRTY_info; recordClosureMutated(cap,p); } } ``` (Neither does `recordClosureMutated`.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12469> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 33

[GHC] #15713: Bogus -Woverlapping-patterns warning with OverloadedStrings
by GHC 06 Oct '18

06 Oct '18

#15713: Bogus -Woverlapping-patterns warning with OverloadedStrings -------------------------------------+------------------------------------- Reporter: | Owner: (none) quasicomputational | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- {{{ $ cat Test.hs {-# LANGUAGE OverloadedStrings, LambdaCase #-} import Data.String data Expr = App Expr Expr | Var String deriving (Eq) instance IsString Expr where fromString = Var . fromString go = \case App ( App ( App "refWithFile" identM ) filenameM) exceptionMayM -> Just 2 App ( App "and" a ) b -> Just 3 App ( App "or" a ) b -> Just 4 _ -> Nothing go' = \case App ( App ( App "refWithFile" identM ) filenameM) exceptionMayM -> Just 2 App ( App "and" a ) b -> Just 3 _ -> Nothing go'' = \case App ( App ( App (Var "refWithFile") identM ) filenameM) exceptionMayM -> Just 2 App ( App (Var "and") a ) b -> Just 3 App ( App (Var "or") a ) b -> Just 4 _ -> Nothing main = do let expr = App (App "or" "a") "b" print (go expr) print (go' expr) $ runghc-8.4.3 Test.hs Test.hs:13:3: warning: [-Woverlapping-patterns] Pattern match is redundant In a case alternative: App (App "or" a) b -> ... | 13 | App ( App "or" a ) b -> Just 4 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Just 4 Nothing $ runghc-8.6.1 Test.hs Test.hs:13:3: warning: [-Woverlapping-patterns] Pattern match is redundant In a case alternative: App (App "or" a) b -> ... | 13 | App ( App "or" a ) b -> Just 4 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Just 4 Nothing }}} The pattern match checker complains about the `"or"` case of `go` being redundant, but, when it is removed (as it is in `go'`) the output is different. `go''` demonstrates that `OverloadedStrings` is relevant, as that is *not* generating a warning. Removing either of the other two cases of `go` also suppresses the warning: all three are necessary. As seen in the transcript, this is happening on both 8.4.3 and 8.6.1. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15713> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15708: Cross-module SPECIALZE pragmas aren't typechecked in -O0
by GHC 06 Oct '18

06 Oct '18

#15708: Cross-module SPECIALZE pragmas aren't typechecked in -O0 -------------------------------------+------------------------------------- Reporter: regnat | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If a module defines a `SPECIALIZE` pragma for a value defined in another module, then the signature of this pragma won't be typecheck by `ghc -O0` (but it will be if the `SPECIALIZE` pragma is in the same module as the value). For example, given {{{#!hs -- Foo.hs module Foo where foo :: a -> a foo = id ---------- -- Bar.hs module Bar where import Foo {-# SPECIALIZE foo :: Int -> Bool #-} }}} running `ghc --make Bar.hs` will run fine, while `ghc --make -O2 Bar.hs` will complain: {{{ Bar.hs:5:1: error: • Couldn't match type ‘Bool’ with ‘Int’ Expected type: Int -> Int Actual type: Int -> Bool • In the SPECIALISE pragma {-# SPECIALIZE foo :: Int -> Bool #-} | 5 | {-# SPECIALIZE foo :: Int -> Bool #-} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} Tested on ghc 8.6.1 and 8.4.3 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15708> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15653: Both `Ptr a` in SerializedCompact are inaccurate because of the `a`
by GHC 05 Oct '18

05 Oct '18

#15653: Both `Ptr a` in SerializedCompact are inaccurate because of the `a` -------------------------------------+------------------------------------- Reporter: chessai | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: | Version: 8.4.3 libraries/compact | Keywords: ghc-compact, | Operating System: Unknown/Multiple compact regions | Architecture: | Type of failure: Incorrect API Unknown/Multiple | annotation Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{SerializedCompactPtr}}} is defined as: {{{#!hs data SerializedCompact a = SerializedCompact { serializedCompactBlockList :: [(Ptr a, Word)] , serializedCompactRoot :: Ptr a } }}} But, these {{{Ptr a}}} values are a lie, because they don't point to something of type 'a', which makes the documentation for {{{ghc-compact}}} sort of confusing to look at. A more accurate type would just be {{{Addr}}}. The consequences of this being changes to {{{Addr}}} are 1: breaking API changes (though not many people use compact regions) 2: A dependency on primitive would be necessary, though I'm again unsure how big of a deal this is, given that ghc-compact already depends on bytestring. ({{{Addr}}} should probably be moved to base, and re-exported from primitive, which would avoid this issue.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15653> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15707: More liberally kinded coercions for newtypes
by GHC 05 Oct '18

05 Oct '18

#15707: More liberally kinded coercions for newtypes -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #12369 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the infinite data family (possible thanks to #12369): {{{#!hs data family I :: k -> k newtype instance I a = I0 (a) newtype instance I a x = I1 (a x) newtype instance I a x y = I2 (a x y) newtype instance I a x y z = I3 (a x y z) ... }}} We end up with a family of eta-contracted coercions: {{{#!hs forall (a :: *). a ~R I a forall (a :: k -> *). a ~R I a forall (a :: k -> l -> *). a ~R I a forall (a :: k -> l -> m -> *). a ~R I a ... }}} What if we could somehow indicate that we desire a polykinded newtype (so to speak) with a coercion `forall (a :: k). a ~R I a` Maybe even do so by default: `newtype I a = I0 a` would create such a polykinded coercion. Though the `I` data constructor and pattern would still only use the *-kinded restriction of it. We could then recover other constructors with: {{{#!hs i1 :: a x -> I a x i1 = coerce ... }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15707> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #15672: Flags missing documentation.
by GHC 05 Oct '18

05 Oct '18

#15672: Flags missing documentation. -------------------------------------+------------------------------------- Reporter: merijn | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 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 following flags are missing documentation in the flag reference section of the GHC user guide: `-fprint-bind-contents`, `-fprint-evld- with-show`, `-fimplicit-import-qualified`, `-copy-libs-when-linking`, `-Werror=compat`, `-Wwarn=compat`, and `-Wno-error=compat`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15672> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15667: Readonly permissions bits are wrong
by GHC 05 Oct '18

05 Oct '18

#15667: Readonly permissions bits are wrong -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Windows Architecture: | Type of failure: GHC doesn't work Unknown/Multiple | at all Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Unfortunately it seems the mapping for the permission bits for GHC 8.6.1 seem to have gotten screwed up. When installed to a read-only location GHC is no longer working due to it attempting to get write access as well. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15667> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13477: Turn cIntegerLibraryType into a dynflag
by GHC 05 Oct '18

05 Oct '18

#13477: Turn cIntegerLibraryType into a dynflag -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new Priority: low | Milestone: Component: GHC API | 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, at configure time we tell GHC whether integers are built using `integer-gmp` or `integer-simple`, and this gets baked in via the global constant `cIntegerLibraryType`. This is all fine for normal use of GHC (the program), but users of ghc (the library) might want to have more leeway here. A good solution seems to be turn this into a dynflag setting, so that users of the GHC API can adjust that as fit. From a cursory glance at the code, this does not seem to be a big problem. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13477> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14899: Significant compilation time regression between 8.4 and HEAD due to coverage checking
by GHC 05 Oct '18

05 Oct '18

#14899: Significant compilation time regression between 8.4 and HEAD due to coverage checking -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Keywords: | Operating System: Unknown/Multiple PatternMatchWarnings | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following program: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} module Bug where data family Sing (z :: k) class SEq k where (%==) :: forall (a :: k) (b :: k). Sing a -> Sing b -> () infix 4 %== data Foo a b c d = A a b c d | B a b c d | C a b c d | D a b c d | E a b c d | F a b c d data instance Sing (z_awDE :: Foo a b c d) where SA :: Sing a -> Sing b -> Sing c -> Sing d -> Sing ('A a b c d) SB :: Sing a -> Sing b -> Sing c -> Sing d -> Sing ('B a b c d) SC :: Sing a -> Sing b -> Sing c -> Sing d -> Sing ('C a b c d) SD :: Sing a -> Sing b -> Sing c -> Sing d -> Sing ('D a b c d) SE :: Sing a -> Sing b -> Sing c -> Sing d -> Sing ('E a b c d) SF :: Sing a -> Sing b -> Sing c -> Sing d -> Sing ('F a b c d) $([d| instance (SEq a, SEq b, SEq c, SEq d) => SEq (Foo a b c d) where (%==) (SA _ _ _ _) (SA _ _ _ _) = () (%==) (SA _ _ _ _) (SB _ _ _ _) = () (%==) (SA _ _ _ _) (SC _ _ _ _) = () (%==) (SA _ _ _ _) (SD _ _ _ _) = () (%==) (SA _ _ _ _) (SE _ _ _ _) = () (%==) (SA _ _ _ _) (SF _ _ _ _) = () (%==) (SB _ _ _ _) (SA _ _ _ _) = () (%==) (SB _ _ _ _) (SB _ _ _ _) = () (%==) (SB _ _ _ _) (SC _ _ _ _) = () (%==) (SB _ _ _ _) (SD _ _ _ _) = () (%==) (SB _ _ _ _) (SE _ _ _ _) = () (%==) (SB _ _ _ _) (SF _ _ _ _) = () (%==) (SC _ _ _ _) (SA _ _ _ _) = () (%==) (SC _ _ _ _) (SB _ _ _ _) = () (%==) (SC _ _ _ _) (SC _ _ _ _) = () (%==) (SC _ _ _ _) (SD _ _ _ _) = () (%==) (SC _ _ _ _) (SE _ _ _ _) = () (%==) (SC _ _ _ _) (SF _ _ _ _) = () (%==) (SD _ _ _ _) (SA _ _ _ _) = () (%==) (SD _ _ _ _) (SB _ _ _ _) = () (%==) (SD _ _ _ _) (SC _ _ _ _) = () (%==) (SD _ _ _ _) (SD _ _ _ _) = () (%==) (SD _ _ _ _) (SE _ _ _ _) = () (%==) (SD _ _ _ _) (SF _ _ _ _) = () (%==) (SE _ _ _ _) (SA _ _ _ _) = () (%==) (SE _ _ _ _) (SB _ _ _ _) = () (%==) (SE _ _ _ _) (SC _ _ _ _) = () (%==) (SE _ _ _ _) (SD _ _ _ _) = () (%==) (SE _ _ _ _) (SE _ _ _ _) = () (%==) (SE _ _ _ _) (SF _ _ _ _) = () (%==) (SF _ _ _ _) (SA _ _ _ _) = () (%==) (SF _ _ _ _) (SB _ _ _ _) = () (%==) (SF _ _ _ _) (SC _ _ _ _) = () (%==) (SF _ _ _ _) (SD _ _ _ _) = () (%==) (SF _ _ _ _) (SE _ _ _ _) = () (%==) (SF _ _ _ _) (SF _ _ _ _) = () |]) }}} It takes significantly longer to compile this program on 8.4 and HEAD: {{{ $ /opt/ghc/8.4.1/bin/ghc --version The Glorious Glasgow Haskell Compilation System, version 8.4.1 $ time /opt/ghc/8.4.1/bin/ghc Bug.hs -fforce-recomp [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) real 0m0.285s user 0m0.236s sys 0m0.036s $ /opt/ghc/head/bin/ghc --version The Glorious Glasgow Haskell Compilation System, version 8.5.20180306 $ time /opt/ghc/head/bin/ghc Bug.hs -fforce-recomp [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) real 0m29.684s user 0m29.656s sys 0m0.060s }}} The reason for this regression is somewhat incidental—it's due to commit ffb2738f86c4e4c3f0eaacf0a95d7326fdd2e383 (`Fix #14838 by marking TH- spliced code as FromSource`). Before that commit, we were supressing pattern-match coverage checking entirely on TH-quoted code. We no longer do this, which means that we coverage-check the TH-quoted instance in that program, which appears to be why it takes so long to compile. This is a serious issue in practice because a good chunk of `singletons`-generated code is of this form, which means that a good amount of code is effectively uncompilable on GHC HEAD now. (See, for instance, this [https://travis- ci.org/goldfirere/singletons/jobs/350483543#L1182 Travis failure] on GHC HEAD.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14899> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9