December 2014 - ghc-tickets

[GHC] #8538: confusing specialization CORE warning, also can't mark type class instances INLINEABLE unless class defn is marked INLINEABLE
by GHC 27 Jul '15

27 Jul '15

#8538: confusing specialization CORE warning, also can't mark type class instances INLINEABLE unless class defn is marked INLINEABLE ------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- As part of writing an array library for numerical purposes, I have a static sized strict list type for representing the Indexing tuple. One implementation strategy makes it a tad generic, and then I'm writing a bunch of manipulation utilities using Functor, Applicative and Foldable. I wrote it with all the functions marked INLINABLE so i could ensure that I could have the index arith calculations SPECIALIZE in the common cases. Unfortunately, it seems like type class instances can only marked INLINABLE if the type class definition is itself marked INLINE or INLINABLE. Considering i'm writing a numerical array library, I want to make sure that address arithmetic. This could could be argued to be by design (and thus a wont fix). That aside, I also get the following Warning for my "map2" function, which i found surprising. (and it perhaps is worth some investigation / cleanup ) {{{ src/Numerical/Types/Shape.hs:165:1: Warning: RULE left-hand side too complicated to desugar let { $dFunctor :: Functor (Shape ('S N0)) [LclId] $dFunctor = Numerical.Types.Shape.$fFunctorShape @ 'Z $dFunctor } in map2 @ a @ b @ c @ N2 (Numerical.Types.Shape.$fApplicativeShape @ ('S N0) (Numerical.Types.Shape.$fFunctorShape @ ('S N0) $dFunctor) (Numerical.Types.Shape.$fApplicativeShape @ 'Z $dFunctor Numerical.Types.Shape.$fApplicativeShape0)) }}} {{{ {-# LANGUAGE PolyKinds #-} {-# LANGUAGE BangPatterns #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE DeriveDataTypeable #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE StandaloneDeriving #-} {-# LANGUAGE CPP #-} {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE NoImplicitPrelude #-} module Numerical.Types.Shape where import GHC.Magic import Data.Monoid import Data.Functor import Data.Foldable import Control.Applicative -- import Numerical.Types.Nat import Prelude (seq, ($!),($),Show(..),Eq(),Int) data Nat = S !Nat | Z type N0 = Z type N1= S N0 type N2 = S N1 type N3 = S N2 type N4 = S N3 {- not doing the HLIST style shape because I don't want to have any pattern matchings going on. Also would play hell with locality quality in the address translation hackery, because there'd be an extra load to get those ints! -} infixr 3 :* {- the concern basically boils down to "will it specialize / inline well" -} data Shape (rank :: Nat) a where Nil :: Shape Z a (:*) :: !(a) -> !(Shape r a ) -> Shape (S r) a --deriving instance (Show (Shape rank a)) -- deriving instance Eq (Shape rank a) -- #if defined( __GLASGOW_HASKELL__ ) && ( __GLASGOW_HASKELL__ >= 707) --deriving instance Typeable (Shape rank a) -- #endif instance Functor (Shape Z) where fmap = \ f Nil -> Nil {-# INLINABLE fmap #-} {-# SPECIALIZE fmap :: (a ->b )-> (Shape Z a)-> (Shape Z b) #-} instance (Functor (Shape r)) => Functor (Shape (S r)) where fmap = \ f (a :* rest) -> f a :* fmap f rest {-# INLINABLE fmap #-} {-# SPECIALIZE fmap :: (a ->b )-> (Shape N1 a)-> (Shape N1 b) #-} {-# SPECIALIZE fmap :: (a ->b )-> (Shape N2 a)-> (Shape N2 b) #-} instance Applicative (Shape Z) where pure = \ _ -> Nil {-# INLINE pure #-} (<*>) = \ _ _ -> Nil {-# INLINE (<*>) #-} {-# SPECIALIZE pure :: a -> Shape Z a #-} {-# SPECIALIZE (<*>) :: Shape Z (a -> b) -> Shape Z a -> Shape Z b #-} instance Applicative (Shape r)=> Applicative (Shape (S r)) where pure = \ a -> a :* (pure a) {-# INLINE pure #-} (<*>) = \ (f:* fs) (a :* as) -> f a :* (inline (<*>)) fs as {-# INLINE (<*>) #-} {-# SPECIALIZE pure :: a -> (Shape Z a) #-} {-# SPECIALIZE pure :: a -> (Shape N1 a) #-} {-# SPECIALIZE pure :: a -> (Shape N2 a )#-} instance Foldable (Shape Z) where foldMap = \ _ _ -> mempty {-# INLINE foldMap #-} foldl = \ _ init _ -> init {-# INLINE foldl #-} foldr = \ _ init _ -> init {-# INLINE foldr #-} foldr' = \_ !init _ -> init {-# INLINE foldr' #-} foldl' = \_ !init _ -> init {-# INLINE foldl' #-} -- {-# SPECIALIZE foldMap :: Monoid m => (a -> m)-> Shape Z a -> m #-} -- {-# SPECIALIZE foldl :: (a ->b -> a) -> a -> Shape Z b -> a #-} -- {-# SPECIALIZE foldr :: (b ->a -> a) -> a -> Shape Z b -> a #-} -- {-# SPECIALIZE foldl' :: (a ->b -> a) -> a -> Shape Z b -> a #-} -- {-# SPECIALIZE foldr' :: (b ->a -> a) -> a -> Shape Z b -> a #-} instance (Foldable (Shape r)) => Foldable (Shape (S r)) where foldMap = \f (a:* as) -> f a <> foldMap f as {-# INLINE foldMap #-} foldl' = \f !init (a :* as) -> let next = f init a in next `seq` (inline foldl) f next as {-# INLINE foldl' #-} foldr' = \f !init (a :* as ) -> f a $! (inline foldr) f init as {-# INLINABLE foldr' #-} foldl = \f init (a :* as) -> let next = f init a in (inline foldl) f next as {-# INLINE foldl #-} foldr = \f init (a :* as ) -> f a $ (inline foldr) f init as {-# INLINE foldr #-} {-# SPECIALIZE foldMap::Monoid m => (a -> m)-> Shape N1 a -> m #-} {-# SPECIALIZE foldl :: (a ->b -> a) ->a -> Shape N1 b -> a #-} {-# SPECIALIZE foldr :: (b ->a -> a) -> a -> Shape N1 b -> a #-} {-# SPECIALIZE foldl' :: (a ->b -> a) -> a -> Shape N1 b -> a #-} {-# SPECIALIZE foldr' :: (b ->a -> a) -> a -> Shape N1 b -> a #-} {-# SPECIALIZE foldMap :: Monoid m => (a -> m)-> Shape N2 a -> m #-} {-# SPECIALIZE foldl :: (a ->b-> a) ->a -> Shape N2 b -> a #-} {-# SPECIALIZE foldr :: (b ->a -> a) -> a -> Shape N2 b -> a #-} {-# SPECIALIZE foldl' :: (a ->b -> a) -> a -> Shape N2 b -> a #-} {-# SPECIALIZE foldr' :: (b ->a -> a) -> a -> Shape N2 b -> a #-} -- map2 :: (Applicative (Shape r))=> (a->b ->c) -> (Shape r a) -> (Shape r b) -> (Shape r c ) map2 = \f l r -> pure f <*> l <*> r {-# INLINABLE map2 #-} {-# SPECIALIZE map2 :: (a -> b -> c ) -> (Shape Z a) -> (Shape Z b) -> (Shape Z c )#-} {-# SPECIALIZE map2 :: (a -> b -> c ) -> (Shape N1 a) -> (Shape N1 b) -> (Shape N1 c )#-} {-# SPECIALIZE map2 :: (a -> b -> c ) -> (Shape N2 a) -> (Shape N2 b) -> (Shape N2 c )#-} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8538> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9267: Lack of type information in GHC error messages when the liberage coverage condition is unsatisfied
by GHC 25 Jul '15

25 Jul '15

#9267: Lack of type information in GHC error messages when the liberage coverage condition is unsatisfied -------------------------+------------------------------------------------- Reporter: | Owner: danilo2 | Status: new Type: bug | Milestone: Priority: | Version: 7.8.2 normal | Operating System: Unknown/Multiple Component: | Type of failure: Incorrect warning at Compiler | compile-time Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- Hello! The problem is not a bug related to proper code execution, but it affects the development in such way, we can treat it as a bug. Lets think about such simple code (it can be further simplified of course): {{{#!haskell {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE UndecidableInstances #-} data UnsafeBase base err val = Value val | Error err | Other (base val) deriving (Show, Eq) class MagicMerge m1 m2 | m1 -> m2 where magicMerge :: m1 a -> m2 a instance MagicMerge (UnsafeBase (UnsafeBase base err) err) (UnsafeBase base err) where magicMerge ma = case ma of Value a -> Value a Error e -> Error e Other o -> o instance MagicMerge (UnsafeBase (UnsafeBase base err1) err2) (UnsafeBase dstBase err1) where magicMerge (ma :: UnsafeBase (UnsafeBase base err1) err2 a) = case ma of Value a -> Value a Error e -> Other $ magicMerge (Error e :: UnsafeBase base err2 a) Other o -> case o of Value a -> Other $ magicMerge (Value a :: UnsafeBase base err2 a) Error e -> Error e Other o' -> Other $ magicMerge (Other o' :: UnsafeBase base err2 a) main = print "help me world!" }}} When trying to compile it using GHC-7.8, we get following error message: {{{#!haskell Illegal instance declaration for ‘MagicMerge (UnsafeBase (UnsafeBase base err1) err2) (UnsafeBase dstBase err1)’ The liberal coverage condition fails in class ‘MagicMerge’ for functional dependency: ‘m1 -> m2’ Reason: lhs type ‘UnsafeBase (UnsafeBase base err1) err2’ does not determine rhs type ‘UnsafeBase dstBase err1’ In the instance declaration for ‘MagicMerge (UnsafeBase (UnsafeBase base err1) err2) (UnsafeBase dstBase err1)’ }}} Which is of course right, but it is completely unhelpfull! When we run the same program against GHC-7.6, we get another message: {{{#!haskell No instance for (MagicMerge (UnsafeBase base err2) dstBase) arising from a use of `magicMerge' Possible fix: add an instance declaration for (MagicMerge (UnsafeBase base err2) dstBase) In the second argument of `($)', namely `magicMerge (Error e :: UnsafeBase base err2 a)' In the expression: Other $ magicMerge (Error e :: UnsafeBase base err2 a) In a case alternative: Error e -> Other $ magicMerge (Error e :: UnsafeBase base err2 a) }}} And it contains a very helpfull information about inferred types. The information is very helpfull, especialy with more complex instances. What is VERY IMPORTANT, when we use the inferred type, the code starts working in both, GHC-7.8 and GHC-7.6. Right now I have to use both versions of GHC to be able to develop my instances faster. So If we add the inferred by GHC-7.6 premise: {{{#!haskell {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE UndecidableInstances #-} data UnsafeBase base err val = Value val | Error err | Other (base val) deriving (Show, Eq) class MagicMerge m1 m2 | m1 -> m2 where magicMerge :: m1 a -> m2 a instance MagicMerge (UnsafeBase (UnsafeBase base err) err) (UnsafeBase base err) where magicMerge ma = case ma of Value a -> Value a Error e -> Error e Other o -> o instance (MagicMerge (UnsafeBase base err2) dstBase) => MagicMerge (UnsafeBase (UnsafeBase base err1) err2) (UnsafeBase dstBase err1) where magicMerge (ma :: UnsafeBase (UnsafeBase base err1) err2 a) = case ma of Value a -> Value a Error e -> Other $ magicMerge (Error e :: UnsafeBase base err2 a) Other o -> case o of Value a -> Other $ magicMerge (Value a :: UnsafeBase base err2 a) Error e -> Error e Other o' -> Other $ magicMerge (Other o' :: UnsafeBase base err2 a) main = print "help me world!" }}} The code compiles and works ok in both GHC-7.6 and GHC-7.8. In such cases, GHC-7.8 should inform about lacking premises. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9267> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8327: Cmm sinking does not eliminate dead code in loops
by GHC 25 Jul '15

25 Jul '15

#8327: Cmm sinking does not eliminate dead code in loops ------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Cmm code shown in #8326 is suboptimal. For this Haskell code: {{{ isTrue# :: Int# -> Bool isTrue# 1# = True isTrue# _ = False f :: Int# -> Int f x | isTrue# (x ># 0#) = I# x | otherwise = -(I# x) }}} we get Cmm that contains dead code in a loop: {{{ cFg: // False branch Hp = Hp + 16; if (Hp > HpLim) goto cFy; else goto cFx; cFy: // not enough heap, call GC HpAlloc = 16; I64[Sp - 16] = cFf; R1 = _sEV::I64; I64[Sp - 8] = _sEU::I64; Sp = Sp - 16; call stg_gc_unbx_r1(R1) returns to cFf, args: 8, res: 8, upd: 8; cFf: // re-do the False branch _sEU::I64 = I64[Sp + 8]; Sp = Sp + 16; _sEV::I64 = R1; goto cFg; cFx: // RHS of False branch I64[Hp - 8] = GHC.Types.I#_con_info; I64[Hp] = -_sEU::I64; R1 = Hp - 7; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; }}} Notice that `_sEV` is dead - we should optimize it away. This is a known deficiency in the Cmm sinking pass (i.e. it does not work for loops). I'm putting this on Trac so we have this documented. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8327> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8604: Some stack/vmem limits (ulimit) combinations causing GHC to fail
by GHC 25 Jul '15

25 Jul '15

#8604: Some stack/vmem limits (ulimit) combinations causing GHC to fail ----------------------------------+---------------------------------- Reporter: clavin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Other Architecture: x86_64 (amd64) | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------------- I have encountered a strange occurrence with GHC that was causing several GHC job failures on an SGE cluster. It turned out that there were other SGE users who needed an absurdly large stack size limit (set via 'ulimit -s') in the several gigabytes range. The default stack size limit had to be raised for the entire cluster. Any job that was run on a machine where the virtual memory limit was less than or equal to 2X the stack size limit, GHC would crash with the following message: ghc: failed to create OS thread: Cannot allocate memory I am running on GHC 7.6.3 with a 64-bit RedHat Enterprise OS, version 5.5. To reproduce the error, I was able to create the following test case: [ ~]$ ulimit -v unlimited [ ~]$ ulimit -s 10240 [ ~]$ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.6.3 [ ~]$ ulimit -v 200000 [ ~]$ ulimit -s 100000 [ ~]$ ghc --version ghc: failed to create OS thread: Cannot allocate memory Several other programs work find using these settings, but GHC consistently has problems. Is this a fundamental issue with how GHC operates or can this be addressed? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8604> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9229: Compiler memory use regression
by GHC 24 Jul '15

24 Jul '15

#9229: Compiler memory use regression -------------------------+------------------------------------------------- Reporter: | Owner: augustss | Status: new Type: bug | Milestone: Priority: | Version: 7.8.2 normal | Operating System: Windows Component: | Type of failure: Compile-time performance bug Compiler | Test Case: Keywords: | Blocking: Architecture: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- I have a module which compiles fine with ghc 7.6, but where ghc 7.8.2 runs out of memory (32-bit Windows). Sadly, I cannot supply the source code since it's proprietary, so I realize that this bug will be almost impossible to fix. It is possible to compile the module with -O0 and -O1, but not -O2. (This is a very performance critical module so I'd like -O2.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9229> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9256: Support automatic derivation of an hs-boot file from an hs file
by GHC 24 Jul '15

24 Jul '15

#9256: Support automatic derivation of an hs-boot file from an hs file ------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: backpack | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- This is essentially augustss's proposal from ticket #1409: I would settle for a solution where I annotate those entities in a module that would go in the hs-boot file. So instead of me having to go through the trouble of creating an extra file I could just say, e.g., Replying to [comment:13 augustss]: > I would settle for a solution where I annotate those entities in a module that would go in the hs-boot file. So instead of me having to go through the trouble of creating an extra file I could just say, e.g., > > {{{ > {-# MODULE_MUTUAL_RECURSION_BREAKER T, foo #-} > data T = ... > foo :: ... > foo = ... > }}} > > The values that have an annotation would have to have a type signature. This should be eminently doable. Here is a more fleshed out proposal. First, consider the definition of an hs-boot file in the absence of mutual recursion (i.e. no breakers are necessary). In this case, the hi-boot file for an hs file is precisely the hi file produced after ordinary renaming and typechecking of the module. As an optimization, we would like to avoid typechecking definitions if an explicit type signature is present (if the type signature is absent, we have no choice.) There are a few choices here: we can force users to give top-level declarations for all exported functions (so unconditionally error if something is missing, by filtering out the relevant value declarations from the source), or we can go ahead and do full typechecking when the signature is missing. (The former is probably the simplest.) Now, how to handle breakers? We need to avoid typechecking them, since their recursive dependence means that they would not type check properly. So we should also filter out their type signatures. (Furthermore, if we are inferring some signatures, we need to make sure that their definitions don't rely on any breakers. For this reason, it is probably simplest to just require explicit type signatures.) If the mechanism for specifying breakers is exclusionary (as opposed to an inclusionary method of saying what values are in the signature), there is an awkward problem of syntax for exporting only an abstract type: the logical choices mean the wrong thing (`T(..)` seem to imply the type is eliminated entirely, whereas `T` seems to imply that the type should be eliminated, but not eh constructors.) Summary: 1. Require top-level signatures in hs to hs-boot files(?) 2. Exclusionary or inclusionary signature pragma? 3. Filter out value declarations and excluded files, then rename/typecheck as normal, producing hi-boot file -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9256> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8131: T7571 with WAY=llvm fails, but not WAY=optllvm
by GHC 20 Jul '15

20 Jul '15

#8131: T7571 with WAY=llvm fails, but not WAY=optllvm ------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Test case (#7571 just will not die, it seems) {{{ $ make TEST=T7571 WAY=llvm ... ====> Scanning ./all.T =====> T7571(llvm) 6 of 7 [0, 0, 0] cd . && '/home/a/ghc/ghc-pristine/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T7571.cmm -fllvm -no-hs-main >T7571.comp.stderr 2>&1 Actual stderr output differs from expected: --- /dev/null 2013-08-07 22:18:14.132934017 -0500 +++ ./T7571.comp.stderr 2013-08-14 01:26:33.942103723 -0500 @@ -0,0 +1 @@ +WARNING: Non constant alignment value given for memcpy! Please report to GHC developers *** unexpected failure for T7571(llvm) }}} However, this test case does not fail under WAY=optllvm, which I think is worth investigating probably: {{{ $ make TEST=T7571 WAY=optllvm ... ====> Scanning ./all.T =====> T7571(optllvm) 6 of 7 [0, 0, 0] cd . && '/home/a/ghc/ghc-pristine/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T7571.cmm -O -fllvm -no-hs-main >T7571.comp.stderr 2>&1 OVERALL SUMMARY for test run started at Wed Aug 14 01:25:42 CDT 2013 7 total tests, which gave rise to 28 test cases, of which 27 were skipped 0 had missing libraries 1 expected passes 0 expected failures 0 caused framework failures 0 unexpected passes 0 unexpected failures }}} However, there is another way to trigger this bug in *both* cases: {{{ #include "Cmm.h" testMemcpy (W_ dst, W_ src, W_ l, W_ sz) { prim %memcpy(dst, src, l, sz); return (); } }}} will fail both ways. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8131> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #9571: nofib should use criterion-style bootstrapping/sampling
by GHC 20 Jul '15

20 Jul '15

#9571: nofib should use criterion-style bootstrapping/sampling -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: NoFib benchmark | Version: 7.9 suite | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- As I discovered when investigating situations like #9570, in some cases, test-cases in nofib are giving nonsense, and it's hard to tell unless you run nofib several times and notice that percentage differences are fluctuating up and down. The quality of the numbers we get for uninformed users would be better if we ran some statistical analysis to tell how many times to run the benchmark, and if there were lots of outliers (rather than just blindly summarizing all the runs using an average.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9571> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8123: GHCi warns about -eventlog even though it's sometimes necessary
by GHC 19 Jul '15

19 Jul '15

#8123: GHCi warns about -eventlog even though it's sometimes necessary -------------------------+------------------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: | Milestone: normal | Version: 7.6.3 Component: GHCi | Operating System: Linux Keywords: | Type of failure: Incorrect warning at Architecture: | compile-time x86_64 (amd64) | Test Case: Difficulty: | Blocking: Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- If I invoke GHCi as {{{ghci -eventlog}}}, it says: {{{Warning: -debug, -threaded and -ticky are ignored by GHCi}}}. However, the flag does make a difference, in that GHCi will be able to load object files that were compiled using {{{-eventlog}}}. For this reason, I don't think {{{-eventlog}}} should trigger the warning. Also runghc has the same issue. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8123> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9243: Recompilation avoidance works imperfectly with -fno-code/-fwrite-interface
by GHC 17 Jul '15

17 Jul '15

#9243: Recompilation avoidance works imperfectly with -fno-code/-fwrite-interface -------------------------+------------------------------------------------- Reporter: | Owner: ezyang | Status: new Type: bug | Milestone: Priority: | Version: 7.9 normal | Operating System: Unknown/Multiple Component: | Type of failure: Compile-time performance bug Compiler | Test Case: Keywords: | Blocking: Architecture: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- With the latest `-fwrite-interface` enhancements, a build directory can contain interface files independently of object files. In cases like this, we would like to have recompilation avoidance avoid typechecking files whose interface files are up-to-date. However, this does not currently work: we always re-typecheck: {{{ t-edyang@cam-05-unx:/5playpen/t-edyang/sandbox/q$ /5playpen/t-edyang/ghc- backpack/inplace/bin/ghc-stage2 --make A.hs -fno-code -fwrite-interface [1 of 1] Compiling A ( A.hs, nothing ) t-edyang@cam-05-unx:/5playpen/t-edyang/sandbox/q$ /5playpen/t-edyang/ghc- backpack/inplace/bin/ghc-stage2 --make A.hs -fno-code -fwrite-interface [1 of 1] Compiling A ( A.hs, nothing ) }}} The reason for this is that recompilation avoidance logic in `compileOne` (in `DriverPipeline.hs`) seems to rely exclusively on "linkables" in order to figure out if source has been modified or not. We never generate an object file with `-fwrite-interface`, so the compiler always concludes that we need to retypecheck. However, recompilation avoidance for hs-boot does work. The reason for this is because we create a dummy o-boot linkable. We can't use this strategy for `-fno-code`, because the dummy object file would imply that we actually compiled the file (which we didn't). The upshot is that to fix this problem, it looks like we might have to rejigger all of the logic in `compileOne`, which why I gave up on this for now. Related to https://github.com/haskell/cabal/issues/1179 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9243> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11