June 2016 - ghc-tickets

[GHC] #11715: There's something fishy going on with Constraint
by GHC 07 Mar '19

07 Mar '19

#11715: There's something fishy going on with Constraint -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 (Type checker) | 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 first noticed something was a bit odd with `Constraint` when chasing #11334. Consider this testcase, {{{#!hs import Data.Typeable main = do print $ typeRep (Proxy :: Proxy Eq) print $ typeOf (Proxy :: Proxy Eq) }}} With `ghc-8.0` this will produce, {{{ Eq Proxy (* -> *) Eq }}} Notice the second line; GHC seems to be claiming that `Eq :: * -> *`, which is clearly nonsense. I believe this issue may be the cause of some of the testsuite failures that I'm seeing on #11011. Unfortunately I haven't the foggiest where this issue might originate. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11715> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 82

[GHC] #12102: “Constraints in kinds” illegal family application in instance (+ documentation issues?)
by GHC 06 Mar '19

06 Mar '19

#12102: “Constraints in kinds” illegal family application in instance (+ documentation issues?) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC 8.0.0.20160511. Example from the user guide: [https://downloads.haskell.org/~ghc/8.0.1/docs/html/users_guide/glasgow_exts… #constraints-in-kinds Constraints in kinds] {{{#!hs type family IsTypeLit a where IsTypeLit Nat = 'True IsTypeLit Symbol = 'True IsTypeLit a = 'False data T :: forall a. (IsTypeLit a ~ 'True) => a -> * where MkNat :: T 42 MkSymbol :: T "Don't panic!" }}} Deriving a standalone `Show` instance *without* the constraint works fine {{{#!hs deriving instance Show (T a) }}} but I couldn't define a `Show` instance given the constraints: {{{#!hs -- • Couldn't match expected kind ‘'True’ -- with actual kind ‘IsTypeLit a0’ -- The type variable ‘a0’ is ambiguous -- • In the first argument of ‘Show’, namely ‘T a’ -- In the stand-alone deriving instance for ‘Show (T a)’ deriving instance Show (T a) }}} let's add constraints {{{#!hs -- • Couldn't match expected kind ‘'True’ -- with actual kind ‘IsTypeLit lit’ -- • In the first argument of ‘Show’, namely ‘T (a :: lit)’ -- In the instance declaration for ‘Show (T (a :: lit))’ instance IsTypeLit lit ~ 'True => Show (T (a :: lit)) where }}} let's derive for a single literal {{{#!hs -- • Illegal type synonym family application in instance: -- T Nat -- ('Data.Type.Equality.C:~ -- Bool -- (IsTypeLit Nat) -- 'True -- ('GHC.Types.Eq# Bool Bool (IsTypeLit Nat) 'True <>)) -- 42 -- • In the stand-alone deriving instance for ‘Show (T (42 :: Nat))’ deriving instance Show (T (42 :: Nat)) }}} same happens with {{{#!hs instance Show (T 42) where }}} ---- The documentation > Note that explicitly quantifying with `forall a` is not necessary here. seems to be wrong since removing it results in {{{ tVDv.hs:10:17-18: error: … • Expected kind ‘a’, but ‘42’ has kind ‘Nat’ • In the first argument of ‘T’, namely ‘42’ In the type ‘T 42’ In the definition of data constructor ‘MkNat’ Compilation failed. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12102> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #10892: ApplicativeDo should use *> and <*
by GHC 05 Mar '19

05 Mar '19

#10892: ApplicativeDo should use *> and <* -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- From @ekmett: Would it be possible to tweak the generation to use `(<*)` or `(*>)` where appropriate when the result isn't being used? For many Applicatives this can be a massive asymptotic win in terms of sharing and/or computational cost. When desugaring using (<*) you'd just omit any handling of the unused result instead. {{{ (\x y -> ...) <$> foo <* bar <*> baz }}} corresponds to {{{ do x <- foo bar y <- baz return ... }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10892> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 30

[GHC] #8657: -fregs-graph still has a limit on spill slots
by GHC 04 Mar '19

04 Mar '19

#8657: -fregs-graph still has a limit on spill slots -----------------------------------+--------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler (NCG) | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- The limit on spill slots was removed for the linear register allocator in 7.8, but not for `-fregs-graph`. SHA-1 fails to compile with `-fregs-graph` in 7.8. Related: #7679 (`-fregs-graph` generates poor code with the new codegen). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8657> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #11982: Typechecking fails for parallel monad comprehensions with polymorphic let
by GHC 04 Mar '19

04 Mar '19

#11982: Typechecking fails for parallel monad comprehensions with polymorphic let -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- {{{ {-# LANGUAGE MonadComprehensions, ParallelListComp #-} module Foo where foo xs ys = [ (f y True, f x 'c') | let f _ z = z, x <- xs | y <- ys ] }}} This fails with {{{ Foo.hs:5:52: error: * Cannot instantiate unification variable `t0' with a type involving foralls: forall t2 t3. t3 -> t2 -> t2 GHC doesn't yet support impredicative polymorphism * In a stmt of a monad comprehension: let f _ z = z, x <- xs | y <- ys In the expression: [(f y True, f x 'c') | let f _ z = z, x <- xs | y <- ys] In an equation for `foo': foo xs ys = [(f y True, f x 'c') | let f _ z = z, x <- xs | y <- ys] }}} NB: `ApplicativeDo` has a related problem: the implementation is quite different and has the effect of monomorphising the let-bound variable. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11982> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #9894: Presence of DWARF debug symbols doesn't result in working backtraces in GDB
by GHC 03 Mar '19

03 Mar '19

#9894: Presence of DWARF debug symbols doesn't result in working backtraces in GDB ----------------------------------+--------------------------------------- Reporter: tibbe | Owner: scpmw Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+--------------------------------------- Now when GHC can output DWARF debug symbols we need to take the remaining steps needed to get downstream tool like GDB to do something useful with it. As of today GDB cannot produce a valid stack trace for this code: {{{#!hs module Main where import System.IO f name = print $ "Hello, " ++ name {-# NOINLINE f #-} g name = f name {-# NOINLINE g #-} main = do name <- getLine g name }}} when a breakpoint is set on the line that defines `f` before the program is run. The resulting backtrace looks like: {{{ (gdb) bt #0 Main_f_info () at /tmp/Test.hs:5 #1 0x0000000000481a00 in ?? () Backtrace stopped: frame did not save the PC }}} This bug tracks the remaining work that needs to be done before this will work. Peter, what is the remaining work here? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9894> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9910: ghc's dwarf (-g) output does not like Unicode (Char.intToDigit: not a digit 136)
by GHC 03 Mar '19

03 Mar '19

#9910: ghc's dwarf (-g) output does not like Unicode (Char.intToDigit: not a digit 136) -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Easy to reproduce as: {{{ inplace/bin/ghc-stage2 -w -g -c testsuite/tests/parser/unicode/utf8_024.hs ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.9.20141219 for x86_64-unknown-linux): Char.intToDigit: not a digit 136 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} {{{ petermw> Yes, Unicode doesn't work with DWARF yet }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9910> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10236: DWARF unwind info is broken
by GHC 03 Mar '19

03 Mar '19

#10236: DWARF unwind info is broken -------------------------------------+------------------------------------- Reporter: | Owner: thoughtpolice | Status: new Type: bug | Milestone: 7.10.2 Priority: high | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple (Debugging) | Type of failure: Incorrect result Keywords: dwarf | at runtime Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D792 | -------------------------------------+------------------------------------- As reported by `bitonic` and `petermw` on `#ghc` (April 2nd): {{{ 07:02 < bitonic> I'm trying to get a meaningful backtrace with DWARF, using <https://ghc.haskell.org/trac/ghc/wiki/DWARF> as a guide. however, all I get is `Backtrace stopped: previous frame identical to this frame (corrupt stack?)` 07:03 < bitonic> I've re-built GHC 7.10.1 using `GhcRtsHcOpts += -g` and `GhcLibHcOpts += -g`, even if I'm not sure it's even necessary 07:04 < bitonic> are there any additional steps I should take? or any way to make sure that the binary I'm generating is sane? }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10236> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10915: Statistical profiling support in the RTS
by GHC 03 Mar '19

03 Mar '19

#10915: Statistical profiling support in the RTS -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: feature | Status: new request | Priority: normal | Milestone: 8.0.1 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): Phab:D1215, | Phab:D1214 | -------------------------------------+------------------------------------- Now since GHC can produce useful debugging information (e.g. DWARF annotations and source notes) in compiled objects, it would great if we could leverage this for more efficient profiling. While ideally we would be able to rely on external tools like `perf` for this task, this would require that the STG stack be walkable like a standard C stack. A more feasible alternative is to incorporate a simple statistical profiler into the RTS. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10915> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #11261: Implement DWARF debugging on powerpc64
by GHC 03 Mar '19

03 Mar '19

#11261: Implement DWARF debugging on powerpc64 -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.11 (CodeGen) | Keywords: | Operating System: Linux Architecture: powerpc64 | Type of failure: Incorrect result | at runtime Test Case: debug, T10667 | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- debug: {{{ ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.11.20151219 for powerpc64-unknown-linux): dwarfReturnRegNo: Unsupported platform! CallStack (from ImplicitParams): error, called at compiler/nativeGen/Dwarf/Constants.hs:224:19 in ghc:Dwarf.Constants Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Provide DWARF constants for registers. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11261> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12