- ghc-tickets - Haskell.org

Re: [GHC] #2189: hSetBuffering stdin NoBuffering doesn't work on Windows
by GHC 20 Mar '17

20 Mar '17

#2189: hSetBuffering stdin NoBuffering doesn't work on Windows -------------------------------------+------------------------------------- Reporter: FalconNL | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 6.8.2 Resolution: | Keywords: hsetbuffering | buffering buffer Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11394, #13440 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * related: #11394 => #11394, #13440 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2189#comment:52> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1600: Optimisation: CPR the results of IO
by GHC 20 Mar '17

20 Mar '17

#1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8598 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by akio): Replying to [comment:68 simonpj]: > Akio, I've fixed that wrapper issue. Thank you! > > What's next on this ticket? After rebasing the branch on top of your fix, the nofib improvements are again consistent but very small: {{{ -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- hpg +0.2% -1.1% 0.212 0.212 0.0% infer +0.3% -1.2% 0.054 0.054 0.0% solid +0.3% -6.6% 0.181 0.181 0.0% sphere +0.3% -1.7% 0.086 0.086 0.0% -------------------------------------------------------------------------------- Min +0.2% -6.6% -23.2% -23.4% -19.2% Max +0.7% +0.1% +16.3% +16.2% 0.0% Geometric Mean +0.3% -0.1% -0.1% -0.1% -0.3% }}} The branch can perform nested CPR in simple cases, but it fails to transform some cases I would like it to. Currently I'm trying to make `extendSigsWithLam` a bit more aggressive by allowing it to generate nested CPR information. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:69> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13459: sdist make target doesn't create required ghc-tarballs dir
by GHC 20 Mar '17

20 Mar '17

#13459: sdist make target doesn't create required ghc-tarballs dir -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: lowest | 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: -------------------------------------+------------------------------------- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13459> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #12518: Allow customizing immutable package dbs by stacking
by GHC 20 Mar '17

20 Mar '17

#12518: Allow customizing immutable package dbs by stacking -------------------------------------+------------------------------------- Reporter: harendra | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Package | Version: 8.0.1 system | 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: -------------------------------------+------------------------------------- = Package Selection Across Multiple Package DBs = As explained by ezyang, when there are multiple package dbs, GHC chooses the packages to use in the following manner. I might have misunderstood so please correct me if I am wrong. * If there are multiple packages with different versions the latest non- broken version is chosen. * If the there are multiple packages with the same version the behavior is unspecified. * If there are multiple packages with the same package-id (shadowing) then the one which comes first in `GHC_PACKAGE_PATH` or which comes first on command line (`-package` flag) will be used. = The Problem = The build tool `Stack` implements stacked package databases. It uses a base package database and then stacks another package database on top of it to customise it further without modifying. The behavior is such that the package db on top of the stack completely overrides the ones below. That means you choose a package from top of the stack even if the version is older. Stack implements this by passing explicit package-ids of the packages to GHC. This scheme works well for cabal projects where we know ALL the packages used by the project in advance. But it does not work for scripts run using runghc. In that case we do not know the packages required by the script in advance and therefore cannot pass the package-ids to GHC. That means we cannot make GHC use the packages in the right way. GHC will choose the latest version even though we want it to choose a possibly older version from the top of the db stack. = Proposed Solution = Implement a new CLI option, something like `--stacked-pkg-dbs`. If this option is used GHC will use `GHC_PACKAGE_PATH` or the -package-db options as a stack of dbs. The first db in the path or the first CLI option will be considered the top of the stack. GHC will choose a package from the first db from the top of the stack irrespective of the version of the package. If the package is broken it should report error rather than silently choosing from the next db. This will allow us to modify an immutable package db by stacking another db on top. Implementing this as a separate option will keep the existing behavior so as to remain backward compatible. This has been discussed in a stack issue on github [https://github.com/commercialhaskell/stack/issues/1957 here]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12518> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

Fw: many thanks
by matthew 20 Mar '17

20 Mar '17

Greetings! I wanted to thank you a lot for all you've done, it was a real help. Please read my whole message here http://pleasure.stgeorgebrainbalance4life.com/7372 Pardon my monkey thumbs, matthew

1 0

[GHC] #11796: Warn about unwanted instances in a modular way
by GHC 20 Mar '17

20 Mar '17

#11796: Warn about unwanted instances in a modular way -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 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: -------------------------------------+------------------------------------- I like to propose the following way to warn about instances that are unwanted by some programmers. First step is to mark the instances at their definition site like so: {{{#!hs {-# WARN_INSTANCE tuple #-} instance Foldable ((,) a) where ... {-# WARN_INSTANCE tuple #-} instance Functor ((,) a) where ... {-# WARN_INSTANCE tuple #-} instance Foldable ((,,) a b) where ... {-# WARN_INSTANCE tuple #-} instance Functor ((,,) a b) where ... }}} This way, all the above instances are collected in an instance group labelled `tuple`. At the use sites we introduce a GHC warning option like `-fwarn-instance=tuple`. This warns about any place where any of the `tuple` instances is used. We can either place {{{ GHC-Options: -fwarn-instance=tuple }}} in a Cabal package description in order to issue warnings in a whole package or we can put {{{ {-# OPTIONS_GHC -fwarn-instance=tuple #-} }}} at the top of a module in order to enable the warning per module. Another candidate for an instance group might be `numeric` for numeric instances of functions and tuples in the `NumInstances` package. What does it mean to use an instance? I would say, if omitting an `instance X Y` would lead to a "missing instance" type error at place Z in a module, then `instance X Y` is used at place Z. There might be an even more restrictive option like `-fforbid- instance=tuple`. This would not only warn about an instance usage, but it would cause a type error. Essentially it should treat all `tuple` instances as if they were not defined. (Other instances might depend on `tuple` instances and if the `tuple` instances weren't there the compiler would not even reach the current module. I do not know, whether this case needs special treatment. We might require that any instance depending on `tuple` must be added to the `tuple` group as well or it might be added automatically.) The advantage of a type error is that we see all problems from `tuple` instances also in the presence of other type errors. Warnings would only show up after a module is otherwise type correct. This solution requires cooperation of the instance implementor. Would that work in practice? Otherwise we must think about ways to declare instance groups independently from the instance declaration and we get the problem of bringing the instance group names into the scope of the importing module. A separate discussion must be held on whether `-fwarn-instance=tuple` should be part of `-Wall`. I think that people should be warned about `tuple` instances early because they won't expect that there is a trap when using `length` and `maximum` and so on. One might also think about generalizations, e.g. whether {{{ {-# WARN_INSTANCE tuple, functor #-} }}} should be allowed in order to put an instance in several groups or whether there should be a way to compose a group from subgroups. Another topic would be a form of instance group disambiguation. Instance groups might be qualified with module or package names. I think package names are more appropriate, like so `-fwarn-instance=base:tuple`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11796> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #13442: Add a coercion/cast operator to CMM
by GHC 20 Mar '17

20 Mar '17

#13442: Add a coercion/cast operator to CMM -------------------------------------+------------------------------------- Reporter: erikd | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- While trying to implement casts between floating-point and integral types #4092) @rwbarton suggested the following CMM: {{{ stg_wordToFloatzh(W_ w) { D_ d; STK_CHK_P_LL(WDS(1), stg_wordToFloatzh, w); Sp(-1) = w; d = Sp(-1); return (d); } }}} This code works outside of GHC, but when I try to add it as `rts/CastFloatWord.cmm` the CMM linter complains with: {{{ Cmm lint error: in basic block c5 in assignment: _c2::F64 = I64[Sp + -1 * 8]; Reg ty: F64 Rhs ty: I64 Program was: {offset c6: // global _c1::I64 = R1; //tick src<rts/CastFloatWord.cmm:(7,1)-(13,1)> if (Sp - 1 * 8 < SpLim) goto c3; else goto c5; c3: // global //tick src<rts/CastFloatWord.cmm:9:35-100> R1 = _c1::I64; R2 = stg_wordToFloatzh; call stg_gc_prim_p_ll(R1, R2) args: 8, res: 0, upd: 8; c5: // global I64[Sp + -1 * 8] = _c1::I64; _c2::F64 = I64[Sp + -1 * 8]; D1 = _c2::F64; call (P64[(old + 8)])(D1) args: 8, res: 0, upd: 8; } }}} For hand written CMM code like this, it would be nice to have a cast/coercion to allow this code to pass the linter. Looking for suggestions as to the syntax. I suspect that it would be best if the destination type was made explicit in the cast operation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13442> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #13449: Multiple pattern synonym declarations for one signature
by GHC 19 Mar '17

19 Mar '17

#13449: Multiple pattern synonym declarations for one signature -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm not sure if I've seen this before. I want to be able to write {{{#!hs data Ty a where TBool :: Ty Bool data Exp a where Lit :: Ty a -> a -> Exp a pattern Fls, Tru :: () => a ~ Bool => Exp a pattern Fls = Lit TBool False pattern Tru = Lit TBool False }}} instead of {{{#!hs pattern Fls :: () => a ~ Bool => Exp a pattern Fls = Lit TBool False pattern Tru :: () => a ~ Bool => Exp a pattern Tru = Lit TBool False }}} just as this is allowed {{{#!hs fls, tru :: Exp Bool fls = Lit TBool False tru = Lit TBool False }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13449> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13387: Segfault when profiling on OS X
by GHC 19 Mar '17

19 Mar '17

#13387: Segfault when profiling on OS X -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.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 built a profiled version of GHC using the `prof` flavour. Then attempting to profile some programs with this executable causes segfaults reliably. 1. Build GHC with the `prof` flavour 2. inplace/bin/ghc-stage2 Main.hs -O2 -fforce-recomp +RTS -p -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13387> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13453: Seemingly can't mix ImplicitParams in where clauses
by GHC 19 Mar '17

19 Mar '17

#13453: Seemingly can't mix ImplicitParams in where clauses -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Keywords: | Operating System: Unknown/Multiple ImplicitParams | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- These are fine {{{#!hs v = () where a = True b = 'a' }}} {{{#!hs v = () where ?a = True ?b = 'a' }}} but the moment one of them is an `ImplicitParams` it fails to parse {{{#!hs -- tAMA.hs:9:3-4: error: Parse error in pattern: ?b -- Compilation failed. v = () where a = True ?b = 'a' -- tAMA.hs:9:3: error: parse error on input ‘b’ -- Compilation failed. v = () where ?a = True b = 'a' }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13453> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2