August 2018 - ghc-tickets

[GHC] #15587: traceEvent tests failing in slow validate
by GHC 06 Sep '18

06 Sep '18

#15587: traceEvent tests failing in slow validate -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Test Suite | Version: 8.5 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D5119 | Wiki Page: -------------------------------------+------------------------------------- traceEvent tests are failing in slow validate when testing in GHCi way: {{{ =====> traceEvent(ghci) 1 of 2 [0, 0, 0] cd "rts/traceEvent.run" && "/home/omer/haskell/ghc/inplace/test spaces /ghc-stage2" traceEvent.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output --interactive -v0 -ignore-dot-ghci -fno-ghci-history +RTS -I0.1 -RTS -eventlog< traceEvent.genscript Actual stderr output differs from expected: diff -uw "rts/traceEvent.run/traceEvent.stderr.normalised" "rts/traceEvent.run/traceEvent.run.stderr.normalised" --- rts/traceEvent.run/traceEvent.stderr.normalised 2018-08-31 12:48:13.548375420 +0300 +++ rts/traceEvent.run/traceEvent.run.stderr.normalised 2018-08-31 12:48:13.548375420 +0300 @@ -1 +0,0 @@ -traceEvent: Event size exceeds EVENT_PAYLOAD_SIZE_MAX, bail out *** unexpected failure for traceEvent(ghci) =====> traceBinaryEvent(ghci) 2 of 2 [0, 1, 0] cd "rts/traceBinaryEvent.run" && "/home/omer/haskell/ghc/inplace/test spaces/ghc-stage2" traceBinaryEvent.hs -dcore-lint -dcmm-lint -no-user- package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output --interactive -v0 -ignore-dot-ghci -fno-ghci-history +RTS -I0.1 -RTS -eventlog< traceBinaryEvent.genscript Actual stderr output differs from expected: diff -uw "rts/traceBinaryEvent.run/traceBinaryEvent.stderr.normalised" "rts/traceBinaryEvent.run/traceBinaryEvent.run.stderr.normalised" --- rts/traceBinaryEvent.run/traceBinaryEvent.stderr.normalised 2018-08-31 12:48:13.712373185 +0300 +++ rts/traceBinaryEvent.run/traceBinaryEvent.run.stderr.normalised 2018-08-31 12:48:13.712373185 +0300 @@ -1 +0,0 @@ -traceBinaryEvent: Event size exceeds EVENT_PAYLOAD_SIZE_MAX, bail out *** unexpected failure for traceBinaryEvent(ghci) Unexpected results from: TEST="traceBinaryEvent traceEvent" }}} I think GHCi doesn't generate eventlogs so there's no way to make these pass. I submitted Phab:D5119 to skip these tests in GHCi way. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15587> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15345: Duplication between `CoreSubst` and `SimplEnv` is very unfortunate
by GHC 06 Sep '18

06 Sep '18

#15345: Duplication between `CoreSubst` and `SimplEnv` is very unfortunate -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- There are lots of very similar functions in `SimplEnv` and `CoreSubst`. For example, in `SimpleEnv` there is a function `substIdType` and likewise in `CoreSubst` but they are different to each other. There is also a `substIdBndr` function in both modules but the one in `SimplEnv` calls `SimpleEnv.substIdType`, the one in `CoreSubst` doesn't call `CoreSubst.substIdType` but has its own inlined version. This means there's at least three different versions of `substIdType` floating around. The correctness of this function is crucial so it would be better not to duplicate it. Can we remove this duplication? Help me Simon! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15345> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15384: Every implication should bump the TcLevel exactly once
by GHC 06 Sep '18

06 Sep '18

#15384: Every implication should bump the TcLevel exactly once -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 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: -------------------------------------+------------------------------------- Simon recently added an assertion that every implication bumps the TcLevel exactly once. However, this turns out not to be true, and thus caused quite a few failures in a `DEBUG` compiler. I commented the check out, but we really should investigate and fix any deviations from this plan. Here is the suspect code in TcSimplify: {{{ -- Though sensible, this check causes lots of testsuite failures. It is -- remaining commented out for now. {- check_tc_level = do { cur_lvl <- TcS.getTcLevel ; MASSERT2( tclvl == pushTcLevel cur_lvl , text "Cur lvl =" <+> ppr cur_lvl $$ text "Imp lvl =" <+> ppr tclvl ) } -} }}} The goal is to uncomment this region without introducing failures. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15384> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #14915: T2783 fails with the threaded1 way
by GHC 06 Sep '18

06 Sep '18

#14915: T2783 fails with the threaded1 way --------------------------------------+---------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.5 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Runtime crash Test Case: T2783 | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------------- When running `./validate --slow` the other day, I saw the XXX test failing with the `threaded1` way. Instead of detecting the loop and aborting with an informative message, we get an assertion failure in the `rts/ThreadPaused.c:threadPaused` function. The program: {{{#!hs main = print $ do x <- [ 0 .. 5 ] ; let { y = 5 - y } ; return y }}} The output: {{{ =====> T2783(threaded1) 1 of 1 [0, 0, 0] cd "./rts/T2783.run" && "/home/alp/ghc/inplace/test spaces/ghc-stage2" -o T2783 T2783.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics- color=never -fno-diagnostics-show-caret -dno-debug-output -threaded -debug cd "./rts/T2783.run" && ./T2783 Wrong exit code for T2783(threaded1)(expected 1 , actual 134 ) Stderr ( T2783 ): T2783: internal error: ASSERTION FAILED: file rts/ThreadPaused.c, line 314 (GHC version 8.5.20180306 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) *** unexpected failure for T2783(threaded1) }}} The code for the corresponding assertion: {{{#!c // We should never have made it here in the event of blackholes that // we already own; they should have been marked when we blackholed // them and consequently we should have stopped our stack walk // above. ASSERT(!((bh_info == &stg_BLACKHOLE_info) && (((StgInd*)bh)->indirectee == (StgClosure*)tso))); }}} This seems to be an actual problem, hence this ticket. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14915> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #15445: SPCIALIZE one of two identical functions does not fire well
by GHC 05 Sep '18

05 Sep '18

#15445: SPCIALIZE one of two identical functions does not fire well --------------------------------------+--------------------------------- Reporter: nobrakal | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- Hi, I am playing with `SPECIALIZE` pragma: {{{#!hs module Todo where {-# SPECIALIZE plusTwoRec :: [Int] -> [Int] #-} plusTwoRec :: Num a => [a] -> [a] plusTwoRec [] = [] plusTwoRec (x:xs) = x+2:plusTwoRec xs plusTwoRec' :: Num a => [a] -> [a] plusTwoRec' [] = [] plusTwoRec' (x:xs) = x+2:plusTwoRec' xs }}} And wanted to benchmark it with (in `Main.hs`): {{{#!hs import Todo import Criterion.Main aListOfInt :: [Int] aListOfInt = [1..10000] main :: IO () main = defaultMain [ bench "plusTwoRec" $ nf plusTwoRec aListOfInt , bench "plusTwoRec'" $ nf plusTwoRec' aListOfInt ] }}} Sadly, the rule of specialization of `plusTwoRec` does not fire in Main.hs (I compiled with: `ghc Main.hs -O -dynamic -ddump-rule-firings` (the `-dynamic` part is due to my ArchLinux installaltion)). The result is: {{{ [1 of 2] Compiling Todo ( Todo.hs, Todo.o ) Rule fired: Class op + (BUILTIN) Rule fired: Class op fromInteger (BUILTIN) Rule fired: integerToInt (BUILTIN) Rule fired: SPEC plusTwoRec (Todo) [2 of 2] Compiling Main ( Main.hs, Main.o ) Rule fired: Class op enumFromTo (BUILTIN) Rule fired: unpack (GHC.Base) Rule fired: unpack (GHC.Base) Rule fired: eftIntList (GHC.Enum) Rule fired: unpack-list (GHC.Base) Rule fired: unpack-list (GHC.Base) Linking Main ... }}} I have inspected a bit the code produced after the simplifications passes (with `-ddump-simpl`) and here is the suspicious part: {{{ plusTwoRec :: forall a. Num a => [a] -> [a] [GblId, Arity=2, Caf=NoCafRefs, Str=<L,U(C(C1(U)),A,A,A,A,A,C(U))><S,1*U>, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=0,unsat_ok=True,boring_ok=True)}] plusTwoRec = plusTwoRec' }}} I believe that `plusTwoRec` is inlined before the specialization has a chance to fire, but I am not sure at all ! Separating the two functions definitions in two different files works. So I don't know if this is a GHC bug, myself that does not read the right part of the GHC manual, if it is only a lack of documentation, or anything else. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15445> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #15576: Hadrian puts its build tree in the wrong place
by GHC 05 Sep '18

05 Sep '18

#15576: Hadrian puts its build tree in the wrong place -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- I have a source tree in my slow, network-mounted backed-up filestore `/home/simonpj/ghc`, and a separate link-tree in my fast, physically- connected, non-backed up filestore `/playpen/ghc`. Every file in `/playpen/ghc` is a symlink to the corresponding source file in `/home/simonpj/ghc`. But when I do {{{ $ cd /playpen/ghc $ hadrian/build.sh -c -j4 --flavour=quick }}} I find a new `_build` director in `/home/simonpj/ghc`. This is bad! It should be in `/playpen/ghc`. Otherwise (a) it's slower, (b) it creates backup churn and (c) as it happens, I ran out of space on the backed-up filestore. Can this be fixed? It's a bad Hadrian shortcoming. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15576> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #15526: Explain or remove mystery import in Unsafe.Coerce
by GHC 05 Sep '18

05 Sep '18

#15526: Explain or remove mystery import in Unsafe.Coerce -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Core | Version: 8.4.3 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `Unsafe.Coerce` has the line {{{#!hs import GHC.Integer () -- for build ordering }}} It is not at all clear to me why build ordering demands that `GHC.Integer` be compiled before `Unsafe.Coerce` when the latter uses no numeric literals, no arithmetic, and no numeric types. If there's a real reason for this, the comment should be expanded. Otherwise, the import should be removed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15526> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #15368: Type families, holes and -fdefer-type-errors may cause 'opt_univ fell into a hole' panic
by GHC 05 Sep '18

05 Sep '18

#15368: Type families, holes and -fdefer-type-errors may cause 'opt_univ fell into a hole' panic -------------------------------------+------------------------------------- Reporter: dramforever | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This program, when compiled like `ghc -fdefer-type-errors -c panic.hs`: {{{#!hs {-# LANGUAGE TypeFamilies #-} module MorePanic where transitive :: (a, b) -> (b, c) -> (a, c) transitive = undefined trigger :: a -> b -> (F a b, F b a) trigger _ _ = _ `transitive` trigger _ _ type family F (n :: *) (m :: *) :: * }}} Gives this panic after several error messages: {{{ ghc.EXE: panic! (the 'impossible' happened) (GHC version 8.4.3 for x86_64-unknown-mingw32): opt_univ fell into a hole {co_a7Sj} Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler\utils\Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler\\types\\OptCoercion.hs:242:5 in ghc:OptCoercion Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} This bug also affects GHCi. Attached is full output -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15368> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10249: Suboptimal error message with deferred type errors
by GHC 05 Sep '18

05 Sep '18

#10249: Suboptimal error message with deferred type errors -------------------------------------+------------------------------------- Reporter: | Owner: Iceland_jack | Status: new Type: feature | Milestone: request | Version: 7.10.1 Priority: normal | Operating System: Unknown/Multiple Component: GHCi | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- {{{#!hs $ ghci -fdefer-type-errors -ignore-dot-ghci GHCi, version 7.10.0.20150316: http://www.haskell.org/ghc/ :? for help Prelude> _ <interactive>:2:1: Warning: Found hole ‘_’ with type: IO t0 Where: ‘t0’ is an ambiguous type variable In the first argument of ‘GHC.GHCi.ghciStepIO :: IO a_aly -> IO a_aly’, namely ‘_’ In a stmt of an interactive GHCi command: it <- GHC.GHCi.ghciStepIO :: IO a_aly -> IO a_aly _ *** Exception: <interactive>:2:1: Found hole ‘_’ with type: IO t0 Where: ‘t0’ is an ambiguous type variable In the first argument of ‘GHC.GHCi.ghciStepIO :: IO a_aly -> IO a_aly’, namely ‘_’ In a stmt of an interactive GHCi command: it <- GHC.GHCi.ghciStepIO :: IO a_aly -> IO a_aly _ (deferred type error) Prelude> }}} It should ideally not expose `ghciStepIO` to the user. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10249> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #10756: Allow users to indicate inaccessible patterns
by GHC 05 Sep '18

05 Sep '18

#10756: Allow users to indicate inaccessible patterns -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 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 Revisions: | -------------------------------------+------------------------------------- Consider {{{#!hs {-# LANGUAGE KindSignatures #-} {-# LANGUAGE GADTs #-} data Elem :: * -> * -> * where EZ :: Elem (f , fs) f ES :: Elem fs f -> Elem (f', fs) f elemAbsurd :: Elem () f -> a elemAbsurd _ = error "inaccessible" }}} This catch-all in `elemAbsurd` is very unfortunate, because if I change my datatype and not all cases are inaccessible anymore the type checker will not be warning me. Although of course there is recent work by SPJ et al on inferring more inaccessible cases, I think it would be tremendously useful for users to be able to indicate that patterns are in fact inaccesible. I'd be very happy if I could write {{{#!hs elemAbsurd :: Elem () f -> a elemAbsurd EZ = inaccessible elemAbsurd (ES _) = inaccessible }}} Note that ghc ''can already detect that these patterns are in fact inaccessible'': it won't let me write the above: {{{ T.hs:12:12: Couldn't match type ‘()’ with ‘(f, fs)’ Inaccessible code in a pattern with constructor EZ :: forall f fs. Elem (f, fs) f, in an equation for ‘elemAbsurd’ }}} So I think it should be very very simple to change the type checker to allow to write cases like this if and only if the RHS is a specially designated symbol "inaccessible", which could be defined simply as {{{#!hs inaccessible :: a inaccessible = error "inaccessible" }}} in `GHC.Prim` or something. This would seem like very little work, and a correspondingly tiny patch, but with quite a large payoff. Future work in automatically detecting inaccessible cases would not make existing code using this style wrong, it just means that we have to write fewer inaccessible cases by hand; but even with more sophisticated inference algorithms for inaccessible cases there will still be inaccessible cases remaining. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10756> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15