- ghc-tickets - Haskell.org

[GHC] #13536: Program which terminated in GHC 8.0.2 loops with 8.2.1
by GHC 18 Apr '17

18 Apr '17

#13536: Program which terminated in GHC 8.0.2 loops with 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 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: -------------------------------------+------------------------------------- This currently causes the `vector` test suite to loop forever (see [https://github.com/haskell/vector/pull/161#issuecomment-292031845 here]). I've reproduced this with GHC 8.2.1 and HEAD. Unfortunately, it's not easy to isolate down to a file with no dependencies, so for now this requires `vector` and `QuickCheck` to reproduce. First, install them: {{{ $ cabal install vector QuickCheck --allow-newer -w /opt/ghc/8.2.1/bin/ghc }}} Then take this file: {{{#!hs {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE TypeFamilies #-} module Main (main) where import qualified Data.Vector.Generic as V import qualified Data.Vector.Unboxed as DVU import Test.QuickCheck import Text.Show.Functions () main :: IO () main = do verboseCheck ((\f (i, b) v -> V.foldl f (i, b) v == foldl (\x -> f (unmodel x)) (i, b) ( DVU.toList v)) :: ((Int, Bool) -> (Int, Bool) -> (Int, Bool)) -> (Int, Bool) -> DVU.Vector (Int, Bool) -> Bool) instance (Arbitrary a, DVU.Unbox a) => Arbitrary (DVU.Vector a) where arbitrary = fmap DVU.fromList arbitrary class TestData a where type Model a unmodel :: Model a -> a instance TestData Bool where type Model Bool = Bool unmodel = id instance TestData Int where type Model Int = Int unmodel = id instance (Eq a, Eq b, TestData a, TestData b) => TestData (a,b) where type Model (a,b) = (Model a, Model b) unmodel (a,b) = (unmodel a, unmodel b) }}} Then compile it with `/opt/ghc/8.2.1/bin/ghc -O2 Main.hs` (the `-O2` part is important). Observe that running it never terminates. However, the same program //does// terminate when compiled with 8.0.2! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13536> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 31

[GHC] #13581: UNPACK should allow recursion that obviously terminates
by GHC 18 Apr '17

18 Apr '17

#13581: UNPACK should allow recursion that obviously terminates -------------------------------------+------------------------------------- Reporter: ryanreich | Owner: (none) Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- I want to do this: {{{ {-# LANGUAGE TypeFamilies MagicHash KindSignatures #-} data Peano = Zero | Succ Peano data family BigWord (n :: Peano) data instance BigWord Zero = MachineWord# Word# data instance BigWord (Succ n) = BigWord {-# UNPACK #-}(BigWord n) {-# UNPACK #-}(BigWord n) }}} However, the compiler tells me that it is ignoring the UNPACKs, and the only reason I can see is that they are apparently recursive. This exact type of recursion is handled just fine in instance declarations because the recursive instance has fewer type constructors than the head; can't UNPACK do the same thing? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13581> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12781: Significantly higher allocation with INLINE vs NOINLINE
by GHC 18 Apr '17

18 Apr '17

#12781: Significantly higher allocation with INLINE vs NOINLINE -------------------------------------+------------------------------------- Reporter: | Owner: MikolajKonarski | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following program allocates much more memory ("bytes allocated in the heap") in its current form than with INLINE replaced by NOINLINE, as in the comment. That may be normal, but virtually every feature of this example is needed to trigger the behaviour and so I have no clear idea which language feature is responsible and should be avoided and, consequently, how to optimize my much more complex codebase (in which INLINES of once used functions tend to help and sometimes significantly so). As a comment to this ticket I will post another example, where the difference in allocation is pumped to a factor of 2000, as a proof that the issue is serious. {{{ {-# LANGUAGE RankNTypes #-} import Control.Monad.ST.Strict import qualified Data.IntMap.Strict as IM -- ghc --make -O1 InlineBloat.hs; ./InlineBloat +RTS -s data P = P Int instance Enum P where fromEnum (P x) = x toEnum n = undefined main = do let {-# NOINLINE z #-} z = 44 dis :: Int -> () {-# INLINE dis #-} -- change here to NOINLINE and observe lower alloc dis pI = let p0 = let (_, x) = pI `quotRem` z in P x p1 = let (_, x) = pI `quotRem` z in P x m = IM.lookup (fromEnum p0) IM.empty b = IM.member (fromEnum p1) IM.empty in m == Just 'c' `seq` b `seq` () {-# NOINLINE l #-} l = [0..10000000] mapVT :: forall s. () -> ST s () {-# INLINE mapVT #-} mapVT _ = mapM_ (\x -> return $! dis x) l return $! runST (mapVT ()) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12781> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #13528: Unqualified export of constructors
by GHC 18 Apr '17

18 Apr '17

#13528: Unqualified export of constructors -------------------------------------+------------------------------------- Reporter: dmendler | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: | 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: -------------------------------------+------------------------------------- Unqualified exports of constructors doesn't work anymore in 8.2.1-rc1. It worked before in 8.0. Is this intended or a regression? {{{ module Test ( GHC.Exts.IsList( Item , fromList , toList ) , Data.Bool.Bool(True, False) ) where import qualified GHC.Exts import qualified Data.Bool }}} The error: {{{ • Not in scope: data constructor ‘False’ Perhaps you meant ‘Prelude.False’ (imported from Prelude) • In the export: Data.Bool.Bool(False, True) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13528> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

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

18 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 18 Apr '17

18 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