January 2014 - ghc-tickets

Re: [GHC] #8031: Template Haskell gets confused with kind variables introduced in separate foralls
by GHC 21 Jan '14

21 Jan '14

#8031: Template Haskell gets confused with kind variables introduced in separate foralls -----------------------------+--------------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: TemplateHaskell PolyKinds Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | -----------------------------+--------------------------------------------- Changes (by jstolarek): * cc: jan.stolarek@… (added) * difficulty: => Unknown -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8031#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6089: Allow declaration splices inside declaration brackets
by GHC 20 Jan '14

20 Jan '14

#6089: Allow declaration splices inside declaration brackets ----------------------------------------------+---------------------------- Reporter: igloo | Owner: simonpj Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Template Haskell | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by monoidal): With {{{ decs :: Q [Dec] decs = [d|$( [d| fun3 = undefined |] ) |] }}} GHC 7.6 complains, but GHC 7.7 apparently ignores the splice - `$decs` does not bring `fun3` into scope. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6089#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8439: add a CPP program field to Settings file (decouple CPP program and C compiler choice)
by GHC 20 Jan '14

20 Jan '14

#8439: add a CPP program field to Settings file (decouple CPP program and C compiler choice) -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8683 -------------------------------------+------------------------------------ Changes (by hvr): * related: => #8683 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8439#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4210: LLVM: Dynamic Library Support
by GHC 20 Jan '14

20 Jan '14

#4210: LLVM: Dynamic Library Support -------------------------------------+------------------------------------ Reporter: dterei | Owner: dterei Type: feature request | Status: closed Priority: low | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: 6.13 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonmar): Yes, `R_COPY` relocations and tables-next-to-code don't work well together, so I believe we do some trickery on other platforms to avoid the linker from generating them. take a look at `compiler/nativeGen/PIC.hs` and search for "copy". -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4210#comment:32> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4210: LLVM: Dynamic Library Support
by GHC 20 Jan '14

20 Jan '14

#4210: LLVM: Dynamic Library Support -------------------------------------+------------------------------------ Reporter: dterei | Owner: dterei Type: feature request | Status: closed Priority: low | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: 6.13 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by bgamari): It turns out that the code above is the same as is seen in `libHSghc- prim*.so` so it seems that the `R_ARM_COPY` relocation is indeed being correctly performed. Given that this same code works with gold, it seems likely that this isn't trampoline code but instead the correct code for this symbol. I now think that it is the copy itself that is causing the crash due to tables-before-code. While the linker knows to copy the symbol itself, it doesn't copy the info table preceding it. Trying to make the runtime linker do the right thing with `R_ARM_COPY` with tables-before-code enabled is going to be very difficult, if not impossible. If this hypothesis is correct, we should disable tables- before-code on ARM when using affected linkers (all versions of bfd ld, as far as I can tell). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4210#comment:31> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8686: "cannot find normal object file" error during compilation
by GHC 20 Jan '14

20 Jan '14

#8686: "cannot find normal object file" error during compilation -----------------------------------+--------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- When I try to compile tests provided in the [http://hackage.haskell.org/package/singletons singletons] package I get the following error: {{{ Building singletons-0.9.3... Preprocessing library singletons-0.9.3... In-place registering singletons-0.9.3... Preprocessing test suite 'compile' for singletons-0.9.3... [ 6 of 20] Compiling Data.Singletons.Core ( Data/Singletons/Core.hs, dist/build/compile/compile-tmp/Data/Singletons/Core.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package containers-0.5.3.1 ... linking ... done. Loading package transformers-0.3.0.0 ... linking ... done. Loading package mtl-2.1.2 ... linking ... done. Loading package syb-0.4.1 ... linking ... done. Loading package pretty-1.1.1.1 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package th-desugar-1.2.1 ... linking ... done. Loading package newtype-0.2 ... linking ... done. Loading package constraints-0.3.4.2 ... linking ... done. Data/Singletons/Core.hs:1:1: cannot find normal object file ‛dist/build/compile/compile- tmp/Data/Singletons/Util.dyn_o’ while linking an interpreted expression }}} This happens on HEAD but not on 7.6.3. Steps to reproduce: 1. Download and extract singletons source code 2. In the cabal file uncomment test-suite section (which is commented out because it doesn't work) 3. `cabal configure --enable-tests && cabal build` Reproducing this requires installing packages required by singletons. I'm setting milestone to 7.8 as this is something that looks like a blocker in a stable release. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8686> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #3693: Show stack traces
by GHC 20 Jan '14

20 Jan '14

#3693: Show stack traces -------------------------------------+------------------------------------ Reporter: jpet | Owner: Tarrasch Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 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: -------------------------------------+------------------------------------ Comment (by simonpj): Tim Schroeder writes (on Haskell Cafe) Hello, I have developed various profiling and debugging tools in the past, but haven't done any work in that direction for GHC compiled Haskell programs. I thought a good start might be to write a document detailing how the call stack works in GHC, and also write a basic debugger stack trace tool. Here: [https://github.com/blitzcode/ghc-stack] I hope this is helpful to people trying to pin down crashes, and people interested in working on debugging / profiling tools. I'd also really appreciate if somebody with more GHC / RTS knowledge than me would have a look and see if I got things right. Cheers, Tim -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3693#comment:53> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4210: LLVM: Dynamic Library Support
by GHC 20 Jan '14

20 Jan '14

#4210: LLVM: Dynamic Library Support -------------------------------------+------------------------------------ Reporter: dterei | Owner: dterei Type: feature request | Status: closed Priority: low | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: 6.13 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by bgamari): Actually, this is quite perplexing as I would have expected the R_ARM_COPY relocation to have already been performed by ld.so by the time we get to executing code. That being said, in place of numerous data symbols I see what appears to be trampoline code, {{{ #5 0xb61f8eaa in evacuate (p=0xb5cfd194) at rts/sm/Evac.c:384 384 ASSERTM(LOOKS_LIKE_CLOSURE_PTR(q), "invalid closure, info=%p", q->header.info); (gdb) print q $1 = (StgClosure *) 0x16bf8 <Main_zdfEqModule_closure> (gdb) print *q $2 = {header = {info = 0x16d64 <ghczmprim_GHCziClasses_DZCEq_static_info>}, payload = 0x16bfc <Main_zdfEqModule_closure+4>} (gdb) x /5i 0x16d64 0x16d64 <ghczmprim_GHCziClasses_DZCEq_static_info>: ldr r3, [r5] 0x16d68 <ghczmprim_GHCziClasses_DZCEq_static_info+4>: add r7, r7, #1 0x16d6c <ghczmprim_GHCziClasses_DZCEq_static_info+8>: blx r3 0x16d70 <ghczmprim_GHCziClasses_DZCEq_static_info+12>: bx lr 0x16d74: movs r0, r0 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4210#comment:30> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4210: LLVM: Dynamic Library Support
by GHC 20 Jan '14

20 Jan '14

#4210: LLVM: Dynamic Library Support -------------------------------------+------------------------------------ Reporter: dterei | Owner: dterei Type: feature request | Status: closed Priority: low | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: 6.13 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by bgamari): Unfortunately, things are still broken with BFD ld due to ld bug 16177 (https://sourceware.org/bugzilla/show_bug.cgi?id=16177) wherein ld inexplicably generates R_ARM_COPY relocations where a standard R_ARM_ABS32 relocation would do just fine (as gold does). Sadly, despite the bug being reported two months ago, there has been no activity from the ld side. For now I suspect we'll just have to advise users to use gold on ARM. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4210#comment:29> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7596: Opportunity to improve CSE
by GHC 20 Jan '14

20 Jan '14

#7596: Opportunity to improve CSE -------------------------------------+------------------------------------ Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): As suggested, I made CSE much more aggressive by floating out much more expressions, so that `Just x` is CSE’ed in {{{#!haskell module T7596 where f :: Maybe Int -> (Bool, Bool) f Nothing = (True, True) f _ = (False, True) {-# NOINLINE f #-} g :: Maybe Int -> (Bool, Bool) g Nothing = (True, True) g _ = (False, True) {-# NOINLINE g #-} foo :: Int -> Bool foo x = case f (Just x) of (a, b) -> case g (Just x) of (p,q) -> a && b && p && q }}} It hardy helps, though: {{{ Min -0.6% -14.1% -33.0% -33.9% -20.0% Max +0.6% +178.2% +85.2% +86.1% +50.0% Geometric Mean -0.2% +14.1% +13.1% +12.5% +0.8% }}} But that is no surprise; it CSE’s dictionary access functions like `lvl1 = GHC.Classes.<= @ a sc` – not much to win here. Preventing aggresive floating of partial applications... slightly better, but still horrible: {{{ Min -0.7% -14.1% -53.0% -55.4% -20.0% Max +0.5% +178.2% +25.9% +25.9% +50.0% Geometric Mean -0.4% +13.6% -16.8% -18.1% +0.6% }}} For example `spectral/sorting`: `+123.1%` increase, due to the expression `reverse rev` shared in this code {{{#!haskell insertSort [] = [] insertSort (x:xs) = trins [] [x] xs where trins :: Ord a => [a] -> [a] -> [a] -> [a] trins rev [] (y:ys) = trins [] ((reverse rev) ++ [y]) ys trins rev xs [] = (reverse rev) ++ xs trins rev (x:xs) (y:ys) | x < y = trins (x:rev) xs (y:ys) | True = trins [] (reverse rev ++ (y:x:xs)) ys }}} Clearly CSE’ing something from different branches can never be a win (besides potentially code size). But that is something the current CSE code cannot check, right? And even in the example from the ticket description, it is not stupid not to do CSE: With some luck the first `I#` allocated will be free before the next GC run, causing no copying. After CSE it stays alive for longer, causing more work. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7596#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0