April 2017 - ghc-tickets

[GHC] #13552: Enum Float/Double does not match Haskell Report
by GHC 10 Apr '17

10 Apr '17

#13552: Enum Float/Double does not match Haskell Report -------------------------------------+------------------------------------- Reporter: Luke | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.0.1 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Section 6.3.4 of the report says that the `Enum` instance for `Float` and `Double` should define the `enumFromThen*` functions such that `enumFromThen e1 e2` is the list `[e1, e1 + i, e1 + 2i, ...]` where `i = e2 - e1`. The actual implementation in base is that of successive additions (which is approximately the same thing for some types). Successive additions causes issues with floating point rounding. Changing the definition to something like {{{#!hs enumFromThen_ e1 e2 = let i = e2 - e1 in map (\n -> e1 + n * i) [0..] }}} significantly improves the accuracy of floating point ranges, as well as **matching what the report says**. {{{ Prelude> last $ take 101 $ [0,0.1..] :: Float 10.000028 Prelude> last $ take 101 $ enumFromThen_ 0 0.1 :: Float 10.0 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13552> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #4154: Deadlock in Chan module
by GHC 10 Apr '17

10 Apr '17

#4154: Deadlock in Chan module -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.4.1 Component: libraries/base | Version: 6.12.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 7.0.1 => 8.4.1 Old description: > The following program: > > {{{ > module Main where > > import Control.Concurrent > > main :: IO () > main = do > todo <- newChan > forkIO $ readChan todo > putStrLn "Before isEmptyChan" > b <- isEmptyChan todo > putStrLn "After isEmptyChan" > writeChan todo () > }}} > > Gives the output: > > {{{ > $ ghc --make Main.hs -threaded && ./Main.exe > Before isEmptyChan > Main.exe: thread blocked indefinitely in an MVar operation > }}} > > I think that's a bug. Note that if the {{{putStrLn}}} statements are > removed then it works, but I think that's because the printing introduces > a delay that lets the other thread run. New description: The following program: {{{#!hs module Main where import Control.Concurrent main :: IO () main = do todo <- newChan forkIO $ readChan todo putStrLn "Before isEmptyChan" b <- isEmptyChan todo putStrLn "After isEmptyChan" writeChan todo () }}} Gives the output: {{{ $ ghc --make Main.hs -threaded && ./Main.exe Before isEmptyChan Main.exe: thread blocked indefinitely in an MVar operation }}} I think that's a bug. Note that if the {{{putStrLn}}} statements are removed then it works, but I think that's because the printing introduces a delay that lets the other thread run. -- Comment: Indeed, let's delete them for 8.4. I've opened #13561 to make sure we don't forget this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4154#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5466: Documentation for Chan could be better
by GHC 10 Apr '17

10 Apr '17

#5466: Documentation for Chan could be better -------------------------------------+------------------------------------- Reporter: pumpkin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Core Libraries | Version: 7.2.1 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by Ömer Sinan Ağacan <omeragacan@…>): In [changeset:"42ef0845d0d2a7cc524e7048502f651d66f6a543/ghc" 42ef0845/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="42ef0845d0d2a7cc524e7048502f651d66f6a543" Improve `readChan` documentation: - Mention that the read end is an `MVar`, so fairness guarantees are inherited. - Mention that it can throw `BlockedIndefinitelyOnMVar` exception. Reviewers: austin, hvr, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #5466 Differential Revision: https://phabricator.haskell.org/D3439 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5466#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4154: Deadlock in Chan module
by GHC 10 Apr '17

10 Apr '17

#4154: Deadlock in Chan module -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 7.0.1 Component: libraries/base | Version: 6.12.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): It's been 7 years since `isEmptyChan` and `unGetChan` was deprecated (first release with deprecation seems to be 7.0). Should we delete them now? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4154#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5466: Documentation for Chan could be better
by GHC 10 Apr '17

10 Apr '17

#5466: Documentation for Chan could be better -------------------------------------+------------------------------------- Reporter: pumpkin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Core Libraries | Version: 7.2.1 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by osa1): https://phabricator.haskell.org/D3439 maybe doesn't close this ticket but it's an improvement. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5466#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12004: Windows unexpected failures
by GHC 10 Apr '17

10 Apr '17

#12004: Windows unexpected failures ----------------------------------------+--------------------------------- Reporter: enolan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- Not sure if these are known or not, sorry if they are. In the 8.0 branch, aab92412cf4cb77d988d36fb013018695c271ccd: {{{ OVERALL SUMMARY for test run started at Mon May 2 11:38:07 2016 PDT 0:40:00 spent to go through 5076 total tests, which gave rise to 14703 test cases, of which 9620 were skipped 73 had missing libraries 4857 expected passes 141 expected failures 0 caused framework failures 0 unexpected passes 12 unexpected failures 0 unexpected stat failures Unexpected failures: ghci.debugger/scripts break011 [bad stdout] (ghci) ghci/prog003 prog003 [bad exit code] (ghci) ghci/scripts T5566 [bad exit code] (ghci) rts testmblockalloc [bad exit code] (normal) rts/T11223 T11223_link_order_a_b_2_fail [bad exit code] (normal) rts/T11223 T11223_link_order_a_b_succeed [bad exit code] (normal) rts/T11223 T11223_link_order_b_a_2_succeed [bad exit code] (normal) rts/T11223 T11223_link_order_b_a_succeed [bad exit code] (normal) rts/T11223 T11223_simple_duplicate_lib [bad exit code] (normal) rts/T11223 T11223_simple_link [bad exit code] (normal) rts/T11223 T11223_simple_link_lib [bad exit code] (normal) rts/T11223 T11223_simple_unused_duplicate_lib [bad exit code] (normal) }}} In HEAD, 36d29f7ce332a2b1fbc36de831b0eef7a6405555: {{{ OVERALL SUMMARY for test run started at Mon May 2 14:07:48 2016 PDT 0:42:17 spent to go through 5112 total tests, which gave rise to 14803 test cases, of which 9680 were skipped 72 had missing libraries 4903 expected passes 140 expected failures 0 caused framework failures 0 unexpected passes 8 unexpected failures 0 unexpected stat failures Unexpected failures: ghci.debugger/scripts break011 [bad stdout] (ghci) ghci/prog003 prog003 [bad exit code] (ghci) partial-sigs/should_compile PatBind [exit code non-0] (normal) plugins plugins01 [bad exit code] (normal) rts T7037 [bad stdout] (normal) rts T9405 [bad exit code] (normal) rts testmblockalloc [bad exit code] (normal) rts/T11223 T11223_simple_duplicate_lib [bad exit code] (normal) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12004> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #13546: Kind error with type equality
by GHC 10 Apr '17

10 Apr '17

#13546: Kind error with type equality -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This code {{{#!hs {-# LANGUAGE TypeInType, TypeFamilies, GADTs, ConstraintKinds #-} import Data.Kind data Dict c where Dict :: c => Dict c data T (t :: k) type family UnT (a :: Type) :: k where UnT (T t) = t untt :: Dict (UnT (T "a") ~ "a") untt = Dict tunt :: Dict (T (UnT (T "a")) ~ T "a") tunt = Dict }}} fails with this error: {{{ tunt.hs:17:8: error: • Couldn't match kind ‘k’ with ‘GHC.Types.Symbol’ ‘k’ is a rigid type variable bound by the type signature for: tunt :: forall k. Dict T (UnT (T "a")) ~ T "a" at tunt.hs:16:1-38 When matching types UnT (T "a") :: k "a" :: GHC.Types.Symbol • In the expression: Dict In an equation for ‘tunt’: tunt = Dict • Relevant bindings include tunt :: Dict T (UnT (T "a")) ~ T "a" (bound at tunt.hs:17:1) | 17 | tunt = Dict | }}} Instead I would expect these reductions to take place: {{{ 1. T (UnT (T "a")) ~ T "a" 2. T "a" ~ T "a" 3. constraint satisfied (refl) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13546> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #13556: "Building and using Win32 DLLs" is dead link
by GHC 10 Apr '17

10 Apr '17

#13556: "Building and using Win32 DLLs" is dead link -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: new Priority: low | 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: -------------------------------------+------------------------------------- https://wiki.haskell.org/GHC/Using_the_FFI Here the link "Building and using Win32 DLLs" is dead. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13556> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10613: Mechanism for checking that we only enter single-entry thunks once
by GHC 10 Apr '17

10 Apr '17

#10613: Mechanism for checking that we only enter single-entry thunks once -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: Other Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- During this week's GHC call it came up that it would be nice to have a linting mechanism for verifying that we only enter single-entry thunks once, as currently this invariant appears to be completely unchecked. Currently we do not record whether a thunk is intended to be single-entry when we emit its code. Moreover, I don't believe there is any room for this left in the info table to record this fact. There are two ways I can think of accomodating this, * stealing a bit from the thunk type field * add a flags field to `StgDebugInfo` such that the lint requires the `debug` way As far as implementing the check itself, I think it should be rather straightforward. When we enter a thunk we simply want to check whether it is single-entry. If it is then we replace it with a special type of `BLACKHOLE`-like thunk which crashes the program (or merely emits a warning) on entry. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10613> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 26

[GHC] #8816: Make SPARC registerised again.
by GHC 10 Apr '17

10 Apr '17

#8816: Make SPARC registerised again. -----------------------------------+--------------------------------- Reporter: kgardas | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Solaris Architecture: sparc | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -----------------------------------+--------------------------------- It looks like recent GHC switched to unregisterised build on SPARC by default. This is kind of regression with the past GHCs where registerised builds were supported. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8816> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7