March 2013 - ghc-tickets

Re: [GHC] #7557: Default implementation for a type class function missing when profiling is enabled
by GHC 07 Mar '13

07 Mar '13

#7557: Default implementation for a type class function missing when profiling is enabled ---------------------------------+------------------------------------------ Reporter: JohnWiegley | Owner: Type: bug | Status: infoneeded 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: | ---------------------------------+------------------------------------------ Changes (by ezyang): * status: new => infoneeded Comment: GitHub links no longer work! -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7557#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5075: CPR optimisation for sum types if only one constructor is used
by GHC 06 Mar '13

06 Mar '13

#5075: CPR optimisation for sum types if only one constructor is used ---------------------------------+------------------------------------------ Reporter: batterseapower | Owner: simonpj Type: feature request | Status: patch Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.0.3 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by parcs): I noticed that sum CPR does not trigger for this function, when it seems like it should: {{{ loop :: Int -> Maybe Int -> Maybe Int loop n x = case n of 0 -> x _ -> loop (n-1) (fmap (+1) x) }}} The specializations that the SpecConstr pass creates for this function seem to be perfect candidates for sum CPR: {{{ Rec { loop_$s$wloop loop_$s$wloop = \ sc_sop sc1_sor -> case sc_sop of ds_Xmj { __DEFAULT -> loop_$s$wloop (-# ds_Xmj 1) (case sc1_sor of _ { I# x_amE -> I# (+# x_amE 1) }); 0 -> Just sc1_sor } end Rec } Rec { loop_$s$wloop1 loop_$s$wloop1 = \ sc_soq -> case sc_soq of ds_Xmj { __DEFAULT -> loop_$s$wloop1 (-# ds_Xmj 1); 0 -> Nothing } end Rec } }}} Or am I mistaken? -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5075#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7742: StandaloneDeriving on Read fails for GADTs
by GHC 06 Mar '13

06 Mar '13

#7742: StandaloneDeriving on Read fails for GADTs --------------------------------------+------------------------------------- Reporter: hoffstaetter | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: Os: MacOS X | Architecture: Unknown/Multiple Failure: GHC rejects valid program | Blockedby: Blocking: | Related: --------------------------------------+------------------------------------- Consider the following code that derives a Read instance for a GADT datatype: {{{ data Foo a where Foo :: Show a => a -> Foo a deriving instance Show (Foo a) }}} The above code works correctly. However, changing the "Show" constraint to "Read" will cause GHC to fail: {{{ data Foo a where Foo :: Read a => a -> Foo a deriving instance Read (Foo a) }}} with the error message: {{{ No instance for (Read a) arising from a use of `GHC.Read.readPrec' In the first argument of `Text.ParserCombinators.ReadPrec.step', namely `GHC.Read.readPrec' In a stmt of a 'do' block: a1 <- Text.ParserCombinators.ReadPrec.step GHC.Read.readPrec In the second argument of `Text.ParserCombinators.ReadPrec.prec', namely `do { Text.Read.Lex.Ident "Foo" <- GHC.Read.lexP; a1 <- Text.ParserCombinators.ReadPrec.step GHC.Read.readPrec; return (Foo a1) }' When typechecking the code for `GHC.Read.readPrec' in a standalone derived instance for `Read (Foo a)': To see the code I am typechecking, use -ddump-deriv }}} A workaround is to place an additional Read constraint on the deriving clause: {{{ data Foo a where Foo :: Read a => a -> Foo a deriving instance Read a => Read (Foo a) }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7742> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #4081: Strict constructor fields inspected in loop
by GHC 05 Mar '13

05 Mar '13

#4081: Strict constructor fields inspected in loop ---------------------------------+------------------------------------------ Reporter: rl | Owner: benl Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 6.13 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime performance bug Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by bgamari): * version: => 6.13 -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4081#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4081: Strict constructor fields inspected in loop
by GHC 05 Mar '13

05 Mar '13

#4081: Strict constructor fields inspected in loop ---------------------------------+------------------------------------------ Reporter: rl | Owner: benl Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler | Version: Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime performance bug Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by bgamari): * cc: bgamari@… (added) * version: 6.13 => Comment: Any progress on the regression test? -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4081#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7465: ./configure --with--ffi-libraries: ld cannot find libffi in a non-standard location
by GHC 05 Mar '13

05 Mar '13

#7465: ./configure --with--ffi-libraries: ld cannot find libffi in a non-standard location --------------------------------+------------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: patch Priority: normal | Component: Build System Version: 7.7 | Keywords: Os: Linux | Architecture: Unknown/Multiple Failure: Building GHC failed | Blockedby: Blocking: | Related: #5743 --------------------------------+------------------------------------------- Changes (by trommler): * status: new => patch Comment: attachment:0001-Record-libffi-directory-in-rts-package-conf-cf.-7465.patch adds a {{{library-dirs}}} entry to rts package conf. This is necessary because {{{--with-system-libffi}}} libffi is an external library that needs to be linked with too. attachment:0002-Add-L-flags-to-libs.depend-fixes-7465.patch adds -L flags for all {{{library-dirs}}} to {{{libs.depend}}} so libffi and other libraries (e.g. PAPI) can be found when those libraries are installed in directories that are not on the linker path. As I had quite long paths {{{ghc-pkg}}} decided to add newlines, so I had to get rid of those first using {{{tr}}}. I wonder if that could also be an issue for computing the -l flags if there were more libraries than fit on one line. The regexp in the second {{{sed}}} command does not handle spaces in directory names correctly, but I feel that won't be an issue on most Linux installations. If you disagree please let me know what you want me to do. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7465#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7340: Building fails with dph-base_dist-install_GHCI_LIB not defined
by GHC 04 Mar '13

04 Mar '13

#7340: Building fails with dph-base_dist-install_GHCI_LIB not defined -------------------------------+-------------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Component: Build System Version: 7.7 | Resolution: worksforme Keywords: | Os: MacOS X Architecture: x86_64 (amd64) | Failure: Building GHC failed Testcase: | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Comment(by ezyang): Might be http://www.haskell.org/pipermail/cvs- ghc/2011-November/068332.html -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7340#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5014: canonicalizePath throws exception on paths that do not exist
by GHC 04 Mar '13

04 Mar '13

#5014: canonicalizePath throws exception on paths that do not exist ----------------------------------+----------------------------------------- Reporter: hesselink | Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: libraries/directory | Version: 7.0.2 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime crash | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: ----------------------------------+----------------------------------------- Changes (by igloo): * difficulty: => Unknown Comment: I think that what I put in the grey box above documents the current state. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5014#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5609: Type checking arrow notation in the presence of deferred constraints
by GHC 04 Mar '13

04 Mar '13

#5609: Type checking arrow notation in the presence of deferred constraints --------------------------------------+------------------------------------- Reporter: dreixel | Owner: ross Type: bug | Status: closed Priority: low | Milestone: 7.6.2 Component: Compiler (Type checker) | Version: 7.3 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: --------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: Right this is fixed. We don't really have a test-case that exercises the snazzy capabilities, but it all looks right now, and existing regression tests pass. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5609#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5333: Arrow command combinators and infixr cause the desugarer to fail
by GHC 04 Mar '13

04 Mar '13

#5333: Arrow command combinators and infixr cause the desugarer to fail ----------------------------------+----------------------------------------- Reporter: peteg | Owner: ross Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler (Parser) | Version: 7.0.3 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: GHC rejects valid program Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ----------------------------------+----------------------------------------- Changes (by simonpj): * difficulty: => Unknown Comment: The major refactorings are now in place to let us fix this ticket. In particular, * #7071 does the data type refactoring * #5609 does the type checker refactoring Completing the move away from "syntax tables" should be straightforward. I'm happy to advise. Simon -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5333#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0