September 2016 - ghc-tickets

[GHC] #12175: Instance resolution regression
by GHC 26 May '17

26 May '17

#12175: Instance resolution regression -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following code works in 7.10, but fails in GHC 8.0.1: {{{ {-# LANGUAGE ConstraintKinds, MultiParamTypeClasses, TypeFamilies, UndecidableInstances #-} import GHC.Exts class Foo a instance (Foo a, Foo b, CTypeOf a ~ CTypeOf b) => Foo (a,b) type family TElt r :: Constraint type instance TElt r = (Foo r, Dispatch (CTypeOf r) r) type family CTypeOf x where CTypeOf (a,b) = CTypeOf a class (repr ~ CTypeOf r) => Dispatch repr r data CT r = CT [r] toCT :: (Foo r) => CT r -> CT r toCT = undefined unzipT :: (TElt a, TElt b, TElt (a,b)) => CT (a,b) -> (CT a, CT b) unzipT = unzipT . toCT main :: IO () main = undefined }}} with the errors {{{ Main.hs:1:1: error: solveWanteds: too many iterations (limit = 4) Unsolved: WC {wc_simple = [D] _ :: Dispatch fsk_a3GC b (CDictCan) [W] hole{a3Hh} :: CTypeOf a ~ CTypeOf b (CNonCanonical) [D] _ :: fsk_a3GC ~ CTypeOf b (CDictCan) [D] _ :: fsk_a3GC ~ CTypeOf b (CDictCan) [D] _ :: fsk_a3GC ~ CTypeOf b (CNonCanonical)} New superclasses found Set limit with -fconstraint-solver-iterations=n; n=0 for no limit Main.hs:22:19: error: • Couldn't match type ‘CTypeOf a’ with ‘CTypeOf b’ arising from a use of ‘toCT’ NB: ‘CTypeOf’ is a type function, and may not be injective • In the second argument of ‘(.)’, namely ‘toCT’ In the expression: unzipT . toCT In an equation for ‘unzipT’: unzipT = unzipT . toCT • Relevant bindings include unzipT :: CT (a, b) -> (CT a, CT b) (bound at Main.hs:22:1) }}} I don't understand the first error at all. The second error seems to be due to calling `toCT` on the type `CT (a,b)`, which requires the constraint `Foo (a,b)`. Rather than using the supplied constraint from `TElt (a,b)`, GHC is trying to resolve the instance provided, which requires `CType a ~ CType b`. Possibly related: #10338, #11948 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12175> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8905: Function arguments are always spilled/reloaded if scrutinee is already in WHNF
by GHC 26 May '17

26 May '17

#8905: Function arguments are always spilled/reloaded if scrutinee is already in WHNF ------------------------------+-------------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- The code generator unnecessarily spills and reloads function arguments if the scrutinee turns out to be already evaluated (i.e. has non-zero tag bits). Here's the beginning of a function body, taken from the `insert` function at https://github.com/tibbe/unordered- containers/blob/master/Data/HashMap/Base.hs#L303: {{{ c2wQ: // stack check if ((Sp + -72) < SpLim) goto c2wR; else goto c2wS; c2wR: // stack check failure R1 = PicBaseReg + $wpoly_go_closure; I64[Sp - 40] = R2; I64[Sp - 32] = R3; P64[Sp - 24] = R4; I64[Sp - 16] = R5; P64[Sp - 8] = R6; Sp = Sp - 40; call (I64[BaseReg - 8])(R1) args: 48, res: 0, upd: 8; c2wS: // stack check success I64[Sp - 40] = PicBaseReg + block_c2my_info; // return addr for eval R1 = R6; // t I64[Sp - 32] = R2; // spill: s I64[Sp - 24] = R3; // spill: x P64[Sp - 16] = R4; // spill: k I64[Sp - 8] = R5; // spill: h Sp = Sp - 40; if (R1 & 7 != 0) goto c2my; else goto c2mz; // eval check of t c2mz: // eval check failed call (I64[R1])(R1) returns to c2my, args: 8, res: 8, upd: 8; // eval c2my: // eval check succeeded _s2b1::I64 = I64[Sp + 8]; // reload: h _s2b2::I64 = I64[Sp + 16]; // reload: k _s2b3::P64 = P64[Sp + 24]; // reload: x _s2b4::I64 = I64[Sp + 32]; // reload: s switch [0 .. 4] (R1 & 7 - 1) { case 0 : goto c2wK; case 1 : goto c2wL; case 2 : goto c2wM; case 3 : goto c2wN; case 4 : goto c2wO; } }}} It seems to me that all the spills/reloads could be pushed into the `c2mz` block. The `c2my` block, in its current form, is reused for a heap check failure case, so the heap check most likely will have to do its own spilling/reloading. However, since the scrutinee not having tags bit or the eval checking failing is not the common case, they should be out of the common path. If it matters the data type is spine strict so GHC should have enough information to know that the common case (e.g. self-recursive calls) already have an evaluated argument (although there might be an indirection in some cases). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8905> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[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] #11593: Template Haskell: Add a way to get names that are neither capturable nor capturing.
by GHC 21 May '17

21 May '17

#11593: Template Haskell: Add a way to get names that are neither capturable nor capturing. -------------------------------------+------------------------------------- Reporter: cgibbard | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Template | Version: 7.10.3 Haskell | Keywords: | Operating System: Unknown/Multiple yhjulwwiefzojcbxybbruweejw | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- From the documentation on newName: "Although names generated by newName cannot ''be captured'', they can ''capture'' other names." We recently ran into a case where we'd really have liked a way to create a name which can't interact at all with other names in the code, apart from where it is used in the construction of the TH expression. In this code: https://github.com/reflex-frp/reflex/blob/develop/src/Reflex/Dynamic/TH.hs The `newName "dynamicQuotedExpressionVariable"` used to be simply `newName "dyn"`, and we ended up having occurrences of `dyn` in the quasiquoted expressions (which would be constructed by NameG) get captured by that newName rather than referring to reflex-dom's definition of `dyn`. There ought to be some Q Name action which can be executed to give fresh names which can be used internally by a TH macro without fear that they can be referred to in any way other than using the Name value obtained from the action. The documentation for `Name` seems to suggest that newName is presently the closest thing, so perhaps we need a new primitive for creating totally-non-interacting Names. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11593> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[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] #12136: SIGABRT on right-shift operation against long negative integer
by GHC 20 May '17

20 May '17

#12136: SIGABRT on right-shift operation against long negative integer --------------------------------------+---------------------------------- Reporter: khibino | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------------- When the code like bellow is executed, the '''shiftR''' call causes SIGABRT. c128.hs {{{#!hs import Data.Bits x:: Integer x = 1 - (1 `shiftL` (128 + 64)) main :: IO () main = print $ x `shiftR` 128 }}} I make this report using examples in GHC 7.10.3, and I found the same problem in GHC 8.0.1 too. backtrace using GDB {{{ % ghc -O0 c128.hs [1 of 1] Compiling Main ( c128.hs, c128.o ) Linking c128 ... % gdb ./c128 GNU gdb (Debian 7.10-1+b1) 7.10 ... Reading symbols from ./c128...(no debugging symbols found)...done. (gdb) run Starting program: /home/hibi/src/haskell/crash/Haskell/c128 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Program received signal SIGABRT, Aborted. 0x00007ffff6ed4478 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:55 55 ../sysdeps/unix/sysv/linux/raise.c: そのようなファイルやディレクトリはありません. (gdb) bt #0 0x00007ffff6ed4478 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:55 #1 0x00007ffff6ed58fa in __GI_abort () at abort.c:89 #2 0x00000000004716df in integer_gmp_mpn_rshift_2c () #3 0x000000000046e004 in salz_info () #4 0x0000000000000000 in ?? () (gdb) frame 2 #2 0x00000000004716df in integer_gmp_mpn_rshift_2c () (gdb) disas Dump of assembler code for function integer_gmp_mpn_rshift_2c: 0x0000000000471630 <+0>: push %r13 ... 0x00000000004716d8 <+168>: jne 0x4716c0 <integer_gmp_mpn_rshift_2c+144> 0x00000000004716da <+170>: callq 0x402c80 <abort@plt> => 0x00000000004716df <+175>: nop 0x00000000004716e0 <+176>: lea 0x0(,%rdx,8),%rdx ... End of assembler dump. (gdb) }}} I found '''abort''' call in '''integer_gmp_mpn_rshift_2c'''. ghc-7.10.3/libraries/integer-gmp2/cbits/wrappers.c {{{#!c mp_limb_t integer_gmp_mpn_rshift_2c (mp_limb_t rp[], const mp_limb_t sp[], const mp_size_t sn, const mp_bitcnt_t count) { ... // round if non-zero bits were shifted out if (nz_shift_out) if (mpn_add_1(rp, rp, rn, 1)) abort(); /* should never happen */ return rp[rn-1]; } }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12136> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8