August 2017 - ghc-tickets

[GHC] #14169: ghci panics when using type applications on variables that aren't in scope
by GHC 29 Aug '17

29 Aug '17

#14169: ghci panics when using type applications on variables that aren't in scope -------------------------------------+------------------------------------- Reporter: tysonzero | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Minimal example: {{{#!hs ghci> foo @Int ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-apple-darwin): initTc: unsolved constraints WC {wc_insol = [W] foo_a7EJ :: t_a7EI[tau:1] (CHoleCan: foo) [W] foo_a7F7 :: t_a7F6[tau:1] (CHoleCan: foo)} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14169> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #14166: Typo Fix `necssary`
by GHC 29 Aug '17

29 Aug '17

#14166: Typo Fix `necssary` -------------------------------------+------------------------------------- Reporter: h4ck3rm1k3 | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- https://github.com/ghc/ghc/pull/72 diff --git a/compiler/hsSyn/HsExpr.hs b/compiler/hsSyn/HsExpr.hs index 1bde776..f75cc2c 100644 --- a/compiler/hsSyn/HsExpr.hs +++ b/compiler/hsSyn/HsExpr.hs @@ -740,7 +740,7 @@ HsPar (and ParPat in patterns, HsParTy in types) is used as follows https://phabricator.haskell.org/rGHC499e43824bda967546ebf95ee33ec1f84a114a7c * ParPat and HsParTy are pretty printed as '( .. )' regardless of whether or - not they are strictly necssary. This should be addressed when #13238 is + not they are strictly necessary. This should be addressed when #13238 is completed, to be treated the same as HsPar. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14166> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #5987: Too many symbols in ghc package DLL
by GHC 29 Aug '17

29 Aug '17

#5987: Too many symbols in ghc package DLL -------------------------------------+------------------------------------- Reporter: igloo | Owner: Phyx- Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.5 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 5355 Related Tickets: | Differential Rev(s): Phab:D2592 Wiki Page: | Phab:D3883 Phab:D3882 -------------------------------------+------------------------------------- Changes (by Phyx-): * status: patch => closed * resolution: => fixed * blockedby: 10352 => Comment: I will open tickets for the rest of the patches. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5987#comment:68> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5987: Too many symbols in ghc package DLL
by GHC 29 Aug '17

29 Aug '17

#5987: Too many symbols in ghc package DLL -------------------------------------+------------------------------------- Reporter: igloo | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 10352 | Blocking: 5355 Related Tickets: | Differential Rev(s): Phab:D2592 Wiki Page: | Phab:D3883 Phab:D3882 -------------------------------------+------------------------------------- Comment (by Tamar Christina <tamar@…>): In [changeset:"5f6a82040694f7c8c2b394c1b418c0167b963e0b/ghc" 5f6a8204/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5f6a82040694f7c8c2b394c1b418c0167b963e0b" Add gen-dll as replacement for dll-split Summary: This tool can be used to generate dll's for any list of object files given to it. It will then repartition them automatically to fit within a dll and generates as many dll's as needed to do this. Cyclic dependencies between these generated dlls are handle automatically so there is no need to tell it how to partition. It is also a lot more general than `dll-split` as it is able to split any package not just `libGHC`. It also uses a trick using GNU style import libraries to hide the splitting from the rest of the pipeline. Which means come linking time you don't need to know which dll contains what symbol or how many split dlls were created. The import libraries are by default created with libtool. However since libtool is BFD based it is very slow. So if present and detected by configure the `genlib` tool from the msys2 project is used. This makes a difference of about ~45 minutes when compiling. To install `genlib` run `pacman -Sy mingw-w64-$(uname -m)-tools-git`. More detailed explaination of the process can be found here https://ghc.haskell.org/trac/ghc/wiki/WindowsDynamicLinking Test Plan: ./validate Reviewers: austin, hvr, bgamari, erikd, simonmar Reviewed By: bgamari Subscribers: snowleopard, rwbarton, thomie, erikd, #ghc_windows_task_force GHC Trac Issues: #5987 Differential Revision: https://phabricator.haskell.org/D3883 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5987#comment:67> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14154: Some cocktail of features causes GHC panic
by GHC 29 Aug '17

29 Aug '17

#14154: Some cocktail of features causes GHC panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- {{{ {-# Language RankNTypes, DerivingStrategies, TypeApplications, ScopedTypeVariables, GADTs, GeneralizedNewtypeDeriving, InstanceSigs, PolyKinds #-} import Data.Coerce newtype Ran g h a = Ran (forall b. (a -> g b) -> h b) newtype Swap p f g a where Swap :: p g f a -> Swap p f g a deriving newtype Show class IxPointed m where ireturn :: a -> m i i a instance IxPointed f => IxPointed (Swap f) where ireturn :: forall a i. a -> Swap f i i a ireturn = coerce (ireturn @f @a @i) instance IxPointed Ran where ireturn :: a -> Ran i i a ireturn a = Ran (\k -> k a) xs = case ireturn @(Swap Main.Ran) 'a' of Swap (Ran f) -> f print }}} {{{ $ ghci -ignore-dot-ghci /tmp/bug.hs GHCi, version 8.3.20170605: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/bug.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 8.3.20170605 for x86_64-unknown-linux): piResultTy k0_a1Ki[tau:2] b0_a1Kt[tau:2] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:949:35 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14154> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

Re: [GHC] #5987: Too many symbols in ghc package DLL
by GHC 29 Aug '17

29 Aug '17

#5987: Too many symbols in ghc package DLL -------------------------------------+------------------------------------- Reporter: igloo | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 10352 | Blocking: 5355 Related Tickets: | Differential Rev(s): Phab:D2592 Wiki Page: | Phab:D3883 Phab:D3882 -------------------------------------+------------------------------------- Changes (by Phyx-): * differential: Phab:D2592 => Phab:D2592 Phab:D3883 Phab:D3882 Comment: @bgamari, not yet. I would like Phab:D3883 to be merged first. I'll then open tickets for the rest of the work. I have more build and ghc changes locally I need to split and make patches for but wanted to do it piece wise. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5987#comment:66> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5987: Too many symbols in ghc package DLL
by GHC 29 Aug '17

29 Aug '17

#5987: Too many symbols in ghc package DLL ---------------------------------+---------------------------------------- Reporter: igloo | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 10352 | Blocking: 5355 Related Tickets: | Differential Rev(s): Phab:D2592 Wiki Page: | ---------------------------------+---------------------------------------- Comment (by bgamari): Phyx, can we consider this to be closed? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5987#comment:65> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5987: Too many symbols in ghc package DLL
by GHC 29 Aug '17

29 Aug '17

#5987: Too many symbols in ghc package DLL ---------------------------------+---------------------------------------- Reporter: igloo | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 10352 | Blocking: 5355 Related Tickets: | Differential Rev(s): Phab:D2592 Wiki Page: | ---------------------------------+---------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"5266ab9059dffa741b172636f50f1fbfd491dbb4/ghc" 5266ab90/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5266ab9059dffa741b172636f50f1fbfd491dbb4" Remove dll-split. This patch removes dll-split from the code base, the reason is dll-split no longer makes any sense. It was designed to split a dll in two, but we now already have many more symbols than would fit inside two dlls. So we need a third one. This means there's no point in having to maintain this list as it'll never work anyway and the solution isn't scalable. Test Plan: ./validate Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, #ghc_windows_task_force GHC Trac Issues: #5987 Differential Revision: https://phabricator.haskell.org/D3882 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5987#comment:64> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6135: Unboxed Booleans
by GHC 29 Aug '17

29 Aug '17

#6135: Unboxed Booleans -------------------------------------+------------------------------------- Reporter: benl | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Resolution: fixed | Keywords: datacon-tags Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | primops/should_run/T6135 Blocked By: 8103, 8103 | Blocking: Related Tickets: #605 | Differential Rev(s): Wiki Page: PrimBool | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => datacon-tags Old description: > Right now the only way to compare two integers is with primops that > produce boxed bools: > > {{{ > <# :: Int# -> Int# -> Bool > ==# :: Int# -> Int# -> Bool > }}} > > To consume the resulting {{{Bool}}} we need a case-expression, which > introduces branches into the core IR and object code. Case expressions > are bad in the presence of heavy inlining because case-of-case performed > by the GHC simplifier tends to duplicate code (like in DPH and Repa > programs). Mis-predicted branches are bad in object code because they > stall the pipeline. > > Consider the following expression: > {{{ > case x <# 0# || x >=# aWidth > || y <# 0# || y >=# aHeight of > True -> ... > False -> ... > }}} > > This is very common in array programming. Ideally, it should turn into > some straight-line code to compute the flag, and then a single branch > instruction once we've worked out what alternative to take. However, as > the only way to consume the {{{Bool}}}s produced by the comparisons is to > introduce more case expressions, we end up with *four* cases in the core > IR. > > What I want is this: > {{{ > data Bool# > (.<#) :: Int# -> Int# -> Bool# > (.==#) :: Int# -> Int# -> Bool# > (.||#) :: Bool# -> Bool# -> Bool# > > case x .<# 0# .||# x .>=# aWidth > .||# y .<# 0# .||# y .>=# aHeight of > True# -> ... > False# -> ... > }}} > > Bool# is the type of one bit integers. I can compute with them > algebraically and be sure that I'll get at most one branch instruction in > the resulting object code. New description: Right now the only way to compare two integers is with primops that produce boxed bools: {{{#!hs <# :: Int# -> Int# -> Bool ==# :: Int# -> Int# -> Bool }}} To consume the resulting {{{Bool}}} we need a case-expression, which introduces branches into the core IR and object code. Case expressions are bad in the presence of heavy inlining because case-of-case performed by the GHC simplifier tends to duplicate code (like in DPH and Repa programs). Mis-predicted branches are bad in object code because they stall the pipeline. Consider the following expression: {{{#!hs case x <# 0# || x >=# aWidth || y <# 0# || y >=# aHeight of True -> ... False -> ... }}} This is very common in array programming. Ideally, it should turn into some straight-line code to compute the flag, and then a single branch instruction once we've worked out what alternative to take. However, as the only way to consume the {{{Bool}}}s produced by the comparisons is to introduce more case expressions, we end up with *four* cases in the core IR. What I want is this: {{{#!hs data Bool# (.<#) :: Int# -> Int# -> Bool# (.==#) :: Int# -> Int# -> Bool# (.||#) :: Bool# -> Bool# -> Bool# case x .<# 0# .||# x .>=# aWidth .||# y .<# 0# .||# y .>=# aHeight of True# -> ... False# -> ... }}} Bool# is the type of one bit integers. I can compute with them algebraically and be sure that I'll get at most one branch instruction in the resulting object code. -- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6135#comment:97> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8317: Optimize tagToEnum# at Core level
by GHC 29 Aug '17

29 Aug '17

#8317: Optimize tagToEnum# at Core level ------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #6135 | ------------------------------------+------------------------------------- Old comparison primops that returned Bool were implemented by inserting call to `tagToEnum#` in the code generator. This call to `tagToEnum#` was later optimized away by a special case in the code geenrator (see [[GhcFile(compiler/codeGen/StgCmmExpr.hs)]], Note [case on bool])). Now that we have new comparison primops (see #6135) we no longer insert `tagToEnum#` in the code generator - all uses of `tagToEnum#` come from explicit calls in a source program. But we still have that special case in the code generator to optimize away `tagToEnum#`. We should drop that special case in the code generator and handle scrutinizing of `tagToEnum#` at the Core level by: 1. removing call to `tagToEnum#` in the scrutinee 2. adding calls to `dataToTag#` in case branches 3. constant-folding inserted `dataToTag#` Here is an example. This Haskell code: {{{ if tagToEnum# (a ># b) then E1 else E2 }}} will be translated to this Core: {{{ case tagToEnum# (a ># b) of True -> E1 False -> E2 }}} and optimized like this: {{{ case a ># b of dataToTag# True -> E1 dataToTag# False -> E2 }}} ====> {{{ case a ># b of 1 -> E1 0 -> E2 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8317> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8