April 2017 - ghc-tickets

[GHC] #13392: ghc --show-options lists flags twice
by GHC 17 Apr '17

17 Apr '17

#13392: ghc --show-options lists flags twice --------------------------------------+--------------------------------- Reporter: ThreeFx | Owner: (none) Type: bug | Status: new Priority: low | Milestone: ⊥ Component: Compiler | Version: 8.0.1 Keywords: newcomer | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- Running `ghc --show-options` with GHC version 8.0.1 returns the flags `-O` and `-W` twice. To check this, execute the following command in your shell: {{{ ghc --show-options | sort | uniq -d }}} At commit `669333d8afaf388a3ce4a56e383b24ea2bdea145` (GHC 8.1.20170304) only `-O` is duplicated. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13392> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #13504: registerTimeout can wait too little because it uses Doubles for times
by GHC 17 Apr '17

17 Apr '17

#13504: registerTimeout can wait too little because it uses Doubles for times -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.2 System | 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: -------------------------------------+------------------------------------- [https://github.com/ghc/ghc/blob/380b25ea4754c2aea683538ffdb179f8946219a0/li… registerTimeout] uses `getMonotonicTime :: IO Double` and thus goes a roundtrip to `Double` when it is perfectly possible to always work on integers instead (`getMonotonicTime` obtains integers and then converts it). This can result in functions like `timeout` to wait too little, as e.g. `timeout 4` is converted to `3.997420` seconds, which can violate standard expecations of programs that it will wait _at least_ as much as demanded. We should export and use the integer based function [https://github.com/ghc/ghc/blob/380b25ea4754c2aea683538ffdb179f8946219a0/li… GHC.getMonotonicNSec] that `getMonotonicTime` calls. Not going through Double will also make inspecting e.g. `strace` more obvious. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13504> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #4417: Quasiquoting without bloating
by GHC 17 Apr '17

17 Apr '17

#4417: Quasiquoting without bloating -------------------------------------+--------------------------------- Reporter: rrnewton | Owner: simonmar Type: feature request | Status: closed Priority: high | Milestone: 7.4.1 Component: Compiler | Version: 6.13 Resolution: fixed | Keywords: executable size Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+--------------------------------- Comment (by Sergei Trofimovich <slyfox@…>): In [changeset:"a92ff5d66182d992d02dfaad4c446ad074582368/ghc" a92ff5d6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a92ff5d66182d992d02dfaad4c446ad074582368" hs_add_root() RTS API removal Before ghc-7.2 hs_add_root() had to be used to initialize haskell modules when haskell was called from FFI. commit a52ff7619e8b7d74a9d933d922eeea49f580bca8 ("Change the way module initialisation is done (#3252, #4417)") removed needs for hs_add_root() and made function a no-op. For backward compatibility '__stginit_<module>' symbol was not removed. This change removes no-op hs_add_root() function and unused '__stginit_<module>' symbol from each haskell module. Signed-off-by: Sergei Trofimovich <slyfox(a)gentoo.org> Test Plan: ./validate Reviewers: simonmar, austin, bgamari, erikd Reviewed By: simonmar Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3460 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4417#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3252: having to call hs_add_root(__stginit_Foo) is a bit of a pain
by GHC 17 Apr '17

17 Apr '17

#3252: having to call hs_add_root(__stginit_Foo) is a bit of a pain -------------------------------------+--------------------------------- Reporter: duncan | Owner: simonmar Type: feature request | Status: closed Priority: high | Milestone: 7.2.1 Component: Compiler (FFI) | Version: 6.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: -------------------------------------+--------------------------------- Comment (by Sergei Trofimovich <slyfox@…>): In [changeset:"a92ff5d66182d992d02dfaad4c446ad074582368/ghc" a92ff5d6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a92ff5d66182d992d02dfaad4c446ad074582368" hs_add_root() RTS API removal Before ghc-7.2 hs_add_root() had to be used to initialize haskell modules when haskell was called from FFI. commit a52ff7619e8b7d74a9d933d922eeea49f580bca8 ("Change the way module initialisation is done (#3252, #4417)") removed needs for hs_add_root() and made function a no-op. For backward compatibility '__stginit_<module>' symbol was not removed. This change removes no-op hs_add_root() function and unused '__stginit_<module>' symbol from each haskell module. Signed-off-by: Sergei Trofimovich <slyfox(a)gentoo.org> Test Plan: ./validate Reviewers: simonmar, austin, bgamari, erikd Reviewed By: simonmar Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3460 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3252#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13580: TypeApplications: panic from unknown function identifier
by GHC 15 Apr '17

15 Apr '17

#13580: TypeApplications: panic from unknown function identifier --------------------------------------+--------------------------------- Reporter: j6carey | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- Using type application with an unknown function identifier causes ghci to panic: {{{ $ ghci GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Prelude> :set -XDataKinds Prelude> :set -XTypeApplications Prelude> foo @3 ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): initTc: unsolved constraints WC {wc_insol = [W] foo_a12q :: t_a12p[tau:1] (CHoleCan: foo) [W] foo_a12O :: t_a12N[tau:1] (CHoleCan: foo)} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Prelude> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13580> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #13574: crash when using template haskell and ghc-mod
by GHC 15 Apr '17

15 Apr '17

#13574: crash when using template haskell and ghc-mod --------------------------------------+--------------------------------- Reporter: quisquous | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: OpenBSD Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- GHC crashes whenever I try to use the ghc-mod tool with even a trivial Template Haskell project. I thought it might be ghc-mod's fault, but a ghc-mod maintainer looked at the info I collected about the bug and he says its a bug in GHC. Here's the discussion about the bug, with the relevant logs and troubleshooting so far: https://github.com/DanielG/ghc-mod/issues/880#issuecomment-293436359 Let me know if it would help to copy+paste that conversation here instead of just providing a link. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13574> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8426: one-shot compilation + TH doesn't see instances that is seen in batch mode
by GHC 15 Apr '17

15 Apr '17

#8426: one-shot compilation + TH doesn't see instances that is seen in batch mode ----------------------------------------------+---------------------------- Reporter: errge | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less than a day) | Type of failure: Other Blocked By: | Test Case: Related Tickets: #7867 | Blocking: ----------------------------------------------+---------------------------- Haskell prime and Haskell98 both states that instances are always seen if there is any chain of imports leading from the current module to the instance. http://darcs.haskell.org/haskell-prime-report/report/haskell-report- html/modules.html#import-instances The ghc manual contains a discussion why this specification is too performance heavy to näively implement and contains the definition of orphanness and an algorithm to reproduce the specification with better performance. http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/separate- compilation.html#orphan-modules Unfortunately this cleverness breaks template haskell. Namely, if: - `Class.hs` contains a class, - `NonOrphan.hs` contains a data that implements the class, - `Importer.hs` just imports `NonOrphan.hs`, - `Main.hs` imports `Importer.hs`, - `Main.hs` reifies the class; then: - one-shot compilation's reify doesn't see the instance, - batch compilation's reify sees the instance. This ambiguity is shown in the attached tgz. Furthermore if `NonOrphan.hs` is in a separate package, then of course even batch compilation mode wouldn't reify the instance correctly. In that case there is no disambiguity between one-shot and batch, simply both is missing the info. I propose to solve this by enforcing a loading of all the interface files for every import transitively for the current module, when we meet an open type family or class reification request in template haskell's reify handler in `TcSplice.hs`. So I propose to keep the optimization of orphan instances and use it 99.9% of the time. We would only ever go on the quest of reading interface files for every import transitively when the user tries to reify something where we have to return an instance list. This means that TH compilations that reify types will get a little bit slower in exchange of being correct and unambiguous. Compilation time in cases when TH reification is not used will not change. I volunteer to prepare the patch, but would like to hear others first. So, any opinions, alternative ideas? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8426> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #13482: PartialTypeSignatures, AllowAmbiguousTypes and ScopedTypeVariables don't play nicely together
by GHC 14 Apr '17

14 Apr '17

#13482: PartialTypeSignatures, AllowAmbiguousTypes and ScopedTypeVariables don't play nicely together -------------------------------------+------------------------------------- Reporter: dramforever | Owner: (none) Type: bug | Status: new 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: -------------------------------------+------------------------------------- **Motivation**: I was playing with [http://lpaste.net/353915 something like this] when I found this great confusion. I was able to produce a minimal example. In each declaration/definition, the function body is the same, but the signature varies. I expect every single one of them to compile, resulting in the same type as `minimal4`. The actual results are shown in-line. I think this sufficiently shows that this behavior is a bug. (The line numbers in the following code aren't useful; I pasted them in after compiling) (The question marks are there because CMD wasn't able to display bullets, I think.) {{{#!hs {-# LANGUAGE PartialTypeSignatures #-} {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE KindSignatures #-} minimal1_noksig :: forall m. _ => Bool minimal1_noksig = (mempty :: m) == (mempty :: m) {- ambi.hs:17:30: error: ? Expected a type, but ‘m’ has kind ‘k0’ ? In an expression type signature: m In the first argument of ‘(==)’, namely ‘(mempty :: m)’ In the expression: (mempty :: m) == (mempty :: m) -} minimal1 :: forall (m :: *). _ => Bool minimal1 = (mempty :: m) == (mempty :: m) {- ambi.hs:11:1: error: ? Ambiguous type variable ‘m0’ prevents the constraint ‘(Monoid m0)’ from being solved. ? When checking that the inferred type minimal1 :: forall m. (Monoid m, Eq m) => Bool is as general as its (partial) signature minimal1 :: Bool -} minimal2 :: forall m. (Eq m, _) => Bool minimal2 = (mempty :: m) == (mempty :: m) {- ambi.hs:14:1: error: ? Could not deduce (Monoid m1) from the context: (Eq m, Monoid m) bound by the inferred type for ‘minimal2’: (Eq m, Monoid m) => Bool at ambi.hs:14:1-33 The type variable ‘m1’ is ambiguous ? When checking that the inferred type minimal2 :: forall m. (Monoid m, Eq m) => Bool is as general as its (partial) signature minimal2 :: forall m. (Eq m, Monoid m) => Bool -} minimal3 :: forall m. (Monoid m, _) => Bool minimal3 = (mempty :: m) == (mempty :: m) -- Compiles minimal4 :: forall m. (Monoid m, Eq m) => Bool minimal4 = (mempty :: m) == (mempty :: m) -- Compiles }}} The code was run in GHCi. GHC version is 8.0.2. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13482> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13566: Bigger core size in ghc8 compared to ghc7
by GHC 13 Apr '17

13 Apr '17

#13566: Bigger core size in ghc8 compared to ghc7 -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Keywords: | 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: -------------------------------------+------------------------------------- Generated core size (as reported by ghc -v) is much bigger in ghc 8.0.2 compared to ghc 7.10.1. Things are slightly better in ghc 8.2.0rc2, but not as good as in ghc7 I think that results in a slight runtime performance problem. steps to reproduce: ghc -O A.hs {{{ Result size of CorePrep = {terms: 5,016, types: 9,813, coercions: 1,443} -- ghc8 Result size of CorePrep = {terms: 975, types: 2,375, coercions: 150} -- ghc7 Result size of CorePrep = {terms: 1,342, types: 2,838, coercions: 320, joins: 0/66} -- ghc8.2 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13566> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #10800: vector-0.11
by GHC 13 Apr '17

13 Apr '17

#10800: vector-0.11 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- vector-0.11 takes substantially longer to compile with 7.10 than 7.8 Unfortunately the issue appears to be in generated code. Lacking time right now so I'm just going to drop the IRC log here, Compile log: https://travis-ci.org/haskell/vector/builds/56179052 {{{ * hvr thought some compile-time improvements landed in 7.10.2 <dolio> I don't think it uses sufficiently less memory to prevent it from using all memory on travis and failing. <dolio> Which is why it suddenly went from 8 minutes to 35. <dolio> Although it's also significantly worse even when you have enough memory. <dolio> hvr: 7.8.4 takes 4m40s, 7.10.2 takes 16m40s. <dolio> i7 4770, 32GB RAM. <dolio> vector 0.11 branch. <dolio> It's not as bad in the 0.10 branch. <dolio> It uses like 60% more memory, too. <dolio> Maybe more. <dolio> It's really just one or two files in the test suite that take all the time/memory. <hvr> dolio: does vector do some aggressive INLINEing? <dolio> Well, yes. <hvr> more in 0.11 than in 0.10? <dolio> It does more stuff in 0.11, yes. <bgamari> vector 0.11 has this new chunked streaming abstraction IIRC <hvr> there's a generic one though iirc <dolio> 0.11 introduced the generalized stream fusion, so there's like three different things going on that specialization has to select one of. <dolio> Instead of just one thing like in 0.10. <dolio> Anyhow, the problem file(s) generate a bunch of tests using template Haskell, so they're pretty opaque. <dolio> I'm pretty sure it's the generated code that's the problem, though. <dolio> Not the template haskell that generates it. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10800> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22