- ghc-tickets - Haskell.org

[GHC] #8120: ghc: panic! (the 'impossible' happened)
by GHC 09 Aug '13

09 Aug '13

#8120: ghc: panic! (the 'impossible' happened) ------------------------------------+------------------------------------- Reporter: EyalLotem | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Foo.hs:6:3:ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for i386-unknown-linux): kindFunResult ghc-prim:GHC.Prim.*{(w) tc 34d} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug The source file has to contain, merely: {{{ l :: m a -> t m a l = undefined f :: a -> f b f = do x <- undefined l $ x undefined main = return () }}} This panic reproduces on at least: 7.6.1, 7.6.2, 7.6.3. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8120> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #7978: Profiling broken
by GHC 09 Aug '13

09 Aug '13

#7978: Profiling broken --------------------------------------------+------------------------------ Reporter: gmainland | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC doesn't work at all | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by ezyang): I've further narrowed down the bug to how selectors are compiled: {{{ --- a/compiler/codeGen/StgCmmBind.hs +++ b/compiler/codeGen/StgCmmBind.hs @@ -282,7 +282,7 @@ mkRhsClosure dflags bndr _cc _bi cgRhsStdThunk bndr lf_info [StgVarArg the_fv] where lf_info = mkSelectorLFInfo bndr offset_into_int - (isUpdatable upd_flag) + (isUpdatable Updatable) (_, _, params_w_offsets) = mkVirtConstrOffsets dflags (addIdReps params) -- Just want the layout maybe_offset = assocMaybe params_w_offsets (NonVoid selectee) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7978#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7978: Profiling broken
by GHC 08 Aug '13

08 Aug '13

#7978: Profiling broken --------------------------------------------+------------------------------ Reporter: gmainland | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC doesn't work at all | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by ezyang): My guess is cardinality analysis is tickling a latent bug in the code generator related to generating code for non-updatable thunks. If you disable cardinality analysis in the following way: {{{ diff --git a/compiler/stgSyn/CoreToStg.lhs b/compiler/stgSyn/CoreToStg.lhs index 1395c22..414a6d8 100644 --- a/compiler/stgSyn/CoreToStg.lhs +++ b/compiler/stgSyn/CoreToStg.lhs @@ -807,7 +807,7 @@ mkStgRhs rhs_fvs srt bndr binder_info rhs (getFVs rhs_fvs) upd_flag srt [] rhs where - upd_flag = getUpdateFlag bndr + upd_flag = Updatable {- SDM: disabled. Eval/Apply can't handle functions with arity zero very well; and making these into simple non-updatable thunks breaks other }}} I think the profiling build goes through as desired. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7978#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5144: Pattern synonyms
by GHC 08 Aug '13

08 Aug '13

#5144: Pattern synonyms -------------------------------------+------------------------------------ Reporter: simonpj | Owner: cactus Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 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 akio): * cc: tkn.akio@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5144#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8004: Applicative/Monad proposal related warnings (AMP phase 1)
by GHC 08 Aug '13

08 Aug '13

#8004: Applicative/Monad proposal related warnings (AMP phase 1) -------------------------------------+------------------------------------ Reporter: quchen | Owner: Type: feature request | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 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 lelf): * cc: me@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8004#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7978: Profiling broken
by GHC 08 Aug '13

08 Aug '13

#7978: Profiling broken --------------------------------------------+------------------------------ Reporter: gmainland | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC doesn't work at all | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by ezyang): I've verified that cardinality + build fixes + mainland workaround result in a segfaulting ghc-stage2, e.g. my log looks like: {{{ 375cd37 Add a work-around for #7978. 6265312 Wibbles (merg-os) to ticky-ticky 507c897 Comments about the Name Cache 99d4e5b Implement cardinality analysis }}} I've also verified that profiling is fine before the cardinality analysis patch. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7978#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8117: We don't distribute copy of GPL with code that requires it
by GHC 08 Aug '13

08 Aug '13

#8117: We don't distribute copy of GPL with code that requires it -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Documentation Difficulty: Easy (less than 1 | bug hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Some tests in testsuite are released under GPL license: * T3787 * T4524 * T3591 but we don't provide copy of the license thus violating the license: {{{ give any other recipients of the Program a copy of this License along with the Program. }}} (Actually testsuite itself doesn't have a license, but that's a different issue) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8117> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #7169: Warning for incomplete record field label used as function
by GHC 08 Aug '13

08 Aug '13

#7169: Warning for incomplete record field label used as function -------------------------------------+------------------------------------ Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Warnings Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by adamgundry): * cc: adam.gundry@… (added) Comment: This sounds like a good idea. I'm deep in record field land at the moment, so I could take a look at it if you like. It should be fairly straightforward: `mkRecSelBind` can record the partiality of the selector in its `IdDetails`, just like for "naughty" selectors. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7169#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6063: GHC's build-time ld-flag checks are problematic
by GHC 08 Aug '13

08 Aug '13

#6063: GHC's build-time ld-flag checks are problematic --------------------------------------------+------------------------------ Reporter: parcs | Owner: Type: bug | thoughtpolice Priority: high | Status: closed Component: Compiler | Milestone: 7.8.1 Resolution: fixed | Version: 7.4.1 Operating System: Linux | Keywords: Type of failure: GHC doesn't work at all | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: #4862 --------------------------------------------+------------------------------ Comment (by gidyn): Replying to [comment:21 jberryman]: > Sorry to reply to a closed bug, but can I get clarification that this is also the case in 7.6.3? I created a bindist from the source distribution (with `make binary-dist`?) and then did a `configure && make install` after installing binutils-gold. When I build it's still trying to pass those flags to `ld` and is failing. Same here. The configure script claims to be checking whether ld understands `--hash-size=31`, but doesn't do anything with it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6063#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3693: Show stack traces
by GHC 07 Aug '13

07 Aug '13

#3693: Show stack traces -------------------------------------+------------------------------------ Reporter: jpet | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.6.2 Component: Runtime System | Version: 6.10.4 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 scpmw): * difficulty: => Unknown Comment: Some progress on this - our [https://github.com/scpmw/ghc/commits /profiling-ncg DWARF / profiling branch] now generates DWARF using NCG, complete with .debug_frame unwind records that are at least valid at the start of blocks. That's enough for GDB to backtrace: {{{ $ gdb stack-trace -q Reading symbols from tack-trace...done. (gdb) break stg_raisezh Breakpoint 1 at 0x68f2f8: file rts/Exception.cmm, line 433. (gdb) run Starting program: stack-trace Breakpoint 1, stg_raisezh () at rts/Exception.cmm:433 433 { (gdb) bt #0 stg_raisezh () at rts/Exception.cmm:433 #1 0x0000000000694330 in ?? () at rts/Updates.cmm:57 #2 0x00000000004047a0 in Main_zdwfibzuerr_info () at stack-trace.hs:7 #3 0x0000000000404770 in Main_zdwfibzuerr_info () at stack-trace.hs:5 }}} Note however that we end up with "??" sometimes due to GDB looking at IP-1 for information about the supposed "call" instruction. With tables next to code, that is guaranteed to be inside the info table, so right now I just declare the info table as belonging to a source file so at least the "at bla" bit is correct. Furthermore, using Max' patch and some more or less involved lookups we can do the backtracking from the RTS as well, which then looks roughly as follows ([https://github.com/scpmw/ghc/commits/stack-tracing code here]): {{{ stack-trace: Barf! Loading debug data... Stack trace: 0: stg_bh_upd_frame_ret (at rts/Updates.cmm:86:1-91:2) 1: fib_err (at stack-trace.hs:7:37-7:42) 2: fib_err (at stack-trace.hs:7:37-7:42) 3: fib_err (at stack-trace.hs:7:37-7:42) 4: fib_err (at stack-trace.hs:7:37-7:42) }}} Here the RTS is reading in DWARF from our own executable as well as libraries using libdwarf, then looking up the code pointers to get labels. These are then looked up in the debug info table we normally use for profiling, which yields (amongst other things) references to the original source code. Caveats: * The quality of the result obviously depends a lot on what we can actually find on the stack. Ironically, higher optimization levels sometimes produce better results, as there's a higher change for functions to have specialized return code. * Only works on Linux at this point - main sticking point would be undoing relocation and finding the right files to read DWARF from (right now I read /proc/self/maps for that). * Depends on a significant amount of code from my profiling-ncg branch, which has a few change that might be controversial - such as adding CmmTick and CmmContext to CmmNode instead of tracking source code ticks per-block or per-procedure. Reasoning is basically that this solution seems to have the least overhead on Cmm optimizations. Something I am wondering right now is what kind of API would be most appropriate for this kind of thing. This comes down pretty much to how much extra functionality we want - we would probably want to be able to request stack dumps manually, but would we want to be able to make the stack contents transparent to the Haskell program? If yes we could convert stack dumps into a Haskell lists, possibly offering whatever extra bits of information while we're at it (e.g. Core references). On the other hand that would be really, really impure - and quite some work to boot. Thoughts? Any particular features people would like to see? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3693#comment:44> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0