September 2017 - ghc-tickets

[GHC] #12658: GHC 7.10.3 sometimes reports unimplemented/strange closure type 63270
by GHC 09 Feb '19

09 Feb '19

#12658: GHC 7.10.3 sometimes reports unimplemented/strange closure type 63270 --------------------------------+--------------------------------------- Reporter: clint | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Linux Architecture: powerpc | Type of failure: Compile-time crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+--------------------------------------- This happened when building http-link-header. {{{ ghc: internal error: scavenge: unimplemented/strange closure type 63270 @ 0xf36de0a8ghc: internal error: scavenge: unimplemented/strange closure type 63270 @ 0xf36de0a8 (GHC version 7.10.3 for powerpc_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Sometimes it segfaults instead. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12658> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9370: large blowup in memory usage and time when doing parallel build of xmlhtml package
by GHC 08 Feb '19

08 Feb '19

#9370: large blowup in memory usage and time when doing parallel build of xmlhtml package -------------------------------------+------------------------------------- Reporter: carter | 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: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I've observed a blowup in ghc memory usage when invoked with parallel build flags. to reproduce {{{ cabal get xmlhtml-0.2.3.2 cabal install xmlhtml-0.2.3.2 --only-dependencies cd xmlhtml-0.2.3.2 }}} then {{{ cabal clean ; cabal configure --ghc-options="-j4" ; time cabal build -j4 -v3 }}} will take quite a while and use > 1gb of ram whereas {{{ cabal clean ; cabal configure --ghc-options="-j1 ; time cabal build -j1 -v3 }}} will use < 150mb of ram. Based upon the output of cabal build -j4 -v3, it looks like the parallel build is spending a lottt more time in the simplifier passes. I'm not sure what changes between the parallel and sequential builds to change this. I'll try to dig into this more in a few days, but recording this problem now before i forget. (though of course any insights would be appreciated) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9370> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 48

[GHC] #8635: GHC optimisation flag ignored when importing a local module with derived type classes
by GHC 08 Feb '19

08 Feb '19

#8635: GHC optimisation flag ignored when importing a local module with derived type classes ------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Given Foo.hs and Bar.hs: {{{ module Foo where data Food = Food -- deriving Eq {-# OPTIONS_GHC -O2 -ddump-simpl #-} module Bar where import Foo bar :: Int -> Bool bar x = x == 72 }}} If I run: {{{ ghc --make Bar -fforce-recomp }}} I get (snipped): {{{ Bar.bar = \ (x_afk :: GHC.Types.Int) -> case x_afk of _ { GHC.Types.I# x1_alo -> case x1_alo of _ { __DEFAULT -> GHC.Types.False; 72 -> GHC.Types.True } } }}} `bar` now looks pretty well optimised. However, if I uncomment the `deriving Eq` I get: {{{ Bar.bar1 = GHC.Types.I# 72 Bar.bar2 = GHC.Classes.== @ GHC.Types.Int GHC.Classes.$fEqInt Bar.bar = \ (x_amD :: GHC.Types.Int) -> Bar.bar2 x_amD Bar.bar1 }}} Now `bar` looks like terrible code, using dictionaries, boxing etc. It seems adding `deriving` in the imported and unused module makes it ignore the optimisation level. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8635> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11822: Pattern match checker exceeded (2000000) iterations
by GHC 07 Feb '19

07 Feb '19

#11822: Pattern match checker exceeded (2000000) iterations -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc3 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: Compile-time (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- graphviz seems a nice benchmark (not too large, few dependencies) that highlights compiler performance problems on "trivial" source code (cf. https://hackage.haskell.org/package/graphviz-2999.18.0.2/docs/src /Data-GraphViz-Attributes-Complete.html#sameAttribute) Compilation of Compiling Data.GraphViz.Attributes.Colors.X11 and Data.GraphViz.Attributes.Values takes >= 1 second each, and the following happens: {{{ cabal install graphviz-2999.18.0.2 --allow-newer ... [17 of 31] Compiling Data.GraphViz.Attributes.Complete ( Data/GraphViz/Attributes/Complete.hs, dist/dist-sandbox- e6f2c124/build/Data/GraphViz/Attributes/Complete.o ) Data/GraphViz/Attributes/Complete.hs:1013:1: warning: Pattern match checker exceeded (2000000) iterations in an equation for ‘sameAttribute’. (Use -fmax-pmcheck-iterations=n to set the maximun number of iterations to n) }}} I do welcome that ghc emits this warning - I expect you want its occurence to be reported as a bug? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11822> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[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] #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] #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