#8569: ASSERT in testcase type-rep, only in some ways: -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): That should be 1df2116c221941ef40a0f6f8fb7dcc42c56738e7 (changed due to pull rebase). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8569#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8569: ASSERT in testcase type-rep, only in some ways: -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Minimalizing the example yields {{{ module Example (x) where data Rep t where Rint :: Rep Int Rdata :: Rep i -> (t -> i) -> (i -> t) -> Rep t addUp :: Rep a -> a -> Int addUp Rint n = n addUp (Rdata i f g) x = addUp i (f x) x = addUp undefined [1] }}} Again, the problem only occurs with `-O`. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8569#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8569: ASSERT in testcase type-rep, only in some ways: -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Here we go: {{{ dmdAnal:Case2 scrut ds_dBX{v} [lid] scrut_ty DmdType {dBX->} alt_tys [DmdType {aqq->}, DmdType {aqq->}] alt_ty DmdType {aqq->} res_ty DmdType {aqq-> dBX->} }}} If I read this correct, in human terms, this tell me “The first case branch will use `aqq` (=`n`) at most once, and will take the box apart and use what’s inside, while do not know anything about how the right case branch uses `n`. The scrutinee does not talk about `n` at all. Therefore, the whole expression uses `n` in an unknown number of times, and also uses what’s inside”. This sounds wrong to me (but I’m not firm on reading demand signatures yet). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8569#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8569: ASSERT in testcase type-rep, only in some ways: -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): This might be related to Note [Don't optimise UProd(Used) to Used]. There it says

But with the joint demand of doesn't convey any clue that there is a product involved, and so the worthSplittingFun will not fire. (We'd need to use the type as well to make it fire.)

so all this trouble of non-canonical demands just to give some bit of information to `worthSplittingFun`, which can probably get this information from `tryWW`, which knows whether the type really is a product type (and not a type variable that was a product type in one branch of a case of the body)? Or are there likely other reasons to keep `UProd(Used)` instead of `UProd`? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8569#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8569: ASSERT in testcase type-rep, only in some ways: -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): In [changeset:"7baefa874d858ec1dd8f875a46eb4be5a732875e/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="7baefa874d858ec1dd8f875a46eb4be5a732875e" Mark type-rep as broken until #8569 is fixed }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8569#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8569: ASSERT in testcase type-rep, only in some ways: -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Test Suite | Version: 7.7 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by nomeata): * status: new => closed * resolution: => wontfix Comment: Guess I did not update the ticket after later discussions. I believe that this is currently a wontfix: * The demand analyser is quite untyped, so in the example in comment:3, where the two branches of a case happen to have quite different types (one being a product, and one not) can only be handled on a best effort basis. Therefore, the code needs to cope with situations where a product demand does not have the right number of components for the constructor at hand. That is also the reason why `lubStr (SCall _) (SProd _)` should not panic. * The `Note [Don't optimise UProd(Used) to Used]` continues to be relevant: We differentiate these semantically equivalent terms to get some insight about how a product is being used. I believe the test suite is now set up to reflect this, i.e. type-rep will expectedly fail when GHC is compiled with `-DDEBUG` *and* the way is an optimizing way. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8569#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8569: ASSERT in testcase type-rep, only in some ways: -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones ): In [changeset:"4b355cd21a190e3d2c2d3a830ba2337d1c442dfe/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="4b355cd21a190e3d2c2d3a830ba2337d1c442dfe" Make the demand on a binder compatible with type (fixes Trac #8569) Because of GADTs and casts we were getting binders whose demand annotation was more deeply nested than made sense for its type. See Note [Trimming a demand to a type], in Demand.lhs, which I reproduce here: Note [Trimming a demand to a type] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Consider this: f :: a -> Bool f x = case ... of A g1 -> case (x |> g1) of (p,q) -> ... B -> error "urk" where A,B are the constructors of a GADT. We'll get a U(U,U) demand on x from the A branch, but that's a stupid demand for x itself, which has type 'a'. Indeed we get ASSERTs going off (notably in splitUseProdDmd, Trac #8569). Bottom line: we really don't want to have a binder whose demand is more deeply-nested than its type. There are various ways to tackle this. When processing (x |> g1), we could "trim" the incoming demand U(U,U) to match x's type. But I'm currently doing so just at the moment when we pin a demand on a binder, in DmdAnal.findBndrDmd. }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8569#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8569: ASSERT in testcase type-rep, only in some ways: -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Test Suite | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: gadt/type-rep | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonpj): * status: new => closed * testcase: => gadt/type-rep * resolution: => fixed Comment: OK I think I've fixed this. Should we merge the change to 7.8 branch? Perhaps not unless it actually bites someone. The trouble it that "bite" has only shown up so far as an ASSERT failure, and I'm not 100% sure that it won't have some other bad consequence if the assert is omitted and we proceed regardless. But nothing has so far. So I'll close for now. Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8569#comment:15 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8569: ASSERT in testcase type-rep, only in some ways: -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Test Suite | Version: 7.7 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: gadt/type- | rep | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nomeata): Thanks for the heads up, changed the status of the bug in changeset:f4904fb/ghc. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8569#comment:17 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler