August 2017 - ghc-tickets

[GHC] #13088: Type operator holes don't work infix
by GHC 26 Feb '18

26 Feb '18

#13088: Type operator holes don't work infix -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: #13050 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Originally noted in https://phabricator.haskell.org/D2910 (which fixed #13050). Currently, you can do this: Does this also work with TypeOperators? That is, you can do this: {{{#!hs {-# LANGUAGE TypeOperators #-} foo :: a `_over` b -> _over a b foo = id }}} But not this: {{{#!hs {-# LANGUAGE TypeOperators #-} foo :: a `_` b -> over a b foo = id }}} osa1 made an attempt at fixing this, and recorded his progress [https://phabricator.haskell.org/D2910#85423 here]: > I played with alternative implementations and attempted at implementing type-level version of this patch as suggested by @RyanGlScott. > > Since `_` needs special treatment by the renamer I think we have to have some kind of special treatment for `_` in the parser too, so this implementation may not be too bad. > > (alternatively I guess we could remove special treatment for `_` in the parser but that'd just move special cases to the renamer, so I'm not sure that's any better than the current approach) > > About the type-level named infix holes: Type renamer is quite different than term renamer (`RnTypes.hs`) and I don't understand type-checker parts of the compiler -- but I was able to made an attempt at implementing this > > {{{#!diff > diff --git a/compiler/hsSyn/HsTypes.hs b/compiler/hsSyn/HsTypes.hs > index 53f200f..877c243 100644 > --- a/compiler/hsSyn/HsTypes.hs > +++ b/compiler/hsSyn/HsTypes.hs > @@ -608,6 +608,7 @@ type LHsAppType name = Located (HsAppType name) > data HsAppType name > = HsAppInfix (Located name) -- either a symbol or an id in backticks > | HsAppPrefix (LHsType name) -- anything else, including things like (+) > + | HsAppWild (Located (HsWildCardInfo name)) > deriving instance (DataId name) => Data (HsAppType name) > > instance (OutputableBndrId name) => Outputable (HsAppType name) where > @@ -987,11 +988,18 @@ getAppsTyHead_maybe tys = case splitHsAppsTy tys of > splitHsAppsTy :: [LHsAppType name] -> ([[LHsType name]], [Located name]) > splitHsAppsTy = go [] [] [] > where > + go :: [LHsType name] > + -> [[LHsType name]] > + -> [Located name] > + -> [LHsAppType name] > + -> ([[LHsType name]], [Located name]) > go acc acc_non acc_sym [] = (reverse (reverse acc : acc_non), reverse acc_sym) > go acc acc_non acc_sym (L _ (HsAppPrefix ty) : rest) > = go (ty : acc) acc_non acc_sym rest > go acc acc_non acc_sym (L _ (HsAppInfix op) : rest) > = go [] (reverse acc : acc_non) (op : acc_sym) rest > + go acc acc_non acc_sym (L l (HsAppWild (L _ wc)) : rest) > + = go (L l (HsWildCardTy wc) : acc) acc_non acc_sym rest > > -- Retrieve the name of the "head" of a nested type application > -- somewhat like splitHsAppTys, but a little more thorough > @@ -1334,14 +1342,18 @@ ppr_fun_ty ctxt_prec ty1 ty2 > > -------------------------- > ppr_app_ty :: (OutputableBndrId name) => TyPrec -> HsAppType name -> SDoc > -ppr_app_ty _ (HsAppInfix (L _ n)) = pprInfixOcc n > +ppr_app_ty _ (HsAppInfix (L _ n)) > + = pprInfixOcc n > ppr_app_ty _ (HsAppPrefix (L _ (HsTyVar NotPromoted (L _ n)))) > = pprPrefixOcc n > ppr_app_ty _ (HsAppPrefix (L _ (HsTyVar Promoted (L _ n)))) > = space <> quote (pprPrefixOcc n) -- We need a space before the ' above, so > -- the parser does not attach it to the > -- previous symbol > -ppr_app_ty ctxt (HsAppPrefix ty) = ppr_mono_lty ctxt ty > +ppr_app_ty ctxt (HsAppPrefix ty) > + = ppr_mono_lty ctxt ty > +ppr_app_ty ctxt (HsAppWild (L _ (AnonWildCard _))) > + = empty -- FIXME > > -------------------------- > ppr_tylit :: HsTyLit -> SDoc > diff --git a/compiler/parser/Parser.y b/compiler/parser/Parser.y > index dfb6755..da4696a 100644 > --- a/compiler/parser/Parser.y > +++ b/compiler/parser/Parser.y > @@ -1833,6 +1833,7 @@ tyapp :: { LHsAppType RdrName } > [mj AnnSimpleQuote $1] } > | SIMPLEQUOTE varop {% ams (sLL $1 $> $ HsAppInfix $2) > [mj AnnSimpleQuote $1] } > + | '`' '_' '`' { sL1 $1 (HsAppWild (sL1 $1 (AnonWildCard PlaceHolder))) } > > atype :: { LHsType RdrName } > : ntgtycon { sL1 $1 (HsTyVar NotPromoted $1) } -- Not including unit tuples > diff --git a/compiler/rename/RnTypes.hs b/compiler/rename/RnTypes.hs > index f3fcf88..9298020 100644 > --- a/compiler/rename/RnTypes.hs > +++ b/compiler/rename/RnTypes.hs > @@ -1050,8 +1050,11 @@ collectAnonWildCards lty = go lty > > gos = mconcat . map go > > + prefix_types_only :: HsAppType Name -> Maybe (LHsType Name) > prefix_types_only (HsAppPrefix ty) = Just ty > prefix_types_only (HsAppInfix _) = Nothing > + prefix_types_only (HsAppWild (L l (AnonWildCard wc_name))) = > + Just (L l (HsWildCardTy (AnonWildCard wc_name))) > > collectAnonWildCardsBndrs :: [LHsTyVarBndr Name] -> [Name] > collectAnonWildCardsBndrs ltvs = concatMap (go . unLoc) ltvs > @@ -1646,8 +1649,9 @@ extract_apps t_or_k tys acc = foldrM (extract_app t_or_k) acc tys > > extract_app :: TypeOrKind -> LHsAppType RdrName -> FreeKiTyVars > -> RnM FreeKiTyVars > -extract_app t_or_k (L _ (HsAppInfix tv)) acc = extract_tv t_or_k tv acc > -extract_app t_or_k (L _ (HsAppPrefix ty)) acc = extract_lty t_or_k ty acc > +extract_app t_or_k (L _ (HsAppInfix tv)) acc = extract_tv t_or_k tv acc > +extract_app t_or_k (L _ (HsAppPrefix ty)) acc = extract_lty t_or_k ty acc > +extract_app t_or_k (L _ (HsAppWild (L l wc))) acc = extract_lty t_or_k (L l (HsWildCardTy wc)) acc > > extract_hs_tv_bndrs :: [LHsTyVarBndr RdrName] -> FreeKiTyVars > -> FreeKiTyVars -> RnM FreeKiTyVars > }}} > > Once I figure out how to do the `FIXME` part this patch may just work. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13088> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[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 24 Feb '18

24 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 24 Feb '18

24 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 24 Feb '18

24 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 24 Feb '18

24 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