March 2017 - ghc-tickets

[GHC] #12718: Segmentation fault, runtime representation polymorphism
by GHC 16 Mar '17

16 Mar '17

#12718: Segmentation fault, runtime representation polymorphism -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHCi crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# Language RebindableSyntax, NoImplicitPrelude, MagicHash, RankNTypes, PolyKinds, ViewPatterns, TypeInType, FlexibleInstances #-} import Prelude hiding (Eq (..), Num(..)) import qualified Prelude as P import GHC.Prim import GHC.Types class Num (a :: TYPE rep) where (+) :: a -> a -> a fromInteger :: Integer -> a instance P.Num a => Num a where (+) = (P.+) fromInteger = P.fromInteger instance Num Int# where (+) = (+#); fromInteger (fromInteger -> I# n) = n u :: Bool u = isTrue# v_ where v_ :: forall rep (a :: TYPE rep). Num a => a v_ = fromInteger 10 }}} segfaults {{{#!hs $ ./bin/repo/ghc4/inplace/bin/ghc-stage2 --interactive -ignore-dot-ghci /tmp/tMjN.hs GHCi, version 8.1.20160930: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/tMjN.hs, interpreted ) Ok, modules loaded: Main. *Main> u True *Main> Segmentation fault (core dumped) $ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12718> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #11431: GHC instantiates levity-polymorphic type variables with foralls
by GHC 16 Mar '17

16 Mar '17

#11431: GHC instantiates levity-polymorphic type variables with foralls -------------------------------------+------------------------------------- Reporter: gridaphobe | 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: -------------------------------------+------------------------------------- Consider the following use of `error`. {{{ ghci> :t error error :: forall (v :: GHC.Types.Levity) (a :: TYPE v). (?callStack::GHC.Stack.Types.CallStack) => [Char] -> a ghci> :t error "bad" :: (forall a. a -> a) -> a error "bad" :: (forall a. a -> a) -> a :: (?callStack::GHC.Stack.Types.CallStack) => (forall a1. a1 -> a1) -> a }}} GHC is instantiating the type variable `a` in the output with `(forall a. a -> a) -> a`, which requires impredicative polymorphism. So this example should actually be rejected by the type checker. Note that GHC also does this with open-kinded type variables, so the behavior with `error` and `undefined` has been around for a while. There are tests that depend on it, and a Note that describes the decision to accept these programs. Still, Simon PJ says perhaps we should really just reject these programs. So here's a ticket to discuss the matter. For more information, see the discussion starting at https://phabricator.haskell.org/D1739#51408. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11431> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #13400: realgcc.exe do not run GHCi in Windows in a particular case
by GHC 15 Mar '17

15 Mar '17

#13400: realgcc.exe do not run GHCi in Windows in a particular case ------------------------------+---------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ------------------------------+---------------------------- First, I start GHCi with a memory card insert in the slot of the computer. GHCi run ok. Second, I stop running GHCi and I remove the memory card. Third, I restart GHCi and a message appears in a window "realgcc.exe there is no disk - insert a disk in drive D:". When I reinsert the memory card, GHCi run again. Realgcc.exe is in the directory c:ghc-8.0.2\mingw\bin. Hope this help! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13400> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #13388: Caret diagnostics interact badly with hsc2hs
by GHC 15 Mar '17

15 Mar '17

#13388: Caret diagnostics interact badly with hsc2hs -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I saw this recently, {{{ libraries\Win32\Graphics\Win32\Window.hsc:188:46: error: Not in scope: type constructor or class `Int32' | 188 | cW_USEDEFAULT = fromIntegral (#{const CW_USEDEFAULT} :: Int32) | ^^^^^ }}} Clearly the caret is pointing to the wrong place in the line. Note that the file in question is a `hsc2hs` file. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13388> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13401: GHCi gives conflicting information about visible type application
by GHC 15 Mar '17

15 Mar '17

#13401: GHCi gives conflicting information about visible type application -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | 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: -------------------------------------+------------------------------------- From the docs for `-XVisibleTypeApplication`: >When printing types with `-fprint-explicit-foralls` (page 72) enabled, type variables not available for visible type application are printed in braces. Thus, if you write `myLength = length` without a type signature, `myLength`‘s inferred type will be `forall {f} {a}. Foldable f => f a -> Int`. {{{ > :set -XScopedTypeVariables > :set -XTypeApplications > :set -fprint-explicit-foralls > let foo :: forall a. a; foo = undefined (LINE 1) > :t foo foo :: forall {a}. a (LINE 2) > > :t (foo @Bool) (foo @Bool) :: Bool (LINE 3) }}} Type application with `foo` (LINE 1) should be possible, but GHCi claims it is not (LINE 2), then allows it anyway (LINE 3). This looks like a bug with `fprint-explicit-foralls` in detecting which variables are available for type application. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13401> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #13428: internal error: Can't allocate thunk for free
by GHC 15 Mar '17

15 Mar '17

#13428: internal error: Can't allocate thunk for free -------------------------------------+------------------------------------- Reporter: alexbiehl | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: RTS linker | Operating System: Windows Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Trying to compile `stack` with `ghc-8.0.2` resulted in this: {{{ [ 73 of 124] Compiling Stack.PackageIndex ( src\Stack\PackageIndex.hs, C:\Users\abiehl\git\stack\dist- newstyle\build\x86_64-windows\ghc-8.0.2\stack-1.4.1\build\Stack\PackageIndex.o ) ghc.exe: internal error: Can't allocate thunk for free (GHC version 8.0.2 for x86_64_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. cabal.exe: Failed to build stack-1.4.1. The build process terminated with exit code 3 }}} The file in question uses `TemplateHaskell` and I suspect the runtime linker to be the culprit. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13428> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13398: Associated type family instance validity checking is too conservative
by GHC 15 Mar '17

15 Mar '17

#13398: Associated type family instance validity checking is too conservative -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.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: #11450 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `mediabus-0.3.0.1` currently fails to build on GHC HEAD because of this regression. Here's a simplified program which exemplifies the issue: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} module Mediabus where data Nat data Rate data StaticTicks where (:/:) :: Nat -> Rate -> StaticTicks type ticks :/ rate = ticks ':/: rate class HasStaticDuration (s :: k) where type SetStaticDuration s (pt :: StaticTicks) :: k instance HasStaticDuration (t :/ r) where type SetStaticDuration (t :/ r) (t' :/ r') = t' :/ r' }}} This compiles fine on GHC 8.0.2, but on GHC HEAD, it gives an odd error: {{{ $ ~/Software/ghc2/inplace/bin/ghc-stage2 --interactive Bug.hs GHCi, version 8.1.20170307: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Mediabus ( Bug.hs, interpreted ) Bug.hs:19:8: error: • Polymorphic type indexes of associated type ‘SetStaticDuration’ (i.e. ones independent of the class type variables) must be distinct type variables Expected: SetStaticDuration (t :/ r) <tv> Actual: SetStaticDuration (t :/ r) (t' :/ r') where the `<tv>' arguments are type variables, distinct from each other and from the instance variables • In the type instance declaration for ‘SetStaticDuration’ In the instance declaration for ‘HasStaticDuration (t :/ r)’ | 19 | type SetStaticDuration (t :/ r) (t' :/ r') = t' :/ r' | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} This error message comes from 8136a5cbfcd24647f897a2fae9fcbda0b1624035 (#11450). To fix it, you have to do a tiresome song and dance with auxiliary type families: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} module Mediabus where data Nat data Rate data StaticTicks where (:/:) :: Nat -> Rate -> StaticTicks type ticks :/ rate = ticks ':/: rate class HasStaticDuration (s :: k) where type SetStaticDuration s (pt :: StaticTicks) :: k instance HasStaticDuration (t :/ r) where type SetStaticDuration (t :/ r) pt = SSDTicks pt type family SSDTicks (pt :: StaticTicks) :: StaticTicks where SSDTicks (t' :/ r') = t' :/ r' }}} But after Simon's motivation for this change in https://ghc.haskell.org/trac/ghc/ticket/11450#comment:24, I'm still not convinced that the original program should be rejected. After all, this change was introduced so that associated type families with //multiple// would be rejected. But in the `SetStaticDuration` example above, there's only one equation, and it's a complete pattern match! So I'm failing to see why it should be rejected. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13398> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #13381: "opt_univ fell into a hole" panic from rewrite rule
by GHC 15 Mar '17

15 Mar '17

#13381: "opt_univ fell into a hole" panic from rewrite rule -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 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: -------------------------------------+------------------------------------- Roboguy reports (via IRC) that the following causes a GHC panic: {{{#!hs {-# LANGUAGE RankNTypes #-} module Crash where data Exp a = Exp fromExp :: Exp a -> a fromExp _ = error "Impossible" toExp :: a -> Exp a toExp _ = Exp newtype Iter a b = Iter { getIter :: forall r. (a -> r) -> (b -> r) -> r } iterLoop :: (a -> Iter a b) -> a -> b iterLoop f x = getIter (f x) (iterLoop f) id -- This rewrite rule results in a GHC panic: "opt_univ fell into a hole" on GHC 8.0.1, 8.0.2, and 8.1. {-# RULES "fromExp-into-iterLoop" [~] forall (f :: Int -> Iter (Exp Int) (Exp Char)) (init :: Int). fromExp (iterLoop f init) = fromExp (iterLoop (f . fromExp) (toExp init)) #-} }}} I have confirmed this, and see the following error: {{{ ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20170305 for x86_64-unknown-linux): opt_univ fell into a hole {a1WD} Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1191:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1195:37 in ghc:Outputable pprPanic, called at compiler/types/OptCoercion.hs:398:29 in ghc:OptCoercion }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13381> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #4092: Floating point manipulation : ulp and coerce IEEE-754 Double# into Word64#
by GHC 15 Mar '17

15 Mar '17

#4092: Floating point manipulation : ulp and coerce IEEE-754 Double# into Word64# -------------------------------------+------------------------------------- Reporter: malosh | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by erikd): * cc: erikd (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4092#comment:28> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13423: Exception to I/O hack in demand analyzer too broad
by GHC 14 Mar '17

14 Mar '17

#13423: Exception to I/O hack in demand analyzer too broad -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The I/O hack in the demand analyzer triggers only for expressions that are not direct applications of primops (see `io_hack_reqd` in `stranal/DmdAnal.hs`). This seems rather arbitrary, and can produce surprising results. Consider {{{#!hs fish :: Int -> IORef Int -> IORef Int -> IO () fish n ref next = do writeIORef ref n writeIORef next n x <- getLine case readMaybe x of Just True -> fish (n + 1) ref next _ -> pure () }}} If `next` is bottom, I would expect this to write `n` to `ref` and then throw an exception. But we actually get something else. First, the demand signature for `fish` ends up being `Str=<L,U(U)><S(S),1*U(U)><S(S),1*U(U)><S,U>`, which seems wrong. Then, as a result, worker/wrapper produces a wrapper that immediately unboxes both `IORef`s, so this is operationally wrong. Why do I think this is wrong? The story Haskell users are told, over and over, is that evaluation is driven only by execution; that we never force anything unless we need its value to determine the next `IO` action. That principle is violated here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13423> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4