August 2018 - ghc-tickets

[GHC] #11759: can't decompose ghc.exe path
by GHC 02 Aug '18

02 Aug '18

#11759: can't decompose ghc.exe path --------------------------------------+---------------------------- Reporter: erisco | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------- {{{ erisco@ERICWIN C:\Users\erisco\haskell-platform-bin $ ghc.exe ghc.exe: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-unknown-mingw32): can't decompose ghc.exe path: "C:\\Users\\erisco\\haskell- platform-bin\\ghc.exe" }}} haskell-platform-bin is a symbolic directory link to "C:\Program Files\Haskell Platform\2014.2.0.0\bin". I did this so there would not be spaces in the path because this is causing other issues for me. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11759> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #15385: -Wincomplete-patterns gets confused when combining GADTs and pattern guards
by GHC 02 Aug '18

02 Aug '18

#15385: -Wincomplete-patterns gets confused when combining GADTs and pattern guards -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Keywords: | Operating System: Unknown/Multiple PatternMatchWarnings | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following code: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE UndecidableInstances #-} {-# OPTIONS_GHC -Wincomplete-patterns #-} module Bug where import Data.Kind data family Sing :: forall k. k -> Type newtype Id a = MkId a data So :: Bool -> Type where Oh :: So True data instance Sing :: Bool -> Type where SFalse :: Sing False STrue :: Sing True data instance Sing :: Ordering -> Type where SLT :: Sing LT SEQ :: Sing EQ SGT :: Sing GT data instance Sing :: forall a. Id a -> Type where SMkId :: Sing x -> Sing (MkId x) class POrd a where type (x :: a) `Compare` (y :: a) :: Ordering class SOrd a where sCompare :: forall (x :: a) (y :: a). Sing x -> Sing y -> Sing (x `Compare` y) type family (x :: a) <= (y :: a) :: Bool where x <= y = LeqCase (x `Compare` y) type family LeqCase (o :: Ordering) :: Bool where LeqCase LT = True LeqCase EQ = True LeqCase GT = False (%<=) :: forall a (x :: a) (y :: a). SOrd a => Sing x -> Sing y -> Sing (x <= y) sx %<= sy = case sx `sCompare` sy of SLT -> STrue SEQ -> STrue SGT -> SFalse class (POrd a, SOrd a) => VOrd a where leqReflexive :: forall (x :: a). Sing x -> So (x <= x) instance POrd a => POrd (Id a) where type MkId x `Compare` MkId y = x `Compare` y instance SOrd a => SOrd (Id a) where SMkId sx `sCompare` SMkId sy = sx `sCompare` sy ----- instance VOrd a => VOrd (Id a) where leqReflexive (SMkId sa) | Oh <- leqReflexive sa = case sa `sCompare` sa of SLT -> Oh SEQ -> Oh -- SGT -> undefined }}} What exactly this code does isn't terribly important. The important bit is that last instance (`VOrd (Id a)`). That //should// be total, but GHC disagrees: {{{ GHCi, version 8.6.0.20180627: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:63:7: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In a case alternative: Patterns not matched: SGT | 63 | = case sa `sCompare` sa of | ^^^^^^^^^^^^^^^^^^^^^^^^... }}} As evidence that this warning is bogus, if you uncomment the last line, then GHC correctly observes that that line is inaccessible: {{{ GHCi, version 8.6.0.20180627: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:66:9: warning: [-Winaccessible-code] • Couldn't match type ‘'True’ with ‘'False’ Inaccessible code in a pattern with constructor: SGT :: Sing 'GT, in a case alternative • In the pattern: SGT In a case alternative: SGT -> undefined In the expression: case sa `sCompare` sa of SLT -> Oh SEQ -> Oh SGT -> undefined | 66 | SGT -> undefined | ^^^ }}} Clearly, something is afoot in the coverage checker. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15385> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #15380: Infinite typechecker loop in GHC 8.6
by GHC 02 Aug '18

02 Aug '18

#15380: Infinite typechecker loop in GHC 8.6 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (Type checker) | Keywords: TypeInType, | Operating System: Unknown/Multiple TypeFamilies | Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following program loops infinitely during typechecking with GHC 8.6.1 and HEAD: {{{#!hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} module Bug where import Data.Kind class Generic a where type Rep a :: Type class PGeneric a where type To a (x :: Rep a) :: a type family MDefault (x :: a) :: a where MDefault x = To (M x) class C a where type M (x :: a) :: a type M (x :: a) = MDefault x }}} In GHC 8.4.3, however this fails with a proper error: {{{ $ /opt/ghc/8.4.3/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:15:16: error: • Occurs check: cannot construct the infinite kind: a ~ Rep (M x) -> M x • In the type ‘To (M x)’ In the type family declaration for ‘MDefault’ • Type variable kinds: x :: a | 15 | MDefault x = To (M x) | ^^^^^^^^ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15380> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #15450: Inconsistency w.r.t. coverage checking warnings for EmptyCase under unsatisfiable constraints
by GHC 02 Aug '18

02 Aug '18

#15450: Inconsistency w.r.t. coverage checking warnings for EmptyCase under unsatisfiable constraints -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple PatternMatchWarnings | Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: #12957 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following code: {{{#!hs {-# LANGUAGE EmptyCase #-} {-# LANGUAGE GADTs #-} {-# OPTIONS_GHC -Wincomplete-patterns #-} module Bug where f :: (Int ~ Bool) => Bool -> a f x = case x of {} g :: (Int ~ Bool) => Bool -> a g x = case x of True -> undefined }}} {{{ $ /opt/ghc/8.4.3/bin/ghci Bug.hs GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:10:7: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In a case alternative: Patterns not matched: False | 10 | g x = case x of True -> undefined | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} Observe that we get a non-exhaustivity warning for the `case` expression in `g` (thanks to commit adb565aa74582969bbcc3b411d6d518b1c76c3cf), but not for the one in `f`. The difference is that `f` uses `EmptyCase`, whereas `g` does not, and the codepath for `EmptyCase` is unfortunately incongruous with the codepath for other coverage checking. I know how to fix this. Patch incoming. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15450> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #15415: GHCi's :kind doesn't work with wildcards
by GHC 02 Aug '18

02 Aug '18

#15415: GHCi's :kind doesn't work with wildcards -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 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: -------------------------------------+------------------------------------- Witness this GHCi session: {{{ rae:20:35:37 ~/ghc/ghc-head/ghc> ~/ghc/ghc-head/inplace/bin/ghc-stage2 --interactive GHCi, version 8.7.20180716: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /Users/rae/.ghc/ghci.conf Prelude> :set -XPartialTypeSignatures Prelude> import Data.Proxy Prelude Data.Proxy> :k Proxy _ Proxy _ :: * Prelude Data.Proxy> :k Proxy (Maybe :: _) <interactive>:1:8: error: • Expecting one more argument to ‘Maybe’ Expected kind ‘_’, but ‘Maybe’ has kind ‘* -> *’ • In the first argument of ‘Proxy’, namely ‘(Maybe :: _)’ In the type ‘Proxy (Maybe :: _)’ }}} It seems we're not doing the correct wildcard thing here: GHCi should report that `_` should be `Type -> Type`. I believe that this is because `TcHsType.tcWildCardBinders` uses `newSkolemTyVar` internally; `tcWildCardBinders` is called from `TcRnDriver.tcRnType`, which is the implementation of GHCi's `:kind`. This is GHC's only call of `tcWildCardBinders`. All other places use `tcWildCardBindersX newWildTyVar`, which makes vastly more sense. I would just fix this myself, but it smells intentional. Does anyone know why we have all this? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15415> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #15348: Enable two-step allocator on FreeBSD
by GHC 02 Aug '18

02 Aug '18

#15348: Enable two-step allocator on FreeBSD ----------------------------------------+--------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: FreeBSD Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- Currently the two-step allocator is disabled on FreeBSD as the `MEM_NORESERVE` macro is undefined. It seems that FreeBSD provided this macro until 2014, when it was [[https://reviews.freebsd.org/D848|removed]] as it wasn't implemented in the kernel. Regardless, Viktor Dukhovni reports empirical evidence on `ghc-devs` that just plain `mmap` does what we want. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15348> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 26

[GHC] #15464: Template Haskell creates System names when it shouldn't
by GHC 01 Aug '18

01 Aug '18

#15464: Template Haskell creates System names when it shouldn't -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Template | Version: 8.4.3 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: -------------------------------------+------------------------------------- If we desugar {{{ [d| foo :: a -> a foo x = x |] }}} we discover that `a` has a "system" name. This is explained in this Note (is DsMeta): {{{ Note [Scoped type variables in bindings] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Consider f :: forall a. a -> a f x = x::a Here the 'forall a' brings 'a' into scope over the binding group. To achieve this we a) Gensym a binding for 'a' at the same time as we do one for 'f' collecting the relevant binders with hsSigTvBinders b) When processing the 'forall', don't gensym The relevant places are signposted with references to this Note }}} The problem is that the gensym approach creates system names, as explained further in `Note [Binders in Template Haskell]` in Convert. Essentially, it explains why to use system names as the result of `qNewName`, which !DsMeta uses for its gensyms. There is a good logic to this approach, but system names are just wrong in the quote above. This can be user-visible when we print out the results, as we see in test case `th/T10267`, which includes silliness like `j :: forall a0. a0 -> a0`. (Recall that GHC appends a `0` to system names when printing.) I worry that the answer here is a new `NameFlavour`, but perhaps cooler heads will prevail. (This problem became user-visible with the fix to #15380, but I fault TH here, not #15380.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15464> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15358: no way to talk about unpacking sum types / unpacking tuples
by GHC 01 Aug '18

01 Aug '18

#15358: no way to talk about unpacking sum types / unpacking tuples -------------------------------------+------------------------------------- Reporter: chessai | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: unboxedsums, | Operating System: Unknown/Multiple unboxedtuples | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Suppose I have the following Haskell module: {{{#!hs {-# LANGUAGE BangPatterns #-} -- strict 'Maybe' data StrictMaybe a = SNothing | SJust !a -- lazy 'Maybe' data Maybe a = Nothing | Just a data BoxedInner = BoxedInner !Int !(Maybe Int) data StillBoxedInner = StillBoxedInner !Int !(StrictMaybe Int) mBoxed :: BoxedInner mBoxed = BoxedInner 0 (Just 0) mWantThisToUnbox :: StillBoxedInner mWantThisToUnbox = StillBoxedInner 1 (Just 1) }}} the 'StrictMaybe' can unbox the first 'Int' into 1#, but the 1 inside of the just cannot unbox. When compiled to core with -O2 what I'd want to see is something like: {{{#!hs mWantThisToUnbox = StillBoxedInner 0# (# | 1# #) }}} (where (# (# #) | a #) is an unboxed sum type with two constructors, one nullary and one unary) but instead the Int inside 'SJust' remains boxed. Even with something like the following: {{{#!hs {-# LANGUAGE UnboxedSums #-} data UMaybe a = (# (# #) | a #) }}} something like 'UMaybe Int' would still result in 'Int' being boxed. This same thing occurs with unpacked tuples, consider something like: {{{#!hs data StrictTuple = StrictTuple !Int !(Int, Int) }}} Anything inside the (Int, Int) tuple will not unbox, despite having a bang pattern there. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15358> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15148: Allow setting of custom alignments
by GHC 01 Aug '18

01 Aug '18

#15148: Allow setting of custom alignments -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 (NCG) | Keywords: CodeGen | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #15124 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Alignment can introduce a bias to benchmarking results which isn't obvious. To help deal with that I want to add some options adjusting alignment for generated code. To give one example I came across while looking into #15124: Padding a function that **is not even called** in nofib/real/eff/FS by multiples of 8 bytes gave runtimes of ~240ms, ~220ms and ~210ms depending on the padding. At 64 byte it seems to loop around (size of a cache line). At a minimum it should be possible to specify alignment of functions. Potentially we could also consider: * Padding for sections. * Padding for functions * Alignment for info tables. * Padding for info tables. * Alignment for Data The cases where this could have benefits: ---- Problem: We optimize one subroutine changing it's size. This leads to alignment changes for the following functions making overall performance potentially worse. Here aligning functions along cache lines would make benchmarks more resilient against accidental alignment changes. ---- Problem: We might try to optimize code based on a specific benchmark. Going purely by performance of this benchmark we might end up optimizing our code for this specific benchmark instead of the general case. Varying the alignment would to check if our code simply found a optimum for the alignment caused by this benchmark or if it is generally better. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15148> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #7836: "Invalid object in processHeapClosureForDead" when profiling with -hb
by GHC 01 Aug '18

01 Aug '18

#7836: "Invalid object in processHeapClosureForDead" when profiling with -hb -------------------------------------+------------------------------------- Reporter: hyperthunk | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Profiling | Version: 8.5 Resolution: fixed | Keywords: profiling Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15063, #15087, | Differential Rev(s): Phab:D4928 #15165 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: => 8.6.1 Comment: Merged in 30a4bcc3fc3a434b3b6ab64289934281591ce09a. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7836#comment:32> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0