January 2019 - ghc-tickets

[GHC] #15219: Implement UnliftedNewtypes proposal
by GHC 14 Feb '19

14 Feb '19

#15219: Implement UnliftedNewtypes proposal -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple UnliftedNewtypes | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The unlifted newtypes proposal is described here: https://github.com/ghc- proposals/ghc-proposals/blob/master/proposals/0013-unlifted-newtypes.rst I am going to be working on it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15219> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #16247: GHC 8.6 Core Lint regression (Kind application error)
by GHC 12 Feb '19

12 Feb '19

#16247: GHC 8.6 Core Lint regression (Kind application error) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 (Type checker) | Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following program produces a Core Lint error on GHC 8.6.3 and HEAD: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind data SameKind :: forall k. k -> k -> Type data Foo :: forall a k (b :: k). SameKind a b -> Type where MkFoo :: Foo sameKind }}} {{{ $ /opt/ghc/8.6.3/bin/ghc Bug.hs -dcore-lint [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) *** Core Lint errors : in result of CorePrep *** <no location info>: warning: In the type ‘forall k (a :: k) k (b :: k) (sameKind :: SameKind a b). Foo sameKind’ Kind application error in type ‘SameKind a_aWE b_aWG’ Function kind = forall k. k -> k -> * Arg kinds = [(k_aWF, *), (a_aWE, k_aWD), (b_aWG, k_aWF)] Fun: k_aWF (a_aWE, k_aWD) *** Offending Program *** <elided> MkFoo :: forall k (a :: k) k (b :: k) (sameKind :: SameKind a b). Foo sameKind }}} (Confusingly, the type of `MkFoo` is rendered as `forall k (a :: k) k (b :: k) (sameKind :: SameKind a b). Foo sameKind` in that `-dcore-lint` error, but I think it really should be `forall k1 (a :: k1) k2 (b :: k2) (sameKind :: SameKind a b). Foo sameKind`.) On GHC 8.4.4 and earlier, this simply produces an error message: {{{ $ /opt/ghc/8.4.4/bin/ghc Bug.hs -dcore-lint [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:9:13: error: • These kind and type variables: a k (b :: k) are out of dependency order. Perhaps try this ordering: k (a :: k) (b :: k) • In the kind ‘forall a k (b :: k). SameKind a b -> Type’ | 9 | data Foo :: forall a k (b :: k). SameKind a b -> Type where | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16247> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #16051: Cross compilation broken under Hadrian
by GHC 12 Feb '19

12 Feb '19

#16051: Cross compilation broken under Hadrian -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Build System | Version: 8.7 (Hadrian) | 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: -------------------------------------+------------------------------------- Hadrian falls over essentially immediately when cross-compiling: {{{ $ ./boot $ ./configure --target=aarch64-linux-gnu $ hadrian/build.cabal.sh -j32 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16051> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #16073: Hadrian build fails on Windows
by GHC 12 Feb '19

12 Feb '19

#16073: Hadrian build fails on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.3 (Hadrian) | Keywords: | Operating System: Windows Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- See https://gitlab.haskell.org/ghc/ghc/-/jobs/2838. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16073> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #16075: OPTIONS_GHC Ignored
by GHC 12 Feb '19

12 Feb '19

#16075: OPTIONS_GHC Ignored -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When I enable `-Weverything`, some `OPTIONS_GHC` pragmas are respected, while others are ignored. For example, with `-Weverything`, this file {{{ main = print "hello" foo :: (Num a, Show a) => a -> IO () foo = print . show }}} generates warnings about: 1. missing an export list 2. top-level binding [main] with no type sig 3. redundant constraint [Num a] If I add `{-# OPTIONS_GHC -fno-warn-missing-signatures -fno-warn-missing- export-lists -fno-warn-redundant-constraints #-}` to the top of the file and recompile, I expect all warnings to go away. But GHC still reports that `main` has no signature. Note that this problem doesn't occur with `-Wall`. With `-Wall`, the code snippet warns about the missing signature on `main`, but when I add the `OPTIONS_GHC`, the warning goes away. Thus this problem appears to be unique to `Weverything`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16075> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15622: Generalize `E{0,1,2,3,6,9,12}` from `Data.Fixed`
by GHC 11 Feb '19

11 Feb '19

#15622: Generalize `E{0,1,2,3,6,9,12}` from `Data.Fixed` -------------------------------------+------------------------------------- Reporter: rockbmb | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Core | Version: 8.4.3 Libraries | Keywords: base, | Operating System: Unknown/Multiple Data.Fixed | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hello; I'm creating this email to propose a change to `Data.Fixed`. Full credit for this idea goes to Bhavik Mehta (@b-mehta on GitHub), who implemented it in this [https://github.com/dmcclean/exact-pi/pull/8 PR] for `exact- pi`. In `Data.Fixed` there are several `E`-prefixed datatypes used to represent a certain number of digits of precision in fixed-precision arithmetic. For example, `E1` has 1 decimal place, `E12` has 12. Each of them, `E{0,1,2,3,6,9,12}` is hardcoded. If more precision types are to be provided, they have to be hardcoded as well, and all of these types resemble each other. I think there is room for improvement here. Instead of having {{{#!hs data E0 instance HasResolution E0 where resolution _ = 1 }}} and repeating it as many times as there are `E` datatypes, I propose to add the following type: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE KindSignatures #-} import GHC.TypeLits (Nat, KnownNat, natVal) data E (n :: Nat) }}} and then do {{{#!hs instance KnownNat n => HasResolution (E n) where resolution _ = 10^natVal (undefined :: E n) }}} just once, replacing `data E0` with `type E0 = E 0` (and the same for the rest of them) to continue reexporting these types. `E` should also be exported. I've sent an email to the Core Libraries Committee regarding this issue. This is my first contribution to GHC, if I'm doing something incorrectly please tell me. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15622> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 31

[GHC] #16052: Core optimizations for memset on a small range
by GHC 11 Feb '19

11 Feb '19

#16052: Core optimizations for memset on a small range -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 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: -------------------------------------+------------------------------------- I've been doing some API bindings lately that require zeroing out memory before poking values into the appropriate places. Sometimes, these are small data structures. For instance, on linux, the internet socket struct `sockaddr_in` is 16 bytes. Here's an example (not involving `sockaddr_in`) of the kind of situation that arises: {{{ {-# language MagicHash #-} {-# language UnboxedTuples #-} module FillArray ( fill ) where import GHC.Exts import GHC.IO data ByteArray = ByteArray ByteArray# fill :: IO ByteArray fill = IO $ \s0 -> case newByteArray# 24# s0 of (# s1, m #) -> case setByteArray# m 0# 24# 0# s1 of s2 -> case writeWord8Array# m 4# 14## s2 of s3 -> case writeWord8Array# m 5# 15## s3 of s4 -> case unsafeFreezeByteArray# m s4 of (# s5, r #) -> (# s5, ByteArray r #) }}} This `fill` function allocates a 24-byte array, sets everything to zero, and then writes the numbers 14 and 15 to elements 4 and 5 respectively. With `-O2`, here's the relevant part of the core we get: {{{ fill1 fill1 = \ s0_a140 -> case newByteArray# 24# s0_a140 of { (# ipv_s16i, ipv1_s16j #) -> case setByteArray# ipv1_s16j 0# 24# 0# ipv_s16i of s2_a143 { __DEFAULT -> case writeWord8Array# ipv1_s16j 4# 14## s2_a143 of s3_a144 { __DEFAULT -> case writeWord8Array# ipv1_s16j 5# 15## s3_a144 of s4_a145 { __DEFAULT -> case unsafeFreezeByteArray# ipv1_s16j s4_a145 of { (# ipv2_s16p, ipv3_s16q #) -> (# ipv2_s16p, ByteArray ipv3_s16q #) } } } } } }}} And, here's the relevant assembly: {{{ fill1_info: _c1kL: addq $56,%r12 cmpq 856(%r13),%r12 ja _c1kP _c1kO: movq $stg_ARR_WORDS_info,-48(%r12) movq $24,-40(%r12) leaq -48(%r12),%rax subq $8,%rsp leaq 16(%rax),%rdi xorl %esi,%esi movl $24,%edx movq %rax,%rbx xorl %eax,%eax call memset addq $8,%rsp movb $14,20(%rbx) movb $15,21(%rbx) movq $ByteArray_con_info,-8(%r12) movq %rbx,(%r12) leaq -7(%r12),%rbx jmp *(%rbp) _c1kP: movq $56,904(%r13) movl $fill1_closure,%ebx jmp *-8(%r13) .size fill1_info, .-fill1_info }}} What a bummer that using `memset` for something as small setting three machine words (on a 64 bit platform) results in a `call` instruction getting generated. Why not simply generate three `movb` instructions for the zero initialization instead? Currently, users can work around this by translating their `setByteArray#` call to several `writeWordArray#` calls. This optimization obscures the meaning of written code and is not portable across architectures (so you have to use `CPP` to make it work on 32 bit and 64 bit). I'd like to add a cmm-to-assembly optimization to GHC that does unrolling instead so that the user can write more natural code. Specifically, here's what I'm thinking: * This only happens when the offset into the `ByteArray#` and the length of the range are constant that are multiples of the machine word size. So, `setByteArray# arr 8# 16# x` is eligible on 32-bit and 64-bit platforms. And `setByteArray# arr 4# 8# x` is eligible only on a 32-bit platform. And `setByteArray# arr 16# y x` is not eligible on any platform. * This only happens when the `call memset` instruction has a range of 32 bytes or less. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16052> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #16166: Compiling with profiling on Windows can cause linker errors
by GHC 11 Feb '19

11 Feb '19

#16166: Compiling with profiling on Windows can cause linker errors -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Windows Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I've attached code that is a drastically trimmed down version of the `warp` library, which depends only on `base` and `bytestring`. I've added a dummy executable, and when compiled with `stack build --profile warp`, results in the following linker errors on Windows: {{{ Linking .stack-work\dist\e626a42b\build\linkerr\linkerr.exe ... C:\Users\ericcro\Desktop\wai\warp\.stack- work\dist\e626a42b\build/libHSwarp-3.2.25-Iebn3G7jEoUDRqe90gH8n4_p.a(RequestHeader.p_o):fake:(.text+0x920): undefined reference to `__chkstk_ms' C:\Users\ericcro\Desktop\wai\warp\.stack- work\dist\e626a42b\build/libHSwarp-3.2.25-Iebn3G7jEoUDRqe90gH8n4_p.a(RequestHeader.p_o):fake:(.text+0xc10): undefined reference to `__chkstk_ms' C:\Users\ericcro\Desktop\wai\warp\.stack- work\dist\e626a42b\build/libHSwarp-3.2.25-Iebn3G7jEoUDRqe90gH8n4_p.a(RequestHeader.p_o):fake:(.text+0xc70): undefined reference to `__chkstk_ms' C:\Users\ericcro\Desktop\wai\warp\.stack- work\dist\e626a42b\build/libHSwarp-3.2.25-Iebn3G7jEoUDRqe90gH8n4_p.a(RequestHeader.p_o):fake:(.text+0xdd8): undefined reference to `__chkstk_ms' C:\Users\ericcro\Desktop\wai\warp\.stack- work\dist\e626a42b\build/libHSwarp-3.2.25-Iebn3G7jEoUDRqe90gH8n4_p.a(RequestHeader.p_o):fake:(.text+0xe90): undefined reference to `__chkstk_ms' C:\Users\ericcro\Desktop\wai\warp\.stack- work\dist\e626a42b\build/libHSwarp-3.2.25-Iebn3G7jEoUDRqe90gH8n4_p.a(RequestHeader.p_o):fake:(.text+0xee0): more undefined references to `__chkstk_ms' follow collect2.exe: error: ld returned 1 exit status `gcc.exe' failed in phase `Linker'. (Exit code: 1) -- While building package warp-3.2.25 using: C:\sr\setup-exe-cache\x86_64-windows\Cabal- simple_Z6RU0evB_2.4.0.1_ghc-8.6.3.exe --builddir=.stack-work\dist\e626a42b build lib:warp exe:linkerr --ghc-options " -ddump-hi -ddump-to-file -fdiagnostics-color=always" Process exited with code: ExitFailure 1 }}} This is preventing me from doing any profiling on my large program which is built on `warp`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16166> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #16257: -fexternal-interpreter with external C shared library leads to undefined symbol during template haskell phase
by GHC 11 Feb '19

11 Feb '19

#16257: -fexternal-interpreter with external C shared library leads to undefined symbol during template haskell phase -------------------------------------+------------------------------------- Reporter: guibou | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 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: -------------------------------------+------------------------------------- I'm building the following `Foo.hs` program using the `hmatrix-gsl` library: {{{#!haskell {-# LANGUAGE TemplateHaskell #-} import Numeric.GSL.Integration main = do print $([| 10 |]) print $ integrateQNG 1 (\x -> x) 0 1 }}} I observes undefined symbols during the template haskell phase when using `-fexternal-interpreter`: Without `-fexternal-interpreter`: {{{ $ ghc -package hmatrix-gsl Foo.hs [1 of 1] Compiling Main ( Foo.hs, Foo.o ) Linking Foo ... [nix-shell:~/bug_report_external]$ ./Foo 10 (0.5,5.551115123125783e-15) }}} But with `-fexternal-interpreter`: {{{ $ ghc -fexternal-interpreter -package hmatrix-gsl Foo.hs [1 of 1] Compiling Main ( Foo.hs, Foo.o ) <command line>: can't load .so/.DLL for: /nix/store /6dhcmmfgy5fa0p3d235yaz4qfx8jhpar-gsl-2.5/lib/libgsl.so (/nix/store /6dhcmmfgy5fa0p3d235yaz4qfx8jhpar-gsl-2.5/lib/libgsl.so: undefined symbol: cblas_ctrmv) }}} I suspect that it happen during the template haskell phase because I cannot observe this issue without template haskell. I can observe this issue with a few other libraries, I used `hmatrix-gsl` in this example because it is on hackage. Actually, you can even reduce the file to: {{{#!haskell {-# LANGUAGE TemplateHaskell #-} main = do print $([| 10 |]) }}} and get the same error as long as you have `-package hmatrix-gsl` in your command line. I generate the build environment with this nix file: {{{#!nix with import (fetchTarball { # 25/01/2019 url = https://github.com/nixos/nixpkgs/archive/11cf7d6e1ff.tar.gz; sha256 = "0zcg4mgfdk3ryiqj1j5iv5bljjvsgi6q6j9z1vkq383c4g4clc72"; }) {}; mkShell { buildInputs = [(haskellPackages.ghcWithPackages(p: [p.hmatrix-gsl]))]; } }}} It setups `ghc-8.6.3` with `hmatrix-gsl-0.19.0.1` (the latest on hackage). Note that `hmatrix-gsl` depends on library `gsl` which have a weird symbol setup. The main library file `libgsl` does not contain the `cbal_ctrmv` symbol which is contained in another library `libgslcbal` which is not a dependency of the shared object `libgsl.so`. library `gslcblas` is listed in `extra-libraries` of the `hmatrix-gsl` package: {{{ ghc-pkg field hmatrix-gsl extra-libraries extra-libraries: gsl gslcblas m }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16257> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #14848: -XDuplicateRecordFields breaks record expression splices
by GHC 10 Feb '19

10 Feb '19

#14848: -XDuplicateRecordFields breaks record expression splices -------------------------------------+------------------------------------- Reporter: dailectic | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: GHC rejects (amd64) | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ {-# language TemplateHaskell #-} {-# language DuplicateRecordFields #-} module Lib where import Language.Haskell.TH import Language.Haskell.TH.Syntax data A = A {x :: Int, y :: String} a = A 3 "test" test = $([e|case a of A {x = b} -> b|]) }}} Without `DuplicateRecordFields` it compiles correctly so `test = 3` but with `DuplicateRecordFields` enabled it gives: {{{ • Illegal variable name: ‘$sel:x:A’ When splicing a TH expression: case Lib.a of (Lib.A {Lib.$sel:x:A = b_0}) -> b_0 • In the untyped splice: $([| case a of { A {x = b} -> b } |]) }}} Additionally, there doesn't seem to be a workaround for munging the name manually, since the `$sel:x:A` name is the one actually in scope, there is no `A.x` like there would be normally, even when the label is not a duplicate. Is there a way to get around this? Ex: by changing the binding name somehow manually? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14848> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5