June 2018 - ghc-tickets

Re: [GHC] #7411: Exceptions are optimized away in certain situations
by GHC 14 Jun '18

14 Jun '18

#7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 #15225 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by tdammers): * related: #5129 => #5129 #15225 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7411#comment:38> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15265: Print result summary in test suite when interrupted
by GHC 14 Jun '18

14 Jun '18

#15265: Print result summary in test suite when interrupted -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: Component: Test Suite | Version: 8.5 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: -------------------------------------+------------------------------------- It'd be helpful if the test runner showed summary of the tests run so far when it's interrupted. This is useful when working on new features: I sometimes run the test suite only to realize something's broken and I'm getting lots of failures. At this point no need to wait until it completes so I interrupt the process, but this doesn't print the summary of the tests run so far, so I have to use terminal scrollback and manually list failing tests etc. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15265> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15252: syn_arg_wraps and syn_res_wrap are only populated after typechecking
by GHC 14 Jun '18

14 Jun '18

#15252: syn_arg_wraps and syn_res_wrap are only populated after typechecking -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The definition for `SyntaxExpr` has two fields which are only populated after type checking. `SyntaxExpr` should have an extension point which contains these two fields. {{{ data SyntaxExpr p = SyntaxExpr { syn_expr :: HsExpr p , syn_arg_wraps :: [HsWrapper] , syn_res_wrap :: HsWrapper } }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15252> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #4806: Make error message more user friendly when module is not found because package is unusable
by GHC 13 Jun '18

13 Jun '18

#4806: Make error message more user friendly when module is not found because package is unusable -------------------------------------+------------------------------------- Reporter: mitar | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4783 Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgillespie): Replying to [comment:32 Phyx-]: > It's quite common to have to update test outputs when you change user visible messages. I'd be more surprised if you didn't have to. In any case, will change it later. After further review, it was only 2 tests. I updated them and added them to the phabricator revision. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4806#comment:33> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13564: Why does memory usage increase so much during CoreTidy?
by GHC 13 Jun '18

13 Jun '18

#13564: Why does memory usage increase so much during CoreTidy? -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: task | 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 made GHC display the live data size before and after each pass and while compiling DynFlags, the live data size increased by almost 50% during the CoreTidy pass, even though the Core program size hardly changed: {{{ ... Result size of Simplifier = {terms: 104,494, types: 264,683, coercions: 15,760, joins: 58/680} !!! Simplifier [DynFlags]: 19.69 221248736: finished in 5337.48 milliseconds, allocated 4416.624 megabytes *** Demand analysis [DynFlags]: 19.69 221248152: Result size of Demand analysis = {terms: 104,494, types: 264,683, coercions: 15,760, joins: 58/680} !!! Demand analysis [DynFlags]: 20.77 248604416: finished in 1349.45 milliseconds, allocated 2298.950 megabytes *** CoreTidy [DynFlags]: 20.77 248603432: Result size of Tidy Core = {terms: 104,440, types: 264,565, coercions: 15,700, joins: 58/679} !!! CoreTidy [DynFlags]: 21.43 342594336: finished in 1124.37 milliseconds, allocated 736.209 megabytes }}} I find the amount of this increase surprising considering what CoreTidy does. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13564> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

Re: [GHC] #2731: Avoid unnecessary evaluation when unpacking constructors
by GHC 12 Jun '18

12 Jun '18

#2731: Avoid unnecessary evaluation when unpacking constructors -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: CodeGen 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: | -------------------------------------+------------------------------------- Comment (by simonpj): > To solve this we would need to track the evaluation requirements of binders in STG. Correct -- and it really would not be hard to do. A relatively straightforward task for someone interested in GHC's back end. I'd be happy to advise. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2731#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15164: Slowdown in ghc compile times from GHC 8.0.2 to GHC 8.2.1 when doing Called arity analysis
by GHC 12 Jun '18

12 Jun '18

#15164: Slowdown in ghc compile times from GHC 8.0.2 to GHC 8.2.1 when doing Called arity analysis -------------------------------------+------------------------------------- Reporter: flip101 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hello, I have this program that compiles against packages of stack LTS-9.21. When i compile with GHC 8.0.2 (version of LTS-9.21) the compiling is fast. 72.01user 34.61system 0:52.98elapsed 201%CPU (0avgtext+0avgdata 600684maxresident)k When i upgrade to LTS-11.9 compiling gets slow. To test if it was a problem with new package or GHC (ghc gives some new packages too) i ran: /usr/bin/time stack build --compiler ghc-8.2.1 --ghc-options="-v3 -j4 -O2 -fexcess-precision -optc-O3 -optc-ffast-math -rtsopts=none -no-rtsopts- suggestions" with the old package of LTS-9.21 but with the newer GHC 8.2.1 compiler. Now the compile times are much higher: 2481.26user 663.66system 35:38.82elapsed 147%CPU (0avgtext+0avgdata 674732maxresident)k I already took out parts of the grammar to get it even to compile. When i have the full grammar i can let my laptop compile 24 hours and it's still busy. I was not sure how to further reduce the code. Maybe when a lot of effort i can cut out a few lines here and there. So i uploaded the entire project here https://github.com/flip111/parser-calledarityanalysis i already took out a lot of code. If anyone has suggestions on how to further reduce the code i can try. Because i had debug info on (-v3 flag) i saw it was stuck for a long time at "Called arity analysis" I prioritize this bug high because i think the slowdown is very problematic. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15164> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 25

Re: [GHC] #2731: Avoid unnecessary evaluation when unpacking constructors
by GHC 12 Jun '18

12 Jun '18

#2731: Avoid unnecessary evaluation when unpacking constructors -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: CodeGen 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: | -------------------------------------+------------------------------------- Changes (by AndreasK): * version: 6.8.3 => 8.5 Comment: If anyone wonders this is still the case in GHC-8.4 / HEAD. Changing the type of `T` to `data T = MkT !(Bool,Bool)` also doesn't change anything. Cmm Code. {{{ {offset c1pY: if ((Sp + -8) < SpLim) (likely: False) goto c1q2; else goto c1q3; c1q2: R2 = R2; R1 = foo_closure; call (stg_gc_fun)(R2, R1) args: 8, res: 0, upd: 8; c1q3: I64[Sp - 8] = c1pV; R1 = R2; Sp = Sp - 8; if (R1 & 7 != 0) goto c1pV; else goto c1pW; c1pW: call (I64[R1])(R1) returns to c1pV, args: 8, res: 8, upd: 8; c1pV: I64[Sp] = c1q1; R1 = P64[R1 + 7]; if (R1 & 7 != 0) goto c1q1; else goto c1q5; c1q5: call (I64[R1])(R1) returns to c1q1, args: 8, res: 8, upd: 8; c1q1: R1 = P64[R1 + 7] & (-8); Sp = Sp + 8; call (I64[R1])(R1) args: 8, res: 0, upd: 8; } }}} To solve this we would need to track the evaluation requirements of binders in STG. Something it seems we currently don't do. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2731#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9539: TQueue can lead to thread starvation
by GHC 12 Jun '18

12 Jun '18

#9539: TQueue can lead to thread starvation -------------------------------------+------------------------------------- Reporter: jwlato | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 7.8.2 Keywords: stm | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- For background, please see [http://stackoverflow.com/questions/25536604 /huge-memory-consumption-for-simple-multithreaded- haskell/25560047#25560047 this SO question] When using TQueue, a sufficiently fast/persistent writer can result in the reader never getting scheduled, causing the queue to continually grow and lost concurrency. I believe the issue is caused by the definition of readTQueue: {{{ readTQueue :: TQueue a -> STM a readTQueue (TQueue read write) = do xs <- readTVar read case xs of (x:xs') -> do writeTVar read xs' return x [] -> do ys <- readTVar write case ys of [] -> retry _ -> case reverse ys of [] -> error "readTQueue" (z:zs) -> do writeTVar write [] writeTVar read zs return z }}} Note that the last `case` needs to traverse the write-end of the queue within the STM transaction. If the list is sufficiently large, a writer can commit a new transaction much more quickly, invalidating the read transaction. If threads continue to write to the queue, the reader will never get an opportunity to commit (and the list will grow, exacerbating the problem). This alternative definition seems to fix the problem, but I don't know if there are other drawbacks to using it. {{{ readTQueue' :: TQueue a -> STM a readTQueue' (TQueue read write) = do xs <- readTVar read case xs of (x:xs') -> do writeTVar read xs' return x [] -> do ys <- readTVar write case ys of [] -> retry _ -> do writeTVar write [] let (z:zs) = reverse ys writeTVar read zs return z }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9539> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23

Re: [GHC] #4806: Make error message more user friendly when module is not found because package is unusable
by GHC 11 Jun '18

11 Jun '18

#4806: Make error message more user friendly when module is not found because package is unusable -------------------------------------+------------------------------------- Reporter: mitar | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4783 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): It's quite common to have to update test outputs when you change user visible messages. I'd be more surprised if you didn't have to. In any case, will change it later. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4806#comment:32> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0