June 2017 - ghc-tickets

[GHC] #13567: Do loopification using join points
by GHC 01 Aug '17

01 Aug '17

#13567: Do loopification using join points -------------------------------------+------------------------------------- Reporter: simonpj | 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: -------------------------------------+------------------------------------- Here's an idea: use join points to accomplish all that the existing "loopification" patch does, and more. The idea is described under "New idea: use join points" in [wiki:Commentary/Compiler/Loopification]. This ticket is to discuss and track progress. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13567> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11995: Can't infer type
by GHC 31 Jul '17

31 Jul '17

#11995: Can't infer type -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: -------------------------------------+------------------------------------- {{{#!hs import Data.Kind data NP :: forall k. (ĸ → Type) → ([k] → Type) where Nil :: NP f '[] (:*) :: f x → NP f xs → NP f (x:xs) newtype K a b = K a deriving Show unK (K a) = a h'collapse :: NP (K a) xs -> [a] h'collapse = \case Nil -> [] K x:*xs -> x : h'collapse xs }}} if we replace `xs` by an underscore: {{{ tJN0.hs:13:29-30: error: … • Could not deduce: (xs :: [ĸ]) ~~ ((':) ĸ x xs :: [ĸ]) from the context: ((k :: *) ~~ (ĸ :: *), (t :: [k]) ~~ ((':) ĸ x xs :: [ĸ])) bound by a pattern with constructor: :* :: forall k (f :: k -> *) (x :: k) (xs :: [k]). f x -> NP k k f xs -> NP k k f ((':) k x xs), in a case alternative at /tmp/tJN0.hs:13:3-9 ‘xs’ is a rigid type variable bound by a pattern with constructor: :* :: forall k (f :: k -> *) (x :: k) (xs :: [k]). f x -> NP k k f xs -> NP k k f ((':) k x xs), in a case alternative at /tmp/tJN0.hs:13:3 Expected type: NP ĸ k (K ĸ a) t Actual type: NP ĸ ĸ (K ĸ a) xs • In the first argument of ‘h'collapse’, namely ‘xs’ In the second argument of ‘(:)’, namely ‘h'collapse xs’ In the expression: x : h'collapse xs • Relevant bindings include xs :: NP ĸ ĸ (K ĸ a) xs (bound at /tmp/tJN0.hs:13:8) h'collapse :: NP ĸ k (K ĸ a) t -> [a] (bound at /tmp/tJN0.hs:11:1) Compilation failed. }}} Should it not be able to infer that? The Glorious Glasgow Haskell Compilation System, version 8.1.20160419 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11995> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13540: Enable -msse2 by default on i386
by GHC 31 Jul '17

31 Jul '17

#13540: Enable -msse2 by default on i386 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: high | Milestone: 8.4.1 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: -------------------------------------+------------------------------------- SSE2 has been around for nearly 15 years now and at this point it is supported nearly universally. Currently we pass `-msse2` to numerically- sensitive testsuite tests since x87 is too imprecise. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13540> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[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] #13744: Compile-time regression in 8.2 when compiling bloodhound's test suite
by GHC 31 Jul '17

31 Jul '17

#13744: Compile-time regression in 8.2 when compiling bloodhound's test suite -------------------------------------+------------------------------------- Reporter: refold | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC 8.2 takes much longer to compile bloodhound's test suite than GHC 8.0.2. With 8.0.2, compilation takes approximately a minute on my machine, 8.2 takes approximately four minutes and uses much more memory. How to reproduce: {{{ $ git clone -b ghc-8.2 https://github.com/23Skidoo/bloodhound.git $ cd bloodhound $ cabal new-build -w ghc-8.0.1 --enable-tests $ cabal new-build -w ghc-8.2.1 --enable-tests }}} GHC version: {{{ $ ghc-8.2.1 --version The Glorious Glasgow Haskell Compilation System, version 8.2.0.20170505 }}} These warnings (fixed in my `ghc-8.2` branch of `bloodhound`) may provide a clue to what's happening: {{{ tests/V1/tests.hs:1876:17: warning: [-Wsimplifiable-class-constraints] • The constraint ‘SOP.All SOP.SListI (SOP.GCode a)’ matches an instance declaration instance forall k (f :: k -> Constraint) (xs :: [k]). (Generics.SOP.Constraint.AllF f xs, SOP.SListI xs) => SOP.All f xs -- Defined in ‘Generics.SOP.Constraint’ This makes type inference for inner bindings fragile; either use MonoLocalBinds, or simplify it using the instance • In the type signature: sopArbitrary :: forall a. (Generic a, SOP.GTo a, SOP.All SOP.SListI (SOP.GCode a), SOP.All2 Arbitrary (SOP.GCode a)) => Gen a }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13744> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #13817: Simplifier and SpecConstr performance regression with 8.2.1
by GHC 31 Jul '17

31 Jul '17

#13817: Simplifier and SpecConstr performance regression with 8.2.1 -------------------------------------+------------------------------------- Reporter: albertov | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc1 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: -------------------------------------+------------------------------------- A propietary application I've upgraded to compile with 8.2.1-rc1 makes GHC manifest a performance regression when producing optimized ({{{-O2}}}) code. After a crude analysis of a compile log produced with {{{-show-passes}}} it appears that the biggest slowdown is in the Simplifier and SpecConstr phases when compiling the "main" modules. Theres a conversation at GHC Users with more details: https://mail.haskell.org/pipermail/glasgow-haskell- users/2017-June/026543.html. The data, the results and the script to to analyse it live at: https://gist.github.com/albertov/145ac5c01bfbadc5c9ff55e9c5c2e50e I'll try to update this ticket with a way to to reproduce it as soon as I can (if I can) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13817> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[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