September 2013 - ghc-tickets

[GHC] #8246: Role annotations does not allow the use of parenthesis
by GHC 17 Sep '13

17 Sep '13

#8246: Role annotations does not allow the use of parenthesis -------------------------------------+------------------------------------- Reporter: DaniilFrumin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 7.7 Keywords: roles | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- There is an inconsistency in roles/kinds annotations wrt parenthesis. For example, the following code compiles just fine {{{ data A (a::*) = A }}} unlike this code {{{ data A (a@R) = A }}} which results in a compilation error: Unexpected type `a@R' where type variable expected In the declaration of `A (a@R)' As Austin Seipp has pointed out, it boils down to simply: 'data A (a) = A' This also prompts for further [http://ghc.haskell.org/trac/ghc/wiki/Roles#Roleandkindannotations discussion] about role annotations in presence of kind annotations [1]. For example, should '((a :: *)@R)' be a correct annotation? Related (?) ticket: #8185 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8246> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8185: Change role annotation syntax
by GHC 17 Sep '13

17 Sep '13

#8185: Change role annotation syntax ----------------------------------------------+---------------------------- Reporter: goldfire | Owner: Type: feature request | goldfire Priority: normal | Status: new Component: Compiler | Milestone: 7.8.1 Keywords: | Version: 7.7 Architecture: Unknown/Multiple | Operating System: Difficulty: Moderate (less than a day) | Unknown/Multiple Blocked By: | Type of failure: Related Tickets: | None/Unknown | Test Case: | Blocking: ----------------------------------------------+---------------------------- Currently, role annotations look like this: {{{ data Foo a@N = ... }}} I've received several criticisms of this syntax: * It is not backward compatible. If a library wishes to use role annotations and remain compilable with earlier versions of GHC, preprocessor commands are necessary. * It is inscrutable for someone not well-versed in roles. * It reminds people of as-patterns, which it is unrelated to. * It is conceivable that it would conflict with type-level as-patterns. For these reasons, I propose the following: {{{ data Foo a {-# ROLE Nominal #-} = ... }}} This syntax, while verbose, eliminates these concerns, considering that the new syntax is easily searchable for someone who doesn't know it. I have proposed something similar on ghc-devs, with no response, so I will implement it shortly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8185> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #8234: Remove role annotations on type synonyms
by GHC 17 Sep '13

17 Sep '13

#8234: Remove role annotations on type synonyms ------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Currently, role annotations are allowed on vanilla type synonyms. However, Simon points out that this is very fragile, because a type synonym can be expanded at any time, thus losing a user's intended restriction. Solution: remove these annotations entirely. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8234> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #5435: GHCi linker should run constructors for linked libraries
by GHC 17 Sep '13

17 Sep '13

#5435: GHCi linker should run constructors for linked libraries -------------------------------------+------------------------------------ Reporter: pumpkin | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.2.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: 7746, 8199 | Related Tickets: #3658 -------------------------------------+------------------------------------ Comment (by Edward Z. Yang <ezyang@…>): In [changeset:4b22a8b57b1791d0a596869040eee8856fc9bb7d/testsuite]: {{{ #!CommitTicketReference repository="testsuite" revision="4b22a8b57b1791d0a596869040eee8856fc9bb7d" Add missing Windows stdout/stderr output for #5435. Signed-off-by: Edward Z. Yang <ezyang(a)mit.edu> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5435#comment:39> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5928: INLINABLE fails to specialize in presence of simple wrapper
by GHC 17 Sep '13

17 Sep '13

#5928: INLINABLE fails to specialize in presence of simple wrapper -------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): On an email thread Johan points out that calls to `f` do not lead to specialised code for `g`, even though `f` has an INLINE pragma: {{{ f = g {-# INLINE f #-} g :: Hashable a => ... g = ... {-# INLINABLE g #-} }}} This was a surprise to me. And yes, it's because specialisation currently occurs before any inlning. Currently the first "gentle" pass of simplification does no inlining. But I think that is for out-of-date reasons. If it honoured INLINE pragmas, then the above code would work just fine. But I got diverted, and the code is lying around on my disk waiting for attention. Reviving this ticket is a good incentive to get back to it. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5928#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6166: Performance regression in mwc-random since 7.0.x
by GHC 17 Sep '13

17 Sep '13

#6166: Performance regression in mwc-random since 7.0.x --------------------------------------------+------------------------------ Reporter: bos | Owner: Type: bug | Status: new Priority: high | Milestone: 7.6.2 Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by Khudyakov): I've slightly simplified test case. I've tried to replace call to uniform with mock function but to avail. It's certainly possible to add only relevant parts of mwc-random. Only small part is actually used Test case is slow (~100x) version of program. It's quite fragile. Small changes can return program to normal performance. Known methods: replace definition of `f` with constant (marked as fast), float `blocks` to the top level. {{{ {-# LANGUAGE BangPatterns #-} import qualified Data.Vector.Unboxed as I import Data.Vector.Unboxed ((!)) import Data.Word import Data.Bits import Control.Monad import System.Random.MWC main :: IO () main = do g <- create replicateM_ (100*1000) $ standard g standard :: GenIO -> IO Double {-# INLINE standard #-} standard gen = do ri <- uniform gen return $! blocks ! fromIntegral ((ri :: Word32) .&. 127) where blocks :: I.Vector Double blocks = I.cons r -- Removing cons $ I.unfoldrN 130 go $ T r f where go (T b g) = let !u = T h (exp (-0.5 * h * h)) h = sqrt (-2 * log (v / b + g)) in Just (h, u) {-# NOINLINE blocks #-} v,r,f :: Double v = 9.91256303526217e-3 r = 3.442619855899 -- f = 2.669629083880923e-3 -- FAST f = exp (-0.5 * r * r) -- SLOW -- Unboxed 2-tuple data T = T {-# UNPACK #-} !Double {-# UNPACK #-} !Double }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6166#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3389: CPP strips out C-style comments
by GHC 17 Sep '13

17 Sep '13

#3389: CPP strips out C-style comments -------------------------------------+------------------------------------ Reporter: nominolo | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 7.0.1 Component: Driver | Version: 6.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: T3389 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by nomeata): * status: new => closed * resolution: => fixed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3389#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3389: CPP strips out C-style comments
by GHC 17 Sep '13

17 Sep '13

#3389: CPP strips out C-style comments -------------------------------------+------------------------------------ Reporter: nominolo | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.0.1 Component: Driver | Version: 6.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: T3389 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Joachim Breitner <mail@…>): In [changeset:168ac1b55f21e541487bf65851e20fe5a92a951d/testsuite]: {{{ #!CommitTicketReference repository="testsuite" revision="168ac1b55f21e541487bf65851e20fe5a92a951d" In the test that tests -optP -C, also pass -optP -ffreestanding This closes #3389, and makes the testsuite go through again. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3389#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3389: CPP strips out C-style comments
by GHC 17 Sep '13

17 Sep '13

#3389: CPP strips out C-style comments -------------------------------------+------------------------------------ Reporter: nominolo | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.0.1 Component: Driver | Version: 6.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: T3389 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by nomeata): * owner: igloo => * status: closed => new * resolution: wontfix => -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3389#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3389: CPP strips out C-style comments
by GHC 17 Sep '13

17 Sep '13

#3389: CPP strips out C-style comments -------------------------------------+------------------------------------ Reporter: nominolo | Owner: igloo Type: feature request | Status: closed Priority: normal | Milestone: 7.0.1 Component: Driver | Version: 6.10.2 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: T3389 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): I can confirm `int-e`s finding here. Should we just add `-ffreestanding` to the test case? I don’t find any other use or documentation of `-optP -C` in ghc or the testsuite. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3389#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0