September 2014 - ghc-tickets

[GHC] #9350: Consider using xchg instead of mfence for CS stores
by GHC 14 Nov '14

14 Nov '14

#9350: Consider using xchg instead of mfence for CS stores -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 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: -------------------------------------+------------------------------------- To get sequential consistency for `atomicWriteIntArray#` we use an `mfence` instruction. An alternative is to use an `xchg` instruction (which has an implicit `lock` prefix), which might have lower latency. We should check what other compilers do. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9350> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8750: Invalid identifier generated with Template Haskell not rejected
by GHC 13 Nov '14

13 Nov '14

#8750: Invalid identifier generated with Template Haskell not rejected --------------------------+------------------------------------------------ Reporter: | Owner: jstolarek | Status: new Type: bug | Milestone: Priority: normal | Version: 7.7 Component: | Operating System: Unknown/Multiple Template Haskell | Type of failure: GHC accepts invalid program Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ I wrote Template Haskell code that generates this declaration: {{{ data (:+Sym1) (a:: Nat) (b :: TyFun Nat Nat) }}} `(:+Sym1)` is not a valid identifier and this declaration fails when I simply put it in a source file and try to compile it. However I get no errors when this definition is generated from Template Haskell. Not sure if this is intended behaviour or not. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8750> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[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 12 Nov '14

12 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] #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

[GHC] #9594: Cleanup of filepath package
by GHC 11 Nov '14

11 Nov '14

#9594: Cleanup of filepath package -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 7.9 Keywords: filepath | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: #8752 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I did a general cleanup/refactoring of the filepath package. Notable changes: * 10% less code * 2 tiny bug fixes * a few extra tests * some more documentation The commits are in my [https://github.com/thomie/filepath/commits/cleanup cleanup branch] on Github. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9594> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9621: New Data.Foldable methods
by GHC 11 Nov '14

11 Nov '14

#9621: New Data.Foldable methods -------------------------------------+------------------------------------- Reporter: hvr | Owner: ekmett Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: #9586 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- place-holder text; details to follow soon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9621> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9077: Forcing the type to be IO {} instead of IO() causes a "panic! The impossible has happened" output.
by GHC 11 Nov '14

11 Nov '14

#9077: Forcing the type to be IO {} instead of IO() causes a "panic! The impossible has happened" output. -------------------------+------------------------------------------------- Reporter: | Owner: Westycoot | Status: new Type: bug | Milestone: Priority: | Version: 7.8.2 normal | Operating System: Unknown/Multiple Component: | Type of failure: Compile-time performance bug Compiler | Test Case: Keywords: | Blocking: Architecture: x86 | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- Below is the source code in which the bug occurs. It is easily reproduce- able, by having the type be IO{} instead of IO(). When ran, this code will produce the "panic! The impossible has happened" output. Which told me to report the bug here. By changing IO() to IO{} (which I did by accident), no exception is thrown, it simply tells the user to panic! {{{ main :: IO {} main = do e1 <- getLine e2 <- getLine print ((read e1) + (read e2)) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9077> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4