October 2016 - ghc-tickets

[GHC] #11153: building lens-4.12.3 impossible happened: dupe _hs_primitive_memcpy
by GHC 09 Oct '16

09 Oct '16

#11153: building lens-4.12.3 impossible happened: dupe _hs_primitive_memcpy -----------------------------------------+--------------------------------- Reporter: blippy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 7.10.2 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -----------------------------------------+--------------------------------- I issued the command: stack install lens hoping to upgrade to lens-4.13 and I received the following error log: GHC runtime linker: fatal error: I found a duplicate definition for symbol _hsprimitive_memcpy whilst processing object file C:\apps\HaskellPlatform\7.10.2-a\lib\extralibs\primitive-0.6\HSprimitive-0.6-3d4UsQu7pJCEtlsxN3gLjk.o This could be caused by: * Loading two different object files which export the same symbol * Specifying the same object file twice on the GHCi command line * An incorrect `package.conf' entry, causing some object to be loaded twice. ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for i386-unknown-mingw32): loadObj "C:\\apps\\HaskellPlatform\\7.10.2-a\\lib\\extralibs\\primitive-0.6\\HSprimitive-0.6-3d4UsQu7pJCEtlsxN3gLjk.o": failed Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11153> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #7687: ghc panic on TH and deriveJSON
by GHC 09 Oct '16

09 Oct '16

#7687: ghc panic on TH and deriveJSON -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Template Haskell | Version: 7.4.2 Resolution: invalid | Keywords: TH Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: 3658 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: infoneeded => closed * resolution: => invalid Comment: No information provided in 4 years. Also dynamic linker has been changed. This error case doesn't exist anymore. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7687#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4520: startup code on Windows should use SetDllDirectory("")
by GHC 09 Oct '16

09 Oct '16

#4520: startup code on Windows should use SetDllDirectory("") -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: feature request | Status: closed Priority: low | Milestone: Component: Runtime System | Version: 7.0.1 Resolution: wontfix | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => closed * resolution: => wontfix Comment: I believe the guidance is outdated and doesn't change anything at all. This guidance also predates UAC, which would prevent a non-admin user from writing to the current directory anyway. If the user has admin rights than very little can be done to stop interference. There are numerous other ways to accomplish the same thing without any extra effort. I don't think this change is worth the engineering effort. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4520#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12171: cygwin - option to accept ISO C99... unsupported
by GHC 09 Oct '16

09 Oct '16

#12171: cygwin - option to accept ISO C99... unsupported -------------------------------------+------------------------------------- Reporter: wozgonon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: Building GHC | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Tried to build Haskell under cygwin under Windows 10 (x86_64) but /configure failed. I had a look on google and through the bug tracker but could not find anything helpful. Note that in the output from ./configure check two versions of gcc.exe 1) ... /ghc/inplace/mingw/bin/gcc.exe 2) C:/Program Files/Haskell Platform/8.0.1/lib/../mingw/bin/gcc.exe The check for the first succeeds but that for the second fails yet they both seem to be the same version of gcc.exe: (realgcc.exe (Rev3, Built by MSYS2 project) 5.2.0) {{{ checking for C:/unix/cygwin64/home/jb/haskell/ghc/inplace/mingw/bin/gcc.exe option to accept ISO C99... none needed checking for C:/Program Files/Haskell Platform/8.0.1/lib/../mingw/bin/gcc.exe option to accept ISO C99... unsupported }}} {{{ $ C:/unix/cygwin64/home/jb/haskell/ghc/inplace/mingw/bin/gcc.exe --version realgcc.exe (Rev3, Built by MSYS2 project) 5.2.0 Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. jb@fabulord ~/haskell/ghc $ "C:/Program Files/Haskell Platform/8.0.1/lib/../mingw/bin/gcc.exe" --version realgcc.exe (Rev3, Built by MSYS2 project) 5.2.0 Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12171> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #12654: Panic on interrupting the evaluation of foldl (\x a -> if x > 100 then 100 else x+a) 0 [1..]
by GHC 09 Oct '16

09 Oct '16

#12654: Panic on interrupting the evaluation of foldl (\x a -> if x > 100 then 100 else x+a) 0 [1..] -------------------------------------+------------------------------------- Reporter: Kuros | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Keywords: ghci panic | Operating System: Windows mvar thread block | Architecture: x86_64 | Type of failure: GHCi crash (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Full log below (it only interrupted about a minute after i pressed ctrl-C, and I pressed it several times since it didn't respond): *Main> foldl (\x a -> if x > 100 then 100 else x+a) 0 [1..] Interrupted. *Main> ghc.exe: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-mingw32): thread blocked indefinitely in an MVar operation Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12654> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #12521: Thread blocked indefinitely in an MVar operation
by GHC 09 Oct '16

09 Oct '16

#12521: Thread blocked indefinitely in an MVar operation -------------------------------------+------------------------------------- Reporter: | Owner: SwiftsNamesake | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: GHCi crash (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs C:\Users\Jonatan>ghci GHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. λ> putStrLn "\35753Haskell\25110\32773Ghci\33021\27491\30830\26174\31034\27721\23383\24182\19988\35835\21462\27721\23383\21629\21517\30340\25991\26723" *** Exception: <stdout>: hPutChar: invalid argument (invalid character) λ> λ> λ> λ> λ> λ> λ> chcp 6 ghc.exe: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-unknown-mingw32): thread blocked indefinitely in an MVar operation Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12521> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11591: thread blocked indefinitely in an MVar operation
by GHC 09 Oct '16

09 Oct '16

#11591: thread blocked indefinitely in an MVar operation --------------------------------------+------------------------------- Reporter: PaulNibin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+------------------------------- *Main> take 24 [13,26..] [13,26,39,52,65,78,91,104,117,130,143,156,169,182,195,208,221,234,247,260,273,286,299,312] *Main> cycle [1,2,3] [1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2, *Main> *Main> *Main> *Main> take 10 (cycle [1,2,3]) [1,2,3,1,2,3,1,2,3,1] *Main> take 10 (cycle "Hel) ghc.exe: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-unknown-mingw32): thread blocked indefinitely in an MVar operation Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11591> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #5620: Dynamic linking and threading does not work on Windows
by GHC 09 Oct '16

09 Oct '16

#5620: Dynamic linking and threading does not work on Windows -------------------------------------+------------------------------------- Reporter: Lennart | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.2.1 (Linking) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #10352 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * cc: Phyx- (added) * architecture: x86 => Unknown/Multiple * related: => #10352 * milestone: => 8.2.1 Comment: @dobenour, what you suggested is basically the same as what @rassilon suggested 4 years ago. The answer is it won't work, this redirect would break for references to const data. and GHC makes use of it a lot. Addresses of closures are usually extracted directly from the export table of the rts. Having the redirects would give you the address of the redirect and not the data. So it won't work unless significant rewrites are done. But I believe SxS assemblies does hold the answer. It will be fixed once #10352 is fixed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5620#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5467: Template Haskell: support for Haddock comments
by GHC 09 Oct '16

09 Oct '16

#5467: Template Haskell: support for Haddock comments -------------------------------------+------------------------------------- Reporter: reinerp | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5467#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12206: No exposed API to get full text of ErrMsg
by GHC 09 Oct '16

09 Oct '16

#12206: No exposed API to get full text of ErrMsg -------------------------------------+------------------------------------- Reporter: bit | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In GHC version 7.10.3 it was possible to get the full text of an error message by using the functions `ErrUtils.errMsgShortDoc` and `ErrUtils.errMsgExtraInfo`. But in GHC version 8.0.1 the code has changed. The full text of the error message is stored in the `ErrMsg` field `ErrUtils.errMsgDoc`, but this field is hidden, and there doesn't seem to be any API to access its contents. The only workaround I can find is to use `ErrUtils.pprLocErrMsg`, and then strip out the first line containing the location info, and then manually unindent the 4-space "hang". This is quite ugly. I suggest exporting `ErrUtils.errMsgDoc`, and then for that to be useful the fields of `ErrUtils.ErrDoc` will also be needed. Additionally, `ErrUtils.formatErrDoc` could be a nice bonus to have (and if exported would lessen the need for the `ErrDoc` fields). The GHC API changes on every GHC release, so since backwards compatibility is not an issue, it would seem that there is no need to have a carefully exposed API, and there is no danger in liberally exporting stuff that clients could potentially find useful. Thank you -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12206> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6