June 2018 - ghc-tickets

[GHC] #11514: Impredicativity is still sneaking in
by GHC 21 Mar '19

21 Mar '19

#11514: Impredicativity is still sneaking in -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire 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: -------------------------------------+------------------------------------- This is erroneously accepted: {{{ {-# LANGUAGE RankNTypes #-} module Bug where foo :: forall a. (Show a => a -> a) -> () foo = undefined }}} `undefined` is being instantiated at `(Show a => a -> a) -> ()`, which requires impredicativity. GHC does the right thing (reject!) if we try to instantiate with a type involving proper foralls. I imagine this is a simple missing check. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11514> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14828: panic! when using :print on some functions with class constraints?
by GHC 21 Mar '19

21 Mar '19

#14828: panic! when using :print on some functions with class constraints? -------------------------------------+------------------------------------- Reporter: jol | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.2 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- These are the problematic ones I've found: {{{ > :t foldl foldl :: Foldable t => (b -> a -> b) -> b -> t a -> b > :print foldl ghc: panic! (the 'impossible' happened) (GHC version 8.2.2 for x86_64-unknown-linux): isUnliftedType t1_a1H7[rt] :: TYPE t_a1H6[rt] 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:1952:10 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > :t fmap fmap :: Functor f => (a -> b) -> f a -> f b > :print fmap ghc: panic! (the 'impossible' happened) (GHC version 8.2.2 for x86_64-unknown-linux): isUnliftedType t1_a1Hu[rt] :: TYPE t_a1Ht[rt] 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:1952:10 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > :t return return :: Monad m => a -> m a > :print return ghc: panic! (the 'impossible' happened) (GHC version 8.2.2 for x86_64-unknown-linux): isUnliftedType t1_a1Wt[rt] :: TYPE t_a1Ws[rt] 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:1952:10 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > :t pure pure :: Applicative f => a -> f a > :print pure ghc: panic! (the 'impossible' happened) (GHC version 8.2.2 for x86_64-unknown-linux): isUnliftedType t1_a1WP[rt] :: TYPE t_a1WO[rt] 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:1952:10 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} These that don't have constraints are fine: {{{ > :print id id = (_t1::a -> a) > :print map map = (_t2::(a1 -> b) -> [a1] -> [b]) > :print const const = (_t3::a2 -> b1 -> a2) }}} This value and function created in the session are fine: {{{ > let x :: Monad m => m (); x = return () Prelude| > :p x x = (_t5::Monad m1 => m1 ()) > let f :: Monad m => Int -> m Int; f n = return (n + 1) Prelude| > :p f f = (_t6::Monad m2 => Int -> m2 Int) }}} mempty and mappend imported from Data.Monoid are fine: {{{ > :m + Data.Monoid > :p mempty mempty = (_t7::Monoid a4 => a4) > :p mappend mappend = (_t8::Monoid a4 => a4 -> a4 -> a4) }}} foldl' and foldr imported from Data.List are not fine: {{{ > :m + Data.List > :p foldl' ghc: panic! (the 'impossible' happened) (GHC version 8.2.2 for x86_64-unknown-linux): isUnliftedType t1_a6Qy[rt] :: TYPE t_a6Qx[rt] 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:1952:10 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > :p Data.List.foldr ghc: panic! (the 'impossible' happened) (GHC version 8.2.2 for x86_64-unknown-linux): isUnliftedType t2_a6RG[rt] :: TYPE t1_a6RF[rt] 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:1952:10 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} but `all` and `init` from that same module are fine: {{{ > :p Data.List.all all = (_t13::Foldable t1 => (a22 -> Bool) -> t1 a22 -> Bool) > :p Data.List.init init = (_t14::[a29] -> [a29]) }}} So, in a given module, among functions with class constraints, some have the error and others don't. I haven't found a value that's not a function with the error, and I haven't found a function with no class constraints exhibit the error. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14828> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #13101: Enable GHC to be loaded into GHCi
by GHC 18 Mar '19

18 Mar '19

#13101: Enable GHC to be loaded into GHCi -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | 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: -------------------------------------+------------------------------------- It would be very helpful for development to be able to load GHC itself into GHCi. In principle this shouldn't be so hard since GHC is just another Haskell program. However, in practice there are a number of modules which use unboxed tuples, which the interpreter does not support. However, it should be possible to the convince GHC to use object code for just these modules and interpret the rest. I have a few attempts at this here (https://gist.github.com/bgamari/bd53e4fd6f3323599387ffc7b11d1a1e) See the following related mailing list threads, * https://mail.haskell.org/pipermail/ghc-devs/2017-January/013545.html * https://mail.haskell.org/pipermail/ghc-devs/2016-March/011555.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13101> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12770: Shrink list of RUNPATH entries for GHC libraries
by GHC 15 Mar '19

15 Mar '19

#12770: Shrink list of RUNPATH entries for GHC libraries -------------------------------------+------------------------------------- Reporter: slyfox | 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: -------------------------------------+------------------------------------- Recently Cabal/GHC acquired '''dynamic-library-dirs''' file tag support in ''' .conf''' files. Cabal-HEAD when used with GHC-HEAD puts all shared libraries into a single directory except the GHC itself (a fallout of https://github.com/haskell/cabal/issues/4046 ). In https://github.com/haskell/cabal/issues/4046#issuecomment-256603828 Christiaan explains our current sources of RUNPATH tags. Basically, current GHC dynamic library layout is still per-directory: {{{ /usr/lib64/ghc-8.1.20161026/Cabal-1.25.0.0/libHSCabal-1.25.0.0-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/array-0.5.1.1/libHSarray-0.5.1.1-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/base-4.9.0.0/libHSbase-4.9.0.0-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/binary-0.8.3.0/libHSbinary-0.8.3.0-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/bytestring-0.10.8.1/libHSbytestring-0.10.8.1-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/compact-1.0.0.0/libHScompact-1.0.0.0-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/containers-0.5.7.1/libHScontainers-0.5.7.1-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/deepseq-1.4.2.0/libHSdeepseq-1.4.2.0-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/directory-1.2.6.2/libHSdirectory-1.2.6.2-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/filepath-1.4.1.0/libHSfilepath-1.4.1.0-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/ghc-8.1/libHSghc-8.1-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/ghc-boot-8.1/libHSghc- boot-8.1-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/ghc-boot-th-8.1/libHSghc-boot- th-8.1-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/ghc-prim-0.5.0.0/libHSghc- prim-0.5.0.0-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/ghci-8.1/libHSghci-8.1-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/haskeline-0.7.2.3/libHShaskeline-0.7.2.3-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/hoopl-3.10.2.1/libHShoopl-3.10.2.1-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/hpc-0.6.0.3/libHShpc-0.6.0.3-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/integer-gmp-1.0.0.1/libHSinteger- gmp-1.0.0.1-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/pretty-1.1.3.3/libHSpretty-1.1.3.3-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/process-1.4.2.0/libHSprocess-1.4.2.0-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/rts/libHSrts-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/rts/libHSrts_debug-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/rts/libHSrts_l-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/rts/libHSrts_thr-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/rts/libHSrts_thr_debug-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/rts/libHSrts_thr_l-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/template-haskell-2.11.0.0/libHStemplate- haskell-2.11.0.0-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/terminfo-0.4.0.2/libHSterminfo-0.4.0.2-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/time-1.6.0.1/libHStime-1.6.0.1-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/transformers-0.5.2.0/libHStransformers-0.5.2.0-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/unix-2.7.2.0/libHSunix-2.7.2.0-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/xhtml-3000.2.1/libHSxhtml-3000.2.1-ghc8.1.20161026.so }}} Could we store them exactly as Cabal does? Namely {{{ dynamic-library-dirs: /usr/lib64/x86_64-linux-ghc-8.1.20161026 }}} Then for globally installed packages (how distributions usually build packages) we would have exactly one RUNPATH. Currently we have: {{{ $ readelf -a /usr/bin/read-idiii | grep RUNPATH 0x000000000000001d (RUNPATH) Library runpath: [/usr/lib64/ghc-8.1.20161026/array-0.5.1.1:/usr/lib64/ghc-8.1.20161026/base-4.9.0.0:/usr/lib64/ghc-8.1.20161026/binary-0.8.3.0:/usr/lib64/ghc-8.1.20161026/bytestring-0.10.8.1:/usr/lib64/ghc-8.1.20161026/containers-0.5.7.1:/usr/lib64/ghc-8.1.20161026/deepseq-1.4.2.0:/usr/lib64/ghc-8.1.20161026/directory-1.2.6.2:/usr/lib64/ghc-8.1.20161026/filepath-1.4.1.0:/usr/lib64/ghc-8.1.20161026 /ghc-prim-0.5.0.0:/usr/lib64/ghc-8.1.20161026/integer- gmp-1.0.0.1:/usr/lib64/ghc-8.1.20161026/process-1.4.2.0:/usr/lib64/ghc-8.1.20161026/rts:/usr/lib64/ghc-8.1.20161026/time-1.6.0.1:/usr/lib64/ghc-8.1.20161026/transformers-0.5.2.0:/usr/lib64/ghc-8.1.20161026/unix-2.7.2.0:/usr/lib64/x86_64 -linux-ghc-8.1.20161026] }}} And that could be just single {{{ /usr/lib64/x86_64-linux-ghc-8.1.20161026 }}} It's close to ticket #11587. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12770> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13951: InScope set assertion failure from monad-skeleton
by GHC 12 Mar '19

12 Mar '19

#13951: InScope set assertion failure from monad-skeleton -------------------------------------+------------------------------------- Reporter: mpickering | 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 PolyKinds, GADTs, Rank2Types, ScopedTypeVariables, Trustworthy #-} module Control.Monad.Skeleton.Internal where data Cat k a b where Empty :: Cat k a a Leaf :: k a b -> Cat k a b Tree :: Cat k a b -> Cat k b c -> Cat k a c viewL :: forall k a b r. Cat k a b -> ((a ~ b) => r) -> (forall x. k a x -> Cat k x b -> r) -> r viewL Empty e _ = e viewL (Leaf k) _ r = k `r` Empty viewL (Tree a b) e r = go a b where go :: Cat k a x -> Cat k x b -> r go Empty t = viewL t e r go (Leaf k) t = r k t go (Tree c d) t = go c (Tree d t) }}} Leads to the assertion failure {{{ [1 of 1] Compiling Control.Monad.Skeleton.Internal ( Internal.hs, Internal.o ) WARNING: file compiler/simplCore/OccurAnal.hs, line 2160 Just 3 [] ghc: panic! (the 'impossible' happened) (GHC version 8.2.0.20170708 for x86_64-unknown-linux): ASSERT failed! in_scope InScope {x_avF ds_d14c} tenv [avF :-> x_avF] tenvFVs [avF :-> x_avF, a11Z :-> k_a11Z] cenv [] cenvFVs [] tys [k1_a120 a_a121 x_avF] cos [] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1188:22 in ghc:Outputable assertPprPanic, called at compiler/types/TyCoRep.hs:2088:56 in ghc:TyCoRep checkValidSubst, called at compiler/types/TyCoRep.hs:2121:29 in ghc:TyCoRep substTy, called at compiler/coreSyn/CoreArity.hs:1197:19 in ghc:CoreArity 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/utils/Outputable.hs:1186:5 in ghc:Outputable assertPprPanic, called at compiler/types/TyCoRep.hs:2088:56 in ghc:TyCoRep checkValidSubst, called at compiler/types/TyCoRep.hs:2121:29 in ghc:TyCoRep substTy, called at compiler/coreSyn/CoreArity.hs:1197:19 in ghc:CoreArity Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13951> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11371: Bogus in-scope set in substitutions
by GHC 12 Mar '19

12 Mar '19

#11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.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: -------------------------------------+------------------------------------- Bartosz [https://mail.haskell.org/pipermail/ghc- devs/2016-January/010892.html reports] that substitution isn't working properly for him. He cites this Note in `TyCoRep`: {{{ -- Note [Generating the in-scope set for a substitution] -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- If we want to substitute [a -> ty1, b -> ty2] I used to -- think it was enough to generate an in-scope set that includes -- fv(ty1,ty2). But that's not enough; we really should also take the -- free vars of the type we are substituting into! Example: -- (forall b. (a,b,x)) [a -> List b] -- Then if we use the in-scope set {b}, there is a danger we will rename -- the forall'd variable to 'x' by mistake, getting this: -- (forall x. (List b, x, x)) -- Urk! This means looking at all the calls to mkOpenTCvSubst.... }}} I think this is an outright bug that has been lurking for ages, and which Bartosz has just managed to tickle. Things to do: * We should add an ASSERT to substTy (and similar functions): **when calling `substTy subst ty` it should be the case that the in-scope set in the substitution is a superset of** * **The free vars of the range of the substitution** * **The free vars of ty minus the domain of the substitution** That ASSERT could be added to the immediate callers of `subst_ty` in `TyCoRep`. (Bartosz: if you add that you should find that it trips before the bug you are actually getting.) * How to fix it properly? The places to look are: everywhere that uses (transitively) one of the `mkOpenTCvSubst` or `zipOpenTCvSubst` functions. * Many calls to `mkOpenTCvSubst` produce a substitution that is only applied to closed types; or at least to types whose only free variables are the ones in the domain of the substitution. Example: the call to `zipOpenTCvSubst` in `DataCon.dataConInstSig`. These ones will all satisfy the ASSERT[[BR]][[BR]] * In other cases, we already have the in-scope set in hand. Example: in `CoreLint.lintTyApp` we find a call to `substTyWith`. But Lint carries an in-scope set, so it would be easy to pass it to `substTyWith`.[[BR]][[BR]] * Finally there may be cases where we really have to take the free vars of the type we are substituting into, and add them to the in-scope set. Doubtless all this applies to substituting in coercions too, and indeed into expressions. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11371> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 64

[GHC] #14533: Make GHC more robust against PC crashes by using atomic writes
by GHC 10 Mar '19

10 Mar '19

#14533: Make GHC more robust against PC crashes by using atomic writes -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Yesterday my Windows machine crashed when ghc was building, left me with a lot of corrupted .hi files (and probably .o files as well). That made me think if we should change ghc to write its output with atomic moves. Discussion on `#ghc`: {{{ bgamari: nh2: well, perhaps I'm not sure it's terribly common for compilers to take such precautions though and if we were to do it for interface files then presumably we would also want to do it for object files siarheit_: that would be very nice geekosaur: compilers in general are happy to write out incomplete/garbage object files bgamari: it seems that way nh2: bgamari: right, if we wanted to do it we should do it for all files ghc writes. Possible that other compilers can also write garbage, but maybe ghc can do better -- one less thing the developer has to think about Phyx-: most compilers also don't do the aggressive recompilation avoidance things we do either.. corrupt hi files wouldn't be an issue if the next time it would override them :) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14533> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #13839: GHC warnings do not respect the default module header
by GHC 09 Mar '19

09 Mar '19

#13839: GHC warnings do not respect the default module header -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: (none) 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: -------------------------------------+------------------------------------- If I compile this program with `-Wall`, I get no warnings: {{{#!hs type T = Int main :: IO () main = return () }}} If I add a module header: {{{#!hs module Main(main) where type T = Int main :: IO () main = return () }}} I now get a warning: {{{ ghcbug2.hs:3:1: warning: [-Wunused-top-binds] Defined but not used: type constructor or class ‘T’ }}} Yet, according to Haskell2010 (section 5.1): > An abbreviated form of module, consisting only of the module body, is permitted. If this is used, the header is assumed to be ‘module Main(main) where’. Therefore, the right behaviour should be to print a warning in the first case as well. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13839> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #14741: High-memory usage during compilation using Template Haskell
by GHC 09 Mar '19

09 Mar '19

#14741: High-memory usage during compilation using Template Haskell -------------------------------------+------------------------------------- Reporter: donatello | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 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: -------------------------------------+------------------------------------- When trying to embed some files into an executable using Template Haskell, I find that memory usage during compilation exceeds 4GB and often crashes my laptop. The files I am trying to embed are only about 25MB in size (totally 35MB in size). I made a somewhat minimal example to demonstrate this problem. To embed the files, I am using the [https://hackage.haskell.org/package/file-embed `file-embed`] package (the issue persists when using the alternative [https://hackage.haskell.org/package/wai-app-static `wai-app-static`] package too. The code to demonstrate runs in Linux and is available here - https://github.com/donatello/file-embed-exp. To try it out, just clone the repository and run Make (it uses the Haskell Stack tool and the Linux dd utility). This appear to be an issue in GHC. Is there anyway to mitigate the issue in the current version? Related discussion: https://github.com/snoyberg/file-embed/issues/24 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14741> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #10069: CPR related performance issue
by GHC 09 Mar '19

09 Mar '19

#10069: CPR related performance issue -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- By default CRP analysis can be too aggressive in trying to pass as much as possible in unboxed tuples, in general it's not a problem but when one big datatype is passed to several consumers it might end up pushed to stack several times instead of once - to heap, things are getting worse when there are sufficient fields to cause stack overflow which otherwise is possible to avoid - in our codebase adding one field with ExistentialQuantification (unused, but that prevents ghc from doing CRP transformation) reduces number of stack overflow by a factor of 1000 and increases overall performance by 10%. In provided example performance for both A and B should be identical and yet B is consistently faster by 3-5% It's possible to increase this performance gap by adding more and more fields. I was able to replicate this issue in ghc 7.8.3 and 7.10,1rc2 {{{#!hs {-# LANGUAGE ExistentialQuantification #-} module Blah where import Criterion import Criterion.Main import Data.Typeable data A = A () !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int data B = forall rep. (Typeable rep) => B rep !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int a :: A a = A () 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 b :: B b = B () 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 {-# NOINLINE a1 #-} a1 :: A -> Int a1 (A _ f1 f2 f3 f4 f5 f6 f7 f8 g1 g2 g3 g4 g5 g6 g7 g8 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _) = f1 {-# NOINLINE a2 #-} a2 :: A -> Int a2 (A _ f1 f2 f3 f4 f5 f6 f7 f8 g1 g2 g3 g4 g5 g6 g7 g8 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _) = f2 {-# NOINLINE a3 #-} a3 :: A -> Int a3 (A _ f1 f2 f3 f4 f5 f6 f7 f8 g1 g2 g3 g4 g5 g6 g7 g8 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _) = f3 {-# NOINLINE a4 #-} a4 :: A -> Int a4 (A _ f1 f2 f3 f4 f5 f6 f7 f8 g1 g2 g3 g4 g5 g6 g7 g8 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _) = f4 {-# NOINLINE b1 #-} b1 :: B -> Int b1 (B _ f1 f2 f3 f4 f5 f6 f7 f8 g1 g2 g3 g4 g5 g6 g7 g8 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _) = f1 {-# NOINLINE b2 #-} b2 :: B -> Int b2 (B _ f1 f2 f3 f4 f5 f6 f7 f8 g1 g2 g3 g4 g5 g6 g7 g8 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _) = f2 {-# NOINLINE b3 #-} b3 :: B -> Int b3 (B _ f1 f2 f3 f4 f5 f6 f7 f8 g1 g2 g3 g4 g5 g6 g7 g8 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _) = f3 {-# NOINLINE b4 #-} b4 :: B -> Int b4 (B _ f1 f2 f3 f4 f5 f6 f7 f8 g1 g2 g3 g4 g5 g6 g7 g8 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _) = f4 {-# NOINLINE fa #-} fa :: A -> Int fa a = a1 a + a2 a + a3 a + a4 a {-# NOINLINE fb #-} fb :: B -> Int fb b = b1 b + b2 b + b3 b + b4 b main :: IO () main = defaultMain [ bgroup "single call" [ bench "A" $ whnf fa a , bench "B" $ whnf fb b ] ] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10069> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 39