- ghc-tickets - Haskell.org

Re: [GHC] #6087: Join points need strictness analysis
by GHC 20 Dec '16

20 Dec '16

#6087: Join points need strictness analysis -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Resolution: | Keywords: JoinPoints 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 simonpj): * keywords: => JoinPoints -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6087#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5302: Unused arguments in join points
by GHC 20 Dec '16

20 Dec '16

#5302: Unused arguments in join points -------------------------------------+------------------------------------- Reporter: reinerp | Owner: simonpj Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: JoinPoints 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 simonpj): * keywords: => JoinPoints -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5302#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12996: Memory leak in recursion when switching from -O1 to -O2
by GHC 20 Dec '16

20 Dec '16

#12996: Memory leak in recursion when switching from -O1 to -O2 -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: Memory leak, | Operating System: Unknown/Multiple optimization | Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- For example code see attachment. When compiling with -O1 the code behaves as expected with each loop taking about the same amount of time. At -O2 each iteration takes (nonlinear) more time than the last and leaks memory. It gets slow enough that I never bothered to let it run past 40 iterations since the slowdown seems to be exponential. I initially hit the bug in code using a Set instead of list but turns out the issue can be reduced to an example with lists. Removing either filter, pattern matching or changing the loop fixes the issue. I tested it under the following conditions: * Compiler flags: -fno-full-laziness/No flags * Compiler versions: GHC 8.0.1 and 7.10.3e * Operating Systems: Windows 10, Linux Mint In every case -O1 works as expected with -O2 showing exponential slowdown with each iteration. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12996> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #13006: Possible program should type check but does not using Implicit Parameters and Vectors
by GHC 20 Dec '16

20 Dec '16

#13006: Possible program should type check but does not using Implicit Parameters and Vectors -------------------------------------+------------------------------------- Reporter: clinton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I think (but I'm not sure) that the following code should type check. This will require using the 'vector' package to illustrate this issue, sorry I couldn't create an example without it. Either uncommenting the explicit `m ()` signature or changing the type to the simpler `D m` data type will allow the code to compile. {{{ {-# LANGUAGE ImplicitParams #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE KindSignatures #-} import Data.Vector.Unboxed.Mutable (MVector) import Control.Monad.Primitive (PrimMonad, PrimState) data D (x :: * -> *) type T m = MVector (PrimState m) Int --type T m = D m h :: forall m. PrimMonad m => T m -> m () h x = let f _ = (let ?v = x in g) {- :: m () -} in f undefined g :: (PrimMonad m , ?v :: T m) => m () g = undefined main = pure () }}} Alternatively, including `g` into the let binding as opposed to the top level will also compile: {{{ {-# LANGUAGE ImplicitParams #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE KindSignatures #-} import Data.Vector.Unboxed.Mutable (MVector) import Control.Monad.Primitive (PrimMonad, PrimState) data D (x :: * -> *) type T m = MVector (PrimState m) Int --type T m = D m h :: forall m. PrimMonad m => T m -> m () h x = let f _ = (let ?v = x in g) {- :: m () -} g :: (PrimMonad m , ?v :: T m) => m () g = undefined in f undefined main = pure () }}} Perhaps this isn't a bug and has to do with the rank-2 type inside of Vector, but I'm just putting in this bug report to confirm. This is an issue as of 8.0.2-rc2. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13006> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #13010: module imports form a cycle instead of failing to parse
by GHC 20 Dec '16

20 Dec '16

#13010: module imports form a cycle instead of failing to parse -------------------------------------+------------------------------------- Reporter: MarcelineVQ | 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: -------------------------------------+------------------------------------- Some issue of parsing is causing certain module imports not to respect the proper format for a module name: `modid → {conid .} conid (modules)` A module import ending in numbers or a dot may be treated as if the . or .<numbers> weren't there. I would expect these to be parse errors instead of falling back to their 'parent', that's surely vague so here's examples. Minimally: `echo "module Lib where import Lib. " > test.hs && ghc test.hs` `echo "module Lib where import Lib.123 " > test.hs && ghc test.hs` Will both result in: {{{ Module imports form a cycle: module ‘Lib’ (test.hs) imports itself }}} This is an error because it's not importing itself, it's importing Lib. or Lib.123 which are invalid module names. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13010> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7298: GHCi is setting stdin/stdout to NoBuffering in runghc when DYNAMIC_GHC_PROGRAMS=YES
by GHC 20 Dec '16

20 Dec '16

#7298: GHCi is setting stdin/stdout to NoBuffering in runghc when DYNAMIC_GHC_PROGRAMS=YES -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: high | Milestone: Component: GHCi | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghc-e/should_run/T2228 Blocked By: | Blocking: Related Tickets: #2228 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => Comment: This is still not fixed, it seems like no one is terribly eager to see it fixed, and the fix won't be terrible simple. Consequently I'm going to un- milestone this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7298#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5775: Inconsistency in demand analysis
by GHC 20 Dec '16

20 Dec '16

#5775: Inconsistency in demand analysis -------------------------------------+------------------------------------- Reporter: rl | Owner: Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.5 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: Bumping off to 8.4 due to lack of owner. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5775#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7325: threadDelay mistreats minBound and maxBound in some configurations
by GHC 20 Dec '16

20 Dec '16

#7325: threadDelay mistreats minBound and maxBound in some configurations -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 7.6.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | base/tests/T8089 Blocked By: | Blocking: Related Tickets: #9722 | Differential Rev(s): Phab:D2861 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"c0c1f801f4ca26f1db68ac527341a1cf051cb7d6/ghc" c0c1f801/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c0c1f801f4ca26f1db68ac527341a1cf051cb7d6" Mark T8089 as unbroken since #7325 is now resolved }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7325#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11522: maxStkSize can overflow
by GHC 20 Dec '16

20 Dec '16

#11522: maxStkSize can overflow -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.8.4 System | 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 `maxStkSize` field of `GC_FLAGS` is a `nat`, or `unsigned int`. It's measured in words, but still 32G is not an unreasonable amount of memory by today's standards. Maybe it's unlikely that anyone would want to set the stack size limit to more than 32G. But if you happen to have just over 40G of physical memory then the default stack size limit will overflow to a value just above zero and then Bad Things would happen. If we want to actually enforce stack limits that are greater than 2^32^ words, we would need to increase the size of the `tot_stack_size` field of a TSO also. Simple test of overflow behavior: `ghci +RTS -K32.0001G` will exit with a stack overflow. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11522> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11502: Scrutinize use of 'long' in rts/
by GHC 20 Dec '16

20 Dec '16

#11502: Scrutinize use of 'long' in rts/ -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.10.3 System | 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: -------------------------------------+------------------------------------- In commit 53055bb5023e8cc145ad8a9cd36ac56cee4695b0 (#5656), several uses of `int` in the rts were replaced by `long`, to avoid potential overflows for some calculations. On Windows though, `int` and `long` have the same size (4 bytes). Carefully go through all uses of `long` in `rts/`, and replace by one of the types from `includes/stg/Types.h`: * `long` -> `StgInt` or `StgInt64` * `unsigned long` -> `StgWord` or `StgWord64` -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11502> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7