March 2014 - ghc-tickets

[GHC] #8868: Old information in Extensions to data types and type synonyms
by GHC 11 Mar '14

11 Mar '14

#8868: Old information in Extensions to data types and type synonyms ------------------------------------+-------------------------------------- Reporter: Kinokkory | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Documentation bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+-------------------------------------- The Release notes for version 7.6.1 says http://www.haskell.org/ghc/docs/7.6.1/html/users_guide/release-7-6-1.html The behavior of the TypeOperator extension has changed: previously, only type operators starting with ":" were considered type constructors, and other operators were treated as type variables. Now type operators are always constructors. But this change isn't reflected in the User's Guide. http://www.haskell.org/ghc/docs/7.6.1/html/users_guide/data-type- extensions.html http://www.haskell.org/ghc/docs/7.6.2/html/users_guide/data-type- extensions.html http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/data-type- extensions.html A type variable can be an (unqualified) operator e.g. +. The lexical syntax is the same as that for variable operators, excluding "(.)", "(!)", and "(*)". In a binding position, the operator must be parenthesised. For example: ... I think this paragraph should be removed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8868> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #7143: ghc-7.6.0.20120810-x86_64-windows.exe -> ghc can't figure out LLVM version
by GHC 11 Mar '14

11 Mar '14

#7143: ghc-7.6.0.20120810-x86_64-windows.exe -> ghc can't figure out LLVM version -------------------------------------------------+------------------------- Reporter: cetinsert | Owner: Type: bug | dterei Priority: high | Status: new Component: Compiler (LLVM) | Milestone: 7.8.1 Resolution: | Version: Operating System: Windows | 7.6.1-rc1 Type of failure: Incorrect warning at | Keywords: llvm compile-time | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by is7s): Replying to [comment:11 schyler]: > Replying to [comment:10 carter]: > > schyler, could you confirm that editing the relevant fields in your GHC settings file fixes things > Confirming llvm 3.4svn and 2.9 on path work perfectly with the settings file fix. Where is the GHC settings file located on Windows? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7143#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5925: Add inline version of newArray#
by GHC 11 Mar '14

11 Mar '14

#5925: Add inline version of newArray# -------------------------------------+------------------------------------ Reporter: tibbe | Owner: simonmar Type: feature request | Status: patch Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 4258 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by tibbe): Could you please attach the first patch you used as well (i.e. run `git format-patch -n master..` and include all three patches). I no longer have the version of my patch that you based your work on and your patches don't apply cleanly on top of the `0001-codeGen-allocate-small-arrays-of- statically-known-si.patch` patch attached to this ticket. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5925#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5925: Add inline version of newArray#
by GHC 10 Mar '14

10 Mar '14

#5925: Add inline version of newArray# -------------------------------------+------------------------------------ Reporter: tibbe | Owner: simonmar Type: feature request | Status: patch Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 4258 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonmar): I've attached my refactored patches, there are two patches that apply on top of the original newArray# patch. The first is a patch I had lying around to change the representation of heap offsets from word to byte offsets, which turned out to be useful here too, so we might as well include it. I haven't tested this other than to eyeball the Cmm, which looks vaguely sensible. Johan, if you could take it from here and run your tests, that would be great. I think I'm still missing a bugfix that you applied in your second patch. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5925#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7994: Make foldl into a good consumer
by GHC 10 Mar '14

10 Mar '14

#7994: Make foldl into a good consumer -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Updated numbers, now running nofib in slow mode. Now the results look slightly better. Guess that is what benchmarking is about: Tweaking the tests until the results are what we want them to be: Effect of Call Arity (with the original foldl): {{{ min mean max Allocations -1.3% -0.0% 0.0% Runtime -4.0% -0.0% +4.9% }}} Effect of Call Arity + defining foldl with foldr: {{{ min mean max Allocations -79.0% -5.2% 0.0% Runtime -47.4% -1.9% +3.0% }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7994#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7994: Make foldl into a good consumer
by GHC 10 Mar '14

10 Mar '14

#7994: Make foldl into a good consumer -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): JFTR: I’m currently working on a presentation and short paper on this, and did some measurements, and found that while making `foldl` a good consumer has a nice effect on allocations (`-4.1%`, the overall effect on the runtime is negligible). Effect of Call Arity (with the original foldl): {{{ min mean max Allocations -1.3% -0.1% 0.0% Runtime -10.8% -0.9% +2.0% }}} Effect of Call Arity + defining foldl with foldr: {{{ min mean max Allocations -74.5% -4.1% 0.0% Runtime -10.4% -0.9% +1.7% }}} (Wishful thinking: Maybe there are real-world programs that would benefit more noticeably, but they are just not included in nofib) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7994#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8766: length [Integer] is twice as slow but length [Int] is 10 times faster
by GHC 10 Mar '14

10 Mar '14

#8766: length [Integer] is twice as slow but length [Int] is 10 times faster ------------------------------+-------------------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- Compared to 7.6.3 length in 7.8.1-rc1 has a performance regression: {{{ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.20140130 bash-3.2$ ghc -O2 LengthIntegerList.hs [1 of 1] Compiling Main ( LengthIntegerList.hs, LengthIntegerList.o ) Linking LengthIntegerList ... bash-3.2$ time ./LengthIntegerList 1073741824 real 0m45.344s user 0m44.230s sys 0m0.494s bash-3.2$ /usr/bin/ghc --version The Glorious Glasgow Haskell Compilation System, version 7.6.3 bash-3.2$ /usr/bin/ghc -O2 LengthIntegerList.hs [1 of 1] Compiling Main ( LengthIntegerList.hs, LengthIntegerList.o ) Linking LengthIntegerList ... bash-3.2$ time ./LengthIntegerList 1073741824 real 0m22.769s user 0m22.042s sys 0m0.385s bash-3.2$ cat LengthIntegerList.hs {-# OPTIONS_GHC -Wall #-} module Main where main :: IO() main = print $ length [1..(2^(30::Int)::Integer)] }}} thus length of [Integer] is twice as slow in rc1 but length of [Int] is 10 times faster: {{{ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.20140130 bash-3.2$ ghc -O2 LengthIntList.hs [1 of 1] Compiling Main ( LengthIntList.hs, LengthIntList.o ) Linking LengthIntList ... bash-3.2$ time ./LengthIntList 1073741824 real 0m0.723s user 0m0.693s sys 0m0.003s bash-3.2$ /usr/bin/ghc --version The Glorious Glasgow Haskell Compilation System, version 7.6.3 bash-3.2$ /usr/bin/ghc -O2 LengthIntList.hs [1 of 1] Compiling Main ( LengthIntList.hs, LengthIntList.o ) Linking LengthIntList ... bash-3.2$ time ./LengthIntList 1073741824 real 0m11.805s user 0m10.900s sys 0m0.351s bash-3.2$ cat LengthIntList.hs {-# OPTIONS_GHC -Wall #-} module Main where main :: IO() main = print $ length [1..(2^(30::Int)::Int)] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8766> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #8869: External preprocessor not used after TH name quote
by GHC 09 Mar '14

09 Mar '14

#8869: External preprocessor not used after TH name quote ----------------------------------+-------------------------- Reporter: myrix | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+-------------------------- Module {{{ {-# LANGUAGE CPP, TemplateHaskell #-} module Main where main = do putStrLn $ show 'id putStrLn __FILE__ }}} fails to compile with external preprocessor: {{{ > ghc -pgmP cpphs -optP --cpp Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Main.hs:7:12: Not in scope: `__FILE__' }}} {{{__FILE__}}} is not expanded: {{{ > ghc -E -pgmP cpphs -optP --cpp Main.hs > cat Main.hspp {-# LINE 1 "Main.hs" #-} #line 1 "Main.hs" {-# LANGUAGE CPP, TemplateHaskell #-} module Main where main = do putStrLn $ show 'id putStrLn __FILE__ }}} Without external preprocessor (just {{{ghc Main.hs}}}) module compiles successfully. Move name quote after {{{__FILE__}}}, like this: {{{ {-# LANGUAGE CPP, TemplateHaskell #-} module Main where main = do putStrLn __FILE__ putStrLn $ show 'id }}} and it work with external preprocessor just fine: {{{ > ghc -pgmP cpphs -optP --cpp Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... > ./Main Main.hs GHC.Base.id }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8869> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #5925: Add inline version of newArray#
by GHC 09 Mar '14

09 Mar '14

#5925: Add inline version of newArray# -------------------------------------+------------------------------------ Reporter: tibbe | Owner: simonmar Type: feature request | Status: patch Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 4258 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by tibbe): Replying to [comment:21 simonmar]: > Thanks, I started refactoring this yesterday. I want to move the knowledge about the array layout into `SMRep` (where the other heap- representation stuff is) as well as sharing the heap allocation code. Great. If you refactor the code I wrote, make sure you get the latest patch as I fixed some bugs. The `newArray#` code now validates (haven't validated the `newByteArray#` version yet). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5925#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5925: Add inline version of newArray#
by GHC 09 Mar '14

09 Mar '14

#5925: Add inline version of newArray# -------------------------------------+------------------------------------ Reporter: tibbe | Owner: simonmar Type: feature request | Status: patch Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 4258 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonmar): Thanks, I started refactoring this yesterday. I want to move the knowledge about the array layout into `SMRep` (where the other heap- representation stuff is) as well as sharing the heap allocation code. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5925#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0