- ghc-tickets - Haskell.org

Re: [GHC] #5001: makeCorePair: arity missing
by GHC 30 Jul '15

30 Jul '15

#5001: makeCorePair: arity missing -------------------------------------+------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: high | Milestone: 7.4.1 Component: Compiler | Version: 7.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | deSugar/should_compile/T5001 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones <simonpj@…>): In [changeset:"72d23c3e0244b1163d7806e40128ad51cc959f7f/ghc" 72d23c3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="72d23c3e0244b1163d7806e40128ad51cc959f7f" Better treatment of signatures in cls/inst The provoking cause for this patch is Trac #5001, comment:23. There was an INLINE pragma in an instance decl, that shouldn't be there. But there was no complaint, just a mysterious WARN later. I ended up having to do some real refactoring but the result is, I think, simpler and more robust. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5001#comment:24> 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 30 Jul '15

30 Jul '15

#5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: | thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 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 Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): Well, any way to include a literal bytestring would help in avoiding the runtime cost. If the setup is only for `Text.ByteString`, there might be some dark coercing magic required to make that a vector while still pointing at the same `Addr#`, but it should work. I currently have a template-haskell based solution in [my repository](https://github.com/entropia/tip-toi- reveng/blob/master/src/BakedVector.hs) which allows me to write [this code](https://github.com/entropia/tip-toi- reveng/blob/master/src/KnownCodes.hs), which works fine for me. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:33> 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 30 Jul '15

30 Jul '15

#5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: | thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 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 Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): nomeata, I'm not sure I see how your problem would be treated by the proposal 2 described in comment:3. Perhaps I am missing something or are you thinking of another approach entirely? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:32> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #10694: CPR analysis too optimistic when returning a component of a product
by GHC 30 Jul '15

30 Jul '15

#10694: CPR analysis too optimistic when returning a component of a product -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | stranal/should_compile/T10694 Blocked By: | Blocking: 10678 Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => stranal/should_compile/T10694 * resolution: => fixed Comment: I think I've fixed this. Thanks for identifying it so clearly. I hope this unblocks your `runST` work. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10694#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #10694: CPR analysis too optimistic when returning a component of a product
by GHC 30 Jul '15

30 Jul '15

#10694: CPR analysis too optimistic when returning a component of a product -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 10678 Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones <simonpj@…>): In [changeset:"499b926be70b06e2e97b234cdb39cac94dd249e0/ghc" 499b926/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="499b926be70b06e2e97b234cdb39cac94dd249e0" Fix Trac #10694: CPR analysis In this commit commit 0696fc6d4de28cb589f6c751b8491911a5baf774 Author: Simon Peyton Jones <simonpj(a)microsoft.com> Date: Fri Jun 26 11:40:01 2015 +0100 I made an error in the is_var_scrut tests in extendEnvForProdAlt. This patch fixes it, thereby fixing Trac #10694. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10694#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10629: threadWaitRead throws BlockedIndefinitelyOnMVar
by GHC 30 Jul '15

30 Jul '15

#10629: threadWaitRead throws BlockedIndefinitelyOnMVar -------------------------------------+------------------------------------- Reporter: | Owner: simonmar facundo.dominguez | Status: new Type: bug | Milestone: Priority: normal | Version: 7.10.1 Component: Runtime | Operating System: Linux System | Type of failure: Incorrect result Keywords: | at runtime concurrency sockets | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- In a project using the network-transport-tcp package, I'm observing {{{threadWaitRead}}} throw the exception {{{BlockedIndefinitelyOnMVar}}}. The call stack is roughly: {{{ ... n-t-tcp:Network.Transport.TCP.handleIncomingMessages n-t-tcp:Network.Transport.TCP.Internal.recvInt32 n-t-tcp:Network.Transport.TCP.Internal.recvExact network:Network.Socket.ByteString:recv network:Network.Socket.ByteString:recvInner network:Network.Socket.Internal:throwSocketErrorWaitRead base:Control.Concurrent:threadWaitRead }}} IIUC this would be an RTS bug. The socket file descriptor is healthy and works fine if the exception is caught and {{{threadWaitRead}}} is retried. Unfortunately, I can only reproduce this in a particular machine and with a rather complex test case. I'd appreciate any advice on inspecting the RTS code to scan for the cause of {{{BlockedIndefinitelyOnMVar}}} being thrown. Of course, if someone can help explaining this behavior I'll be most thankful. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10629> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] Batch modify:
by GHC 30 Jul '15

30 Jul '15

Batch modification to by hvr: milestone to 7.10.3 Comment: Ticket retargeted after milestone closed -- Tickets URL: <http://ghc.haskell.org/trac/ghc/query?id=> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10595: BuiltinRules override other rules in some cases.
by GHC 29 Jul '15

29 Jul '15

#10595: BuiltinRules override other rules in some cases. -------------------------------------+------------------------------------- Reporter: gjsimms | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- It seems that the Class op * rules will override a user defined rule for class functions. This seems to be a long outstanding issue: http://stackoverflow.com/questions/9811294/rewrite-rules-not-firing-for- rules-matching-multiple-instance-methods I also just ran into someone else on the haskell IRC channel who had an even simpler example then the one on that page: {{{#!hs {-# NOINLINE d #-} {-# RULES "d exp" d exp = exp #-} d :: (Double -> Double) -> (Double -> Double) d f = f . (+20.0) g :: Double -> Double g = (+5.0) main = do print $ d exp 1.0 -- FAIL should print 2.718281828459045 >> printed exp 21.0 instead print $ d g 3.0 -- PASS should print 28.0 -- Compiled with: -- ghc -fenable-rewrite-rules -O rules.hs }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10595> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #10685: ghci segfaults on Travis
by GHC 29 Jul '15

29 Jul '15

#10685: ghci segfaults on Travis -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: GHCi | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHCi crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Some 100 ghci tests are failing on Travis. I bisected it down to b949c96b4960168a3b399fe14485b24a2167b982 "Eliminate zero_static_objects_list()", Phab:D1076. Not that the Travis build sets `DYNAMIC_GHC_PROGRAMS = NO` and 'GhcLibWays = v`. Complete log: https://s3.amazonaws.com/archive.travis-ci.org/jobs/72543456/log.txt -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10685> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10699: Regression: panic with custom rewrite rules on primops
by GHC 29 Jul '15

29 Jul '15

#10699: Regression: panic with custom rewrite rules on primops -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #10555 Differential Revisions: | -------------------------------------+------------------------------------- The following program results in a panic with ghc-7.10.2 (and also HEAD with the patches for #10528 and #10595 applied), but not with ghc-7.10.1. {{{#!haskell {-# LANGUAGE MagicHash #-} module T10555b where import GHC.Prim {-# RULES "double commute left *" forall x1 x2 x3. (*##) x1 ((*##) x2 x3) = (*##) ((*##) x2 x3) x1 #-} {-# RULES "double **4" forall x . x **## 4.0## = let xx = x *## x in xx *## xx #-} }}} {{{ $ ghc-7.10.2 -fforce-recomp -O T10555b.hs ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): Simplifier ticks exhausted When trying RuleFired double commute left * To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 4004 }}} I find this suprising, because there isn't anything to rewrite yet, is there? These are the prerequisites to trigger the bug: * both rules are needed * the function (`*##`) should be a primop If I replace the function (`*##`) by `f` below, I don't get a panic, but I do get the following warning: {{{ RULE left-hand side too complicated to desugar Optimised lhs: case f x2 x3 of wild_00 { __DEFAULT -> f x1 wild_00 } Orig lhs: case f x2 x3 of wild_00 { __DEFAULT -> f x1 wild_00 } }}} {{{#!haskell {-# NOINLINE f #-} f :: Double# -> Double# -> Double# f = undefined }}} Note that the first rewrite rule (`"double commute left *"`) is buggy by itself, since it will loop on `times4` (with any compiler version): {{{#!haskell times4 :: Double -> Double times4 (D# x) = D# ((x *## x) *## (x *## x)) }}} So I'm not quite sure if there is a actually a bug in GHC here, but I don't understand what's going on either. These examples are extracted from the [https://hackage.haskell.org/package /fast-math fast-math] package. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10699> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1