July 2015 - ghc-tickets

Re: [GHC] #7521: Accelerate examples does not compile with default value of -fsimpl-tick-factor
by GHC 08 Jul '15

08 Jul '15

#7521: Accelerate examples does not compile with default value of -fsimpl-tick- factor -------------------------------------+------------------------------------- Reporter: eamsden | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): Also #10491 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7521#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10585: Implement proper bidirectional type inference
by GHC 08 Jul '15

08 Jul '15

#10585: Implement proper bidirectional type inference -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 (Type checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The [http://research.microsoft.com/en-us/um/people/simonpj/papers/higher- rank/putting.pdf Practical Type Inference paper] (JFP '07) lays out a nice, relatively straightforward bidirectional type inference algorithm for GHC. The problem is that there is not great hygiene practiced around transitions between "down" checking and "up" checking, neither in the paper nor in the implementation. Examine Figure 8 of the paper, which presents the bidirectional typing rules. There are several syntactic forms which are fundamentally "up" forms -- forms that cannot gain any benefit from any type information being propagated downwards. Examples include App, Var, and Annot. Other forms propagate the very direction they are operated in, such as Let. And then some forms depend somewhat delicately on direction, such as the Abs rules. I propose changing these rules to be more in the style of Figure 4 from Dunfield & Krishnaswami's ICFP'13 paper [http://arxiv.org/pdf/1306.6032v1 here]. The particular rule I'm interested in is DeclSub, paraphrased here: {{{ G |-up e : s1 s1 <= s2 --------------- G |-down e : s2 }}} (I'm not advocating other aspects of their approach, just the general idea around this rule being the only transition between down and up.) In GHC, mediating between "down" checking and "up" checking is done in an ad-hoc manner, made even more difficult by the fact that it takes two separate steps to pull off properly: we must first `deeplyInstantiate` the "up" type that we get and then call `tcSubType` (or one of its variants). And, because this has to be done for each "up" expression form (forms that cannot use down-propagated type information), it's easy to miss a case. As a case in point, consider the following code: {{{ foo :: forall b. b -> (Int -> Int) -> b foo = undefined bar :: ((forall a. a -> a) -> Int) -> Int bar = undefined baz = bar (foo 3) bum = bar (3 `foo`) }}} In 7.10.1, `baz` is accepted, while `bum` is not. This is because the code for left-sections doesn't ever call `tcSubType` -- it uses `unifyType`. While that one case is easy enough to fix, I advocate a redesign of `tcExpr` to break it into two functions: one for "down" forms and one for "up" forms. These would, of course, be mutually recursive in order so that both can handle all expression forms. But these transitions could then be policed more easily. I don't actually think this would entail all that much work, and it would structurally remove the possibility of bugs such as the one above. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10585> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9665: Add "since" information to LANGUAGE extensions in GHC user guide
by GHC 07 Jul '15

07 Jul '15

#9665: Add "since" information to LANGUAGE extensions in GHC user guide -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: Type: task | Status: new Priority: high | Milestone: Component: Documentation | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- If one wants to support older versions of GHC, it is hard to find out whether one can use a certain LANGUAGE extension. One has to go to older versions of the GHC manual to find out whether the corresponding documentation was already there, or browse release notes. Requests: 1. Document for new LANGUAGE extensions that they are available since version 7.10. For example, by adding "(Since GHC 7.10)" to the heading of the new feature. 2. Do this also for the previous LANGUAGE extensions, by adding e.g., "(Since GHC 7.6)" etc. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9665> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #10557: Use `+RTS -G1` for more stable residency measurements
by GHC 07 Jul '15

07 Jul '15

#10557: Use `+RTS -G1` for more stable residency measurements -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Test Suite | 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: | -------------------------------------+------------------------------------- Tests that measure `peak_megabytes_allocated` and `max_bytes_used` can be very sensitive to small changes in, well, just about anything: order of command line flags, what should be irrelevant compiler patches, minor changes in the test file to compile. From `Note [residency]` in `testsuite/tests/perf/compiler/all.T`: {{{ # Residency (peak_megabytes_allocated and max_bytes_used) is sensitive # to when the major GC runs, which makes it inherently inaccurate. # Sometime an innocuous change somewhere can shift things around such # that the samples occur at a different time, and the residency # appears to change (up or down) when the underlying profile hasn't # really changed. }}} I propose setting `+RTS -G1` for these tests. This seems to make them more robust to small changes, as can be seen in the following two graphs, adapted from the test for #9675: https://ghc.haskell.org/trac/ghc/attachment/ticket/9675/T9675-peak_megabyte… https://ghc.haskell.org/trac/ghc/attachment/ticket/9675/T9675-max_bytes_use… This shows the `peak_megabytes_allocated` and `max_bytes_used` as a function of the number fields when compiling a single record: {{{ data Foo = Foo { field1 :: Int -> Int , field2 :: Int -> Int ... }}} The default `GHC -O` line is wiggling up and down, while the `GHC -O +RTS -G1` line is nice and smooth, which is what we want. I don't know if making this change defeats the purpose of some tests, which is why I'm opening this ticket. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10557> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10023: Relax Monad constraint in traceM and traceShowM to Applicative
by GHC 07 Jul '15

07 Jul '15

#10023: Relax Monad constraint in traceM and traceShowM to Applicative -------------------------------------+------------------------------------- Reporter: | Owner: RyanGlScott | Status: new Type: feature | Milestone: request | Version: 7.10.1-rc1 Priority: normal | Operating System: Unknown/Multiple Component: | Type of failure: Other libraries/base | Blocked By: Keywords: | Related Tickets: Architecture: | Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Now that {{{Applicative}}} is a superclass of {{{Monad}}} in GHC 7.10, the current type signatures of {{{traceM}}} and {{{traceShowM}}} from {{{Debug.Trace}}} are too constricted: {{{#!hs traceM :: Monad m => String -> m () traceM string = trace string $ return () traceShowM :: (Show a, Monad m) => a -> m () traceShowM = traceM . show }}} These can be equivalently defined with {{{Applicative}}}: {{{#!hs traceM :: Applicative m => String -> m () traceM string = trace string $ pure () traceShowM :: (Show a, Applicative m) => a -> m () traceShowM = traceM . show }}} However, the {{{M}}} suffixes probably won't make sense after changing the type signatures, so it might be wise to create new {{{traceA}}} and {{{traceShowA}}} functions and deprecate {{{traceM}}} and {{{traceShowM}}}. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10023> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #10439: Opt_ImplicitImportQualified doesn't work for constructor field name
by GHC 07 Jul '15

07 Jul '15

#10439: Opt_ImplicitImportQualified doesn't work for constructor field name -------------------------------------+------------------------------------- Reporter: watashi | Owner: watashi Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: x86 | Type of failure: GHC rejects Test Case: | valid program Blocking: | Blocked By: Differential Revisions: | Related Tickets: -------------------------------------+------------------------------------- {{{#!hs -- ghci -fimplicit-import-qualified Prelude> let tree = Data.Tree.Node 0 [] Prelude> Data.Tree.rootLabel tree 0 Prelude> let f i j = i { Data.Tree.rootLabel = j } <interactive>:4:17: ‘Data.Tree.rootLabel’ is not a (visible) constructor field name Prelude> import qualified Data.Tree Prelude Data.Tree> let f i j = i { Data.Tree.rootLabel = j } Prelude Data.Tree> f tree 1 Node {rootLabel = 1, subForest = []} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10439> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9863: Provide PowerPC 64 bit native code generator
by GHC 07 Jul '15

07 Jul '15

#9863: Provide PowerPC 64 bit native code generator -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: powerpc64 | Type of failure: Difficulty: Project (more | None/Unknown than a week) | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- I have started work on a native code generator for PowerPC 64 bit by extending the 32 bit code generator. The code is hosted on github: [https://github.com/trommler/ghc/tree/native] So far I plan to support the old ELF v1.9 ABI on big endian. I might look into little endian and ELF 2.0 later. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9863> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #10283: Make it possible to suppress warnings produced by -fdefer-type-errors
by GHC 07 Jul '15

07 Jul '15

#10283: Make it possible to suppress warnings produced by -fdefer-type-errors -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple (Type checker) | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- At the moment, there seems to be no way to suppress warnings generated by `-fdefer-type-errors` (even `-w` doesn't work). It would be nice to be able to silence them, preferably via a new flag `-fno-warn-deferred-type- errors`. The motivation for this comes from using `-fdefer-type-errors` to write tests that certain definitions do not typecheck (which is very useful, and is a cheaper alternative to writing code to invoke GHC on a source file and analyse its output). In this situation, it is annoying to see a large number of warnings when compiling the testsuite. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10283> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #10573: Generalize forever to Applicative
by GHC 07 Jul '15

07 Jul '15

#10573: Generalize forever to Applicative -------------------------------------+------------------------------------- Reporter: fumieval | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: | Operating System: Unknown/Multiple libraries/base | Type of failure: None/Unknown Keywords: AMP | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- This was proposed a month ago (https://mail.haskell.org/pipermail/libraries/2015-May/025711.html) and all the responses were positive. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10573> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #3: DiffArray should be instance of Show
by GHC 07 Jul '15

07 Jul '15

#3: DiffArray should be instance of Show --------------------------+-------------------- Reporter: magunter | Owner: nobody Type: bug | Status: closed Priority: normal | Milestone: Component: hslibs/lang | Version: 5.0 Resolution: Fixed | Keywords: --------------------------+-------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"5857e0afb5823987e84e6d3dd8d0b269b7546166/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5857e0afb5823987e84e6d3dd8d0b269b7546166" fix EBADF unqueueing in select backend (Trac #10590) Alexander found a interesting case: 1. We have a queue of two waiters in a blocked_queue 2. first file descriptor changes state to RUNNABLE, second changes to INVALID 3. awaitEvent function dequeued RUNNABLE thread to a run queue and attempted to dequeue INVALID descriptor to a run queue. Unqueueing INVALID fails thusly: #3 0x000000000045cf1c in barf (s=0x4c1cb0 "removeThreadFromDeQueue: not found") at rts/RtsMessages.c:42 #4 0x000000000046848b in removeThreadFromDeQueue (...) at rts/Threads.c:249 #5 0x000000000049a120 in removeFromQueues (...) at rts/RaiseAsync.c:719 #6 0x0000000000499502 in throwToSingleThreaded__ (...) at rts/RaiseAsync.c:67 #7 0x0000000000499555 in throwToSingleThreaded (..) at rts/RaiseAsync.c:75 #8 0x000000000047c27d in awaitEvent (wait=rtsFalse) at rts/posix/Select.c:415 The problem here is a throwToSingleThreaded function that tries to unqueue a TSO from blocked_queue, but awaitEvent function leaves blocked_queue in a inconsistent state while traverses over blocked_queue: case RTS_FD_IS_READY: IF_DEBUG(scheduler, debugBelch("Waking up blocked thread %lu\n", (unsigned long)tso->id)); tso->why_blocked = NotBlocked; tso->_link = END_TSO_QUEUE; // Here we break the queue head pushOnRunQueue(&MainCapability,tso); break; Signed-off-by: Sergei Trofimovich <siarheit(a)google.com> Test Plan: tested on a sample from T10590 Reviewers: austin, bgamari, simonmar Reviewed By: bgamari, simonmar Subscribers: qnikst, thomie, bgamari Differential Revision: https://phabricator.haskell.org/D1024 GHC Trac Issues: #10590, #4934 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0