January 2014 - ghc-tickets

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

25 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): [https://github.com/bgamari/ghc/compare/disable-ld Here] is a patch set to ensure that people aren't bitten by this. We sacrifice support for binutils' ld when dynamic linking on ARM but at least people don't encounter random segfaults. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4210#comment:33> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2283: WIndows: loading objects that refer to DLL symbols
by GHC 25 Jan '14

25 Jan '14

#2283: WIndows: loading objects that refer to DLL symbols ---------------------------------+------------------------------- Reporter: simonmar | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: GHCi | Version: 6.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: #7097 #7568 ---------------------------------+------------------------------- Comment (by awson): I've updated the patch (added a reference to the ticket and updated the comment). See also my explanation here: https://ghc.haskell.org/trac/ghc/ticket/7097#comment:19. Btw, with this patch we don't need to fix mingw-w64 (or any other) headers anymore. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2283#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32
by GHC 25 Jan '14

25 Jan '14

#7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 -------------------------------+---------------------------------- Reporter: cetinsert | Owner: thoughtpolice Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.6.1-rc1 Resolution: | Keywords: R_X86_64_PC32 Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: -------------------------------+---------------------------------- Comment (by awson): I've updated the patch for HEAD. Now: 1. Memory for trampolines is reserved right next to memory for image. We reserve this space for all symbols in image. This could look as overkill, but this is the way it is done in unixish cases, and also {{{VirtualAlloc}}} takes physical memory from system lazily (only when relevant page is accessed), and we don't need to save virtual space because we have plenty of it. Unlike in unixish cases, though, we avoid any reallocations because we can take the number of symbols from PECoff header. 2. Loading of archives is fixed. Looking into the code I can say it never worked for static GHCi linker on Win64. Now it works. Don't try to remove prelinked HSbase-4.7.0.0.o though :) otherwise ghci segfaults trying to set buffering status for base's stdin, stdout and stderr. I suspect, this is related to the way {{{initInterpBuffering}}} in {{{GhciMonad.hs}}} works. 3. Disabled {{{.ctor}}} handling comments now contain the number of related ticket, which I've created for this. 4. The status is documented in release notes. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7134#comment:47> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8694: ghc -M doesn't handle addDependentFile or #included files
by GHC 24 Jan '14

24 Jan '14

#8694: ghc -M doesn't handle addDependentFile or #included files ------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 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: | ------------------------------------+------------------------------------- ghc -M doesn't emit dependencies specified by TH's `addDependentFile`, not does it emit dependencies for `#include`d files. The former is quite hard to do, because it requires compiling the code: we only have the information about `addDependentFile` calls after compilation. So in order to fix this, `ghc -c` would have to drop some information somewhere for the build system to pick up. In theory we should only have to preprocess files to get the list of #included files, and ghc -M already preprocesses all the files. However, currently #included files are picked up by the lexer during parsing, so fixing this isn't trivial. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8694> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5144: Pattern synonyms
by GHC 24 Jan '14

24 Jan '14

#5144: Pattern synonyms -------------------------------------------+------------------------------- Reporter: simonpj | Owner: cactus Type: feature request | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: 8581, 8582, 8583, 8584 | Blocked By: | Related Tickets: -------------------------------------------+------------------------------- Comment (by thoughtpolice): Thanks Gergo! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5144#comment:47> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7994: Make foldl into a good consumer
by GHC 24 Jan '14

24 Jan '14

#7994: Make foldl into a good consumer -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: -------------------------------------+------------------------------------ Comment (by nomeata): Ok, here is a very different approach to solving the original problem of this ticket, namely making `foldl` a good consumer. Instead of trying hard to make the compiler sufficiently smart, why not help him a little bit? So here is what I did: I created a new magic function `oneShot` (similar to `lazy` etc.). Semantically, `oneShot = λ f λ x. f x", but the unfolding will put a `OneShot` on the binder for x. So essentially, it allows the programmer to tell the compiler: I promise I will only call this function once (and if I break my promise, I won’t blame you). So now one would define {{{ foldl k z xs = foldr (\v fn -> oneShot (\z -> fn (k z v))) id xs z }}} (because at this point, we know that the result of `foldr ... id xs` is ''not'' going to be used multiple times) and voilà – good code: {{{ Foo.$wfoo :: GHC.Prim.Int# -> (# GHC.Types.Double, GHC.Types.Double #) [GblId, Arity=1, Str=DmdType <L,U>, Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=1, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [0] 249 30}] Foo.$wfoo = \ (ww_s1ox :: GHC.Prim.Int#) -> case GHC.Prim.tagToEnum# @ GHC.Types.Bool (GHC.Prim.># 1 ww_s1ox) of _ [Occ=Dead] { GHC.Types.False -> letrec { $wgo_s1ot [Occ=LoopBreaker] :: GHC.Prim.Int# -> GHC.Prim.Double# -> GHC.Prim.Double# -> (# GHC.Types.Double, GHC.Types.Double #) [LclId, Arity=3, Str=DmdType <S,U><L,U><L,U>] $wgo_s1ot = \ (w_s1oc :: GHC.Prim.Int#) (ww1_s1oj :: GHC.Prim.Double#) (ww2_s1oo :: GHC.Prim.Double#) -> case Foo.f (GHC.Types.I# w_s1oc) of _ [Occ=Dead] { Data.Complex.:+ ww8_aYl ww9_aYm -> case ww8_aYl of _ [Occ=Dead] { GHC.Types.D# ww11_s1sa -> case ww9_aYm of _ [Occ=Dead] { GHC.Types.D# ww13_s1sc -> case GHC.Prim.tagToEnum# @ GHC.Types.Bool (GHC.Prim.==# w_s1oc ww_s1ox) of _ [Occ=Dead] { GHC.Types.False -> $wgo_s1ot (GHC.Prim.+# w_s1oc 1) (GHC.Prim.+## ww1_s1oj ww11_s1sa) (GHC.Prim.+## ww2_s1oo ww13_s1sc); GHC.Types.True -> (# GHC.Types.D# (GHC.Prim.+## ww1_s1oj ww11_s1sa), GHC.Types.D# (GHC.Prim.+## ww2_s1oo ww13_s1sc) #) } } } }; } in $wgo_s1ot 1 0.0 0.0; GHC.Types.True -> (# Foo.foo1, Data.Complex.$fFloatingComplex1 #) } }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7994#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2110: Rules to eliminate casted id's
by GHC 24 Jan '14

24 Jan '14

#2110: Rules to eliminate casted id's -------------------------------------+------------------------------------ Reporter: igloo | Owner: Type: feature request | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.8.2 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): I looked into this and further cleaned up the branch. But I just cannot get it to optimize `map unsafeCoerce` away, and the problem seems to be not enough eta-expansion in the simplifier. So here is the rule as desugared; it has the shape that we want it to have {{{ ------ Local rules for imported ids -------- "map/coerce" [ALWAYS] forall (@ a) (@ b) ($r$dCoercible :: a GHC.Prim.~R# b). GHC.Base.map @ a @ b ((\ (tpl :: a) -> tpl) `cast` (<a>_R -> ($r$dCoercible) :: (a -> a) ~# (a -> b))) = (\ (tpl :: [a]) -> tpl) `cast` (<[a]>_R -> [($r$dCoercible)]_R :: ([a] -> [a]) ~# ([a] -> [b])) }}} And here is the Core that we want it to match: {{{ GHC.Base.map @ GHC.Types.Int @ Test.Age ((Unsafe.Coerce.unsafeCoerce1 @ GHC.Types.Int @ Test.Age) `cast` (<GHC.Types.Int>_R -> UnivCo representational GHC.Types.Int Test.Age :: (GHC.Types.Int -> GHC.Types.Int) ~# (GHC.Types.Int -> Test.Age))) }}} And for reference, here is the information on `unsafeCoerce1`: {{{ unsafeCoerce1 :: forall a b. a -> a {- Arity: 1, HasNoCafRefs, Strictness: <S,1*U>, Unfolding: (\ @ a @ b x :: a -> x) -} }}} When trying to match, the matcher successfully matches the casts and then tries to match {{{ \ (tpl{v} [lid] :: a{tv aMF} [tv]) -> tpl{v} [lid] }}} against {{{ base:Unsafe.Coerce.unsafeCoerce1{v rKi} [gid] @ ghc-prim:GHC.Types.Int{(w) tc 3J} @ main:Test.Age{tc rM6} }}} It eta-expands both sides to match {{{ tpl{v} [lid] }}} against {{{ base:Unsafe.Coerce.unsafeCoerce1{v rKi} [gid] @ ghc-prim:GHC.Types.Int{(w) tc 3J} @ main:Test.Age{tc rM6} tpl{v} [lid] }}} and there it fails. Possible solutions: If GHC would inline `unsafeCoerce1` even though it is undersaturated, we’d be matching {{{ GHC.Base.map @ GHC.Types.Int @ Test.Age ((\ x :: GHC.Types.Int -> x) `cast` (<GHC.Types.Int>_R -> UnivCo representational GHC.Types.Int Test.Age :: (GHC.Types.Int -> GHC.Types.Int) ~# (GHC.Types.Int -> Test.Age))) }}} which would succeed (this is also the shape we get from `map Age`). But I did not manage to define `unsafeCoerce` in a way that this happens. Alternatively, the matching code could, after eta-expanding, simplify the expression, so that the unfolding would happen here. Otherwise, my code is ready for review, see branch `wip/nomeata-T2110`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2110#comment:41> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2110: Rules to eliminate casted id's
by GHC 24 Jan '14

24 Jan '14

#2110: Rules to eliminate casted id's -------------------------------------+------------------------------------ Reporter: igloo | Owner: Type: feature request | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.8.2 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): > I’m not convinced about your solution. It seems a bit of a hack. I’m just re-reading this thread, and it seems that my proposed solution (replace `Coercible` in a rule with `~R#`, and inline `coercoe`) is precisely what we had concluded last week – is that right or was there a misunderstanding on my side? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2110#comment:40> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2283: WIndows: loading objects that refer to DLL symbols
by GHC 24 Jan '14

24 Jan '14

#2283: WIndows: loading objects that refer to DLL symbols ---------------------------------+------------------------------- Reporter: simonmar | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: GHCi | Version: 6.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: #7097 #7568 ---------------------------------+------------------------------- Comment (by simonmar): Yes, a source code comment in both cases please. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2283#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

24 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 blitzcode): This is all quite tricky since there seem to be so many different approaches to consider! ;-) For profiling, I am mostly coming at this problem from the perspective of already having an external tool that works for C/C++ and wanting to add Haskell support to it (it's a sampling profiler, pausing threads and capturing their stack, as you already said). I think you make a very valid point about already having all the functionality in the RTS (eventually). I don't have any technical / ideological reason to prefer an external profiler, what I'm after is seeing profiling data in realtime, while the program is running. If the RTS is collecting profiling data it could either provide some kind of IPC API to have an external tool collect it, or maybe just have a Haskell API so one could use a library like EKG to show it to the user. I couldn't really figure out how the Haskell to C stack transition works, but I think that's a less common case than the Haskell to C one anyway. Glad to hear that the latter seems to be working! I don't agree that having an external program do a stack walk is necessarily complicated or awkward. With your DWARF3 work, one should be able to use something like libunwind-ptrace (http://www.nongnu.org/libunwind/man/libunwind-ptrace%283%29.html) and have that functionality available without any custom work. For debugging, I think there's merit for an external tool. For RTS exceptions we're ok, but as soon as we have an actual segfault, some memory corruption has often already taken place. Any kind of stack traversal, symbol lookup and error reporting code will have a decent chance of failing itself due to a corrupted heap or such. The only library that I can think of would be libunwind. It's supported on Linux/BSD, Apple ships some kind of version of it on OS X (there are some limitations / issues with their port, IIRC), does DWARF2/3. It's not on Windows, but there's build-in support for stack walking through the DbgHelp library (StackWalk64, no idea if Windows PDB debug information supports the kind of wizardry your using to explain the STG stack to a DWARF3 debugger, though). It seems generating the right kind of debug symbols, and supporting and doing stack walking for Haskell & C/C++ on all three platforms is a major challenge... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3693#comment:57> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0