December 2015 - ghc-tickets

[GHC] #10421: exponential blowup in inlining (without INLINE pragmas)
by GHC 26 May '17

26 May '17

#10421: exponential blowup in inlining (without INLINE pragmas) -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The test case for #10397 also demonstrates an exponential blowup by the inliner, without any INLINE pragmas. I added another four fields to the `Register` type, and I get these final Core program sizes. (The variation in sizes between versions is not really important, the point is just that they are very large for all versions.) {{{ ghc-7.6.3: *** CorePrep: Result size of CorePrep = {terms: 1,702,684, types: 1,950,647, coercions: 103} ghc-7.8.4: *** CorePrep: Result size of CorePrep = {terms: 1,964,183, types: 1,950,620, coercions: 97} ghc-7.10.1: *** CorePrep: Result size of CorePrep = {terms: 1,964,212, types: 1,950,764, coercions: 97} ghc-7.11: *** CorePrep: Result size of CorePrep = {terms: 1,964,212, types: 1,950,764, coercions: 97} }}} Ideally GHC should not produce enormous Core programs on its own like this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10421> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10735: Smooth out the differences between `compiler/utils/Pretty.hs` and `libraries/pretty`
by GHC 23 May '17

23 May '17

#10735: Smooth out the differences between `compiler/utils/Pretty.hs` and `libraries/pretty` -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #1062, #1176, Differential Revisions: | #7666 -------------------------------------+------------------------------------- GHC has an internal copy of `pretty` in `compiler/utils/Pretty.hs`. Todo: * refactor GHC's copy to make it as similar as possible to `pretty`, without making any real code changes. * apply the bug fixes that `pretty` received to GHC's copy, making sure not to pick up any possible new bugs in the process. According to (1): "There is one situation where the laws for pretty are ambiguous and leave room for choice. GHC decided one way and pretty the other." * Find which law that is, and document the differences. This hopefully allows us to close the following tickets for free: #1062, #1176 and #7666, maybe more. Ideally we could remove GHC's copy altogether, but we're not there yet. GHC's copy uses FastString, which is supposedly needed for performance, whereas pretty uses `String`. (1) https://github.com/haskell/pretty/issues/1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10735> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 26

[GHC] #9287: changed dependency generation
by GHC 23 May '17

23 May '17

#9287: changed dependency generation ------------------------------------+-------------------------------------- Reporter: maeder | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Documentation bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+-------------------------------------- "ghc -M" for ghc-7.8.x changed in that an error occurs: {{{ You must specify at least one -dep-suffix }}} By chance (#8746) I found that {{{ ghc -M -dep-suffix "" B.hs }}} works, but only for the new ghc-7.8.x. For module B importing module A the following dependencies are generated: {{{ # DO NOT DELETE: Beginning of Haskell dependencies A.o : A.hs B.o : B.hs B.o : A.hi # DO NOT DELETE: End of Haskell dependencies }}} The same command used with ghc-7.6.x produces wrong dependencies: {{{ # DO NOT DELETE: Beginning of Haskell dependencies A.o A._o : A.hs B.o B._o : B.hs B.o : A.hi B._o : A._hi # DO NOT DELETE: End of Haskell dependencies }}} Obviously, only for dynamic linking a dep-suffix should be needed. However for ghc-7.6. this must be "dyn" and for ghc-7.8.x this must "dyn_" plus the empty suffix! {{{ ghc-7.6.3 -M -dep-suffix dyn B.hs ghc-7.8.2 -M -dep-suffix dyn_ -dep-suffix "" B.hs }}} Both calls produce: {{{ # DO NOT DELETE: Beginning of Haskell dependencies A.o A.dyn_o : A.hs B.o B.dyn_o : B.hs B.o : A.hi B.dyn_o : A.dyn_hi # DO NOT DELETE: End of Haskell dependencies }}} The changed behavior is not documented in http://www.haskell.org/ghc/docs/7.8.2/html/users_guide/separate- compilation.html#makefile-dependencies The (accidental?) change should also be documented in the release notes! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9287> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9445: GHC Panic: Tick Exhausted with high factor
by GHC 22 May '17

22 May '17

#9445: GHC Panic: Tick Exhausted with high factor -------------------------------------+------------------------------------- Reporter: adinapoli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: panic | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: 5539 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Hello guys, this is an old bug which has been reported so many times that I'm not sure this will be noise or something useful. In a nutshell I have been hit by this bug installing the library "SFML", which relies heavily on FFI. The only interesting thing of this report is that it was necessary an very high simpl-factor to make the installation go through! Pre-bump: {{{ Resolving dependencies... In order, the following will be installed: SFML-0.2.0.0 (reinstall) Warning: Note that reinstalls are always dangerous. Continuing anyway... Configuring SFML-0.2.0.0... Building SFML-0.2.0.0... Preprocessing library SFML-0.2.0.0... [...] [34 of 71] Compiling SFML.Graphics.Transform ( dist/build/SFML/Graphics/Transform.hs, dist/build/SFML/Graphics/Transform.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-apple-darwin): Simplifier ticks exhausted When trying UnfoldingDone $j_sZQW{v} [lid] To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 2655928 }}} And this was the magic line: {{{ cabal install SFML --ghc-option=-fsimpl-tick-factor=1630 }}} HTH, it turns out it's quite an annoying one! And yes, "1630" was the smaller factor which made the installation possible. Alfredo -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9445> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #9700: Support C structures in Haskell FFI
by GHC 22 May '17

22 May '17

#9700: Support C structures in Haskell FFI -------------------------------------+------------------------------------- Reporter: Yuras | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: Phab:D252 -------------------------------------+------------------------------------- This ticket is for tracking progress on [[CStructures]] language extension proposal. The idea is to support C structures in Haskell FFI. See wiki for details. If it will be accepted, I'm going to implement it in few steps. The first one is to support structures as return value. Platform specific part for that is already implemented, see Phab:D252 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9700> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8048: Register spilling produces ineffecient/highly contending code
by GHC 21 May '17

21 May '17

#8048: Register spilling produces ineffecient/highly contending code -------------------------------------+------------------------------------- Reporter: schyler | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 7.6.3 Keywords: register | Operating System: Unknown/Multiple allocator spill | Type of failure: Runtime Architecture: Unknown/Multiple | performance bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- The native codegen and llvm both produce ineffecient code for functions using structures with many strict fields or unboxed values. Consider the following program: {{{ {-# LANGUAGE BangPatterns #-} module Spill where import GHC.Exts data S = S !Int !Int !Int !Int !Int !Int !Int !Int !Int spill :: S -> S -> S -> S spill (S !a !b !c !d !e !f !g !h !i) (S !j !k !l !m !n !o !p !q !r) (S !s !t !u !v !w !x !y !z _) = S (a + j + s) (b + c) (k + r) (a + b + c + d + e + f + g + h + i) (j + k + l + m + n + o + p + q + r) (s + t + u + v + w + x + y + z) (a + b + c) (j + k + l) (s + t + u) }}} Parts of the code produced for this (which is identical regardless of -funbox-strict-fields) looks like: {{{ _cnc: addq $80,%r12 cmpq 144(%r13),%r12 ja _cni movq $Spill.S_con_info,-72(%r12) movq 32(%rbp),%rax movq %rax,-64(%r12) movq 24(%rbp),%rax movq %rax,-56(%r12) movq 16(%rbp),%rax movq %rax,-48(%r12) movq 8(%rbp),%rax movq %rax,-40(%r12) movq 40(%rbp),%rax movq %rax,-32(%r12) movq 48(%rbp),%rax movq %rax,-24(%r12) movq 56(%rbp),%rax movq %rax,-16(%r12) movq 64(%rbp),%rax movq %rax,-8(%r12) movq 7(%rbx),%rax movq %rax,0(%r12) leaq -71(%r12),%rbx addq $72,%rbp jmp *0(%rbp) }}} {{{ _csv: movq 63(%rbx),%rax movq %rax,-56(%rbp) movq 55(%rbx),%rax movq %rax,-48(%rbp) movq 47(%rbx),%rax movq %rax,-40(%rbp) movq 39(%rbx),%rax movq %rax,-32(%rbp) movq 31(%rbx),%rax movq %rax,-24(%rbp) movq 23(%rbx),%rax movq %rax,-16(%rbp) movq 71(%rbx),%rax movq %rax,-8(%rbp) movq 15(%rbx),%rax movq %rax,0(%rbp) }}} And likewise for LLVM: {{{ .LBB10_1: # %coZ movq 7(%rbx), %rcx movq $Spill_S_con_info, 8(%rax) movq 8(%rbp), %rdx movq %rdx, 16(%rax) movq 16(%rbp), %rdx movq %rdx, 24(%rax) movq 24(%rbp), %rdx movq %rdx, 32(%rax) movq 32(%rbp), %rdx movq %rdx, 40(%rax) movq 40(%rbp), %rdx movq %rdx, 48(%rax) movq 48(%rbp), %rdx movq %rdx, 56(%rax) movq 56(%rbp), %rdx movq %rdx, 64(%rax) movq 64(%rbp), %rdx movq %rdx, 72(%rax) movq %rcx, (%r12) movq 72(%rbp), %rax leaq 72(%rbp), %rbp leaq -71(%r12), %rbx jmpq *%rax # TAILCALL }}} Quoting from #ghc "the [register allocator] core algo is '96 vintage". Improvements are needed; * Take into consideration pipelining and handle spills less dramatically, attempting to reduce register contention * Sink memory reads in order to reduce register pressure -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8048> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #11325: Type of hole does not get refined after pattern matching on [GADT] constructors
by GHC 19 May '17

19 May '17

#11325: Type of hole does not get refined after pattern matching on [GADT] constructors -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (Type checker) | Keywords: GADTs | Operating System: Linux Architecture: x86 | Type of failure: Incorrect | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- From [https://www.youtube.com/watch?v=6snteFntvjM A Practical Introduction to Haskell GADTs] from LambdaConf 2015, example from attachment Hole.hs: {{{#!hs {-# LANGUAGE GADTs #-} data STy ty where SInt :: STy Int SBool :: STy Bool SMaybe :: STy a -> STy (Maybe a) zero :: STy ty -> ty zero ty = case ty of SInt -> 5 SBool -> False SMaybe a -> _ }}} When running with "GHCi, version 7.11.20151226": {{{ % ghci -ignore-dot-ghci /tmp/Hole.hs GHCi, version 7.11.20151226: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/Hole.hs, interpreted ) /tmp/Hole.hs:12:15: error: • Found hole: _ :: ty Where: ‘ty’ is a rigid type variable bound by the type signature for: zero :: forall ty. STy ty -> ty at /tmp/Hole.hs:8:9 • In the expression: _ In a case alternative: SMaybe a -> _ In the expression: case ty of { SInt -> 5 SBool -> False SMaybe a -> _ } • Relevant bindings include a :: STy a (bound at /tmp/Hole.hs:12:10) ty :: STy ty (bound at /tmp/Hole.hs:9:6) zero :: STy ty -> ty (bound at /tmp/Hole.hs:9:1) Failed, modules loaded: none. Prelude> }}} when older versions (GHCi version 7.10.2) refine the type of `_` to `Maybe a`: {{{ % ghci-7.10.2 -ignore-dot-ghci /tmp/Hole.hs GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/Hole.hs, interpreted ) /tmp/Hole.hs:12:15: Found hole ‘_’ with type: Maybe a Where: ‘a’ is a rigid type variable bound by a pattern with constructor SMaybe :: forall a. STy a -> STy (Maybe a), in a case alternative at /tmp/Hole.hs:12:3 Relevant bindings include a :: STy a (bound at /tmp/Hole.hs:12:10) ty :: STy ty (bound at /tmp/Hole.hs:9:6) zero :: STy ty -> ty (bound at /tmp/Hole.hs:9:1) In the expression: _ In a case alternative: SMaybe a -> _ In the expression: case ty of { SInt -> 5 SBool -> False SMaybe a -> _ } Failed, modules loaded: none. Prelude> }}} Regression? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11325> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #8721: Testsuite not reporting errors for DYN way on OS X
by GHC 18 May '17

18 May '17

#8721: Testsuite not reporting errors for DYN way on OS X ------------------------------------+---------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.6.3 Keywords: dynamic linking | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+---------------------------- Using GHC 7.6.3, on OS X 10.8.5, for the program: `main = putStrLn "Hello World"`, compiling with `ghc --make -dynamic Main.hs`, I get: {{{ ~/Documents/devel/test$ ./Main dyld: Library not loaded: /usr/local/lib/ghc-7.6.3/base-4.6.0.1/libHSbase-4.6.0.1-ghc7.6.3.dylib Referenced from: /Users/christiaan/Documents/devel/test/./Main Reason: image not found Trace/BPT trap: 5 }}} The reason for this is that: * I installed GHC in: `/opt/ghc/7.6.3` instead of the default `/usr/local`. * GHC-bundled libraries get an OS X `install_name` with a prefix of `/usr/local/` instead of `/opt/ghc/7.6.3/`, meaning that the runtime linker will be looking in the wrong place. So, I wondered why this bug never showed in the testsuite and decided to test: {{{ /opt/ghc/7.6.3/src/ghc/testsuite (ghc-7.6)$ make WAY=dyn TEST=10queens … =====> 10queens(dyn) 1834 of 3403 [0, 0, 0] cd ./programs/10queens && '/opt/ghc/7.6.3/src/ghc/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package- db -rtsopts -fno-ghci-history --make -o 10queens Main -O -dynamic >10queens.comp.stderr 2>&1 cd ./programs/10queens && ./10queens </dev/null >10queens.run.stdout 2>10queens.run.stderr OVERALL SUMMARY for test run started at Fri Jan 31 09:42:45 CET 2014 3403 total tests, which gave rise to 13561 test cases, of which 0 caused framework failures 13560 were skipped 1 expected passes 0 had missing libraries 0 expected failures 0 unexpected passes 0 unexpected failures }}} However, when I run the `10queens` program myself: {{{ /opt/ghc/7.6.3/src/ghc/testsuite (ghc-7.6)$ tests/programs/10queens/10queens dyld: Library not loaded: /usr/local/lib/ghc-7.6.3.20130421/base-4.6.0.1/libHSbase-4.6.0.1-ghc7.6.3.20130421.dylib Referenced from: /opt/ghc/7.6.3/src/ghc/testsuite/tests/programs/10queens/10queens Reason: image not found Trace/BPT trap: 5 }}} I get a similar error as the one reported above. Due to commit f7be53ac9dac85b83e7fe5ecede01b98a572ba48, these errors will no longer show in GHC 7.8. However, I feel that the testsuite is now giving a false sense of security in terms of dynamic linking. Obviously dynamic linking was broken in 7.6, but the testsuite did not catch it! Sadly, this behaviour can now only be verified in the 7.6 branch, and not in 7.8 or HEAD. Hopefully somebody more knowledgeable of the testsuite can comment why dynamic linking worked when an executable was run "within" the testsuite, whilst being broken when run normally. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8721> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11272: Overloaded state-monadic function is not specialised
by GHC 13 May '17

13 May '17

#11272: Overloaded state-monadic function is not specialised -------------------------------------+------------------------------------- Reporter: NickSmallbone | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I have a simple typeclass-polymorphic function which fails to specialise. Here is module A which defines the function `overloaded`: {{{#!hs module A where import Control.Monad.Trans.State import Control.Monad overloaded :: Ord a => a -> a -> State () () overloaded x y = do () <- get when (x <= y) (overloaded y x) }}} In module B I use `overloaded` on `Int`s: {{{#!hs module B where import A import Control.Monad.Trans.State specialised :: Int -> Int -> () specialised x y = execState (A.overloaded x y) () }}} Unfortunately the generated code is not specialised but passes an `Ord` dictionary around. It doesn't make any difference if I mark `overloaded` as `INLINEABLE` or not. In the core file, `overloaded` has been worker-wrapper transformed but the worker is marked `INLINEABLE[0]` - so I'm not sure why it's not being specialised. Curiously, if I make `overloaded` be a normal function instead of one in the state monad, or if I replace `() <- get` with simply `get`, specialisation goes through fine. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11272> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #9450: GHC instantiates Data instances before checking hs-boot files
by GHC 11 May '17

11 May '17

#9450: GHC instantiates Data instances before checking hs-boot files -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: boot,deriving | Operating System: Architecture: x86_64 (amd64) | Unknown/Multiple Difficulty: Unknown | Type of failure: Compile- Blocked By: | time crash Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When compiling a file with deriving instances in it and making use of boot files, it appears that the derivation is attempted before the boot files are checked for consistency. This can lead to GHC panics, as when compiling GHC after this commit https://github.com/alanz/ghc/commit/c73182ca7345f0debba47d0b17a907bcac27c41f In the attached files, if you try to load HsLit.lhs into ghci it will complain about the missing Data instance, not about the boot file inconsistency. If you remove the Data from the deriving clause of HsOverLit, it complains about the boot file inconsistency. I have not managed to reproduce the original panic in this stripped down environment, but if it is needed to more fully understand the problem I can try again to do that. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9450> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8