March 2018 - ghc-tickets

[GHC] #14468: Why does alanz's branch blow up GHC's heap?
by GHC 19 Mar '18

19 Mar '18

#14468: Why does alanz's branch blow up GHC's heap? -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | 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: -------------------------------------+------------------------------------- alanz mentioned that moving all of GHC's `Data` instances [[https://git.haskell.org/ghc.git/blob/12028239b597e17fb3f3734c6b494e127be58e…]] to a new module causes the stage1 compile to run out of memory during compilation (he has 8 GB of memory). This is rather suspicious as this module isn't terribly large. IIRC typechecking time may be non-linear in program size, but I don't see why it would be non-linear in space. Investigate. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14468> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11382: Optimize Data.Char
by GHC 19 Mar '18

19 Mar '18

#11382: Optimize Data.Char -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Core | Version: 7.10.3 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Many of the predicates in `Data.Char` do full Unicode category lookups which turns out to be quite expensive. Ideally we would handle some of the more common ASCII characters with cheaper tests before falling back to the full Unicode treatment. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11382> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #11260: Re-compilation tests fail on powerpc64
by GHC 19 Mar '18

19 Mar '18

#11260: Re-compilation tests fail on powerpc64 -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: Linux Architecture: powerpc64 | Type of failure: Compile-time | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- recomp011: {{{ [1 of 1] Compiling Main ( Main.hs, Main.o ) [A.hsinc changed] Linking Main ... 4343 +Linking Main ... 4343 }}} recomp015: {{{ [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... Running main... +Linking Main ... Running main... }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11260> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11495: TH_spliceE5_prof is failing with release candidate 8.0.1
by GHC 19 Mar '18

19 Mar '18

#11495: TH_spliceE5_prof is failing with release candidate 8.0.1 -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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: -------------------------------------+------------------------------------- `TH_spliceE5_prof` looks like this: {{{ TH_spliceE5_prof:: $(RM) TH_spliceE5_prof*.o TH_spliceE5_prof*.hi TH_spliceE5_prof*.dyn_o TH_spliceE5_prof*.dyn_hi TH_spliceE5_prof '$(TEST_HC)' $(TEST_HC_OPTS) $(HC_OPTS) $(ghcThWayFlags) --make -v0 TH_spliceE5_prof.hs -c '$(TEST_HC)' $(TEST_HC_OPTS) $(HC_OPTS) --make -v0 TH_spliceE5_prof.hs -prof -auto-all -osuf .p.o -o $@ ./$@ }}} In 4905b83a2d448c65ccced385343d4e8124548a3b, Simon added that `$(ghcThWayFlags)` to the first compilation command. With a release compiler, `ghcThWayFlags` defaults to `-dynamic`. But compiling with `-dynamic` doesn't produce `.dyn_o` files (you need `-dynamic-too` for that, which is enabled by `-XTemplateHaskell`, but **not** when compiling with `-dynamic`), so the second compilation results in: {{{ TH_spliceE5_prof.hs:8:17: fatal: cannot find object file ‘./TH_spliceE5_prof_Lib.dyn_o’ while linking an interpreted expression make[1]: *** [TH_spliceE5_prof] Error 1 *** unexpected failure for TH_spliceE5_prof(normal) }}} Not passing `-dynamic` fixes the test. But in the function `failNonStd` in `compiler/ghci/Linker.hs` Simon suggests that passing `-dynamic`: {{{ Cannot load -prof objects when GHC is built with -dynamic To fix this, either: (1) Use -fexternal-interprter, or (2) Build the program twice: once with -dynamic, and then with -prof using -osuf to set a different object file suffix. }}} Some ideas for a solution: * change that message to not mention `-dynamic` * always turn on `-dynamic-too` when `-XTemplateHaskell` is on, also when using `-dynamic` * find the place where `.dyn_o` is expected, and teach it that `.o` might also be ok. * make `-fexternal-interpreter` the default. Delete the test and a whole bunch of other stuff. It's all such a mess. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11495> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #11827: InteractiveEval error handling gets a boot ModSummary instead of normal ModSummary
by GHC 19 Mar '18

19 Mar '18

#11827: InteractiveEval error handling gets a boot ModSummary instead of normal ModSummary -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc3 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: -------------------------------------+------------------------------------- Given: A.hs {{{#!hs module A where data A = A f :: A -> Bool f C = False }}} A.hs-boot {{{#!hs module A where data A f :: A -> Bool }}} B.hs {{{#!hs module B where import {-# SOURCE #-} A data B = B A g :: B -> Bool g (B a) = f a }}} ghci reports: {{{ $ ghci B.hs GHCi, version 8.0.0.20160411: http://www.haskell.org/ghc/ :? for help [1 of 3] Compiling A[boot] ( A.hs-boot, interpreted ) [2 of 3] Compiling A ( A.hs, interpreted ) A.hs:6:3: error: Not in scope: data constructor ‘C’ *** Exception: expectJust showModule CallStack (from HasCallStack): error, called at compiler/utils/Maybes.hs:48:27 in ghc:Maybes > }}} So instead of a normal error telling me that the C constructor does not exist, I get an additional exception from expectJust because something went wrong in GHCs internal error reporting routine. Looking at https://github.com/ghc/ghc/blob/master/compiler/main/InteractiveEval.hs#L956, the expectJust exception is due to the fact that while reporting an error about A.hs, GHCi somehow got a hold of the ModSummary of A.hs-boot instead of A.hs -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11827> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #11773: linux/powepc : ghc-stage1 segfaults when building unregisterised
by GHC 19 Mar '18

19 Mar '18

#11773: linux/powepc : ghc-stage1 segfaults when building unregisterised --------------------------------+---------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: powerpc | Type of failure: Building GHC failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+---------------------------------------- Building unregisterised to test code paths that don't get tested in the registerised compile mode. The segfault: {{{ "inplace/bin/ghc-stage1" -static -O -H64m -Wall -Iincludes -Iincludes/dist \ -Iincludes/dist-derivedconstants/header -Iincludes/dist- ghcconstants/header \ -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -optc-DNOSMP \ -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen \ -Irts/dist/build -Irts/dist/build/autogen -O2 -Wnoncanonical-monad- instances \ -c rts/StgStartup.cmm -o rts/dist/build/StgStartup.o }}} seems to occur on powerpc, but not on x86_64 or armhf. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11773> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11765: Allow documentary type signatures
by GHC 19 Mar '18

19 Mar '18

#11765: Allow documentary type signatures -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 (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: -------------------------------------+------------------------------------- In some cases (e.g., `lens`) it's useful to document a binding with a more specific type signature than the true one, to show a useful special case. Unfortunately, this documentation can potentially be wrong or go out of date. I'd like to propose a pragma for this: {{{#!hs {-# Documentary #-} f :: T -> U }}} would ask the type checker to verify that `f :: T -> U`. Specifically, it would have the effect of creating and type checking, but then discarding, a hidden binding {{{#!hs f_doc :: T -> U f_doc t = f t }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11765> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13690: Running profiling tests in the GHCi way is extremely slow
by GHC 19 Mar '18

19 Mar '18

#13690: Running profiling tests in the GHCi way is extremely slow -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Running, e.g., `profinline001` in the GHCi way takes somewhere around eleven seconds. This seems pretty extreme. I noticed this when writing T12962 in the as-yet-unmerged Phab:D3550, which takes about the same amount of time. These are very small and very simple bits of code that don't do much at all, so it seems the problem must lie elsewhere. I have no idea where, though. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13690> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12712: break011 is broken on Windows
by GHC 19 Mar '18

19 Mar '18

#12712: break011 is broken on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: break011 | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The `break011` testcase fails on Windows with some unexpected differences in stdout. {{{ +++ ./ghci.debugger/scripts/break011.run/break011.run.stdout.normalised 2016-10-16 01:57:26.489544400 +0000 @@ -51,6 +51,9 @@ "foo" "CallStack (from HasCallStack): error, called at Test7.hs:<line>:<column> in <package-id>:Main") -*** Exception: foo -CallStack (from HasCallStack): - error, called at Test7.hs:<line>:<column> in <package-id>:Main +Stopped in <exception thrown>, <unknown> +_exception :: e = SomeException + (ErrorCallWithLocation + "foo" + "CallStack (from HasCallStack): + error, called at Test7.hs:<line>:<column> in <package-id>:Main") }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12712> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13443: Typeclass resolution errors quite puzzling
by GHC 19 Mar '18

19 Mar '18

#13443: Typeclass resolution errors quite puzzling -------------------------------------+------------------------------------- Reporter: tomjaguarpaw | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (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: -------------------------------------+------------------------------------- This ticket is based on a post I made to haskell-cafe: https://mail.haskell.org/pipermail/haskell-cafe/2016-August/124622.html Here's a program with an odd error message (GHC 8.0.1): {{{ data A a = A a deriving Eq data B = B main :: IO () main = print (A B == A B) test/main.hs:5:15: error: • No instance for (Eq B) arising from a use of ‘==’ • In the first argument of ‘print’, namely ‘(A B == A B)’ In the expression: print (A B == A B) In an equation for ‘main’: main = print (A B == A B) }}} I get an error about `Eq B` even though it's `Eq A` that is manifestly required at the call site. This error is odder when `A` and `B` are defined far away from the use of `==`. This is even odder: {{{ data A a = A a data B = B instance Ord a => Eq (A a) where main :: IO () main = print (A B == A B) test/main.hs:7:15: error: • No instance for (Ord B) arising from a use of ‘==’ • In the first argument of ‘print’, namely ‘(A B == A B)’ In the expression: print (A B == A B) In an equation for ‘main’: main = print (A B == A B) }}} Now not only is the type puzzling (`B` instead of `A`) but the *class* is puzzling (`Ord` instead of `Eq`). This occurred to me in practice because `Data.Graph.Inductive.PatriciaTree.Gr` has `(Eq a, Ord b) => Eq (Gr a b)`. It would have been a lot more helpful to see {{{ * No instance for (Ord B) * arising from (Eq A) * arising from the use of '==' }}} Does anyone agree with me that GHC should produce the full trace when it fails to resolve instances rather than just the proximal failure? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13443> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2