March 2016 - ghc-tickets

[GHC] #11684: Fix tests with Clang
by GHC 23 Mar '16

23 Mar '16

#11684: Fix tests with Clang -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Configuring GHC with `--with-gcc=clang` and then running the tests currently causes over 100 test failues. The vast majority are due to stderr differences due to Clang producing more warnings, specifically `warning: argument unused during compilation`. The obvious solution would be to filter these out in the testsuite runner. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11684> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #11723: TYPE 'UnboxedTupleRep is a lie
by GHC 23 Mar '16

23 Mar '16

#11723: TYPE 'UnboxedTupleRep is a lie -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: high | 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: -------------------------------------+------------------------------------- From @RyanGlScott, comment:28:ticket:11471: I notice that there's a single constructor of `RuntimeRep` for unboxed tuples (`UnboxedTupleRep`). Does this mean something like this should be allowed? {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE KindSignatures #-} module Example where import Data.Typeable import GHC.Exts data Wat (a :: TYPE 'UnboxedTupleRep) = Wat a }}} Currently, that fails to compile due to a separate GHC panic: {{{ $ /opt/ghc/head/bin/ghc -O2 -fforce-recomp Example.hs [1 of 1] Compiling Example ( Example.hs, Example.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.1.20160317 for x86_64-unknown-linux): unboxed tuple PrimRep Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} But wouldn't this be dangerous anyway? After all, unboxed tuples are supposed to represent arguments on the stack, so couldn't unboxed tuple polymorphic potentially lead to the RTS miscalculating how much data to read? Or am I misreading this? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11723> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #11635: Missleading error message when using polymorpic kinds
by GHC 23 Mar '16

23 Mar '16

#11635: Missleading error message when using polymorpic kinds -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 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: -------------------------------------+------------------------------------- Example program: {{{ {-# LANGUAGE TypeInType, KindSignatures, ExplicitForAll #-} import Data.Kind data X (a :: forall k. k -> * ) = X }}} errors with {{{ polykind.hs:3:1: error: Expecting one more argument to ‘a’ Expected kind ‘k0’, but ‘a’ has kind ‘forall k. k -> *’ }}} Without `TypeInType`, the error is better, yet gives false hint: {{{ polykind.hs:3:23: error: Illegal kind: forall k. k -> * Did you mean to enable TypeInType? }}} --- For the record 7.10.3 doesn't recognise polymorphic kinds at all (same program, without `Data.Kind` import): {{{ polykind.hs:3:23: parse error on input ‘forall’ }}} Which makes me think that polymorphic kinds are somehow supported, but maybe not. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11635> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #7198: New codegen more than doubles compile time of T3294
by GHC 23 Mar '16

23 Mar '16

#7198: New codegen more than doubles compile time of T3294 -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.2 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #4258 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes, if improving STG->Cmm can be done without major contortions -- and the additional complexity is documented -- that sounds perfect -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7198#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7198: New codegen more than doubles compile time of T3294
by GHC 23 Mar '16

23 Mar '16

#7198: New codegen more than doubles compile time of T3294 -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.2 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #4258 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): The basic problem here is that * The Stg->Cmm code generator generates suboptimal code * The `CmmSink` pass would mostly optimise it away, but it is only run at -O. * The extra code is hurting compile time * The old code generator generated simpler code, and thus was faster It's not obvious what the solution is. We might need several improvements in various places. it's not clear whether the lets should be flattened; if so, this is the job of earlier phases (simplifier or CorePrep). Flattening lets is a tradeoff, and I suspect the simplifier is already doing a reasonable job here, and has just decided not to in this case. In some cases I made the STG->Cmm code generator a bit more clever, so as to generate less code and improve compile time, even though later optimisation phases would have produced the same result. I like this approach because it improves compile times for -O0, relying on later optimisation is brittle, and a few tweaks can have a big effect due to the regular patterns that occur in Cmm. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7198#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5927: A type-level "implies" constraint on Constraints
by GHC 22 Mar '16

22 Mar '16

#5927: A type-level "implies" constraint on Constraints -------------------------------------+------------------------------------- Reporter: illissius | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.4.1 checker) | 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 maoe): * cc: maoe (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5927#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2893: Implement "Quantified contexts" proposal
by GHC 22 Mar '16

22 Mar '16

#2893: Implement "Quantified contexts" proposal -------------------------------------+------------------------------------- Reporter: porges | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.10.1 Resolution: | Keywords: proposal 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 maoe): * cc: maoe (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2893#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5850: Greater customization of GHCi prompt
by GHC 22 Mar '16

22 Mar '16

#5850: Greater customization of GHCi prompt -------------------------------------+------------------------------------- Reporter: JamesFisher | Owner: niksaz Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.4.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9994 | Differential Rev(s): Phab:D623 Wiki Page: | -------------------------------------+------------------------------------- Changes (by niksaz): * owner: => niksaz -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5850#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11737: Make validate --testsuite-only behave correctly w.r.t. bindisttest
by GHC 22 Mar '16

22 Mar '16

#11737: Make validate --testsuite-only behave correctly w.r.t. bindisttest -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Build System | 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: -------------------------------------+------------------------------------- I'm in the process of validating. One of the error messages is a bit wrong, so I change the error message code. But the change is more than just the phrasing of the message; it's conceivable that a mistake in this edit will cause misbehavior, but only on rejected programs. So I determine that I don't need to re-run the full validation, but just recompile and run the testsuite. I recompile. I say `validate --testsuite-only`. And then, after I read the results, I realize that validation uses the bindist version of the GHC, which isn't the one that I just built. So have to do it all again. Thus, request: have `--testsuite-only` not use the bindist version. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11737> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #5850: Greater customization of GHCi prompt
by GHC 22 Mar '16

22 Mar '16

#5850: Greater customization of GHCi prompt -------------------------------------+------------------------------------- Reporter: JamesFisher | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.4.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9994 | Differential Rev(s): Phab:D623 Wiki Page: | -------------------------------------+------------------------------------- Changes (by niksaz): * owner: niksaz => -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5850#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0