May 2016 - ghc-tickets

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 19 May '16

19 May '16

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: 11362 | Blocking: Related Tickets: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, | Phab:D1268, Phab:D1360, Phab:D1373, Wiki Page: | Phab:D1396, Phab:D1457, Phab:D1468, DeterministicBuilds | Phab:D1487, Phab:D1504, Phab:D1508 -------------------------------------+------------------------------------- Comment (by Bartosz Nitka <niteria@…>): In [changeset:"6282bc31808e335cd8386dd20d469bc2457f84de/ghc" 6282bc31/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6282bc31808e335cd8386dd20d469bc2457f84de" Kill varSetElems in tidyFreeTyCoVars I haven't observed this to have an effect on nondeterminism, but tidyOccName appears to modify the TidyOccEnv in a way dependent on the order of inputs. It's easy enough to change it to be deterministic to be on the safe side. Test Plan: ./validate Reviewers: simonmar, austin, bgamari, simonpj Reviewed By: simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2238 GHC Trac Issues: #4012 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:173> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5556: Support pin-changing on ByteArray#s
by GHC 19 May '16

19 May '16

#5556: Support pin-changing on ByteArray#s -------------------------------------+------------------------------------- Reporter: pumpkin | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Mathnerd314): #12059 adds an `isPinnedByteArray#` primop, but there is still no zero- copy method of pinning / unpinning. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5556#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12063: Knot-tying failure when type-synonym refers to non-existent data
by GHC 19 May '16

19 May '16

#12063: Knot-tying failure when type-synonym refers to non-existent data -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: hs-boot | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider: {{{ -- A.hs-boot module A data T -- B.hs module B import {-# SOURCE #-} A type S = T -- A.hs module A import B x :: S }}} This will cause a tcIfaceGlobal panic when compiling `A.hs` in one-shot mode. The reason is that we will attempt to knot tie `B.hi`'s reference to `A:T` when typechecking the contents of `A.hs`, but unfortunately there is no declaration of `T` in the real `A.hs`, so the knot tying will fail. It's not entirely clear to me how to deal with this problem. The obvious thing to do is to fault in the `TyThing` from the ModDetails of the hs- boot file (great care must be taken because we don't actually want to load the hs-boot file!) We'll then fail in due course when we check if we actually implement everything the hs-boot file needs. But this could complicate things: 1. This "robustness" could mask another, much more difficult to diagnose bug when there was an actual knot-tying failure. Then, we will silently fail to tie the knot, and then if something bad happens it is a lot less obvious what went wrong. However! I think there is an ASSERT we can add in this case: when we add things to the type environment (and update the knot tying variable), we can check if we have faulted in the relevant entity from the hs-boot file. If we have, then we know there is knot-tying failure and we should fail. 2. Having two sets of `TyThing`s for the same `Name` could lead to hard to diagnose errors; e.g., you are comparing `S` for equality with `S`, but they return not equal because one of these is a type synonym tycon and the other is an abstract tycon. There might be some adjustments to the debug printing mechanism to make such situations more obvious. Here is another way to fix the bug: check if all the types declared in the hs-boot file are actually defined before doing any typechecking proper. Interestingly, this is a possible solution for #12034: the implication is that all types mentioned in the hs-boot file must be defined PRIOR to the first splice. If we look at #1012, this would not be a burden for users that use TH and hs-boot. Also, it nicely fits with a solution for #12042, since we need to check for type synonym loops at some point BEFORE typechecking, and this is the obvious place to do so. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12063> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #1262: RecursiveDo in Template Haskell
by GHC 18 May '16

18 May '16

#1262: RecursiveDo in Template Haskell -------------------------------------+------------------------------------- Reporter: philip.weaver@… | Owner: mgsloan Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Template Haskell | Version: 6.6 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | th/TH_recursiveDo Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1979 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * owner: => mgsloan * testcase: => th/TH_recursiveDo * differential: => Phab:D1979 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1262#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 18 May '16

18 May '16

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: 11362 | Blocking: Related Tickets: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, | Phab:D1268, Phab:D1360, Phab:D1373, Wiki Page: | Phab:D1396, Phab:D1457, Phab:D1468, DeterministicBuilds | Phab:D1487, Phab:D1504, Phab:D1508 -------------------------------------+------------------------------------- Comment (by Bartosz Nitka <niteria@…>): In [changeset:"fffe3a25adab41d44943ed1be0191cf570d3e154/ghc" fffe3a25/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="fffe3a25adab41d44943ed1be0191cf570d3e154" Make inert_model and inert_eqs deterministic sets The order inert_model and intert_eqs fold affects the order that the typechecker looks at things. I've been able to experimentally confirm that the order of equalities and the order of the model matter for determinism. This is just a straigthforward replacement of nondeterministic VarEnv for deterministic DVarEnv. Test Plan: ./validate Reviewers: simonpj, goldfire, austin, bgamari, simonmar Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2232 GHC Trac Issues: #4012 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:172> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5683: bug in signum function
by GHC 18 May '16

18 May '16

#5683: bug in signum function -------------------------------------+------------------------------------- Reporter: tristes_tigres | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.6.1 Component: Prelude | Version: 7.0.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): This was fixed in commit d9a20573f473cc7389004470999b8a318aa6b3f2: {{{ Author: Alexander Berntsen <alexander(a)plaimi.net> Date: Mon Aug 18 21:43:33 2014 -0500 Make Prelude.signum handle -0.0 correctly (#7858) Summary: Make the `Float` and `Double` implementations of `signum` handle -0.0 correctly per IEEE-754. This, together with "Make Prelude.abs handle -0.0 correctly (#7858)", fixes Trac #7858. Depends on D145 Signed-off-by: Alexander Berntsen <alexander(a)plaimi.net> Test Plan: signum of (-0.0) should be (-0.0) not 0.0. Test program: main = putStrLn $ p ++ " " ++ n where f = show . signum p = f (-0.0 :: Double) n = f (0.0 :: Double) Reviewers: ekmett, hvr, rwbarton, austin Reviewed By: austin Subscribers: phaskell, simonmar, relrod, ezyang, carter Differential Revision: https://phabricator.haskell.org/D148 GHC Trac Issues: #7858 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5683#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11761: autoconf 2.69 breaks configure
by GHC 18 May '16

18 May '16

#11761: autoconf 2.69 breaks configure -------------------------------------+------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- linux ppc64 buildbot reveals interesting issue which shows as following while running configure: {{{ ./configure: line 561: save_bash_input: buffer already exists for new fd 417 }}} it looks like this issue is presented in configure only when configure is generated by autoconf 2.69. On the same platform hand installed autoconf 2.68 produces working configure. I guess this is multi-platform so I do not mark platform here. Also as this is in 3th party package I'm reporting this just for the reference of known issue... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11761> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11749: Add long forms for -keep-* flags and possibly deprecate short forms
by GHC 18 May '16

18 May '16

#11749: Add long forms for -keep-* flags and possibly deprecate short forms -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 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: -------------------------------------+------------------------------------- The fact that GHC's `-keep-*` flags are short flags (e.g. begin with only one dash) is confusing and inconsistent with most of the rest of our flags, which use the typical gnu long form (with two dashes). I propose that we add `--keep-*` flags and consider deprecating the short forms at some point. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11749> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11738: A command to remove modules from the target list
by GHC 18 May '16

18 May '16

#11738: A command to remove modules from the target list -------------------------------------+------------------------------------- Reporter: jh3141 | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: GHCi | Version: 7.10.3 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: -------------------------------------+------------------------------------- Maybe it's because I'm a newbie, or possibly just because having the separate lists is a little confusing generally, but I quite often accidentally add a module to the target list (:a modulename) when I meant to add it to the current scope (:m +modulename). A way of *removing* the module after doing this would be useful, because it often results in errors when I use :reload. The following stack overflow question contains an answer with a suggested implementation, which could be useful: http://stackoverflow.com/questions/36139011/how-to-remove-module-from- target-list-in-ghci -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11738> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #11730: GHC panics ('unload: no interpreter") during T10052 test
by GHC 18 May '16

18 May '16

#11730: GHC panics ('unload: no interpreter") during T10052 test -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- T10052.hs currently results in a runtime panic on interpreter-less GHCs: {{{ =====> T10052(normal) 7 of 8 [0, 5, 0] cd ./T10052 && $MAKE -s --no-print-directory T10052 </dev/null > T10052.run.stdout 2> T10052.run.stderr Wrong exit code (expected 0 , actual 2 ) Stdout: Makefile:9: recipe for target 'T10052' failed Stderr: when making flags consistent: warning: -O conflicts with --interactive; -O ignored. T10052: T10052: panic! (the 'impossible' happened) (GHC version 8.1.20160320 for x86_64-unknown-linux): unload: no interpreter Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[1]: *** [T10052] Error 1 *** unexpected failure for T10052(normal) }}} I'm creating this ticket in order to reference this ticket via a `expect_broken()` annotation -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11730> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2