- ghc-tickets - Haskell.org

Re: [GHC] #1600: Optimisation: CPR the results of IO
by GHC 03 Aug '15

03 Aug '15

#1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: lowest | Milestone: 7.12.1 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 Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Yes, do rebase `wip/nested-cpr` on master, do a like-for-like `nofib` comparison. I'd quite like to see this land. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:49> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10155: [PATCH] Possibly incorrect stack pointer usage in StgRun() on x86_64
by GHC 03 Aug '15

03 Aug '15

#10155: [PATCH] Possibly incorrect stack pointer usage in StgRun() on x86_64 -------------------------------------+------------------------------------- Reporter: stengel | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.8.1 System | Operating System: Unknown/Multiple Keywords: | Type of failure: Other Architecture: x86_64 | Blocked By: (amd64) | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The STG_RETURN code from StgCRun.c is incorrect for x86_64 variants where the ABI doesn't impose a mandatory red zone for the stack, like on Windows or Xen/HaLVM. The current implementation restores the stack pointer first, which effectively marks the area with the saved registers as reusable. Later, the CPU registers are restored from this "free" area. This ordering happens to work by accident on operating systems that strictly adhere to the System V ABI, because any interrupt/signal delivery is guaranteed to leave the first 128 bytes past the stack pointer untouched (red zone). On other systems this might result in corrupted CPU registers if an interruption happens just after restoring the stack pointer. The red zone is usually only used by small leaf functions to avoid updates to the stack pointer and exploiting it doesn't give us any advantage in this case. The attached patch reorders the register access, so that the stack pointer is restored last. It's also shorter by one instruction. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10155> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10543: MacOS: validate fails on \u
by GHC 03 Aug '15

03 Aug '15

#10543: MacOS: validate fails on \u -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.10.1 System | Operating System: MacOS X Keywords: | Type of failure: Building GHC Architecture: | failed Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Running validate on MacOS fails with this error (due to `-Werror`): {{{ libraries/Cabal/Cabal/Distribution/Simple/BuildTarget.hs:392:24: error: \u used with no following hex digits; treating as '\' followed by identifier [-Werror,-Wunicode] matchBuildTarget pkg = \utarget fexists -> ^ 1 error generated. make[1]: *** [utils/ghc-cabal/dist/build/tmp/ghc-cabal] Error 1 }}} I am using ghc from homebrew to bootstrap on OS X 10.10.3. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10543> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10729: Type inference in GADT pattern matches
by GHC 03 Aug '15

03 Aug '15

#10729: Type inference in GADT pattern matches -------------------------------------+------------------------------------- Reporter: mniip | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When pattern matching against GADT constructors, GHC seems to have issues with inferring the type of the resulting expression. Minimal example: Assume the datatype: {{{ data D a where D :: D () }}} A simple function that pattern matches on it: {{{ a D = () }}} It is expected to have type `D a -> ()` (Note: not `D () -> ()`, existence of a `D` should ensure `()`, not the type signature), but instead it errors: {{{ error: Couldn't match expected type ‘t’ with actual type ‘()’ ‘t’ is untouchable inside the constraints: t1 ~ () bound by a pattern with constructor: D :: D (), in an equation for ‘a’ ‘t’ is a rigid type variable bound by the inferred type of a :: D t1 -> t }}} Note that the error goes away when we annotate the type of the function: {{{ b :: D a -> () -- no error b D = () }}} Or if we supply another branch that clarifies the type: {{{ c D = () -- no error c _ = () }}} But it reappears if the other branch doesn't provide anything to infer from: {{{ d D = () -- error d _ = undefined }}} The same issue happens in `case`: {{{ e x = case x of D -> () -- error }}} But only when the value being matched comes from outside: {{{ f = case D of D -> () -- no error }}} This behavior is reprooducible and identical in 7.8.4. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10729> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #7944: GHC goes into an apparently infinite loop at -O2
by GHC 03 Aug '15

03 Aug '15

#7944: GHC goes into an apparently infinite loop at -O2 -------------------------------------+------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: #5550 #8852 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by amosrobinson): Hmm. So I thought in this case, the is_too_recursive check should stop specialisation after a few runs. The counting of recursive constructors is only going down through applications though: I wonder whether it needs to handle lets, cases, etc? https://github.com/ghc/ghc/blob/master/compiler/specialise/SpecConstr.hs#L1… -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7944#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7944: GHC goes into an apparently infinite loop at -O2
by GHC 03 Aug '15

03 Aug '15

#7944: GHC goes into an apparently infinite loop at -O2 -------------------------------------+------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: #5550 #8852 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): Yes, infinite loop with ghc-7.10.2 as well as ghc-7.11.20150711 (HEAD). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7944#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7944: GHC goes into an apparently infinite loop at -O2
by GHC 03 Aug '15

03 Aug '15

#7944: GHC goes into an apparently infinite loop at -O2 -------------------------------------+------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: #5550 #8852 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by amosrobinson): Hi, I had a go reducing this more. I only have ghc 7.8.3, so would someone be able to try this on head? {{{ #!haskell module T7944 where import GHC.Exts -- Force specialisation of "go" data SPEC = SPEC | SPEC2 {-# ANN type SPEC ForceSpecConstr #-} -- This is more or less just an ordinary fold go :: SPEC -> [a] -> IntMap a -> IntMap a go SPEC [] m = m go SPEC (_:xs) m = go SPEC xs -- This would be the "worker function" of the fold $ Unary m -- Both constructors are necessary, despite only one being used data IntMap a = Nil | Unary (IntMap a) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7944#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7944: GHC goes into an apparently infinite loop at -O2
by GHC 03 Aug '15

03 Aug '15

#7944: GHC goes into an apparently infinite loop at -O2 -------------------------------------+------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: #5550 #8852 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): `-fno-spec-constr` indeed fixes the problem. I reduced the test code some more, but it still requires `vector`. {{{ $ cabal install vector # cabal gave me vector-0.10.12.3 $ ghc-7.10.2 -O2 --make Repro.hs # also fails with ghc-7.11.20150711 }}} {{{#!haskell module Repro where import qualified Data.Vector as V import qualified IntMap as I constructMap :: V.Vector (Int, [Int]) -> I.IntMap [Int] constructMap = V.foldl' go I.empty where go m (k,v) = snd $ I.insertWith (++) k v m }}} {{{#!haskell module IntMap where import Data.Bits ((.&.), complement, xor) import GHC.Num (Num(..)) import GHC.Real (fromIntegral) type Nat = Word natFromInt :: Key -> Nat natFromInt i = fromIntegral i intFromNat :: Nat -> Key intFromNat w = fromIntegral w data IntMap a = Nil | Tip Key a | Bin Prefix Mask (IntMap a) (IntMap a) type Prefix = Int type Mask = Int type Key = Int empty :: IntMap a empty = Nil insertWith :: (a -> a -> a) -> Key -> a -> IntMap a -> (Maybe a, IntMap a) insertWith f k x t = case t of Bin p m l r | nomatch k p m -> (Nothing, join k (Tip k x) p t) | zero k m -> let (found, l') = insertWith f k x l in (found, Bin p m l' r) | otherwise -> let (found, r') = insertWith f k x r in (found, Bin p m l r') Tip ky y | k == ky -> (Just y, Tip k (f x y)) | otherwise -> (Nothing, join k (Tip k x) ky t) Nil -> (Nothing, Tip k x) join :: Prefix -> IntMap a -> Prefix -> IntMap a -> IntMap a join p1 t1 p2 t2 | zero p1 m = Bin p m t1 t2 | otherwise = Bin p m t2 t1 where m = branchMask p1 p2 p = mask p1 m zero :: Key -> Mask -> Bool zero i m = (natFromInt i) .&. (natFromInt m) == 0 nomatch :: Key -> Prefix -> Mask -> Bool nomatch i p m = (mask i m) /= p mask :: Key -> Mask -> Prefix mask i m = maskW (natFromInt i) (natFromInt m) maskW :: Nat -> Nat -> Prefix maskW i m = intFromNat (i .&. (complement (m-1) `xor` m)) branchMask :: Prefix -> Prefix -> Mask branchMask p1 p2 = intFromNat (highestBitMask (natFromInt p1)) highestBitMask :: Nat -> Nat highestBitMask x1 = x1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7944#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10727: compiler/rename/RnSource.lhs:429:14-81: Irrefutable pattern failed
by GHC 03 Aug '15

03 Aug '15

#10727: compiler/rename/RnSource.lhs:429:14-81: Irrefutable pattern failed -------------------------------------+------------------------------------- Reporter: doelie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Keywords: | Operating System: Linux Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- see bug.sh in: http://zwizwa.be/stuff/ghc_bug.tgz make: Entering directory `/home/tom/pub/darcs/meta/siso' ghc Test.hs [ 9 of 10] Compiling Code ( Code.hs, Code.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.4.1 for x86_64-unknown-linux): compiler/rename/RnSource.lhs:429:14-81: Irrefutable pattern failed for pattern Data.Maybe.Just (inst_tyvars, _, SrcLoc.L _ cls, _) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10727> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #7521: Accelerate examples does not compile with default value of -fsimpl-tick-factor
by GHC 02 Aug '15

02 Aug '15

#7521: Accelerate examples does not compile with default value of -fsimpl-tick- factor -------------------------------------+------------------------------------- Reporter: eamsden | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * priority: high => normal Comment: I'm not even convinced this should be considered to be a bug. Various programs require varying amounts of effort from the simplifier; it is fair to say that `accelerate` sits on the high end of this spectrum. Do we really want to set the default simplifier tick factor to accommodate this extreme case? For the moment I'm going to lower the priority of this ticket, although arguably we could just close it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7521#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0