March 2013 - ghc-tickets

Re: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals
by GHC 22 Mar '13

22 Mar '13

#5218: Add unpackCStringLen# to create Strings from string literals ---------------------------------+------------------------------------------ Reporter: tibbe | Owner: igloo Type: feature request | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.0.3 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: 5877 | ---------------------------------+------------------------------------------ Changes (by liyang): * cc: hackage.haskell.org@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5218#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4364: Template Haskell: Cycle in type synonym declarations
by GHC 22 Mar '13

22 Mar '13

#4364: Template Haskell: Cycle in type synonym declarations ----------------------------------------+----------------------------------- Reporter: igloo | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler (Type checker) | Version: 7.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ----------------------------------------+----------------------------------- Changes (by liyang): * cc: hackage.haskell.org@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4364#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4243: Make a proper options parser for the RTS
by GHC 22 Mar '13

22 Mar '13

#4243: Make a proper options parser for the RTS ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: task | Status: new Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 6.13 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by liyang): * cc: hackage.haskell.org@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4243#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3927: Incomplete/overlapped pattern warnings + GADTs = inadequate
by GHC 22 Mar '13

22 Mar '13

#3927: Incomplete/overlapped pattern warnings + GADTs = inadequate ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 6.12.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: #4139 | ---------------------------------+------------------------------------------ Changes (by liyang): * cc: hackage.haskell.org@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3927#comment:30> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4139: Spurious non-exhaustive pattern match warnings are given using GADTs
by GHC 22 Mar '13

22 Mar '13

#4139: Spurious non-exhaustive pattern match warnings are given using GADTs ------------------------------------------------+--------------------------- Reporter: blarsen | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.0.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: GADTs, warnings, pattern matching Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Incorrect warning at compile-time | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: #3927 ------------------------------------------------+--------------------------- Changes (by liyang): * cc: hackage.haskell.org@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4139#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6037: Compile-time crash with sources with non-representable unicode characters
by GHC 22 Mar '13

22 Mar '13

#6037: Compile-time crash with sources with non-representable unicode characters ---------------------------------+------------------------------------------ Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Keywords: | Os: Linux Architecture: Unknown/Multiple | Failure: Compile-time crash Difficulty: Unknown | Testcase: T6037 Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by liyang): * cc: hackage.haskell.org@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6037#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4245: ghci panic: thread blocked indefinitely in an MVar operation
by GHC 22 Mar '13

22 Mar '13

#4245: ghci panic: thread blocked indefinitely in an MVar operation -------------------------------+-------------------------------------------- Reporter: pturnbull | Owner: tibbe Type: bug | Status: new Priority: high | Milestone: 7.6.2 Component: GHCi | Version: 6.12.3 Keywords: MVar | Os: MacOS X Architecture: x86_64 (amd64) | Failure: GHCi crash Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | -------------------------------+-------------------------------------------- Changes (by PHO): * cc: pho@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4245#comment:29> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3333: GHCi doesn't load weak symbols
by GHC 22 Mar '13

22 Mar '13

#3333: GHCi doesn't load weak symbols --------------------------------------+------------------------------------- Reporter: heatsink | Owner: akio Type: bug | Status: patch Priority: normal | Milestone: 7.6.2 Component: GHCi | Version: 6.10.4 Keywords: weak, dynamic loading | Os: Linux Architecture: x86 | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | --------------------------------------+------------------------------------- Changes (by cmears): * cc: chris@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3333#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7520: Implement cardinality analysis
by GHC 21 Mar '13

21 Mar '13

#7520: Implement cardinality analysis ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by nfrisby): SPJ determined that this cardinality analysis could make some fragile fusion opportunities more robust. My experimentation with -fdicts-strict in `nofib/shootout/spectral-norm` was disrupting such a fusion. {{{ let x_aPi = build (\b c n -> eftIntFB c n 0 (...)) -- from "[0..n-1]" in Library.allocaArray n $ \ptr -> foldr (mapFB ...) (...) x_aPi -- from "forM_ ..." }}} If `allocaArray` is not inlined early enough (which my -fdicts-strict tinkering prevented), the `ptr` lambda is not identified as one-shot, so `x_aPi` will not be inlined under it and `foldr/build` won't fire. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7520#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4962: Dead code fed to CorePrep because RULEs keep it alive spuriously
by GHC 21 Mar '13

21 Mar '13

#4962: Dead code fed to CorePrep because RULEs keep it alive spuriously --------------------------------------+------------------------------------- Reporter: batterseapower | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.2.1 Component: Compiler | Version: 7.0.1 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime performance bug | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: --------------------------------------+------------------------------------- Changes (by simonpj): * difficulty: => Unknown Old description: > This ticket is split off from #4941. > > I'm seeing output code that looks roughly like this in the final > simplifier output: > > {{{ > let > {-# RULES go (Just x) = $sgo_s1lg x #-} > go = ... go ... $w$sgo ... > $sgo_s1lg = ... $w$sgo_s1mv ... > $w$sgo_s1mv = ... big ... > in ... $w$sgo_s1mv ... > }}} > > This is bad because $sgo is will be dead for the purposes of code > generation, but currently GHC will allocate a closure for it at runtime > anyway. > > What we should do is drop the dead binding once we have decided that it's > not reachable via the exported RULES in the interface file. > > I've confirmed that this patch achieves this effect (and eliminates the > main source of increased allocations I was seeing in #4941): > > {{{ > hunk ./compiler/main/TidyPgm.lhs 22 > +import OccurAnal ( occurAnalysePgm ) > hunk ./compiler/main/TidyPgm.lhs 43 > +import qualified ErrUtils as Err > hunk ./compiler/main/TidyPgm.lhs 47 > +import PprCore > hunk ./compiler/main/TidyPgm.lhs 322 > + > + -- Occurrence analyse the input program, assuming all local > rules are off, > + -- but retaining any bindings referred to by external rules. > + -- Occurrence information may have improved since the last run > of the > + -- simplifier because some bindings will become dead once > RULES are dropped. > + -- > + -- The analysis itself will take care of dropping any newly- > dead syntax. > + ; Err.dumpIfSet_dyn dflags Opt_D_dump_occur_anal "BEFORE TidyPgm > occurrence analysis" (pprCoreBindings binds) > + ; binds <- return $ occurAnalysePgm Nothing ext_rules binds > + ; Err.dumpIfSet_dyn dflags Opt_D_dump_occur_anal "TidyPgm > occurrence analysis" (pprCoreBindings binds) > + > hunk ./compiler/simplCore/OccurAnal.lhs 393 > - rule_fvs = idRuleVars bndr -- See Note [Rule > dependency info] > + rule_fvs = case occ_rule_act env of Nothing -> emptyVarSet; > Just _ -> idRuleVars bndr -- See Note [Rule dependency info] > + -- FIXME: this is a terrible hack to try to have OccAnal drop > bindings that are kept alive only due to rules at the CoreTidy stage > }}} > > However the patch is a bit horrible: because attached RULES keep bindings > alive in a LetRec even if the rules can never be activated (i.e. > occ_rule_act env == Nothing) the bindings I want to be dropped never get > dropped. The reason I consider my fix a hack is that just because the > rules are inactive *now* doesn't mean that they will be inactive *later*. > > A better approach would perhaps be to wait until the RULES are stripped > from the binders entirely (e.g. OccAnal the output of CoreTidy). However, > this is not straightforward because CoreTidy has globalised Ids, so > OccAnaling the output says that all top level bindings have no FVs and > hence turns all LetRecs into Lets! New description: This ticket is split off from #4941. I'm seeing output code that looks roughly like this in the final simplifier output: {{{ let {-# RULES go (Just x) = $sgo_s1lg x #-} go = ... go ... $w$sgo ... $sgo_s1lg = ... $w$sgo_s1mv ... $w$sgo_s1mv = ... big ... in ... $w$sgo_s1mv ... }}} This is bad because $sgo is will be dead for the purposes of code generation, but currently GHC will allocate a closure for it at runtime anyway. What we should do is drop the dead binding once we have decided that it's not reachable via the exported RULES in the interface file. I've confirmed that this patch achieves this effect (and eliminates the main source of increased allocations I was seeing in #4941): {{{ hunk ./compiler/main/TidyPgm.lhs 22 +import OccurAnal ( occurAnalysePgm ) hunk ./compiler/main/TidyPgm.lhs 43 +import qualified ErrUtils as Err hunk ./compiler/main/TidyPgm.lhs 47 +import PprCore hunk ./compiler/main/TidyPgm.lhs 322 + + -- Occurrence analyse the input program, assuming all local rules are off, + -- but retaining any bindings referred to by external rules. + -- Occurrence information may have improved since the last run of the + -- simplifier because some bindings will become dead once RULES are dropped. + -- + -- The analysis itself will take care of dropping any newly- dead syntax. + ; Err.dumpIfSet_dyn dflags Opt_D_dump_occur_anal "BEFORE TidyPgm occurrence analysis" (pprCoreBindings binds) + ; binds <- return $ occurAnalysePgm Nothing ext_rules binds + ; Err.dumpIfSet_dyn dflags Opt_D_dump_occur_anal "TidyPgm occurrence analysis" (pprCoreBindings binds) + hunk ./compiler/simplCore/OccurAnal.lhs 393 - rule_fvs = idRuleVars bndr -- See Note [Rule dependency info] + rule_fvs = case occ_rule_act env of Nothing -> emptyVarSet; Just _ -> idRuleVars bndr -- See Note [Rule dependency info] + -- FIXME: this is a terrible hack to try to have OccAnal drop bindings that are kept alive only due to rules at the CoreTidy stage }}} However the patch is a bit horrible: because attached RULES keep bindings alive in a !LetRec even if the rules can never be activated (i.e. occ_rule_act env == Nothing) the bindings I want to be dropped never get dropped. The reason I consider my fix a hack is that just because the rules are inactive *now* doesn't mean that they will be inactive *later*. A better approach would perhaps be to wait until the RULES are stripped from the binders entirely (e.g. !OccAnal the output of !CoreTidy). However, this is not straightforward because !CoreTidy has globalised Ids, so OccAnaling the output says that all top level bindings have no FVs and hence turns all !LetRecs into Lets! -- -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4962#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0