February 2016 - ghc-tickets

[GHC] #10383: AArch64: get GHC Calling convention working
by GHC 07 Dec '16

07 Dec '16

#10383: AArch64: get GHC Calling convention working -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: feature | Status: new request | Milestone: 7.12.1 Priority: normal | Version: 7.11 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: Building GHC Architecture: aarch64 | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Building on AArch64 via the LLVM abckend has been working for some time. Its now time to get `("Unregisterised", "NO")` working as well. Enabling GHC calling convention can be done with this patch to `configure.ac`: {{{ diff --git a/configure.ac b/configure.ac index d5d9ab3..a11e5af 100644 --- a/configure.ac +++ b/configure.ac @@ -241,7 +241,7 @@ AC_SUBST(SOLARIS_BROKEN_SHLD) dnl ** Do an unregisterised build? dnl -------------------------------------------------------------- case "$HostArch" in - i386|x86_64|powerpc|arm) + i386|x86_64|powerpc|arm|aarch64) UnregisterisedDefault=NO ;; *) }}} but when building it this way, the stage2 compiler dies will `Illegal instructon`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10383> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 41

[GHC] #10332: AArch64 : divbyzero test fails
by GHC 07 Dec '16

07 Dec '16

#10332: AArch64 : divbyzero test fails -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: aarch64 | Type of failure: Incorrect result Test Case: | at runtime testsuite/tests/rts/divbyzero.hs | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- On AArch64/Linux the test in `testsuite/tests/rts/divbyzero.hs` which is: {{{ main :: IO () main = print (5 `divInt` 0) }}} just prints "0" and exits with a zero status code. From the "ARMv8 Instriction Set Overview" document I found (wasn't able to find anything more recent): https://www.element14.com/community/servlet/JiveServlet/downloadBody/41836-… Section 3.6 says "There is no hardware check for “divide by zero”, but this check can be performed in the shadow of a long latency division. A divide by zero writes zero to the destination register." Looks like we need extra code to check for this, but not sure how to report it. Should probably look at what GCC and Clang do. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10332> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10174: AArch64 : ghc-stage2 segfaults compiling libraries/parallel
by GHC 07 Dec '16

07 Dec '16

#10174: AArch64 : ghc-stage2 segfaults compiling libraries/parallel -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: aarch64 | Type of failure: Building GHC Test Case: | failed Blocking: | Blocked By: Differential Revisions: | Related Tickets: -------------------------------------+------------------------------------- Compiling git HEAD (e02ef0e6d4eefa5f0) on AArch64 hardware using ghc-7.6.3 from Debian as the bootstrap compiler. LLVM is version 3.6. It fails with: {{{ "inplace/bin/ghc-stage2" -hisuf hi -osuf o -hcsuf hc -static -H64m -O0 -fllvm \ -this-package-key paral_2NTMt5X9WUG6LNupBFIZti -hide-all-packages -i \ -ilibraries/parallel/. -ilibraries/parallel/dist-install/build \ -ilibraries/parallel/dist-install/build/autogen \ -Ilibraries/parallel/dist-install/build \ -Ilibraries/parallel/dist-install/build/autogen -Ilibraries/parallel/. \ -optP-include -optPlibraries/parallel/dist- install/build/autogen/cabal_macros.h \ -package-key array_BLJREAlFJ4zJ2kSDphVieY -package-key base_8gvrDSBdaidLA14EDtK6ja \ -package-key conta_1uqbEcrmZiO1C91Z8ePoyI -package-key deeps_Bw45clVBNVT4S1LLyUOPfh \ -Wall -feager-blackholing -XHaskell2010 -O -fllvm -no-user-package- db -rtsopts \ -odir libraries/parallel/dist-install/build \ -hidir libraries/parallel/dist-install/build \ -stubdir libraries/parallel/dist-install/build \ -dynamic-too -c libraries/parallel/./Control/Parallel/Strategies.hs \ -o libraries/parallel/dist- install/build/Control/Parallel/Strategies.o \ -dyno libraries/parallel/dist- install/build/Control/Parallel/Strategies.dyn_o libraries/parallel/ghc.mk:5: recipe for target 'libraries/parallel/dist-install/build/Control/Parallel/Strategies.o' failed make[1]: *** [libraries/parallel/dist- install/build/Control/Parallel/Strategies.o] Segmentation fault }}} It seems that `inplace/lib/bin/ghc-stage1` (which is working fine) is statically linked to all the Haskell libraries where as `inplace/lib/bin /ghc-stage2` is dynamically linked which would explain why stage1 works fine and stage2 segfaults. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10174> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #11578: Fix GHC on AArch64/Arm64
by GHC 07 Dec '16

07 Dec '16

#11578: Fix GHC on AArch64/Arm64 --------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: aarch64 | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+------------------------------------- Raising this to track discussion about GHC on Arm64. There is already some discussion in ticket #11206 (ARM is generally a disaster), but that ticket is about 32 bit Arm which is vastly different and is now mostly fixed. Information worth saving from #11206: * GHC 7.8.4 from Debian can build the ghc-8.0 branch, but cannot build HEAD because HEAD requires ghc-7.10 to build. * GHC 7.10 from Debian is broken because of an unfixed bug in llvm-3.5.2. * User @mfox reports that ghc-7.10 does build against llvm-3.7 and results in a compiler that can build HEAD. * That GHC 7.10 can be build against llvm-3.7 is a happy accident. Versions of GHC are usually locked to a specific version of LLVM. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11578> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #10962: Improved arithmetic primops
by GHC 07 Dec '16

07 Dec '16

#10962: Improved arithmetic primops -------------------------------------+------------------------------------- Reporter: nkaretnikov | Owner: nkaretnikov Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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: | https://ghc.haskell.org/trac/ghc/wiki/ImprovedArithmeticPrimops -------------------------------------+------------------------------------- See the todo list on the wiki page. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10962> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #8224: Excessive system time -- new IO manager problem?
by GHC 07 Dec '16

07 Dec '16

#8224: Excessive system time -- new IO manager problem? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Keywords: IO Manager, | Operating System: Linux System Time | Type of failure: Runtime Architecture: x86_64 (amd64) | performance bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- This is an issue that came to light when testing the patches on #910. You can see some of the numbers there. Basically, recent GHC HEAD builds, running a large number of threads blocked on MVars will result in burning a lot of system time. The attached file provides a mediocre reproducer. With it, you can see that building with HEAD as of Aug 31st and running with `-RTS -N32` will result in around 200ms system time, whereas GHC 7.6.3 spends about 30ms in system time. This shows the disparity, but the result is not that egregious. A more noticeable example is on ticket #910, where when running on 31 threads, there is an 8 minutes of system time for 17 minutes of user time, and yet at one thread that system time drops to under two seconds! {{{ 1 thread: real 1m20.028s user 1m17.921s sys 0m1.768s 31 threads: real 1m27.445s user 17m0.314s sys 8m0.175s }}} It needs to be determined whether this system time is a result of the parallel compilation patches on #910, or whether it is a new problem with the runtime system, and in particular with the parallel IO manager. I am inclined to believe that compiling in parallel involves extra IO (repeatedly reading interface files?), but not eight minutes of it!! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8224> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 40

[GHC] #11548: Absolutely misleading error message on kind error
by GHC 07 Dec '16

07 Dec '16

#11548: Absolutely misleading error message on kind error -------------------------------------+------------------------------------- Reporter: mniip | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs module Bug where import Data.Proxy fun :: Proxy a -> () fun Proxy = () bug :: () bug = fun (Proxy :: Proxy Maybe) }}} {{{#!hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:9:12: error: • Expected kind ‘Proxy Maybe’, but ‘Data.Proxy.Proxy :: Proxy Maybe’ has kind ‘Proxy Maybe’ • In the first argument of ‘fun’, namely ‘(Proxy :: Proxy Maybe)’ In the expression: fun (Proxy :: Proxy Maybe) In an equation for ‘bug’: bug = fun (Proxy :: Proxy Maybe) }}} 7.10 gives the appropriate `Couldn't match kind ‘* -> *’ with ‘*’` message. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11548> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #11485: Very unhelpful message resulting from kind mismatch
by GHC 07 Dec '16

07 Dec '16

#11485: Very unhelpful message resulting from kind mismatch -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following code: {{{#!hs module Foo where import Data.Typeable tyConOf :: Typeable a => Proxy a -> TyCon tyConOf = typeRepTyCon . typeRep tcList :: TyCon tcList = tyConOf (Proxy :: Proxy []) }}} fails because `-XPolyKinds` is not enabled. But the error message that you get is quite different on GHC 7.10 and 8.0. On GHC 7.10.3: {{{ [1 of 1] Compiling Foo ( Foo.hs, Foo.o ) Foo.hs:9:19: Couldn't match kind ‘* -> *’ with ‘*’ Expected type: Proxy a0 Actual type: Proxy [] In the first argument of ‘tyConOf’, namely ‘(Proxy :: Proxy [])’ In the expression: tyConOf (Proxy :: Proxy []) In an equation for ‘tcList’: tcList = tyConOf (Proxy :: Proxy []) }}} But on GHC 8.0.1-rc1: {{{ Foo.hs:9:19: error: • Expected kind ‘Proxy []’, but ‘Data.Proxy.Proxy :: Proxy []’ has kind ‘Proxy []’ • In the first argument of ‘tyConOf’, namely ‘(Proxy :: Proxy [])’ In the expression: tyConOf (Proxy :: Proxy []) In an equation for ‘tcList’: tcList = tyConOf (Proxy :: Proxy []) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11485> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10812: High memory usage
by GHC 02 Dec '16

02 Dec '16

#10812: High memory usage -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Hello, lets consider following program: {{{ {-# LANGUAGE NoMonomorphismRestriction #-} import System.Mem.Weak import Control.Concurrent import System.Mem data Tst a = Tst a deriving (Show, Eq) tst a = do let arr = [0 .. a*a*a] v = Tst (seq arr arr) ptr <- mkWeakPtr v Nothing return ptr main = do ptrs <- mapM tst [1..100000000] --performGC --performMajorGC --performMinorGC threadDelay 1000000 xr <- mapM deRefWeak ptrs print $ length $ filter (/= Nothing) xr threadDelay 5000000 return () }}} It simply creates 10 million of weak references to values of {{{Tst}}}. These weak pointers are returned in the main function. After that we sleep a second and ask how meany references are alive. I get the {{{0}}} as a result here - so everything seems ok - garbage collection worked. There is a problem though - somehow the memory was not released, because on the second 5-second sleep the program uses over 14 Gb of RAM on my computer. I'm compiling it simply with {{{ghc -O2 Main.hs}}}. I'm pretty sure this is a bug, because such behaviour is not expected I think. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10812> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #8848: Warning: Rule too complicated to desugar
by GHC 01 Dec '16

01 Dec '16

#8848: Warning: Rule too complicated to desugar ------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I've a very very modest application of Specialize to fixed sized lists in some of my code which seems to trip up the specialization machinery. Is there any flags I can pass GHC to make sure it doesn't give up on these specialize calls? is the only work around to write my own monomorphic versions and add some hand written rewrite rules?! {{{ rc/Numerical/Types/Shape.hs:225:1: Warning: RULE left-hand side too complicated to desugar let { $dFunctor_a3XB :: Functor (Shape ('S 'Z)) [LclId, Str=DmdType] $dFunctor_a3XB = Numerical.Types.Shape.$fFunctorShape @ 'Z $dFunctor_a3Rn } in map2 @ a @ b @ c @ ('S ('S 'Z)) (Numerical.Types.Shape.$fApplicativeShape @ ('S 'Z) (Numerical.Types.Shape.$fFunctorShape @ ('S 'Z) $dFunctor_a3XB) (Numerical.Types.Shape.$fApplicativeShape @ 'Z $dFunctor_a3XB Numerical.Types.Shape.$fApplicativeShape0)) src/Numerical/Types/Shape.hs:226:1: Warning: RULE left-hand side too complicated to desugar let { $dFunctor_a3XG :: Functor (Shape ('S 'Z)) [LclId, Str=DmdType] $dFunctor_a3XG = Numerical.Types.Shape.$fFunctorShape @ 'Z $dFunctor_a3Rn } in let { $dFunctor_a3XF :: Functor (Shape ('S ('S 'Z))) [LclId, Str=DmdType] $dFunctor_a3XF = Numerical.Types.Shape.$fFunctorShape @ ('S 'Z) $dFunctor_a3XG } in map2 @ a @ b @ c @ ('S ('S ('S 'Z))) (Numerical.Types.Shape.$fApplicativeShape @ ('S ('S 'Z)) (Numerical.Types.Shape.$fFunctorShape @ ('S ('S 'Z)) $dFunctor_a3XF) (Numerical.Types.Shape.$fApplicativeShape @ ('S 'Z) $dFunctor_a3XF (Numerical.Types.Shape.$fApplicativeShape @ 'Z $dFunctor_a3XG Numerical.Types.Shape.$fApplicativeShape0))) }}} the associated code (smashed into a single module ) is {{{ {-# LANGUAGE DataKinds, GADTs, TypeFamilies, ScopedTypeVariables #-} {-# LANGUAGE DeriveDataTypeable #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE BangPatterns #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE StandaloneDeriving #-} {-# LANGUAGE CPP #-} {-# LANGUAGE DeriveFunctor #-} {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE NoImplicitPrelude #-} module Numerical.Types.Shape where import GHC.Magic import Data.Data import Data.Typeable() import Data.Type.Equality import qualified Data.Monoid as M import qualified Data.Functor as Fun import qualified Data.Foldable as F import qualified Control.Applicative as A import Prelude hiding (foldl,foldr,init,scanl,scanr,scanl1,scanr1) data Nat = S !Nat | Z deriving (Eq,Show,Read,Typeable,Data) #if defined(__GLASGOW_HASKELL_) && (__GLASGOW_HASKELL__ >= 707) deriving instance Typeable 'Z deriving instance Typeable 'S #endif type family n1 + n2 where Z + n2 = n2 (S n1') + n2 = S (n1' + n2) -- singleton for Nat data SNat :: Nat -> * where SZero :: SNat Z SSucc :: SNat n -> SNat (S n) --gcoerce :: (a :~: b) -> ((a ~ b) => r) -> r --gcoerce Refl x = x --gcoerce = gcastWith -- inductive proof of right-identity of + plus_id_r :: SNat n -> ((n + Z) :~: n) plus_id_r SZero = Refl plus_id_r (SSucc n) = gcastWith (plus_id_r n) Refl -- inductive proof of simplification on the rhs of + plus_succ_r :: SNat n1 -> Proxy n2 -> ((n1 + (S n2)) :~: (S (n1 + n2))) plus_succ_r SZero _ = Refl plus_succ_r (SSucc n1) proxy_n2 = gcastWith (plus_succ_r n1 proxy_n2) Refl type N0 = Z type N1= S N0 type N2 = S N1 type N3 = S N2 type N4 = S N3 type N5 = S N4 type N6 = S N5 type N7 = S N6 type N8 = S N7 type N9 = S N8 type N10 = S N9 {- Need to sort out packed+unboxed vs generic approaches see ShapeAlternatives/ for -} infixr 3 :* {- the concern basically boils down to "will it specialize / inline well" -} newtype At a = At a deriving (Eq, Ord, Read, Show, Typeable, Functor) data Shape (rank :: Nat) a where Nil :: Shape Z a (:*) :: !(a) -> !(Shape r a ) -> Shape (S r) a --deriving (Show) #if defined(__GLASGOW_HASKELL_) && (__GLASGOW_HASKELL__ >= 707) deriving instance Typeable Shape #endif instance Eq (Shape Z a) where (==) _ _ = True instance (Eq a,Eq (Shape s a))=> Eq (Shape (S s) a ) where (==) (a:* as) (b:* bs) = (a == b) && (as == bs ) instance Show (Shape Z a) where show _ = "Nil" instance (Show a, Show (Shape s a))=> Show (Shape (S s) a) where show (a:* as) = show a ++ " :* " ++ show as -- at some point also try data model that -- has layout be dynamicly reified, but for now -- keep it phantom typed for sanity / forcing static dispatch. -- NB: may need to make it more general at some future point --data Strided r a lay = Strided { getStrides :: Shape r a } {-# INLINE reverseShape #-} reverseShape :: Shape n a -> Shape n a reverseShape Nil = Nil reverseShape list = go SZero Nil list where go :: SNat n1 -> Shape n1 a-> Shape n2 a -> Shape (n1 + n2) a go snat acc Nil = gcastWith (plus_id_r snat) acc go snat acc (h :* (t :: Shape n3 a)) = gcastWith (plus_succ_r snat (Proxy :: Proxy n3)) (go (SSucc snat) (h :* acc) t) instance Fun.Functor (Shape Z) where fmap = \ _ Nil -> Nil --{-# INLINE fmap #-} instance (Fun.Functor (Shape r)) => Fun.Functor (Shape (S r)) where fmap = \ f (a :* rest) -> f a :* Fun.fmap f rest --{-# INLINE fmap #-} instance A.Applicative (Shape Z) where pure = \ _ -> Nil --{-# INLINE pure #-} (<*>) = \ _ _ -> Nil --{-# INLINE (<*>) #-} instance A.Applicative (Shape r)=> A.Applicative (Shape (S r)) where pure = \ a -> a :* (A.pure a) --{-# INLINE pure #-} (<*>) = \ (f:* fs) (a :* as) -> f a :* (inline (A.<*>)) fs as --{-# INLINE (<*>) #-} instance F.Foldable (Shape Z) where foldMap = \ _ _ -> M.mempty --{-# fold #-} foldl = \ _ init _ -> init foldr = \ _ init _ -> init foldr' = \_ !init _ -> init foldl' = \_ !init _ -> init instance (F.Foldable (Shape r)) => F.Foldable (Shape (S r)) where foldMap = \f (a:* as) -> f a M.<> F.foldMap f as foldl' = \f !init (a :* as) -> let next = f init a in next `seq` F.foldl f next as foldr' = \f !init (a :* as ) -> f a $! F.foldr f init as foldl = \f init (a :* as) -> let next = f init a in F.foldl f next as foldr = \f init (a :* as ) -> f a $ F.foldr f init as -- map2 :: (A.Applicative (Shape r))=> (a->b ->c) -> (Shape r a) -> (Shape r b) -> (Shape r c ) map2 = \f l r -> A.pure f A.<*> l A.<*> r {-# SPECIALIZE map2 :: (a->b->c)-> (Shape Z a )-> Shape Z b -> Shape Z c #-} {-# SPECIALIZE map2 :: (a->b->c)-> (Shape (S Z) a )-> Shape (S Z) b -> Shape (S Z) c #-} {-# SPECIALIZE map2 :: (a->b->c)-> (Shape (S (S Z)) a )-> Shape (S (S Z)) b -> Shape (S (S Z)) c #-} {-# SPECIALIZE map2 :: (a->b->c)-> (Shape (S (S(S Z))) a )-> Shape (S (S (S Z))) b -> Shape (S (S(S Z))) c #-} -- {-# INLINABLE map2 #-} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8848> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17