May 2015 - ghc-tickets

[GHC] #10110: Compiling unit fails with Loading temp shared object failed
by GHC 19 May '15

19 May '15

#10110: Compiling unit fails with Loading temp shared object failed -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 7.10.1-rc2 Keywords: | Operating System: Linux Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: #10058 Differential Revisions: | -------------------------------------+------------------------------------- @goldfire reported in #10058 in comment 1 another failure: {{{ [43 of 55] Compiling Tests.Compile.UnitParser ( Tests/Compile/UnitParser.hs, dist/build/main/main- tmp/Tests/Compile/UnitParser.o ) <no location info>: ghc: panic! (the 'impossible' happened) (GHC version 7.10.0.20150123 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc6444_0/libghc6444_264.so: undefined symbol: DataziMetrologyziSIziUnits_zdfShowHectare_closure Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} While on the surface this looks like a duplicate of #10058 it is not. The issue is only on Linux (travis to be precise), not OSX. Looking at the undefined symbol, here we see a symbol from the current module whereas in #10058 the undefined symbol lives in one of the packages. My theory is that the travis machine is running a modified link editor that defaults to `--as-needed` being set whereas the binutils default is `-no-as-needed`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10110> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #10366: Post link to MacOS binary of 7.10
by GHC 19 May '15

19 May '15

#10366: Post link to MacOS binary of 7.10 -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | Status: new Priority: highest | Milestone: 7.10.2 Component: | Version: 7.10.1 Documentation | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- More than a month after GHC 7.10 is released, there still isn't a binary linked for MacOS at https://www.haskell.org/ghc/download_ghc_7_10_1#binaries. I see that the binary exists in https://downloads.haskell.org/~ghc/7.10.1/, but that link is critical to finding it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10366> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 18 May '15

18 May '15

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Fuuzetsu Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Fuuzetsu): >It would be unusual to delay a patch-level release for a ticket that has been open for five years. Well, if anything we'd only be holding it up for the specialisation issue posted recently. To me at least it seems like a serious regression so it should probably be fixed in some patch release, whether it's 7.10.2 or 7.10.3 is up to whenever a fix is found. But I also don't want to hold up any other fixes. I wish only to not end up in a situation where the final 7.10.x is released and to get much else in we have to wait for 7.12. As long as it's fixed in 7.10 somewhere, I'm happy. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:85> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10335: Failure to construct superclasses in instance
by GHC 18 May '15

18 May '15

#10335: Failure to construct superclasses in instance -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Consider {{{ {-# LANGUAGE MultiParamTypeClasses, FlexibleInstances, ConstraintKinds #-} module Foo where class Eq a => C a b type X a = (Eq a, Show a) instance X a => C a [b] }}} HEAD gives {{{ Foo.hs:8:10: Could not deduce (Eq a) arising from the superclasses of an instance declaration from the context: X a bound by the instance declaration at Foo.hs:8:10-23 Possible fix: add (Eq a) to the context of the instance declaration In the instance declaration for ‘C a [b]’ }}} This is fall-out from refactoring the silent-superclass story. Patch coming. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10335> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10422: reorder in nativeCodeGen too slow
by GHC 18 May '15

18 May '15

#10422: reorder in nativeCodeGen too slow -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 (CodeGen) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When working on #10397 and after fixing the bottleneck in `elimCommonBlocks` I noticed that `reorder` was taking most of the time. Bad lazy linked lists. I have a fix, will put it on Phabricator for validation shortly -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10422> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10429: GHC fails to import instance
by GHC 18 May '15

18 May '15

#10429: GHC fails to import instance -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- The following code compiles in 7.8.4 but fails to compile in 7.10.1. Tagged.hs {{{#!hs module Tagged where import Control.Monad.Trans newtype TaggedT s m b = TagT (m b) instance MonadTrans (TaggedT s) }}} Main.hs {{{#!hs import Control.Monad.Trans.Class import Tagged returnT :: (MonadTrans t) => t m a -> t m a returnT a = undefined f :: TaggedT Int m a -> TaggedT Int m a f = returnT }}} GHC complains {{{ Could not deduce (MonadTrans (TaggedT Int)) arising from a use of ‘returnT’ }}} If I change the import in Main to `Control.Monad.Trans`, 7.10.1 accepts the program. Since the import `Control.Monad.Trans` is actually a folder, the class `MonadTrans` must refer to the definition in `Control.Monad.Trans.Class`, so GHC should find the instance. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10429> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #10248: GHC panic when used with deferred type errors, again
by GHC 18 May '15

18 May '15

#10248: GHC panic when used with deferred type errors, again ---------------------------------------+------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1-rc3 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ---------------------------------------+------------------------------- Similar to previous report of mine #9834. Given `error.hs` {{{#!hs data I a = I a }}} I get the following result: {{{#!hs $ ghci -fdefer-type-errors -ignore-dot-ghci error.hs <ype-errors -ignore-dot-ghci error.hs GHCi, version 7.10.0.20150316: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( error.hs, interpreted ) Ok, modules loaded: Main. *Main> I <$> _ I <$> _ <interactive>:2:7: Warning: Found hole ‘_’ with type: IO a0 Where: ‘a0’ is an ambiguous type variable In the second argument of ‘(<$>)’, namely ‘_’ In the first argument of ‘GHC.GHCi.ghciStepIO :: IO a_auR -> IO a_auR’, namely ‘I <$> _’ In a stmt of an interactive GHCi command: it <- GHC.GHCi.ghciStepIO :: IO a_auR -> IO a_auR (I <$> _) ghc: panic! (the 'impossible' happened) (GHC version 7.10.0.20150316 for i386-unknown-linux): nameModule $dShow_aIT Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *Main> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10248> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10359: Tuple constraint synonym led to asymptotic performance lossage
by GHC 18 May '15

18 May '15

#10359: Tuple constraint synonym led to asymptotic performance lossage -------------------------------------+------------------------------------- Reporter: axch | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- I encountered a situation where using a tuple constraint synonym produced an asymptotic runtime performance degradation, from linear to quadratic time. The enclosed Bug.hs reproduces the potentially relevant features of the problem. The function `test` there is quadratic, but should be linear. The file also contains a definition of `test2`, which differs only in eschewing the constraint synonym, and is linear, as it should be. In more detail: the program tries to count to 20,000 in a rather contrived way. It maintains a Box, which holds the current count and a function that can accept an increment and a count to produce a new count (namely, `(+)`). The function `do_step` lifts incrementation to Boxes, using their contained function to update their stored count. The first tricky thing is that the incrementing function stored in the Box is polymorphic in both arguments separately: it can accept increments that are not the same type as the stored count (and converts them). The second tricky thing is that I don't want to expose the type variable for the increment type (as opposed to the count type) to clients of the Box, so the Box's incrementing function is stored polymorphic (with an explicit forall). Finally, I want to impose the constraint `(Fractional num, Real num)` on allowable increments (even though this example only needs `Real num`). This constellation of desiderata conspires to produce quadratic performance: doubling the parameter to `test` (but not `test2`) multiplies its runtime by 4. Inspecting the heap profile indicates a growing accumulation of closures when running `test` (but not `test2`). Inspecting the generated stg (enclosed) locates a potential culprit: apparently when `do_step` (but not `do_step2`) reconstructs the Box, it changes the `func` stored there to be a fresh closure that destructures the `Numerical` constraint tuple, constructs a fresh one, and calls the function that was in that slot previously with it. I hypothesize that this accumulates as a chain that performs a linear number of such destructurings and restructurings at each increment, leading to the observed quadratic runtime and linear memory growth. Incidentally, I checked whether record wildcards were the issue (no: `test4`) and whether updating just the `obj` field solves it (yes: `test3`). Sadly, the latter solution is not directly usable in my actual application because of "Record update for insufficiently polymorphic field". -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10359> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #10228: Increased memory usage with GHC 7.10.1
by GHC 18 May '15

18 May '15

#10228: Increased memory usage with GHC 7.10.1 -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- (Repost from ghc-devs) I just uprgaded both of my machines to use GHC 7.10.1. I keep sandboxed installations of GHC and this means I had to rebuild Agda and Idris because the binaries built with GHC 7.8.4 were stored inside deactivated 7.8.4 sandbox. Sadly, I had problems building both Agda and Idris due to GHC taking up all of available memory. With Idris the problematic module was Idris.ElabTerm (~2900LOC). The interesting part of the story is that when I do a clean build of Idris GHC consumes all of memory when compiling that module and I have to kill the build. But when I restart the build after killing GHC the module is compiled using a reasonable amount of memory and within reasonable time. With Agda the problematic module is Agda.TypeChecking.Serialise (~2000LOC). The trick with killing the build and restarting it didn't work in this case. I had to compile Agda with GHC 7.8.4 (which works without problems though the mentioned module still requires a lot of memory) and alter my setup so that Agda binary is not stored inside GHC sandbox. I wonder if any of you came across similar issues with GHC 7.10.1? Do we have any performance data that allows to compare memory usage and performance of GHC 7.10.1 with previous stable releases? All of the above happened on 64bit Debian Wheezy with 2GB of RAM. On my second machine, this time with 4GB of RAM, compiling Agda ran out of memory (again Agda.TypeChecking.Serialise module) and I had to kill the build. But once I restarted the build the module was compiled succesfully in a matter of minutes and using around 50% of memory. This looks like some kind of memory leak in GHC. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10228> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10427: Template variable unbound in rewrite rule
by GHC 17 May '15

17 May '15

#10427: Template variable unbound in rewrite rule -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- This may be due to a bug in [singletons](https://hackage.haskell.org/package/singletons), but GHC requested I post a bug here, so I am dutifully complying. The following code fails with -O2 (but succeeds with -O1): {{{#!hs {-# LANGUAGE DataKinds, GADTs, KindSignatures, PolyKinds, ScopedTypeVariables, TemplateHaskell, TypeFamilies, UndecidableInstances #-} module Error where import qualified GHC.Num as Num import Data.Singletons.Prelude hiding (sMin, sMax, MinSym0, MaxSym0) import Data.Singletons.TH import Data.Type.Natural as N hiding ((:-)) singletons [d| newtype Foo = Bar Nat deriving (Eq,Show) |] singletons [d| ppMul :: Foo -> [Foo] -> [Foo] ppMul x@(Bar p) pps@((Bar p'):pps') = (Bar p'):ppMul x pps' |] }}} with the message {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-unknown-linux): Template variable unbound in rewrite rule n_Xdkc [n_adis, n1_adix, n_adiA, sc_se5w, sg_se5x, sc_se5y] [n_Xdk2, n1_Xdk8, n_Xdkc, sc_Xe79, sg_Xe7b, sc_Xe7d] [TYPE Let_1627437169XSym3 n_adis n_adiA n1_adix, TYPE n1_adix, (SBar @ ('Bar n_adis) @ n_adis @~ <'Bar n_adis>_N sc_se5w) `cast` (sg_se5x :: R:SingFooz (BarSym1 n_adis) ~R# Sing (Apply BarSym0 n_adis)), sc_se5y] [TYPE Let_1627437169XSym3 n_adis n_XdjP n1_XdjH, TYPE n1_XdjH, (SBar @ ('Bar n_adis) @ n_adis @~ <'Bar n_adis>_N sc_se5w) `cast` (Sub (Sym TFCo:R:SingFooz[0]) (Sym (TFCo:R:ApplyFooNatBarSym0l0[0] <n_adis>_N)) :: R:SingFooz (BarSym1 n_adis) ~R# Sing (Apply BarSym0 n_adis)), sPps'_aciK] }}} I found that if I rewrite `ppmul` as `ppMul x pps@((Bar p'):pps') = (Bar p'):ppMul x pps'` (i.e. remove the pattern match on `x`), then ghc -02 succeeds. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10427> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1