January 2018 - ghc-tickets

[GHC] #14681: More incorrect Template Haskell parenthesization
by GHC 18 Jan '18

18 Jan '18

#14681: More incorrect Template Haskell parenthesization -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.2.2 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The latest installment of "RyanGlScott finds bugs in Template Haskell pretty-printing". Here is what's featured on today's episode: {{{#!hs {-# LANGUAGE TemplateHaskell #-} {-# OPTIONS_GHC -ddump-splices #-} module Bug where import Data.Functor.Identity import Language.Haskell.TH $([d| f = \(Identity x) -> x |]) $([d| g = $(pure $ VarE '(+) `AppE` LitE (IntegerL (-1)) `AppE` (LitE (IntegerL (-1)))) |]) }}} Running this with GHC 8.2 or later yields some incorrectly parenthesized output: {{{ $ /opt/ghc/8.2.2/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:8:3-31: Splicing declarations [d| f_azO = \ (Identity x_azP) -> x_azP |] ======> f_a3Nx = \ Identity x_a3Ny -> x_a3Ny Bug.hs:9:3-90: Splicing declarations [d| g_a3NU = $(pure $ VarE '(+) `AppE` LitE (IntegerL (- 1)) `AppE` (LitE (IntegerL (- 1)))) |] pending(rn) [<splice_a3NV, pure $ VarE '(+) `AppE` LitE (IntegerL (- 1)) `AppE` (LitE (IntegerL (- 1)))>] ======> g_a4dU = ((+) -1) -1 }}} In particular, look at these two lines: {{{ f_a3Nx = \ Identity x_a3Ny -> x_a3Ny g_a4dU = ((+) -1) -1 }}} These should be: {{{ f_a3Nx = \ (Identity x_a3Ny) -> x_a3Ny g_a4dU = ((+) (-1)) (-1) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14681> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14665: http://www.cminusminus.org/ is dead
by GHC 18 Jan '18

18 Jan '18

#14665: http://www.cminusminus.org/ is dead -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: Component: Documentation | Version: 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 a couple of comments referring to it in the source, it's easy enough to find the original site at the mirror: http://www.cs.tufts.edu/~nr/c--/index.html or from the wayback machine: https://web.archive.org/web/20080822062234/http://www.cminusminus.org/ If we no longer own the domain, perhaps it would be a good idea to move it under haskell.org somewhere? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14665> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14603: GHC segfaults building store with profiling
by GHC 18 Jan '18

18 Jan '18

#14603: GHC segfaults building store with profiling -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.4.1-alpha1 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: -------------------------------------+------------------------------------- Trying to build `store` c5b6e34ebe4f74a971a8d7428c4cd1fe9bfeecf1 with GHC 8.4.1-alpha1 and profiling enabled results in a segmentation fault. {{{ Thread 1 "ghc" received signal SIGSEGV, Segmentation fault. >>> bt #0 0x00007ffff2f19100 in templatezmhaskell_LanguageziHaskellziTHziSyntax_nameModule_info () from /opt/exp/ghc/roots/8.4.1-alpha1/lib/ghc-8.4.0.20171214/bin/../template- haskell-2.13.0.0/libHStemplate-haskell-2.13.0.0-ghc8.4.0.20171214.so #1 0x0000000000000000 in ?? () }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14603> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #5889: -fno-prof-count-entries leads to linking errors
by GHC 18 Jan '18

18 Jan '18

#5889: -fno-prof-count-entries leads to linking errors -------------------------------------+------------------------------------- Reporter: akio | Owner: bgamari Type: bug | Status: patch Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: GHC rejects | Test Case: valid program | profiling/should_compile/T5889 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4325 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => patch * differential: => Phab:D4325 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5889#comment:30> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13016: SPECIALIZE INLINE doesn't necessarily inline specializations of a recursive function
by GHC 17 Jan '18

17 Jan '18

#13016: SPECIALIZE INLINE doesn't necessarily inline specializations of a recursive function -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: #13014 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_ext… #specialize-inline The user's guide] for `SPECIALIZE INLINE` states it will do a "type-based unrolling" of a recursive function over GADTs. It gives an example, which I've munged a bit to simplify and listed here. {{{#!hs {-# Language GADTs #-} module C where data Arr e where ArrInt :: !Int -> Arr Int ArrPair :: Arr e1 -> Arr e2 -> Arr (e1, e2) (!:) :: Arr e -> Int -> e {-# SPECIALISE INLINE (!:) :: Arr Int -> Int -> Int #-} {-# SPECIALISE INLINE (!:) :: Arr (a, b) -> Int -> (a, b) #-} (ArrInt ba) !: i = ba * i (ArrPair a1 a2) !: i = (a1 !: i, a2 !: i) }}} {{{#!hs module D where import C example = ArrPair (ArrInt 2) (ArrInt 3) !: 5 }}} The specialize rule for pairs fires, but it does not get inlined. This is because the specialization for pairs is marked as a loopbreaker. This behavior contradicts the text from the users guide, emphasis mine: Here, `(!:)` is a recursive function that indexes arrays of type `Arr e`. Consider a call to `(!:)` at type `(Int,Int)`. The second specialisation will fire, ''and the specialised function will be inlined''. It has two calls to `(!:)`, both at type `Int`. Both these calls fire the first specialisation, whose body is also inlined. The result is a type-based unrolling of the indexing function. If I move the `SPECIALIZE INLINE` pragma to the downstream module, then it is not marked as a loopbreaker and we see the expected type-based unrolling. Two possible ways to resolve this ticket: * `SPECIALIZE INLINE` should always achieve supercompilation even if declared in the defining module; the specialization should not be marked as a loopbreaker. * The docs should be updated to say the pragma must be declared in a separate module. I suggest the former. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13016> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #14679: The interpreter showed panic! (the 'impossible' happened)
by GHC 17 Jan '18

17 Jan '18

#14679: The interpreter showed panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: crick_ | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: panic | Operating System: Windows Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- My code - {{{#!hs {- Example run: Enter initial state: 12356 784 Enter final state: 123586 74 1 2 3 5 8 6 7 4 1 2 3 5 8 6 7 4 1 2 3 5 6 7 8 4 1 2 3 5 6 7 8 4 Minimum path length: 3 -} import Data.List import Data.List.Split import Data.Map as Map hiding (map, filter) swap :: Int -> Int -> State -> State swap i j (State xs depth) = let (i', j') = if i > j then (j ,i) else (i, j) left = take i' xs middle = drop (i'+1) $ take j' xs i_elem = xs !! i' right = drop (j'+1) xs j_elem = xs !! j' xs' = left ++ [j_elem] ++ middle ++ [i_elem] ++ right in (State xs' depth) printGrid :: State -> IO() printGrid (State xs depth) = let [x,y,z] = chunksOf 6 $ intersperse ' ' xs in do putStrLn x putStrLn y putStrLn z putStrLn "" data State = State { state :: [Char], depth :: Int } deriving (Eq, Show, Ord) getMoves :: State -> [Char] getMoves (State xs depth) = case ' ' `elemIndex` xs of Nothing -> error "Empty block not found" Just n -> let l = n `elem` [1,4,7,2,5,8] r = n `elem` [0,3,6,1,4,7] d = n `elem` [0..5] u = n `elem` [3..8] pairs = zip [l,r,d,u] ['L','R','D','U'] filtered = filter (\x -> fst x) pairs in map snd filtered next :: State -> [Char] -> [State] next (State state depth) cs = case ' ' `elemIndex` state of Nothing -> error "Empty block not found" Just n -> do c <- cs return $ case c of 'L' -> swap n (n-1) (State state (depth + 1)) 'R' -> swap n (n+1) (State state (depth + 1)) 'U' -> swap n (n-3) (State state (depth + 1)) 'D' -> swap n (n+3) (State state (depth + 1)) test :: State -> State -> Bool test state1 state2 = (state state1) == (state state2) -- loop :: finalState -> open -> closed -> accmulated parentMap -> parentMap loop :: State -> [State] -> [State] -> Map State State -> Maybe (State, Map State State) loop final [] _ _ = Nothing loop final open@(x:xs) closed parentMap = if test final x then Just (x, parentMap) else let moves = getMoves x nextStates = next x moves filter_fn = \x -> not (x `elem` open || x `elem` closed) filtered = filter filter_fn nextStates newMap = insertIntoMap filtered x parentMap in loop final (xs ++ filtered) (x:closed) newMap insertIntoMap :: [State] -> State -> Map State State -> Map State State insertIntoMap [] _ parentMap = parentMap insertIntoMap (x:xs) parent parentMap = insertIntoMap xs parent (Map.insert x parent parentMap) printAns :: State -> Map State State -> Int -> IO () printAns state parentMap count = case Map.lookup state parentMap of Just parent -> do printGrid parent printAns parent parentMap (count + 1) Nothing -> do putStrLn $ "Minimum path length: " ++ show count return () ans :: Maybe (State, Map State State) -> IO () ans (Just (final, parentMap)) = do printGrid final printAns final parentMap 0 ans _ = putStrLn "No answer found." main :: IO () main = do putStrLn "Enter initial state: " start <- getLine putStrLn "Enter final state: " final <- getLine ans $ loop (State final 0) [(State start 0)] [] Map.empty }}} Test Cases I entered in the order: *Main> main Enter initial state: 123456 784 Enter final state: 1234567 8mianrrupted. *Main> *Main> main Enter initial state: 12356 784 Enter final state: 123586 74 1 2 3 5 8 6 7 4 1 2 3 5 8 6 7 4 1 2 3 5 6 7 8 4 1 2 3 5 6 7 8 4 Minimum path length: 3 *Main> <interactive>: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-mingw32): thread blocked indefinitely in an MVar operation Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14679> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #5889: -fno-prof-count-entries leads to linking errors
by GHC 17 Jan '18

17 Jan '18

#5889: -fno-prof-count-entries leads to linking errors -------------------------------------+------------------------------------- Reporter: akio | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: GHC rejects | Test Case: valid program | profiling/should_compile/T5889 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Simon, we were wrong about CorePrep not dropping unfoldings for exported ids, it really drops all unfoldings. There's a note {{{ {- Note [Drop unfoldings and rules] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ We want to drop the unfolding/rules on every Id: - We are now past interface-file generation, and in the codegen pipeline, so we really don't need full unfoldings/rules - The unfolding/rule may be keeping stuff alive that we'd like to discard. See Note [Dead code in CorePrep] - Getting rid of unnecessary unfoldings reduces heap usage - We are changing uniques, so if we didn't discard unfoldings/rules we'd have to substitute in them HOWEVER, we want to preserve evaluated-ness; see Note [Preserve evaluated-ness in CorePrep] Note [Preserve evaluated-ness in CorePrep] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ We want to preserve the evaluated-ness of each binder (via evaldUnfolding) for two reasons * In the code generator if we have case x of y { Red -> e1; DEFAULT -> y } we can return 'y' rather than entering it, if we know it is evaluated (Trac #14626) * In the DataToTag magic (in CorePrep itself) we rely on evaluated-ness. See Note Note [dataToTag magic]. -} }}} I can also clearly see that in the code we don't distinguish exported from non-exported, we just zap all unfoldings (see `cpCloneBndrs` and `zapUnfolding`). So it seems to me like we may have to collect cost centers before or during CorePrep. I vaguely remember discussing this in the meeting and one of the arguments against this was that `CorePrep` is already complex enough so if possible it'd be nice to avoid making it even more complex. Are there any other reasons for not doing this in CorePrep? Can we maybe implement a pass before CorePrep just for cost center collection? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5889#comment:29> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14648: ghc-pkg does handle unitids
by GHC 17 Jan '18

17 Jan '18

#14648: ghc-pkg does handle unitids -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: ghc-pkg | 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: -------------------------------------+------------------------------------- I base the summary and the description on a single observation, see below. Sorry should this turn out to be a deduction too aggressive. == Assumed problem description New-style package-dbs can contain the same (package, version) entry multiple times, as entries are identified using an additional hash. I'll call the full identifier "unitId". The ghc-pkg interface seems to not support specifying full unitIds, i.e. "my-package-0.1.0.0-somehash" seems to be interpreted like "my-package-0.1.0.0-*". This is both a missing functionality and a bug: 1. many operations make sense per-unitId, not just per (package, version) 2. The fact that my-package-0.1.0.0-otherhash is unregistered by "ghc-pkg unregister my-package-0.1.0.0-somehash" is quite surprising. == Observation 1. Take a package-db containing the same (package, version) entry with two different hashes, e.g. - semigroupoids-5.2.1-2f552e489ce3109c2672606e2dc6e33c4f38174da930d5db0bb0dafbb4dccae8 - semigroupoids-5.2.1-e50d44ead36c6b8428c9417007cee15bd9cbe3a2906c19553366d94b15c2471e I suggest making a copy of some existing (cabal store) db. 2. call `ghc-pkg --package-db my-copy unregister semigroupoids-5.2.1-2f552e489ce3109c2672606e2dc6e33c4f38174da930d5db0bb0dafbb4dccae8` 3. test `ghc-pkg --package-db my-copy list semigroupoids-5.2.1` Expected result: `semigroupoids-5.2.1-e50d44ea..` is still registered Observed result: empty list == Impact This blocks the use-case of a garbage-collection for the global new-style package db "store". -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14648> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13683: Use epoll rather than poll where appropriate
by GHC 16 Jan '18

16 Jan '18

#13683: Use epoll rather than poll where appropriate ----------------------------------------+--------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Core Libraries | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- Linux supports an `epoll` system call that's supposed to scale better to large numbers of watched file descriptors than `poll`. We should probably use it when available and appropriate. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13683> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14338: Simplifier fails with "Simplifier ticks exhausted"
by GHC 16 Jan '18

16 Jan '18

#14338: Simplifier fails with "Simplifier ticks exhausted" -------------------------------------+------------------------------------- Reporter: dredozubov | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- While upgrading a codebase to GHC 8.2.1(it compiles reliably with 7.10.3) we encountered an issue with core simplifier(and rewrite rules if I correctly understood the meaning of RuleFired): {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-apple-darwin): Simplifier ticks exhausted When trying RuleFired Class op $p2HModify To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed Total ticks: 10450410 1494659 PreInlineUnconditionally 149100 w_ipsJ 149095 w_ipps 149084 w_iplQ 149084 w1_iplR 149084 w2_iplS 149084 w3_iplT 149078 w_ipm7 149078 w1_ipm8 149078 w2_ipm9 149078 w3_ipma 120 $d~_iplr 120 $d~1_ipls 120 irred_iplu 120 eta_iplv 39 v_spsR 38 v_sp9c 38 v1_sp9d 38 v_spii 38 v1_spij 38 v2_spik 38 v3_spil 37 v_sp99 37 v1_sp9a 37 v_spin 37 v1_spio 37 v2_spip 37 v3_spiq 36 v_sp9f 36 v1_sp9g 36 v_spis ...skipping... 1 cobox1_apuk 1 cobox_apuq 1 cobox1_apur 1 cobox_apux 1 cobox1_apuy 2 CaseIdentity 2 ds1_iqAB 4 FillInCaseDefault 1 nt_sqyY 1 nt_sqz9 1 nt_sqze 1 nt_sqzj Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/simplCore/SimplMonad.hs:199:31 in ghc:SimplMonad Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} We tried to shrink reproducible example to something reasonable and this is what we got: https://github.com/4e6/webapp-template-hs/tree/simpl-tick- factor Compiling it with stack build --ghc-options='-fsimpl-tick-factor=1000'(ten times the default) will demonstrate the issue. It fails reliably with a combination of servant and hset libraries. Removing one route from a servant API or moving the PayloadX to the head of type-level list makes it compilable again. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14338> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 40