- ghc-tickets - Haskell.org

[GHC] #13896: Use response file to invoke hsc2hs
by GHC 07 Oct '18

07 Oct '18

#13896: Use response file to invoke hsc2hs ----------------------------------------+--------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: hsc2hs | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- We already use response files when invoking Haddock due to Windows command line length limitations. It [[https://github.com/haskell/cabal/issues/3122#issuecomment-311489312|seems]] that we also need to do the same with `hsc2hs`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13896> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #13841: ADOPT pragma for silencing orphan instances warnings per instance
by GHC 07 Oct '18

07 Oct '18

#13841: ADOPT pragma for silencing orphan instances warnings per instance -------------------------------------+------------------------------------- Reporter: cocreature | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- Currently GHC only allows enabling and disabling the warnings about orphan instances on a module level. I’d like to have an ADOPT pragma that allows disabling the warning for specific instance: {{{#!haskell instance {-# ADOPT #-} C Int }}} Apart from disabling the warning about orphan instances for this specific instance, this pragma should have no effect. I already hacked together a [https://github.com/cocreature/ghc/tree/adopt- pragma prototype] and I’m willing to clean that up and submit a diff if other people like this. This does change the surface language but disabling a warning seem too small of an effect for the ghc proposals process (I’m happy to make a proposal if you disagree). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13841> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #2515: Flag to suppress orphan instance warnings
by GHC 07 Oct '18

07 Oct '18

#2515: Flag to suppress orphan instance warnings -------------------------------------+------------------------------------- Reporter: tim | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 6.8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10150 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Lemming): * related: => #10150 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2515#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15714: Compacting StaticPtr of a function doesn't work
by GHC 06 Oct '18

06 Oct '18

#15714: Compacting StaticPtr of a function doesn't work -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- I think we should be able to compact a StaticPtr of a function, but it currently doesn't work. Reproducer: {{{#!haskell {-# LANGUAGE StaticPointers #-} import GHC.StaticPtr import Data.Compact foo :: Int -> Int foo x = x^2 main = do c <- compact (static foo :: StaticPtr (Int -> Int)) return () }}} Output: {{{ ./compact_test compact_test: compaction failed: cannot compact functions }}} Tried with 8.4.3 (compact on hackage doesn't build with 8.6). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15714> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[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