October 2017 - ghc-tickets

[GHC] #9112: data families with representational matching
by GHC 18 Oct '17

18 Oct '17

#9112: data families with representational matching ------------------------------------+------------------------------------- Reporter: jwlato | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Since ghc-7.8, the following is no longer possible: {{{ -- simplified example taken from the vector package class MVectorClass (v :: * -> * -> *) a where basicLength :: v s a -> Int data family MVector s a data instance MVector s Int -- implementation not important newtype Age = Age Int deriving (MVectorClass MVector) -- rejected }}} Following from discussion in #8177, to enable this ghc would need to support data families with representational matching, such that `MVector s Int` and `MVector s Age` are representationally equal. This has broken some code that previously worked, however as there are some workarounds I'm not sure how important it is. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9112> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #14360: traceM documentation not clear (and possibly incorrect)
by GHC 18 Oct '17

18 Oct '17

#14360: traceM documentation not clear (and possibly incorrect) -------------------------------------+------------------------------------- Reporter: saurabhnanda | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 8.0.2 Libraries | Keywords: docs | 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 code-example and the accompanying text at https://www.stackage.org/haddock/lts-9.0/base-4.9.1.0/Debug- Trace.html#v:traceM are out of sync. Also, it's not very clear what the following line means: > Note that the application of traceM is not an action in the Applicative context, as traceIO is in the IO type. I realised something was wrong when, during a refactor, I ended up with the equivalent of the following loop, which caused a thread to completely freeze and become unresponsive: > forever $ traceShowM "something" -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14360> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #13203: Implement Bits Natural clearBit
by GHC 18 Oct '17

18 Oct '17

#13203: Implement Bits Natural clearBit -------------------------------------+------------------------------------- Reporter: dylex | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.0.2 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: -------------------------------------+------------------------------------- The current Bits Natural implementation says: {{{TODO: setBit, clearBit, complementBit (needs more primitives)}}}. The default implementations of setBit and complementBit work fine, but clearBit relies on complement, and so fails. Even if it had to use a conditional complementBit on testBit, it would be better than nothing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13203> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #14359: C-- pipeline/NCG fails to optimize simple repeated addition
by GHC 18 Oct '17

18 Oct '17

#14359: C-- pipeline/NCG fails to optimize simple repeated addition -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.2.1 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: -------------------------------------+------------------------------------- While debugging #14346 I noticed some rather abhorrent code in a disassembly of the `newPinnedByteArray#` primop: {{{ Dump of assembler code for function stg_newPinnedByteArrayzh: 0x00000000004a8518 <+0>: mov 0x378(%r13),%rax 0x00000000004a851f <+7>: cmpq $0x0,0x10(%rax) 0x00000000004a8524 <+12>: je 0x4a8593 <stg_newPinnedByteArrayzh+123> 0x00000000004a8526 <+14>: mov 0x4f5730,%rax 0x00000000004a852e <+22>: mov 0x38(%rax),%rax 0x00000000004a8532 <+26>: cmp 0x4f5718,%rax 0x00000000004a853a <+34>: jae 0x4a8593 <stg_newPinnedByteArrayzh+123> 0x00000000004a853c <+36>: mov %rbx,%rax 0x00000000004a853f <+39>: lea 0x7(%rax),%rcx 0x00000000004a8543 <+43>: shr $0x3,%rcx 0x00000000004a8547 <+47>: add $0x10,%rax <--- starts here 0x00000000004a854b <+51>: add $0xf,%rax 0x00000000004a854f <+55>: add $0x7,%rax 0x00000000004a8553 <+59>: shr $0x3,%rax 0x00000000004a8557 <+63>: mov $0x49d820,%ecx }}} That is three successive `add` instructions; surely those should be collapsed into one by the Cmm-to-Cmm pipeline. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14359> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10980: Deriving Read instance from datatype with N fields leads to N^2 code size growth
by GHC 18 Oct '17

18 Oct '17

#10980: Deriving Read instance from datatype with N fields leads to N^2 code size growth -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- The problem observed on GHC's code base when explored why exactly some object files are so huge. Let's look at the stats of text code section sizes on today's HEAD (skipping GHCi libraries and stage1 binaries): {{{ ~/dev/git/ghc $ size `find -name *.o -type f | grep -v stage1 | grep -v HS` | sort -k1 -n -r | head -n20 text data bss dec hex filename 1791068 145448 0 1936516 1d8c84 ./compiler/stage2/build/DynFlags.o 1558637 77464 0 1636101 18f705 ./compiler/stage2/build/PprC.o 1397966 23272 0 1421238 15afb6 ./compiler/stage2/build/PlatformConstants.o 1332048 373344 0 1705392 1a05b0 ./libraries/Cabal/Cabal/dist- boot/build/Distribution/PackageDescription.o 1331238 373352 0 1704590 1a028e ./bootstrapping/Distribution/PackageDescription.o 1271578 246240 0 1517818 1728fa ./libraries/template-haskell/dist- boot/build/Language/Haskell/TH/Syntax.o 1229696 311616 0 1541312 1784c0 ./libraries/Cabal/Cabal/dist- install/build/Distribution/PackageDescription.o 1215082 224288 0 1439370 15f68a ./libraries/template-haskell/dist- install/build/Language/Haskell/TH/Syntax.o 1071746 242664 0 1314410 140e6a ./compiler/stage2/build/HsExpr.o 1015090 40904 0 1055994 101cfa ./compiler/stage2/build/Llvm/PpLlvm.o 970203 124944 0 1095147 10b5eb ./compiler/stage2/build/Parser.o 849693 79760 0 929453 e2ead ./compiler/stage2/build/HsDecls.o 833327 35440 0 868767 d419f ./compiler/stage2/build/X86/CodeGen.o 819959 127192 0 947151 e73cf ./libraries/Cabal/Cabal/dist- boot/build/Distribution/Simple/Setup.o 819685 125120 0 944805 e6aa5 ./bootstrapping/Distribution/Simple/Setup.o 816927 124520 0 941447 e5d87 ./libraries/Cabal/Cabal/dist- install/build/Distribution/Simple/Setup.o 785398 41536 0 826934 c9e36 ./compiler/stage2/build/CoreLint.o 772550 42040 0 814590 c6dfe ./compiler/stage2/build/DriverPipeline.o 766461 36280 0 802741 c3fb5 ./compiler/stage2/build/HscMain.o 735605 23408 0 759013 b94e5 ./libraries/containers/dist- install/build/Data/Sequence.o }}} '''PlatformConstants.o''' is a very clear example of this problem. Trimmed down example of this file is: {{{#!hs module M (D) where data D = D { a0 , a01 , a02 , a03 , a04 , a05 , a06 , a07 , a08 , a09 , a10 , a11 , a12 , a13 , a14 , a15 , a16 , a17 , a18 , a19 , a20 , a21 , a22 , a23 , a24 , a25 , a26 , a27 , a28 , a29 , a30 , a31 , a32 , a33 , a34 , a35 , a36 , a37 , a38 , a39 , a40 , a41 , a42 , a43 , a44 , a45 , a46 , a47 , a48 , a49 , a50 , a51 , a52 , a53 , a54 , a55 , a56 , a57 , a58 , a59 , a60 , a61 , a62 , a63 , a64 , a65 , a66 , a67 , a68 , a69 , a70 , a71 , a72 , a73 , a74 , a75 , a76 , a77 , a78 , a79 , a80 , a81 , a82 , a83 , a84 , a85 , a86 , a87 , a88 , a89 , a90 , a91 , a92 , a93 , a94 , a95 , a96 , a97 , a98 , a99 :: Int } deriving Read }}} Results in 800KB file: {{{ $ ghc-stage2 -c -O1 -fforce-recomp M.hs -o M.o $ size M.o text data bss dec hex filename 847039 16080 0 863119 d2b8f M.o }}} The size growth is quadratic: {{{ # fields code-size 1 6263 21 61767 41 173623 61 347503 81 583367 101 881231 121 1241087 141 1662959 161 2146815 181 2692679 201 3300543 221 3970407 241 4702263 261 5496135 281 6351991 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10980> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #14358: GHCi does not exit after heap overflow exception
by GHC 17 Oct '17

17 Oct '17

#14358: GHCi does not exit after heap overflow exception -------------------------------------+------------------------------------- Reporter: ferdinandvw | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Start GHCi as follows `ghci +RTS -M20m` Enter the following {{{#!hs > let xs = [1..10^6] :: [Int] > Data.List.foldl' (+) 0 xs }}} This results in (as expected): `*** Exception: heap overflow` However, GHCi did not exit. Entering any expression will result in the above given exception. And if you try to reload GHCi the following panic error will be produced: {{{#!hs Ok, 0 modules loaded. ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-unknown-linux): heap overflow Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I tried the same using GHC 7.10.3 and 8.0.2. In both cases GHCi would exit after the initial heap overflow exception. With 8.2.1 this does not happen. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14358> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #11262: Test print022: wrong stdout on powerpc64
by GHC 17 Oct '17

17 Oct '17

#11262: Test print022: wrong stdout on powerpc64 -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: GHCi | Version: 7.11 Keywords: | Operating System: Linux Architecture: powerpc64 | Type of failure: Incorrect result | at runtime Test Case: print022 | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHCi prints a NUL(?) character instead of an 'x'. {{{ () -test = C 1 32 1.2 1.23 'x' 1 1.2 1.23 +test = C 1 32 1.2 1.23 '/NUL' 1 1.2 1.23 Breakpoint 0 activated at print022.hs:11:1-7 Stopped at print022.hs:11:1-7 _result :: r = _ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11262> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9274: GHC panic with UnliftedFFITypes+CApiFFI
by GHC 17 Oct '17

17 Oct '17

#9274: GHC panic with UnliftedFFITypes+CApiFFI -----------------------------------+--------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- The following code fails to compile with at least GHC 7.6, 7.8 and HEAD: {{{#!hs import GHC.Prim import Foreign.C type GmpLimb = CULong type GmpSize = CLong -- mp_limb_t mpn_add_1 (mp_limb_t *rp, const mp_limb_t *s1p, mp_size_t n, mp_limb_t s2limb) foreign import capi unsafe "gmp.h mpn_add_1" c_mpn_add_1 :: MutableByteArray# s -> ByteArray# -> GmpSize -> GmpLimb -> IO GmpLimb }}} with the following compile error message: {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.9.20140704 for x86_64-unknown-linux): toCType MutableByteArray# s Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Otoh, replacing `capi` with `ccall` makes the code compile just fine -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9274> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #13955: Backpack does not handle unlifted types
by GHC 17 Oct '17

17 Oct '17

#13955: Backpack does not handle unlifted types -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: 8.2.1-rc2 Keywords: backpack | Operating System: Unknown/Multiple LevityPolymorphism | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In the code snippet below, I attempt to use backpack with levity polymorphism: {{{ {-# LANGUAGE MagicHash #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE DataKinds #-} unit number-unknown where signature NumberUnknown where import GHC.Types data Number plus :: Number -> Number -> Number multiply :: Number -> Number -> Number module NumberStuff where import NumberUnknown funcA :: Number -> Number -> Number funcA x y = plus x (multiply x y) unit number-int where module NumberUnknown where type Number = Int plus :: Int -> Int -> Int plus = (+) multiply :: Int -> Int -> Int multiply = (*) unit number-unboxed-int where module NumberUnknown where import GHC.Prim type Number = Int# plus :: Int# -> Int# -> Int# plus = (+#) multiply :: Int# -> Int# -> Int# multiply = (*#) unit main where dependency number-unknown[NumberUnknown=number-unboxed- int:NumberUnknown] module Main where import NumberStuff main = putStrLn "Hello world!" }}} Compiling this with `ghc --backpack packer.bkp` fails with the following error: {{{ - Type constructor ‘Number’ has conflicting definitions in the module and its hsig file Main module: type Number = GHC.Prim.Int# :: TYPE 'GHC.Types.IntRep Hsig file: data Number The types have different kinds - while checking that number-unboxed-int:NumberUnknown implements signature NumberUnknown in number-unknown[NumberUnknown=number-unboxed- int:NumberUnknown] type Number = Int# }}} The error is pretty clear: `Number` can only be instantiated by types of kind `Type` (aka `TYPE LiftedRep`). Even while remaining levity monomorphic, there doesn't seem to be a way to pick a different kind. For example, redefining `Number` in the signature as {{{ data Number :: TYPE IntRep }}} leads to the following immediate failure: {{{ Kind signature on data type declaration has non-* return kind TYPE 'IntRep }}} I do not understand any of the internals of backpack, so I do not understand if there's anything fundamental that makes this impossible. Going one step further, I would like to be able to do something like this (the syntax here is not even currently valid for a backpack signature): {{{ type MyRep :: RuntimeRep data Number :: TYPE MyRep }}} This may be instantiated with something like this: {{{ type MyRep = IntRep type Number = Int# }}} And then end users would be able to monomorphize levity-polymorphic functions. This would be really neat because there is currently no way to do this in GHC. So, I guess there are really two feature requests in here. One is the ability to use unlifted data types with backpack. The other is the ability to use backpack to monomorphize levity-polymorphic functions. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13955> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #14285: Entered absent arg - triggered by INLINEABLE, regression from 8.0.2
by GHC 17 Oct '17

17 Oct '17

#14285: Entered absent arg - triggered by INLINEABLE, regression from 8.0.2 --------------------------------------+--------------------------------- Reporter: j.waldmann | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- Steps to reproduce: {{{ git clone https://gitlab.imn.htwk-leipzig.de/waldmann/pure-matchbox git checkout a2005d246cb7bd77a33bf4c09419534bc7ecd435 stack build .stack-work/install/x86_64-linux/nightly-2017-09-26/8.2.1/bin/pure- matchbox -i -w Count data/z001.srs }}} Output: {{{ pure-matchbox: Oops! Entered absent arg ww Map k (Set k1) }}} Error goes away when compiling with -O0, or when removing this pragma in src/Matchbox/Pairs.hs {{{ 52 {-# INLINEABLE pre_images #-} 53 pre_images x rel = images x $ mirrorRel rel }}} (normal output starts with YES on a single line) Error also goes away when building with 8.0.2 {{{ PATH=/where/you/have/installed/ghc-8.0.2/bin:$PATH stack build --resolver=lts-9.6 }}} I tried to isolate a shorter test case but gave up after some hours. Is there some automation for this? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14285> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9