November 2014 - ghc-tickets

Re: [GHC] #4114: Add a flag to remove/delete intermediate files generated by GHC
by GHC 13 Nov '14

13 Nov '14

#4114: Add a flag to remove/delete intermediate files generated by GHC -------------------------------------+------------------------------------- Reporter: guest | Owner: VictorDenisov Type: feature | Status: new request | Milestone: 7.10.1 Priority: low | Version: 6.10.4 Component: Compiler | Keywords: newcomer Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #2258 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by jstolarek): * keywords: => newcomer -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4114#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2258: ghc --cleanup
by GHC 13 Nov '14

13 Nov '14

#2258: ghc --cleanup -------------------------------------+------------------------------------- Reporter: claus | Owner: VictorDenisov Type: feature | Status: new request | Milestone: 7.10.1 Priority: lowest | Version: 6.8.2 Component: Compiler | Keywords: newcomer Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #4114 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by jstolarek): * keywords: => newcomer -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2258#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9763: Implement Foldable methods for Array directly
by GHC 13 Nov '14

13 Nov '14

#9763: Implement Foldable methods for Array directly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Currently, they're implemented via conversion to lists. This works out sanely for `foldr` and `foldr1`, after some transformations, but it's rather less sane for left folds. Left folds end up "twisted" like their list counterparts, giving potentially surprising performance characteristics. For `Array`, left and right folds can reasonably be expected to be symmetrical. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9763> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9428: Pretty printer bad formatting
by GHC 13 Nov '14

13 Nov '14

#9428: Pretty printer bad formatting -------------------------------------+------------------------------------- Reporter: terrelln | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Driver | Version: 7.6.3 Keywords: pretty print | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Other Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When compiling with `-fwarn-incomplete-patterns`, the first test case `s17.hs` (attached) outputs unmatched patterns correctly. {{{ test.hs:4:1: Warning: Pattern match(es) are non-exhaustive In an equation for `f': Patterns not matched: B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ A B B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ A B B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ B _ A B A B ... }}} However, when compiling `s18.hs` each argument is printed on its own line. 16 lines of the output are included below. {{{ test.hs:4:1: Warning: Pattern match(es) are non-exhaustive In an equation for `f': Patterns not matched: B _ B _ B _ B _ B _ B _ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9428> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #9431: integer-gmp small Integer multiplication does two multiplications on x86
by GHC 13 Nov '14

13 Nov '14

#9431: integer-gmp small Integer multiplication does two multiplications on x86 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- `timesInteger` begins thusly: {{{ timesInteger :: Integer -> Integer -> Integer timesInteger (S# i) (S# j) = if isTrue# (mulIntMayOflo# i j ==# 0#) then S# (i *# j) else -- ... }}} The x86 backend implements `mulIntMayOflo#` as a (word, word) -> double word multiplication, followed by bit manipulation to test for overflow of the low word. Then, if there was no overflow, on the next line we multiply the operands again. We should be able to do better here. We need a new primop that combines `mulIntMayOflo#` with the actual multiplication result, at least in the non-overflow case (though with some more work we might be able to turn the double word result directly into a large Integer), and then we need to update `timesInteger` to use it. The LLVM backend probably has the same behavior, though it might be smart enough to notice that the multiplication is repeated; I haven't checked its assembly output. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9431> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9442: Building GHC with Clang
by GHC 13 Nov '14

13 Nov '14

#9442: Building GHC with Clang -------------------------------------+------------------------------------- Reporter: conradwt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- How does one build GHC from scratch using Clang on OS X 10.9 and 10.10? At this time, I'm seeing the following message: $ ./configure checking for gfind... /opt/local/bin/gfind checking for sort... /usr/bin/sort checking for GHC version date... inferred 7.9.20140813 checking for ghc... no configure: error: GHC is required. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9442> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9608: Type level as-patterns
by GHC 13 Nov '14

13 Nov '14

#9608: Type level as-patterns -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Hello! I would love to see type level as-patterns in Haskell. They would be very helpfull when writing complex type families. Here is a good example: {{{ #!haskell type family XOut m1 m2 where XOut (ValueS vbase vs) (MonadCtx2Dummy' m2 s2 env set m s) = MonadCtx2Dummy' m2 s2 (XEnv env (ValueS vbase vs)) (XSet set (ValueS vbase vs)) m (XSafety s (ValueS vbase vs)) }}} could then be written as: {{{ #!haskell type family XOut m1 m2 where XOut a@(ValueS vbase vs) (MonadCtx2Dummy' m2 s2 env set m s) = MonadCtx2Dummy' m2 s2 (XEnv env a) (XSet set a) m (XSafety s a) }}} which is much cleaner, less verbose and lot safer then the first one. (Safer in terms of accidental typos when refactoring etc). Cheers, Wojciech -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9608> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9794: Additional assert function: assert :: Bool -> String -> a -> a
by GHC 13 Nov '14

13 Nov '14

#9794: Additional assert function: assert :: Bool -> String -> a -> a -------------------------------------+------------------------------------- Reporter: rodlogic | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Currently, we have an assert function in GHC.Base: {{{#!hs -- Assertion function. This simply ignores its boolean argument. -- The compiler may rewrite it to @('assertError' line)@. -- | If the first argument evaluates to 'True', then the result is the -- second argument. Otherwise an 'AssertionFailed' exception is raised, -- containing a 'String' with the source file and line number of the -- call to 'assert'. -- -- Assertions can normally be turned on or off with a compiler flag -- (for GHC, assertions are normally on unless optimisation is turned on -- with @-O@ or the @-fignore-asserts@ -- option is given). When assertions are turned off, the first -- argument to 'assert' is ignored, and the second argument is -- returned as the result. -- SLPJ: in 5.04 etc 'assert' is in GHC.Prim, -- but from Template Haskell onwards it's simply -- defined here in Base.lhs assert :: Bool -> a -> a assert _pred r = r }}} This get's rewritten by the type checker to assertError: {{{#!hs Note [Adding the implicit parameter to 'assert'] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The typechecker transforms (assert e1 e2) to (assertError "Foo.hs:27" e1 e2). This isn't really the Right Thing because there's no way to "undo" if you want to see the original source code in the typechecker output. We'll have fix this in due course, when we care more about being able to reconstruct the exact original program. }}} I would like to propose an additional one: {{{#!hs assertStr :: Bool -> String -> a -> a assertStr _pred msg r = r }}} NOTE: what is a name that is more consistent with the code base? That would get rewritten as: {{{#!hs assertError ("Foo.hs:27 - " ++ show msg) e1 e2 }}} Why? This makes assertions a bit more meaningful when reading the error message, and they can replace the existing ASSERT2 macros throughout the code base. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9794> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9792: map/coerce rule never seems to fire
by GHC 12 Nov '14

12 Nov '14

#9792: map/coerce rule never seems to fire -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Runtime Blocked By: | performance bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- If I write a nice, simple use, like: {{{#!hs myPotato = map coerce }}} or even {{{#!hs myPotato = Data.OldList.map coerce }}} the "`map/coerce`" rule does not fire. It looks like there are two things getting in the way: 1. The `map` rule fires first, turning `map` into a `build/foldr` form, which `map/coerce` does not recognize. 2. Even if `map` gets written back, `coerce` has been expanded into something the rule doesn't recognize. So we end up with something that looks like {{{#!hs myPotato = \ (@ a_are) (@ b_arf) ($dCoercible_arz :: Coercible a_are b_arf) (lst_aqx :: [a_are]) -> map @ a_are @ b_arf (\ (tpl_B2 [OS=ProbOneShot] :: a_are) -> case $dCoercible_arz of _ [Occ=Dead] { GHC.Types.MkCoercible tpl1_B3 -> tpl_B2 `cast` (tpl1_B3 :: a_are ~R# b_arf) }) lst_aqx }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9792> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #9496: Simplify primitives for short cut fusion
by GHC 12 Nov '14

12 Nov '14

#9496: Simplify primitives for short cut fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.3 Keywords: fusion | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Other Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Currently, there appear to be two production primitives, `build` and `augment` (although I may have missed some). There are multiple consumption primitives (at least: `foldr`, `head`, `and`, `or`, `any`, and `all`). The rule sets for some producers seem to forget to handle `augment`, and the `augment/augment` rule is omitted as "true, but not, I think, useful". A number of other functions are instead rewritten into `foldr` forms, and then written back if they don't fuse. == What to do: == Personally, I'd be very tempted to start by saying `build g = augment g []` (or ''possibly'' even `build g = extend [] g []` if I can ever get that idea to work) and cut the problem in half. The main problem I see with this is if other people are importing `GHC.Exts` or `GHC.Base`, writing things with `build`, and expecting them to fuse. One way to deal with this, perhaps, is to hack a special rule into the RULES compiler to recognize `GHC.Base.build` on the LHS of RULES and replace it with the appropriate `augment` form, emitting a warning. Where to go after that: the question remains whether it's best in general to rewrite a form to `foldr` to make it fuse, or to fuse directly with `augment`. The answer presumably depends, at least in part, on whether there are additional `foldr`-based rules we may want to add that would take advantage of the effort put into the translation back from the `foldr` form. I would conjecture that most such rules we could want would go beyond what the RULES system actually can do. That said, if we can find a way to use `foldr` forms without the horrible pain of translating back from them, that would be a very good thing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9496> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4