March 2017 - ghc-tickets

[GHC] Trac email verification for user: henenenerik
by GHC 06 Mar '17

06 Mar '17

Please visit the following URL to confirm your email address. Verification URL: <http://ghc.haskell.org/trac/ghc/verify_email?verify=1&token=3-SC1QCT> Username: henenenerik Verification Token: 3-SC1QCT -- GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] Trac email verification for user: Neuromancer42
by GHC 06 Mar '17

06 Mar '17

Please visit the following URL to confirm your email address. Verification URL: <http://ghc.haskell.org/trac/ghc/verify_email?verify=1&token=PUcrY7cG> Username: Neuromancer42 Verification Token: PUcrY7cG -- GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13329: Windows CMD.EXE "Quick Edit Mode"
by GHC 05 Mar '17

05 Mar '17

#13329: Windows CMD.EXE "Quick Edit Mode" -------------------------------------+------------------------------------- Reporter: irongremlin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: clipboard, | Operating System: Windows quick edit | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Behavior: When a compiled haskell executable launches into a windows 7 'cmd.exe' terminal session, it does not respect the users 'quick edit mode' setting, and launches with the system default setting instead. I have not replicated this issue on other versions of windows. Details: For a description of the feature behavior, see: https://blogs.msdn.microsoft.com/adioltean/2004/12/27/useful-copypaste- trick-in-cmd-exe/ The registry key entry controlling this setting is: HKEY_CURRENT_USER\Console\QuickEdit (1 == on, 0 ==off) Tiny illustrative program: main :: IO () putStrLn "Try to copy this text" >>=(\_ -> getLine) >>= putStrLn Additional notes: The workaround is pretty simple, launch the program from a .bat script - cmd /K myscript.exe Or from inside an existing cmd.exe session, and the problem goes away. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13329> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] Trac email verification for user: lars
by GHC 05 Mar '17

05 Mar '17

Please visit the following URL to confirm your email address. Verification URL: <http://ghc.haskell.org/trac/ghc/verify_email?verify=1&token=UZ8JL-No> Username: lars Verification Token: UZ8JL-No -- GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13377: Compiler error: Simplifier ticks exhausted
by GHC 05 Mar '17

05 Mar '17

#13377: Compiler error: Simplifier ticks exhausted -------------------------------------+------------------------------------- Reporter: | Owner: (none) simplifierticks | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | 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: -------------------------------------+------------------------------------- 2.4 Programming jointly with types and values Exercise 2.4.1 (Fixpoint). The lambda term: y = = \f->(\x->f (x x)) (\x->f (x x)) (that encodes a fixed point combinator in the untyped lambda calculus) does not type check in Haskell. Try it! Interestingly though, recursion on the type level can be used to introduce recursion on the value level. If we define the recursive type: data F a = = F { unF :: F a->a } then we can “annotate” the definition of y with applications of F and unF such that y typechecks. Do it! This works on someones else his computer: {{{#!hs data F a = F { unF :: F a -> a } -- y = \f -> (\x -> f (x x)) (\x -> f (x x)) y = \f -> (\x -> x $ F x) (\x -> f . unF x $ x) }}} Compiler error: ghc.EXE: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-mingw32): Simplifier ticks exhausted When trying UnfoldingDone x_s1Gq 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 To see detailed counts use -ddump-simpl-stats Total ticks: 6480 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Increased -fsimpl-tick-factor to 100.000 still the error occurred -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13377> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] Trac email verification for user: simplifierticks
by GHC 05 Mar '17

05 Mar '17

Please visit the following URL to confirm your email address. Verification URL: <http://ghc.haskell.org/trac/ghc/verify_email?verify=1&token=PCGVgBOg> Username: simplifierticks Verification Token: PCGVgBOg -- GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10830: maximumBy has a space leak
by GHC 04 Mar '17

04 Mar '17

#10830: maximumBy has a space leak -------------------------------------+------------------------------------- Reporter: | Owner: NeilMitchell | Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.10.2 libraries/base | Keywords: | Operating System: Windows Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Given the program: {{{#!hs import Data.List main = print $ maximumBy compare [1..10000] }}} Compiling with {{{-O2}}}, on GHC 7.8.3 this runs in constant stack space (works fine with {{{+RTS -K1K}}}). With GHC 7.10.2 I get: {{{ $ ghc --make Test.hs -O2 -rtsopts [1 of 1] Compiling Main ( Test.hs, Test.o ) Linking Test.exe ... $ Test +RTS -K100K Stack space overflow: current size 33680 bytes. Use `+RTS -Ksize -RTS' to increase it. }}} Not sure why it's failing at 33K instead of 100K, but it's certainly taking more than 1K as GHC 7.8.3 did. See #3416 for previous discussion of this issue. My guess is that in older versions of GHC the strictness analysis managed to kick in and optimise things. With the burnt bridges that no longer works. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10830> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 33

[GHC] #13353: foldr/nil rule not applied consistently
by GHC 04 Mar '17

04 Mar '17

#13353: foldr/nil rule not applied consistently -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I just had a project where it made a difference whether I add {{{ {-# RULES "foldr/nil" forall k n . GHC.Base.foldr k n [] = n #-} }}} to my file or not, despite this rule already being present in the library. I tried to minimize the problem and came up with this: {{{#!hs foo1 (f, fs) (x, xs) = (f x, map ($x) fs ++ map f xs) foo2 f fs x xs = (f x, map ($x) fs ++ map f xs) test1 x xs = foo1 (id, []) (x, xs) test2 x xs = foo2 id [] x xs test3 x xs = (id x, map ($x) [] ++ map id xs) }}} `test2` and `test3` nicely optimize the `map … [] ++` away, but `test` does not. (In this minimized example, adding the rule again locally does *not* help, but there is still something fishy.) Also, in all cases, `map id` remains, which should not be the case. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13353> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13374: Let exprSize ignore case analysis
by GHC 04 Mar '17

04 Mar '17

#13374: Let exprSize ignore case analysis -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- This came out of a discussion at #1335, where Simon says: > > So it seems that after splitting the function into two pieces, it is small enough(?) so that both pieces inline? > > Yes that is galling I agree. > > * Part of the trouble is that strictness analysis does a deep semantic analysis, pulls all the evals to the top, inlines them unconditionally, leaving behind a worker that may now be a lot smaller. The sizeExpr code in CoreUnfold is necessarily much simpler. > > * The discount we award for a scrutinised argument is computed in size_up here: > > {{{ > alts_size (SizeIs tot tot_disc tot_scrut) > -- Size of all alternatives > (SizeIs max _ _) > -- Size of biggest alternative > = SizeIs tot (unitBag (v, 20 + tot - max) > `unionBags` tot_disc) tot_scrut > }}} > > For a single-alternative case (and you have a tuple arg here) tot = max, so there's fixed discount of 20. You could make that into a controllable flag and try varying it. > > * Idea. If a function starts with case x of blah (even if wrapped in lets) we know that the strictness analyser will find it strict in x. So we know it'll generate a wrapper, and the wrapper will inline. So in the end it'll be as if that case cost nothing at all. It would not be hard to make sizeExpr simply count zero for the cost of such cases; including nested. (Certainly for single-alternative ones.) > > Worth a try? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13374> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11421: adding a PartialTypeSignatures to a binding affected by MonoLocalBinds leads compile-time failure
by GHC 04 Mar '17

04 Mar '17

#11421: adding a PartialTypeSignatures to a binding affected by MonoLocalBinds leads compile-time failure -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- See attached file. I think both type signatures for xs should work. The ghci error unfortunately doesn't show up on :reload, but it shows up when trying to run an unrelated function (main here). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11421> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4