September 2016 - ghc-tickets

[GHC] #11970: Simplify Parent
by GHC 09 Oct '16

09 Oct '16

#11970: Simplify Parent -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- This commit {{{ commit 96621b1b4979f449e873513e9de8d806257c9493 Associate pattern synonyms with types in module exports }}} added `PatternSynonym` to `RdrName.Parent`. That's a pretty heavy hammer. It forces us to add `IsPatSyn` to `AvailInfo`, including binary serialisation etc. And I think it's needed in precisely one place, namely `RnNames.findPatSyns`. Right? The caller of `findPatSyns` and the associated `lookupChildren` is jolly obscure and I don't fully understand it. I **think** the issue is this: * I want to allow an export item `T( K )`, where `K` is a pattern synonym, even though it's not really (yet) associated with `T`. I think the goal of this code was to reject the `K` if it's a data constructor. But we also have a **further** check in `tcExports` to check that `K` has the right type. Surely it'd be better to nuke this `PatternSynonym` and `IsPatSyn` stuff? Just use`isDataOcc` in the export lookup part. Then the `tcExport` check will object if you write an export item like `Either( Just )`. Fewer moving parts! Matthew, does this make sense? Might you look at it? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11970> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #9547: Empty constraint tuples are mis-kinded
by GHC 07 Oct '16

07 Oct '16

#9547: Empty constraint tuples are mis-kinded -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Consider {{{ -- If :: forall k. 'Bool -> k -> k -> k type family If cond tru fls where If True tru fls = tru If False tru fls = fls foo :: If True () (Eq a) => a -> a foo = error "urk" }}} This should work fine. But we get {{{ Foo.hs:8:21: The third argument of `If' should have kind `*', but `Eq a' has kind `Constraint' In the type signature for `foo': foo :: If True () (Eq a) => a -> a }}} Reason: GHC is treating the `()` unit tuple as of kind `*`. Reason is that in the `HsTupleTy` case of `tc_hs_type` in `TcHsType`, we see {{{ -- In the [] case, it's not clear what the kind is, so guess * }}} And that guess is plain wrong in this case. Unfortunately I don't see an easy fix, but it's plain wrong as-is. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9547> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12395: Misleading GHCi errors when package is installed
by GHC 07 Oct '16

07 Oct '16

#12395: Misleading GHCi errors when package is installed -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When a package is installed in a cabal sandbox/global package directory and code is loaded with GHCi when a file has been deleted, GHCi gives very misleading errors. First, if we don't install the package, we get the correct error/expected result: {{{ > mv B.hs B.hs.old > ghci Main.hs Main.hs:3:1: error: Failed to load interface for ‘B’ Use -v to see a list of the files searched for. Failed, modules loaded: A. }}} But if we first install the package, we get a very strange error: {{{ > mv B.hs.old B.hs > cabal install > mv B.hs B.hs.old > ghci Main.hs Main.hs:6:14: error: Ambiguous occurrence ‘str’ It could refer to either ‘A.str’, imported from ‘A’ at Main.hs:2:1-8 (and originally defined at A.hs:7:1-3) or ‘B.str’, imported from ‘B’ at Main.hs:3:1-8 (and originally defined in ‘A’) Failed, modules loaded: A. }}} I'm using GHC 8.0.1, cabal-install-1.24.0.0, and Cabal Library-1.24.0.0. This is Very Annoying because I use this process to minimize examples. For example, when I want to simplify code by removing a module, I just delete it and then rely on GHCi to tell me what I need to update. Anyone not aware of this bug would be totally confused by the error, and even though I do know about the bug, the error is completely unhelpful. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12395> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #12130: ghc: panic! (the 'impossible' happened): find_tycon Block []
by GHC 06 Oct '16

06 Oct '16

#12130: ghc: panic! (the 'impossible' happened): find_tycon Block [] -------------------------------------+------------------------------------- Reporter: jeiea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.0.1 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I just tried building yesod-simple template project with nightly-2016-05-29 snapshot and some extra-deps package, and it seems to fail due to {{{$(widgetFile ...)}}} yesod template haskell clause. It was same on linux and windows, and when I remove handler ghc fails at Application module (and seems also due to template haskell). {{{ ~/yt> stack build ... yt-0.0.0: configure Configuring yt-0.0.0... yt-0.0.0: build Preprocessing library yt-0.0.0... [1 of 9] Compiling Settings ( Settings.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/Settings.o ) [2 of 9] Compiling Settings.StaticFiles ( Settings/StaticFiles.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/Settings/StaticFiles.o ) [3 of 9] Compiling Import.NoFoundation ( Import/NoFoundation.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/Import/NoFoundation.o ) [4 of 9] Compiling Foundation ( Foundation.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/Foundation.o ) [5 of 9] Compiling Import ( Import.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/Import.o ) [6 of 9] Compiling Handler.Common ( Handler/Common.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/Handler/Common.o ) [7 of 9] Compiling Handler.Home ( Handler/Home.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/Handler/Home.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): find_tycon Block [] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Completed 179 action(s). -- While building package yt-0.0.0 using: /home/jeiea/.stack/setup-exe-cache/x86_64-linux/setup-Simple- Cabal-1.24.0.0-ghc-8.0.1 --builddir=.stack- work/dist/x86_64-linux/Cabal-1.24.0.0 build lib:yt exe:yt --ghc-options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12130> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #12637: ghc-pkg: Allow unregistering multiple packages in one call
by GHC 05 Oct '16

05 Oct '16

#12637: ghc-pkg: Allow unregistering multiple packages in one call -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- This can save lots of time when the cost to invoke a single GHC command is high, for example through docker. An example user of this would be `stack build`, which will unregister all relevant packages if e.g. `--extra-lib-dirs` has changed. Currently it has to do that through multiple `ghc-pkg unregister` operations, which can take about 2 seconds per call when done through a docker image. If we could unregister multiple packages at once, such use cases would have to pay the 2 seconds penalty only once. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12637> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10163: Export typeRepKinds in Data.Typeable
by GHC 04 Oct '16

04 Oct '16

#10163: Export typeRepKinds in Data.Typeable -------------------------------------+------------------------------------- Reporter: | Owner: RyanGlScott | Status: new Type: feature | Milestone: request | Version: 7.10.1-rc3 Priority: normal | Operating System: Unknown/Multiple Component: | Type of failure: Other libraries/base | Blocked By: Keywords: | Related Tickets: Architecture: | Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Now that {{{TypeRep}}} has a {{{[KindRep]}}} field internally, {{{Data.Typeable}}} should export {{{typeRepKinds}}} (alongside {{{typeRepTyCon}}} and {{{typeRepArgs}}}, which are currently exported) to allow users to access it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10163> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11054: GHC on Windows could not use more than 64 logical processors
by GHC 04 Oct '16

04 Oct '16

#11054: GHC on Windows could not use more than 64 logical processors -------------------------------------+------------------------------------- Reporter: varosi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.10.2 System | Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I found that GHC runtime does not take advantage of processor groups under Windows. So it cannot use more than 64 logical processors (2x 18 core physical + HT). This is Reddit thread about: https://www.reddit.com/r/haskell/comments/3q1r0o/ghc_on_numa_72_core_2_proc… MSDN link https://msdn.microsoft.com/en- us/library/windows/desktop/dd405503(v=vs.85).aspx -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11054> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 48

[GHC] #12628: __GLASGOW_HASKELL_LLVM__ is no longer an Int
by GHC 03 Oct '16

03 Oct '16

#12628: __GLASGOW_HASKELL_LLVM__ is no longer an Int -------------------------------------+------------------------------------- Reporter: nicolast | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Driver | Version: 8.0.1 Keywords: llvm cpp | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- From the user guide (http://ghc.readthedocs.io/en/8.0.1/phases.html#index-8) {{{ __GLASGOW_HASKELL_LLVM__ Only defined when -fllvm is specified. When GHC is using version x.y.z of LLVM, the value of __GLASGOW_HASKELL_LLVM__ is the integer ⟨xy⟩. }}} This is not the case, though, due to 29310b622801733e1b29a9a61988406872db13ca which changes {{{figureLlvmVersion :: DynFlags -> IO (Maybe Int)}}} into {{{figureLlvmVersion :: DynFlags -> IO (Maybe (Int, Int))}}}, and the driver just {{{show}}}ing the result (https://github.com/ghc/ghc/blob/29310b622801733e1b29a9a61988406872db13ca/co…) As a result, the macro value which used to be a numeric value is now something like {{{(3, 7)}}}. I'm now using a work-around (https://github.com/NicolasT/reedsolomon/commit/9d25ad6a26a29c90b82daacbf406…) but ''or'' the 'tuple value' should become 'official API', ''or'' this is a regression to be fixed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12628> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #12593: ghci spins forever
by GHC 03 Oct '16

03 Oct '16

#12593: ghci spins forever -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- When run with {{{ ghci -ignore-dot-ghci -XRankNTypes -XTypeInType -XGADTs -XConstraintKinds t5AE.hs }}} the compiler spins -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12593> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #12614: Integer division can overwrite other arguments to foreign call
by GHC 02 Oct '16

02 Oct '16

#12614: Integer division can overwrite other arguments to foreign call -------------------------------------+------------------------------------- Reporter: jscholl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (NCG) | Keywords: integer | Operating System: Unknown/Multiple division | Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If you call a foreign function, GHC can generate incorrect code while passing the arguments to the function, overwriting the 3rd argument if a later argument contains an integer division. Main.hs: {{{ {-# LANGUAGE ForeignFunctionInterface #-} module Main where {-# NOINLINE foo #-} foo :: Int -> IO () foo x = c_foo 0 0 x $ x + x `quot` 10 foreign import ccall "foo" c_foo :: Int -> Int -> Int -> Int -> IO () main :: IO () main = do foo 202 foo 203 foo 204 }}} foo.c: {{{ #include <stdio.h> void foo(int a, int b, int c, int d) { printf("%d, %d, %d, %d\n", a, b, c, d); } }}} Expected output: {{{ 0, 0, 202, 222 0, 0, 203, 223 0, 0, 204, 224 }}} Actual output: {{{ 0, 0, 2, 222 0, 0, 3, 223 0, 0, 4, 224 }}} The bug has to be somewhere in the code generator. The cmm reads: {{{ call "ccall" arg hints: [‘signed’, ‘signed’, ‘signed’, ‘signed’] result hints: [] foo(0, 0, _s3nE::I64, _s3nE::I64 + %MO_S_Quot_W64(_s3nE::I64, 10)); }}} This generates the following assembler code: {{{ xorl %edi,%edi xorl %esi,%esi movq %rbx,%rdx movl $10,%ecx movq %rax,%rdx <-- move 3rd argument into rdx movq %rbx,%rax movq %rdx,%r8 cqto idivq %rcx <-- rax := rax / rcx; rdx := rax % rcx movq %rbx,%rcx addq %rax,%rcx subq $8,%rsp xorl %eax,%eax movq %r8,%rbx call foo }}} Thus rdx is overwritten again before the call, leading to incorrect results. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12614> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7