January 2015 - ghc-tickets

[GHC] #9967: Pattern synonym type signature documentation out of date
by GHC 09 Jan '15

09 Jan '15

#9967: Pattern synonym type signature documentation out of date -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: 7.10.1-rc1 Documentation | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Section 7.3.9.3 of the 7.10.1 RC1 user's guide uses the old pattern synonym type syntax for `ExNumPat`. I'd fix it myself, but I'm not 100% sure I'd do it correctly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9967> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9934: Typo in GHC.RTS.Flags
by GHC 09 Jan '15

09 Jan '15

#9934: Typo in GHC.RTS.Flags -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.1-rc1 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: Other hour) | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Currently, the {{{GCFlags}}} data type in the {{{GHC.RTS.Flags}}} module of {{{base-4.8.0.0}}} has a field named {{{heapSizeSuggesionAuto}}} (without a {{{t}}} in {{{Suggesion}}}). Given that the corresponding struct field in {{{rts/Flags.h}}} is named {{{heapSizeSuggestionAuto}}}, this is probably a typo. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9934> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #5129: "evaluate" optimized away
by GHC 09 Jan '15

09 Jan '15

#5129: "evaluate" optimized away -------------------------------------+------------------------------------- Reporter: dons | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: fixed | Keywords: seq, Operating System: Unknown/Multiple | evaluate Type of failure: Incorrect result | Architecture: at runtime | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Feuerbach): Thanks Simon. I'll try to digest what you've written, and based on my understanding I'll write a better documentation for evaluate that would explain the issue. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5129#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9972: t7861 gives unexpected result (deferred type error)
by GHC 09 Jan '15

09 Jan '15

#9972: t7861 gives unexpected result (deferred type error) -------------------------------------+------------------------------------- Reporter: luite | 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'm not sure why `validate` does not trip on this, but the test case does not look obviously disabled to me, so I thought I'd just report it so at least it doesn't get unnoticed. GHC 7.8: {{{ "Hello" t7861: t7861.hs:11:5: Couldn't match type ‘a’ with ‘[a]’ ‘a’ is a rigid type variable bound by the type signature for f :: A a -> a at t7861.hs:10:6 Expected type: A a -> a Actual type: A a -> [a] Relevant bindings include f :: A a -> a (bound at t7861.hs:11:1) In the expression: doA In an equation for ‘f’: f = doA (deferred type error) }}} On GHC 7.10 the result is (both with and without optimization) {{{ "Hello" "Bad" }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9972> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #3676: realToFrac doesn't sanely convert between floating types
by GHC 09 Jan '15

09 Jan '15

#3676: realToFrac doesn't sanely convert between floating types -------------------------------------+------------------------------------- Reporter: draconx | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Core Libraries | Version: 6.12.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: None/Unknown | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by lelf): * cc: me@…, core-libraries-committee@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3676#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5129: "evaluate" optimized away
by GHC 09 Jan '15

09 Jan '15

#5129: "evaluate" optimized away -------------------------------------+------------------------------------- Reporter: dons | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: fixed | Keywords: seq, Operating System: Unknown/Multiple | evaluate Type of failure: Incorrect result | Architecture: at runtime | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): A later note, in the light of [https://www.haskell.org/pipermail/ghc- devs/2015-January/007900.html this email thread]. Looking at the Haddock documentation for `evaluate`, Roman said: we seem to have three possible implementations for `evaluate`: {{{ 1) evaluate x = return $! x 2) evaluate x = (return $! x) >>= return 3) evaluate x = \s -> seq# x s }}} Now (1) is too strict: `(evaluate (error "urk") True)` should yield `True`. And, contrary to my claim in the email thread, (2) suffers from comment:2 above: inlining can mean that the argument to `evaluate` never gets evaluated. Consider, under (2) {{{ evaluate = \x -> (return $! x) >>= return = \x. \s. case return $! x s of (s1, r) -> return r s1 = \x s. x `seq` case (s,x) of (s1, r) -> return r s1 = \x s. x `seq` (s,x) = \x s. case x of _ -> (s,x) }}} Now consider the call in comment:2: {{{ evalutate poss_err >> assertFailure "foo"` = (inline >>) \s -> case evaluate poss_err of (s1, _) -> assertFailure "foo" s1 = (inline evaluate) \s -> case (case x of _ -> (s,x)) of (s1, _) -> assertFailure "foo" s1 = (case of case) case x of _ -> assertFailure "foo" s1 }}} and now, as explained in comment:2, since `assertFailure` diverges, GHC feel free to discard the case on `x`. Using a primop `seq# :: a -> State# -> (State#, a)` means that the I/O options that follows, which consumes the state that comes out of the `seq#` simply can't start until the `seq#` has executed. And that is what we want for `evaluate`. So only (3) will do. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5129#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9904: ghc: out of memory, requested 1048576 bytes on openbsd
by GHC 09 Jan '15

09 Jan '15

#9904: ghc: out of memory, requested 1048576 bytes on openbsd ------------------------------------+---------------------------------- Reporter: vu3rdd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: cabal-install | Operating System: OpenBSD Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ------------------------------------+---------------------------------- Hi, I freshly installed OpenBSD 5.6 on an AMD64 system. I also installed ghc and cabal-install from the OpenBSD package system. The version in OpenBSD 5.6 package tree is: $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.6.3 $ cabal --version cabal-install version 1.16.0.2 using version 1.16.0 of the Cabal library Now, I do a `cabal update' and `cabal install cabal-install'. I get this error: ghc: out of memory, requested 1048576 bytes I am not sure if it is a cabal-install bug or a ghc bug or an OpenBSD bug. So, if you think it is not a ghc bug, please go ahead and close this bug (and accept my apologies..), I will open it against cabal-install or openbsd instead. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9904> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #5821: SPECIALISE fails with a cryptic warning
by GHC 08 Jan '15

08 Jan '15

#5821: SPECIALISE fails with a cryptic warning -------------------------------------+------------------------------------- Reporter: rl | Owner: ezyang Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D610 -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => patch -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5821#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5821: SPECIALISE fails with a cryptic warning
by GHC 08 Jan '15

08 Jan '15

#5821: SPECIALISE fails with a cryptic warning -------------------------------------+------------------------------------- Reporter: rl | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D610 -------------------------------------+------------------------------------- Changes (by ezyang): * differential: => Phab:D610 Comment: The ideal resolution is to teach the RULE engine how to deal with type families, but until then I've just augmented the error message with a little note. It might even be possible to look at type and realize that type families are involved (and maybe even suggest a better type) but that seems way more involved than just fixing it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5821#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5821: SPECIALISE fails with a cryptic warning
by GHC 08 Jan '15

08 Jan '15

#5821: SPECIALISE fails with a cryptic warning -------------------------------------+------------------------------------- Reporter: rl | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by ezyang: Old description: > Example: > > {{{ > type family T a > type instance T Int = Bool > > foo :: Num a => a -> T a > foo = undefined > > {-# SPECIALISE foo :: Int -> Bool #-} > }}} > > GHC produces this warning: > > {{{ > RULE left-hand side too complicated to desugar > case cobox of _ { GHC.Types.Eq# cobox -> > (foo @ Int $dNum) > `cast` (<Int> -> cobox :: (Int -> T Int) ~# (Int -> Bool)) > } > }}} > > Given that rewrite rules don't reliably work in the presence of type > families, I somewhat suspect that GHC won't be able to generate a > sensible specialisation here but it should produce a better diagnostic. New description: Example: {{{ {-# LANGUAGE TypeFamilies #-} module A where type family T a type instance T Int = Bool foo :: Num a => a -> T a foo = undefined {-# SPECIALISE foo :: Int -> Bool #-} }}} GHC produces this warning: {{{ RULE left-hand side too complicated to desugar case cobox of _ { GHC.Types.Eq# cobox -> (foo @ Int $dNum) `cast` (<Int> -> cobox :: (Int -> T Int) ~# (Int -> Bool)) } }}} Given that rewrite rules don't reliably work in the presence of type families, I somewhat suspect that GHC won't be able to generate a sensible specialisation here but it should produce a better diagnostic. -- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5821#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0