January 2019 - ghc-tickets

[GHC] #12149: Support bit-fields
by GHC 05 Feb '19

05 Feb '19

#12149: Support bit-fields -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Type: bug | Status: new Priority: normal | Milestone: Component: hsc2hs | Version: 8.0.1 Keywords: bit-fields | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Having C type like: {{{ typedef struct S { int f0: 1; int f1: 15; } S; }}} and {{{hsc}}} code like {{{ #{peek S, f0} p }}} Causes {{{hsc2hs}}} to fail with {{{ error: attempt to take address of bit-field structure member 'f0' }}} Apparently this is an error from gcc, which cannot provide the address of bit-fields. However, in Haskell we are not interested in the address of the bit-field but in its value. It would be useful to have a way to get and set the values of these fields. Some former discussion [https://mail.haskell.org/pipermail/haskell- cafe/2008-November/050317.html here] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12149> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #16092: Bug when trying to combine two lists
by GHC 05 Feb '19

05 Feb '19

#16092: Bug when trying to combine two lists -------------------------------------+------------------------------------- Reporter: sutbult | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Building GHC (amd64) | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I want to write a function that takes two lists and returns a list that includes every possible combination of elements from the two given lists, using a given function. I thought that this code would work: {{{#!hs combine :: (a -> b -> c) [a] -> [b] -> [c] combine fn alist blist = [fn a b | a <- alist, b <- blist] }}} However, when compiling, this message arises from GHC: Glasgow Haskell Compiler, Version 8.2.1, stage 2 booted by GHC version 7.10.3 Using binary package database: /Library/Frameworks/GHC.framework/Versions/8.2.1-x86_64/usr/lib/ghc-8.2.1/package.conf.d/package.cache Using binary package database: /Users/samuelutbult/.ghc/x86_64-darwin-8.2.1/package.conf.d/package.cache package flags [] loading package database /Library/Frameworks/GHC.framework/Versions/8.2.1-x86_64/usr/lib/ghc-8.2.1/package.conf.d loading package database /Users/samuelutbult/.ghc/x86_64-darwin-8.2.1/package.conf.d wired-in package ghc-prim mapped to ghc-prim-0.5.1.0 wired-in package integer-gmp mapped to integer-gmp-1.0.1.0 wired-in package base mapped to base-4.10.0.0 wired-in package rts mapped to rts wired-in package template-haskell mapped to template-haskell-2.12.0.0 wired-in package ghc mapped to ghc-8.2.1 wired-in package dph-seq not found. wired-in package dph-par not found. package flags [] loading package database /Library/Frameworks/GHC.framework/Versions/8.2.1-x86_64/usr/lib/ghc-8.2.1/package.conf.d loading package database /Users/samuelutbult/.ghc/x86_64-darwin-8.2.1/package.conf.d wired-in package ghc-prim mapped to ghc-prim-0.5.1.0 wired-in package integer-gmp mapped to integer-gmp-1.0.1.0 wired-in package base mapped to base-4.10.0.0 wired-in package rts mapped to rts-1.0 wired-in package template-haskell mapped to template-haskell-2.12.0.0 wired-in package ghc mapped to ghc-8.2.1 wired-in package dph-seq not found. wired-in package dph-par not found. *** Chasing dependencies: Chasing modules from: *Combine.hs !!! Chasing dependencies: finished in 0.69 milliseconds, allocated 0.222 megabytes Stable obj: [] Stable BCO: [] Ready for upsweep [NONREC ModSummary { ms_hs_date = 2018-12-23 17:18:05.830132761 UTC ms_mod = Main, ms_textual_imps = [(Nothing, Prelude)] ms_srcimps = [] }] *** Deleting temp files: Deleting: compile: input file Combine.hs *** Checking old interface for Main (use -ddump-hi-diffs for more details): [1 of 1] Compiling Main ( Combine.hs, Combine.o ) *** Parser [Main]: !!! Parser [Main]: finished in 1.05 milliseconds, allocated 0.171 megabytes *** Renamer/typechecker [Main]: *** Deleting temp files: Deleting: *** Deleting temp dirs: Deleting: ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-apple-darwin): repSplitAppTys a_anL[sk:1] b_anM[sk:1] -> c_anN[sk:1] [] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:808:9 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16092> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #16004: Vector performance regression in GHC 8.6
by GHC 04 Feb '19

04 Feb '19

#16004: Vector performance regression in GHC 8.6 -------------------------------------+------------------------------------- Reporter: guibou | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 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: -------------------------------------+------------------------------------- Hello. With the following code, I can observe a performance regression between ghc 8.4 and 8.6: {{{#!haskell {-# LANGUAGE ScopedTypeVariables #-} module Main where import qualified Data.Vector.Unboxed.Mutable as Vector import qualified Data.Vector.Unboxed as VectorU import Data.Foldable (for_) main :: IO () main = do let n = 1000 let vUnmutable :: VectorU.Vector Double = VectorU.generate (n * n) (\i -> fromIntegral i) v :: Vector.IOVector Double <- VectorU.unsafeThaw vUnmutable for_ [0..(n - 1)] $ \k -> do for_ [0..(n - 1)] $ \i -> do for_ [0..(n - 1)] $ \j -> do a <- Vector.unsafeRead v (i * n + k) b <- Vector.unsafeRead v (k * n + j) c <- Vector.unsafeRead v (i * n + j) Vector.unsafeWrite v (i * n + j) (min (a + b) c) }}} Built with `-O2` and with / without `-fllvm`. I'm using `vector-0.12.0.1`. Here are the timing results: GHC 8.2.2 no llvm: 1.7s llvm: 1.0s GHC 8.4.4 no llvm: 1.6s llvm: 0.9s GHC 8.6.2 no llvm: 4.8s llvm: 4.3s I'm using the following bash + nix script to gather theses timings: {{{#!bash nix-shell -p 'haskell.packages.ghc822.ghcWithPackages(p: [p.vector])' --run "ghc-pkg list | grep vector; ghc -O2 FloydBench.hs -Wall -fforce- recomp; time ./FloydBench" nix-shell -p 'haskell.packages.ghc822.ghcWithPackages(p: [p.vector])' -p llvm_39 --run "ghc-pkg list | grep vector; ghc -O2 FloydBench.hs -Wall -fforce-recomp -fllvm; time ./FloydBench" nix-shell -p 'haskell.packages.ghc844.ghcWithPackages(p: [p.vector])' --run "ghc-pkg list | grep vector; ghc -O2 FloydBench.hs -Wall -fforce- recomp; time ./FloydBench" nix-shell -p 'haskell.packages.ghc844.ghcWithPackages(p: [p.vector])' -p llvm_5 --run "ghc-pkg list | grep vector; ghc -O2 FloydBench.hs -Wall -fforce-recomp -fllvm; time ./FloydBench" nix-shell -p 'haskell.packages.ghc862.ghcWithPackages(p: [p.vector])' --run "ghc-pkg list | grep vector; ghc -O2 FloydBench.hs -Wall -fforce- recomp; time ./FloydBench" nix-shell -p 'haskell.packages.ghc862.ghcWithPackages(p: [p.vector])' -p llvm_6 --run "ghc-pkg list | grep vector; ghc -O2 FloydBench.hs -Wall -fforce-recomp -fllvm; time ./FloydBench" }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16004> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #14180: Strange/bad error message binding unboxed type variable
by GHC 04 Feb '19

04 Feb '19

#14180: Strange/bad error message binding unboxed type variable -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.3 (Type checker) | Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# language TypeInType, TypeFamilies, MagicHash #-} import GHC.Exts type family MatchInt (f :: Int) :: () where MatchInt ('I# x) = '() }}} produces {{{ <interactive>:2:59: error: • Couldn't match a lifted type with an unlifted type When matching kinds k0 :: * Int# :: TYPE 'IntRep Expected kind ‘Int#’, but ‘x’ has kind ‘k0’ • In the first argument of ‘ 'I#’, namely ‘x’ In the first argument of ‘MatchInt’, namely ‘( 'I# x)’ In the type family declaration for ‘MatchInt’ }}} If, however, I replace `x` in the pattern with `_`, the type checker is satisfied. If I give it a pattern signature, {{{#!hs MatchInt ('I# (x :: Int#)) = '() }}} I get a different (and equally unhelpful) error message, {{{ • Expecting a lifted type, but ‘Int#’ is unlifted • In the kind ‘Int#’ In the first argument of ‘ 'I#’, namely ‘(x :: Int#)’ In the first argument of ‘MatchInt’, namely ‘( 'I# (x :: Int#))’ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14180> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #13624: loadObj() does not respect alignment
by GHC 04 Feb '19

04 Feb '19

#13624: loadObj() does not respect alignment -------------------------------------+------------------------------------- Reporter: tmcdonell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System (Linker) | 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 is perhaps known, but I'll write it down here in case somebody else runs into this problem as well. Since `loadObj()` just `mmap()`s the entire object file and decodes it ''in place'', it does not respect the alignment requirements specified in the section headers. This is problematic for instructions which require alignment, e.g. SSE, AVX. The attached `map.ll` program is `map (+1)` over an array of floating point numbers. In particular, the core loop is 8-way SIMD vectorised x 4-way unrolled, for 32-elements per loop iteration. A tail loop handles any remainder one-at-a-time. You can compile it using `llc -filetype=obj -mcpu=native map.ll`. For a CPU with AVX instructions (sandy bridge or later) you should get the following: {{{ $ objdump -d map.o Disassembly of section .text: 0000000000000000 <map>: 0: 49 89 f3 mov %rsi,%r11 3: 49 29 fb sub %rdi,%r11 6: 0f 8e f9 00 00 00 jle 105 <map+0x105> c: 49 83 fb 20 cmp $0x20,%r11 10: 0f 82 bd 00 00 00 jb d3 <map+0xd3> 16: 4d 89 da mov %r11,%r10 19: 49 83 e2 e0 and $0xffffffffffffffe0,%r10 1d: 4d 89 d9 mov %r11,%r9 20: 49 83 e1 e0 and $0xffffffffffffffe0,%r9 24: 0f 84 a9 00 00 00 je d3 <map+0xd3> 2a: 49 01 fa add %rdi,%r10 2d: 48 8d 44 ba 60 lea 0x60(%rdx,%rdi,4),%rax 32: 49 8d 7c b8 60 lea 0x60(%r8,%rdi,4),%rdi 37: c5 fc 28 05 00 00 00 vmovaps 0x0(%rip),%ymm0 # 3f <map+0x3f> 3e: 00 3f: 4c 89 c9 mov %r9,%rcx 42: 66 66 66 66 66 2e 0f data16 data16 data16 data16 nopw %cs:0x0(%rax,%rax,1) 49: 1f 84 00 00 00 00 00 50: c5 f8 10 4f a0 vmovups -0x60(%rdi),%xmm1 55: c5 f8 10 57 c0 vmovups -0x40(%rdi),%xmm2 5a: c5 f8 10 5f e0 vmovups -0x20(%rdi),%xmm3 5f: c5 f8 10 27 vmovups (%rdi),%xmm4 63: c4 e3 75 18 4f b0 01 vinsertf128 $0x1,-0x50(%rdi),%ymm1,%ymm1 6a: c4 e3 6d 18 57 d0 01 vinsertf128 $0x1,-0x30(%rdi),%ymm2,%ymm2 71: c4 e3 65 18 5f f0 01 vinsertf128 $0x1,-0x10(%rdi),%ymm3,%ymm3 78: c4 e3 5d 18 67 10 01 vinsertf128 $0x1,0x10(%rdi),%ymm4,%ymm4 7f: c5 f4 58 c8 vaddps %ymm0,%ymm1,%ymm1 83: c5 ec 58 d0 vaddps %ymm0,%ymm2,%ymm2 87: c5 e4 58 d8 vaddps %ymm0,%ymm3,%ymm3 8b: c5 dc 58 e0 vaddps %ymm0,%ymm4,%ymm4 8f: c4 e3 7d 19 48 b0 01 vextractf128 $0x1,%ymm1,-0x50(%rax) 96: c5 f8 11 48 a0 vmovups %xmm1,-0x60(%rax) 9b: c4 e3 7d 19 50 d0 01 vextractf128 $0x1,%ymm2,-0x30(%rax) a2: c5 f8 11 50 c0 vmovups %xmm2,-0x40(%rax) a7: c4 e3 7d 19 58 f0 01 vextractf128 $0x1,%ymm3,-0x10(%rax) ae: c5 f8 11 58 e0 vmovups %xmm3,-0x20(%rax) b3: c4 e3 7d 19 60 10 01 vextractf128 $0x1,%ymm4,0x10(%rax) ba: c5 f8 11 20 vmovups %xmm4,(%rax) be: 48 83 e8 80 sub $0xffffffffffffff80,%rax c2: 48 83 ef 80 sub $0xffffffffffffff80,%rdi c6: 48 83 c1 e0 add $0xffffffffffffffe0,%rcx ca: 75 84 jne 50 <map+0x50> cc: 4d 39 cb cmp %r9,%r11 cf: 75 05 jne d6 <map+0xd6> d1: eb 32 jmp 105 <map+0x105> d3: 49 89 fa mov %rdi,%r10 d6: 4c 29 d6 sub %r10,%rsi d9: 4a 8d 04 92 lea (%rdx,%r10,4),%rax dd: 4b 8d 0c 90 lea (%r8,%r10,4),%rcx e1: c5 fa 10 05 00 00 00 vmovss 0x0(%rip),%xmm0 # e9 <map+0xe9> e8: 00 e9: 0f 1f 80 00 00 00 00 nopl 0x0(%rax) f0: c5 fa 58 09 vaddss (%rcx),%xmm0,%xmm1 f4: c5 fa 11 08 vmovss %xmm1,(%rax) f8: 48 83 c0 04 add $0x4,%rax fc: 48 83 c1 04 add $0x4,%rcx 100: 48 ff ce dec %rsi 103: 75 eb jne f0 <map+0xf0> 105: c5 f8 77 vzeroupper 108: c3 req }}} The attached `test.c` will load the object file and try to execute it. The `#define N` on line 7 will change the size of the array. For fewer than 32 elements this works as expected (where the input array is [0..N-1]): {{{ $ ./build.sh + llc-4.0 -filetype=obj -mcpu=native map.ll + ghc --make -no-hs-main test.c $ ./a.out array size is 31 calling function... ok 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 10.0 11.0 12.0 13.0 14.0 15.0 16.0 17.0 18.0 19.0 20.0 21.0 22.0 23.0 24.0 25.0 26.0 27.0 28.0 29.0 30.0 31.0 }}} For 32 elements or larger (i.e. entering the core loop) the program will (almost certainly) segfault. {{{ $ lldb a.out (lldb) target create "a.out" Current executable set to 'a.out' (x86_64). (lldb) run Process 7294 launched: '<snip>/a.out' (x86_64) array size is 32 calling function... Process 7294 stopped * thread #1: tid = 0xc41676, 0x000000010019f207, queue = 'com.apple.main- thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT) frame #0: 0x000000010019f207 -> 0x10019f207: vmovaps 0xe1(%rip), %ymm0 0x10019f20f: movq %r9, %rcx 0x10019f212: nopw %cs:(%rax,%rax) 0x10019f220: vmovups -0x60(%rdi), %xmm1 }}} The `VMOVAPS` instruction requires the source address to be 32-byte aligned. It is attempting to load 8 floats from one of the const sections (the ones for the +1), but since the section was not loaded at the required alignment, fails. I've tested this on x86_64 macOS (Mach-O) and ubuntu (ELF). I don't have any other systems to test on. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13624> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #10857: "ghci -XMonomorphismRestriction" doesn't turn on the monomorphism restriction
by GHC 04 Feb '19

04 Feb '19

#10857: "ghci -XMonomorphismRestriction" doesn't turn on the monomorphism restriction -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Compare {{{ rwbarton@morphism:/tmp$ ghci-7.10.1 -XMonomorphismRestriction GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help Prelude> let a = (+) Prelude> :t a a :: Num a => a -> a -> a }}} with {{{ rwbarton@morphism:/tmp$ ghci-7.10.1 GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help Prelude> :set -XMonomorphismRestriction Prelude> let a = (+) Prelude> :t a a :: Integer -> Integer -> Integer }}} Confusing! This also occurred in 7.8. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10857> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #15185: Enum instance for IntX / WordX are inefficient
by GHC 04 Feb '19

04 Feb '19

#15185: Enum instance for IntX / WordX are inefficient -------------------------------------+------------------------------------- Reporter: guibou | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Core | Version: 8.4.2 Libraries | 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 following factorial benchmark show high discrepancy in performance between `Int` and `Int64` (and similarly between `Word` and `Word64`) when using `product [1..n]` to compute factorial: {{{#!haskell {-# LANGUAGE TypeApplications #-} import Criterion.Main import Data.Int import Data.Word import Numeric.Natural fact :: Integral t => t -> t fact n = product [1..n] fact2 :: Integral t => t -> t fact2 n = go 1 n where go acc 1 = acc go acc n = go (acc * n) (n - 1) main :: IO () main = defaultMain [ bgroup "fact 20" [ bench "Int" $ whnf (fact @Int) 20 , bench "Word" $ whnf (fact @Word) 20 , bench "Int64" $ whnf (fact @Int64) 20 , bench "Word64" $ whnf (fact @Word64) 20 , bench "Integer" $ whnf (fact @Integer) 20 , bench "Natural" $ whnf (fact @Natural) 20 ] , bgroup "fact2 20" [ bench "Int" $ whnf (fact @Int) 20 , bench "Word" $ whnf (fact @Word) 20 , bench "Int64" $ whnf (fact @Int64) 20 , bench "Word64" $ whnf (fact @Word64) 20 , bench "Integer" $ whnf (fact @Integer) 20 , bench "Natural" $ whnf (fact @Natural) 20 ] ] }}} {{{ benchmarking fact 20/Int time 17.33 ns (17.22 ns .. 17.41 ns) 1.000 R² (1.000 R² .. 1.000 R²) mean 17.21 ns (17.16 ns .. 17.29 ns) std dev 222.4 ps (184.5 ps .. 282.3 ps) variance introduced by outliers: 15% (moderately inflated) benchmarking fact 20/Word time 17.25 ns (17.01 ns .. 17.63 ns) 0.999 R² (0.997 R² .. 1.000 R²) mean 17.19 ns (17.11 ns .. 17.36 ns) std dev 358.6 ps (199.4 ps .. 674.3 ps) variance introduced by outliers: 32% (moderately inflated) benchmarking fact 20/Int64 time 166.7 ns (165.4 ns .. 168.5 ns) 0.999 R² (0.997 R² .. 1.000 R²) mean 166.8 ns (166.0 ns .. 168.5 ns) std dev 4.077 ns (1.854 ns .. 6.592 ns) variance introduced by outliers: 35% (moderately inflated) benchmarking fact 20/Word64 time 560.5 ns (550.6 ns .. 575.0 ns) 0.995 R² (0.989 R² .. 1.000 R²) mean 556.5 ns (549.1 ns .. 575.9 ns) std dev 36.08 ns (9.195 ns .. 60.69 ns) variance introduced by outliers: 78% (severely inflated) benchmarking fact 20/Integer time 421.9 ns (419.8 ns .. 425.3 ns) 1.000 R² (0.999 R² .. 1.000 R²) mean 427.7 ns (425.5 ns .. 431.3 ns) std dev 9.238 ns (6.311 ns .. 16.19 ns) variance introduced by outliers: 28% (moderately inflated) benchmarking fact 20/Natural time 534.5 ns (532.6 ns .. 536.3 ns) 1.000 R² (1.000 R² .. 1.000 R²) mean 533.7 ns (532.6 ns .. 535.3 ns) std dev 4.535 ns (3.652 ns .. 6.226 ns) benchmarking fact2 20/Int time 17.14 ns (17.07 ns .. 17.23 ns) 1.000 R² (1.000 R² .. 1.000 R²) mean 17.15 ns (17.10 ns .. 17.24 ns) std dev 227.1 ps (167.4 ps .. 286.9 ps) variance introduced by outliers: 16% (moderately inflated) benchmarking fact2 20/Word time 16.93 ns (16.86 ns .. 17.02 ns) 1.000 R² (1.000 R² .. 1.000 R²) mean 16.90 ns (16.86 ns .. 16.95 ns) std dev 149.8 ps (107.4 ps .. 192.5 ps) benchmarking fact2 20/Int64 time 165.1 ns (164.6 ns .. 165.7 ns) 1.000 R² (1.000 R² .. 1.000 R²) mean 164.8 ns (164.5 ns .. 165.1 ns) std dev 1.033 ns (778.6 ps .. 1.363 ns) benchmarking fact2 20/Word64 time 545.3 ns (542.8 ns .. 547.9 ns) 1.000 R² (1.000 R² .. 1.000 R²) mean 543.6 ns (542.4 ns .. 545.2 ns) std dev 4.741 ns (3.736 ns .. 5.824 ns) benchmarking fact2 20/Integer time 419.1 ns (417.2 ns .. 421.1 ns) 1.000 R² (1.000 R² .. 1.000 R²) mean 418.2 ns (416.8 ns .. 420.2 ns) std dev 5.415 ns (4.094 ns .. 7.147 ns) variance introduced by outliers: 12% (moderately inflated) benchmarking fact2 20/Natural time 533.8 ns (532.2 ns .. 536.1 ns) 1.000 R² (1.000 R² .. 1.000 R²) mean 533.2 ns (532.1 ns .. 534.8 ns) std dev 4.428 ns (3.217 ns .. 5.741 ns) }}} In `fact`, `Int` and `Word` are efficient, `Int64` and `Word64` are respectively 10x and 20x slowers, when they should be identical on 64 bit platform. `Word64` is even slower than `Integer`! Replacing `fact` by a handwritten recursion, in `fact2` gives something more coherent where all the 64 bits types have roughly the same efficiency. I observed in the source code that `Int` and `Int64` are not implemented as type synonym. Using `-ddump-rule-firings`, I observed that a rule `fold/build` fired and removed the `fold` for the `Int` case, and not for the `Int64`, I don't understand much ;( This is not dramatic because most people will use `Int` instead of `Int64`, but it is a surprising behavior. I also observed that smaller integral (such as `Int8`, `Int16`, `Int32`) behaves as badly as `Int64`) and this is much more important because there is no other default and more efficient type synonym. Note that I'll be interested to provide a patch myself if mentored a bit. Especially, I'm thinking about merging the `Int` and `Int64` implementation (with respect to the architecture default word size). Tested on GHC 8.4.2 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15185> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9693: Reloading GHCi with Template Haskell names can panic GHC
by GHC 03 Feb '19

03 Feb '19

#9693: Reloading GHCi with Template Haskell names can panic GHC -------------------------------------+------------------------------------- Reporter: maxs | 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: | rejects valid program Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- First, load the following program into GHCi. '''Fun.hs''' {{{#!hs module Fun where import Language.Haskell.TH stuff = do -- let x = mkName "X" x <- newName "X" sequence $ [dataD (return []) x [] [ normalC x [] ] []] }}} '''thbug.hs''' {{{#!hs {-# LANGUAGE TemplateHaskell #-} import Fun stuff }}} Then comment out the newName, un comment the mkName and reload GHCi. {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-apple-darwin): kcLookupKind APromotionErr RecDataConPE Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} It is important to note this is a valid program, if you then close GHCi and start it again with the modified file, it will load correctly. Reloading after attempting to compile the newName version will cause a panic. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9693> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #11084: Some type families don't reduce with :kind!
by GHC 03 Feb '19

03 Feb '19

#11084: Some type families don't reduce with :kind! -------------------------------------+------------------------------------- Reporter: goldfire | 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: -------------------------------------+------------------------------------- Sadly, I'm unable to reproduce this without `singletons`. :( Observe: {{{ > ghci GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help Prelude> import Data.Promotion.Prelude -- singletons-2.0.1 Prelude Data.Promotion.Prelude> :kind! Lookup 'True '[ '(True, True) ] Lookup 'True '[ '(True, True) ] :: Maybe Bool = Data.Singletons.Prelude.List.Case_1628035408 'True 'True 'True '[] (Data.Singletons.Apply (Data.Singletons.Apply (:==$) 'True) 'True) Prelude Data.Promotion.Prelude> :kind! Lookup 'True '[ '(True, True) ] Lookup 'True '[ '(True, True) ] :: Maybe Bool = JustSym1 'True }}} Note that the exact same command run twice yields different results. I tried peeking at `-ddump-tc-trace` but got nothing of use. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11084> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12001: RFC: Add pattern synonyms to base
by GHC 02 Feb '19

02 Feb '19

#12001: RFC: Add pattern synonyms to base -------------------------------------+------------------------------------- Reporter: Iceland_jack | 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: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Since we have pattern synonyms it's worth considering if some belong in base: [https://hackage.haskell.org/package/lens-4.14/docs/Data-Complex-Lens.html Data.Complex.Lens] contains patterns that could be defined in base, here are some more suggestions: === Data.Array === {{{#!hs pattern ArrayIx :: Ix i => (i, i) -> [(i, e)] -> Array i e pattern ArrayIx low'high xs <- ((\arr -> (bounds arr, assocs arr)) -> (low'high, xs)) where ArrayIx low'high xs = array low'high xs }}} === Data.Bits === {{{#!hs pattern ZeroBits :: (Eq a, Bits a) => a pattern ZeroBits <- ((== zeroBits) -> True) where ZeroBits = zeroBits pattern BitSize :: Bits a => Int -> a pattern BitSize n <- (bitSizeMaybe -> Just n) pattern Signed :: Bits a => a pattern Signed <- (isSigned -> True) pattern Unsigned :: Bits a => a pattern Unsigned <- (isSigned -> False) pattern PopCount :: Bits a => Int -> a pattern PopCount n <- (popCount -> n) }}} === Data.Char === {{{#!hs pattern ControlChar :: Char pattern ControlChar <- (isControl -> True) pattern SpaceChar :: Char pattern SpaceChar <- (isSpace -> True) }}} === Data.Complex === {{{#!hs pattern Conjugate :: Num a => Complex a -> Complex a pattern Conjugate a <- (conjugate -> a) where Conjugate a = conjugate a pattern Polar :: RealFloat a => a -> a -> Complex a pattern Polar m theta <- (polar -> (m, theta)) where Polar m theta = mkPolar m theta -- See https://github.com/ekmett/lens/issues/653 pattern Real :: Num a => a -> Complex a pattern Real r <- r :+ _ where Real r = r :+ 0 pattern Imaginary :: Num a => a -> Complex a pattern Imaginary i <- _ :+ i where Imaginary i = 0 :+ i }}} === GHC.Float === {{{#!hs pattern NegativeZero :: RealFloat a => a pattern NegativeZero <- (isNegativeZero -> True) where NegativeZero = -0 pattern Denormalized :: RealFloat a => a pattern Denormalized <- (isDenormalized -> True) pattern NaN :: RealFloat a => a pattern NaN <- (isNaN -> True) where NaN = 0 / 0 -- How ever negative infinity is handled pattern Infinity :: RealFloat a => a pattern Infinity <- ((== 1 / 0) -> True) where Infinity = 1 / 0 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12001> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16