- ghc-tickets - Haskell.org

[GHC] #12966: GHC panics with forall and constraint
by GHC 15 Dec '16

15 Dec '16

#12966: GHC panics with forall and constraint -------------------------------------+------------------------------------- Reporter: xcmw | 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: -------------------------------------+------------------------------------- {{{ λ> type Maybeify c = forall d. (c d) => ((~) (Maybe d)) <interactive>:2:39: error:ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-apple-darwin): print_equality ~ Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12966> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #5654: Profiling semantics bug
by GHC 15 Dec '16

15 Dec '16

#5654: Profiling semantics bug -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: closed Priority: low | Milestone: 8.2.1 Component: Profiling | Version: 7.2.1 Resolution: fixed | 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.2.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5654#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5205: Control.Monad.forever leaks space
by GHC 15 Dec '16

15 Dec '16

#5205: Control.Monad.forever leaks space --------------------------------------------+------------------------------ Reporter: akio | Owner: pcapriotti Type: bug | Status: closed Priority: high | Milestone: 7.6.1 Component: libraries/base | Version: 7.0.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime performance bug | Test Case: T5205 Blocked By: | Blocking: Related Tickets: | --------------------------------------------+------------------------------ Comment (by Ben Gamari <ben@…>): In [changeset:"d39816285341cf639b51ae14f65c63a3e89bba95/ghc" d398162/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d39816285341cf639b51ae14f65c63a3e89bba95" testsuite: Separate out Windows results for T5205 This test seems to have much different allocation behavior on Windows and Linux. Previously we had widened the acceptance window to 7% to accomodate this, but even this isn't enough any more. Instead of further widening the window let's just give an expected number for each platform. Really, this is precisely the issue with our performance testing model which I've been complaining about in #12758. Fixes test for #5205 on 64-bit Windows. Test Plan: Validate on Windows Reviewers: austin Subscribers: thomie, Phyx Differential Revision: https://phabricator.haskell.org/D2848 GHC Trac Issues: #5205 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5205#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5654: Profiling semantics bug
by GHC 15 Dec '16

15 Dec '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 Ben Gamari <ben@…>): In [changeset:"394231b301efb6b56654b0a480ab794fe3b7e4db/ghc" 394231b3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="394231b301efb6b56654b0a480ab794fe3b7e4db" Fix cost-centre-stacks bug (#5654) This fixes some cases of wrong stacks being generated by the profiler. For background and details on the fix see `Note [Evaluating functions with profiling]` in `rts/Apply.cmm`. This does have an impact on allocations for some programs when profiling. nofib results: ``` k-nucleotide +0.0% +8.8% +11.0% +11.0% 0.0% puzzle +0.0% +12.5% 0.244 0.246 0.0% typecheck 0.0% +8.7% +16.1% +16.2% 0.0% ------------------------------------------------------------------------ -------- Min -0.0% -0.0% -34.4% -35.5% -25.0% Max +0.0% +12.5% +48.9% +49.4% +10.6% Geometric Mean +0.0% +0.6% +2.0% +1.8% -0.3% ``` But runtimes don't seem to be affected much, and the examples I looked at were completely legitimate. For example, in puzzle we have this: ``` position :: ItemType -> StateType -> BankType position Bono = bonoPos position Edge = edgePos position Larry = larryPos position Adam = adamPos ``` where the identifiers on the rhs are all record selectors. Previously the profiler gave a stack that looked like ``` position bonoPos ... ``` i.e. `bonoPos` was at the same level of the call stack as `position`, but now it looks like ``` position bonoPos ... ``` I used the normaliser from the testsuite to diff the profiling output from other nofib programs and they all looked better. Test Plan: * the broken test passes * validate * compiled and ran all of nofib, measured perf, diff'd several .prof files Reviewers: niteria, erikd, austin, scpmw, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2804 GHC Trac Issues: #5654, #10007 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5654#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9890: RTS -qa option is helpful but under-documented
by GHC 15 Dec '16

15 Dec '16

#9890: RTS -qa option is helpful but under-documented -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | Documentation bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The entire documentation for the RTS `-qa` option is Use the OS's affinity facilities to try to pin OS threads to CPU cores. This is an experimental feature, and may or may not be useful. Please let us know whether it helps for you! It does help for us: enabling it on a multithreaded, moderately GC-heavy web server led to a sizeable improvement (~20%) in throughput benchmarks. However, it would be nice if the GHC documentation was a little more descriptive about what exactly this option does and how experimental it is now considered! (Relatedly, perhaps it would be worth adding a single index of RTS options in the user's guide, much like the flag reference for GHC itself.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9890> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #8440: Get rid of the remaining static flags
by GHC 15 Dec '16

15 Dec '16

#8440: Get rid of the remaining static flags -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: task | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2839 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D2839 Comment: Yay, hsyl20 picked this up! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8440#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12977: Template Haskell: unboxedTupleTypeName doesn't handle unboxed 0- and 1-tuples
by GHC 15 Dec '16

15 Dec '16

#12977: Template Haskell: unboxedTupleTypeName doesn't handle unboxed 0- and 1-tuples -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.0.1 Haskell | 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: -------------------------------------+------------------------------------- GHC has a notion of unboxed 0-tuples and 1-tuples: {{{ λ> :set -XUnboxedTuples λ> :k (##) (##) :: TYPE 'GHC.Types.VoidRep λ> :k (# Int #) (# Int #) :: TYPE 'GHC.Types.UnboxedTupleRep }}} But it is impossible to acquire the `Name`s of these type constructors using `unboxedTupleTypeName` from `template-haskell`: {{{ λ> :set -XTemplateHaskell λ> :m + Language.Haskell.TH Language.Haskell.TH.Syntax λ> :k $(conT (unboxedTupleTypeName 0)) <interactive>:1:1: error: • Exception when trying to run compile-time code: unboxedTupleTypeName 0 CallStack (from HasCallStack): error, called at libraries/template- haskell/Language/Haskell/TH/Syntax.hs:1179:26 in template- haskell:Language.Haskell.TH.Syntax Code: conT (unboxedTupleTypeName 0) • In the untyped splice: $(conT (unboxedTupleTypeName 0)) λ> :k $(conT (unboxedTupleTypeName 1)) <interactive>:1:1: error: • Exception when trying to run compile-time code: unboxedTupleTypeName 1 CallStack (from HasCallStack): error, called at libraries/template- haskell/Language/Haskell/TH/Syntax.hs:1180:26 in template- haskell:Language.Haskell.TH.Syntax Code: conT (unboxedTupleTypeName 1) • In the untyped splice: $(conT (unboxedTupleTypeName 1)) }}} And similarly for `unboxedTupleDataName`. This is because of [http://git.haskell.org/ghc.git/blob/9c9a2229fe741c55a8fb8d0c6380ec066a77722… /template-haskell/Language/Haskell/TH/Syntax.hs#l1184 silly restrictions] put in place on the definitions of `unboxedTupleTypeName` and `unboxedTupleDataName` within `template-haskell`: {{{#!hs -- Unboxed tuple data and type constructors -- | Unboxed tuple data constructor unboxedTupleDataName :: Int -> Name -- | Unboxed tuple type constructor unboxedTupleTypeName :: Int -> Name unboxedTupleDataName 0 = error "unboxedTupleDataName 0" unboxedTupleDataName 1 = error "unboxedTupleDataName 1" unboxedTupleDataName n = mk_unboxed_tup_name (n-1) DataName unboxedTupleTypeName 0 = error "unboxedTupleTypeName 0" unboxedTupleTypeName 1 = error "unboxedTupleTypeName 1" unboxedTupleTypeName n = mk_unboxed_tup_name (n-1) TcClsName }}} It should be possible to lift this restriction. I'll work on this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12977> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #7289: Mingw FPU init not Windows compatible.
by GHC 15 Dec '16

15 Dec '16

#7289: Mingw FPU init not Windows compatible. -------------------------------------+------------------------------------- Reporter: Lennart | Owner: Phyx- Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 7.2.2 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2819 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7289#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10614: Show constraints in ``Found hole...''
by GHC 15 Dec '16

15 Dec '16

#10614: Show constraints in ``Found hole...'' -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Currently it is not clear when types are known equal. Consider writing castWith: {{{#!hs {-# LANGUAGE GADTs , TypeOperators #-} import Data.Type.Equality hiding (castWith) castWith :: a :~: b -> a -> b castWith Refl x = _ }}} which results in {{{ TypeEq.hs:5:19: error: Found hole: _ :: b Where: ‘b’ is a rigid type variable bound by the type signature for: castWith :: a :~: b -> a -> b at TypeEq.hs:4:13 Relevant bindings include x :: a (bound at TypeEq.hs:5:15) castWith :: a :~: b -> a -> b (bound at TypeEq.hs:5:1) In the expression: _ In an equation for ‘castWith’: castWith Refl x = _ }}} Filling the hole with x is correct, but it is not clear from the message that GHC knows this. It would be useful to have a section "Constraints include" e.g. {{{ TypeEq.hs:5:19: error: Found hole: _ :: b Where: ‘b’ is a rigid type variable bound by the type signature for: castWith :: a :~: b -> a -> b at TypeEq.hs:4:13 Relevant bindings include x :: a (bound at TypeEq.hs:5:15) castWith :: a :~: b -> a -> b (bound at TypeEq.hs:5:1) Constraints include <------ NEW LINE a ~ b (from Refl :: a :~: a at TypeEq.hs:5:10) <------ NEW LINE In the expression: _ In an equation for ‘castWith’: castWith Refl x = _ }}} And show class constraints (Show a etc.) similarly -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10614> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

Re: [GHC] #7289: Mingw FPU init not Windows compatible.
by GHC 15 Dec '16

15 Dec '16

#7289: Mingw FPU init not Windows compatible. -------------------------------------+------------------------------------- Reporter: Lennart | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 7.2.2 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2819 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"6f7d8279cea4aa1082fb07adf5da507297e21ee8/ghc" 6f7d827/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6f7d8279cea4aa1082fb07adf5da507297e21ee8" Reset FPU precision back to MSVCRT defaults Mingw-w64 does a stupid thing. They set the FPU precision to extended mode by default. The reasoning is that it's for compatibility with GNU Linux ported libraries. However the problem is this is incompatible with the standard Windows double precision mode. In fact, if we create a new OS thread then Windows will reset the FPU to double precision mode. So we end up with a weird state where the main thread by default has a different precision than any child threads. Test Plan: ./validate new test T7289 Reviewers: simonmar, austin, bgamari, erikd Reviewed By: simonmar Subscribers: thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D2819 GHC Trac Issues: #7289 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7289#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0