December 2016 - ghc-tickets

[GHC] #10976: Applicative Comprehensions
by GHC 02 Apr '17

02 Apr '17

#10976: Applicative Comprehensions -------------------------------------+------------------------------------- Reporter: davidar | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: 8914 | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- As discussed on `ghc-devs`, when both the `MonadComprehensions` and `ApplicativeDo` language extensions are enabled, it should be possible to use comprehension-notation (in addition to do-notation) for `Applicative`s. This would allow, for example, an expression like {{{#!hs (\x y -> x + 2*y) <$> ZipList [1..10] <*> ZipList [10,20..100] }}} to also be written as {{{#!hs [ x + 2*y | x <- ZipList [1..10], y <- ZipList [10,20..100] ] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10976> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12490: ApplicativeDo and RebindableSyntax do not desugar as expected
by GHC 02 Apr '17

02 Apr '17

#12490: ApplicativeDo and RebindableSyntax do not desugar as expected -------------------------------------+------------------------------------- Reporter: AaronFriel | 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: -------------------------------------+------------------------------------- In a module with -XApplicativeDo, -XRebindableSyntax, and local definitions for everything in the Functor-Applicative-Monad hierarchy, do- notation always desugars to "join (... (return ...))" (or /s/return/pure/). This forces the result to have at least the constraints of join, which in my case is "IxMonad m". {{{#!hs {-# LANGUAGE RebindableSyntax, ApplicativeDo #-} module My where -- straightforward definitions of fmap, pure, (<*>), join, return, (>>=), (>>) and fail in terms of IxFunctor, IxPointed, IxApplicative, IxMonad fPure m = do a <- m b <- m pure (a, b) fReturn m = do a <- m b <- m return (a, b) }}} According to -ddump-ds, these desugar to: {{{#!hs fPure :: IxMonad m => m k1 k1 a -> m k1 k1 (a, a) fPure m = My.join ( My.(<*>) (My.fmap (\a b -> My.pure (a, b)) m) m ) fReturn :: IxMonad m => m k1 k1 a -> m k1 k1 (a, a) fReturn m = My.join ( My.(<*>) (My.fmap (\a b -> My.return (a, b)) m) m ) }}} But I would expect: {{{#!hs fPure m = My.(<*>) (My.fmap (\a b -> (a, b)) m) m fReturn m = -- same }}} It appears that when "return" is not from base, ApplicativeDo only partially desugars to the specification. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12490> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #11612: Bug in ApplicativeDo
by GHC 02 Apr '17

02 Apr '17

#11612: Bug in ApplicativeDo -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- I discovered a bug in `ApplicativeDo`. Fix coming shortly. The problem is illustrated by this test case, which I will add to `ado001.hs` in the testsuite: {{{ test11 :: M () test11 = do x1 <- a let x2 = x1 x3 <- b let x4 = c x5 = x4 return (const () (x1,x2,x3,x4)) }}} Which should give `(a | b)`, but gives `(a ; b)` in 8.0.1 RC. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11612> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8501: Improve error message when using rec/mdo keyword without RecursiveDo extention.
by GHC 29 Mar '17

29 Mar '17

#8501: Improve error message when using rec/mdo keyword without RecursiveDo extention. -------------------------------------+------------------------------------- Reporter: shelarcy | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #3968 | -------------------------------------+------------------------------------- GHC shows unhelpful error message when using rec keyword and/or mdo keyword without RecursiveDo extention. {{{ module NoRecursiveDo where foo = do rec str <- return "foo" putStrLn str }}} {{{ $ ghc -c NoRecursiveDo.hs NoRecursiveDo1.hs:4:5: Parse error in pattern: rec }}} {{{ module NoRecursiveDo2 where bar = mdo str <- return "bar" putStrLn str }}} {{{ $ ghc -c NoRecursiveDo2.hs NoRecursiveDo2.hs:4:9: parse error on input `<-' }}} {{{ module NoRecursiveDo3 where baz = mdo putStrLn "baz" }}} {{{ $ ghc -c NoRecursiveDo3.hs NoRecursiveDo3.hs:3:7: Not in scope: `mdo' Perhaps you meant `mod' (imported from Prelude) }}} I think that GHC should suggest to use RecursiveDo extention when using mdo/rec keyword. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8501> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12983: Loading temp shared object failed: TemplateHaskell and recompilation
by GHC 27 Mar '17

27 Mar '17

#12983: Loading temp shared object failed: TemplateHaskell and recompilation -------------------------------------+------------------------------------- Reporter: StefanWehr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: template | Operating System: Unknown/Multiple haskell, recompilation | Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In our project, we get from time to time an error like this: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/8r/25v12lxd02zdm7lpky3xcnh80000gn/T/ghc40483_0/libghc_1.dylib, 5): Symbol not found: _ShortText_ShortText_con_info Referenced from: /var/folders/8r/25v12lxd02zdm7lpky3xcnh80000gn/T/ghc40483_0/libghc_1.dylib Expected in: flat namespace in /var/folders/8r/25v12lxd02zdm7lpky3xcnh80000gn/T/ghc40483_0/libghc_1.dylib }}} I was able to create a somewhat minimal setup for reproducing the problem. I've reproduced the problem on Mac and Linux with GHC 8.0.1, didn't try on Windows. The root of the problem seems to be an interaction with template haskell and the recompilation manager. I'll now explain the setup. I've attached an archive which contains all code and a simple build script. Just unpack the archive and execute ./build.sh to reproduce the problem. The setup consists of four files. (Don't be confused by the module names. They are derived from our project). The problem arises after a change to one of these files and a recompilation. Here are the initial versions of the four files. {{{#!hs -- src/ShortText.hs module ShortText where data ShortText = ShortText String toString :: ShortText -> String toString (ShortText s) = s }}} {{{#!hs -- src/Hospital.hs module Hospital where foo :: Int -> String foo i = show i }}} {{{#!hs -- src/Types.hs {-# LANGUAGE TemplateHaskell #-} module Types where import qualified Hospital import Language.Haskell.TH genCode :: Q [Dec] genCode = let s = Hospital.foo 5 in [d|string = s|] }}} {{{#!hs -- src/MetaHandler.hs {-# LANGUAGE TemplateHaskell #-} module Main where import qualified Types -- splices in "string :: String" $(Types.genCode) main :: IO () main = putStrLn string }}} Compiling the project for the first time works without problems: {{{ $ /Users/swehr/.stack/programs/x86_64-osx/ghc-8.0.1/bin/ghc -O0 -isrc -ibuild -dynamic -outputdir build -package template-haskell --make src/MetaHandler.hs [1 of 3] Compiling Hospital ( src/Hospital.hs, build/Hospital.o ) [2 of 3] Compiling Types ( src/Types.hs, build/Types.o ) [3 of 3] Compiling Main ( src/MetaHandler.hs, build/Main.o ) Linking src/MetaHandler ... }}} I then changed the content of src/Hospital.hs to use the ShortText module. Here is the new content: {{{#!hs -- src/Hospital.hs module Hospital where import ShortText foo :: Int -> String foo i = toString (ShortText (show i)) }}} Then recompilation fails: {{{ [1 of 4] Compiling ShortText ( src/ShortText.hs, build/ShortText.o ) [2 of 4] Compiling Hospital ( src/Hospital.hs, build/Hospital.o ) [4 of 4] Compiling Main ( src/MetaHandler.hs, build/Main.o ) [TH] ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/8r/25v12lxd02zdm7lpky3xcnh80000gn/T/ghc40827_0/libghc_7.dylib, 5): Symbol not found: _ShortText_ShortText_con_info Referenced from: /var/folders/8r/25v12lxd02zdm7lpky3xcnh80000gn/T/ghc40827_0/libghc_7.dylib Expected in: flat namespace in /var/folders/8r/25v12lxd02zdm7lpky3xcnh80000gn/T/ghc40827_0/libghc_7.dylib Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Looking at the output when compiling with -v3 gives a clue why: {{{ ... *** Linker: /usr/bin/gcc -m64 -fno-stack-protector -DTABLES_NEXT_TO_CODE -m64 -dynamiclib -o /var/folders/8r/25v12lxd02zdm7lpky3xcnh80000gn/T/ghc40913_0/libghc_7.dylib build/Hospital.o build/Types.o -undefined dynamic_lookup -single_module -install_name '@rpath/libghc_7.dylib' -L/Users/swehr/.stack/programs/x86_64-osx/ghc-8.0.1/lib/ghc-8.0.1 /template-haskell-2.11.0.0 -Wl,-rpath -Wl,/Users/swehr/.stack/programs/x86_64-osx/ghc-8.0.1/lib/ghc-8.0.1 /template-haskell-2.11.0.0 -L/Users/swehr/.stack/programs/x86_64-osx/ghc-8.0.1/lib/ghc-8.0.1/pretty-1.1.3.3 -Wl,-rpath -Wl,/Users/swehr/.stack/programs/x86_64-osx/ghc-8.0.1/lib/ghc-8.0.1/pretty-1.1.3.3 -L/Users/swehr/.stack/programs/x86_64-osx/ghc-8.0.1/lib/ghc-8.0.1/deepseq-1.4.2.0 -Wl,-rpath -Wl,/Users/swehr/.stack/programs/x86_64-osx/ghc-8.0.1/lib/ghc-8.0.1/deepseq-1.4.2.0 -L/Users/swehr/.stack/programs/x86_64-osx/ghc-8.0.1/lib/ghc-8.0.1/array-0.5.1.1 -Wl,-rpath -Wl,/Users/swehr/.stack/programs/x86_64-osx/ghc-8.0.1/lib/ghc-8.0.1/array-0.5.1.1 -L/Users/swehr/.stack/programs/x86_64-osx/ghc-8.0.1/lib/ghc-8.0.1/ghc- boot-th-8.0.1 -Wl,-rpath -Wl,/Users/swehr/.stack/programs/x86_64-osx/ghc-8.0.1/lib/ghc-8.0.1/ghc- boot-th-8.0.1 -L/Users/swehr/.stack/programs/x86_64-osx/ghc-8.0.1/lib/ghc-8.0.1/base-4.9.0.0 -Wl,-rpath -Wl,/Users/swehr/.stack/programs/x86_64-osx/ghc-8.0.1/lib/ghc-8.0.1/base-4.9.0.0 -L/Users/swehr/.stack/programs/x86_64-osx/ghc-8.0.1/lib/ghc-8.0.1/integer- gmp-1.0.0.1 -Wl,-rpath -Wl,/Users/swehr/.stack/programs/x86_64-osx/ghc-8.0.1/lib/ghc-8.0.1 /integer-gmp-1.0.0.1 -L/Users/swehr/.stack/programs/x86_64-osx/ghc-8.0.1/lib/ghc-8.0.1/ghc- prim-0.5.0.0 -Wl,-rpath -Wl,/Users/swehr/.stack/programs/x86_64-osx/ghc-8.0.1/lib/ghc-8.0.1/ghc- prim-0.5.0.0 -L/Users/swehr/.stack/programs/x86_64-osx/ghc-8.0.1/lib/ghc-8.0.1/rts -Wl,-rpath -Wl,/Users/swehr/.stack/programs/x86_64-osx/ghc-8.0.1/lib/ghc-8.0.1/rts -lHStemplate-haskell-2.11.0.0-ghc8.0.1 -lHSpretty-1.1.3.3-ghc8.0.1 -lHSdeepseq-1.4.2.0-ghc8.0.1 -lHSarray-0.5.1.1-ghc8.0.1 -lHSghc-boot- th-8.0.1-ghc8.0.1 -lHSbase-4.9.0.0-ghc8.0.1 -lHSinteger- gmp-1.0.0.1-ghc8.0.1 -lHSghc-prim-0.5.0.0-ghc8.0.1 -liconv *** Deleting temp files: Deleting: /var/folders/8r/25v12lxd02zdm7lpky3xcnh80000gn/T/ghc40913_0/ghc_8.rsp /var/folders/8r/25v12lxd02zdm7lpky3xcnh80000gn/T/ghc40913_0/libghc_7.dylib *** Deleting temp dirs: Deleting: /var/folders/8r/25v12lxd02zdm7lpky3xcnh80000gn/T/ghc40913_0 ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/8r/25v12lxd02zdm7lpky3xcnh80000gn/T/ghc40913_0/libghc_7.dylib, 5): Symbol not found: _ShortText_ShortText_con_info Referenced from: /var/folders/8r/25v12lxd02zdm7lpky3xcnh80000gn/T/ghc40913_0/libghc_7.dylib Expected in: flat namespace in /var/folders/8r/25v12lxd02zdm7lpky3xcnh80000gn/T/ghc40913_0/libghc_7.dylib }}} We can see here that the .o file for ShortText is not passed to gcc when building libghc_7.dylib. I suspect that libghc_7.dylib is used to run template haskell code, but this is only a guess. Looking at the .hi file for MetaHandler, we can see why gcc does not get the .o file for ShortText: ShortText is not included in the module dependencies: {{{ $ /Users/swehr/.stack/programs/x86_64-osx/ghc-8.0.1/bin/ghc --show-iface build/Main.hi Magic: Wanted 33214052, got 33214052 Version: Wanted [8, 0, 0, 1], got [8, 0, 0, 1] Way: Wanted [], got [d, y, n] interface Main 8001 interface hash: def8085a5dcb4980922089d5d21cf0f9 ABI hash: 1a46783c6a6c6b308503cf705db45d4d export-list hash: d2d75d71ebb6963f6e9c9a5b4050ef71 orphan hash: 693e9af84d3dfcc71e640e005bdc5e2e flag hash: 3468616c2ba87fe39e866ff30d651f01 sig of: Nothing used TH splices: True where exports: main string module dependencies: Hospital Types package dependencies: array-0.5.1.1 base-4.9.0.0 deepseq-1.4.2.0 ghc-boot-th-8.0.1 ghc-prim-0.5.0.0 integer- gmp-1.0.0.1 pretty-1.1.3.3 template-haskell-2.11.0.0 orphans: GHC.Base GHC.Float }}} I think the main problem is that src/Types.hs is not recompiled in the second run. I also experimented with compiling each file separately, using the -c flag. When I then compile src/Types.hs, ghc outputs "compilation NOT required" in the second run. If a compile src/Types.hs with -fforce- recomp in the 2nd run, everything works fine. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12983> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12181: Multi-threaded code on ARM64 GHC runtime doesn't use all available cores
by GHC 27 Mar '17

27 Mar '17

#12181: Multi-threaded code on ARM64 GHC runtime doesn't use all available cores -------------------------------------+------------------------------------- Reporter: varosi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.10.3 System | Keywords: | Operating System: Unknown/Multiple Architecture: arm | Type of failure: Runtime | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is the machine: [http://www.cnx-software.com/2016/04/30/setup-guide-mini-review-of-bq- aquaris-m10-ubuntu-edition-tablet-from-a-developers-perspective/] Haskell ray-tracer that uses Control.Parallel.Strategies and parBuffer that is working well on x64 machine and using all the cores available use only 2 cores from 4 in total on that ARM machine. This machine usually work on two cores only and when it sees that they are used more - it enables two more to get total of four cores. If I give "+RTS -N4" it works just fine. So I think the problem is that the runtime doesn't check for all available cores, but only for enabled. In the first link you could see that "lscpu" returns 4 cores in total. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12181> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #9418: Warnings about "INLINE binder is (non-rule) loop breaker"
by GHC 27 Mar '17

27 Mar '17

#9418: Warnings about "INLINE binder is (non-rule) loop breaker" -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Gabor rightly complains: I see literally ''thousands'' of these warnings (in yesterday's and) today's bootstraps: {{{ HC [stage 1] libraries/base/dist-install/build/GHC/Base.o *** Core Lint warnings : in result of Desugar (after optimization) *** {-# LINE 261 "libraries/base/GHC/Base.lhs #-}: Warning: [RHS of $c>>_arr :: forall r_agf a_adQ b_adR. (r_agf -> a_adQ) -> (r_agf -> b_adR) -> r_agf -> b_adR] INLINE binder is (non-rule) loop breaker: $c>>_arr {-# LINE 632 "libraries/base/GHC/Base.lhs #-}: Warning: [RHS of $c>>_apH :: forall a_adQ b_adR. GHC.Types.IO a_adQ -> GHC.Types.IO b_adR -> GHC.Types.IO b_adR] INLINE binder is (non-rule) loop breaker: $c>>_apH }}} }}} This is clearly unsatisfactory, because it is unsettling, and perhaps conceals more important warnings. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9418> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12137: Warning about “INLINE binder is (non-rule) loop breaker” with `-dcore-lint`
by GHC 27 Mar '17

27 Mar '17

#12137: Warning about “INLINE binder is (non-rule) loop breaker” with `-dcore-lint` -------------------------------------+------------------------------------- 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: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- With this code using `lens` {{{#!hs {-# Language TemplateHaskell #-} import Control.Lens data Config = Config { _companyName :: String } data AppState = AppState { _asConfig :: Config } makeClassy ''Config instance HasConfig AppState where config = undefined }}} gives {{{ $ ghci -ignore-dot-ghci -dcore-lint /tmp/tvQq.hs GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/tvQq.hs, interpreted ) *** Core Lint warnings : in result of Simplifier *** /tmp/tvQq.hs:10:10: warning: [RHS of $ccompanyName_a7EP :: Lens' AppState String] INLINE binder is (non-rule) loop breaker: $ccompanyName_a7EP *** Core Lint warnings : in result of Simplifier *** /tmp/tvQq.hs:10:10: warning: [RHS of $ccompanyName_a7EP :: Lens' AppState String] INLINE binder is (non-rule) loop breaker: $ccompanyName_a7EP Ok, modules loaded: Main. *Main> }}} ---- `makeClass` actually dumps {{{ <interactive>:64:54-72: Splicing declarations makeClassy ''Config ======> class HasConfig c_axo7 where config :: Lens' c_axo7 Config companyName :: Lens' c_axo7 String {-# INLINE companyName #-} companyName = (.) config companyName instance HasConfig Config where {-# INLINE companyName #-} config = id companyName = iso (\ (Config x_axo8) -> x_axo8) Config }}} Using that to create a small example ---- {{{#!hs data Config = Config { name :: String } class HasConfig a where config :: a -> Config companyName :: a -> String {-# INLINE companyName #-} companyName a = name (config a) instance HasConfig Config where {-# INLINE companyName #-} config = id companyName = name . config }}} which works perfectly fine without `-dcore-lint` but fails with {{{ $ ghci -ignore-dot-ghci -dcore-lint /tmp/tvQq.hs GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/tvQq.hs, interpreted ) *** Core Lint warnings : in result of Simplifier *** /tmp/tvQq.hs:11:3: warning: [RHS of $ccompanyName_a18Q :: Config -> String] INLINE binder is (non-rule) loop breaker: $ccompanyName_a18Q *** Core Lint warnings : in result of Simplifier *** /tmp/tvQq.hs:11:3: warning: [RHS of $ccompanyName_a18Q :: Config -> String] INLINE binder is (non-rule) loop breaker: $ccompanyName_a18Q Ok, modules loaded: Main. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12137> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12709: GHC panic
by GHC 21 Mar '17

21 Mar '17

#12709: GHC panic -------------------------------------+------------------------------------- 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: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I get {{{ $ ./ghc-stage2 -ignore-dot-ghci --interactive /tmp/tEZm.hs GHCi, version 8.1.20160930: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/tEZm.hs, interpreted ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20160930 for x86_64-unknown-linux): kindPrimRep.go rep_a13E Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1076:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1080:37 in ghc:Outputable pprPanic, called at compiler/simplStg/RepType.hs:369:9 in ghc:RepType kindPrimRep, called at compiler/simplStg/RepType.hs:337:18 in ghc:RepType typePrimRep, called at compiler/ghci/ByteCodeGen.hs:1541:15 in ghc:ByteCodeGen Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} running {{{#!hs {-# Language MagicHash, PolyKinds, ViewPatterns, TypeInType, RebindableSyntax, NoImplicitPrelude #-} import GHC.Types import Prelude hiding (Num (..)) import qualified Prelude as P import GHC.Prim data BoxUnbox = BUB Int Int# class Num (a :: TYPE rep) where (+) :: a -> a -> a fromInteger :: Integer -> a instance Num Int where (+) = (P.+) fromInteger = P.fromInteger instance Num Int# where (+) = (+#) fromInteger (fromInteger -> I# n) = n a :: BoxUnbox a = let u :: Num (a :: TYPE rep) => a u = 1 + 2 + 3 + 4 in BUB u u }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12709> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9701: GADTs not specialized properly
by GHC 21 Mar '17

21 Mar '17

#9701: GADTs not specialized properly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Runtime Blocked By: | performance bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This has probably been raised before, but I can't find a ticket. If I write {{{#!hs data Silly a where Silly :: Ord a => a -> Silly a isItSilly :: a -> Silly a -> Bool isItSilly a (Silly x) = a < x isItSillyInt :: Int -> Silly Int -> Bool isItSillyInt = isItSilly }}} then I get {{{ isItSilly isItSilly = \ @ a_aBq eta_B2 eta1_B1 -> case eta1_B1 of _ { Silly $dOrd_aBs x_aAy -> < $dOrd_aBs eta_B2 x_aAy } isItSillyInt isItSillyInt = isItSilly }}} Although GHC knows that `eta_B2` is an `Int`, and `x_aAy` therefore must be one as well, it looks up the `<` method in the `eta1_B1` dictionary instead of just using `ltInt`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9701> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14