- ghc-tickets - Haskell.org

[GHC] #10707: -fth-dec-file outputs invalid case clauses
by GHC 30 Jan '16

30 Jan '16

#10707: -fth-dec-file outputs invalid case clauses -------------------------------------+------------------------------------- Reporter: Fabian | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #10701 Differential Revisions: | -------------------------------------+------------------------------------- instance Data.Aeson.Types.Class.ToJSON Language.Haskell.TH.Syntax.Name where Data.Aeson.Types.Class.toJSON x = \ k_a94l v_a94m -> case k_a94l of { GHC.Base.Just "" -> GHC.Err.undefined GHC.Base.Nothing -> GHC.Err.undefined } (GHC.Base.Just "test") "test2" -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10707> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #11507: `GHC.Base.eqString`'s documentation is messed up
by GHC 29 Jan '16

29 Jan '16

#11507: `GHC.Base.eqString`'s documentation is messed up -------------------------------------+------------------------------------- Reporter: czipperz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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: -------------------------------------+------------------------------------- Reads: {{{#!hs {-# RULES "eqString" (==) = eqString #-} -- eqString also has a BuiltInRule in PrelRules.lhs: -- eqString (unpackCString# (Lit s1)) (unpackCString# (Lit s2) = s1==s2 }}} The problem is that the string at `(unpackCString# (Lit s2) =` is unclosed (should be `(unpackCString# (Lit s2))`). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11507> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11482: Turn -fdefer-typed-holes on by default
by GHC 29 Jan '16

29 Jan '16

#11482: Turn -fdefer-typed-holes on by default -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #9497, #11481 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- From http://www.devalot.com/articles/2013/07/why-haskell.html: You can, however, return an `undefined` value which when evaluated will terminate the program. Haskell programmers use this to stub out parts of the program during development and they’re easy to detect during a production build.↩ That's terrible, they should be using typed holes! Hypothesis: because `ghc -fdefer-typed-holes Test.hs` is annoying to type, haskellers currently reach for `undefined` instead of typed holes (i.e. `_`), to mark the part of their code that isn't finished yet. Richard writes in ticket:9497#comment:2: I'm -1 on [enabling -fdefer-typed-holes by default]. It seems to invite the possibility that holes could make their way into released code. That's true, but the alternative is worse: developers keep using `undefined` instead of typed holes. Since ghc doesn't show any warnings for using `undefined` (#8064), we should make it as easy as possible to use typed holes, which does always show a warning (unless explicitly suppressed). Having to specify a command-line flag is too high a barrier (since `undefined` is so well known and easy to use) Proposal: * ghc turns `-fdefer-typed-holes` on by default. * build scripts specify `-fno-defer-typed-holes` to make sure no holes make it into releases. * we encourage everyone to use `_` instead of `undefined`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11482> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11506: uType_defer can defer too long
by GHC 29 Jan '16

29 Jan '16

#11506: uType_defer can defer too long -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- Here is the test case: {{{ {-# LANGUAGE PolyKinds, ExistentialQuantification, ScopedTypeVariables, TypeFamilies, TypeInType #-} module Bug where import Data.Proxy import Data.Kind type family ProxyType where ProxyType = (Proxy :: Type -> Type) data T = forall a. MkT (ProxyType a) foo (MkT (_ :: Proxy a)) = const True (undefined :: a) }}} This should be accepted. But I get {{{ Bug.hs:13:53: error: • Expected a type, but ‘a’ has kind ‘k10’ • In an expression type signature: a In the second argument of ‘const’, namely ‘(undefined :: a)’ In the expression: const True (undefined :: a) }}} Why should it be accepted? GHC can infer that the existential `a` in `MkT` has kind `Type`. (Indeed this works.) Then, we should unify the pattern signature `Proxy k1 a1` with `ProxyType a2`; the latter expands to `Proxy Type a2` and we get `k1 := Type` and `a1 := a2`, allowing `undefined :: a` to be accepted. Why doesn't it work? When checking the pattern type signature in `foo`, GHC then checks if `ProxyType a2` is a subtype of `Proxy k1 a1`. This check is deferred because of the type family. In a short while, GHC needs to know that `a` has kind `Type` to make sure that `undefined :: a` is well-typed. At this point, it doesn't know that `a` has kind `Type` (because the unification was deferred), and so an error is issued. I'm not sure how to resolve this. This is indeed a consequence of `TypeInType`, but it seems more to do with solver engineering than the new `TypeInType` stuff. And there is an easy workaround: just add a kind signature. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11506> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #11486: info tables are no longer aligned
by GHC 29 Jan '16

29 Jan '16

#11486: info tables are no longer aligned -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- Take a simple program like {{{ main = mapM_ print "Hello, world" }}} and build with `-O`. Versions of ghc as late as 7.11.20150806 generate assembly that includes {{{ ... _c3mn: movq $sat_s3m2_info,-16(%r12) movq %r14,(%r12) movq $block_c3mi_info,-16(%rbp) movl $GHC.Types.True_closure+2,%edi movq %rsi,%rax leaq -16(%r12),%rsi movl $GHC.IO.Handle.FD.stdout_closure,%r14d movq %rax,-8(%rbp) addq $-16,%rbp jmp GHC.IO.Handle.Text.hPutStr2_info .text .align 8 .quad 1 .quad 32 block_c3mi_info: _c3mi: movq 8(%rbp),%rbx addq $16,%rbp jmp stg_ap_v_fast ... }}} Note the `.align 8` ensuring that the info table (and the code `_c3mi` itself) is 8-byte aligned. In 8.1.20160107 we instead get {{{ _c5gE: movq $sat_s5g9_info,-16(%r12) movq %r14,(%r12) movq $block_c5gz_info,-16(%rbp) movl $GHC.Types.True_closure+2,%edi movq %rsi,%rax leaq -16(%r12),%rsi movl $GHC.IO.Handle.FD.stdout_closure,%r14d movq %rax,-8(%rbp) addq $-16,%rbp jmp GHC.IO.Handle.Text.hPutStr2_info _c5gF: movq $24,904(%r13) _c5gC: movl $Main.main2_closure,%ebx jmp *-8(%r13) .quad 1 .quad 32 block_c5gz_info: _c5gz: movq 8(%rbp),%rbx addq $16,%rbp jmp stg_ap_v_fast .size Main.main2_info, .-Main.main2_info }}} There is some minor rearrangement, but more importantly there is no longer any `.align 8` before `.quad 1`. That means the info table is not necessarily aligned, and indeed `c5gz_info` ended up at the address `40676f`. I'm guessing this is bad for performance, though I don't know how bad. I'm pretty sure this is due to 4a32bf925b8aba7885d9c745769fe84a10979a53 "Implement function-sections for Haskell code" though I haven't looked at that commit in detail. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11486> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

Re: [GHC] #5654: Profiling semantics bug
by GHC 28 Jan '16

28 Jan '16

#5654: Profiling semantics bug -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: low | Milestone: Component: Profiling | Version: 7.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | profiling/should_run/scc004 Blocked By: | Blocking: Related Tickets: #10007 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): Commit that nomeata mentioned in comment:10 (Phab:D1821 actually): commit f42db1574935b088cfc13cca7c935990002651dc {{{ Author: Joachim Breitner <mail(a)joachim-breitner.de> Date: Sat Jan 23 13:12:10 2016 +0100 Remove unused IND_PERM it seems that this closure type has not been in use since 5d52d9, so all this is dead and untested code. This removes it. Some of the code might be useful for a counting indirection as described in #10613, so when implementing that, have a look at what this commit removes. Test Plan: validate on harbormaster Reviewers: austin, bgamari, simonmar Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1821 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5654#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11481: New GHCi command `:load!` doesn't defer typed holes
by GHC 28 Jan '16

28 Jan '16

#11481: New GHCi command `:load!` doesn't defer typed holes -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.10.3 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: -------------------------------------+------------------------------------- Test.hs: {{{#!hs f :: Int f = _ main = print f }}} {{{ $ ghc-8.0.1 --interactive GHCi, version 8.0.0.20160111: http://www.haskell.org/ghc/ :? for help Prelude> :load! Test.hs [1 of 1] Compiling Main ( Test.hs, interpreted ) Test.hs:2:5: error: • Found hole: _ :: Int • In the expression: _ In an equation for ‘f’: f = _ • Relevant bindings include f :: Int (bound at Test.hs:2:1) Failed, modules loaded: none. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11481> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #11500: C finalizer of a finalized ForeignPtr may be called again when RTS shuts down
by GHC 27 Jan '16

27 Jan '16

#11500: C finalizer of a finalized ForeignPtr may be called again when RTS shuts down -------------------------------------+------------------------------------- Reporter: skydust | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.8.3 System | 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: -------------------------------------+------------------------------------- The C finalizer of a ForeignPtr that was explicitly finalized (finalizeForeignPtr) is sometimes called again when the RTS shuts down. Expected behaviour: - The test script (./test.sh) below never stops Observed behaviour: - After a while, the test script stops with an error message indicating double free or memory corruption {{{#!sh $ ./test.sh }}} {{{ [1 of 1] Compiling Main ( finalizer_hs.hs, finalizer_hs.o ) Linking finalizer_hs ... *** Error in `./finalizer_hs': double free or corruption (!prev): 0x00000000010b85e0 *** ./test.sh: line 3: 20482 Aborted (core dumped) ./finalizer_hs +RTS -N 178 }}} File finalizer_hs.hs {{{#!hs {-# LANGUAGE ForeignFunctionInterface #-} import Foreign (Ptr, FunPtr, malloc) import Foreign.ForeignPtr (newForeignPtr, finalizeForeignPtr) import Control.Monad (forM, forM_) foreign import ccall "stdlib.h &free" p_free :: FunPtr (Ptr a -> IO ()) main :: IO () main = do fps <- forM [1 .. 10000] $ \_ -> do p <- malloc newForeignPtr p_free (p :: Ptr Int) forM_ fps finalizeForeignPtr }}} File test.sh: {{{#!sh ghc finalizer_hs.hs -threaded CNT=0 while ./finalizer_hs +RTS -N; do CNT=$((CNT+1)); done echo $CNT }}} Note: running several instances of ./test.sh concurrently triggers the problem faster Issue detected on following tested setups: - Linux 32bit GHC 7.10.2 - Linux 64bit GHC 7.8.3 - Linux 64bit GHC 7.8.4 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11500> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #5654: Profiling semantics bug
by GHC 27 Jan '16

27 Jan '16

#5654: Profiling semantics bug -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: low | Milestone: Component: Profiling | Version: 7.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | profiling/should_run/scc004 Blocked By: | Blocking: Related Tickets: #10007 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Marlow <marlowsd@…>): In [changeset:"85daac593c498f581d46f44982ee5dcf1001f611/ghc" 85daac5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="85daac593c498f581d46f44982ee5dcf1001f611" Fix cost-centre-stack bug when creating new PAP (#5654) See comment in `AutoApply.h`. This partly fixes #5654. New test added, and renamed the old test to match the ticket number. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5654#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9105: Profiling binary consumes CPU even when idle on Linux.
by GHC 27 Jan '16

27 Jan '16

#9105: Profiling binary consumes CPU even when idle on Linux. ----------------------------+--------------------------------- Reporter: robinp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+--------------------------------- The program is main = forever $ threadDelay 1000000 >> return () . Compiled with 32bit GHC 7.6.3 or 7.8.2 on Debian (inside a VM), GHC 7.4.1 on Ubuntu (not VM). The non-profiling binary doesn't consume CPU, the profiling does ~10% (of a 2Ghz machine). Running with +RTS -I0, so this is not the idle gc. When strace-ing, the profiling one seems to receive a constant flow of SIGVTALRM, while the normal receives one burst each second. I see I can switch off "master tick interval" with -V0, and then CPU is not used, but the consequences of this are not very well documented (apart from context switching becoming deterministic). Interestingly, if I compile using profiling on Windows (latest haskell- platform, 64bit), it doesn't use more CPU than the non-profiling. So, the question is, why does this happen on Linux, and if it can be avoided somehow. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9105> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11