- ghc-tickets - Haskell.org

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

[GHC] #8677: Perhaps you haven't installed the "p_dyn" libraries for package ‛integer-gmp’
by GHC 21 Jan '14

21 Jan '14

#8677: Perhaps you haven't installed the "p_dyn" libraries for package ‛integer- gmp’ -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Compiling ghc from git HEAD (e4a4abae21d14a6c1a4ae875fa582e2b389dc177) with a pretty standard mk/build.mk {{{ > diff mk/build.mk mk/build.mk.sample 12c12 < BuildFlavour = perf --- > #BuildFlavour = perf }}} Once I install ghc-7.7 and try to use cabal to install other libraries I get: {{{ Building aeson-0.7.0.0... Failed to install aeson-0.7.0.0 Last 10 lines of the build log ( /home/erikd/.cabal/logs/aeson-0.7.0.0.log ): [ 9 of 12] Compiling Data.Aeson.Encode ( Data/Aeson/Encode.hs, dist/build/Data/Aeson/Encode.o ) [10 of 12] Compiling Data.Aeson.Generic ( Data/Aeson/Generic.hs, dist/build/Data/Aeson/Generic.o ) [11 of 12] Compiling Data.Aeson ( Data/Aeson.hs, dist/build/Data/Aeson.o ) [12 of 12] Compiling Data.Aeson.TH ( Data/Aeson/TH.hs, dist/build/Data/Aeson/TH.o ) [ 1 of 12] Compiling Data.Aeson.Types.Internal ( Data/Aeson/Types/Internal.hs, dist/build/Data/Aeson/Types/Internal.p_o ) Top level: Failed to load interface for ‛GHC.Integer.Type’ Perhaps you haven't installed the "p_dyn" libraries for package ‛integer-gmp’? Use -v to see a list of the files searched for. Updating documentation index /home/erikd/.cabal/share/doc/index.html cabal: Error: some packages failed to install: aeson-0.7.0.0 failed during the building phase. The exception was: ExitFailure 1 }}} My cabal setup has: {{{ library-profiling: True }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8677> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8180: ghc --make uses wrong way with Template Haskell
by GHC 21 Jan '14

21 Jan '14

#8180: ghc --make uses wrong way with Template Haskell ----------------------------------+--------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------- I have the following files: {{{ {-# LANGUAGE TemplateHaskell #-} module THSplice where number3 = [| 3 |] }}} {{{ {-# LANGUAGE TemplateHaskell #-} module Main where import THSplice main = putStrLn (show $number3) }}} When I say `ghc Main.hs`, I get this: {{{ [1 of 2] Compiling THSplice ( THSplice.hs, THSplice.o ) [2 of 2] Compiling Main ( Main.hs, Main.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Main.hs:7:23: cannot find normal object file ‛./THSplice.dyn_o’ while linking an interpreted expression }}} It's possible a different collection of flags could get this to work, but I think this behavior goes against the intended "it just works" flavor of `--make`. This is a regression bug -- ghc 7.6.3 does the right thing. I'm on MacOS 10.7.5, Xcode 4.3.3. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8180> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

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

21 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): > The demand analyser currently analyses the function before the body. One could do a second round, but there is a risk of exponential blow-up. In this case, the let is a recursive let anyways, so we are going to do multiple iterations. Do we really need to avoid re-analysis so hard? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7994#comment:4> 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 21 Jan '14

21 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): In theory, it's possible. There is even a comment in my code exactly about this. I'll cite it here: "Unlike in unixish case we don't bother to guarantee extras are laid out next to object image in memory. It looks Windows allocator don't suddenly want to allocate memory from top to down if we don't tell him so. And we don't." {{{VirtualAlloc}}} has a special flag {{{MEM_TOP_DOWN}}} which according to http://msdn.microsoft.com/en- us/library/windows/desktop/aa366887%28v=vs.85%29.aspx: "Allocates memory at the highest possible address". Without this flag it (as I tested) allocates memory "not far away from here". I agree this is not a strong guarantee, but, as of now, all works perfectly. Also, {{{VirtualAlloc}}}'ed ({{{oc->image}}} is allocated with {{{VirtualAlloc}}}) memory can't be reallocated without explicit new allocation and data copying. Sure, it won't take much to implement all this, but I just can't bring myself to do it right now. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7134#comment:44> 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 21 Jan '14

21 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 simonmar): One thing worries me about this patch: isn't it possible that `VirutalAlloc` will give you some memory that is more than a 32-bit offset away from the source of the jump, which would mean that your trampoline would be too far away? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7134#comment:43> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5987: Too many symbols in ghc package DLL
by GHC 21 Jan '14

21 Jan '14

#5987: Too many symbols in ghc package DLL -------------------------------------+------------------------------------ Reporter: igloo | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.2 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: 3658 | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * milestone: 7.10.1 => 7.8.2 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5987#comment:32> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

21 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: -------------------------------------------+------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: This is now merged. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5144#comment:42> 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 21 Jan '14

21 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): https://ghc.haskell.org/trac/ghc/attachment/ticket/7134/ghc-7.6.3-w64fix2.p… is now relevant, so I change this one too. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2283#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

21 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 Tarrasch): Wow, this is amazing! There's also a discussion tree at reddit: http://www.reddit.com/r/haskell/comments/1vo1se/hacking_ghcs_stack_for_fun_… Tim covers a lot of interesting stuff I have not really had time nor knowledge to dive into. In particular he confronts the difficulties of foreign function calls and receiving signals that don't get turned into Haskell exceptions, like `unsafeWrite v 1000000000 (0 :: Int)` in contrast to `error "rts-aware exception"`. For my thesis work, I'll be sticking with how to handle RTS-aware exceptions. But I'll be enthusiastically following how Tim's ghd is progressing. His README on the github page is a very, very well-written and good read. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3693#comment:54> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0