February 2019 - ghc-tickets

[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] #16300: Make TH always reify data types with explicit return kinds
by GHC 11 Feb '19

11 Feb '19

#16300: Make TH always reify data types with explicit return kinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Template | Version: 8.6.3 Haskell | 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: -------------------------------------+------------------------------------- Currently, whenever you reify a data type with Template Haskell, it will return a `DataD`/`NewtypeD` where the return kind information has been set to `Nothing`: {{{ λ> putStrLn $(reify ''Bool >>= stringE . show) TyConI (DataD [] GHC.Types.Bool [] Nothing [NormalC GHC.Types.False [],NormalC GHC.Types.True []] []) }}} One could argue that this isn't a problem since data types always have return kind `Type` anyway. For 99% of data types, this is true. There are a handful of exceptions, such as unboxed tuples (with return kind `TYPE (TupleRep [...])`, but those could be dismissed as unusual special cases. With the advent of [https://phabricator.haskell.org/D4777 unlifted newtypes], however, things become murkier. `UnliftedNewtypes` let you define newtypes like this one: {{{#!hs newtype Foo :: TYPE IntRep where MkFoo :: Int# -> Foo }}} Notice how the return kind is //not// `Type`, but instead `TYPE IntRep`. However, TH reification doesn't clue you in to this fact: {{{ λ> putStrLn $(reify ''Foo >>= stringE . show) TyConI (NewtypeD [] Ghci8.Foo [] Nothing (GadtC [Ghci8.MkFoo] [(Bang NoSourceUnpackedness NoSourceStrictness,ConT GHC.Prim.Int#)] (ConT Ghci8.Foo)) []) }}} Still `Nothing`. There's no easy way in general to determine what the return kind of an unlifted newtype is using TH reification, which is unfortunate. Luckily, I think there's a very simple fix that we could apply here: just have TH reification return `Just (<kind>)` instead of `Nothing`! There's no technical reason why TH couldn't do this; the only reason it currently returns `Nothing` is due to historical convention. Moreover, I doubt that this would even break any code in the wild, since `Nothing` doesn't convey any useful information in the context of TH reification anyway. Does this sound reasonable? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16300> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[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

Re: [GHC] #7679: Regression in -fregs-graph performance
by GHC 11 Feb '19

11 Feb '19

#7679: Regression in -fregs-graph performance -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler (NCG) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #7192, #8657 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by vanessamchale): * cc: vanessa.mchale@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7679#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #16282: all-missed-specializations doesn't suggest warning
by GHC 11 Feb '19

11 Feb '19

#16282: all-missed-specializations doesn't suggest warning -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `-Weverything` turns on `-Wall-missed-specializations`. When most warnings print, they say, e.g., `warning: [-Wincomplete-uni-patterns]` which is helpful because I can then easily suppress all warnings of that type with an `-fno-warn-*`. But missed specializations do not show the warning flag: {{{ Foo.hs: warning: Could not specialise imported function `foo' Probable fix: add INLINABLE pragma on `foo' }}} There is no indication of what warning flag triggered the warning. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16282> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[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] #16304: Hadrian: refactor libffi and rts rules.
by GHC 11 Feb '19

11 Feb '19

#16304: Hadrian: refactor libffi and rts rules. -------------------------------------+------------------------------------- Reporter: davide | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (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: -------------------------------------+------------------------------------- The rts package depends on libffi. The hadrian rules around this are a bit hacky. The rts needs some specific header files, then the corresponding libffi rule takes on some unsolicited responsibilities, copying some important files into the rts directory. Also see mpickering's [https://gitlab.haskell.org/ghc/ghc/merge_requests/174#note_3288 comment] on this: This whole copying the header files into the rts dir seemed very dodgy to me. Why do we not depend on libffi when building the rts and then copy the files we need in the rules for building the rts? This is a hack implemented partly to get around the issue of not knowing the names of some libffi files until after building libffi. There surely is an idiomatic solution to this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16304> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0