February 2016 - ghc-tickets

[GHC] #11607: ApplicativeDo easily foiled with `pure`
by GHC 27 Feb '16

27 Feb '16

#11607: ApplicativeDo easily foiled with `pure` -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 (Type checker) | Keywords: ApplicativeDo | 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: -------------------------------------+------------------------------------- `ApplicativeDo` fails to desugar `do` blocks ending with `pure`. For instance, {{{#!hs {-# LANGUAGE ApplicativeDo #-} {-# LANGUAGE GeneralizedNewtypeDeriving #-} newtype MaybeA a = MaybeA (Maybe a) deriving (Show, Functor, Applicative) main = print $ do x <- MaybeA $ Just 42 pure x }}} However, if the final `pure` is changed to `return` things work as expected. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11607> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #11597: Optimize cmpTypeX
by GHC 27 Feb '16

27 Feb '16

#11597: Optimize cmpTypeX -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: task | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- Simon and I observed that we could skip the kind-check in `cmpTypeX` if the type has no casts, which is the vastly common case. I will collect this information while checking the type and omit the kind check if possible. Putting on "highest" priority basically because this is so easy to do. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11597> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11651: Allow plugins to define built-in rules
by GHC 27 Feb '16

27 Feb '16

#11651: Allow plugins to define built-in rules -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- Conal Eliot has an application in which he wants a plugin to add some new `BuiltinRules` to the `mg_rules` of the `ModGuts` of the module being compiled. He needs a built-in rule (which runs some custom code) rather than a vanilla `CoreRule` (which pattern-matches the argument). But then he got a GHC panic {{{ get a GHC panic: “No match in record selector ru_args”. }}} Turns out it comes from these lines in `OccAnal` {{{ imp_rule_edges = foldr (plusVarEnv_C unionVarSet) emptyVarEnv [ mapVarEnv (const maps_to) (exprFreeIds arg `delVarSetList` ru_bndrs imp_rule) | imp_rule <- imp_rules , let maps_to = exprFreeIds (ru_rhs imp_rule) `delVarSetList` ru_bndrs imp_rule , arg <- ru_args imp_rule ] }}} This code is just working out what locally-defined variables should be kept alive by the `mg_rules` for imported Ids. But `BuiltinRules` don't have any `ru_args`. Easy fix: just don't traverse builtin rules in this scan. In Conal's case, the rules that his plugin adds certainly don't mention locally- defined Ids. I'll do this shortly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11651> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8710: Overlapping patterns warning misplaced
by GHC 27 Feb '16

27 Feb '16

#8710: Overlapping patterns warning misplaced -------------------------+------------------------------------------------- Reporter: | Owner: goldfire | Status: new Type: bug | Milestone: Priority: low | Version: 7.7 Component: | Operating System: Unknown/Multiple Compiler | Type of failure: Incorrect warning at Keywords: | compile-time Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- Consider {{{ {-# OPTIONS_GHC -fwarn-overlapping-patterns #-} len [] = 0 len (_:t) = 1 + len t len _ = error "urk" }}} GHC reports the problem with this definition at the first line of it. I think it would be more helpful to have it at the last line, which is the pattern that will never match. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8710> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #9917: ddump-llvm runs opt/llc even when -fllvm isnt set
by GHC 27 Feb '16

27 Feb '16

#9917: ddump-llvm runs opt/llc even when -fllvm isnt set -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- to reproduce put {{{ main= putStrLn "hello world" }}} in hello.hs and then invoke `ghc hello.hs -O2 -v3 -fforce-recomp -ddump-llvm` then at some point you'll see something like {{{ *** LLVM Optimiser: opt-3.4 /var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T/ghc88460_0/ghc88460_2.ll -o /var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T/ghc88460_0/ghc88460_4.bc -O2 '--enable-tbaa=true' *** LLVM Compiler: llc-3.4 -O2 '-relocation-model=pic' /var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T/ghc88460_0/ghc88460_4.bc -o /var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T/ghc88460_0/ghc88460_5.lm_s '--enable-tbaa=true' '-mattr=+sse2' *** LLVM Mangler: }}} in the output -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9917> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11619: GHC.Stats documentation error
by GHC 27 Feb '16

27 Feb '16

#11619: GHC.Stats documentation error -------------------------------------+------------------------------------- Reporter: orion | Owner: Type: bug | Status: new Priority: low | Milestone: Component: | Version: 7.10.3 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: -------------------------------------+------------------------------------- The [https://hackage.haskell.org/package/base-4.8.2.0/docs/GHC- Stats.html#t:GCStats documentation] for GCStats is not formatted properly: {{{ numByteUsageSamples :: !Int64 Number of byte usage samples taken | Sum of all byte usage samples, can be used with numByteUsageSamples to calculate averages with arbitrary weighting (if you are sampling this record multiple times). }}} {{{ wallSeconds :: !Double Total wall clock time elapsed since start | Number of bytes copied during GC, minus space held by mutable lists held by the capabilities. Can be used with parMaxBytesCopied to determine how well parallel GC utilized all cores. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11619> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11521: Test failures for the `profasm` way when BUILD_PROF_LIBS=YES
by GHC 27 Feb '16

27 Feb '16

#11521: Test failures for the `profasm` way when BUILD_PROF_LIBS=YES -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.11 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: -------------------------------------+------------------------------------- When running `validate --slow`, which also builds libraries the profiling way now (see #11496), a lot of tests are failing for test ways `profasm` and `profthreaded`. To reproduce, set `BUILD_PROF_LIBS=YES` in `mk/build.mk` and run `make` in toplevel directory. Then run: `make test CLEANUP=1 WAY=profasm TEST="T2552 cgrun045 T5626 cgrun051 cgrun016 cgrun059 T2120 T11193 T9078 overflow3 overflow2 overflow1 T10728 T7919 T11049 T5550 conc021 SplicesUsed T5654b-O1 T5654b-O0 T2552 Rules1 T3220 T7837 ColInference3 hpc_fork ffi008 fptrfail01 TH_spliceViewPat overloadedrecfldsrun04 overloadedlabelsrun04 arr004 arr007 arr008 arr003 assert T8089 readFloat stm060 T5628 tough T7411 qq007 qq008 qq009"` (some of the above tests might be failing for other reasons, but most should be about this issue) Here is an example failure: {{{ --- ./codeGen/should_run/cgrun045.stderr.normalised 2016-01-31 16:34:03.831816885 +0100 +++ ./codeGen/should_run/cgrun045.run.stderr.normalised 2016-01-31 16:34:03.831816885 +0100 @@ -1,3 +1,6 @@ cgrun045: hello world! CallStack (from HasCallStack): error, called at cgrun045.hs:<line>:<column> in <package-id>:Main \ No newline at end of file +CallStack (from -prof): + Main.main (cgrun045.hs:6:1-52) + Main.CAF (<entire-module>) \ No newline at end of file *** unexpected failure for cgrun045(profasm) }}} Is this expected behavior? The double callstacks look a little weird to me. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11521> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #11585: Overload the static form to reduce verbosity
by GHC 27 Feb '16

27 Feb '16

#11585: Overload the static form to reduce verbosity -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: feature | Status: new request | Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- Static pointers are rarely used naked: most often they are defined at the base of a {{{Closure}}}, as defined in e.g. the {{{distributed-closure}}} and {{{distributed-static}}} packages. So a typical usage pattern is: {{{ distributeMap (closure (static (\x -> x * 2))) }}} which is more verbose than it needs to be. Ideally we'd just have to write {{{ distributeMap (static (\x -> x * 2)) }}} and let the static pointer be lifted to a {{{Closure}}} implicitly. i.e. what we want is to overload static literals, just like we already overload list literals and string literals. This is achieved by introducing the {{{IsStatic}}} type class and changing the typing rule for static forms slightly: {{{ static (e :: t) :: IsStatic p => p t }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11585> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11601: Strict Haskell is not as strict as it probably should be
by GHC 27 Feb '16

27 Feb '16

#11601: Strict Haskell is not as strict as it probably should be -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- Consider this with `-XStrict` {{{ f y = let Just x = blah[y] in body[y,x] }}} Suppose that in a call to `f`, * `blah` returns `Nothing` * but `body` does not use `x` Should `f` succeed? For sure, `blah` will be evaluated to HNF before `body` is started, but is the match against `Just` done strictly too? According to [http://downloads.haskell.org/~ghc/master/users- guide/glasgow_exts.html#recursive-and-polymorphic-let-bindings our current semantics], in the match against `Just` is ''not'' done strictly, so the call should succeed. I think that’s unexpected and probably wrong. The translation goes like this: {{{ !(Just x) = blah ==> (FORCE) v = blah; Just x = v (and add a seq on v) ==> (SPLIT) v = blah; x = case v of Just x -> x }}} So we finish up with {{{ f y = let v = blah[y] in let x = case v of Just x -> x in v `seq` body[y,x] }}} I don’t think that’s what we intended, because there's a thunk for `x`. If the pattern can fail, I think we want the FORCE rule to say this: {{{ Replace any binding !p = e with v = case e of p -> (v1,..,vn); (v1,..,vn) = v and replace e0 with v seq e0, where v is fresh and v1..vn are the variable(s) bound by p }}} (Compare with the text at the above link.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11601> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #11603: Fix/clarify documentation in GHC.Stats
by GHC 27 Feb '16

27 Feb '16

#11603: Fix/clarify documentation in GHC.Stats -------------------------------------+------------------------------------- Reporter: dcturner | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Core | Version: 8.1 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following were not clear to me until I read the source: `numByteUsageSamples` is (also) the number of major GCs performed. `currentBytesUsed` is the number of live bytes ''at the end of the last major GC''. Is `currentBytesSlop` also at the end of the last major GC? Can't see that it's actually set to anything nonzero anywhere... The comments for `cumulativeBytesUsed` and `parTotBytesCopied` are in the wrong places. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11603> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6