- ghc-tickets - Haskell.org

[GHC] #12741: --numa doesn't work even if libnuma is available
by GHC 23 Oct '16

23 Oct '16

#12741: --numa doesn't work even if libnuma is available -------------------------------------+------------------------------------- Reporter: darshan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 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: -------------------------------------+------------------------------------- The configure script set USE_LIBNUMA to 1 if numa exists however the code checks for HAVE_LIBNUMA. From the main directory, {{{ ./configure && make clean && make boot && make cd nofib/parallel/queens ../../../inplace/bin/ghc-stage2 Main.hs -rtsopts -threaded ./Main 15 +RTS -N24 -s -A64m --numa }}} It fails saying {{{ Main: --numa: OS reports NUMA is not available }}} https://phabricator.haskell.org/D2329 introduced this error. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12741> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12751: T5611 fails non-deterministically on OSX
by GHC 23 Oct '16

23 Oct '16

#12751: T5611 fails non-deterministically on OSX -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- Here is the test. {{{#!hs {-# LANGUAGE CPP,ForeignFunctionInterface #-} import Control.Concurrent import Foreign.C import System.IO #ifdef mingw32_HOST_OS sleep n = sleepBlock (n*1000) foreign import stdcall unsafe "Sleep" sleepBlock :: Int -> IO () #else sleep n = sleepBlock n foreign import ccall unsafe "sleep" sleepBlock :: Int -> IO () #endif main :: IO () main = do hSetBuffering stdout LineBuffering tid <- forkIO $ do putStrLn "child: Sleeping" _ <- sleep 1 -- The following lines should not happen after the killThread from the -- parent thread completes. However, they do... -- putStrLn "child: Done sleeping" threadDelay 100000 putStrLn "child: Done waiting" threadDelay 100000 -- putStrLn $ "parent: Throwing exception to thread " ++ show tid throwTo tid $ userError "Exception delivered successfully" putStrLn "parent: Done throwing exception" threadDelay 200000 }}} It occasionally fails with {{{ =====> T5611(normal) 1 of 1 [0, 0, 0] cd "./concurrent/should_run/T5611.run" && "/Users/matt/Documents/haskell/ghc/inplace/test spaces/ghc-stage2" -o T5611 T5611.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno- warn-missed-specialisations -fshow-warning-groups -dno-debug-output cd "./concurrent/should_run/T5611.run" && ./T5611 Actual stderr output differs from expected: --- ./concurrent/should_run/T5611.run/T5611.stderr.normalised 2016-10-21 22:08:55.000000000 +0100 +++ ./concurrent/should_run/T5611.run/T5611.run.stderr.normalised 2016-10-21 22:08:55.000000000 +0100 @@ -1 +0,0 @@ -T5611: user error (Exception delivered successfully) *** unexpected failure for T5611(normal) Unexpected results from: TEST="T5611" }}} I am marking it broken for now. Does anyone know why it is failing? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12751> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #5030: Slow type checking of type-level computation heavy code.
by GHC 22 Oct '16

22 Oct '16

#5030: Slow type checking of type-level computation heavy code. -------------------------------------------------+----------------------- Reporter: thesz | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.2.1 Component: Compiler (Type checker) | Version: 7.0.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Compile-time performance bug | Test Case: T5030 Blocked By: | Blocking: Related Tickets: | -------------------------------------------------+----------------------- Comment (by Simon Peyton Jones <simonpj@…>): In [changeset:"1f09b246d377a0007a953e5a77545d81671d2e36/ghc" 1f09b246/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1f09b246d377a0007a953e5a77545d81671d2e36" Accept 20% dedgradation in Trac #5030 compile time In commit 31621b12 * A collection of type-inference refactorings. I fixed a bug in the on-the-fly unifier. Usually the on-the-fly unifier (TcUnify) defers type function applications to the constraint solver. But in one situation it inconsistently did not defer, so a unification happened without reducing a type function. By a fluke this makes T5030 (specifcially the definition of cnst) much better. It turns out that consistently non-deferring type functions makes the test for #3064 go bad. So somehow the current, inconsistent situation was an accidental sweet spot. But it's a horrible sweet spot, relying on what was essentially a bug. So I've accepted the worsening (it's an exotic case), and opened #12724 to deal with the underlying cause. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5030#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12724: Be lazier about reducing type-function applications
by GHC 22 Oct '16

22 Oct '16

#12724: Be lazier about reducing type-function applications -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- Consider this: {{{ f :: F 20 -> F 20 f x = x }}} That ought to typecheck in a trice, right? But if `F` is a type function, GHC currently (8.0) eagerly reduces `F 20` to normal form. Let's say `F 20` unltimately reduces to `Int`, after a long time. Then we get {{{ f = \x . (x |> g1) |> g2 where g1 :: F 20 ~ Int g2 :: Int ~ F 20 }}} Here both `g1` and `g2` are big coercions. So we waste time reducing `F 20` ''and'' we generate giant coercions by doing so. Maybe the optimiser gets rid of them again; more probably not. But it's clearly stupid. This is one reason that the program in #5030 typechecks so slowly. We have {{{ cnst :: Integer -> Either (Immediate DummyCPU) (RegVar DummyCPU) cnst x = Left (Const x) }}} and there is absolutely no need to reduce either argument of the `Either` to normal form. Richard and I have ideas about how to fix this, but I'm recording it in a ticket. and -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12724> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #3064: Very long compile times with type functions
by GHC 22 Oct '16

22 Oct '16

#3064: Very long compile times with type functions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: low | Milestone: 8.0.1 Component: Compiler (Type | Version: 6.10.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | perf/compiler/T3064 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones <simonpj@…>): In [changeset:"1f09b246d377a0007a953e5a77545d81671d2e36/ghc" 1f09b246/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1f09b246d377a0007a953e5a77545d81671d2e36" Accept 20% dedgradation in Trac #5030 compile time In commit 31621b12 * A collection of type-inference refactorings. I fixed a bug in the on-the-fly unifier. Usually the on-the-fly unifier (TcUnify) defers type function applications to the constraint solver. But in one situation it inconsistently did not defer, so a unification happened without reducing a type function. By a fluke this makes T5030 (specifcially the definition of cnst) much better. It turns out that consistently non-deferring type functions makes the test for #3064 go bad. So somehow the current, inconsistent situation was an accidental sweet spot. But it's a horrible sweet spot, relying on what was essentially a bug. So I've accepted the worsening (it's an exotic case), and opened #12724 to deal with the underlying cause. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3064#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11339: Possible type-checker regression in GHC 8.0
by GHC 22 Oct '16

22 Oct '16

#11339: Possible type-checker regression in GHC 8.0 -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 (Type checker) | 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 following code (extracted from hackage:microlens) type-checks on GHC 7.10 but '''not''' on GHC 8.0/8.1: {{{#!hs {-# LANGUAGE RankNTypes, ScopedTypeVariables #-} module Failing where import Control.Applicative ( Const(Const, getConst) ) import Data.Functor.Identity ( Identity(Identity) ) type Traversal s t a b = forall f. Applicative f => (a -> f b) -> s -> f t failing :: forall s t a b . Traversal s t a b -> Traversal s t a b -> Traversal s t a b failing left right afb s = case pins t of [] -> right afb s _ -> t afb where -- t :: (a -> f b) -> f t -- TYPECHECKS with GHC 7.10, but not with GHC 8.x: Bazaar { getBazaar = t } = left sell s -- FAILS TO TYPECHECK with GHC 7.10 and GHC 8.x: -- t = getBazaar (left sell s) sell :: a -> Bazaar a b b sell w = Bazaar ($ w) pins :: ((a -> Const [Identity a] b) -> Const [Identity a] t) -> [Identity a] pins f = getConst (f (\ra -> Const [Identity ra])) newtype Bazaar a b t = Bazaar { getBazaar :: (forall f. Applicative f => (a -> f b) -> f t) } instance Functor (Bazaar a b) where fmap f (Bazaar k) = Bazaar (fmap f . k) instance Applicative (Bazaar a b) where pure a = Bazaar $ \_ -> pure a Bazaar mf <*> Bazaar ma = Bazaar $ \afb -> mf afb <*> ma afb }}} The following error is emitted on GHC 8.0: {{{ failing.hs:13:11: error: • Couldn't match type ‘f’ with ‘Const [Identity a]’ ‘f’ is a rigid type variable bound by the type signature for: failing :: forall (f :: * -> *). Applicative f => Traversal s t a b -> Traversal s t a b -> (a -> f b) -> s -> f t at failing.hs:11:1 Expected type: a -> Const [Identity a] b Actual type: a -> f b • In the first argument of ‘t’, namely ‘afb’ In the expression: t afb In a case alternative: _ -> t afb • Relevant bindings include t :: (a -> Const [Identity a] b) -> Const [Identity a] t (bound at failing.hs:18:26) sell :: a -> Bazaar a b b (bound at failing.hs:24:5) pins :: ((a -> Const [Identity a] b) -> Const [Identity a] t) -> [Identity a] (bound at failing.hs:27:5) afb :: a -> f b (bound at failing.hs:11:20) right :: Traversal s t a b (bound at failing.hs:11:14) left :: Traversal s t a b (bound at failing.hs:11:9) failing :: Traversal s t a b -> Traversal s t a b -> Traversal s t a b (bound at failing.hs:11:1) }}} I don't understand why `Bazaar t = ...` vs `t = getBazaar ...` makes a difference in GHC 7.10 at all. So I'm not sure if this is a regression or actually something that got fixed in GHC 8.0... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11339> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #12749: Typechecker regression involving RankNTypes
by GHC 21 Oct '16

21 Oct '16

#12749: Typechecker regression involving RankNTypes -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | 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: -------------------------------------+------------------------------------- The following code compiles on GHC 7.0.4 through 7.10.3, but not with GHC 8.0.1, 8.0.2, or HEAD: {{{#!hs {-# LANGUAGE RankNTypes #-} module Bug where type NatTrans f g = forall x. f x -> g x -- NatTrans analog of id applyNT :: NatTrans f g -> NatTrans f g applyNT x = x b :: Bool b = True eitherToMaybe :: NatTrans (Either a) Maybe eitherToMaybe (Left _) = Nothing eitherToMaybe (Right x) = Just x trans :: NatTrans (Either a) Maybe -> NatTrans (Either a) Maybe trans x = x applyNTCheck :: NatTrans (Either a) Maybe applyNTCheck = (if b then trans else applyNT) eitherToMaybe }}} {{{ $ /opt/ghc/8.0.1/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:21:27: error: • Couldn't match type ‘NatTrans (Either a) Maybe’ with ‘Either a0 x0 -> Maybe x0’ Expected type: (Either a0 x0 -> Maybe x0) -> Either a x -> Maybe x Actual type: NatTrans (Either a) Maybe -> Either a x -> Maybe x • In the expression: trans In the expression: if b then trans else applyNT In the expression: (if b then trans else applyNT) eitherToMaybe • Relevant bindings include applyNTCheck :: Either a x -> Maybe x (bound at Bug.hs:21:1) }}} (Originally spotted [https://github.com/ku-fpg/natural- transformation/pull/13#issuecomment-255378141 here].) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12749> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12743: Profiling wrongly attributes allocations to a function with Int# result
by GHC 21 Oct '16

21 Oct '16

#12743: Profiling wrongly attributes allocations to a function with Int# result -------------------------------------+------------------------------------- Reporter: | Owner: MikolajKonarski | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Profiling can't decide whether the given function allocates or not at all. The code snippet says it all: {{{ {-# LANGUAGE MagicHash #-} import GHC.Exts -- ghc -prof --make bork.hs -fprof-auto -O1 -- ./bork +RTS -s -P -RTS main = do let f :: Int -> Int# -- {-# NOINLINE f #-} f x = case x `div` 17 of I# i -> i -- {-# NOINLINE g #-} g h = sum $ map (\y -> I# (h y)) [0..1000000] g f `seq` return () -- COST CENTRE MODULE %time %alloc ticks bytes -- main.g Main 73.6 93.3 159 224000328 -- main.f Main 24.1 6.7 52 16000016 -- main.g.\ Main 2.3 0.0 5 0 -- When either of the NOINLINE is enabled, the profile becomes: -- COST CENTRE MODULE %time %alloc ticks bytes -- main.g Main 72.9 93.3 161 224000328 -- main.f Main 16.7 0.0 37 0 -- main.g.\ Main 10.4 6.7 23 16000016 -- So, does f actually allocate or not? -- Profiling is quite a bit less useful if it can't answer that reliably, -- because in larger code snippets it's hard to decide from source -- or from Core/STG. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12743> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12236: Windows profiling: T11627b segfaults for WAY=prof_hc_hb
by GHC 21 Oct '16

21 Oct '16

#12236: Windows profiling: T11627b segfaults for WAY=prof_hc_hb ----------------------------------------+--------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.10.3 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #11627 Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- Reproducible with 7.10.3, 8.0.1 and today's HEAD ( afa6e8309e8e7a069abcf7879791d53cdf22f00a). The test was added by @jme in #11627. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12236> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12740: generic Linux installer contains dynamically linked helpers failing to run on non glibc systems
by GHC 20 Oct '16

20 Oct '16

#12740: generic Linux installer contains dynamically linked helpers failing to run on non glibc systems -------------------------------------+------------------------------------- Reporter: gliptak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Installing GHC (amd64) | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I downloaded http://downloads.haskell.org/~ghc/8.0.1/ghc-8.0.1-x86_64-deb8-linux.tar.xz and running configure on Alpine Linux (musl based) failed. The immediate cause seems to be that ghc-* files are not linked statically. {{{ /tmp/ghc-8.0.1 # file utils/ghc-cabal/dist-install/build/tmp/ghc-cabal utils/ghc-cabal/dist-install/build/tmp/ghc-cabal: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=6359ffd9a860387d6f91c40dccceaddd493f7a54, not stripped /tmp/ghc-8.0.1 # file utils/ghc-pwd/dist-install/build/tmp/ghc-pwd utils/ghc-pwd/dist-install/build/tmp/ghc-pwd: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld- linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=9fcf1bc38db049d6bafc6e611c09b6700071bfbb, not stripped }}} Could static linkage be considered for these helpers allowing them to run on non-glibc setups? Thanks -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12740> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2