- ghc-tickets - Haskell.org

[GHC] #8247: Dependency tracking (--make) broken for re-exported modules
by GHC 01 Oct '13

01 Oct '13

#8247: Dependency tracking (--make) broken for re-exported modules ------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Say, I re-export a module, from which I hide some bindings: {{{ module B (module A) where import A hiding (a1) }}} where `A` is defined thus: {{{ module A where a1 = 5 a2 = 42 a3 = 113 }}} I use `B` from `C`: {{{ module C where import B a2 = 142 }}} Build `C`, with `ghc --make C.hs`, observing redefinition error (of `a2`). Now hide also `a2` in `B` like this (by editing `B.hs`): {{{ module B (module A) where import A hiding (a1, a2) }}} Build `C` again, and observe that the error persists, because `B` has not been rebuilt, and its interface file not regenerated. Deleting `B.hi` and recompiling resolves the situation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8247> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #7783: MultiWayIf should start a new layout
by GHC 01 Oct '13

01 Oct '13

#7783: MultiWayIf should start a new layout --------------------------------------+------------------------------------ Reporter: exbb2 | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler (Parser) | Version: 7.6.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #4359 --------------------------------------+------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => fixed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7783#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7783: MultiWayIf should start a new layout
by GHC 01 Oct '13

01 Oct '13

#7783: MultiWayIf should start a new layout --------------------------------------+------------------------------------ Reporter: exbb2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler (Parser) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #4359 --------------------------------------+------------------------------------ Comment (by Simon Marlow <marlowsd@…>): In [changeset:aab65608f9a26990b2c5083e4b65b9d1f6c9b48a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="aab65608f9a26990b2c5083e4b65b9d1f6c9b48a" Add layout to MultiWayIf (#7783) This makes it possible to write x = if | False -> if | False -> 1 | False -> 2 | True -> 3 Layout normally inserts semicolons between declarations at the same indentation level, so I added optional semicolons to the syntax for guards in MultiWayIf syntax. This is a bit of a hack, but the alternative (a special kind of layout that doesn't insert semicolons) seemed worse, or at least equally bad. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7783#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8377: GHCi crashes with unboxed values on 32-bit platforms
by GHC 01 Oct '13

01 Oct '13

#8377: GHCi crashes with unboxed values on 32-bit platforms ---------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: x86 | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ---------------------------+------------------------------------- The following program causes GHCi to crash, on x86 Linux and x86 Windows. {{{ {-# LANGUAGE MagicHash #-} import System.Mem import GHC.Base main = do let list = concatMap buildThunk [0..10000] length list `seq` performGC print $ last list buildThunk :: Int -> [Int] buildThunk (I# k) = [f k] f :: Int# -> Int f x = I# x }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8377> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #7993: ghc 7.6 (not 7.4) sometimes hangs at child process exit on s390x
by GHC 01 Oct '13

01 Oct '13

#7993: ghc 7.6 (not 7.4) sometimes hangs at child process exit on s390x -----------------------------------+--------------------------- Reporter: cjwatson | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: Other Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+--------------------------- Comment (by simonmar): Getting a stack trace would probably help. You want to make sure that GHC itself is built with `-debug`: set `GhcDebugged=YES` in your build.mk (this will slow down the build, but you can remove it later). When the process hangs, attach to it with gdb and get a backtrace of all the threads. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7993#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7753: Profiling report broken with foreign exported functions
by GHC 01 Oct '13

01 Oct '13

#7753: Profiling report broken with foreign exported functions ---------------------------------+------------------------------------ Reporter: akio | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Profiling | Version: 7.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Changes (by akio): * status: new => patch Comment: I'm not sure if this is the best way to fix it, but the attached patch improves the output; now {{{wrapper}}} and {{{f}}} are placed directly under {{{MAIN}}}, and they get {{{inherited}}} costs correctly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7753#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7753: Profiling report broken with foreign exported functions
by GHC 01 Oct '13

01 Oct '13

#7753: Profiling report broken with foreign exported functions ---------------------------------+------------------------------------ Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Profiling | Version: 7.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Comment (by akio): I think I know what is happening. The {{{wrapper}}} and {{{f}}} cost centres are actually placed under {{{SYSTEM}}}. I can see it by using {{{+RTS -pa}}} instead of {{{+RTS -p}}}. However {{{SYSTEM}}} is a hidden cost centre, so by default it's not included in the report, resulting in a confusing call tree. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7753#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8129: Constraint solver panic when -ddump-tc-trace is used
by GHC 01 Oct '13

01 Oct '13

#8129: Constraint solver panic when -ddump-tc-trace is used -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.7 checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: Compile-time Architecture: Unknown/Multiple | crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- {{{ {-# LANGUAGE MultiParamTypeClasses, TypeFamilies #-} {-# OPTIONS_GHC -ddump-tc-trace #-} type family F (x :: *) :: * class (y ~ F x) => C x y z = () :: C x y => () }}} causes a panic while tracing the typechecker: {{{ solveNestedImplications starting { original inerts = Equalities: Type-function equalities: [D] _ :: F x_aeH ~ y_aeI (CFunEqCan) Dictionaries: [W] $dC_aeK :: C x_aeH y_aeI (CDictCan) Irreds: Insolubles = {} Solved dicts 0 Solved funeqs 0 thinner_inerts = Equalities:ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20130812 for i386-unknown-linux): No match in record selector ctev_evar }}} If `-ddump-tc-trace` is not used, the correct constraint solving error is generated: {{{ Could not deduce (C x0 y0) arising from the ambiguity check for an expression type signature from the context (C x y) bound by an expression type signature: C x y => () }}} It seems that `prepareInertsForImplications` in `TcSMonad` assumes that all the `inert_funeqs` are givens or wanteds; if there are some deriveds, then the above panic results. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8129> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

Re: [GHC] #5928: INLINABLE fails to specialize in presence of simple wrapper
by GHC 01 Oct '13

01 Oct '13

#5928: INLINABLE fails to specialize in presence of simple wrapper -------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by liyang): * cc: hackage.haskell.org@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5928#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8389: Building GHC 7.7 fails at haddock step
by GHC 30 Sep '13

30 Sep '13

#8389: Building GHC 7.7 fails at haddock step ----------------------------------+---------------------------------------- Reporter: dsamperi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: | Type of failure: Building GHC failed Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ----------------------------------+---------------------------------------- Building GHC (following instructions at GitHub) leads to a panic while running git/ghc/inplace/bin/haddock. OS is Fedora Linux 18. Installed latest version of cabal-install, Alex, Happy, and Haddock. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8389> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1