- ghc-tickets - Haskell.org

[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

Re: [GHC] #6132: Can't use both shebang line and #ifdef declarations in the same file.
by GHC 11 Feb '19

11 Feb '19

#6132: Can't use both shebang line and #ifdef declarations in the same file. -------------------------------------+------------------------------------- Reporter: gfxmonk | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 7.0.4 (Parser) | Resolution: | Keywords: cpp Operating System: MacOS X | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: runghc/T6132 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ahri): I've opened a ticket on the Clang bugtracker: https://bugs.llvm.org/show_bug.cgi?id=40689 I wonder if GHC should simply allow leading whitespace as "sh" seems happy enough to accept a file in this form. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6132#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6132: Can't use both shebang line and #ifdef declarations in the same file.
by GHC 11 Feb '19

11 Feb '19

#6132: Can't use both shebang line and #ifdef declarations in the same file. -------------------------------------+------------------------------------- Reporter: gfxmonk | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 7.0.4 (Parser) | Resolution: | Keywords: cpp Operating System: MacOS X | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: runghc/T6132 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ahri): Still broken on OSX - works fine on Linux and Win32 (64). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6132#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #16302: A non-function coerced to a function can cause a stg_ap_pp_ret
by GHC 11 Feb '19

11 Feb '19

#16302: A non-function coerced to a function can cause a stg_ap_pp_ret -------------------------------------+------------------------------------- Reporter: WheatWizard | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: Runtime crash (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If you create an function by unsafe coercing a non-function you can get some strange functions. If you then take one of these function and apply it something it crashes with a {{{stg_ap_pp_ret}}}. Here is a pretty minimal example. {{{ import Unsafe.Coerce main=(unsafeCoerce()::a->IO())1 }}} You can reproduce it online here: https://tio.run/##y0gszk7Nyfn/PzO3IL@oRCE0rzgxLVXPOT@1KDmVKzcxM89WoxQsBhHS0… Here is another one: {{{ import Unsafe.Coerce g=unsafeCoerce()::a->a main=print$g(g)1 }}} If you coerce functions this doesn't appear to happen. For example: {{{ import Unsafe.Coerce main=(unsafeCoerce id::a->IO())1 }}} is a fine program. Sometimes this causes a segmentation fault (particularly with higher airity functions): {{{ import Unsafe.Coerce main=(unsafeCoerce(+)::a->IO())1 }}} but I've never gotten it to make a {{{stg_ap_pp_ret}}}. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16302> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #16289: GHC thinks pattern match is exhaustive
by GHC 10 Feb '19

10 Feb '19

#16289: GHC thinks pattern match is exhaustive -------------------------------------+------------------------------------- Reporter: dnspies | 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: -------------------------------------+------------------------------------- {{{ {-# OPTIONS_GHC -Werror #-} module Lib where data Value = Finite Integer | Infinity deriving (Eq) instance Num Value where (+) = undefined (*) = undefined abs = undefined signum = undefined negate = undefined fromInteger = Finite isSpecial :: Value -> Bool isSpecial Infinity = True isSpecial 0 = True isSpecial 1 = True isSpecial _ = False }}} {{{ > ghc Lib.hs [1 of 1] Compiling Lib ( Lib.hs, Lib.o ) Lib.hs:19:1: error: [-Woverlapping-patterns, -Werror=overlapping-patterns] Pattern match is redundant In an equation for ‘isSpecial’: isSpecial 1 = ... | 19 | isSpecial 1 = True | ^^^^^^^^^^^^^^^^^^^^^^^^^ Lib.hs:20:1: error: [-Woverlapping-patterns, -Werror=overlapping-patterns] Pattern match is redundant In an equation for ‘isSpecial’: isSpecial _ = ... | 20 | isSpecial _ = False | ^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16289> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[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