April 2017 - ghc-tickets

[GHC] #10064: Add support for "foo"## literals to MagicHash
by GHC 24 Jul '17

24 Jul '17

#10064: Add support for "foo"## literals to MagicHash -------------------------------------+------------------------------------- Reporter: chadaustin | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.4 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I'm working on a high-performance library for building up buffers of data. Appending ByteStrings works pretty well, but, for bytestring literals, it's faster to avoid the CAF (and it's associated tag check + indirect jump) entirely and append a zero-terminate MagicHash string literal via Addr#. Then I discovered that it's 30% faster if you can avoid the strlen with an explicit length. See this benchmark: https://github.com/chadaustin /buffer- builder/blob/ac662962d6d3c21f206ab8e8121323b9f18677fa/bench/Bench.hs#L42 That API is not very pleasant, of course. :) Thus, here is a feature request: It would be great if "foo"## produced (# Int#, Addr# #), where the Int# is the length of the buffer in bytes. The compiler could enforce that the literal only contains 8-bit values. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10064> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9453: The example for GHC Generics is kinda broken
by GHC 24 Jul '17

24 Jul '17

#9453: The example for GHC Generics is kinda broken -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | 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: -------------------------------------+------------------------------------- From http://www.reddit.com/r/haskell/comments/2douzn/problem_with_popular_ghcgen…: The popular GHC.Generics serialization example at http://www.haskell.org/ghc/docs/latest/html/users_guide/generic- programming.html#idp25226064 illustrates how to serialize a sum datatype (a :+: b), with a 0 bit representing a and a 1 bit representing b. However, consider a :+: b :+: c. If the compiler treats this as (a :+: b) :+: c, then a is 00, b is 01, c is 1. If it's a :+: (b :+: c), then a is 0, b is 10, c is 11. The compiler's decision, even though (as I understand it) consistent for any given compile, could differ later. The manual, at http://hackage.haskell.org/package/generic- deriving-1.6.3/docs/Generics-Deriving-Base.html#g:9 states not to depend on the ordering, which the example does. I think this is a valid concern, and the manual should be at least updated to discuss this problem. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9453> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #13304: GHC 8.0.* is slow when run on Windows 10 Ubuntu subsystem
by GHC 24 Jul '17

24 Jul '17

#13304: GHC 8.0.* is slow when run on Windows 10 Ubuntu subsystem -------------------------------------+------------------------------------- Reporter: sukhmel | 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: -------------------------------------+------------------------------------- I have tried both 8.0.1 and 8.0.2 versions of GHC. 7.10.3 runs just fine. Installation process is also much faster for 7.10.3, later versions have taken around 4 hours to be installed. Programs compiled with slow GHC are also slow. Sample program: {{{#!haskell main = putStrLn "Hello, world!" }}} GHC is installed with Stack. Windows version is 1607 build 15031.0 I believe this could be a bug in implementation of Ubuntu subsystem, but I'm not quite sure what part of it is failing. {{{ $ time stack ghc -- -e 'putStrLn ""' real 2m28.240s user 0m0.375s sys 3m30.078s $ time stack ghc -- --version The Glorious Glasgow Haskell Compilation System, version 8.0.2 real 1m45.533s user 0m0.125s sys 2m46.516s time stack ghc --compiler ghc-8.0.1 -- --version The Glorious Glasgow Haskell Compilation System, version 8.0.1 real 2m54.764s user 0m0.234s sys 3m58.422s }}} {{{ $ time ghc -e 'putStrLn ""' real 0m0.872s user 0m0.109s sys 0m0.125s $ time ghc --version The Glorious Glasgow Haskell Compilation System, version 7.6.3 real 0m0.072s user 0m0.000s sys 0m0.031s time stack ghc --compiler ghc-7.10.3 -- -e 'putStrLn ""' real 0m0.876s user 0m0.234s sys 0m0.688s time stack ghc --compiler ghc-7.10.3 -- --version The Glorious Glasgow Haskell Compilation System, version 7.10.3 real 0m0.832s user 0m0.109s sys 0m0.813s }}} {{{ $ echo 'main = putStrLn "Hello, world!"' > test.hs $ time stack ghc --compiler ghc-8.0.2 -- test [1 of 1] Compiling Main ( test.hs, test.o ) Linking test ... real 3m56.582s user 0m0.609s sys 5m8.125s $ time ./test Hello, world! real 0m27.540s user 0m0.000s sys 0m27.297s }}} {{{ $ echo 'main = putStrLn "Hello, world!"' > test.hs $ time stack ghc --compiler ghc-7.10.3 -- test [1 of 1] Compiling Main ( test.hs, test.o ) Linking test ... real 0m2.222s user 0m0.406s sys 0m1.406s $ time ./test Hello, world! real 0m0.030s user 0m0.000s sys 0m0.031s }}} Part of Stack output with timings: {{{ $ stack ghc --verbose -- -e 'putStrLn "Hello, world!"' Version 1.3.2, Git revision 3f675146590da4f3edf768b89355f798229da2a5 (4395 commits) x86_64 hpack-0.15.0 ... 2017-02-19 21:13:05.756085: [debug] No project config file found, using defaults. 2017-02-19 21:13:05.759402: [debug] Run from outside a project, using implicit global project config 2017-02-19 21:13:05.761724: [debug] Using resolver: lts-8.0 from implicit global project's config file: /home/sukhmel/.stack/global- project/stack.yaml ... 2017-02-19 21:13:05.788855: [debug] Run process: /sbin/ldconfig -p 2017-02-19 21:13:05.816489: [debug] Process finished in 26ms: /sbin/ldconfig -p 2017-02-19 21:13:05.820648: [debug] Run process: /usr/bin/gcc -v 2017-02-19 21:13:05.844975: [debug] Process finished in 23ms: /usr/bin/gcc -v ... 2017-02-19 21:13:05.854997: [debug] Using standard GHC build 2017-02-19 21:13:05.856774: [debug] Getting global package database location ... 2017-02-19 21:13:05.867711: [debug] Run process: /home/sukhmel/.stack/programs/x86_64-linux/ghc-8.0.2/bin/ghc-pkg --no- user-package-db list --global 2017-02-19 21:13:05.888957: [debug] Run process: /home/sukhmel/.stack/programs/x86_64-linux/ghc-8.0.2/bin/ghc --numeric- version 2017-02-19 21:13:05.919968: [debug] Run process: /home/sukhmel/.stack/programs/x86_64-linux/ghc-8.0.2/bin/ghc-pkg --no- user-package-db field --simple-output Cabal version 2017-02-19 21:13:38.605653: [debug] Process finished in 32736ms: /home/sukhmel/.stack/programs/x86_64-linux/ghc-8.0.2/bin/ghc-pkg --no- user-package-db list --global 2017-02-19 21:14:11.930034: [debug] Process finished in 32792ms: /home/sukhmel/.stack/programs/x86_64-linux/ghc-8.0.2/bin/ghc-pkg --no- user-package-db field --simple-output Cabal version 2017-02-19 21:14:11.931071: [debug] Process finished in 32831ms: /home/sukhmel/.stack/programs/x86_64-linux/ghc-8.0.2/bin/ghc --numeric- version ... 2017-02-19 21:14:11.939817: [debug] Run process: /home/sukhmel/.stack/programs/x86_64-linux/ghc-8.0.2/bin/ghc -e "putStrLn \"Hello, world!\"" }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13304> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13375: ghc-pkg "cache is out of date" message breaks testsuite
by GHC 23 Jul '17

23 Jul '17

#13375: ghc-pkg "cache is out of date" message breaks testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: ghc-pkg | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Since the merge of the package database locking business, `ghc-pkg dump` spews a message on `stderr` on Windows, {{{ $ "C:/msys64/home/ben/ghc/inplace/bin/ghc-pkg.exe" dump WARNING: cache is out of date: C:\msys64\home\ben\ghc\inplace\lib\package.conf.d\package.cache ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix. name: xhtml version: 3000.2.1 id: xhtml-3000.2.1 ... }}} When the testsuite driver sees this it (namely `testutil.getStdout`) assumes something has gone terribly wrong and aborts. From a cursory look it's not clear how we got into this situation; the file indeed exists and was certainly touched during the build. However, running `ghc-pkg recache` indeed seems to fix the issue. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13375> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #13354: Package database locking patch broke ghc-pkg with non-existent database
by GHC 23 Jul '17

23 Jul '17

#13354: Package database locking patch broke ghc-pkg with non-existent database -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Package | Version: 8.0.1 system | 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 seems that Phab:D3090 (#13194) broke `ghc-pkg`'s behavior in the face of non-existent package databases. Namely, `cabal install` fails during registration with, {{{ Creating package registration file: /tmp/pkgConf- compact-0.1.0.1-13684/pkgConf ("/opt/exp/ghc/roots/master/bin/ghc-pkg",["update","-","--global","-- user","-v2"]) /opt/exp/ghc/roots/master/bin/ghc-pkg returned ExitFailure 1 with error message: ghc-pkg: Couldn't open database /home/ben/.ghc/x86_64-linux-8.1.20170227/package.conf.d for modification: /home/ben/.ghc/x86_64-linux-8.1.20170227/package.conf.d.lock: openBinaryFile: does not exist (No such file or directory) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13354> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #11375: Type aliases twice as slow to compile as closed type families.
by GHC 22 Jul '17

22 Jul '17

#11375: Type aliases twice as slow to compile as closed type families. -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: | Operating System: MacOS X Architecture: aarch64 | Type of failure: Compile-time | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hello guys! This bug is awkard at last to me. So I notiiced today, that using type aliases in my code takes twice as long to copile than using closed type families with just single member. So to be most precise - when I replace the following line: {{{ type XQ1 m a = Targets (Match m a) }}} with {{{ type family XQ1 m a where XQ1 m a = Targets (Match m a) }}} the compilation time drops from 15s to 7s (this type alias is heavily used across the application). I think it could be somehow related to the famous #8095 bug, but I can of course be wrong here. Unfortunetally the codebase is pretty big and its not so easy to make a minimal example, but I'll try to work on it during the upcoming weekend (please notify me if that would not be necessary). And some statistics from `-dshow-passes`: When using type alias: {{{ *** Parser: *** Renamer/typechecker: *** Desugar: Result size of Desugar (after optimization) = {terms: 10,303, types: 66,949, coercions: 16,383,834} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 10,722, types: 75,391, coercions: 16,507,338} Result size of Simplifier iteration=2 = {terms: 10,550, types: 74,437, coercions: 16,504,770} Result size of Simplifier iteration=3 = {terms: 10,543, types: 74,347, coercions: 16,504,734} Result size of Simplifier = {terms: 10,543, types: 74,347, coercions: 16,504,630} *** Tidy Core: Result size of Tidy Core = {terms: 10,846, types: 75,522, coercions: 16,504,729} *** CorePrep: Result size of CorePrep = {terms: 14,823, types: 96,430, coercions: 16,504,729} *** ByteCodeGen: Upsweep completely successful. *** Deleting temp files: Warning: deleting non-existent /var/folders/y9/km24zv3d4yl711mwv85vwljc0000gp/T/ghc64965_0/ghc_95.c Warning: deleting non-existent /var/folders/y9/km24zv3d4yl711mwv85vwljc0000gp/T/ghc64965_0/ghc_94.o Ok, modules loaded: Prologue, Type.Bool, Type.Container, Type.List, Type.Set, Data.Cata, Type.Promotion, Data.Bits.Mask, Control.Monad.State.Dependent, Control.Monad.Poly, Control.Applicative.Poly, Type.Regex, Type.Either, Data.Reprx, Data.Impossible, Type.Cache.TH, Main, Control.Lens.Utils, Control.Lens.Wrapped.Utils, Data.Text.CodeBuilder, Data.Text.CodeBuilder.Tok, Data.Text.CodeBuilder.Builder, Data.Text.CodeBuilder.Doc, Data.Binary.Instances.Missing, Data.Default.Instances.Missing, Data.String.Class, Data.Text.Class, Data.Convert, Data.Layer, Data.Container.Class, Data.Container.List, Data.Functor.Utils, Type.Operators, Type.Show, Type.Wrapped, Data.Container.Opts, Data.Container.Poly, Data.Convert.Base, Data.Convert.Instances, Data.Convert.Instances.Map, Data.Convert.Instances.Num, Data.Convert.Instances.Text, Data.Convert.Instances.TH, Data.Convert.Bound, Data.Bits.Base. *** Parser: *** Desugar: *** Simplify: *** CorePrep: *** ByteCodeGen: ... }}} and with type families: {{{ *** Parser: *** Renamer/typechecker: *** Desugar: Result size of Desugar (after optimization) = {terms: 310, types: 867, coercions: 78} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 301, types: 878, coercions: 296} Result size of Simplifier = {terms: 301, types: 878, coercions: 293} *** Tidy Core: Result size of Tidy Core = {terms: 337, types: 1,002, coercions: 293} *** CorePrep: Result size of CorePrep = {terms: 475, types: 1,305, coercions: 293} *** ByteCodeGen: *** Deleting temp files: Warning: deleting non-existent /var/folders/y9/km24zv3d4yl711mwv85vwljc0000gp/T/ghc64863_0/ghc_93.c Warning: deleting non-existent /var/folders/y9/km24zv3d4yl711mwv85vwljc0000gp/T/ghc64863_0/ghc_92.o compile: input file /var/folders/y9/km24zv3d4yl711mwv85vwljc0000gp/T/ghc64863_0/ghc_1.hscpp *** Checking old interface for Main: [45 of 45] Compiling Main ( /Users/wdanilo/dev/hs/public/variants/Main.hs, interpreted ) *** Parser: *** Renamer/typechecker: *** Desugar: Result size of Desugar (after optimization) = {terms: 10,303, types: 67,609, coercions: 162,249} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 10,722, types: 75,721, coercions: 323,027} Result size of Simplifier iteration=2 = {terms: 10,550, types: 74,767, coercions: 320,473} Result size of Simplifier iteration=3 = {terms: 10,543, types: 74,677, coercions: 320,437} Result size of Simplifier = {terms: 10,543, types: 74,677, coercions: 320,333} *** Tidy Core: Result size of Tidy Core = {terms: 10,846, types: 75,852, coercions: 320,432} *** CorePrep: Result size of CorePrep = {terms: 14,823, types: 96,760, coercions: 320,432} *** ByteCodeGen: Upsweep completely successful. *** Deleting temp files: Warning: deleting non-existent /var/folders/y9/km24zv3d4yl711mwv85vwljc0000gp/T/ghc64863_0/ghc_95.c Warning: deleting non-existent /var/folders/y9/km24zv3d4yl711mwv85vwljc0000gp/T/ghc64863_0/ghc_94.o Ok, modules loaded: Prologue, Type.Bool, Type.Container, Type.List, Type.Set, Data.Cata, Type.Promotion, Data.Bits.Mask, Control.Monad.State.Dependent, Control.Monad.Poly, Control.Applicative.Poly, Type.Regex, Type.Either, Data.Reprx, Data.Impossible, Type.Cache.TH, Main, Control.Lens.Utils, Control.Lens.Wrapped.Utils, Data.Text.CodeBuilder, Data.Text.CodeBuilder.Tok, Data.Text.CodeBuilder.Builder, Data.Text.CodeBuilder.Doc, Data.Binary.Instances.Missing, Data.Default.Instances.Missing, Data.String.Class, Data.Text.Class, Data.Convert, Data.Layer, Data.Container.Class, Data.Container.List, Data.Functor.Utils, Type.Operators, Type.Show, Type.Wrapped, Data.Container.Opts, Data.Container.Poly, Data.Convert.Base, Data.Convert.Instances, Data.Convert.Instances.Map, Data.Convert.Instances.Num, Data.Convert.Instances.Text, Data.Convert.Instances.TH, Data.Convert.Bound, Data.Bits.Base. *** Parser: *** Desugar: *** Simplify: *** CorePrep: *** ByteCodeGen: ... }}} As we can see the type aliases produce much more coertions: 16,383,834 vs 78 using type families. This is really interesting thing and it seems related to the linked bug above. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11375> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #13434: hs_try_putmvar003 is timing out / segfaulting
by GHC 19 Jul '17

19 Jul '17

#13434: hs_try_putmvar003 is timing out / segfaulting -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.1 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is basically reproduceable every time I validate. During validation, the program times out, but when I run it by hand, it segfaults. Running in debug sanity mode, I get: {{{ hstry: internal error: MVAR_CLEAN on mutable list (GHC version 8.3.20170316 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Simon Marlow, I'm happy to investigate more if you can't repro. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13434> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #11095: -O0 -g slows GHC down on list literals (compared to -O0 without -g)
by GHC 19 Jul '17

19 Jul '17

#11095: -O0 -g slows GHC down on list literals (compared to -O0 without -g) -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- Tried to buld syb-0.6 testsuite with '-O0 -g' flags today and noticed compiler hung for a couple of hours. Distilled example from syb-0.6 testsuite (exact example attached): {{{#!hs {-# LANGUAGE NoImplicitPrelude #-} {-# OPTIONS_GHC -O0 #-} module Bug (bug) where {-# NOINLINE f #-} f :: a -> a f v = v bug :: [()] bug = f v v :: [()] v = [(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),() ,(),(),(),(),() ... --- a lot of these ] }}} {{{ $ time ghc -c -fforce-recomp -O0 Bug.hs real 0m0.333s user 0m0.288s sys 0m0.042s $ time ghc -c -fforce-recomp -O0 -g Bug.hs real 0m40.241s user 0m40.021s sys 0m0.070s }}} For some reason '''-g''' manages slow things down at a large factor. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11095> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #8903: Add dead store elimination
by GHC 18 Jul '17

18 Jul '17

#8903: Add dead store elimination ------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- We could use some dead store elimination in the code generator. Here's some Cmm that has redundant stores to the same locations: {{{ // thawArray#: I64[Hp - 168] = I64[PicBaseReg + stg_MUT_ARR_PTRS_DIRTY_info@GOTPCREL]; I64[Hp - 160] = 16; I64[Hp - 152] = 17; _c2nT::I64 = Hp - 168; call MO_Memcpy(_c2nT::I64 + 24, _s2cx::P64 + 24, 128, 8); // writeArray#: P64[(_c2nT::I64 + 24) + (_s2cy::I64 << 3)] = _s2cE::P64; I64[_c2nT::I64] = I64[PicBaseReg + stg_MUT_ARR_PTRS_DIRTY_info@GOTPCREL]; I8[(_c2nT::I64 + 24) + ((I64[_c2nT::I64 + 8] << 3) + (_s2cy::I64 >> 7))] = 1 :: W8; // unsafeFreeze# I64[_c2nT::I64] = I64[PicBaseReg + stg_MUT_ARR_PTRS_FROZEN0_info@GOTPCREL]; }}} There are three stores to the same location (`I64[_c2nT::I64]`). (There's also one much less obvious double store to another location, which will probably be much harder to address: the store to `P64[(_c2nT::I64 + 24) + (_s2cy::I64 << 3)]` overwrites a word previous written by the `MO_Memcpy`. Getting to that one will be hard as the memcoy callish !MachOp only gets expanded in the backend.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8903> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9630: compile-time performance regression (probably due to Generics)
by GHC 18 Jul '17

18 Jul '17

#9630: compile-time performance regression (probably due to Generics) -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Compile- Blocked By: | time performance bug Related Tickets: #9583 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This is a continuation of #9583 Compiling latest Cabal from Git's `Language.Haskell.Extension` module shows a significant performance regression with respect to GHC 7.8.3: {{{ $ uname -a Linux duo 3.17.0-031700rc6-generic #201409211935 SMP Sun Sep 21 23:37:11 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux $ git describe cabal-install_merged-1912-g7161e4c ######################################################################################## $ /opt/ghc/7.8.3/bin/ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.3 $ /opt/ghc/7.8.3/bin/ghc -Rghc-timing -O -c Language/Haskell/Extension.hs <<ghc: 5228751760 bytes, 543 GCs, 34135677/114940864 avg/max bytes residency (14 samples), 273M in use, 0.00 INIT (0.03 elapsed), 4.96 MUT (5.28 elapsed), 3.26 GC (3.47 elapsed) :ghc>> ######################################################################################## $ /opt/ghc/head/bin/ghc --version The Glorious Glasgow Haskell Compilation System, version 7.9.20140923 $ /opt/ghc/head/bin/ghc -Rghc-timing -O -c Language/Haskell/Extension.hs <<ghc: 125917854120 bytes, 3181 GCs, 349136895/833496072 avg/max bytes residency (30 samples), 2096M in use, 0.001 INIT (0.001 elapsed), 133.003 MUT (142.730 elapsed), 73.241 GC (78.234 elapsed) :ghc>> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9630> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 66