November 2018 - ghc-tickets

[GHC] #14579: GeneralizedNewtypeDeriving produces ambiguously-kinded code
by GHC 04 Mar '19

04 Mar '19

#14579: GeneralizedNewtypeDeriving produces ambiguously-kinded code -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 (Type checker) | Keywords: deriving | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This program //should// compile: {{{#!hs {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind import Data.Proxy newtype Wat (x :: Proxy (a :: Type)) = MkWat (Maybe a) deriving Eq newtype Glurp a = MkGlurp (Wat ('Proxy :: Proxy a)) deriving Eq }}} After all, it //should// produce this `Eq (Glurp a)` instance, which compiles without issue: {{{#!hs instance Eq a => Eq (Glurp a) where (==) = coerce @(Wat ('Proxy :: Proxy a) -> Wat ('Proxy :: Proxy a) -> Bool) @(Glurp a -> Glurp a -> Bool) (==) }}} But despite my wishful thinking, GHC does not actually do this. In fact, the code that GHC tries to generate for an `Eq (Glurp a)` instance is completely wrong: {{{ $ /opt/ghc/8.2.2/bin/ghci -ddump-deriv Bug.hs GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) ==================== Derived instances ==================== Derived class instances: instance forall a (x :: Data.Proxy.Proxy a). GHC.Classes.Eq a => GHC.Classes.Eq (Bug.Wat x) where (GHC.Classes.==) = GHC.Prim.coerce @(GHC.Base.Maybe a_a2wE -> GHC.Base.Maybe a_a2wE -> GHC.Types.Bool) @(Bug.Wat x_a2wF -> Bug.Wat x_a2wF -> GHC.Types.Bool) (GHC.Classes.==) (GHC.Classes./=) = GHC.Prim.coerce @(GHC.Base.Maybe a_a2wE -> GHC.Base.Maybe a_a2wE -> GHC.Types.Bool) @(Bug.Wat x_a2wF -> Bug.Wat x_a2wF -> GHC.Types.Bool) (GHC.Classes./=) instance GHC.Classes.Eq a => GHC.Classes.Eq (Bug.Glurp a) where (GHC.Classes.==) = GHC.Prim.coerce @(Bug.Wat Data.Proxy.Proxy -> Bug.Wat Data.Proxy.Proxy -> GHC.Types.Bool) @(Bug.Glurp a_a1vT -> Bug.Glurp a_a1vT -> GHC.Types.Bool) (GHC.Classes.==) (GHC.Classes./=) = GHC.Prim.coerce @(Bug.Wat Data.Proxy.Proxy -> Bug.Wat Data.Proxy.Proxy -> GHC.Types.Bool) @(Bug.Glurp a_a1vT -> Bug.Glurp a_a1vT -> GHC.Types.Bool) (GHC.Classes./=) Derived type family instances: Bug.hs:12:12: error: • Couldn't match representation of type ‘a0’ with that of ‘a’ arising from a use of ‘GHC.Prim.coerce’ ‘a’ is a rigid type variable bound by the instance declaration at Bug.hs:12:12-13 • In the expression: GHC.Prim.coerce @(Wat Proxy -> Wat Proxy -> Bool) @(Glurp a -> Glurp a -> Bool) (==) In an equation for ‘==’: (==) = GHC.Prim.coerce @(Wat Proxy -> Wat Proxy -> Bool) @(Glurp a -> Glurp a -> Bool) (==) When typechecking the code for ‘==’ in a derived instance for ‘Eq (Glurp a)’: To see the code I am typechecking, use -ddump-deriv In the instance declaration for ‘Eq (Glurp a)’ • Relevant bindings include (==) :: Glurp a -> Glurp a -> Bool (bound at Bug.hs:12:12) | 12 | deriving Eq | ^^ Bug.hs:12:12: error: • Could not deduce (Eq a0) arising from a use of ‘==’ from the context: Eq a bound by the instance declaration at Bug.hs:12:12-13 The type variable ‘a0’ is ambiguous These potential instances exist: instance forall k (s :: k). Eq (Proxy s) -- Defined in ‘Data.Proxy’ instance Eq Ordering -- Defined in ‘GHC.Classes’ instance Eq Integer -- Defined in ‘integer-gmp-1.0.1.0:GHC.Integer.Type’ ...plus 25 others ...plus 9 instances involving out-of-scope types (use -fprint-potential-instances to see them all) • In the third argument of ‘GHC.Prim.coerce’, namely ‘(==)’ In the expression: GHC.Prim.coerce @(Wat Proxy -> Wat Proxy -> Bool) @(Glurp a -> Glurp a -> Bool) (==) In an equation for ‘==’: (==) = GHC.Prim.coerce @(Wat Proxy -> Wat Proxy -> Bool) @(Glurp a -> Glurp a -> Bool) (==) When typechecking the code for ‘==’ in a derived instance for ‘Eq (Glurp a)’: To see the code I am typechecking, use -ddump-deriv | 12 | deriving Eq | ^^ Bug.hs:12:12: error: • Couldn't match representation of type ‘a1’ with that of ‘a’ arising from a use of ‘GHC.Prim.coerce’ ‘a’ is a rigid type variable bound by the instance declaration at Bug.hs:12:12-13 • In the expression: GHC.Prim.coerce @(Wat Proxy -> Wat Proxy -> Bool) @(Glurp a -> Glurp a -> Bool) (/=) In an equation for ‘/=’: (/=) = GHC.Prim.coerce @(Wat Proxy -> Wat Proxy -> Bool) @(Glurp a -> Glurp a -> Bool) (/=) When typechecking the code for ‘/=’ in a derived instance for ‘Eq (Glurp a)’: To see the code I am typechecking, use -ddump-deriv In the instance declaration for ‘Eq (Glurp a)’ • Relevant bindings include (/=) :: Glurp a -> Glurp a -> Bool (bound at Bug.hs:12:12) | 12 | deriving Eq | ^^ Bug.hs:12:12: error: • Could not deduce (Eq a1) arising from a use of ‘/=’ from the context: Eq a bound by the instance declaration at Bug.hs:12:12-13 The type variable ‘a1’ is ambiguous These potential instances exist: instance forall k (s :: k). Eq (Proxy s) -- Defined in ‘Data.Proxy’ instance Eq Ordering -- Defined in ‘GHC.Classes’ instance Eq Integer -- Defined in ‘integer-gmp-1.0.1.0:GHC.Integer.Type’ ...plus 25 others ...plus 9 instances involving out-of-scope types (use -fprint-potential-instances to see them all) • In the third argument of ‘GHC.Prim.coerce’, namely ‘(/=)’ In the expression: GHC.Prim.coerce @(Wat Proxy -> Wat Proxy -> Bool) @(Glurp a -> Glurp a -> Bool) (/=) In an equation for ‘/=’: (/=) = GHC.Prim.coerce @(Wat Proxy -> Wat Proxy -> Bool) @(Glurp a -> Glurp a -> Bool) (/=) When typechecking the code for ‘/=’ in a derived instance for ‘Eq (Glurp a)’: To see the code I am typechecking, use -ddump-deriv | 12 | deriving Eq | ^^ }}} Yikes. To see what went wrong, let's zoom in a particular part of the `-ddump-deriv` output (cleaned up a bit for presentation purposes): {{{#!hs instance Eq a => Eq (Glurp a) where (==) = coerce @(Wat 'Proxy -> Wat 'Proxy -> Bool) @(Glurp a -> Glurp a -> Bool) (==) }}} Notice that it's `Wat 'Proxy`, and not `Wat ('Proxy :: Proxy a)`! And no, that's not just a result of GHC omitting the kind information—you will see the exact same thing if you compile with `-fprint-explicit-kinds`. What's going on here? As it turns out, the types inside of those visible type applications aren't `Type`s, but rather `HsType GhcRn`s (i.e., source syntax). So what is happening is that GHC is literally producing `@(Wat 'Proxy -> Wat 'Proxy -> Bool)` //as source syntax//, not as a `Type`. This means that `'Proxy` has an underspecified kind, resulting in the numerous `The type variable ‘a0’ is ambiguous` errors you see above. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14579> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 27

[GHC] #14078: -ddump-json doesn't work well with GHCi
by GHC 04 Mar '19

04 Mar '19

#14078: -ddump-json doesn't work well with GHCi -------------------------------------+------------------------------------- Reporter: dramforever | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.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: -------------------------------------+------------------------------------- Currently, `:set -ddump-json` in `GHCi` causes all errors to be gathered to be written out on exit. `ghci -ddump-json` is even worse, only resulting in a `[]` being output on exit. However, I believe this completely defeats the purpose of this flag in GHCi. I expect `ghci -ddump-json` to work like this: for _each_ evaluation typed at the GHCi prompt, one JSON array is output for all messages this evaluation caused. This proposed behavior is consistent with other flags like `-ddump-simpl`, and will allow tooling to interact with GHCi nicely. Reporting this as a bug because this looks half-supported rather than unsupported, and also because of the different behaviors of `ghci -ddump- json` and `:set -ddump-json`. Sorry if it was not warranted. == Steps to reproduce `cmd>` is the shell prompt. {{{#!hs cmd> ghc --version The Glorious Glasgow Haskell Compilation System, version 8.2.1 cmd> type tmp.hs main = print 2 + 2 cmd> ghci -ddump-json tmp.hs GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( tmp.hs, interpreted ) tmp.hs:1:8: error: ? No instance for (Num (IO ())) arising from a use of ‘+’ ? In the expression: print 2 + 2 In an equation for ‘main’: main = print 2 + 2 | 1 | main = print 2 + 2 | ^^^^^^^^^^^ Failed, 0 modules loaded. Prelude> :q Leaving GHCi. [] cmd> ghci GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Prelude> :set -ddump-json Prelude> :l tmp.hs [1 of 1] Compiling Main ( tmp.hs, interpreted ) tmp.hs:1:8: error: ? No instance for (Num (IO ())) arising from a use of ‘+’ ? In the expression: print 2 + 2 In an equation for ‘main’: main = print 2 + 2 | 1 | main = print 2 + 2 | ^^^^^^^^^^^ Failed, 0 modules loaded. Prelude> :q Leaving GHCi. [ {"span": {"file": "tmp.hs","startLine": 1,"startCol": 8,"endLine": 1,"endCol": 19},"doc": "\u2022 No instance for (Num (IO ())) arising from a use of \u2018+\u2019\n\u2022 In the expression: print 2 + 2\n In an equation for \u2018main\u2019: main = print 2 + 2","severity": "SevError","reason": null}, {"span": null,"doc": "[1 of 1] Compiling Main ( tmp.hs, interpreted )","severity": "SevOutput","reason": null}] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14078> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #15729: Static GHCi can segfault when accessing .bss section in C
by GHC 04 Mar '19

04 Mar '19

#15729: Static GHCi can segfault when accessing .bss section in C --------------------------------------+------------------------------- Reporter: watashi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.6.1 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+------------------------------- When an object file is statically linked, GHCi can return junk or segfault when trying to access data defined in .bss section via foreign call. {{{ watashi % ~/gao/ghc/inplace/bin/ghc-stage2 --info | grep Dynamic ,("Dynamic by default","NO") ,("GHC Dynamic","NO") watashi % cat bss.c int read_bss(int i) { static int bss[1 << 20]; return bss[i]; } watashi % ~/gao/ghc/inplace/bin/ghc-stage2 --interactive test.o GHCi, version 8.7.20180920: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/watashi/.ghci Prelude> :m + Foreign Foreign.C Prelude Foreign Foreign.C> foreign import ccall unsafe "read_bss" read_bss :: Int -> IO Int Prelude Foreign Foreign.C> read_bss 0 4294059519 Prelude Foreign Foreign.C> read_bss 1 65535 Prelude Foreign Foreign.C> mapM (read_bss . bit) [0 .. 19] zsh: segmentation fault (core dumped) ~/gao/ghc/inplace/bin/ghc-stage2 --interactive test.o }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15729> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #15723: -prof -fPIC -fexternal-dynamic-refs generates non-PIC relocations for external symbol
by GHC 04 Mar '19

04 Mar '19

#15723: -prof -fPIC -fexternal-dynamic-refs generates non-PIC relocations for external symbol -------------------------------------+------------------------------------- Reporter: watashi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 (CodeGen) | Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When compiling code with `-prof -fPIC -fexternal-dynamic-refs`, the generated object file may contains R_X86_64_PC32 relocation to symbols defined in another object file. will add more details -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15723> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #15593: QuantifiedConstraints: trouble with type family
by GHC 04 Mar '19

04 Mar '19

#15593: QuantifiedConstraints: trouble with type family -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Keywords: | Operating System: Unknown/Multiple QuantifiedConstraints, | ConstraintKinds | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# Language KindSignatures, TypeFamilies, QuantifiedConstraints, FlexibleInstances #-} import Data.Kind data TreeF a b = T0 | T1 a | T2 b b -- from Data.Reify class MuRef (a :: Type) where type DeRef a :: Type -> Type class (forall xx. DeRef (tree xx) ~ TreeF xx) => MuRef1 tree instance (forall xx. DeRef (tree xx) ~ TreeF xx) => MuRef1 tree }}} fails with {{{ $ ~/code/qc-ghc/inplace/bin/ghc-stage2 --interactive -ignore-dot-ghci 351.hs GHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( 351.hs, interpreted ) 351.hs:12:10: error: • Couldn't match type ‘DeRef (tree xx)’ with ‘TreeF xx’ arising from the superclasses of an instance declaration • In the instance declaration for ‘MuRef1 tree’ | 12 | instance (forall xx. DeRef (tree xx) ~ TreeF xx) => MuRef1 tree | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Failed, no modules loaded. Prelude> }}} ---- What I want to write: {{{#!hs {-# Language KindSignatures, TypeFamilies, QuantifiedConstraints, FlexibleInstances, DataKinds, TypeInType, MultiParamTypeClasses, UndecidableInstances, AllowAmbiguousTypes #-} import Data.Kind -- from Data.Reify class MuRef (a :: Type) where type DeRef a :: Type -> Type type T = Type type TT = T -> T type TTT = T -> TT class (forall xx. (MuRef (f xx), DeRef (f xx) ~ deRef1 f xx)) => MuRef1 (f :: TT) (deRef1 :: TT -> TTT) instance (forall xx. (MuRef (f xx), DeRef (f xx) ~ deRef1 f xx)) => MuRef1 (f :: TT) (deRef1 :: TT -> TTT) }}} where I am trying to capture [https://hackage.haskell.org/package/folds-0.7.4/docs/src/Data-Fold- Internal.html MuRef1 & DeRef1] {{{#!hs class MuRef1 (f :: TT) where type DeRef1 f :: TTT muRef1 :: proxy (f a) -> Dict (MuRef (f a), DeRef (f a) ~ DeRef1 f a) }}} ---- Workarounds: I think splitting the class alias & quantification does the job (I haven't tested it but it compiles), I want to know if the first two programs are meant to compile or not {{{#!hs {-# Language KindSignatures, TypeFamilies, QuantifiedConstraints, FlexibleInstances, DataKinds, TypeInType, MultiParamTypeClasses, UndecidableInstances, AllowAmbiguousTypes, FlexibleContexts #-} -- .. class (MuRef (f xx), DeRef (f xx) ~ deRef1 f xx) => MuRef1_ f deRef1 xx instance (MuRef (f xx), DeRef (f xx) ~ deRef1 f xx) => MuRef1_ f deRef1 xx class (forall xx. cls xx) => Forall cls instance (forall xx. cls xx) => Forall cls class Forall (MuRef1_ f deRef1) => MuRef1 f deRef1 instance Forall (MuRef1_ f deRef1) => MuRef1 f deRef1 }}} or as a regular type/constraint synonym (at the loss of partial application) {{{#!hs type MuRef1 f deRef1 = (forall xx. (MuRef (f xx), DeRef (f xx) ~ deRef1 f xx)) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15593> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15853: Unregisterised GHC panics when building test cgrun018
by GHC 04 Mar '19

04 Mar '19

#15853: Unregisterised GHC panics when building test cgrun018 -------------------------------------+------------------------------------- Reporter: iliastsi | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.4.3 (CodeGen) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: cgrun018 | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- An unregisterised ghc-8.4 on amd64 panics when building test cgrun018. {{{ Compile failed (exit code 1) errors were: [1 of 1] Compiling Main ( cgrun018.hs, cgrun018.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.4.4 for x86_64-unknown-linux): pprStatics: float F32 F32 F32 F32 F32 F32 F32 F32 F32 F32 F32 Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/cmm/PprC.hs:525:5 in ghc:PprC }}} We have seen this error while building packages for Debian on 64-bit architectures where GHC is unregisterised (e.g., mips64el, s390x): [https://buildd.debian.org/status/fetch.php?pkg=haskell- gloss&arch=mips64el&ver=1.13.0.1-1&stamp=1540810998&raw=0 gloss on mips64el], [https://buildd.debian.org/status/fetch.php?pkg=haskell- juicypixels&arch=s390x&ver=3.2.9.5-3&stamp=1540808360&raw=0 juicypixels on s390x] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15853> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15960: Using -g causes differences in generated core.
by GHC 03 Mar '19

03 Mar '19

#15960: Using -g causes differences in generated core. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 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: -------------------------------------+------------------------------------- For nofib/shootout/fannkuch-redux: Normal results {{{ > /e/ghc-8.6.1/bin/ghc.exe Main.hs -O2 -XBangPatterns -fforce-recomp -ddump-simpl -dsuppress-all -dsuppress-uniques | less ... Result size of Tidy Core = {terms: 2,747, types: 2,736, coercions: 100, joins: 50/73} ... }}} {{{ > /e/ghc-8.6.1/bin/ghc.exe Main.hs -O2 -XBangPatterns -fforce-recomp -ddump-simpl -dsuppress-all -dsuppress-uniques -g | less ... Result size of Tidy Core = {terms: 2,654, types: 2,557, coercions: 100, joins: 38/71} ... }}} There are also structural differences in the generated code. I've hit the issue with a tree based on head as well so likely happening there as well. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15960> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[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