- ghc-tickets - Haskell.org

[GHC] #12664: System.Environment.withArgs and friends leak memory
by GHC 19 Oct '16

19 Oct '16

#12664: System.Environment.withArgs and friends leak memory -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: | Version: 8.0.1 libraries/base | 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: -------------------------------------+------------------------------------- `ArgvLeak.hs`: {{{ import System.Environment main :: IO () main = withArgs ["a","b","c"] $ return () }}} repro: {{{ > ghc ArgvLeak.hs [1 of 1] Compiling Main ( ArgvLeak.hs, ArgvLeak.o ) Linking ArgvLeak ... > valgrind --leak-check=full ./ArgvLeak ==27227== Memcheck, a memory error detector ==27227== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==27227== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info ==27227== Command: ./ArgvLeak ==27227== ==27227== Warning: set address range perms: large range [0x200000000, 0x600100000) (noaccess) ==27227== ==27227== HEAP SUMMARY: ==27227== in use at exit: 107 bytes in 9 blocks ==27227== total heap usage: 62 allocs, 53 frees, 60,175 bytes allocated ==27227== ==27227== 55 (40 direct, 15 indirect) bytes in 1 blocks are definitely lost in loss record 6 of 6 ==27227== at 0x4C2FB55: calloc (in /usr/lib/valgrind /vgpreload_memcheck-amd64-linux.so) ==27227== by 0x470057: stgCallocBytes (RtsUtils.c:107) ==27227== by 0x4652C1: copyArgv (RtsFlags.c:1811) ==27227== by 0x465FAE: setProgArgv (RtsFlags.c:1877) ==27227== by 0x41CC4A: base_SystemziEnvironment_zdLr7BcsetProgArgv_info (in /home/smarlow/scratch/ArgvLeak) ==27227== ==27227== LEAK SUMMARY: ==27227== definitely lost: 40 bytes in 1 blocks ==27227== indirectly lost: 15 bytes in 4 blocks ==27227== possibly lost: 0 bytes in 0 blocks ==27227== still reachable: 52 bytes in 4 blocks ==27227== suppressed: 0 bytes in 0 blocks ==27227== Reachable blocks (those to which a pointer was found) are not shown. ==27227== To see them, rerun with: --leak-check=full --show-leak-kinds=all ==27227== ==27227== For counts of detected and suppressed errors, rerun with: -v ==27227== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12664> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12719: master branch broken with alex 3.2
by GHC 18 Oct '16

18 Oct '16

#12719: master branch broken with alex 3.2 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: highest | Milestone: 8.2.1 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: -------------------------------------+------------------------------------- The build fails with all sorts of type errors. Need to work out what is going on when there is time. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12719> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12616: type synonyms confuse generalized newtype deriving role checking
by GHC 18 Oct '16

18 Oct '16

#12616: type synonyms confuse generalized newtype deriving role checking -------------------------------------+------------------------------------- Reporter: daviddarais | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Keywords: generalized | Operating System: Unknown/Multiple newtype deriving roles rankntypes | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Below is a small Haskell file showing the problem. It defines a simple `MonadTrans` typeclass, but using a type operator `~>`. When using the type operator, GHC complains that generalized newtype deriving gets stuck on a nominal role, but when the type operator is not used then GND works just fine. Perhaps this is just expected behavior with mixing RankNTypes and GND (and roles), but it's rather unfortunate. {{{#!hs {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeOperators #-} module GND where type m ~> n = forall a. m a -> n a class MonadTrans t where -- > this line works: -- lift :: (Monad m) => m a -> t m a -- > this line doesn't: lift :: (Monad m) => m ~> t m data StateT s m a = StateT { runStateT :: s -> m (a, s) } instance MonadTrans (StateT s) where lift xM = StateT $ \ s -> do { x <- xM ; return (x,s) } newtype OtherStateT s m a = OtherStateT { runOtherStateT :: StateT s m a } deriving (MonadTrans) }}} The error message is: {{{ GND.hs:23:13: error: • Couldn't match representation of type ‘m1 ~> StateT s m1’ with that of ‘m1 a1 -> OtherStateT s m1 a1’ arising from a use of ‘GHC.Prim.coerce’ • In the expression: GHC.Prim.coerce (lift :: (~>) m (StateT s m)) :: forall (m :: TYPE GHC.Types.PtrRepLifted -> TYPE GHC.Types.PtrRepLifted). Monad m => (~>) m (OtherStateT s m) In an equation for ‘lift’: lift = GHC.Prim.coerce (lift :: (~>) m (StateT s m)) :: forall (m :: TYPE GHC.Types.PtrRepLifted -> TYPE GHC.Types.PtrRepLifted). Monad m => (~>) m (OtherStateT s m) When typechecking the code for ‘lift’ in a derived instance for ‘MonadTrans (OtherStateT s)’: To see the code I am typechecking, use -ddump-deriv In the instance declaration for ‘MonadTrans (OtherStateT s)’ • Relevant bindings include lift :: m ~> OtherStateT s m (bound at GND.hs:23:13) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12616> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #1600: Optimisation: CPR the results of IO
by GHC 18 Oct '16

18 Oct '16

#1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8598 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: osa1 (added) Comment: I wonder why there's a consistent 2% increase in binary size; I was not expecting that. I have not looked at the code... when you are ready, seeing it all as one Phab diff (not lots) would be helpful. Omer may be thinking about nested CPR, and has an implementation on a branch somewhere. This is a particular instance of nested CPR, so it'd be good to sync up with him (cc'd). Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:55> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12723: Family instance modules are not fingerprinted in ABI
by GHC 18 Oct '16

18 Oct '16

#12723: Family instance modules are not fingerprinted in ABI -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Driver | 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 leads to the following delightful, five module bug: {{{ -- A.hs {-# LANGUAGE TypeFamilies #-} module A where type family F a type instance F Int = Bool -- B.hs module B where import A -- C.hs module C where import B -- D.hs module D where import C -- E.hs module E where import D import B }}} Build these modules. Then rename A to A2 (fixing B's import), and build them again. You'll get: {{{ ezyang@sabre:~/Dev/labs/T3871$ ghc --make E.hs [1 of 5] Compiling A2 ( A2.hs, A2.o ) [2 of 5] Compiling B ( B.hs, B.o ) [3 of 5] Compiling C ( C.hs, C.o ) [B changed] [5 of 5] Compiling E ( E.hs, E.o ) [B changed] attempting to use module ‘A’ (./A.hs) which is not loaded }}} The problem is clear: D was not recompiled, but it needs to be, because when the module gets renamed, we need to update its list of family instance modules to rename A to A2. When we don't do this, the subsequent family instance check chokes because it tries to load A. And why did D decide not to get recompiled? Because the ABI hash of B did not change. And that's WRONG. (Also, family instances are really awful, you really do have to rebuild everything when you change them. UGH.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12723> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #1600: Optimisation: CPR the results of IO
by GHC 18 Oct '16

18 Oct '16

#1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8598 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by akio): Replying to [comment:53 nomeata]: > How tedious was it to rebase? It took me a few days, but in the process I learned a lot about nested CPR and about the demand analyzer in general. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:54> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11214: Remove JavaScriptFFI from --supported-extensions list
by GHC 18 Oct '16

18 Oct '16

#11214: Remove JavaScriptFFI from --supported-extensions list -------------------------------------+------------------------------------- Reporter: luite | Owner: Type: bug | 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: -------------------------------------+------------------------------------- GHC supports the `JavaScriptFFI` extension syntactically, but it just rejects all `foreign import javascript` declarations in the typechecker. Similar to the change in #11102 I think the proper thing to do is to make GHC say that `JavaScriptFFI` is not supported. Cabal 1.24 can then use this information in dependency resolution. GHCJS would then just add this to the list by itself, since it has its own front end. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11214> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #1600: Optimisation: CPR the results of IO
by GHC 18 Oct '16

18 Oct '16

#1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8598 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Oh, that’s an old branch. I’m happy that a second pair of eyes looks at it. How tedious was it to rebase? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:53> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1600: Optimisation: CPR the results of IO
by GHC 18 Oct '16

18 Oct '16

#1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8598 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by akio): I've rebased nomeata's branch: https://github.com/takano- akio/ghc/compare/afdde48...f8eb150 Some nofib results: {{{ -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- mandel +1.9% -25.0% 0.047 0.047 0.0% gcd +2.0% -21.6% 0.030 0.031 0.0% k-nucleotide +1.7% -18.0% +3.4% +2.7% 0.0% wave4main +2.0% +12.3% 0.179 0.179 0.0% kahan +2.0% +7.8% +1.4% +1.3% 0.0% solid +2.0% -6.4% 0.081 0.081 0.0% sphere +2.0% +5.8% 0.040 0.040 0.0% hpg +2.0% +4.1% 0.102 0.102 0.0% symalg +1.9% +3.6% 0.007 0.007 0.0% gamteb +2.4% -4.8% 0.026 0.026 0.0% -------------------------------------------------------------------------------- Min +1.5% -25.0% -0.6% -0.4% -20.0% Max +2.8% +12.3% +12.7% +12.8% +12.0% Geometric Mean +2.0% -0.5% +5.0% +4.7% +0.2% }}} I'll look into the allocation regressions next. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:52> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12044: Remove sortWith in favor of sortOn
by GHC 18 Oct '16

18 Oct '16

#12044: Remove sortWith in favor of sortOn -------------------------------------+------------------------------------- Reporter: cblp | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: 7.10.3 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: 2659 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- There is Data.List.sortOn that does the same as GHC.Exts.sortWith, and even seems to be more effective. GHC.Exts.sortWith should be deprecated or removed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12044> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7