April 2017 - ghc-tickets

[GHC] #12878: Use gold linker by default if available on ELF systems
by GHC 31 Jul '17

31 Jul '17

#12878: Use gold linker by default if available on ELF systems -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Driver | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `ld.gold` is both faster and less buggy than `ld.bfd`, but only works on ELF. On ELF systems, we should thus prefer `ld.gold` when it is installed, even when `ld.bfd` is supported (as it is on x86). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12878> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13283: T5435_dyn_asm fails with gold linker
by GHC 31 Jul '17

31 Jul '17

#13283: T5435_dyn_asm fails with gold linker -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.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: -------------------------------------+------------------------------------- I tried validating with `ld.gold` as my system linker and one test failed: {{{ cd "./rts/T5435_dyn_asm.run" && $MAKE -s --no-print-directory T5435_dyn_asm T5435_dyn_asm failed with ['initArray1', 'initArray2', 'ctors2', 'ctors1', 'success'], see all.T for details }}} The expected output has `ctors1` and then `ctors2`. This looks like a bug in gold to me. ezyang, do you agree? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13283> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9020: Massive blowup of code size on trivial program
by GHC 31 Jul '17

31 Jul '17

#9020: Massive blowup of code size on trivial program ------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The test `simplCore/should_compile/simpl015` was leading to massive compile times. This is weird: it looks like: {{{ main = do { return () ; return () ... hundreds more times ... ; return () } }}} It turns out that the cause was over-eager eta-expansion. Each `return ()` gives a top-level PAP thus {{{ lvl17 :: IO () lvl17 = returnIO () }}} But these definitions are then eta-expanded, thus: {{{ lvl17 = ((\eta. returnIO () |> sym g) eta) |> g where g :: State# RealWorld -> (# State# RealWorld, () #) ~ IO () }}} Now in general it makes sense to eta-expand through newtypes (as is done here), because it exposes more lambadas. But it really doesn't make sense to eta-expand a PAP like this. Fortunately the fix is easy: use `exprArity` rather than `manifestArity` in `SimplUtils.tryEtaExpandRhs`. The effect on `simpl015` is dramatic: compiler allocation drops from 6.6G to 812M; and residency drops from 1.8G to 45M. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9020> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #13594: Typechecker behavior w.r.t. BangPatterns and nested foralls has changed in 8.2
by GHC 31 Jul '17

31 Jul '17

#13594: Typechecker behavior w.r.t. BangPatterns and nested foralls has changed in 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 (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 Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Try running this code in GHCi: {{{ λ> :set -XBangPatterns -XRankNTypes -XTypeFamilies λ> let x :: forall a . a ~ Integer => forall b. b ~ Integer => (a, b); !x = (1, 2) }}} In GHC 8.0.1 and 8.0.2, this works. But in GHC 8.2.1: {{{ <interactive>:3:74: Couldn't match expected type ‘forall a. (a ~ Integer) => forall b. (b ~ Integer) => (a, b)’ with actual type ‘(Integer, Integer)’ In the expression: (1, 2) In a pattern binding: !x = (1, 2) }}} If you put this code into a source file: {{{#!hs {-# LANGUAGE BangPatterns #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE RankNTypes #-} module Bug where x :: forall a . a ~ Integer => forall b. b ~ Integer => (a, b) !x = (1, 2) }}} Then it also works in GHC 8.0.1. and 8.0.2, but it errors on GHC 8.2 (this time with a different error): {{{ GHCi, version 8.2.0.20170413: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:6:1: error: Overloaded signature conflicts with monomorphism restriction x :: forall a. a ~ Integer => forall b. b ~ Integer => (a, b) | 6 | x :: forall a . a ~ Integer => forall b. b ~ Integer => (a, b) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13594> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 26

[GHC] #13054: Generating unique names with template haskell
by GHC 31 Jul '17

31 Jul '17

#13054: Generating unique names with template haskell -------------------------------------+------------------------------------- Reporter: tim-m89 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.0.1 Haskell | 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 need to use template haskell to generate a few instances where those instances each use a foreign function obtained from a particular {{{FunPtr}}}. As far as I'm aware, the only clean way to do this requires top level declarations of the form: {{{foreign import ccall "dynamic" makeFun1 :: FunPtr Foo -> Foo}}} If there was either: * Another way to do this without requiring top level named declarations. * The possibility to use these within a where clause (template haskell would suggest so given that it lets you use {{{Dec}}} within a {{{where}}}). Then I'd be fine probably be fine without names. I've tried using {{{newName}}} as it apparently generates fresh names but I cannot get it work for me. I've put a copy of the test case [https://gitlab.com/tim-m89/hs-th-name- issue here]. I compile with {{{stack build --ghc-options="-ddump-splices -ddump-to-file"}}} and the error is: {{{ th-name-issue/app/Main.hs:7:12: error: Multiple declarations of ‘makeFun’ Declared at: app/Main.hs:7:12 app/Main.hs:7:12 }}} Then I run {{{gvim .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/th- name-issue-exe/th-name-issue-exe-tmp/app/Main.dump-splices}}} And can see: {{{ app/Main.hs:7:12-25: Splicing declarations template-haskell-2.11.0.0:Language.Haskell.TH.Quote.quoteDec importGen " stuff here " ======> foreign import ccall safe "dynamic" makeFun_a3pc :: GHC.Ptr.FunPtr (Foreign.C.String.CString -> IO ()) -> Foreign.C.String.CString -> IO () foreign import ccall safe "dynamic" makeFun_a3pd :: GHC.Ptr.FunPtr (Foreign.C.String.CString -> IO ()) -> Foreign.C.String.CString -> IO () }}} Which suggests that I did manage to get unique names after all, so I don't know why it didn't compile?? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13054> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #13173: Investigate old comment at the top of SrcLoc
by GHC 29 Jul '17

29 Jul '17

#13173: Investigate old comment at the top of SrcLoc -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- There is a comment at the top of `SrcLoc` which says {{{ {-# OPTIONS_GHC -fno-omit-interface-pragmas #-} -- Workaround for Trac #5252 crashes the bootstrap compiler without -O -- When the earliest compiler we want to boostrap with is -- GHC 7.2, we can make RealSrcLoc properly abstract }}} This is a well-defined small task so I will mark it for newcomers. 1. Try to work out what the pragma is meant to do by reading #5252 2. Work out whether we can now make `RealSrcLoc` "properly abstract" (if it is not already) 3. Remove or update this comment and pragma. 4. Pray it doesn't break the whole compiler. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13173> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #12989: ($) can have a more general type
by GHC 28 Jul '17

28 Jul '17

#12989: ($) can have a more general type -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- The documentation (in section 9.12.1 for GHC 8; I don't know what section it is in 8.2) suggests a hypothetical type for `($)`: {{{#!hs bad :: forall (r1 :: RuntimeRep) (r2 :: RuntimeRep) (a :: TYPE r1) (b :: TYPE r2). (a -> b) -> a -> b bad f x = f x }}} It explains, correctly, that this definition will not work because `x` has a representation-polymorphic type. However, this doesn't actually explain why `($)` doesn't have that type! Indeed, both GHC 8 and 8.2 accept the following: {{{#!hs good :: forall (r1 :: RuntimeRep) (r2 :: RuntimeRep) (a :: TYPE r1) (b :: TYPE r2). (a -> b) -> a -> b good f = f }}} This has very slightly different semantics, but anyone relying on the difference is already doing something they shouldn't. It may or may not be possible to retain the current semantics with some care and magic, if we so desire. I didn't really know how to characterize this ticket properly. It could be considered a documentation bug or a compiler feature request. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12989> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13541: Make it easier to use the gold linker
by GHC 28 Jul '17

28 Jul '17

#13541: Make it easier to use the gold linker -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- As pointed out in #4862, the `gold` linker is significantly faster than BFD `ld`. Currently we use whatever linker `gcc` uses by default. This is an unfortunate situation for users as few packagers take the effort to configure their builds to use `gold`. I think we should consider the following, > Introduce a configure flag (to both the source distribution, and the distributed binary distributions), `--enable-gold`. When enabled, `configure` will check for the functioning of `gcc -fuse-ld=gold`. If found to work `-fuse-ld=gold` would be added to GHC's `optl`. The flag would throw an error on non-ELF platforms (which are not supported by `gold`). While there is admittedly not a whole lot of precedent for this, the status quo means we are leaving a significant bit of compiler performance on the table in a majority of cases. Given that `stack` uses GHC's official bindists, we should try to improve this situation. * -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13541> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 35

[GHC] #13601: GHC errors but hangs
by GHC 28 Jul '17

28 Jul '17

#13601: GHC errors but hangs -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) 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: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE TypeFamilies, DataKinds, TypeInType #-} import GHC.Exts import Prelude (Bool(True,False),Integer,Ordering,undefined) import qualified Prelude import Data.Kind -------------------- -- class hierarchy type family Rep (rep :: RuntimeRep) :: RuntimeRep where -- Rep IntRep = IntRep -- Rep DoubleRep = IntRep -- Rep PtrRepUnlifted = IntRep -- Rep PtrRepLifted = PtrRepLifted class Boolean (Logic a) => Eq (a :: TYPE rep) where type Logic (a :: TYPE rep) :: TYPE (Rep rep) (==) :: a -> a -> Logic a class Eq a => POrd (a :: TYPE rep) where inf :: a -> a -> a class POrd a => MinBound (a :: TYPE rep) where minBound :: () -> a class POrd a => Lattice (a :: TYPE rep) where sup :: a -> a -> a class (Lattice a, MinBound a) => Bounded (a :: TYPE rep) where maxBound :: () -> a class Bounded a => Complemented (a :: TYPE rep) where not :: a -> a class Bounded a => Heyting (a :: TYPE rep) where infixr 3 ==> (==>) :: a -> a -> a class (Complemented a, Heyting a) => Boolean a (||) :: Boolean a => a -> a -> a (||) = sup (&&) :: Boolean a => a -> a -> a (&&) = inf }}} hangs with {{{ $ ghci a.hs GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( a.hs, interpreted ) a.hs:18:16: error: C-c C-cInterrupted. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13601> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #12018: Equality constraint not available in pattern type signature (GADTs/ScopedTypeVariables)
by GHC 28 Jul '17

28 Jul '17

#12018: Equality constraint not available in pattern type signature (GADTs/ScopedTypeVariables) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.10.3 (Type checker) | Keywords: GADTs, | Operating System: Unknown/Multiple ScopedTypeVariables | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs data Exp a where Tru :: Ty Bool eval :: Exp a -> a eval Tru = True }}} Works fine, as does {{{#!hs eval :: Exp a -> a eval (Tru :: Exp _) = True }}} But {{{#!hs eval :: Exp a -> a eval (Tru :: Exp Bool) = True }}} doesn't, is this an intended design of GADTs/ScopedTypeVariables that the type equality constraint isn't in scope in the type signature of the pattern match, I would like to match on an existential type in my own code: {{{#!hs compile (ArrIx arr index :: Exp (Sca elt)) = do ... }}} It can be worked around by writing: {{{#!hs eval a@Tru = case a :: Exp Bool of }}} but for my own code it seems I must write {{{#!hs compile uuu@(ArrIx arr index :: Exp a) = do case uuu :: (a ~ Sca elt) => Exp (Sca elt) of }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12018> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11