January 2014 - ghc-tickets

Re: [GHC] #8029: batch-mode recompilation checking sometimes fails
by GHC 23 Jan '14

23 Jan '14

#8029: batch-mode recompilation checking sometimes fails -----------------------------+--------------------------------------------- Reporter: jwlato | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: recompilation, batch-mode Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | -----------------------------+--------------------------------------------- Comment (by simonmar): There was one small suggestion to emerge from this discussion, namely to add the package name to the error message, but it was acknowledged that that wouldn't help in the instance that sparked the ticket. So is it worth keeping the ticket open? FWIW I don't think we should be looking for `.hs` files in one-shot compilation. As Ian says, there's no requirement that they have to be in a discoverable location at all, and it might break existing build systems to add that requirement. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8029#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8691: Investigate recent 32bit compiler performance regressions
by GHC 23 Jan '14

23 Jan '14

#8691: Investigate recent 32bit compiler performance regressions -------------------------+------------------------------------------------- Reporter: | Owner: thoughtpolice | Status: new Type: bug | Milestone: 7.8.1 Priority: | Version: 7.7 normal | Operating System: Unknown/Multiple Component: | Type of failure: Compile-time performance bug Compiler | Test Case: Keywords: | Blocking: Architecture: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- In c5088e299a66109346057afc151c33e47b850b92 I tweaked the numbers for the x86/Linux build to get them to pass for the RC, but some of these look pretty bad. Most of them shot up quite a bit. Some of them I don't think were very recent (modification date unspecified, etc.) A few others had updates as early as November, so something has clearly slipped on 32bit platforms here. I spent a tiny amount of time investigating, but didn't get very far. I'm not holding the RC for these, but it's worth investigating when we get a chance. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8691> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

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

23 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 cactus): What documentation is needed beside the new section in `docs/users_guide/glasgow_exts`? Also, can you point me in the direction of the release notes? I'd like to add a note not just mentioning pattern synonyms but also explaining that it is a preview that will need feedback from actual usage and which has more features planned. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5144#comment:44> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

22 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 monoidal): Reminder: we still need documentation and release notes entry. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5144#comment:43> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

22 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): Thank you for your kind words! I've been most interested in the lower-level faults simply because they have the least support from the existing tools. I'm currently back on another project after spending a week or so on the debugging project, but I'm thinking about how to turn it into a a more usable and portable tool. Basically, I think I would rewrite it to be based fully on gdb's machine interface or lldb's C++ API. This buys me a few things: - Unified code to access the target process state (no more Win32 ReadProcessMemory() vs Linux ptrace() vs OS X mach_vm_read_overwrite()) - Unified code for symbol lookup (no more Win32 Sym* APIs vs Linux addr2line vs OS X / BSD atos) - Support for both stack traces from live processes and core dumps with no extra work - C/C++/etc. stack unwinding already done The biggest issue still seems to be keeping the debugger's view of the stack and heap in sync with the runtime / compiler sources. GHC's RTS data structures / memory layout seem fairly stable from what I can tell, but I'd like to make everything as automatic as possible. After all, there are quite a few different OS, CPU architecture, compiler and RTS flavors to support. I would use the DerivedConstants.h header and generate some additional offsets, register mappings and such using a similar mechanism. I still think the approach of directly accessing the target process through OS-level functions has some merit. Mostly for profiling, where we'd like to inspect the program hundreds or even thousands of times per second with as little overhead as possible. The CCS is a fairly good tool for pinning down the location of a crash, but Peter's work on improving DWARF information is really what I'm looking forward to for profiling. Hopefully this can be a part of 7.10! Peter, do your DWARF improvements handle FFI calls (traversing from C back into Haskell)? Also, do you think it would be feasible to support frame pointers as an option for GHC? I know debuggers have long moved on to doing stack unwinding with debug information, but there seem to be numerous profiling tools still using them for speed and simplicity. There's been some discussion here regarding RTS APIs to access the stack, but are there any ideas on how to expose this API to other processes? There are advantages to having debugging, profiling and heap walking tools be as unobtrusive as possible, not changing the program code or runtime behavior. RTS support for this type of access could make writing such tools simpler. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3693#comment:55> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

22 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): > (Or, a variant: Do that initialisation, but also do local fixed- pointing, starting from the stored values, so that when an inner let is re-analysed, but nothing has changed, then there is only one iteration.) Ah, so that is what `ae_virigin` is all about... doing the same trick in my code helps in keeping compilation times down; but I must be introducing bugs somewhere; compiled with my code GHC itself goes into infinite loops – but that is a problem for another day. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7994#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #915: Implement list fusion using streams instead of foldr/build
by GHC 22 Jan '14

22 Jan '14

#915: Implement list fusion using streams instead of foldr/build ----------------------------+---------------------------------------------- Reporter: simonpj | Owner: Type: task | Status: closed Priority: normal | Milestone: 7.6.1 Component: | Version: 6.8 libraries/base | Keywords: fusion Resolution: invalid | Architecture: Unknown/Multiple Operating System: | Difficulty: Project (more than a week) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: N/A | Blocking: | ----------------------------+---------------------------------------------- Comment (by duncan): We do now have a solution, however the current implementation relies on HERMIT. See: ''The HERMIT in the Stream -- Fusing Stream Fusion’s concatMap'' by Andrew Farmer, Christian Höner zu Sierdissen and Andy Gill. http://ittc.ku.edu/~afarmer/concatmap-pepm14.pdf See also this summary/commentary: http://blog.ezyang.com/2014/01/pepm14 -the-hermit-in-the-stream/ -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/915#comment:46> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

22 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): I gave it a shot, analysing the body and the rhs of a let in alternation until a fixed point is found with regard to * demand on the rhs * rhs’s demand type * body’s demand type and as expected, the resulting core looks good: {{{ $wgo_s1oi [Occ=LoopBreaker] :: GHC.Prim.Int# -> GHC.Prim.Double# -> GHC.Prim.Double# -> Data.Complex.Complex GHC.Types.Double [LclId, Arity=3, Str=DmdType <S,U><L,U><L,U>] $wgo_s1oi = \ (w_s1o3 :: GHC.Prim.Int#) (ww1_s1oa :: GHC.Prim.Double#) (ww2_s1of :: GHC.Prim.Double#) -> case Foo.f (GHC.Types.I# w_s1o3) of _ [Occ=Dead] { Data.Complex.:+ ww4_s1nS ww5_s1nX -> case ww4_s1nS of _ [Occ=Dead] { GHC.Types.D# ww7_s1re -> case ww5_s1nX of _ [Occ=Dead] { GHC.Types.D# ww9_s1rg -> case GHC.Prim.tagToEnum# @ GHC.Types.Bool (GHC.Prim.==# w_s1o3 ww_s1om) of _ [Occ=Dead] { GHC.Types.False -> $wgo_s1oi (GHC.Prim.+# w_s1o3 1) (GHC.Prim.+## ww1_s1oa ww7_s1re) (GHC.Prim.+## ww2_s1of ww9_s1rg); GHC.Types.True -> Data.Complex.:+ @ GHC.Types.Double (GHC.Types.D# (GHC.Prim.+## ww1_s1oa ww7_s1re)) (GHC.Types.D# (GHC.Prim.+## ww2_s1of ww9_s1rg)) } } } }; } in $wgo_s1oi 1 0.0 0.0; }}} But also as expected, for other code, with more nested lets, compilation time becomes unacceptably large. Has anyone considered doing the fixed-pointing not locally for every let, but across the whole top-level-binding? I.e. initialize all demands and strictness signatures with their strongest possible value (`absDmd` and `botDmdType`), and then analyse the whole expression in repeated passes over all of it, until nothing changes any more. (Or, a variant: Do that initialisation, but also do local fixed-pointing, starting from the stored values, so that when an inner let is re-analysed, but nothing has changed, then there is only one iteration.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7994#comment:5> 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 22 Jan '14

22 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): Previous patches were buggy and worked on 7.6.3 by accident. This new patch is more or less independent and works. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2283#comment:9> 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 22 Jan '14

22 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 made preliminary port of this patch to HEAD. It works on my Windows 8 64-bit boxes, but some mentions should be made: 1. I've disabled {{{.ctor}}} section handling. It was introduced recently and does not work on x86_64 mingw32 barfing {{{can't find section `'}}}; 2. It turned out STG allocator (which uses standard C {{{malloc}}}, which, in turn, uses {{{HeapAlloc}}} on Windows) can allocate some memory from high addresses. This did not occured when I allocated trampolines area with {{{VirtualAlloc}}} directly, but it makes Symon's concerns looks much more reasonable than I thought before. Probably, it is worth efforts to guarantee placement of trampolines area next to object image in memory as it is made in unixish code. Especially because we now allocate trampolines for all externs and not only for undefined externs (which accidentally was enough for 7.6.3) precisely because of STG allocator puts some *defined* externs to high addresses. Anyway, right now this patch makes x86_64 mingw32 working! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7134#comment:45> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0