- ghc-tickets - Haskell.org

[GHC] #11040: Split SRT tables on Mac OS
by GHC 11 Jan '17

11 Jan '17

#11040: Split SRT tables on Mac OS ----------------------------------------+--------------------------------- Reporter: olsner | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- Split off from https://phabricator.haskell.org/D1242#inline-11490 Mac uses subsections via symbols to allow dead code stripping, but doesn't seem to do anything special with the SRT tables (in `HscMain.doCodeGen`), so either I'm missing something or Mac doesn't actually get much useful dead code stripping at all from the subsections feature because the SRT tables would keep everything alive. Perhaps Mac should just always do SRT splitting. Looks like you need to manually add `-optl-Wl,-dead_strip` to test this, since that's not enabled by default. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11040> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12958: Properly detect if GHCi is running in MinTTY
by GHC 11 Jan '17

11 Jan '17

#12958: Properly detect if GHCi is running in MinTTY -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: GHCi | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Since the user experience of GHCi is known to be rather poor when run in MinTTY (e.g., see #12720), GHCi emits a warning when it thinks it's being run in a terminal that uses MinTTY (such as Cygwin or MSYS2). [http://git.haskell.org/ghc.git/blob/17ac9b19438d5e8f6de33f99828e8c0e7c8c112… Here] is the code that checks for this in `ghci.c`: {{{#!c if (getenv("_")) { printf("WARNING: GHCi invoked via 'ghci.exe' in *nix-like shells (cygwin-bash, in particular)\n"); printf(" doesn't handle Ctrl-C well; use the 'ghcii.sh' shell wrapper instead\n"); fflush(stdout); } }}} This is a rather shoddy way to detect MinTTY's presence, however. It's quite easy to define an environmental variable named `_` in terminals that don't use MinTTY (e.g., ConEmu). After seeing Phab:D2809, I learned of a much more reliable way to detect for MinTTY's presence: {{{#!hs queryCygwinTerminal :: Win32.HANDLE -> IO Bool queryCygwinTerminal h = do fileType <- Win32.getFileType h if fileType /= Win32.fILE_TYPE_PIPE then pure False else do fn <- getFileNameByHandle h pure (("\\cygwin-" `isPrefixOf` fn || "\\msys-" `isPrefixOf` fn) && "-pty" `isInfixOf` fn && "-master" `isSuffixOf` fn) `catch` \ (_ :: IOError) -> pure False getFileNameByHandle :: Win32.HANDLE -> IO String getFileNameByHandle h = do let sizeOfDWORD = sizeOf (undefined :: Win32.DWORD) let sizeOfWchar = sizeOf (undefined :: CWchar) -- note: implicitly assuming that DWORD has stronger alignment than wchar_t let bufSize = sizeOfDWORD + mAX_PATH * sizeOfWchar allocaBytes bufSize $ \ buf -> do getFileInformationByHandleEx h fileNameInfo buf (fromIntegral bufSize) len :: Win32.DWORD <- peek buf let len' = fromIntegral len `div` sizeOfWchar peekCWStringLen (buf `plusPtr` sizeOfDWORD, min len' mAX_PATH) getFileInformationByHandleEx :: Win32.HANDLE -> CInt -> Ptr a -> Win32.DWORD -> IO () getFileInformationByHandleEx h cls buf bufSize = do lib <- Win32.getModuleHandle (Just "kernel32.dll") ptr <- Win32.getProcAddress lib "GetFileInformationByHandleEx" let c_GetFileInformationByHandleEx = mk_GetFileInformationByHandleEx (castPtrToFunPtr ptr) Win32.failIfFalse_ "getFileInformationByHandleEx" (c_GetFileInformationByHandleEx h cls buf bufSize) type F_GetFileInformationByHandleEx a = Win32.HANDLE -> CInt -> Ptr a -> Win32.DWORD -> IO Win32.BOOL foreign import WINAPI "dynamic" mk_GetFileInformationByHandleEx :: FunPtr (F_GetFileInformationByHandleEx a) -> F_GetFileInformationByHandleEx a }}} We should port this to C and use this in `ghci.c` instead of what we have now. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12958> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #1791: heap overflow should generate an exception
by GHC 11 Jan '17

11 Jan '17

#1791: heap overflow should generate an exception -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: feature request | Status: patch Priority: normal | Milestone: ⊥ Component: Runtime System | Version: 6.8 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: outofmem2 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2790 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"12ad4d417b89462ba8e19a3c7772a931b3a93f0e/ghc" 12ad4d4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="12ad4d417b89462ba8e19a3c7772a931b3a93f0e" Throw an exception on heap overflow This changes heap overflow to throw a HeapOverflow exception instead of killing the process. Test Plan: GHC CI Reviewers: simonmar, austin, hvr, erikd, bgamari Reviewed By: simonmar, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2790 GHC Trac Issues: #1791 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1791#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13094: Poor register allocation and redundant moves when using `foreign import prim`
by GHC 10 Jan '17

10 Jan '17

#13094: Poor register allocation and redundant moves when using `foreign import prim` ----------------------------------------+--------------------------------- Reporter: jberryman | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #12232 Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- This may well be the same as #12232 but I didn't want to risk hijacking that one. I've been looking at the dumped asm from a library where I use `foreign import prim` to call a simple assembly routine (that may be irrelevant). I see many `movq` instructions, and when I traced them by hand many or most seemed superfluous saving and restoring of registers. Here is a contiguous and mostly self-contained snippet of the assembly, with notes. I have four values I'm interested in V0, V1, V2, V3 which I started tracing at the note "registers good for sipRound_s_x2 at this point". Below I specifically follow V3 through the assmebly, marking lines with {{{"*** V3 ***"}}}, and the moves don't seem sensible to my (untrained) eye: {{{ _c7Ns: movq %r9,%rbx movq %rax,%r9 movq %r8,%rax ; *** V3 *** movq %rbx,%r8 movq %rdi,%rbx movq %rax,%rdi ; *** V3 (back to rdi!) *** movq %rsi,%rax movq %rbx,%rsi movq %r14,%rbx movq %rax,%r14 movq %rcx,16(%rbp) addq $16,%rbp jmp *8(%rbp) .align 8 .quad 836 .quad 32 block_info: _c7Nk: movq 16(%rbp),%rax movq $8,16(%rbp) movq 24(%rbp),%rcx incq %rcx movq %rcx,24(%rbp) movq 32(%rbp),%rdx incq %rdx movq %rdx,32(%rbp) xorq 8(%rbp),%rbx addq $16,%rbp movl $8,%r8d xorl %r9d,%r9d _n7T1: movq %rax,64(%rsp) movq %r8,%rax ; --- registers good for sipRound_s_x2 at this point ------ movq %rdi,%r8 ; moving V3 *OUT* of rdi *** V3 *** movq %rsi,%rdi ; moving V2 *OUT* of rdi movq %r14,%rsi ; moving V1 *OUT* of r14 movq %rbx,%r14 ; moving V0 *OUT* of rbx movq 64(%rsp),%rbx _c7My: ; (NOTE: there are a few jumps to here from other sections not included here) cmpq 24(%rbx),%rdx je _c7Ns _c7Nr: movq 16(%rbx),%r10 movzbl (%r10,%rdx,1),%r10d cmpq $1,%rax jne _c7N9 _c7Nl: movq $block_info,-16(%rbp) shlq $8,%r9 orq %r10,%r9 ;----- at this point (name: register): V0: r14, V1: rsi, V2: rdi, V3: r8 movq %rdi,%rax ; save rdi, trying to be rsi movq %r8,%rdi ; prepared rdi(V3) *** V3 *** xorq %r9,%rdi movq %rsi,%rcx movq %rax,%rsi ; prepared rsi(V2) movq %r14,%rax movq %rcx,%r14 ; prepared r14(V1) movq %rbx,%rcx movq %rax,%rbx ; prepared rbx(V0) movq %r9,-8(%rbp) movq %rcx,(%rbp) addq $-16,%rbp jmp sipRound_s_x2 .align 8 .quad 1733 .quad 32 block_info: _c7N2: movq 24(%rbp),%rax movq $7,24(%rbp) movq 32(%rbp),%rcx incq %rcx movq %rcx,32(%rbp) movq 40(%rbp),%rdx incq %rdx movq %rdx,40(%rbp) movq 16(%rbp),%r8 xorq 8(%rbp),%rbx addq $24,%rbp movl $7,%r9d _n7T2: movq %rax,64(%rsp) movq %r9,%rax movq %r8,%r9 movq %rdi,%r8 movq %rsi,%rdi movq %r14,%rsi movq %rbx,%r14 movq 64(%rsp),%rbx jmp _c7My _c7N9: cmpq $1,%rax jbe _c7N3 _c7MW: decq %rax movq %rax,(%rbp) incq %rcx movq %rcx,8(%rbp) incq %rdx movq %rdx,16(%rbp) shlq $8,%r9 orq %r10,%r9 jmp _c7My _c7N3: movq $block_info,-24(%rbp) movq %rdi,%rax movq %r8,%rdi ; *** V3 (back to rdi!) *** xorq %r9,%rdi movq %rsi,%rcx movq %rax,%rsi movq %r14,%rax movq %rcx,%r14 movq %rbx,%rcx movq %rax,%rbx movq %r9,-16(%rbp) movq %r10,-8(%rbp) movq %rcx,(%rbp) addq $-24,%rbp jmp sipRound_s_x2 .size $whashRemainingBytes_info, .-$whashRemainingBytes_info }}} This is my first time looking closely at assembly, so maybe this is normal or no big deal performance-wise (I haven't gotten around to trying to correlate number of moves with performance of my variations yet), or I'm missing something obvious. I wasn't able to make sense of an objdump-ed version of the llvm-compiled program. The code for the version where the same {{{sipRound}}} stuff is implemented in normal haskell also has a lot of moves (even more in fact), but they seem interspersed throughout and are less easy to sort through, e.g. a random snippet: {{{ xorq %rdi,%r8 movq %r14,%rdi shrq $32,%rdi shlq $32,%r14 orq %rdi,%r14 addq %r8,%r14 movq %r14,%rdi addq %rsi,%rdi movq %rsi,%r10 shrq $51,%r10 shlq $13,%rsi orq %r10,%rsi xorq %rdi,%rsi movq %r8,%r10 shrq $43,%r10 shlq $21,%r8 orq %r10,%r8 xorq %r14,%r8 movq %rax,%r10 shrq $32,%r10 shlq $32,%rax orq %r10,%rax addq %r8,%rax movq %rax,%r10 }}} Intuitively this is also bad, after all the haskell we're compiling looks almost trivially like the good assembly we'd like/expect (although perhaps {{{rotl}}} is shaking things up here, as we have to implement it with two shifts and an OR): {{{#!hs -- in the Identity monad do v0 <- return $ v0 + v1 v1 <- return $ rotl v1 13 v1 <- return $ v1 `xor` v0 v0 <- return $ rotl v0 32 v2 <- return $ v2 + v3 v3 <- return $ rotl v3 16 v3 <- return $ v3 `xor` v2 v0 <- return $ v0 + v3 v3 <- return $ rotl v3 21 v3 <- return $ v3 `xor` v0 }}} You can check out the branch here, which I'll keep at 838b27a: https://github.com/jberryman/hashabler/tree/saved-branch-exhibiting- seemingly-bad-register-allocation You can build and observe the assembly with: {{{ $ cabal configure -fdev --enable-benchmarks && cabal build core $ gvim ./dist/build/core/core-tmp/core.dump-asm }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13094> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11551: Get doctests into testsuite
by GHC 10 Jan '17

10 Jan '17

#11551: Get doctests into testsuite -------------------------------------+------------------------------------- Reporter: lwm | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Core | Version: 7.10.3 Libraries | Keywords: | Operating System: Unknown/Multiple documentation, doctest | Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It seems like a bit of a shame not to have Mr.Orlitzky's lovely doctests not running with the testsuite. Or perhaps to at least have some sort of `make doctest`. If there is some interest to get this working, I'd like to take a look at submitting a patch. Here are the previous documentation patches I can find: https://phabricator.haskell.org/p/mjo/ I can see the following files that have doctests: {{{ ruby-2.2.1 ~/work/contributing/ghc (master) [12:35:44] lwm$ grep -R "=== __Examples__" libraries/base/ | uniq grep: libraries/base/Data/Maybe.hs:-- ==== __Examples__ libraries/base/Data/Either.hs:-- ==== __Examples__ libraries/base/Data/List.hs:-- ==== __Examples__ libraries/base/Data/Functor.hs:-- ==== __Examples__ libraries/base/Data/Bool.hs:-- ==== __Examples__ libraries/base/Data/Char.hs:-- ==== __Examples__ libraries/base/GHC/Unicode.hs:-- ==== __Examples__ libraries/base/Text/Printf.hs:-- ==== __Examples__ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11551> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8761: Make pattern synonyms work with Template Haskell
by GHC 10 Jan '17

10 Jan '17

#8761: Make pattern synonyms work with Template Haskell ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Template Haskell has no support for pattern synonyms. This should be added. Specifically: * Create syntax in `Language.Haskell.TH.Syntax` and corresponding functions in `Language.Haskell.TH.Lib` * Support in !DsMeta for desugaring pattern synonym quotations. See `rep_bind`. * Support in Convert for splicing in pattern synonyms. * Support in !TcSplice for reifying pattern synonyms. See `reifyThing`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8761> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 26

Re: [GHC] #6087: Join points need strictness analysis
by GHC 10 Jan '17

10 Jan '17

#6087: Join points need strictness analysis -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by lukemaurer): This seems to have gone away; AFAICT, nowadays the join point is never created. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6087#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13083: Constraint solving failure with Coercible + type family + newtype
by GHC 10 Jan '17

10 Jan '17

#13083: Constraint solving failure with Coercible + type family + newtype -------------------------------------+------------------------------------- Reporter: conal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: Coercible | Operating System: MacOS X Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm getting a type error using `coerce` to remove the wrapper of a `newtype` specialization involving a the following. See below for the smallest example I was able to construct. {{{#!hs {-# LANGUAGE TypeOperators #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE UndecidableInstances #-} {-# OPTIONS_GHC -Wall #-} -- | Bug(?) in Coercible constraint solving -- module B2 where import GHC.Generics (Par1(..),(:*:)(..)) import GHC.Exts (coerce) -- Representation as free vector space type family V (a :: *) :: * -> * type instance V Float = Par1 type instance V (a,b) = V a :*: V b type instance V (Par1 a) = V a type instance V ((f :*: g) a) = V (f a, g a) -- • Variable ‘a’ occurs more often -- in the type family application ‘V (f a, g a)’ -- than in the instance head -- (Use UndecidableInstances to permit this) type R = Float -- Linear map in row-major order newtype L a b = L (V b (V a R)) -- Use coerce to drop newtype wrapper bar :: L a b -> V b (V a R) bar = coerce {-------------------------------------------------------------------- Bug demo --------------------------------------------------------------------} -- A rejected type specialization of bar with a ~ (R,R), b ~ (Par1 R,R) foo :: L (R,R) (Par1 R,R) -> V (Par1 R,R) (V (R,R) R) foo = coerce -- • Couldn't match representation of type ‘V Par1’ -- with that of ‘Par1’ -- arising from a use of ‘coerce’ -- Note that Par1 has the wrong kind (* -> *) for V Par1 -- Same error: -- -- foo :: (a ~ (R,R), b ~ (Par1 R,R)) => L a b -> V b (V a R) -- The following similar signatures work: -- foo :: L (R,R) (R,Par1 R) -> V (R,Par1 R) (V (R,R) R) -- foo :: L (Par1 R,R) (R,R) -> V (R,R) (V (Par1 R,R) R) -- Same error: -- -- Linear map in column-major order -- newtype L a b = L (V a (V b s)) -- foo :: L (R,R) (Par1 R,R) -> V (R,R) (V (Par1 R,R) R) -- foo = coerce }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13083> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #7353: Make system IO interruptible on Windows
by GHC 10 Jan '17

10 Jan '17

#7353: Make system IO interruptible on Windows -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: refold Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Core Libraries | Version: 7.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Great, thanks @refold, I'll take a look and let you know. I'm certainly planning on trying to get it into the tree. We can just branch it off for now. I want to use this as a basis for the other I/O changes in GHC. Would be a shame to let all this work go to waste :) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7353#comment:35> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13084: 'foreign import prim' are marked PlaySafe by the parser
by GHC 09 Jan '17

09 Jan '17

#13084: 'foreign import prim' are marked PlaySafe by the parser -------------------------------------+------------------------------------- Reporter: jberryman | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: -------------------------------------+------------------------------------- Experimenting with a {{{foreign import prim}}} in my code I noticed the generated core produces {{{__pkg_ccall_GC}}} which concerned me since I thought perhaps we were experiencing the overhead of a "safe" ccall. Reid Barton reccommended filing a report, commenting: it looks like prim imports are marked PlaySafe by the parser, which is presumably mostly ignored, and definitely ignored during code generation. But wherever it's not ignored there could be a bug see: http://stackoverflow.com/questions/41528208/why-is-there-no-foreign- import-prim-unsafe -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13084> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2