February 2017 - ghc-tickets

[GHC] #12923: MultiParamTypeClasses + ExtendedDefaultRules
by GHC 14 Feb '17

14 Feb '17

#12923: MultiParamTypeClasses + ExtendedDefaultRules -------------------------------------+------------------------------------- Reporter: amindfv | Owner: Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- -XExtendedDefaultRules allows us to avoid ambiguity for unannotated numeric literals: {{{#!hs {-# LANGUAGE ExtendedDefaultRules #-} data A = A deriving Show class ToA a where toA :: a -> A instance ToA Double where toA _ = A main = print (toA 5 :: A) }}} But if we have a multi-param typeclass, -XExtendedDefaultRules doesn't help us: {{{#!hs {-# LANGUAGE ExtendedDefaultRules #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FlexibleInstances #-} data A x = A deriving Show class ToA a x where toA :: a -> A x instance ToA Double x where toA _ = A main = print (toA 5 :: A Bool) }}} It would be really nice for an EDSL I'm working on to be able to use extended defaults here! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12923> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #13278: test 'debug' is timing out on OS X
by GHC 14 Feb '17

14 Feb '17

#13278: test 'debug' is timing out on OS X ----------------------------------------+--------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- All the builds I've seen are failing due to a timeout of the `debug` test, apparently while running the `./debug` executable. Strange since it looks like it ought to finish very quickly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13278> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #1600: Optimisation: CPR the results of IO
by GHC 14 Feb '17

14 Feb '17

#1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) 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 simonpj): Good looking numbers esp for mandel, gcd. Can you dig in to see what is really happening there? How does the inner loop look? For code size, it's worth investigating to get insight. Look at the "module sizes" in the nofib-analyse log, and take a look at modules that got significantly bigger. Is that code-size increase because of an actual optimisation or is it just accidental? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:63> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] Trac email verification for user: AaronNGray
by GHC 14 Feb '17

14 Feb '17

Please visit the following URL to confirm your email address. Verification URL: <http://ghc.haskell.org/trac/ghc/verify_email?verify=1&token=bRId-8Lg> Username: AaronNGray Verification Token: bRId-8Lg -- GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13215: Panic: push_bang_into_newtype_arg
by GHC 13 Feb '17

13 Feb '17

#13215: Panic: push_bang_into_newtype_arg -------------------------------------+------------------------------------- Reporter: nad | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- Just for fun I tried to compile Agda using `-XStrict`. Result: {{{ [...] [235 of 324] Compiling Agda.Syntax.Translation.InternalToAbstract [...] ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for i386-unknown-linux): push_bang_into_newtype_arg {} }}} To reproduce (using GHC 8.0.2): {{{ git clone https://github.com/agda/agda.git cd agda git checkout f8a24fe9ed50e4287bc7308e2b3da4615db87aa8 cabal install --ghc-options=-XStrict --constraint=EdisonCore==1.3.1.1 --constraint=EdisonAPI==1.3.1 --constraint=base==4.9.1.0 --constraint=ghc- prim==0.5.0.0 --constraint=rts==1.0 --constraint=integer-gmp==1.0.0.1 --constraint=mtl==2.2.1 --constraint=transformers==0.5.2.0 --constraint=QuickCheck==2.9.2 --constraint=containers==0.5.7.1 --constraint=array==0.5.1.1 --constraint=deepseq==1.4.2.0 --constraint=random==1.1 --constraint=time==1.6.0.1 --constraint=template- haskell==2.11.1.0 --constraint=ghc-boot-th==8.0.2 --constraint=pretty==1.1.3.3 --constraint=tf-random==0.5 --constraint=primitive==0.6.1.0 --constraint=binary==0.8.3.0 --constraint=bytestring==0.10.8.1 --constraint=boxes==0.1.4 --constraint=split==0.2.3.1 --constraint=data-hash==0.2.0.1 --constraint=directory==1.3.0.0 --constraint=filepath==1.4.1.1 --constraint=unix==2.7.2.1 --constraint=edit-distance==0.2.2.1 --constraint=equivalence==0.3.1 --constraint=STMonadTrans==0.3.4 --constraint=transformers-compat==0.5.1.4 --constraint=geniplate- mirror==0.7.4 --constraint=gitrev==1.2.0 --constraint=process==1.4.3.0 --constraint=hashable==1.2.5.0 --constraint=text==1.2.2.1 --constraint=hashtables==1.2.1.0 --constraint=vector==0.11.0.0 --constraint=haskeline==0.7.3.0 --constraint=terminfo==0.4.0.2 --constraint=ieee754==0.7.9 --constraint=monadplus==1.4.2 --constraint =murmur-hash==0.1.0.9 --constraint=parallel==3.2.1.0 --constraint=regex- tdfa==1.2.2 --constraint=parsec==3.1.11 --constraint=regex-base==0.93.2 --constraint=strict==0.3.2 --constraint=unordered-containers==0.2.7.2 --constraint=xhtml==3000.2.1 --constraint=zlib==0.6.1.2 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13215> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #9562: Type families + hs-boot files = unsafeCoerce
by GHC 13 Feb '17

13 Feb '17

#9562: Type families + hs-boot files = unsafeCoerce -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: GHC Blocked By: | accepts invalid program Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Consider the following bundle of modules: A.hs: {{{#!hs {-# LANGUAGE TypeFamilies #-} module A where type family F a b }}} B.hs-boot: {{{#!hs module B where import A oops :: F a b -> a -> b }}} B.hs: {{{#!hs {-# LANGUAGE TypeFamilies #-} module B where import A import C type instance F a b = b oops :: F a b -> a -> b oops = const }}} C.hs: {{{#!hs module C (oops) where import {-# SOURCE #-} B }}} D.hs: {{{#!hs {-# LANGUAGE TypeFamilies #-} module D where import A import C type instance F a b = a unsafeCoerce :: a -> b unsafeCoerce x = oops x x }}} Main.hs: {{{#!hs module Main where import D ( unsafeCoerce ) main = print $ (unsafeCoerce True :: Int) }}} When loading these into GHCi, we quite reasonably get a type family instance overlap error. But, separate compilation leads to disaster: {{{ rae:01:49:47 ~/temp/bug> ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.3 rae:01:49:49 ~/temp/bug> ghc -c A.hs rae:01:49:53 ~/temp/bug> ghc -c B.hs-boot rae:01:49:58 ~/temp/bug> ghc -c C.hs rae:01:50:09 ~/temp/bug> ghc -c B.hs rae:01:50:13 ~/temp/bug> ghc -c D.hs rae:01:50:17 ~/temp/bug> ghc Main.hs -o Unsafe [6 of 6] Compiling Main ( Main.hs, Main.o ) Linking Unsafe ... rae:01:50:23 ~/temp/bug> ./Unsafe 2882303761534249061 }}} Yikes! Proposed (terrible) solution: hs-boot files '''must''' list all type instance declarations in the corresponding modules. It may also be a good idea to require all normal instance declarations in the hs-boot file as well, because this same trick can be used to introduce incoherence (I think -- haven't tested). This bug persists even if `Main` declares that it is `Safe`. I've attached a tarball of the files for ease of testing. (Credit to Edward Yang and Geoff Mainland, whose discussion provoked the line of inquiry that led to this discovery.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9562> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

Re: [GHC] #1600: Optimisation: CPR the results of IO
by GHC 13 Feb '17

13 Feb '17

#1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) 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:61 simonmar]: > make won't necessarily rebuild your libraries, due to GHC's recompilation avoidance. Oh I see... Thank you for the tip! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:62> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1600: Optimisation: CPR the results of IO
by GHC 13 Feb '17

13 Feb '17

#1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) 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 simonmar): > (I had stage=2 in build.mk. I removed it and typed make. Is it not sufficient to cause a full build?). make won't necessarily rebuild your libraries, due to GHC's recompilation avoidance. It knows about changes in the source code and the flags, but it doesn't know about changes in GHC itself. So when I'm making measurements like this, I always delete the library object files manually: ``` find libraries/*/dist-install | grep 'o$' | xargs rm ``` -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:61> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1600: Optimisation: CPR the results of IO
by GHC 13 Feb '17

13 Feb '17

#1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) 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): It seems like the above results were bogus because it used libraries compiled with the wrong compiler (I had `stage=2` in build.mk. I removed it and typed `make`. Is it not sufficient to cause a full build?). After a clean build, the allocation numbers look very good: {{{ -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- compress2 +2.0% -0.9% 0.170 0.170 -3.7% fft2 +1.0% -0.2% 0.078 0.078 0.0% fluid +2.1% -0.4% 0.006 0.006 0.0% gamteb +0.4% -4.5% 0.032 0.032 0.0% gcd +0.7% -21.4% 0.046 0.046 0.0% infer -0.1% -1.2% 0.054 0.054 0.0% integer +1.0% -1.5% -15.0% -15.0% 0.0% mandel +1.0% -24.4% 0.051 0.051 0.0% rfib +1.0% -0.3% 0.012 0.012 0.0% solid +0.4% -6.6% 0.130 0.131 0.0% -------------------------------------------------------------------------------- Min -0.2% -24.4% -21.1% -21.3% -3.7% Max +2.1% +0.1% +39.3% +39.3% +17.3% Geometric Mean +0.2% -0.7% -4.9% -4.9% +0.1% }}} Should I worry about the increase in the code size? If not I'll clean up the branch and submit a Diff. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:60> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13270: Make Core Lint faster
by GHC 12 Feb '17

12 Feb '17

#13270: Make Core Lint faster -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Not using `-dcore-lint` makes the validate build 25% faster overall. See https://perf.haskell.org/ghc/#compare/639e702b6129f501c539b158b982ed8489e3d…. We should at least profile it and check for anything egregiously inefficient. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13270> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1