April 2017 - ghc-tickets

Re: [GHC] #4960: Better inlining test in CoreUnfold
by GHC 07 Apr '17

07 Apr '17

#4960: Better inlining test in CoreUnfold -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.0.1 Resolution: | Keywords: newcomer, | Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bredelings): * cc: bredelings (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4960#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals
by GHC 07 Apr '17

07 Apr '17

#5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > If i remember correctly, a `ByteArray#` would have an extra header and a length field, which in turn bring a 2 words overhead, one word more compareing to the `(# int#, addr# #)` solution. Right, this would incur another word of overhead. However, on the majority of machines this is 8-bytes which is quite significant. Looking at GHC itself, just over a third of all string literals are 8 characters or less (6000 our of 17500). For these literals adding another word would increase the fractional overhead from >50% to >67%. I have spoken with GHC users targeting mobile platforms who already suffer from our code size; it's hard to justify such an increase without a very good reason. > But i would argue this overhead can bring a nice solution to ghc's long lasting literal problem, for example, vector package and text package can provide some TH to directly save some byteArray# literal using hexadecimal notation, this save many extra copying during runtime. What is stopping these libraries from providing this mechanism currently using `Addr#` and primitive strings directly? In general primitive strings are, as the name would suggest, primitive. I'm not sure forcing a heap object representation here is necessary nor prudent. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:59> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13539: Options -pgmlclang and -pgmlc overlap
by GHC 07 Apr '17

07 Apr '17

#13539: Options -pgmlclang and -pgmlc overlap -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I tried to tell GHC to use `clang` with `-pgmlclang`, and only after some time found out that it won't work, because GHC interprets that as `-pgmlc` `lang` (surprise, `-pgmlc` is also an option). The user manual suggests that `pgmc<value>` (without space) is the recommended syntax. If spaces are in fact allowed, we should change the manual. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13539> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13505: Write the name of the people of the Haskell Committee into the GHC compiler
by GHC 06 Apr '17

06 Apr '17

#13505: Write the name of the people of the Haskell Committee into the GHC compiler -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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: -------------------------------------+------------------------------------- Hi,\\ Write the name of the people in the Haskell report file is good.\\ I propose to write also the names in the compiler.\\\\ The names would be accessible, for instance, by the following commands:\\ with GHC in a command line: {{{ghc -- Committee}}}\\ with GHCi: {{{: Committee}}}\\\\ For instance, in the Haskell 2010 Language Report, the Haskell Committee is not up-to-date. In the last release of GHC, 8.0.2, it would have been the current Committee with the former.\\ What do you all think?\\ -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13505> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10053: problem in ghci calling main after loading compiled code
by GHC 06 Apr '17

06 Apr '17

#10053: problem in ghci calling main after loading compiled code -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1-rc2 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- ghci GHCi, version 7.10.0.20150123: http://www.haskell.org/ghc/ :? for help Prelude> :load rsa Ok, modules loaded: Main. Prelude Main> :show modules Main ( rsa.hs, rsa.o ) Prelude Main> main Too late for parseStaticFlags: call it before runGhc or runGhcT *** Exception: ExitFailure 1 Prelude Main> note, there is no failure if I load interpreted code -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10053> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 26

Re: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals
by GHC 06 Apr '17

06 Apr '17

#5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 Wiki Page: | -------------------------------------+------------------------------------- Comment (by winter): If i remember correctly, a `ByteArray#` would have an extra header and a length field, which in turn bring a 2 words overhead, one word more compareing to the `(# int#, addr# #)` solution. But i would argue this overhead can bring a nice solution to ghc's long lasting literal problem, for example, `vector` package and `text` package can provide some TH to directly save some `byteArray#` literal using hexadecimal notation, this save many extra copying during runtime. Finally, by nature of binary loading, this `ByteArray#` is pinned, so we can still get its address without trouble. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:58> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13000: minor doc bug about list fusion in GHC user's guide
by GHC 06 Apr '17

06 Apr '17

#13000: minor doc bug about list fusion in GHC user's guide -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Documentation | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- First, the Users Guide (8.0.1.20161117) in section 10.32.6,List fusion, should mention length as a good consumer. Secondly, it says: "If you want to write your own good consumers or producers, look at the Prelude definitions of the above functions to see how to do so." However if you go to https://hackage.haskell.org/package/base-4.9.0.0/docs/Prelude.html and look at the source code for length you end up at https://hackage.haskell.org/package/base-4.9.0.0/docs/src/Data.Foldable.htm… which is not a good consumer. I think the User's Guide should be changed to replace "Prelude" with "https://hackage.haskell.org/package/base-4.9.0.0/docs/src/GHC.List.html". -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13000> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #4862: Enable usage of gold linker with GHC
by GHC 06 Apr '17

06 Apr '17

#4862: Enable usage of gold linker with GHC -------------------------------------+------------------------------------- Reporter: ajd | Owner: igloo Type: feature request | Status: closed Priority: normal | Milestone: 7.4.3 Component: Compiler | Version: 7.0.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): A summary of how to use gold for linking for those who are looking for instructions [http://stackoverflow.com/questions/43243322/how-to-link- with-the-gnu-gold-linker-instead-of-ld-in-haskell/ can be found here.] It is much faster. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4862#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6063: GHC's build-time ld-flag checks are problematic
by GHC 06 Apr '17

06 Apr '17

#6063: GHC's build-time ld-flag checks are problematic -------------------------------------+------------------------------------- Reporter: parcs | Owner: thoughtpolice Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: Type of failure: GHC doesn't work | Unknown/Multiple at all | Test Case: Blocked By: | Blocking: Related Tickets: #4862 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): A summary of how to use gold for linking for those who are looking for instructions [http://stackoverflow.com/questions/43243322/how-to-link- with-the-gnu-gold-linker-instead-of-ld-in-haskell/ can be found here.] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6063#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13533: -ddump-warnings
by GHC 06 Apr '17

06 Apr '17

#13533: -ddump-warnings -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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: -------------------------------------+------------------------------------- It would be useful to have a way to dump the warnings from a compilation to a file, and seemingly the most natural way to do that would be to extend with {{{-ddump-warnings}}}. The use case is that developers often want to develop and debug without worrying so much about warnings, but should almost always resolve the warnings before committing. If you build with {{{-Werror}}} that impedes development. If you don't build with {{{-Werror}}} then you may check in code that later fails continuous integration tests, or have to do a clean build to get the warnings out. An alternative workflow would be to always dump warnings to a file, then before commit have a script to quickly check if any of the files are non-empty. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13533> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0