October 2018 - ghc-tickets

[GHC] #14626: No need to enter a scrutinised value
by GHC 08 Oct '18

08 Oct '18

#14626: No need to enter a scrutinised value -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: performance | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #13861 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While analysing the output of #13861 I stumbled over an unnecessary pessimisation in handling of scrutinised values. With words of Simon (from https://phabricator.haskell.org/D4267 with minor edits added): Interesting. Yes, please make a ticket! (And transfer the info below into it.) I think the issue is this. Given (the STG-ish code) {{{#!hs data Colour = Red | Green | Blue f x = case x of y Red -> Green DEFAULT -> y }}} (here `y` is the case binder) we can just return `x` rather than entering it in DEFAULT branch, because `y` will be fully evaluated and its pointer will be correctly tagged. You absolutely can't check for an `OccName` of `"wild"`!! That is neither necessary nor sufficient :-). Instead, check `isEvaldUnfolding (idUnfolding y)`. See `Note [Preserve evaluatedness]` in `CoreTidy.hs`. And be sure to augment that note if you make the change. I would expect perf benefits to be small on average, but it's simple to implement. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14626> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 47

[GHC] #15724: GHC panic with malformed pragma
by GHC 08 Oct '18

08 Oct '18

#15724: GHC panic with malformed pragma -------------------------------------+------------------------------------- Reporter: etorreborre | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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: -------------------------------------+------------------------------------- This comment crashes GHC (the comment is not properly closed) {{{#!hs {-# OPTIONS_GHC -f-nowarn-orphans #} }}} {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.4.3 for x86_64-apple-darwin): getOptions'.parseToks: Couldn't read " \"|\")) <> rand_bytes\n pure $ (==) hashed rehashed\n final = either (FailedToParse . show) (bool InValid Valid) result\n\n{-# ANN StateNamePrefix (Just (\"Test\" :: Text)) " as String }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15724> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15720: Assign to literals is allowed in ghci
by GHC 08 Oct '18

08 Oct '18

#15720: Assign to literals is allowed in ghci -------------------------------------+------------------------------------- Reporter: sighingnow | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I have been asked that why `1 = 2` is allowed in ghci, which is quite confusing for beginners. {{{ > 1 = 2 > 1 1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15720> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15716: GHC hangs on default implementation of type family
by GHC 08 Oct '18

08 Oct '18

#15716: GHC hangs on default implementation of type family -------------------------------------+------------------------------------- Reporter: Heimdell | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.4.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I have this code: {{{ {-# language TypeFamilies #-} {-# language MultiParamTypeClasses #-} {-# language FlexibleInstances #-} import Control.Monad.Except class Component comp where data Error comp :: * type ComponentT comp :: * -> * type ComponentT comp = ExceptT (Error comp) }}} I expect it to either compile or fail with error. Instead, GHC[i] hangs every time. It prints {{{ <interactive>:10:28: error: }}} and then hangs. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15716> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14152: Float exit paths out of recursive functions
by GHC 08 Oct '18

08 Oct '18

#14152: Float exit paths out of recursive functions -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 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: #14137 #10918 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is a spin off of a discussion from #14137. == The problem == We generally avoid inlining or floating a binding into a recursive function, because we do not want to duplicat work/allocations. But sometimes the binding is only used inside the recursive function on the “exit path”. In which case it would be good to inline. Example: {{{#!hs let x = f x0 in let go 10 = h x go i = go (i+1) in go (0::Int) + 100 }}} It would be beneficial to inline `x`. The problem is that it is not very obvious that this occurence of `x` is ok for inlining. In particular, it is not syntactically visible. == Proposed solution == If we apply loopification (#14068), this would turn into {{{#!hs let x = f x0 in let go n = joinrec jgo 10 = h x jgo i = call jgo (i+1) in call jgo n in go (0::Int) + 100 }}} I’d like to call this ''first joinrec normal form'', defined as “every recursive function where all recursive calls are tail-recursive is a recursive join point”. This ticket proposes to transform this even further and ''float out all case alternatives that do not mention `jgo` as non-recursive join- points'', as so: {{{#!hs let x = f x0 in let go n = join jexit = h x joinrec jgo 10 = call jexit jgo i = call jgo (i+1) in call jgo n in go (0::Int) + 100 }}} I’d like to call this ''second `joinrec` normal form'', defined as “in first `joinrec` normal form, and all subexpressions of a recursive join point `j` that are in tail-call position and do not mention `j` are join calls”. If the floated expression has free variables that are bound inside the `joinrec`, they turn into parameters of the newly created joinpoint. At this point, GHC can tell that `go` is called at most once, and will therefore happily inline `x` into the right hand side of `jexit. == Alternative solutions == Ticket #10918 uses Call Arity results to learn that `x` is one-Shot, and inline it even in the original code. This works, but the problem is that float-out will undo this. See [ticket:10918#comment:5]. == Limitation === It only works for recursive functions that are join points, or can be turned into join points by loopification (#14068). It does not work forexample for {{{#!hs let x = f x0 let go 0 = h x go n = (go (n-1) + 1 in go 10 }}} although it would be equally desirable to float `h x` out of `go` so that `x` can be inlined. == Preservation == A remaining tricky point is that we need to stop one of these carefully- constructed non-recursive join points being inlined into a recursive join point, even if it is invoked at just one place. That should not be hard. And in a final run of the simplifer (or in CorePrep) we could switch off that restriction and let it inline. (Ticket #14137 is about inlining ''more'' join points into recursive join points, so it is the antithesis to the present ticket.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14152> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 45

[GHC] #15719: Primitive atomic logical operations
by GHC 07 Oct '18

07 Oct '18

#15719: Primitive atomic logical operations -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- We offer fetch-and-and, fetch-and-or, etc., which are available as GCC intrinsics. Unfortunately, as far as I can tell those operations are ''not'' actually offered by x86_64. So I ''believe'' GCC must be implementing them using CAS loops on that (rather important) architecture. On the other hand, that instruction set does offer a plain atomic-and, atomic-or, etc., that do not fetch. In some cases, that may be sufficient. For example, I'm currently designing a potential replacement for the stable pointer system that uses a bitmap to represent a free list. Each deletion operation needs to update the bitmap (or) and then check whether a certain threshold number of entries are free (popcnt). One straightforward way to accomplish this with available instructions would be 1. Atomic OR to mark an entry free 2. Load the bitmap 3. Perform the popcnt test Of course, it would be ''nice'' to have fetch-and-or here, but we don't actually need it--if a bunch of deletions happen concurrently, then at least one of them will see the popcnt over the threshold. Could we (and should we) offer non-fetching atomic operations implemented natively where they're available? One important question is of course whether we'd actually get better performance this way than using a CAS loop. I would conjecture that this is this case under contention, but I don't actually know. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15719> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #13896: Use response file to invoke hsc2hs
by GHC 07 Oct '18

07 Oct '18

#13896: Use response file to invoke hsc2hs ----------------------------------------+--------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: hsc2hs | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- We already use response files when invoking Haddock due to Windows command line length limitations. It [[https://github.com/haskell/cabal/issues/3122#issuecomment-311489312|seems]] that we also need to do the same with `hsc2hs`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13896> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #13841: ADOPT pragma for silencing orphan instances warnings per instance
by GHC 07 Oct '18

07 Oct '18

#13841: ADOPT pragma for silencing orphan instances warnings per instance -------------------------------------+------------------------------------- Reporter: cocreature | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- Currently GHC only allows enabling and disabling the warnings about orphan instances on a module level. I’d like to have an ADOPT pragma that allows disabling the warning for specific instance: {{{#!haskell instance {-# ADOPT #-} C Int }}} Apart from disabling the warning about orphan instances for this specific instance, this pragma should have no effect. I already hacked together a [https://github.com/cocreature/ghc/tree/adopt- pragma prototype] and I’m willing to clean that up and submit a diff if other people like this. This does change the surface language but disabling a warning seem too small of an effect for the ghc proposals process (I’m happy to make a proposal if you disagree). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13841> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #2515: Flag to suppress orphan instance warnings
by GHC 07 Oct '18

07 Oct '18

#2515: Flag to suppress orphan instance warnings -------------------------------------+------------------------------------- Reporter: tim | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 6.8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10150 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Lemming): * related: => #10150 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2515#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15714: Compacting StaticPtr of a function doesn't work
by GHC 06 Oct '18

06 Oct '18

#15714: Compacting StaticPtr of a function doesn't work -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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 think we should be able to compact a StaticPtr of a function, but it currently doesn't work. Reproducer: {{{#!haskell {-# LANGUAGE StaticPointers #-} import GHC.StaticPtr import Data.Compact foo :: Int -> Int foo x = x^2 main = do c <- compact (static foo :: StaticPtr (Int -> Int)) return () }}} Output: {{{ ./compact_test compact_test: compaction failed: cannot compact functions }}} Tried with 8.4.3 (compact on hackage doesn't build with 8.6). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15714> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4