- ghc-tickets - Haskell.org

Re: [GHC] #7670: StablePtrs should be organized by generation for efficient minor collections
by GHC 28 Aug '18

28 Aug '18

#7670: StablePtrs should be organized by generation for efficient minor collections -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): I didn't mention per-capability hash tables, only per-generation. per- capability might be worthwhile to avoid locking overhead, but my nagging concern about all this is that I'm not sure what we're optimising for. Are there any heavy users of StableNames that would benefit from optimisation here, or are people avoiding StableNames because they aren't efficient enough? Or is the main concern implementation complexity? Adding per- generation tables would increase complexity, it's not clear to me that going to per-generation hash tables would result in a simpler implementation, even if the no-stable-table idea was implemented too. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7670#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15557: Reduce type families in equations' RHS when testing equation compatibility
by GHC 28 Aug '18

28 Aug '18

#15557: Reduce type families in equations' RHS when testing equation compatibility -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (Type checker) | Keywords: TypeFamilies | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: #8423 #15546 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The reference I found for closed type families with compatible equations is: https://www.microsoft.com/en-us/research/wp- content/uploads/2016/07/popl137-eisenberg.pdf There in Definition 8 in section 3.4 it states: Definition 8 (Compatibility implementation). The test for compatibility, written compat(p, q), checks that unify(lhsp, lhsq) = Ω implies Ω(rhsp) = Ω(rhsq). If unify(lhsp, lhsq) fails, compat(p, q) holds vacuously. Examine the following families: {{{#!hs type family If (a :: Bool) (b :: k) (c :: k) :: k where If False a b = b If True a b = a type family Eql (a :: k) (b :: k) :: Bool where Eql a a = True Eql _ _ = False type family Test (a :: Maybe k) (b :: Maybe k) :: Maybe k where Test (Just x) (Just y) = If (Eql x y) (Just x) Nothing Test a a = a Test Nothing _ = Nothing Test _ Nothing = Nothing }}} Applying the check to the equations 1 and 2 of `Test` we get: unify(<`Just x`, `Just y`>, <`a`, `a`>) = Ω = [`a` -> `Just x`, `y` -> `x`] Ω(`a`) = `Just x` = `If (Eql x x) (Just x) Nothing` = Ω(`If (Eql x y) (Just x) Nothing`) Therefore the equations must be compatible, and when tidying `forall a. p a -> p (Test a a)` the application should reduce to `forall a. p a -> p a` That doesn't happen: {{{#!hs > :t undefined :: p a -> p (Test a a) p a -> p (Test a a) }}} Examining the IfaceAxBranches (cf #15546) we see: {{{#!hs axiom D:R:Test:: Test a ('Just x) ('Just y) = If (Eql x y) ('Just x) 'Nothing Test k a a = a (incompatible indices: [0]) Test k 'Nothing _ = 'Nothing Test k _ 'Nothing = 'Nothing }}} GHC did not consider the two equations compatible. Digging into why, I came across this ticket: #8423, in which a potentially unbounded (and indefinite) number of type family reductions was necessary to evidence Ω(rhsp) = Ω(rhsq). I don't claim to fully understand goldfire's ticket:8423#comment:10, but the issue is clear: reducing type families while doing a compartibility check might depend on other compatibility checks already being done, including a check depending on itself in which case we are interested in the biggest fixed point (why?). The family here doesn't require any of that special consideration because `Eql x x` reduces right away without any compatibility checks, and `If` is essentially open (indeed making `If` open doesn't help anything). This brings the question: is something like goldfire's described algorithm (or a simplification thereof) something we would like to have in GHC or is that too complex? What is the status on the implementation of that algorithm? P.S: An interesting workaround is adding an `If t c c = c` equation (compatible), and then writing `Test` as: {{{#!hs type family Test (a :: Maybe k) (b :: Maybe k) :: Maybe k where Test (Just x) (Just y) = If (Eql (Just x) (Just y)) (Just x) Nothing Test a a = If (Eql a a) a Nothing Test Nothing a = If (Eql Nothing a) Nothing Nothing Test a Nothing = If (Eql a Nothing) Nothing Nothing }}} This lets GHC discover the necessary equalities without reducing type families, yet erase the workaround'ed type family applications immediately. P.P.S: In ticket:15546#comment:4 I mixed up left and right, it's the RHS that should be/are not reduced. This probably confused SPJ a lot. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15557> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #15573: Make bindings with multiple occurrences a join point instead of duplicating code during inlining.
by GHC 28 Aug '18

28 Aug '18

#15573: Make bindings with multiple occurrences a join point instead of duplicating code during inlining. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: JoinPoints | 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 have some intermediate core of the form: {{{ -- RHS size: {terms: 9, types: 2, coercions: 0, joins: 0/0} cseAlts_s1dD [Occ=Once!T[1]] :: T -> Int# [LclId, CallArity=1, Str=<S,1*U>] cseAlts_s1dD = \ (lamVar_s1dw [Occ=Once!, Dmd=<S,1*U>, OS=OneShot] :: T) -> case lamVar_s1dw of wild_Xc [Dmd=<L,A>] { __DEFAULT -> 1#; B -> 2#; C -> 3# } -- RHS size: {terms: 14, types: 3, coercions: 0, joins: 0/0} $wfmerge_s1cZ [InlPrag=NOUSERINLINE[0]] :: T -> T -> Int# [LclId, Arity=2, CallArity=2, Str=<S,1*U><L,1*U>] $wfmerge_s1cZ = \ (w_s1cU [Occ=Once!, Dmd=<S,1*U>] :: T) (w_s1cV [Occ=Once*, Dmd=<L,1*U>] :: T) -> case w_s1cU of wild_XA [Dmd=<L,A>] { __DEFAULT -> -1#; A -> 2#; B -> cseAlts_s1dD w_s1cV; C -> cseAlts_s1dD w_s1cV } }}} Which after the simplifier ran got inlined into the branches to give us: {{{ fmerge = \ (w_s1cU :: T) (w_s1cV :: T) -> case w_s1cU of { __DEFAULT -> GHC.Types.I# -1#; A -> GHC.Types.I# 2#; B -> case w_s1cV of { __DEFAULT -> GHC.Types.I# 1#; B -> GHC.Types.I# 2#; C -> GHC.Types.I# 3# }; C -> case w_s1cV of { __DEFAULT -> GHC.Types.I# 1#; B -> GHC.Types.I# 2#; C -> GHC.Types.I# 3# } } }}} What I would really like GHC to do instead though is to make `cseAlts_s1dD` a join point when possible. This would eliminate both the call overhead AND the call duplication. The current behavior seems fine when we can't make it a join point. But when we can we should try to take advantage of that opportunity. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15573> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15546: Display coaxiom branch incompatibilities in GHCi
by GHC 28 Aug '18

28 Aug '18

#15546: Display coaxiom branch incompatibilities in GHCi -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Keywords: TypeFamilies, | Operating System: Unknown/Multiple GHCi | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently the only way to figure out how GHC figured out compatibility of branches in a closed type family is to compile it to `.hi` and then sieve through `--show-iface` output. Something as simple this should suffice: {{{#!hs > :i == type family (==) (a :: k) (b :: k) :: Bool where (==) (f a) (g b) = (f == g) && (a == b) (==) a a = 'True -- incompatible with: 0 (==) _1 _2 = 'False -- incompatible with: 0, 1 -- Defined in ‘Data.Type.Equality’ infix 4 == }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15546> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

Re: [GHC] #7741: Add SIMD support to x86/x86_64 NCG
by GHC 27 Aug '18

27 Aug '18

#7741: Add SIMD support to x86/x86_64 NCG -------------------------------------+------------------------------------- Reporter: shelarcy | Owner: abhir00p Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.7 Resolution: | Keywords: SIMD Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #3557 | Differential Rev(s): Wiki Page: wiki:SIMD | -------------------------------------+------------------------------------- Changes (by maoe): * cc: maoe (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7741#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15305: Erroneous "non-exhaustive pattern match" using nested GADT with strictness annotation
by GHC 27 Aug '18

27 Aug '18

#15305: Erroneous "non-exhaustive pattern match" using nested GADT with strictness annotation -------------------------------------+------------------------------------- Reporter: jkoppel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In the following code, `fun` contains an exhaustive pattern match, but, when compiling with -Wall, ghc erroneously reports a non-exhaustive pattern match. {{{#!hs data (:+:) f g a = Inl !(f a) | Inr !(g a) data A data B data Foo l where Foo :: Foo A data Bar l where Bar :: Bar B type Sig = Foo :+: Bar fun :: Sig B -> Int fun (Inr Bar) = 1 }}} This report came from https://stackoverflow.com/questions/16225281/gadts- failed-exhaustiveness-checking . Without strictness annotations, this is indeed a failed exhaustive check, due to bottom. I spoke to Richard Eisenberg at PLDI a few days ago, and he informed me that, if this warning did not disappear with strictness annotations, it was a bug. I added strictness annotations, and it did not disappear. I've tried all combinations of using strictness annotations and/or running with `{-# LANGUAGE Strict #-}`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15305> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #15551: TH-reified type classes have redundant tyvars/class constraints on each method
by GHC 27 Aug '18

27 Aug '18

#15551: TH-reified type classes have redundant tyvars/class constraints on each method -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Template | Version: 8.4.3 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: -------------------------------------+------------------------------------- If you try to reify a type class in Template Haskell, as in the following example: {{{#!hs {-# LANGUAGE TemplateHaskell #-} module Bug where import Language.Haskell.TH class C a where method :: a $(pure []) main :: IO () main = putStrLn $(reify ''C >>= stringE . pprint) }}} You'll discover something strange: {{{ $ /opt/ghc/8.4.3/bin/runghc Bug.hs class Bug.C (a_0 :: *) where Bug.method :: forall (a_0 :: *) . Bug.C a_0 => a_0 }}} Notice how `method` has a completely redundant `forall (a_0 :: *) . Bug.C a_0 =>`! I find this very strange, and would have expected to simply see `Bug.method :: a_0` instead. Currently, I have to work around this oddity by manually stripping off the `forall (a_0 :: *) . Bug.C a_0 =>` myself, but it would be nice if I didn't have to do so. Does this proposal sound reasonable? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15551> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14021: 8.2.1 deb8 bindist fails to install on Windows 10 WSL
by GHC 27 Aug '18

27 Aug '18

#14021: 8.2.1 deb8 bindist fails to install on Windows 10 WSL -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.2 Component: Build System | Version: 8.2.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: -------------------------------------+------------------------------------- In principle the GHC 8.2.1 bindist for Debian 8 should work fine on WSL. However, in practice it fails during `make install` with this error, {{{ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14021> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #8733: I/O manager causes unnecessary syscalls in send/recv loops
by GHC 26 Aug '18

26 Aug '18

#8733: I/O manager causes unnecessary syscalls in send/recv loops ------------------------------------+------------------------------------- Reporter: tibbe | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Network applications often call send followed by recv, to send a message and then read an answer. This causes syscall traces like this one: {{{ recvfrom(13, ) -- Haskell thread A sendto(13, ) -- Haskell thread A recvfrom(13, ) = -1 EAGAIN -- Haskell thread A epoll_ctl(3, ) -- Haskell thread A (a job for the IO manager) recvfrom(14, ) -- Haskell thread B sendto(14, ) -- Haskell thread B recvfrom(14, ) = -1 EAGAIN -- Haskell thread B epoll_ctl(3, ) -- Haskell thread B (a job for the IO manager) }}} The recvfrom call always fails, as the response from the partner we're communicating with won't be available right after we send the request. We ought to consider descheduling the thread as soon as sending is "done". The hard part is to figure out when that is. See http://www.yesodweb.com/blog/2014/02/new-warp for a real world example. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8733> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #15567: security of package environment files
by GHC 26 Aug '18

26 Aug '18

#15567: security of package environment files -------------------------------------+------------------------------------- Reporter: joeyhess | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- ghc will read package environment files owned by other users than the current user, in directories below the current directory. So using ghc in shared directories like /tmp is now a security concern. {{{ joey@darkstar:/tmp/test/sub>ls -l ../../.ghc.environment.x86_64-linux-8.2.2 -rw-r--r-- 1 mail mail 9 Aug 25 15:03 ../../.ghc.environment.x86_64-linux-8.2.2 joey@darkstar:/tmp/test/sub>cat ../.ghc.environment.x86_64-linux-8.2.2 outdated joey@darkstar:/tmp/test/sub>ghc --make foo <command line>: cannot satisfy -package-id outdated (use -v for more information) }}} I suppose this could at least be used to trick ghc into building against an older version of some package that was updated with a security fix. It might be possible to exploit in other ways, perhaps by pointing to a backdoored build of a package? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15567> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4