- ghc-tickets - Haskell.org

[GHC] #12735: Evaluate the feasibility of using lld for linking
by GHC 02 Dec '16

02 Dec '16

#12735: Evaluate the feasibility of using lld for linking -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System (Linker) | 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: -------------------------------------+------------------------------------- Our runtime system's linker a represents a significant amount of rather tricky code. We have in the past attempted to jettison it by moving to dynamic linking, although this lead to its own set of issues (see [DynamicLinkingDebate]). Another approach would be to let someone else implement our linker for us. While in the past linkers were rather monolithic things, today there exists LLVM's `lld` [http://lld.llvm.org/|linker] Like the other LLVM projects, its design is quite modular and can be used as a library. It seems likely that it could be made to do our bidding with enough effort. The question, of course, is whether this effort is greater than the effort we currently spend on the runtime linker. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12735> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #11445: Turn on SplitSections by default
by GHC 02 Dec '16

02 Dec '16

#11445: Turn on SplitSections by default -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 11285 Related Tickets: | Differential Rev(s): Phab:D1800 Wiki Page: | -------------------------------------+------------------------------------- Comment (by refold): @awson Please do whatever is easiest for you. If you don't want to bother with integrating your patches into upstream `binutils`, maybe someone else is, so please at least open source them. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11445#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #11445: Turn on SplitSections by default
by GHC 02 Dec '16

02 Dec '16

#11445: Turn on SplitSections by default -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 11285 Related Tickets: | Differential Rev(s): Phab:D1800 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dobenour): * cc: awson (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11445#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #11445: Turn on SplitSections by default
by GHC 02 Dec '16

02 Dec '16

#11445: Turn on SplitSections by default -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 11285 Related Tickets: | Differential Rev(s): Phab:D1800 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dobenour): awson: could GHC have the new linker script embedded into it, so that GHC can use it automatically? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11445#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11744: Latest Xcode update violates POSIX compliance of `nm -P`
by GHC 02 Dec '16

02 Dec '16

#11744: Latest Xcode update violates POSIX compliance of `nm -P` ----------------------------------------+--------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- TLDR: Apple messed up again and broke POSIX compliance luite ran into problems when he installed the latest Xcode update because the derived platform constants were off. He provided me the output of `nm -P ./includes/dist- derivedconstants/header/tmp.o` which turned out have numbers which didn't make sense: {{{ _derivedConstantAP_STACK_SPLIM C 1025 0 _derivedConstantBITMAP_BITS_SHIFT C 7 0 _derivedConstantBLOCKS_PER_MBLOCK C 253 0 _derivedConstantBLOCK_SIZE C 4097 0 _derivedConstantCINT_SIZE C 5 0 _derivedConstantCLONG_LONG_SIZE C 9 0 _derivedConstantCLONG_SIZE C 9 0 _derivedConstantDOUBLE_SIZE C 9 0 _derivedConstantDYNAMIC_BY_DEFAULT C 2 0 ... }}} Which with an older Xcode version would have looked like {{{ _derivedConstantAP_STACK_SPLIM C 401 0 _derivedConstantBITMAP_BITS_SHIFT C 7 0 _derivedConstantBLOCKS_PER_MBLOCK C fd 0 _derivedConstantBLOCK_SIZE C 1001 0 _derivedConstantCINT_SIZE C 5 0 _derivedConstantCLONG_LONG_SIZE C 9 0 _derivedConstantCLONG_SIZE C 9 0 _derivedConstantDOUBLE_SIZE C 9 0 _derivedConstantDYNAMIC_BY_DEFAULT C 2 0 ... }}} So obviously `nm -P`'s output changed from hexadecimal to (non-compliant) decimal formatting of numbers. For reference, here's how POSIX specifies the semantics of `nm`: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/nm.html > `-P` > Write information in a portable output format, as specified in the STDOUT section. ... > If the `-P` option is specified, the previous information shall be displayed using the following portable format. The three versions differ depending on whether `-t d`, `-t o`, or `-t x` was specified, respectively: > > {{{"%s%s %s %d %d\n", <library/object name>, <name>, <type>, <value>, <size>}}} > > {{{"%s%s %s %o %o\n", <library/object name>, <name>, <type>, <value>, <size>}}} > > {{{"%s%s %s %x %x\n", <library/object name>, <name>, <type>, <value>, <size>}}} In the event that Apple can't be bothered to fix this bug (I've had bad experience with Apple and standard-compliance in the past, hence my pessimism) we could try to workaround by using `nm -P -t x` when building on OSX... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11744> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #11724: Must check for representation polymorphism in datatype declarations
by GHC 02 Dec '16

02 Dec '16

#11724: Must check for representation polymorphism in datatype declarations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.0.1 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: -------------------------------------+------------------------------------- {{{#!hs data Foo (r :: RuntimeRep) (a :: TYPE r) = Foo a }}} panics. It should error instead. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11724> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12668: Program that fails Core Lint terribly
by GHC 02 Dec '16

02 Dec '16

#12668: Program that fails Core Lint terribly -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 (Type checker) | 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: -------------------------------------+------------------------------------- While looking for a testcase for another unrelated compiler bug (see Phab:D2577) I had the pleasure of encountering this specimen, {{{#!hs {-# LANGUAGE TypeInType #-} {-# LANGUAGE RankNTypes #-} module Hi where import GHC.Exts data Some r = Some (TYPE r -> TYPE r) doSomething :: forall (r :: RuntimeRep). forall (a :: TYPE r). () => Int -> (a -> Int) -> a -> a doSomething n f = case n of 1 -> error "hello" 3 -> error "hello" }}} GHC 465c6c5d15f8fb54afb78408f3a79e75e74d2cd4 seems to let this program typecheck, but if you enable Core Lint it soon becomes clear that not all is well. Here's a sampling of the carnage, {{{ $ ghc hi.hs -fforce-recomp -dcore-lint -O0 [1 of 1] Compiling Hi ( hi.hs, hi.o ) *** Core Lint errors : in result of Desugar (after optimization) *** <no location info>: warning: In the type ‘a_a2ON -> Int’ Ill-kinded argument in type or kind ‘a_a2ON -> Int’ type or kind ‘a_a2ON -> Int’ kind: TYPE r_a2OM <no location info>: warning: In the type ‘a_a2ON -> a_a2ON’ Ill-kinded argument in type or kind ‘a_a2ON -> a_a2ON’ type or kind ‘a_a2ON -> a_a2ON’ kind: TYPE r_a2OM <no location info>: warning: In the type ‘a_a2ON -> a_a2ON’ Ill-kinded argument in type or kind ‘a_a2ON -> a_a2ON’ type or kind ‘a_a2ON -> a_a2ON’ kind: TYPE r_a2OM <no location info>: warning: In the expression: patError @ 'PtrRepLifted @ (a_a2ON -> a_a2ON) "hi.hs:(12,5)-(14,24)|case"# Ill-kinded argument in type or kind ‘a_a2ON -> a_a2ON’ type or kind ‘a_a2ON -> a_a2ON’ kind: TYPE r_a2OM ... }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12668> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

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

02 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

Re: [GHC] #11445: Turn on SplitSections by default
by GHC 02 Dec '16

02 Dec '16

#11445: Turn on SplitSections by default -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 11285 Related Tickets: | Differential Rev(s): Phab:D1800 Wiki Page: | -------------------------------------+------------------------------------- Comment (by awson): If somebody wants to enjoy the benefits of `-split-sections` vs `-split- objs` (they are tremendous) '''immediately''', she has the following options: 1. I could try to put linker script patches to upstream `binutils`. Honestly, I don't want to bother with this ATM; 2. I could publish these patches for those interested to build their own `binutils`; 3. I could publish linker scripts which could be used with existing `binutils`. Since all options require (at least) to modify any existing build scripts, I believe that, perhaps, the option 3 might be the most welcomed one. OTOH, options 2 and 3 require more involvement than the first one. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11445#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12901: Levity polymorphic expressions mustn't be floated out
by GHC 02 Dec '16

02 Dec '16

#12901: Levity polymorphic expressions mustn't be floated out -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: hsyl20 Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple LevityPolymorphism | Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I have been trying to add the following code into GHC: {{{#!hs {-# LANGUAGE PatternSynonyms #-} {-# LANGUAGE ViewPatterns #-} pattern AppOp1 :: PrimOp -> Arg CoreBndr -> CoreExpr pattern OpVal :: PrimOp -> Arg CoreBndr pattern AppOp1 op x = App (OpVal op) x pattern OpVal op <- Var (isPrimOpId_maybe -> Just op) where OpVal op = Var (mkPrimOpId op) }}} It triggers the following CoreLint error: {{{ <no location info>: warning: [RHS of lvl_spfb :: r] RuntimeRep-polymorphic binder: lvl_spfb :: (r :: TYPE rep) }}} Indeed: {{{#!hs $mAppOp1 :: forall (r :: TYPE rep). CoreExpr -> (PrimOp -> Arg CoreBndr -> r) -> (Void# -> r) -> r [LclIdX, Arity=3] $mAppOp1 = \ (@ (rep_agRe :: RuntimeRep)) (@ (r_agRf :: TYPE rep)) (scrut_agRh :: CoreExpr) (cont_agRi :: PrimOp -> Arg CoreBndr -> r) (fail_agRj :: Void# -> r) -> let { fail_spbW :: Void# -> r [LclId, Arity=1] fail_spbW = \ _ [Occ=Dead, OS=OneShot] -> fail_agRj void# } in let { lvl_spfb :: r [LclId] lvl_spfb = fail_spbW void# } in case scrut_agRh of { __DEFAULT -> fail_spbW void#; App ds_dj2u x_afoV -> $mOpVal @ rep @ r ds_dj2u (\ (op_afoU :: PrimOp) -> cont_agRi op_afoU x_afoV) (\ _ [Occ=Dead] -> lvl_spfb) }}} According to the levity polymorphism paper `lvl_spfb` shouldn't have been floated out in a let-binding. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12901> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3