October 2015 - ghc-tickets

[GHC] #11037: Expose pop count primitives to cmm
by GHC 30 Oct '15

30 Oct '15

#11037: Expose pop count primitives to cmm -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- I can't actually invoke the various `MO_PopCnt width` prim ops from the literal Cmm syntax. Would it be possible to expose them via `machOps` in `CmmParse.y` as `popcnt8`, `popcnt16`, etc.? This would enable me to generate much more efficient code. I started hacking up a mostly Cmm-side implementation of a HashMap. This lets me directly index into fields in data constructors and the like, eliding the indirection of the array machinery and allowing a much more direct implementation. Other than this, until this point it has been going remarkably smoothly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11037> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11012: Support for unicode primes on identifiers.
by GHC 30 Oct '15

30 Oct '15

#11012: Support for unicode primes on identifiers. -------------------------------------+------------------------------------- Reporter: ghartshaw | Owner: Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | 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: -------------------------------------+------------------------------------- GHC should allow the (single/double/triple/quadruple) prime characters in Unicode to be allowed in identifiers. This would make them consistent with the ASCII apostrophe, which is usually used in place of a single prime. The current workaround for primes (using one or more apostrophes) is unwieldy for higher primes (e.g. {{{a'''}}} and {{{a''''}}}). All of the following identifiers should be valid. {{{ a' // U+0027 APOSTROPHE a′ // U+2032 PRIME a″ // U+2033 DOUBLE PRIME a‴ // U+2034 TRIPLE PRIME a⁗ // U+2057 QUADRUPLE PRIME }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11012> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10890: Incorrect redundant import warning for type classes
by GHC 30 Oct '15

30 Oct '15

#10890: Incorrect redundant import warning for type classes -------------------------------------+------------------------------------- Reporter: quchen | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 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 Revisions: | -------------------------------------+------------------------------------- Given the three files below, the import marked with (!!!) is reported as redundant. Upon deleting it, GHC reports that "has" is not a visible class method of BClass. This came up in the context of the MFP (#10751), with the correspondences Base<->Control.Monad, Extends<->Control.Monad.Fail. We would like to have Control.Monad re-export Control.Monad.Fail.MonadFail without its (clashing) member "fail" for the time being. For future compatibility, some modules should implement MonadFail right now, requiring us to import Control.Monad.Fail explicitly in order to write an instance. Said procedure leads to the described import warning, which breaks the validation script for example. {{{#!hs -- Base.hs module Base (AClass(..), BClass()) where import Extends (BClass()) class AClass a where has :: a }}} {{{#!hs -- Extends.hs module Extends where class BClass b where has :: b }}} {{{#!hs -- UseSite.hs module UseSite where import Base import Extends -- (!!!) data Bar = Bar instance AClass Bar where has = Bar instance BClass Bar where has = Bar }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10890> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #10928: Refine pattern synonym sigantures
by GHC 30 Oct '15

30 Oct '15

#10928: Refine pattern synonym sigantures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 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): | -------------------------------------+------------------------------------- > I think that the current state of pattern synonym signatures is quite > confusing, especially regarding the constraints. For those unfamiliar, > a signature looks like the following, > > {{{ > pattern ExNumPat :: (Show b) => (Num a, Eq a) => b -> T a > }}} > > The first constraint being the "provided constraints" and the second > the "required constraints". > > My main concern is when only a single constraint is specified then > these are treated as the provided constraints. The manual gives the > reason that this is the "more common" choice. It seems that this > motivation is driven by the original ticket which had a lengthy > discussion about GADTs. In my experience, the opposite is true, it is > more common to have required constraints. > > This is true especially in a few common cases such as `pattern Foo = > 27`, where users define pattern synonyms which have (overloaded) > literals on the RHS. The most general signature for such a pattern is > `pattern :: () => (Eq a, Num a) => a`. > > For this reason, I think it would be better if either > > 1. Only specifying one constraint corresponded to the required constraints > 2. We required users to specify both sets of constraints, even if the > provided constraints are empty. > > In terms of breakage, I don't think that pattern synonym signatures > are widely used yet. In both schemes it is possible to write backwards > compatible code by writing both sets of constraints. > > I think a lot of the confusion also arises from the unusual form of > the signature, it is unusual to specify two sets of constraints and I > suspect users tends to assume that a single set of constraints is > either provided or required depending on what they want it to mean. > Forcing the specification of both, forces the user to make the > distinction earlier rather than trying to decipher error messages. > This is copied from a message sent to ghc-devs. This ticket is to track the progress. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10928> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 32

Re: [GHC] #7608: LLVM only handles a hard-coded list of triples.
by GHC 30 Oct '15

30 Oct '15

#7608: LLVM only handles a hard-coded list of triples. -------------------------------------+------------------------------------- Reporter: singpolyma | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (LLVM) | Version: 7.7 Resolution: | Keywords: cross- | compiling llvm Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: 7610 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by erikd): * cc: erikd (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7608#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11001: BlockedIndefinitelyOnMVar thrown with live reference in unrelated finalizer
by GHC 29 Oct '15

29 Oct '15

#11001: BlockedIndefinitelyOnMVar thrown with live reference in unrelated finalizer -------------------------------------+------------------------------------- Reporter: exFalso | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.10.2 System | Keywords: | Operating System: Linux BlockedIndefinitelyOnMVar | finalize | Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I am not sure whether this is a bug, but it is certainly unexpected behaviour. The following code throws a BlockedIndefinitelyOnMVar in the forked thread even though the MVar would be eventually written to by an unrelated finalizer: {{{#!hs import Control.Concurrent import Data.IORef main :: IO () main = do mvar <- newEmptyMVar -- _ <- forkIO $ threadDelay 9999999999999 >> isEmptyMVar mvar >> return () ref <- newIORef () -- unrelated IORef _ <- mkWeakIORef ref (putMVar mvar ()) -- register finalizer _ <- forkFinally (takeMVar mvar :: IO ()) print threadDelay 1000000 }}} And indeed, if the forkIO line is uncommented no exception is thrown, as the new thread keeps another live reference to the MVar. Is this intended behaviour? Why does the MVar reference in the finalizer not count for BlockedIndefinitelyOnMVar? (A similar thing happens with STM primitives.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11001> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10998: Parser should suggest -XMagicHash
by GHC 29 Oct '15

29 Oct '15

#10998: Parser should suggest -XMagicHash -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: low | 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: -------------------------------------+------------------------------------- When using GHCi, this is leading to a weird situation where GHCi is actually suggesting an identifier with `#` in it, but also rejecting when you actually type it: {{{ ➜ ~ ghc-stage2 --interactive GHCi, version 7.11.20151016: http://www.haskell.org/ghc/ :? for help λ:1> :m + GHC.Prim λ:2> :t unsafe unsafeCoerce# unsafeFreezeArrayArray# unsafeFreezeSmallArray# unsafeThawSmallArray# unsafeFreezeArray# unsafeFreezeByteArray# unsafeThawArray# λ:2> :t unsafeCoerce# <interactive>:1:14: error: parse error (possibly incorrect indentation or mismatched brackets) λ:3> :set -XMagicHash λ:4> :t unsafeCoerce# unsafeCoerce# :: a -> b }}} (also tried with 7.10) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10998> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #545: GHCi + profiling doesn't work
by GHC 29 Oct '15

29 Oct '15

#545: GHCi + profiling doesn't work -------------------------------------+------------------------------------- Reporter: nilsanders | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 5.0 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 simonmar): * owner: => simonmar Comment: Work in progress: https://github.com/simonmar/ghc/tree/prof-ghci -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/545#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #545: GHCi + profiling doesn't work
by GHC 29 Oct '15

29 Oct '15

#545: GHCi + profiling doesn't work -------------------------------------+------------------------------------- Reporter: nilsanders | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 5.0 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 simonmar): * status: closed => new * type: bug => feature request * os: => Unknown/Multiple * component: Compiler => GHCi * failure: => None/Unknown * architecture: => Unknown/Multiple * milestone: => 8.0.1 * owner: nobody => * resolution: Wont Fix => Old description: > {{{ > Main.hs: > > module Main where > > main = putStrLn "Hi!" > > Compile this with profiling turned on: > > > ghc -prof -auto-all -o hello --make Main.hs > ghc-5.00: chasing modules from: Main.hs > Compiling Main ( Main.hs, ./Main.o ) > ghc: linking ... > > Try to load the file with GHCi: > > > ghci Main > ___ ___ _ > / _ \ /\ /\/ __(_) > / /_\// /_/ / / | | GHC Interactive, version > 5.00, For Haskell 98. > / /_\\/ __ / /___| | http://www.haskell.org/ghc/ > \____/\/ /_/\____/|_| Type :? for help. > > Loading package std ... linking ... done. > Skipping Main ( Main.hs, ./Main.o ) > ghc-5.00: fatal error: do_Elf32_Rel_relocations: > ./Main.o: unknown symbol `CC_LIST' > > }}} New description: {{{ Main.hs: module Main where main = putStrLn "Hi!" Compile this with profiling turned on: > ghc -prof -auto-all -o hello --make Main.hs ghc-5.00: chasing modules from: Main.hs Compiling Main ( Main.hs, ./Main.o ) ghc: linking ... Try to load the file with GHCi: > ghci Main ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 5.00, For Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help. Loading package std ... linking ... done. Skipping Main ( Main.hs, ./Main.o ) ghc-5.00: fatal error: do_Elf32_Rel_relocations: ./Main.o: unknown symbol `CC_LIST' }}} -- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/545#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4837: Template Haskell does not work in a profiled compiler.
by GHC 29 Oct '15

29 Oct '15

#4837: Template Haskell does not work in a profiled compiler. -------------------------------------+------------------------------------- Reporter: benl | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Profiling | Version: 7.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC doesn't work | Unknown/Multiple at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * owner: => simonmar * priority: low => high Comment: I'm working on this. It's mostly working already, the patch is on my github branch: https://github.com/simonmar/ghc/tree/prof-ghci -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4837#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0