April 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] #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 04 Mar '19

04 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 04 Mar '19

04 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 04 Mar '19

04 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 04 Mar '19

04 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 04 Mar '19

04 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

[GHC] #11337: Unwind information incorrect between Sp adjustment and end of block
by GHC 04 Mar '19

04 Mar '19

#11337: Unwind information incorrect between Sp adjustment and end of block -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (CodeGen) | 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: -------------------------------------+------------------------------------- As pointed out in Phab:D1532, the DWARF unwinding information that we produce is currently a bit oversimplified. Namely, we produce exactly one unwind table per Cmm block. This works reasonably well in most cases since we most Cmm blocks have the form, {{{ aProcedure() { casl: -- we just entered the procedure, so the unwinding is trivial. unwind Sp = Sp -- we push some values onto the stack... I64[Sp - 16] = ... I64[Sp - 8] = ... -- and before leaving the block we update Sp. Sp = Sp - 16; -- technically our unwind information is now a lie call aFunction() returns to casd; casd: -- we inherit the unwind information from the state of the stack when we -- left the preceding block (casl) unwind Sp = Sp + 16 R2 = I64[Sp + 8]; -- pop off that which we pushed Sp = Sp + 16; call GHC.List.$wunsafeTake_info(R3, R2) args: 8, res: 0, upd: 8; }}} Here there is a narrow window where our unwind information is technically wrong: between updating `Sp` in `casl` and calling into `aFunction`. Note that after we arrive in `aFunction` we are safe, since our return address is `casd`, which has the correct unwinding information. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11337> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10