- ghc-tickets - Haskell.org

Re: [GHC] #5013: sporadic failures during compilation under solaris
by GHC 31 Jan '13

31 Jan '13

#5013: sporadic failures during compilation under solaris ----------------------------+----------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 7.0.4 Resolution: | Keywords: Os: Solaris | Architecture: x86 Failure: Runtime crash | Difficulty: Testcase: | Blockedby: Blocking: | Related: ----------------------------+----------------------------------------------- Comment(by maeder): This problem still happened with ghc-7.6.2 (without chance to reproduce) {{{ Failed to load interface for `GHC.Types' There are files missing in the `ghc-prim' package, try running 'ghc-pkg check'. Use -v to see a list of the files searched for. }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5013#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7297: LLVM incorrectly hoisting loads
by GHC 31 Jan '13

31 Jan '13

#7297: LLVM incorrectly hoisting loads ---------------------------------+------------------------------------------ Reporter: dterei | Owner: dterei Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler (LLVM) | Version: 7.7 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Incorrect result at runtime Difficulty: Unknown | Testcase: 367_letnoescape Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by dterei): http://llvm.org/docs/LangRef.html#i_load LLVM docs on volatile: {{{ Certain memory accesses, such as loads, stores, and llvm.memcpys may be marked volatile. The optimizers must not change the number of volatile operations or change their order of execution relative to other volatile operations. The optimizers may change the order of volatile operations relative to non-volatile operations. This is not Java's "volatile" and has no cross-thread synchronization behavior. }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7297#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7297: LLVM incorrectly hoisting loads
by GHC 31 Jan '13

31 Jan '13

#7297: LLVM incorrectly hoisting loads ---------------------------------+------------------------------------------ Reporter: dterei | Owner: dterei Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler (LLVM) | Version: 7.7 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Incorrect result at runtime Difficulty: Unknown | Testcase: 367_letnoescape Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by dterei): Copying some info from an email (Memory model of Cmm?) with Simon Marlow so I can archive it finally: {{{ The best reference for this is the code I wrote to identify conflicts in the Cmm sinking pass, see the function 'conflicts': http://www.haskell.org/ghc/dist/current/docs/html/libraries/ghc-7.7.2012090… But that won't tell you anything about whether reading a memory location can be cached or not. How does LLVM handle this? I'm thinking that maybe we should have an explicit "volatile load" operation, that would behave like a CmmLoad but could not be hoisted. It should be a CallishMachOp, because you presumably want to specify ordering for a volatile load with respect to other side-effecting operations. }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7297#comment:6> 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 30 Jan '13

30 Jan '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 simonpj): Still to come: the sum-CPR stuff is switched off for '''nested''' functions because it turns some let-no-escape functions into non-let-no- escape ones, which increases allocation. I'm hopeful that Nick F's work on late-lambda-lifting may solve this, in which case we can switch it on more vigorously. Hence leaving open for now. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5075#comment:9> 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 30 Jan '13

30 Jan '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 simonpj@…): commit d3b8991be3875302ca6d1a4ef6e72891e9567dd5 {{{ Author: Simon Peyton Jones <simonpj(a)microsoft.com> Date: Thu Jan 24 14:50:50 2013 +0000 Introduce CPR for sum types (Trac #5075) The main payload of this patch is to extend CPR so that it detects when a function always returns a result constructed with the *same* constructor, even if the constructor comes from a sum type. This doesn't matter very often, but it does improve some things (results below). Binary sizes increase a little bit, I think because there are more wrappers. This with -split-objs. Without split-ojbs binary sizes increased by 6% even for HelloWorld.hs. It's hard to see exactly why, but I think it was because System.Posix.Types.o got included in the linked binary, whereas it didn't before. Program Size Allocs Runtime Elapsed TotalMem fluid +1.8% -0.3% 0.01 0.01 +0.0% tak +2.2% -0.2% 0.02 0.02 +0.0% ansi +1.7% -0.3% 0.00 0.00 +0.0% cacheprof +1.6% -0.3% +0.6% +0.5% +1.4% parstof +1.4% -4.4% 0.00 0.00 +0.0% reptile +2.0% +0.3% 0.02 0.02 +0.0% ---------------------------------------------------------------------- Min +1.1% -4.4% -4.7% -4.7% -15.0% Max +2.3% +0.3% +8.3% +9.4% +50.0% Geometric Mean +1.9% -0.1% +0.6% +0.7% +0.3% Other things in this commit ~~~~~~~~~~~~~~~~~~~~~~~~~~~ * Got rid of the Lattice class in Demand * Refactored the way that products and newtypes are decomposed (no change in functionality) compiler/basicTypes/BasicTypes.lhs | 17 ++ compiler/basicTypes/DataCon.lhs | 60 ----- compiler/basicTypes/Demand.lhs | 429 ++++++++++++++++++----------------- compiler/basicTypes/MkId.lhs | 11 +- compiler/cmm/CLabel.hs | 1 - compiler/coreSyn/CoreLint.lhs | 12 +- compiler/coreSyn/CoreSyn.lhs | 7 +- compiler/deSugar/DsCCall.lhs | 45 ++++- compiler/deSugar/DsForeign.lhs | 2 +- compiler/prelude/PrelRules.lhs | 2 +- compiler/simplCore/Simplify.lhs | 5 +- compiler/specialise/SpecConstr.lhs | 2 +- compiler/stranal/DmdAnal.lhs | 49 +++- compiler/stranal/WwLib.lhs | 210 ++++++++---------- compiler/types/Coercion.lhs | 62 ++++-- compiler/types/FamInstEnv.lhs | 26 +-- compiler/types/TyCon.lhs | 25 ++- compiler/types/Type.lhs | 26 +-- compiler/vectorise/Vectorise/Exp.hs | 10 +- 19 files changed, 515 insertions(+), 486 deletions(-) }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5075#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7472: Build on FreeBSD fails with ncurses
by GHC 30 Jan '13

30 Jan '13

#7472: Build on FreeBSD fails with ncurses ----------------------------------+----------------------------------------- Reporter: nematoder | Owner: pgj Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 7.6.1 Resolution: wontfix | Keywords: ncurses, freebsd Os: FreeBSD | Architecture: Unknown/Multiple Failure: Building GHC failed | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: ----------------------------------+----------------------------------------- Comment(by pgj): Replying to [comment:4 simonmar]: > Would someone like to create a wiki page for FreeBSD under [wiki:Building/Preparation] and put this and any other FreeBSD-specific info there please? Yes, I volunteer for this. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7472#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7472: Build on FreeBSD fails with ncurses
by GHC 30 Jan '13

30 Jan '13

#7472: Build on FreeBSD fails with ncurses ----------------------------------+----------------------------------------- Reporter: nematoder | Owner: pgj Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 7.6.1 Resolution: wontfix | Keywords: ncurses, freebsd Os: FreeBSD | Architecture: Unknown/Multiple Failure: Building GHC failed | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: ----------------------------------+----------------------------------------- Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => wontfix Comment: Sounds like the ticket can be closed then. Would someone like to create a wiki page for FreeBSD under [wiki:Building/Preparation] and put this and any other FreeBSD-specific info there please? -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7472#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7601: Internal error with kind annotation on associated type family
by GHC 30 Jan '13

30 Jan '13

#7601: Internal error with kind annotation on associated type family -----------------------------+---------------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: polykinds Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- The following module: {{{ {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeFamilies #-} module Bug where class C (a :: k) where type F (a :: k) }}} Makes GHC raise an internal error: {{{ GHC internal error: `k' is not in scope during type checking, but it passed the renamer tcl_env of environment: [(reB, AThing forall (k :: BOX). k -> Constraint), (reC, AThing forall (k :: BOX) (k :: BOX). k -> k)] In the kind `k' In the class declaration for `C' }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7601> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #7282: polykinds error: Found `k' but expected `k'
by GHC 30 Jan '13

30 Jan '13

#7282: polykinds error: Found `k' but expected `k' -------------------------------------------------+-------------------------- Reporter: HolgerReinhardt | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.6.1 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC rejects valid program | Difficulty: Unknown Testcase: indexed_types/should_compile/T7282 | Blockedby: Blocking: | Related: -------------------------------------------------+-------------------------- Changes (by simonpj): * status: new => closed * difficulty: => Unknown * resolution: => fixed * testcase: => indexed_types/should_compile/T7282 Comment: Thank you for reporting this -- v helpful. Simon -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7282#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7609: Backticks in an an error message
by GHC 30 Jan '13

30 Jan '13

#7609: Backticks in an an error message ----------------------------------------------+----------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.1 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Incorrect warning at compile-time | Blockedby: Blocking: | Related: ----------------------------------------------+----------------------------- {{{ {-# LANGUAGE TypeOperators #-} data X a b f :: (a `X` a, Maybe) f = undefined }}} gives an error message: {{{ X.hs:4:16: Expecting one more argument to `Maybe' In the type signature for `f': f :: (a X a, Maybe) ^^^^^ }}} which should be {{{a `X` a}}}. The same thing happens in constraints, such as {{{ f :: (a `X` a) => Maybe }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7609> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2