October 2015 - ghc-tickets

[GHC] #10734: pprint of ‘let’ inside ‘do’ prints invalid Haskell
by GHC 10 Feb '16

10 Feb '16

#10734: pprint of ‘let’ inside ‘do’ prints invalid Haskell -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.10.2 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- On GHC 7.10.1 {{{#!hs Prelude Language.Haskell.TH Language.Haskell.TH.Ppr> pprint <$> runQ [| do { let { x = 5 }; return x; } |] "do {let x_0 = 5; GHC.Base.return x_0}" }}} The let binding inside the resulting {{{do}}} should be inside curly braces too -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10734> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10022: Clean up GHC.RTS.Flags
by GHC 09 Feb '16

09 Feb '16

#10022: Clean up GHC.RTS.Flags -------------------------------------+------------------------------------- Reporter: | Owner: thoughtpolice | Status: new Type: bug | Milestone: 7.12.1 Priority: normal | Version: 7.10.1-rc1 Component: | Operating System: Unknown/Multiple libraries/base | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: #9970 Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- There's some cleanup to do for `GHC.RTS.Flags`, based on the comments in https://ghc.haskell.org/trac/ghc/ticket/5364#comment:11 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10022> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8136: arr020 test fails randomly with ghci way
by GHC 07 Feb '16

07 Feb '16

#8136: arr020 test fails randomly with ghci way -----------------------------+---------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.7 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -----------------------------+---------------------------------- I noticed that when I run arr020 (`make TEST=arr020`) it randomly segfaults when running `ghci` way. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8136> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8265: getTokenStream fails for source using cpp
by GHC 07 Feb '16

07 Feb '16

#8265: getTokenStream fails for source using cpp -----------------------------------+--------------------------------------- Reporter: alanz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- Calling getTokenStream (or getRichTokenStream) on a module that has CPP directives fails as the lexer is given un-preprocessed source -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8265> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10862: No way to exclude current directory from search path
by GHC 07 Feb '16

07 Feb '16

#10862: No way to exclude current directory from search path -------------------------------------+------------------------------------- Reporter: literon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Having Main.hs in the current directory, executing ghc --make Main -i still compiles the module, even though -i should in theory "reset the search path back to nothing". But it seems nothing ~ the default (current dir). I would propose to either change the behavior, or add a new flag, in order to be able to better control the build environment. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10862> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10898: GHCI crash
by GHC 07 Feb '16

07 Feb '16

#10898: GHCI crash ---------------------------------+------------------------------- Reporter: trebor | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ---------------------------------+------------------------------- robert@HeisenbergJr:~$ ghci GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for i386-unknown-linux): interactiveUI:setBuffering2 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10898> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8842: Make sure msys2 builds non emulating binaries
by GHC 06 Feb '16

06 Feb '16

#8842: Make sure msys2 builds non emulating binaries ------------------------------------+--------------------------------- Reporter: schyler | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+--------------------------------- I came across this in my own project. MSys2 doesn't enter #ifdef blocks which test for _WIN32. Instead, it pretends to be Linux and has a set of headers which emulate things like mmap. These emulation functions are really really slow -- in my personal tests about 10x slower than calling the WINAPI -- so this ticket is just a reminder (it may already be done) for someone to check that MSys2 builds things non-emulated in GHC. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8842> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9686: Link option detection does not work for incremental builds on Windows
by GHC 06 Feb '16

06 Feb '16

#9686: Link option detection does not work for incremental builds on Windows -------------------------------------+------------------------------------- Reporter: gintas | Owner: gintas Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- ghc on Linux embeds link options into the resulting binary in order to be able to tell when a binary needs to be recompiled because different link options have been passed in to ghc. This functionality is not present on Windows, forcing users to pass in -fforce-recomp. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9686> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10289: compiling huge HashSet hogs memory
by GHC 05 Feb '16

05 Feb '16

#10289: compiling huge HashSet hogs memory -------------------------------------+------------------------------------- Reporter: zudov | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Compiling a huge (~2.5k elements) set with GHC-7.10.1 or GHC-head and unordered-containers-0.2.5.1 or unordered-containers-head takes way too much memory. Here is a [https://github.com/zudov/html5-entity/blob/unordered- containers/src/Text/Html/Entity/Data/EntitySet.hs file] which I am trying to compile. I've also set up a [https://travis- ci.org/zudov/html5-entity/builds/58063328 travis build] which demonstrates the behaviour with different versions of GHC and unordered-containers. Further I would be referring to [https://travis- ci.org/zudov/html5-entity/jobs/58063332 this build-job] which uses GHC-7.10.1 and unordered-containers-0.2.5.1. * [https://travis-ci.org/zudov/html5-entity/jobs/58063332#L397 Compilation] with default optimization options takes around [https ://travis-ci.org/zudov/html5-entity/jobs/58063332#L408 12GB] of memory. * [https://travis-ci.org/zudov/html5-entity/jobs/58063332#L367 Compilation] with `-O0` takes around [https://travis- ci.org/zudov/html5-entity/jobs/58063332#L378 400MB]. * [https://travis-ci.org/zudov/html5-entity/jobs/58063332#L457 Compilation] with `-O2` takes around [https://travis- ci.org/zudov/html5-entity/jobs/58063332#L468 12GB] of memory. * [https://travis-ci.org/zudov/html5-entity/jobs/58063332#L487 Compilation] with `-O2 -fignore-interface-pragmas` takes around [https ://travis-ci.org/zudov/html5-entity/jobs/58063332#L498 500MB] of memory, which solves the problem. When the build uses GHC-7.8.4, neither of this hogging [https://travis- ci.org/zudov/html5-entity/jobs/58063330 occurs]. Another interesting observation is that [https://travis- ci.org/zudov/html5-entity/jobs/58063330#L339 compiling] [https://github.com/zudov/html5-entity/blob/unordered- containers/src/Text/Html/Entity/Data/EntityMap.hs HashMap] of the same size, doesn't cause memory hogging even with `-O2`. This attracted my attention as `HashSet` is implemented in terms of `HashMap`. I reported the issue to `unordered-containers` as well: [https://github.com/tibbe/unordered-containers/issues/100 link]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10289> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #9638: Speed up Data.Char.isDigit
by GHC 05 Feb '16

05 Feb '16

#9638: Speed up Data.Char.isDigit -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: Runtime hour) | performance bug Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- `isDigit` is currently defined like this: {{{#!hs isDigit :: Char -> Bool isDigit c = c >= '0' && c <= '9' }}} This will short-circuit the right way if you're looking for digits mixed with spaces, but the wrong way if you're looking for digits mixed with letters. It also requires a conditional jump to do that short-circuiting (confirmed by inspecting the assembly). It should be better to use an unsigned comparison instead: {{{#!hs isDigit :: Char -> Bool isDigit c = (fromIntegral (ord c) :: Word) - 48 <= 9 }}} The interesting section looks like this {{{ movq 7(%rbx),%rax addq $-48,%rax cmpq $9,%rax setbe %al movzbl %al,%eax shlq $3,%rax movq ghczmprim_GHCziTypes_Bool_closure_tbl(%rax),%rbx addq $8,%rbp jmp *(%rbp) }}} or like this with -fllvm: {{{ movq 7(%rbx), %rax addq $-48, %rax cmpq $10, %rax sbbq %rax, %rax andq $8, %rax movq ghczmprim_GHCziTypes_Bool_closure_tbl(%rax), %rbx movq 8(%rbp), %rax addq $8, %rbp jmpq *%rax # TAILCALL }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9638> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10