August 2013 - ghc-tickets

Re: [GHC] #7500: GHC: internal error: getMBlock: mmap: Operation not permitted
by GHC 29 Aug '13

29 Aug '13

#7500: GHC: internal error: getMBlock: mmap: Operation not permitted ----------------------------------+------------------------------------ Reporter: guest | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+------------------------------------ Comment (by Austin Seipp <aseipp@…>): In [changeset:acb91b920ebac992c52594adf605b2caf98ab4c0/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="acb91b920ebac992c52594adf605b2caf98ab4c0" Treat EPERM error from mmap as an OOM (#7500) Linux can give back EPERM from an mmap call when a user program attempts to map pages near `mmap_min_addr`, which is a kernel security measure to prevent people from mapping pages at address 0. We may do this when we hint to mmap what address to map the pages to. However, it's theoretically possible we're not actually out of memory - we could have continuously mapped pages at some other place far away from `mmap_min_addr` and succeeded instead. So as an added precaution, if mmap for a given addr gives us EPERM, we'll also attempt to map *again*, but without the address hint. Maybe the kernel can do the right thing. However, while testing #7500, the amount of free address space we could have otherwise used only turns out to be about 139MB. Which isn't really a lot. So, given that, we *also* otherwise treat EPERM as an out of memory error. This fixes #7500. Signed-off-by: Austin Seipp <aseipp(a)pobox.com> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7500#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5188: Runtime error when allocating lots of memory
by GHC 29 Aug '13

29 Aug '13

#5188: Runtime error when allocating lots of memory ---------------------------------+--------------------------- Reporter: knyblad | Owner: Type: bug | Status: patch Priority: low | Milestone: 7.6.2 Component: GHCi | Version: 6.12.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+--------------------------- Comment (by thoughtpolice): I reverted 48865521 (and its kin) because unfortunately it causes a validate failure on amd64/Linux, where the conditional in patch #2 is always false, meaning we will always calculate `size = n * MBLOCK_SIZE`. I'll look into this shortly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5188#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5188: Runtime error when allocating lots of memory
by GHC 29 Aug '13

29 Aug '13

#5188: Runtime error when allocating lots of memory ---------------------------------+--------------------------- Reporter: knyblad | Owner: Type: bug | Status: patch Priority: low | Milestone: 7.6.2 Component: GHCi | Version: 6.12.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+--------------------------- Comment (by Austin Seipp <aseipp@…>): In [changeset:48865521de6638240819b3979edbb3d33401dc8e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="48865521de6638240819b3979edbb3d33401dc8e" Check for integer overflow in osGetMBlocks Fixes Trac #5188. Signed-off-by: Austin Seipp <aseipp(a)pobox.com> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5188#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7782: flag to run the demand analysis a second time
by GHC 29 Aug '13

29 Aug '13

#7782: flag to run the demand analysis a second time ----------------------------+---------------------------------------------- Reporter: nfrisby | Owner: nfrisby Type: task | Status: closed Priority: normal | Milestone: 7.8.1 Component: | Version: 7.7 Compiler | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #4941, #5302, #6087, #4962 None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => fixed Comment: Thanks Nicholas! I also took the time to update the ActiveBranches page. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7782#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7782: flag to run the demand analysis a second time
by GHC 29 Aug '13

29 Aug '13

#7782: flag to run the demand analysis a second time ----------------------------+---------------------------------------------- Reporter: nfrisby | Owner: nfrisby Type: task | Status: new Priority: normal | Milestone: 7.8.1 Component: | Version: 7.7 Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #4941, #5302, #6087, #4962 None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Description changed by nfrisby: Old description: > There are some tickets documenting runtime bugs that can be cleaned up by > running the demand analyzer (followed by a simplifier run) a second time > at the end of the pipeline: #4941, #5302, #6087. #6070 ? Others? > > Here's the effects on nofib. Run time didn't seem to change as > drastically. The "X/Y" column headers mean "library-flags/test-flags" > given to GHC when compiling the respective bit. > > {{{ > Allocations > > ------------------------------------------------------------------------------- > Program O2/O2 late-dmd+O2/O2 late-dmd+O2 > /late-dmd+O2 > ------------------------------------------------------------------------------- > cryptarithm2 25078168 +0.0% +8.0% > nucleic2 98331744 +0.0% +3.2% > > cichelli 80310632 +0.0% -22.9% > fasta 401159024 -9.1% -9.1% > fulsom 321427240 +0.0% -2.6% > k-nucleotide 4125102928 -0.0% -4.8% > knights 2037984 +0.0% -3.7% > mandel2 1041840 +0.0% -21.4% > parstof 3103208 +0.0% -1.4% > reverse-complem 155188304 -12.8% -12.8% > simple 226412800 -0.0% -1.0% > }}} > All other changes less than 1% allocation. > Note that it improves a couple tests significantly just via changes in > the base libraries. > > For cryptarithm2, (cf remarks in #4941) > * 4% increase allocation is due to reboxing > * 4% is due to dead closures, because the fix in #4962 isn't working for > some reason. > > For nucleic2, in var_most_distant_atom, an let-bound function is inlined > after w/w, and hence grows numerous closures by a significant amount. I'm > not sure where to lay the blame for this. Note however, that just making > nucleic2's data types use strict !Float fields changes its allocation > -72.4%, so maybe this "bad practice" corner case is a small issue. > > The main remaining task beyond the attached patch is to repair the > treatment of wrapper's strictness signatures in .hi files. Because the > second demand analysis might change a these signatures, the current > compaction mechanism that .hi uses results in ill-formed Core. For the > attached patch, I've just disabled that .hi compaction mechanism, but > this just needlessly bloats .hi files. New description: There are some tickets documenting runtime bugs that can be cleaned up by running the demand analyzer (followed by a simplifier run) a second time at the end of the pipeline: #4941, #5302, #6087. #6070 ? Others? The -flate-dmd-anal flag has been committed to HEAD (cf comment:10 below). The remaining task is to determine if `-O2` should imply `-flate-dmd- anal`. It currently does not: late demand analysis is ''off'' by default. See LateDmd for more info. -- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7782#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7782: flag to run the demand analysis a second time
by GHC 29 Aug '13

29 Aug '13

#7782: flag to run the demand analysis a second time ----------------------------+---------------------------------------------- Reporter: nfrisby | Owner: nfrisby Type: task | Status: new Priority: normal | Milestone: 7.8.1 Component: | Version: 7.7 Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #4941, #5302, #6087, #4962 None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by Nicolas Frisby <nicolas.frisby@…>): In [changeset:c080f727ba5f83921b842fcff71e9066adbdc250/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c080f727ba5f83921b842fcff71e9066adbdc250" simplified the .hi format and added the -flate-dmd-anal flag (fixes #7782) cf http://ghc.haskell.org/trac/ghc/wiki/LateDmd }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7782#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8188: about template haskell's pretty print: 3 % 5 -> 3 / 5
by GHC 29 Aug '13

29 Aug '13

#8188: about template haskell's pretty print: 3 % 5 -> 3 / 5 -------------------------------------+------------------------------------- Reporter: YoshikuniJujo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.6.3 Keywords: template haskell | Operating System: Unknown/Multiple pretty print RationalL | Type of failure: Incorrect result Architecture: Unknown/Multiple | at runtime Difficulty: Easy (less than 1 | Test Case: hour) | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- I think it's better that the ghc can read what is printed by pretty printer. Now: pprLit 0 (RationalL 3.5) => 7 % 2 I want: => 7 / 2 I'll send patch. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8188> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8187: about template haskell's pretty print: ($$$) xy = ...
by GHC 29 Aug '13

29 Aug '13

#8187: about template haskell's pretty print: ($$$) xy = ... -------------------------------------+------------------------------------- Reporter: YoshikuniJujo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Incorrect result Difficulty: Easy (less than 1 | at runtime hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Language.Haskell.TH.Ppr Now: ppr $ FunD (mkName "$$" [Clause [] (NormalB $ VarE $ mkName "x") []] => $$ = x I want: => ($$) = x -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8187> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #4801: Typechecker performance regression 6.12 -> 7.0.1
by GHC 29 Aug '13

29 Aug '13

#4801: Typechecker performance regression 6.12 -> 7.0.1 --------------------------------------------+------------------------------ Reporter: simonmar | Owner: simonpj Type: bug | Status: closed Priority: high | Milestone: 7.0.2 Component: Compiler (Type checker) | Version: 7.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: perf/compiler/T4801 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by jstolarek): I just recalled - this test was failing for me on a 32bit Linux. And it still is, along with a few more. 64bit Linux still validates clean for me. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4801#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8004: Applicative/Monad proposal related warnings (AMP phase 1)
by GHC 29 Aug '13

29 Aug '13

#8004: Applicative/Monad proposal related warnings (AMP phase 1) -------------------------------------+------------------------------------ Reporter: quchen | Owner: quchen Type: feature request | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by quchen): * owner: => quchen -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8004#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0