February 2018 - ghc-tickets

[GHC] #14811: Unary unboxed tuple field causes panic
by GHC 18 Feb '18

18 Feb '18

#14811: Unary unboxed tuple field causes panic -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Compiling this code under 8.2 or HEAD (but not 8.0), I get an error. {{{#!hs {-# language UnboxedTuples #-} module Reccy where data Foo a = Foo (# a #) }}} {{{ Reccy.hs:1:1: error: Can't find interface-file declaration for variable GHC.Types.$tcUnit# Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error | 1 | -- {-# language GADTs, TypeOperators #-} | ^ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14811> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13994: STG lint failure on master
by GHC 18 Feb '18

18 Feb '18

#13994: STG lint failure on master -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 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: -------------------------------------+------------------------------------- As of 4700baaf8f9bf3c44a53a595d840c7c14cfd6f98 building with this `build.mk` results in an STG lint failure, {{{ BuildFlavour = devel2 include mk/flavours/$(BuildFlavour).mk GhcLibHcOpts += -g3 -ddump-to-file -ddump-stg -dcore-lint -dstg-lint -dcmm-lint GhcRtsHcOpts += -g3 GhcStage2HcOpts += -g3 -ddump-to-file -ddump-stg -dcore-lint -dstg-lint -dcmm-lint }}} The failures occurs while building `libraries/integer-gmp/dist- install/build/GHC/Integer/Type.o` and are of the form, {{{ *** Stg Lint ErrMsgs: in Stg2Stg *** <no location info>: warning: [in body of lambda with binders m0_scBi :: State# s_a2Ej -> State# s_a2Ej, s1_scBj :: State# s_a2Ej] s'_scBk is out of scope <no location info>: warning: [RHS of $j1_sdij :: (# BigNat, GmpLimb# #)] Let(rec) binder ‘$j1_sdij’ has unlifted type ‘(# BigNat, GmpLimb# #)’ RHS: (elided for brevity) <no location info>: warning: [RHS of $j4_sdQ1 :: (# BigNat, BigNat #)] Let(rec) binder ‘$j4_sdQ1’ has unlifted type ‘(# BigNat, BigNat #)’ RHS: (elided) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13994> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #13185: haskell-relational-query: ghc: panic! (the 'impossible' happened)
by GHC 18 Feb '18

18 Feb '18

#13185: haskell-relational-query: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: LocutusOfBorg | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Linux Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: build | Blocked By: relational-query with ghc 8.0.2 | Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hello, this seems a regression of ghc 8.0.2 since 8.0.1 was building it fine: https://launchpadlibrarian.net/303858976/buildlog_ubuntu-zesty-amd64 .haskell-relational-query_0.8.3.2-2build1_BUILDING.txt.gz as you can see in the build log: Preprocessing test suite 'sqls' for relational-query-0.8.3.2... [1 of 3] Compiling Model ( test/Model.hs, dist-ghc/build/sqls /sqls-tmp/Model.o ) [2 of 3] Compiling Lex ( test/Lex.hs, dist-ghc/build/sqls /sqls-tmp/Lex.o ) [3 of 3] Compiling Main ( test/sqlsEq.hs, dist-ghc/build/sqls /sqls-tmp/Main.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone runReaderT To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 405365 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug /usr/share/cdbs/1/class/hlibrary.mk:147: recipe for target 'build-ghc- stamp' failed make: *** [build-ghc-stamp] Error 1 dpkg-buildpackage: error: debian/rules build gave error exit status 2 thanks, Gianfranco -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13185> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #9429: Alternative to type family Any
by GHC 18 Feb '18

18 Feb '18

#9429: Alternative to type family Any -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: 9097, 9380 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- In GHC HEAD, `Any` is no longer a datatype. There are good reasons for this change, one of which was explained in #9097, the original ticket, and another in #9380. Unfortunately, a casualty of this change is that it is no longer easy to generalize the [https://hackage.haskell.org/package/rank1dynamic|rank1dynamic package] to rank-1 types with type variables of arbitrary kind (not just `*`). We submitted a way to do so [here], that exploits the fact that `Any` has the very magical property of inhabiting *all* kinds, including closed ones. This works for GHC 7.8, but won't work in HEAD, because we require that there exists a `Typeable` instance for `Any`, just as there are `Typeable` instances for any other type one wishes to have instances for. The reason is that now that `Any` is a type family, `Any` is no longer a legal instance head. There are several possible solutions that I see: * while it's clearly dangerous for the compiler to be inserting the old `Any` during typechecking from the moment that we have computation in types over closed kinds, we may still want the old `Any`, say under a different name, as a backdoor. It wouldn't be used by the compiler during type checking - only by packages such as rank1dynamic. I believe that furthermore, if we restrict the old `Any` to not inhabit closed kinds, then none of the problems cited in the above tickets arise. * Instead of making the new `Any` a type family, keep it a datatype, but ban it from inhabiting closed kinds. I don't know if such an `Any` would be sufficient for the purposes of GHC, however. * Hardwire a `Typeable` instance for the `Any` type family (not sure if this makes sense). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9429> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 33

Re: [GHC] #7259: Eta expansion of products in System FC
by GHC 18 Feb '18

18 Feb '18

#7259: Eta expansion of products in System FC -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 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 kcsongor): * cc: kcsongor (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7259#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14787: Remove StgLint type checks
by GHC 18 Feb '18

18 Feb '18

#14787: Remove StgLint type checks -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 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: -------------------------------------+------------------------------------- Copying from the mailing list thread: ---- https://mail.haskell.org/pipermail/ghc-devs/2018-February/015371.html I've been looking into some StgLint-related tickets: - #13994: Found a StgLint problem and fixed, there's another problem waiting to be fixed. Both related with the fact that after unarisation we lose even more typing information and type checks needs to be relaxed. - #14116: StgLint failed to look through newtypes, and because coercions are removed at that point it failed to type check. Solution was to relax type checks. - #5345: Because `unsafeCoerce# is operationally no-op, and we don't have coercions in STG, StgLint can't type check at all. The commit message notes: > Fundamentally STG Lint is impossible, because unsafeCoerce# > can randomise all the types. > This patch does a bit of fiddle faddling in StgLint which > makes it a bit better, but it's a losing battle. - #14117: Related with StgLint not keeping up with recent changes (join points), because it's not enabled by default in tests/validate. - #14118: Related with the fact that pre- and post-unarise we have different invariants in STG. Solution was to add a "unarise" parameter and do different checks based on that. - #14120: Again type checking errors. Commit for #14116 also fixes this. The commits compares `typePrimRep`s of types instead of comparing actual types (even this is not enough, see #13994). All this of course took time to debug. In addition, the new `StgCSE` pass makes transformations that trigger case alternative checks (and probably some other checks) because scrutinee and result won't have same types after the transformation described in `Note [Case 2: CSEing case binders]`. There's also this comment in StgLint.hs WARNING: ~~~~~~~~ This module has suffered bit-rot; it is likely to yield lint errors for Stg code that is currently perfectly acceptable for code generation. Solution: don't use it! (KSW 2000-05). It seems like it hasn't been used since 2000. All this suggests that - Checks related to types are impossible in StgLint. (see e.g. commit messages in #5345, #1420, transformations done by unariser and StgCSE) - It's not enabled since 2000, which I think means that it's not needed. This makes me question whether it's worth maintaining. Maybe we should just remove it. If we still want to keep we should decide on what it's supposed to do. Only invariants I can think of are: - After unarise there should be no unboxed tuple and sum binders. unarise is a simple pass and does same thing to all binders, there are no tricky cases so I'm not sure if we need to check this. - Variables should be defined before use. I again don't know if this should be checked, could this be useful for StgCSE? So I think we should do one of these: 1. Remove StgLint. 2. Rewrite it to only check these two and nothing else, enable it in validate (and in other build flavours that enable CoreLint). What do you think? If you think we should keep StgLint, can you think of any other checks? If we could reach a consensus I'm hoping to update StgLint (or remove it). ---- Simon suggested creating a ticket and keeping StgLint. This is the tracking ticket. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14787> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14763: GHC 8.4.1-alpha regression with FunctionalDependencies
by GHC 18 Feb '18

18 Feb '18

#14763: GHC 8.4.1-alpha regression with FunctionalDependencies -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.4.1-alpha3 (Type checker) | Keywords: FunDeps | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This regression prevents `esqeueleto-2.5.3` from building with GHC 8.4.1. Here is a minimized example of the problem: {{{#!hs {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE MultiParamTypeClasses #-} module Bug where data Value a = Value a data SomeValue expr where SomeValue :: Esqueleto query expr backend => expr (Value a) -> SomeValue expr class Esqueleto (query :: * -> *) (expr :: * -> *) backend | query -> expr backend, expr -> query backend data SqlQuery a data SqlBackend data SqlExpr a where ECompositeKey :: SqlExpr (Value a) instance Esqueleto SqlQuery SqlExpr SqlBackend match' :: SomeValue SqlExpr -> a match' (SomeValue ECompositeKey) = undefined }}} On GHC 8.2.2, this typechecks without issue. On GHC 8.4.1-alpha (version 8.4.0.20180204), this fails with: {{{ $ /opt/ghc/8.4.1/bin/ghci Bug.hs GHCi, version 8.4.0.20180204: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:25:19: error: • Could not deduce: query ~ SqlQuery arising from a functional dependency between: constraint ‘Esqueleto query SqlExpr backend’ arising from a pattern with constructor: SomeValue :: forall (query :: * -> *) (expr :: * -> *) backend a. Esqueleto query expr backend => expr (Value a) -> SomeValue expr, in an equation for ‘match'’ instance ‘Esqueleto SqlQuery SqlExpr SqlBackend’ at Bug.hs:22:10-46 from the context: Value a1 ~ Value a2 bound by a pattern with constructor: ECompositeKey :: forall a. SqlExpr (Value a), in an equation for ‘match'’ at Bug.hs:25:19-31 ‘query’ is a rigid type variable bound by a pattern with constructor: SomeValue :: forall (query :: * -> *) (expr :: * -> *) backend a. Esqueleto query expr backend => expr (Value a) -> SomeValue expr, in an equation for ‘match'’ at Bug.hs:25:9-31 Inaccessible code in a pattern with constructor: ECompositeKey :: forall a. SqlExpr (Value a), in an equation for ‘match'’ • In the pattern: ECompositeKey In the pattern: SomeValue ECompositeKey In an equation for ‘match'’: match' (SomeValue ECompositeKey) = undefined | 25 | match' (SomeValue ECompositeKey) = undefined | ^^^^^^^^^^^^^ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14763> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14768: -O1 changes result at runtime, duplicating __DEFAULT case
by GHC 18 Feb '18

18 Feb '18

#14768: -O1 changes result at runtime, duplicating __DEFAULT case -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.4.1-alpha3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Here is a program, which works as expected in GHC 8.4.1-alpha3 with `-O0`, but changes it behaviour with `-O1`. {{{#!hs {-# LANGUAGE MagicHash #-} import qualified Data.Vector.Unboxed as U import GHC.Exts vec :: U.Vector Moebius vec = U.singleton Moebius0 main :: IO () main = print $ U.head vec == U.head vec data Moebius = Moebius0 | Moebius1 | Moebius2 deriving (Eq) fromMoebius :: Moebius -> Int fromMoebius Moebius0 = 0 fromMoebius Moebius1 = 1 fromMoebius Moebius2 = 2 toMoebius :: Int -> Moebius toMoebius (I# i#) = tagToEnum# i# {- ...unboxed vector instances, see file attached... -} }}} It is expected that this program will print `True`. However, when compiled with `-O1` it prints `False`. {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.4.0.20180204 $ ghc -O0 Sieve.hs && ./Sieve [1 of 1] Compiling Main ( Sieve.hs, Sieve.o ) [Optimisation flags changed] Linking Sieve ... True $ ghc -O1 Sieve.hs && ./Sieve [1 of 1] Compiling Main ( Sieve.hs, Sieve.o ) [Optimisation flags changed] Linking Sieve ... False }}} It reproduces on OS X and Ubuntu, but worked fine in GHC 8.2. I looked into generated Core and found a suspicious function, having two `__DEFAULT` cases with different bodies. {{{#!hs main2 :: String main2 = case vec `cast` <Co:3> of { Vector ipv_sb7L ipv1_sb7M ipv2_sb7N -> case <# 0# ipv1_sb7M of { __DEFAULT -> case main3 ipv1_sb7M of wild_00 { }; 1# -> case indexIntArray# ipv2_sb7N ipv_sb7L of { __DEFAULT -> $fShowBool4; __DEFAULT -> $fShowBool2; 1# -> $fShowBool2; 2# -> $fShowBool2 } } } }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14768> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #13852: Can we have more SIMD primops, corresponding to the untapped AVX etc. instructions?
by GHC 17 Feb '18

17 Feb '18

#13852: Can we have more SIMD primops, corresponding to the untapped AVX etc. instructions? -------------------------------------+------------------------------------- Reporter: | Owner: (none) leftaroundabout | Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (LLVM) | Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- [http://hackage.haskell.org/package/ghc-prim-0.5.0.0/docs/GHC- Prim.html#g:28 GHC.Prim] contains a good couple of vectorised instructions, which can be [http://hackage.haskell.org/package/primitive- simd-0.1.0.0/docs/Data-Primitive-SIMD.html used by libraries] for generating nice fast e.g. sums of floating-point vectors. However, several instructions that modern processors could vectorise are missing there. In particular, I would like to be able to use the VPSLLVD...VPSRAVD shifting operations, and at some point perhaps VPMAXSQ...VPMINUQ maximum/minimum operations. It would be great if corresponding primops could be added. Else I would like to know – where is this stuff even defined? [http://hackage.haskell.org/package/ghc- prim-0.5.0.0/docs/src/GHC.Prim.html GHC.Prim] as such seems to be merely an automatically-generated dummy module, mostly for Haddock. (On the other hand, I find it also a bit strange that there are primops for [http://hackage.haskell.org/package/ghc-prim-0.5.0.0/docs/GHC- Prim.html#v:quotInt8X16-35- integer division], which is apparently [https://stackoverflow.com/questions/16822757/sse-integer-division not supported by SSE/AVX] at all!) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13852> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #14782: typeclass polymorphism defeats bang patterns
by GHC 16 Feb '18

16 Feb '18

#14782: typeclass polymorphism defeats bang patterns -------------------------------------+------------------------------------- Reporter: dmwit | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- I think the following program should crash, but it doesn't: {{{ {-# LANGUAGE BangPatterns #-} main = let n :: Num a => a; !n = undefined in return () }}} Interestingly, my attempt to translate this out of BangPatterns into standard Haskell according to the translation on the wiki page led to a compile-time error: {{{ main = let n :: Num a => a; x@n = undefined in x `seq` return () }}} Produces the error: {{{ test.hs:1:12: error: • Overloaded signature conflicts with monomorphism restriction n :: forall a. Num a => a • In the expression: let n :: Num a => a x@n = undefined in x `seq` return () In an equation for ‘main’: main = let n :: Num a => a x@n = undefined in x `seq` return () | 1 | main = let n :: Num a => a; x@n = undefined in x `seq` return () | ^^^^^^^^^^^^^^^ }}} Even giving `x` its own explicitly polymorphic type signature -- what I thought was the standard way to prevent the monomorphism restriction from being a problem -- doesn't help. I'm uncertain what to make of that, but it certainly seems related: earlier versions of the compiler both do not give that error and do produce a crashing program, as I expected. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14782> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6