December 2016 - ghc-tickets

Re: [GHC] #876: Length is not a good consumer
by GHC 11 Dec '16

11 Dec '16

#876: Length is not a good consumer -------------------------------------+------------------------------------- Reporter: ariep@… | Owner: Type: bug | Status: new Priority: lowest | Milestone: 7.6.2 Component: libraries/base | Version: 6.5 Resolution: | Keywords: length Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | perf/should_run/T876 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): This code, compiled with `-O, does fuse, and allocates nothing (or constant amounts) {{{#!hs module Foo where x :: Int -> Int x n = length [0..(10^n)::Int] }}} {{{ $ ghci -fobject-code -O Foo GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Foo ( Foo.hs, Foo.o ) Ok, modules loaded: Foo. Prelude Foo> :set +s Prelude Foo> x 1 11 (0.03 secs, 14,976,744 bytes) Prelude Foo> x 7 10000001 (0.02 secs, 0 bytes) Prelude Foo> x 8 100000001 (0.04 secs, 0 bytes) }}} (almost) HEAD: {{{ GHCi, version 8.1.20161117: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Foo (.hs -> .o) WARNING: file compiler/simplCore/SimplCore.hs, line 663 Simplifier bailing out after 4 iterations [58, 14, 2, 2] Size = {terms: 96, types: 32, coercions: 0} Ok, modules loaded: Foo (Foo.o). Prelude Foo> :set +s Prelude Foo> x 1 11 (0.19 secs, 94,792 bytes) Prelude Foo> x 2 101 (0.01 secs, 94,648 bytes) Prelude Foo> x 7 10000001 (0.01 secs, 98,568 bytes) Prelude Foo> x 8 100000001 (0.05 secs, 98,448 bytes) }}} Testing this in with interpreted code is not sufficient, as the optimizer does less in that case. So so far, everything seems as expected to me. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/876#comment:30> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #915: Implement list fusion using streams instead of foldr/build
by GHC 11 Dec '16

11 Dec '16

#915: Implement list fusion using streams instead of foldr/build -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: closed Priority: normal | Milestone: 7.6.1 Component: libraries/base | Version: 6.8 Resolution: invalid | Keywords: fusion Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by George): Given the preceding comment by Duncan does it make sense to reopen this as a potential task? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/915#comment:47> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #876: Length is not a good consumer
by GHC 11 Dec '16

11 Dec '16

#876: Length is not a good consumer -------------------------------------+------------------------------------- Reporter: ariep@… | Owner: Type: bug | Status: new Priority: lowest | Milestone: 7.6.2 Component: libraries/base | Version: 6.5 Resolution: | Keywords: length Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | perf/should_run/T876 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by George): * status: closed => new * resolution: fixed => Comment: I believe this has regressed. {{{ length [0..10] 11 it :: Int (0.11 secs, 85,536 bytes) Prelude> length [0..(10^7)] 10000001 it :: Int (0.25 secs, 720,084,176 bytes) Prelude> }}} My guess, fwiw, is that this is connected with AMP, making list an instance of Foldable and the issue that rewrite rules cannot be applied to class methods as discussed in recent emails between Conal and SimonPJ. I think the current priority of lowest is correct but thought it worth noting that the problem still exists. Also I think that the user's guide does not accurately reflect the state of list fusion, i.e. https://ghc.haskell.org/trac/ghc/ticket/915. The User's Guide, section 9.32.6 states "This list could readily be extended; if there are Prelude functions that you use a lot which are not included, please tell us." As this bug and ticket 915 indicates extending the list is not always easy. I can file a doc bug if people would like. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/876#comment:29> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12871: Upgrade Mingw-w64 bindist for GHC to GCC 6.2.0 and Binutils 2.27.2
by GHC 10 Dec '16

10 Dec '16

#12871: Upgrade Mingw-w64 bindist for GHC to GCC 6.2.0 and Binutils 2.27.2 -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | 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): Phab:D2749 | Wiki Page: -------------------------------------+------------------------------------- Bump up the bindists to have a more up to date gcc and binutils. The updated binutils should fix LLVM backend on 64bit Windows. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12871> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

Re: [GHC] #7289: Mingw FPU init not Windows compatible.
by GHC 10 Dec '16

10 Dec '16

#7289: Mingw FPU init not Windows compatible. -------------------------------------+------------------------------------- Reporter: Lennart | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 7.2.2 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2819 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: upstream => patch * differential: => Phab:D2819 * architecture: x86 => Unknown/Multiple -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7289#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7206: Implement cheap build
by GHC 09 Dec '16

09 Dec '16

#7206: Implement cheap build -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.4.2 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by bgamari): I took another look at this while waiting for a build and I believe I have identified the source of the additional allocations. In particular I looked at the `real/parser` nofib case, which regresses in allocations by about 3% when using `cheapBuild` for `unpack`, {{{ "unpack" [~1] forall a . unpackCString# a = cheapBuild (unpackFoldrCString# a) }}} The issue is replicated with an example as simple as, {{{#!hs module Hi where data Pat = PatVar Id | PatCon Id [Pat] | PatWild | PatTuple [Pat] deriving (Show{-was:Text-}) type Id = String }}} A pattern which occurs quite often in `parser`. Let's consider the code generated for the `PatTuple` branch of `$cshowsPrec` (taken from the output of the phase 1 simplifier pass), {{{#!hs -- Before cheapBuild PatTuple b1 -> case a of { GHC.Types.I# x -> case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.>=# x 11#) of { False -> ++ @ Char lvl (GHC.Show.showList__ @ Pat $cshowList b1 eta); True -> GHC.Types.: @ Char GHC.Show.shows6 (++ @ Char lvl (GHC.Show.showList__ @ Pat $cshowList b1 (GHC.Types.: @ Char GHC.Show.shows4 eta))) } } -- After cheapBuild PatTuple b1 -> let { p :: ShowS p = \ (x :: String) -> GHC.CString.unpackAppendCString# "PatTuple "# (GHC.Show.showList__ @ Pat $cshowList b1 x) } in case a of { GHC.Types.I# x -> case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.>=# x 11#) of { False -> p eta; True -> GHC.Types.: @ Char GHC.Show.shows6 (p (GHC.Types.: @ Char GHC.Show.shows4 eta)) } } }}} We see that after the introduction of `cheapBuild` the `p` binding is no longer inlined. Comparing the output of `dump-inlinings` reveals why, **Before `cheapBuild`** {{{ Considering inlining: p arg infos [ValueArg] interesting continuation BoringCtxt some_benefit True is exp: True is work-free: True guidance IF_ARGS [0] 80 0 discounted size = 60 ANSWER = YES Inlining done: p Inlined fn: \ (x :: GHC.Base.String) -> GHC.Base.++ @ GHC.Types.Char lvl (GHC.Types.: @ GHC.Types.Char GHC.Show.shows5 (GHC.Show.showLitString b1 (GHC.Types.: @ GHC.Types.Char GHC.Show.shows5 x))) Cont: ApplyToVal nodup (GHC.Types.: @ GHC.Types.Char GHC.Show.shows4 x) Stop[BoringCtxt] [GHC.Types.Char] }}} **After `cheapBuild`** {{{ Considering inlining: p arg infos [ValueArg] interesting continuation BoringCtxt some_benefit True is exp: True is work-free: True guidance IF_ARGS [0] 110 0 discounted size = 90 ANSWER = NO }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7206#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9308: nofib fannkuch-redux runs perpetually with -fllvm
by GHC 09 Dec '16

09 Dec '16

#9308: nofib fannkuch-redux runs perpetually with -fllvm ------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Running the nofib benchmarks with make -k EXTRA_HC_OPTS=-fllvm on a HEAD build of ghc configured with perf-llvm (3.4.2) results in fannkuch-redux running in an infinite loop. The benchmark runs in about 3.5s without the -fllvm {{{ HC = /Users/xx/Projects/ghc/inplace/bin/ghc-stage2 HC_OPTS = -O2 -Rghc-timing -H32m -hisuf hi -fllvm -rtsopts -XBangPatterns -O2 RUNTEST_OPTS = -ghc-timing ==nofib== fannkuch-redux: time to compile Main follows... /Users/jrp/Projects/ghc/inplace/bin/ghc-stage2 -O2 -Rghc-timing -H32m -hisuf hi -fllvm -rtsopts -XBangPatterns -O2 -c Main.hs -o Main.o <<ghc: 358716248 bytes, 313 GCs, 10827462/27497216 avg/max bytes residency (6 samples), 57M in use, 0.00 INIT (0.00 elapsed), 0.20 MUT (0.53 elapsed), 0.21 GC (0.23 elapsed) :ghc>> ==nofib== fannkuch-redux: size of Main.o follows... __TEXT __DATA __OBJC others dec hex 10333 497 0 0 10830 2a4e ==nofib== fannkuch-redux: time to link fannkuch-redux follows... <<ghc: 19914544 bytes, 16 GCs, 1005021/2239600 avg/max bytes residency (3 samples), 25M in use, 0.00 INIT (0.00 elapsed), 0.01 MUT (0.53 elapsed), 0.02 GC (0.02 elapsed) :ghc>> ==nofib== fannkuch-redux: size of fannkuch-redux follows... __TEXT __DATA __OBJC others dec hex 4075520 446464 0 4295945496 4300467480 10053ed18 ==nofib== fannkuch-redux: time to run fannkuch-redux follows... ../../runstdtest/runstdtest ./fannkuch-redux -o1 fannkuch-redux.stdout -o1 fannkuch-redux.stdout -ghc-timing 11; ../../runstdtest/runstdtest ./fannkuch-redux -o1 fannkuch-redux.stdout -o1 fannkuch-redux.stdout -ghc-timing 11; ../../runstdtest/runstdtest ./fannkuch-redux -o1 fannkuch-redux.stdout -o1 fannkuch-redux.stdout -ghc-timing 11; ../../runstdtest/runstdtest ./fannkuch-redux -o1 fannkuch-redux.stdout -o1 fannkuch-redux.stdout -ghc-timing 11; ../../runstdtest/runstdtest ./fannkuch-redux -o1 fannkuch-redux.stdout -o1 fannkuch-redux.stdout -ghc-timing 11; }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9308> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9504: LLVM backend TBAA is too aggressive
by GHC 09 Dec '16

09 Dec '16

#9504: LLVM backend TBAA is too aggressive -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Incorrect Blocked By: | result at runtime Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- At https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/LLVM/Ali… there is written > It [a memory load/store] is very rarely of the form: > {{{ > x = Sp + 8 > I64[x] = ... > }}} > And when it is, 'it is' (unconfirmed) always deriving a "heap" pointer, "stack" pointers are always of the in-line variety. In fact commit e10589a505b44f4f0394500c6a0d2db5baa7f3f4 treats any memory access through a Cmm local variable as having the "other" type, which cannot alias any non-"other" address. But it turns out that a Cmm local might be either an offset from Sp (#9125, though TBAA doesn't seem to have been the cause of the bad code there) or an offset from a Cmm global variable (#9308). In general, we don't know anything about what it might be so we should conservatively use the "top" "type". -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9504> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #12937: String merging broken on Darwin
by GHC 09 Dec '16

09 Dec '16

#12937: String merging broken on Darwin ------------------------------------------+---------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Linking) | Version: 8.0.1 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ------------------------------------------+---------------------------- Phab:D1290 introduced logic to have the linker merge strings to resolve #9577. Unfortunately this logic does not appear to work as expected on OS X. This should be fixed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12937> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9125: int-to-float conversion broken on ARM - 7.8.1-rc2
by GHC 09 Dec '16

09 Dec '16

#9125: int-to-float conversion broken on ARM - 7.8.1-rc2 --------------------------+------------------------------------------------ Reporter: | Owner: Ansible | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.1 Component: | Operating System: Linux Compiler | Type of failure: Incorrect result at runtime Keywords: | Test Case: Architecture: arm | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ I compiled ghc on the raspberry pi. See this bug for more about that build of ghc: [https://ghc.haskell.org/trac/ghc/ticket/8896 8896]. A simple test program: {{{ main = do mapM_ (print . (fromInteger :: Integer -> Float)) [0..100] }}} And the result: {{{ 0.0 127.0 256.0 257.0 516.0 517.0 518.0 519.0 1040.0 1041.0 1042.0 1043.0 1044.0 1045.0 1046.0 1047.0 2096.0 2097.0 2098.0 2099.0 2100.0 2101.0 2102.0 2103.0 2104.0 2105.0 2106.0 2107.0 2108.0 2109.0 2110.0 2111.0 4224.0 4225.0 4226.0 4227.0 4228.0 4229.0 4230.0 4231.0 4232.0 4233.0 4234.0 4235.0 4236.0 4237.0 4238.0 4239.0 4240.0 4241.0 4242.0 4243.0 4244.0 4245.0 4246.0 4247.0 4248.0 4249.0 4250.0 4251.0 4252.0 4253.0 4254.0 4255.0 8512.0 8513.0 8514.0 8515.0 8516.0 8517.0 8518.0 8519.0 8520.0 8521.0 8522.0 8523.0 8524.0 8525.0 8526.0 8527.0 8528.0 8529.0 8530.0 8531.0 8532.0 8533.0 8534.0 8535.0 8536.0 8537.0 8538.0 8539.0 8540.0 8541.0 8542.0 8543.0 8544.0 8545.0 8546.0 8547.0 8548.0 8538.0 }}} This code, however, works normally: {{{ main = do mapM_ (print . (fromInteger :: Integer -> Double)) [0..100] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9125> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 45