- ghc-tickets - Haskell.org

[GHC] #13144: FoatOut is not floating bottoming expressions properly
by GHC 08 Feb '17

08 Feb '17

#13144: FoatOut is not floating bottoming expressions properly -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 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): | Wiki Page: -------------------------------------+------------------------------------- Consider part of Eric's program in #13143, and pretty much exactly what is in `GHC.Arr`. {{{ {-# INLINE index #-} index :: (Int, Int) -> Int -> Int index b@(l,h) i | l <= i && i < h = 0 | otherwise = indexError b i 0 {-# NOINLINE indexError #-} indexError :: (Int, Int) -> Int -> Int -> b indexError rng i tp = error (show rng) }}} Before float-out we have {{{ index = \ (b_ay8 :: (Int, Int)) (i_ayb :: Int) -> case b_ay8 of wild_Xe { (l_ay9, h_aya) -> case && (leInt l_ay9 i_ayb) (ltInt i_ayb h_aya) of { False -> indexError @ Int wild_Xe i_ayb (I# 0#); True -> GHC.Types.I# 0# } } }}} and after float-out we see {{{ index = \ (b_ay8 :: (Int, Int)) (i_ayb :: Int) -> case b_ay8 of wild_Xe { (l_ay9, h_aya) -> case && (leInt l_ay9 i_ayb) (ltInt i_ayb h_aya) of { False -> indexError @ Int b_ay8 i_ayb lvl_s2cd; True -> GHC.Types.I# 0# } } }}} We've floated the `(I# 0#)`. ''But we should have floated the entire call to `indexError` thus'': {{{ False -> lvl_xxx b_ay8 i_ayb }}} with {{{ lvl_xxx b i = indexError @Int b i (I# 0#) }}} Why? Because it makes the expression smaller and moves the error handling code out of the way. Float-out makes some attempt to to this, but it's not right yet. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13144> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13241: Compile-time flag causing GC to zero evacuated memory
by GHC 08 Feb '17

08 Feb '17

#13241: Compile-time flag causing GC to zero evacuated memory -------------------------------------+------------------------------------- Reporter: tommd | Owner: Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- The `memory` package includes a `ScrubbedBytes` type that scrubs (zeros) the bytestring upon free via a finalizer. The intent with this type is to achieve a common requirement in the cryptographic world that key material is zeroed once it is no longer needed. Sadly, this technique is not useful for many reasons: * Consumers often take bytestrings * Key material often exists as other types such as bytestring, Text in case of passwords>>=KDF, or Integer in the case of home-grown RSA operations. * Scrubbing via a finalizer is clumsy, verbose, and error prone. `memory`'s scrubbing appears to be related to or even have caused a bug with a related library a while back. Note I am rather keen on _not_ arguing about the suitability of Haskell for cryptographic purposes. That's an orthogonal topic to the value of zeroing freed memory. I would like GHC to include a flag (`--zero-evacuated`?) that will cause evacuated memory to be zeroed by the GC. This functionality already exists as a debugging feature to help recognize unused (or misused) memory so I anticipate the actual RTS code change to be minimal. The main question is if GHCHQ agrees this feature is valuable enough to include another flag. Thoughts? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13241> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10635: -fwarn-redundant-constraints should not be part of -Wall
by GHC 08 Feb '17

08 Feb '17

#10635: -fwarn-redundant-constraints should not be part of -Wall -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.11 Component: Compiler | Operating System: Unknown/Multiple (Type checker) | Type of failure: Incorrect Keywords: | warning at compile-time Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When I compile existing code with GHC-7.11.20150707 I get lot of "redundant constraints" warnings. Generally I think that this warning can be very useful for minimizing constraints, nonetheless there are good reasons not choose minimal constraints for a type signature. E.g. if I have to implement `Data.Map.singleton` I do not need the `Ord k` constraint for the key type. However, I might add it anyway in order to be able to change the implementation in future such that it uses `Ord k` dictionary. Thus I suggest to exclude `-fwarn-redundant-constraints` from `-Wall`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10635> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 38

[GHC] #13143: NOINLINE and worker/wrapper
by GHC 07 Feb '17

07 Feb '17

#13143: NOINLINE and worker/wrapper -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 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): | Wiki Page: -------------------------------------+------------------------------------- Currently we do no worker/wrapper on a NOINLINE thing. In `WorkWrap`: {{{ tryWW dflags fam_envs is_rec fn_id rhs | isNeverActive inline_act -- No point in worker/wrappering if the thing is never inlined! -- Because the no-inline prag will prevent the wrapper ever -- being inlined at a call site. }}} But if we have, say, {{{ {-# NOINLINE f #-} f (x,y) = error (show x) g True p = f p g False p = snd p + 1 }}} then strictness analysis will discover `f` is strict, and `g`, but ''because `f` has no wrapper'', the worker for `g` will rebox the thing. So we get {{{ f (x,y) = error (show x) $wg b x y = let p = (x,y) -- Yikes! Reboxing! in case b of True -> f p False -> y + 1 g b p = case p of (x,y) -> $wg b x y }}} Now, in this case the reboxing will float into the `True` branch, an so the allocation will only happen on the error path. But it won't float inwards if there are multiple branches that call `(f p)`, so the reboxing will happen on every call of `g`. Disaster. Solution: do worker/wrapper even on NOINLINE things; but move the NOINLINE pragma to the worker. --------------------------- This actually happens! In `GHC.Arr` we have {{{ {-# NOINLINE indexError #-} indexError :: Show a => (a,a) -> a -> String -> b indexError rng i tp = error (...) index b i | inRange b i = unsafeIndex b i | otherwise = indexError b i "Char" }}} The `inRange` generates multiple alternatives, which the `indexError` is duplicated into, and exactly this phenomenon takes place. Eric (gridaphobe) offered this standalone example {{{ module Err where tabulate :: (Int -> a) -> (Int, Int) -> [Int] tabulate f (l,u) = array (l,u) [l..u] {-# INLINE array #-} array :: (Int, Int) -> [Int] -> [Int] array (l,u) is = [index (l,u) i | i <- is] {-# INLINE index #-} index :: (Int, Int) -> Int -> Int index b@(l,h) i | l <= i && i < h = 0 | otherwise = indexError b i 0 {-# NOINLINE indexError #-} indexError :: (Int, Int) -> Int -> Int -> b indexError rng i tp = error (show rng) }}} Compile this with GHC 8, and shudder at the terrible code we get for `$wtabulate`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13143> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #13216: internal error: stg_ap_pppppp_ret
by GHC 07 Feb '17

07 Feb '17

#13216: internal error: stg_ap_pppppp_ret -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: bug | Status: new Priority: normal | Milestone: 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): | Wiki Page: -------------------------------------+------------------------------------- We started getting the following from our app; though it's not reliably reproducible: {{{ internal error: stg_ap_pppppp_ret (GHC version 8.0.1 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Abort }}} Unfortunately I cannot share code, nor I can upgrade to GHC 8.0.2 due to work environment restrictions. My apologies for the worst bug report. Neither google nor Trac searches produced anything related. I'm wondering if anybody has seen this, or have any ideas where to look at. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13216> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

Re: [GHC] #1600: Optimisation: CPR the results of IO
by GHC 07 Feb '17

07 Feb '17

#1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8598 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Indeed. Start with one or two poster-child examples to show what the goal is; and check they work as expected. Only then go in with nofib. Also this is a long ticket. It would be good to write a decription somewhere (on the wiki page?) of what exactly the patch does. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:59> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13166: Warning: Can't find file "C:\...\lib/include\ghcversion.h" in directories
by GHC 07 Feb '17

07 Feb '17

#13166: Warning: Can't find file "C:\...\lib/include\ghcversion.h" in directories -------------------------------------+------------------------------------- Reporter: domenkozar | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Windows Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm not exactly sure yet where this is coming from, but I'd like to report an warning on Windows during preprocessing phase: {{{ [00:03:39] Preprocessing library cardano-sl-0.1.0.0... [00:03:39] Warning: Can't find file "C:\Users\appveyor\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.1\lib/include\ghcversion.h" in directories [00:03:39] src/Pos [00:03:39] . [00:03:39] .stack-work\dist\b7fec021\build [00:03:39] .stack-work\dist\b7fec021\build [00:03:39] .stack-work\dist\b7fec021\build\autogen [00:03:39] .stack-work\dist\b7fec021\build [00:03:39] C:\OpenSSL-Win64\include [00:03:39] C:\Users\appveyor\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\include [00:03:39] C:\projects\pos-haskell-prototype\rocksdb\include [00:03:39] C:\OpenSSL-Win64\include [00:03:39] C:\Users\appveyor\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\include [00:03:39] C:\projects\pos-haskell-prototype\rocksdb\include [00:03:39] C:\sr\snapshots\a78c6a89\lib\x86_64-windows-ghc-8.0.1 \vector-algorithms-0.7.0.1-8R8UpWgvBC926XMxBjYPpx\include [00:03:39] C:\sr\snapshots\a78c6a89\lib\x86_64-windows- ghc-8.0.1\zlib-0.6.1.2-4CWLN1T27kOJhNvXgy46ZV\include [00:03:39] C:\Users\appveyor\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.1\lib\process-1.4.2.0\include [00:03:39] C:\sr\snapshots\a78c6a89\lib\x86_64-windows- ghc-8.0.1\vector-0.11.0.0-BEDZb5o2QOhGbIm6ky7rl6\include [00:03:39] C:\sr\snapshots\a78c6a89\lib\x86_64-windows-ghc-8.0.1\old- time-1.1.0.3-IcvdkJUsE9M8t3io8peAEp\include [00:03:39] C:\Users\appveyor\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.1\lib\directory-1.2.6.2\include [00:03:39] C:\sr\snapshots\a78c6a89\lib\x86_64-windows- ghc-8.0.1\primitive-0.6.1.0-Ip44DqhfCp21tTUYbecwa\include [00:03:39] C:\Users\appveyor\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.1\lib\time-1.6.0.1\include [00:03:39] C:\Users\appveyor\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.1\lib\Win32-2.3.1.1\include [00:03:39] C:\sr\snapshots\a78c6a89\lib\x86_64-windows- ghc-8.0.1\network-2.6.3.1-nK9qnsiJR03CWuPIGMmX\include [00:03:39] C:\Users\appveyor\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.1\lib\bytestring-0.10.8.1\include [00:03:39] C:\Users\appveyor\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.1\lib\base-4.9.0.0\include [00:03:39] C:\Users\appveyor\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.1\lib \integer-gmp-1.0.0.1\include [00:03:39] C:\Users\appveyor\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.1\lib/include [00:03:39] Asked for by: src/Pos/CLI.hs at line 2 col 1 }}} It appears to trigger for each module using cpphs. The file is present, so I suspect the problem is in unix path character in `C:\Users\appveyor\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.1\lib/include\ghcversion.h`. Using verbose mode we can observe that's the case: {{{ "cpphs" "-DWITH_WEB" "-DWITH_WALLET" "-include" ".stack- work\dist\ca59d0ab\build\autogen\cabal_macros.h" "--cpp" "-I" ".stack- work\dist\ca59d0ab\build" "-I" ".stack-work\dist\ca59d0ab\build" "-I" ".stack-work\dist\ca59d0ab\build\autogen" "-I" ".stack- work\dist\ca59d0ab\build" "-I" "C:\OpenSSL-Win64\include" "-I" "C:\Users\Administrator\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\include" "-I" "C:\rocksdb\include" "-I" "C:\OpenSSL-Win64\include" "-I" "C:\Users\Administrator\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\include" "-I" "C:\rocksdb\includ e" "-I" "C:\sr\snapshots\b3566c00\lib\x86_64-windows-ghc-8.0.2\vector- algorithms-0.7.0.1-C2u1KYklHg84I6SQQVEAin\include" "-I" "C:\sr\snapshots\bb34f894\lib\x86_64-windows- ghc-8.0.2\zlib-0.6.1.2-7negTfm2ujt1gW4wr40MUp\include" "-I" "C:\sr\snapshots\bb34f894\lib\x86_64-windows- ghc-8.0.2\process-1.4.2.0-KoK49SuYVPk1TQ4YVt6ZK5\include" "-I" "C:\sr\snapshots\bb34f894\lib\x86_64-windows- ghc-8.0.2\vector-0.11.0.0-LMwQhhnXj8U3T5Bm1JFxG\include" "-I" "C:\sr\snapshots\bb34f894\lib\x86_64-windows-ghc-8.0.2\old- time-1.1.0.3-KWRsMSdY26c2L27Y9n9cyq\include" "-I" "C:\sr\snapshots\bb34f894\lib\x86_64-windows- ghc-8.0.2\directory-1.2.6.2-qiZgXsB5o98ZsOYUWltfF\include" "-I" "C:\sr\snapshots\bb34f894\lib\x86_64-windows- ghc-8.0.2\primitive-0.6.1.0-6AbSTw9JXz141LE5p6LGH\include" "-I" "C:\Users\Administrator\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.2\lib\time-1.6.0.1\include" "-I" "C:\Users\Administrator\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.2\lib\Win32-2.3.1.1\include" "-I" "C:\sr\snapshots\bb34f894\lib\x86_64-windows- ghc-8.0.2\network-2.6.3.1-AwRxOQvT8JM9e8zDFK7aCI\include" "-I" "C:\Users\Administrator\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.2\lib\bytestring-0.10.8. 1\include" "-I" "C:\Users\Administrator\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.2\lib\base-4.9.1.0\include" "-I" "C:\Users\Administrator\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.2\lib \integer-gmp-1.0.0.1\include" "-I" "C:\Users\Administrator\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.2\lib/include" "-D__GLASGOW_HASKELL__=800" "-include" "C:\Users\Administrator\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.2\lib/include\ghcversion.h" "-Dmingw32_BUILD_OS=1" "-Dx86_64_BUILD_ARCH=1" "-Dmingw32_HOST_OS=1" "-Dx86_64_HOST_ARCH=1" "-D__GLASGOW_HASKELL_TH__=1" "-D_ _SSE__=1" "-D__SSE2__=1" "-includeC:\Users\ADMINI~1\AppData\Local\Temp\2\ghc2384_0\ghc_18.h" "-x" "assembler-with-cpp" "src\Pos\Binary\Crypto.hs" "-o" "C:\Users\ADMINI~1\AppData\Local\Temp\2\ghc2384_0\ghc_17.hscpp" }}} I highly suspect https://github.com/ghc/ghc/blob/master/utils/ghc- pkg/Main.hs#L1956 since it does some unclear path mungling, probably leaving undosified suffix. Note that those functions were copied from `compiler/main/SysTools.hs` which changed significantly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13166> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #13235: (makeVersion [4, 9, 0, 0] <= makeVersion [4, 9]) == False
by GHC 06 Feb '17

06 Feb '17

#13235: (makeVersion [4, 9, 0, 0] <= makeVersion [4, 9]) == False -------------------------------------+------------------------------------- Reporter: varosi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.0.1 libraries/base | 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 have hit a strange bug in cabal project. Zeroes in Version have meaning, which is not logical (at least mathematically). See this example: {{{ import Data.Version makeVersion [4, 9, 0, 0] <= makeVersion [4, 9] False }}} I propose to add zeroes to the version with less numbers, so they could be equally compared. Related discussion: https://github.com/commercialhaskell/stack/issues/2948 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13235> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1600: Optimisation: CPR the results of IO
by GHC 06 Feb '17

06 Feb '17

#1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8598 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by akio): I've rebased the [https://github.com/takano-akio/ghc/commits/nested-cpr branch] on top of the join points work. In nofib, allocations are generally down but the difference is not very big: {{{ -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- bspt +0.0% +0.1% 0.007 0.007 0.0% compress2 +1.5% -0.9% 0.158 0.158 -3.7% fluid +1.6% -0.2% 0.007 0.007 0.0% infer +0.0% -1.2% 0.039 0.039 0.0% pic +0.1% -0.6% 0.005 0.005 0.0% solid +0.0% -6.6% 0.159 0.159 0.0% -------------------------------------------------------------------------------- Min -0.0% -6.6% -28.7% -28.8% -3.7% Max +1.6% +0.1% +4.3% +4.3% +6.7% Geometric Mean +0.1% -0.1% -14.7% -14.5% +0.0% }}} I'll look more carefully to see why the improvement is so small. I may have messed up something while rebasing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:58> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7102: Type family instance overlap accepted in ghci
by GHC 06 Feb '17

06 Feb '17

#7102: Type family instance overlap accepted in ghci -------------------------------------+------------------------------------- Reporter: exbb2 | Owner: rwbarton Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.4.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: T7102a, T7102 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2994 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"0abe7361249b0b4dc43dc66547451da8916b30bf/ghc" 0abe7361/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0abe7361249b0b4dc43dc66547451da8916b30bf" Don't replace type family instances with the same LHS in GHCi (#7102) This fixes the easy part of #7102 by removing the logic that lets the user replace a type family instance with a new one with the same LHS. As discussed on that ticket, this is unsound in general. Better to have the user redefine the type family from scratch. The example from comment:7 involving loading modules into ghci is not fixed yet; it actually doesn't rely on the instances having the same LHS. This commit adds an expect_broken test for that example as well. Test Plan: T7102a for the fix; T7102 is the test not fixed yet Reviewers: dfeuer, austin, bgamari, goldfire Reviewed By: dfeuer Subscribers: dfeuer, thomie Differential Revision: https://phabricator.haskell.org/D2994 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7102#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0