December 2015 - ghc-tickets

Re: [GHC] #3559: split ghci modules off into their own package
by GHC 10 Dec '15

10 Dec '15

#3559: split ghci modules off into their own package -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: task | Status: new Priority: low | Milestone: 8.0.1 Component: GHCi | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * failure: => None/Unknown Comment: See also wiki:RemoteGHCi -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3559#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11157: (Optimized prime generation) ghc: panic! (the 'impossible' happened)
by GHC 10 Dec '15

10 Dec '15

#11157: (Optimized prime generation) ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: jachymb | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I try to compile the example from https://wiki.haskell.org/Prime_numbers#Using_ST_Array {{{#!hs {-# OPTIONS_GHC -O2 #-} import Control.Monad import Control.Monad.ST import Data.Array.ST import Data.Array.Unboxed sieveUA :: Int -> UArray Int Bool sieveUA top = runSTUArray $ do let m = (top-1) `div` 2 r = floor . sqrt $ fromIntegral top + 1 sieve <- newArray (1,m) True -- :: ST s (STUArray s Int Bool) forM_ [1..r `div` 2] $ \i -> do isPrime <- readArray sieve i when isPrime $ do -- ((2*i+1)^2-1)`div`2 == 2*i*(i+1) forM_ [2*i*(i+1), 2*i*(i+2)+1..m] $ \j -> do writeArray sieve j False return sieve }}} I get the following error: {{{ [1 of 1] Compiling Main ( p111.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): floatExpr tick break<29>() Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The error does not happen if I remove the OPTIONS_GHC -O2 directive. I use ArchLinux and the GHC compiled package from it's standard repositories. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11157> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11146: Manual eta expansion leads to orders of magnitude less allocations
by GHC 10 Dec '15

10 Dec '15

#11146: Manual eta expansion leads to orders of magnitude less allocations -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new Priority: normal | 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 Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While working on deterministic free variable computation I run into some performance issues. I narrowed it down to code that when eta expanded performed less allocations. I ended up writing a benchmark and for large examples the eta expanded versions performs orders of magnitude less allocations. The results of my test: {{{ EtaExpanded test3 50,450,112 bytes allocated in the heap real 0.89 EtaReduced test3 3,661,740,240 bytes allocated in the heap real 3.66 }}} The whole source is here: https://github.com/niteria/deterministic-fvs, I'm also attaching the two interesting implementations. I experimented with it a little and GHC eta-expanded when I didn't have mutually recursive bindings. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11146> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #11192: Induced `Eq` constraint on numeric literal + partial type signature = panic!
by GHC 10 Dec '15

10 Dec '15

#11192: Induced `Eq` constraint on numeric literal + partial type signature = panic! -------------------------------------+------------------------------------- Reporter: kwf | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Type checker) | Keywords: numeric | Operating System: Unknown/Multiple literal, partial type signature, | the impossible happened, panic | Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When I use a partial type signature in a non-top-level let-binding (or where clause), ''and'' the type is sufficiently ambiguous, ''and'' the binding in question uses a numeric literal, I get a panic from GHC instead of a report of the inferred type of the hole. So, this breaks: {{{#!hs module Fails where fails :: a fails = let go :: _ go 0 a = a in go (0 :: Int) undefined }}} {{{ Fails.hs:7:11: Couldn't match expected type ‘a’ with actual type ‘Int’ ‘a’ is untouchable inside the constraints () bound by the type signature for fails :: a1 at Fails.hs:3:10ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-apple-darwin): No skolem info: a_a1iD[sk] }}} ...but this succeeds: {{{#!hs module Succeeds where succeeds :: a succeeds = let go :: _ go _ a = a in go (0 :: Int) undefined }}} {{{ Succeeds.hs:13:14: Found hole ‘_’ with type: t -> t1 -> t1 Where: ‘t’ is a rigid type variable bound by the inferred type of go :: t -> t1 -> t1 at Succeeds.hs:14:8 ‘t1’ is a rigid type variable bound by the inferred type of go :: t -> t1 -> t1 at Succeeds.hs:14:8 To use the inferred type, enable PartialTypeSignatures <snip> }}} The '''only''' difference between these two modules is the use of a numeric literal in a pattern match; that is, the troublesome line boils down to: {{{#!hs go 0 a = a }}} vs. {{{#!hs go _ a = a }}} Note that GHC gives us several pieces of feedback before talking about the panic. Before the above-quoted error, we get: {{{ Fails.hs:5:14: Found hole ‘_’ with type: a2 -> t1 -> t1 Where: ‘t1’ is a rigid type variable bound by the inferred type of go :: (Eq a2, Num a2) => a2 -> t1 -> t1 at Fails.hs:6:8 ‘a2’ is a rigid type variable bound by the inferred type of go :: (Eq a2, Num a2) => a2 -> t1 -> t1 at Fails.hs:6:8 To use the inferred type, enable PartialTypeSignatures <snip> Fails.hs:6:8: No instance for (Eq a) When checking that ‘go’ has the specified type go :: forall t a. a -> t -> t Probable cause: the inferred type is ambiguous <snip> Fails.hs:7:7: Couldn't match expected type ‘a1’ with actual type ‘t’ because type variable ‘a1’ would escape its scope This (rigid, skolem) type variable is bound by the type signature for fails :: a1 at Fails.hs:3:10 <snip> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11192> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #5987: Too many symbols in ghc package DLL
by GHC 10 Dec '15

10 Dec '15

#5987: Too many symbols in ghc package DLL ---------------------------------+---------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 5355 Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by bgamari): * owner: thoughtpolice => * priority: high => normal Comment: Demoting priority as we have disabled dynamic linking on Windows (see comment:29). My understanding of this situation is that it is not an intrinsic limitation of PE. The relevant data structures are the `.edata` and `.idata` tables which are defined in sections 63 and 64 of the PE/COFF specification. The specification specifies that one means of referring to exported symbols is via a 16-bit ordinal. However, this is not the only way; if the lookup fails the loader will fall back to a standard name search. Indeed, Microsoft even explicitly says that ordinals [[https://msdn.microsoft.com/en-us/library/hyx1zcd3.aspx|are a legacy artifact]] and their use is discouraged in new code (this document describes the `.def` format, but the idea still applies), > You can use @ordinal to specify that a number, and not the function name, will go into the DLL's export table. Many Windows DLLs export ordinals to support legacy code. It was common to use ordinals in 16-bit Windows code, because it can help minimize the size of a DLL. We don’t recommend exporting functions by ordinal unless your DLL’s clients need it for legacy support. Because the .LIB file will contain the mapping between the ordinal and the function, you can use the function name as you normally would in projects that use the DLL. For this reason I believe the problem is in fact that `ld.bfd` is producing DLLs with symbols exported by (or perhaps objects that are imported by) ordinal. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5987#comment:46> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11187: Odd interaction between type families and coercions (regression)
by GHC 10 Dec '15

10 Dec '15

#11187: Odd interaction between type families and coercions (regression) -------------------------------------+------------------------------------- Reporter: dfeuer | 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 Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE TypeFamilies #-} module Wonk where import Data.Type.Coercion type family X coercionXX :: Coercion X X coercionXX = Coercion }}} This works just fine in 7.8.3, but in 7.10.2 it gives the following peculiar error: {{{ Couldn't match representation of type ‘X’ with that of ‘X’ NB: ‘X’ is a type function, and may not be injective In the expression: Coercion In an equation for ‘coercionXX’: coercionXX = Coercion }}} I don't even know what it means for a ''nullary'' type function to be injective. I tried the following workarounds: {{{#!hs coercionXX1 :: Coercion X X coercionXX1 = c where c :: x ~ X => Coercion x x c = Coercion coercionXX2 :: Coercion X X coercionXX2 = c where c = Coercion }}} Interestingly, `coercionXX1` seems to work under all circumstances, with or without the top-level type signature; `coercionXX2` works if it's in a `.hs` file, but does ''not'' work if entered by hand at the `ghci` prompt (it produces a similar error). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11187> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11183: Numeric.showFFloat outputs decimal point when it should not.
by GHC 09 Dec '15

09 Dec '15

#11183: Numeric.showFFloat outputs decimal point when it should not. -------------------------------------+------------------------------------- Reporter: Dobiasd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.10.2 libraries/base | Keywords: Numeric, | Operating System: Unknown/Multiple showFFloat, showFFloatAlt | Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs showFFloat Nothing 42 "" }}} The expression above should give "42" but actually gives "42.0". Only showFFloatAlt should do this. Minimal example: http://ideone.com/yYvqrf -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11183> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11181: Program hands forever in sched_yield() / yield() unless -N is limited
by GHC 08 Dec '15

08 Dec '15

#11181: Program hands forever in sched_yield() / yield() unless -N is limited ---------------------------------------+---------------------------------- Reporter: patrick_thomson | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Solaris Architecture: x86_64 (amd64) | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ---------------------------------------+---------------------------------- We have a web application executable that, when run with -N24 (on our 24-core machine) hangs indefinitely, taking up 100% CPU. Introspecting with strace reveals that it's stuck in {{{yield}}} (on native SmartOS) and {{{shed_yield}}} (on both SmartOS LX and Linux emulation with KVM). If we run with +RTS -N2 -RTS, we do not observe this behavior. Attached is the output of truss(1) on an instance of a hung process. Other possibly-relevant information: this is an instance of the Warp web server and the Snap framework. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11181> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #609: Useful optimisation for set-cost-centre
by GHC 08 Dec '15

08 Dec '15

#609: Useful optimisation for set-cost-centre -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Profiling | Version: None Resolution: None | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Is this ticket still valid? I just tried to reproduce this, but I don't think we're generating `scc` calls anymore. (maybe scc operation is done by the RTS now?) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/609#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10527: Panic Simplifier ticks exhausted with type families
by GHC 08 Dec '15

08 Dec '15

#10527: Panic Simplifier ticks exhausted with type families -------------------------------------+------------------------------------- Reporter: sopvop | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I've tried to compile my vinyl-like records with 7.10.2-rc1 and got: {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.10.1.20150612 for x86_64-unknown-linux): Simplifier ticks exhausted When trying RuleFired Class op rreplace To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 225484 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Attached self contained test compiles with 7.10.1, but fails with 7.10.2-rc1 when compiled with optimizations. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10527> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 30