July 2017 - ghc-tickets

[GHC] #11777: RTS source code issues
by GHC 25 Feb '18

25 Feb '18

#11777: RTS source code issues -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- Tiago Silva <tiagosilva(a)hush.com> writes: Last night I started looking at the C files used in GHC and noticed these issues: {{{ /driver/utils/cwrapper.c : int main(int, char **); }}} `void *p` is apparently unused, even if the compiler optimizes it away.. you should check if something went missing. {{{ /rts/RetainerProfile.c : static nat sanityCheckHeapClosure(StgClosure *) }}} `StgInfoTable *info` has the same issue as above {{{ /rts/RetainerSet.c #elif defined(RETAINER_SCHEME_CC) // Retainer scheme 3: retainer = cost centre void printRetainerSetShort(FILE *f, RetainerSet *rs, nat max_length) { char tmp[max_length + 1]; int size; nat j; } }}} Unlike the other functions around it, this function does nothing. Its variables are also not unused? {{{ /rts/sm/MarkWeak.c : void markWeakPtrList (void); if (w->header.info == &stg_DEAD_WEAK_info) { last_w = &(w->link); } else { last_w = &(w->link); } }}} Not sure what's going on here. Regardless of the test the two branches do the same thing. {{{ /rts/win32/IOManager.c : AddIORequest, AddDelayRequest, AddProcRequest functions }}} If `(!ioMan || !wItem)` the functions either return 0 or FALSE, but they don't free `wItem` before. Is this optimized by the compiler? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11777> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #13011: Simplifier ticks exhausted: a 10-line case
by GHC 25 Feb '18

25 Feb '18

#13011: Simplifier ticks exhausted: a 10-line case -------------------------------------+------------------------------------- Reporter: L.K.Rebellion | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Keywords: Simplifier | Operating System: Linux ticks exhausted | Type of failure: Compile-time Architecture: x86 | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: #8319 #12776 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I was trying to define a function that could take itself as an argument. {{{#!hs newtype MobiusFn a = MobiusFn { func :: MobiusFn a -> a } spin :: MobiusFn a -> a spin mf = func mf mf }}} Use it to find suffixes of a `String` {{{#!hs suffixes :: String -> [String] suffixes = spin $ MobiusFn suffixesMF where suffixesMF _ [] = [] suffixesMF mf s@(_:xs) = s : spin mf xs }}} Add `main` and compile {{{#!hs main = readLn >>= (print . suffixes) }}} The compiler panicked with {{{ [1 of 1] Compiling Main ( test.hs, test.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for i386-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone mf_s1UD }}} But if we ignore the empty string case, it works well with non-empty strings. {{{#!hs suffixes :: String -> [String] suffixes = spin $ MobiusFn suffixesMF where suffixesMF _ s@[_] = [s] suffixesMF mf s@(_:xs) = s : spin mf xs }}} Two versions tested. {{{ GHC version 8.0.1 for i386-unknown-linux GHC version 7.10.3 for i386-unknown-linux }}} Thank you for reading. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13011> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8597: Git Hook script to prevent large binary blobs being checked in
by GHC 23 Feb '18

23 Feb '18

#8597: Git Hook script to prevent large binary blobs being checked in ------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- It has already occurred in the past in `testsuite.git` repo, that executables were checked in by accident, and caused the Git history to get bloated. In order to avoid such accidents in the future a Git hook script in the style of [http://stackoverflow.com/questions/20226132/is-there-a-git-hook- which-can-prevent-binary-check-ins this] might be useful, but taking also into account the size, and/or possibly with a magic safeword to be put in the commit message, to override the check for a single commit, if the author really knows what (s)he's doing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8597> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #13153: Several Traversable instances have an extra fmap
by GHC 23 Feb '18

23 Feb '18

#13153: Several Traversable instances have an extra fmap -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Core | Version: 8.1 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: -------------------------------------+------------------------------------- For example, we define {{{#!hs instance Traversable ZipList where traverse f (ZipList xs) = ZipList <$> traverse f xs }}} If the list is very short, the extra `fmap` could be bad. We can fix this by inlining the inner `traverse`. However, I suspect a better approach would be to add a method to `Traversable`: {{{#!hs mapTraverse :: Applicative f => (t b -> r) -> (a -> f b) -> t a -> f r mapTraverse p f xs = p <$> traverse f xs }}} but I need to work through whether this is enough power to solve enough problems. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13153> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #11826: unsafe causes bug, news @ 11
by GHC 23 Feb '18

23 Feb '18

#11826: unsafe causes bug, news @ 11 -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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 know there has been plenty of levity here lately but here goes :) I didn't expect ‘isUndefined’ to be safe but this may be interesting to the devs (I am obedient and report it thusly and hereby-ly per GHC's request) {{{#!haskell % ghci -ignore-dot-ghci GHCi, version 8.1.20160117: http://www.haskell.org/ghc/ :? for help Prelude> import Control.Exception Prelude Control.Exception> import System.IO.Unsafe Prelude Control.Exception System.IO.Unsafe> import Unsafe.Coerce Prelude Control.Exception System.IO.Unsafe Unsafe.Coerce> isUndefined x = unsafePerformIO $ catch ((unsafeCoerce x :: IO ()) >> return False) (const $ return True :: SomeException -> IO Bool) Prelude Control.Exception System.IO.Unsafe Unsafe.Coerce> isUndefined (succ True) True Prelude Control.Exception System.IO.Unsafe Unsafe.Coerce> isUndefined (succ False) <interactive>: internal error: stg_ap_v_ret (GHC version 8.1.20160117 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) % }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11826> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12524: RFC: Allow prefixing result evaluated at GHCi prompt
by GHC 23 Feb '18

23 Feb '18

#12524: RFC: Allow prefixing result evaluated at GHCi prompt -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: lowest | Milestone: Component: GHCi | Version: 8.0.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: -------------------------------------+------------------------------------- Similar to `prompt`, `prompt-cont` (previously `prompt2`): allowing users to supply a prefix to evaluation results with `result` has two use cases I can think of {{{ :set prompt " ghci> " :set prompt-cont " ghci| " :set result " " }}} the desired outcome would be `↓` as indented code for IRC, also reddit code format: {{{ ghci> 1 + 2 + 3 6 ghci> reverse "hello" "olleh" }}} ---- The other case came from [https://twitter.com/rightfold/status/767301255140179968 this tweet] {{{ :set prompt "" :set result "-- " }}} {{{ 1 + 2 + 3 -- 6 reverse "hello" -- "olleh" }}} This can be copied/pasted back to a separate GHCi session where the result is ignored. ---- I haven't seen this feature in any other repl, I'm not sure if this would see much use. This wouldn't work with IO actions without some magic. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12524> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #14001: Inlining does not work between modules
by GHC 20 Feb '18

20 Feb '18

#14001: Inlining does not work between modules -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.2 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: -------------------------------------+------------------------------------- Hi! I discovered today something that looks like a terrifying bug. I was discussing it on IRC and so far there is no explanation why it happens. Let's grab a test code from here: https://github.com/luna/dependent- state/tree/irc-testing (branch irc-testing). If you download it and execute `stack --stack-yaml stack-develop.yaml bench dependent-state:layered-state-benchmark` benchmarks from `test/bench/Main.hs` will be executed. Everything is compiled with `-O2` etc (see stack-develop.yaml for details). And now (everything regarding file `Control/Monad/State/Layered.hs`): 1. If you change lines `94-111` to use pointfree instead of normal arg, you get 40x slowdown 2. If you then uncomment lines `80-81`, everything is fast again. The problem is that lines `80-81` are: {{{ (.) :: (b -> c) -> (a -> b) -> a -> c (.) f g = \x -> f (g x) ; {-# INLINE (.) #-} }}} It seems that this function is inlined ONLY if is defined in this module. If we use the one from base OR if we move this function to separate module, we can observe the slowdown. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14001> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #11285: Static linking is really slow sometimes
by GHC 20 Feb '18

20 Feb '18

#11285: Static linking is really slow sometimes -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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'm testing on Cabal `Setup.hs`, which links against Cabal. On a beefy machine with many cores and lots of RAM, I see a x2 regression in linking time from GHC 7.10.2 to GHC 8.0 (a recent HEAD) using GNU ld (not gold): {{{ [ezyang@hs01 ezyang]$ rm A; time ghc --make A.hs -fforce-recomp [1 of 1] Compiling Main ( A.hs, A.o ) Linking A ... real 0m1.273s user 0m0.990s sys 0m0.210s [ezyang@hs01 ezyang]$ rm A; time ghc-8.0/usr/bin/ghc --make A.hs -fforce- recomp [1 of 1] Compiling Main ( A.hs, A.o ) Linking A ... real 0m3.270s user 0m2.727s sys 0m0.523s }}} On a puny eight year-old laptop, I see a x2 regression from 7.6 to 7.10 (with not much change with 8.0) {{{ ezyang@sabre:~$ rm A; time ghc --make -O0 A.hs -fforce-recomp rm: cannot remove ‘A’: No such file or directory [1 of 1] Compiling Main ( A.hs, A.o ) Linking A ... real 0m3.058s user 0m1.860s sys 0m1.164s ezyang@sabre:~$ rm A; time ghc-7.10 --make -O0 A.hs -fforce-recomp [1 of 1] Compiling Main ( A.hs, A.o ) Linking A ... real 0m7.139s user 0m4.616s sys 0m2.488s }}} There must be something which is causing the linker to run slowly in one case, and quickly in the other. It would be really good to figure out what this is. Slow linking is NOT NICE. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11285> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #13422: INLINE CONLIKE sometimes fails to inline
by GHC 20 Feb '18

20 Feb '18

#13422: INLINE CONLIKE sometimes fails to inline -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: #7206 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I got surprisingly poor results from the `cheapBuild` experiment (see #7206), so I decided to try a simple example. {{{#!hs foo :: Int -> Int foo n = s + p where nums = [1..n] s = sum nums p = product nums }}} The idea is that we want `nums` to inline into `s` and `p`; the lost sharing is unimportant. Unfortunately, this didn't fuse. I got {{{ -- RHS size: {terms: 44, types: 31, coercions: 0, joins: 2/3} $wfoo :: Int# -> Int# $wfoo = \ (ww_s2HT :: Int#) -> let { nums_s2Gq :: [Int] nums_s2Gq = eftInt 1# ww_s2HT } in joinrec { $wgo_s2HP :: [Int] -> Int# -> Int# $wgo_s2HP (w_s2HJ :: [Int]) (ww1_s2HN :: Int#) = case w_s2HJ of { [] -> joinrec { $wgo1_s2HI :: [Int] -> Int# -> Int# $wgo1_s2HI (w1_s2HC :: [Int]) (ww2_s2HG :: Int#) = case w1_s2HC of { [] -> +# ww1_s2HN ww2_s2HG; : y_a2F9 ys_a2Fa -> case y_a2F9 of { I# y1_a2Gf -> jump $wgo1_s2HI ys_a2Fa (*# ww2_s2HG y1_a2Gf) } }; } in jump $wgo1_s2HI nums_s2Gq 1#; : y_a2F9 ys_a2Fa -> case y_a2F9 of { I# y1_a2EX -> jump $wgo_s2HP ys_a2Fa (+# ww1_s2HN y1_a2EX) } }; } in jump $wgo_s2HP nums_s2Gq 0# -- RHS size: {terms: 10, types: 4, coercions: 0, joins: 0/0} foo :: Int -> Int foo = \ (w_s2HQ :: Int) -> case w_s2HQ of { I# ww1_s2HT -> case $wfoo ww1_s2HT of ww2_s2HX { __DEFAULT -> I# ww2_s2HX } } }}} I verified that `cheapBuild` actually appeared (in `-dverbose-core2core`), but it didn't fuse, and ultimately inlined. Interestingly, forcing the argument manually fixed the problem: {{{#!hs foo :: Int -> Int foo !n = s + p where nums = [1..n] s = sum nums p = product nums }}} produces {{{#!hs $wfoo :: Int# -> Int# $wfoo = \ (ww_s2Ia :: Int#) -> case tagToEnum# (># 1# ww_s2Ia) of { False -> joinrec { $wgo_s2I6 :: Int# -> Int# -> Int# $wgo_s2I6 (w_s2I0 :: Int#) (ww1_s2I4 :: Int#) = case tagToEnum# (==# w_s2I0 ww_s2Ia) of { False -> jump $wgo_s2I6 (+# w_s2I0 1#) (+# ww1_s2I4 w_s2I0); True -> let { x_X2Fz :: Int# x_X2Fz = +# ww1_s2I4 w_s2I0 } in joinrec { $wgo1_s2HY :: Int# -> Int# -> Int# $wgo1_s2HY (w1_s2HS :: Int#) (ww2_s2HW :: Int#) = case tagToEnum# (==# w1_s2HS ww_s2Ia) of { False -> jump $wgo1_s2HY (+# w1_s2HS 1#) (*# ww2_s2HW w1_s2HS); True -> +# x_X2Fz (*# ww2_s2HW w1_s2HS) }; } in jump $wgo1_s2HY 1# 1# }; } in jump $wgo_s2I6 1# 0#; True -> 1# } }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13422> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11427: TypeSynonyms not deduced
by GHC 20 Feb '18

20 Feb '18

#11427: TypeSynonyms not deduced -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: -------------------------------------+------------------------------------- {{{ class (AllF f xs, SListI xs) => All (f :: k -> Constraint) (xs :: [k]) instance #if __GLASGOW_HASKELL__ >= 710 {-# OVERLAPPING #-} #endif All SListI xss => SingI (xss :: [[k]]) where sing = sList }}} fails with {{{ • Could not deduce (SListI xss) arising from the superclasses of an instance declaration from the context: All SListI xss bound by the instance declaration at src/Generics/SOP/Constraint.hs:141:3-40 • In the instance declaration for ‘SingI xss’ }}} See https://travis-ci.org/well-typed/generics-sop/jobs/102388817 and https://github.com/phadej/generics-sop/tree/ghc-8.0.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11427> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15