February 2019 - ghc-tickets

[GHC] #16364: Derived Enum for small number of constructors seems suboptimal
by GHC 26 Feb '19

26 Feb '19

#16364: Derived Enum for small number of constructors seems suboptimal -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE MagicHash #-} module En (toEnum', toEnum'', toEnum''', toEnum'''') where import GHC.Int import GHC.Prim import GHC.Word data Q' = Foo' | Bar' deriving Enum toEnum' :: Int -> Q' toEnum' 0 = Foo' toEnum' 1 = Bar' toEnum' x = error $ "out of range " <> show x toEnum'' :: Int -> Q' toEnum'' x@(I# n) | x >= 0 && x <= 1 = tagToEnum# n toEnum'' x = error $ "out of range " <> show x toEnum''' :: Int -> Q' toEnum''' x@(I# n) | x == 0 || x == 1 = tagToEnum# n toEnum''' x = error $ "out of range " <> show x toEnum'''' :: Int -> Q' toEnum'''' x@(I# n) = case int2Word# n `leWord#` 1## of 0# -> error $ "out of range " <> show x _ -> tagToEnum# n }}} For the derived {{{toEnum}}}, we get something as {{{#!hs -- RHS size: {terms: 19, types: 4, coercions: 0, joins: 0/0} En.$w$ctoEnum [InlPrag=NOUSERINLINE[2]] :: Int# -> Q' [GblId, Arity=1, Str=<S,U>, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [0] 83 0}] En.$w$ctoEnum = \ (ww_s3Kl :: Int#) -> case >=# ww_s3Kl 0# of { __DEFAULT -> En.$wlvl ww_s3Kl; 1# -> case <=# ww_s3Kl 1# of { __DEFAULT -> En.$wlvl ww_s3Kl; 1# -> tagToEnum# @ Q' ww_s3Kl } } -- RHS size: {terms: 6, types: 3, coercions: 0, joins: 0/0} En.$fEnumQ'_$ctoEnum [InlPrag=NOUSERINLINE[2]] :: Int -> Q' [GblId, Arity=1, Str=<S(S),1*U(U)>, Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=1,unsat_ok=True,boring_ok=False) Tmpl= \ (w_s3Ki [Occ=Once!] :: Int) -> case w_s3Ki of { I# ww1_s3Kl [Occ=Once] -> En.$w$ctoEnum ww1_s3Kl }}] En.$fEnumQ'_$ctoEnum = \ (w_s3Ki :: Int) -> case w_s3Ki of { I# ww1_s3Kl -> En.$w$ctoEnum ww1_s3Kl } }}} Two comparisons to find out one thing! Contrast this with something like {{{toEnum'}}}: {{{#!hs toEnum' = \ (ds_d3dp :: Int) -> case ds_d3dp of { I# ds1_d3dr -> case ds1_d3dr of ds2_X3dR { __DEFAULT -> En.$wlvl1 ds2_X3dR; 0# -> En.Foo'; 1# -> En.Bar' } } }}} Surely this seems better? But we don't even have to write out the constructors by hand in this case. {{{toEnum'''}}} actually produces the same code as {{{toEnum'}}}. I also wrote {{{toEnum''''}}} which I had some hopes for but actually runs the slowest. I'm unsure why. Seems simple enough: {{{#!hs toEnum'''' = \ (x_a2Sd :: Int) -> case x_a2Sd of { I# n_a2Se -> case leWord# (int2Word# n_a2Se) 1## of { __DEFAULT -> tagToEnum# @ Q' n_a2Se; 0# -> En.$wlvl4 n_a2Se } } }}} The point of this ticket is to consider whether it's not better to simply expand small number of constructors in a derived enumeration into a pattern match. In microbenchmark, {{{toEnum'}}} seems faster. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16364> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15936: Rethink Choice of Baseline Commit for Performance Tests
by GHC 25 Feb '19

25 Feb '19

#15936: Rethink Choice of Baseline Commit for Performance Tests -------------------------------------+------------------------------------- Reporter: davide | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.3 Component: Test Suite | Version: 8.6.2 Keywords: performance | Operating System: Unknown/Multiple tests git notes | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- = Intro = Currently we always use the previous commit when running performance tests. This works well in CI where we fully test each commit in sequence (and hence always have test results for the previous commit). Remember, test results are stored in git notes and are not by default shared between repositories (i.e. your local repo will only have performance results run locally on your machine). This is by design: we want to avoid comparing results form different machines. Unfortunately This is not so effective when testing locally. The programmer may have only run a subset of performance tests on the previous commit, and often have not run the tests at all (this is notably true after performing a rebase: the previous commit has changed). We need to rethink how we pick a baseline commit. = Goals = * In all cases, do something sensible. * Giving a warning if conditions are not idea. Provide clear and simple instructions on how to get to the ideal case. * Give control over the baseline commit to the programmer via command line options. * In general, performance tests should just work! No extra knowledge needed by the programmer. * If tests pass without warning now, then they should pass without warning later. = Proposed Solution = * Choose baseline commit * Provide command line arguments to set the baseline commit * If not baseline commit is provided use the "Ideal baseline commit". * If local test results for the baseline are available use those results. * Else if results from CI are available (without fetching), then use those results. * Else Warn user that there are no results available (tests trivially pass), then suggest fetching CI results (quick and easy, give full command, mention you may have to wait for CI to finish if the commit is recent) or running locally (more accurate, mention exact commit to checkout), or manually select a baseline commit. == Ideal baseline commit == * If there are no new changes: 0 ahead and 0 or more behind master. * Ideal baseline commit is the previous commit. * Else 1 or more ahead and 0 or more behind master. * Ideal baseline commit is `merge-base master HEAD` * Assume that the intention is to create a patch where all new commits will ultimately be squashed and placed on top of master. We only want to consider performance changes caused by the new commits, so we use the merge base instead of master HEAD (though these may be the same commit). = Open issues = If commits between HEAD and the baseline commit [https://ghc.haskell.org/trac/ghc/wiki/Performance/Tests#ExpectedPerformance… allow changes] in performance numbers, what should the behaviour be? What happens if this is merged? The commits will be squashed: this could affect the commit message and hence the allowed changes which is parsed from the commit messages. = Use cases = TODO This section is a WIP We generally will assume that the master branch corresponds to ghc's master branch (though may be slightly out of date). ||= Case =||= Details =||= Baseline =|| || 0 commits ahead of master || May be on master or branched off master with no new commits || previous commit || || CI pre-merge || || CI post-merge -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15936> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10170: Find versioned versions of LLVM tools
by GHC 25 Feb '19

25 Feb '19

#10170: Find versioned versions of LLVM tools -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 (LLVM) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Since it has become more widely know that the LLVM developers often make breaking changes to the IR language between releases, some Linu distributions (eg Debain and hence Ubuntu) have started doing multi- version LLVM installs. For instance on Debian, the llvm-3.6 programs are installed in `/usr/lib/llvm-3.6/bin` as `llc` and `opt`. I propose that the `configure.ac` and `aclocal.m4` configuration goop be modified to look for `llc` and `opt` in these versioned `/usr/lib/llvm-X.Y` locations. I'm also willing to do the hard yards on implementing this if people think its a good idea. This can be seen as a step along the way to more stringent LLVM versioning requirements. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10170> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #16329: Simplifier ticks exhausted when fusioning list literals
by GHC 25 Feb '19

25 Feb '19

#16329: Simplifier ticks exhausted when fusioning list literals -------------------------------------+------------------------------------- Reporter: autotaker | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- GHC 8.6.3 cannot compile the following code with `-O`. {{{#!hs module Main10(func) where import Control.Monad import Data.IORef func :: Int -> IO Int func n = do ref <- newIORef False let xs = map (n+) [1,2,3,4,5,6,7,8,9,10] step acc x = do when (x `mod` 2 == 0) $ modifyIORef' ref not pure (acc + 1) foldM step 0 xs }}} {{{ $ stack ghc -- --version The Glorious Glasgow Haskell Compilation System, version 8.6.3 $ stack ghc -- -O Main10.hs [1 of 1] Compiling Main10 ( Main10.hs, Main10.o ) Simplifier ticks exhausted When trying RuleFired +# To increase the limit, use -fsimpl-tick-factor=N (default 100). If you need to increase the limit substantially, please file a bug report and indicate the factor you needed. If GHC was unable to complete compilation even with a very large factor (a thousand or more), please consult the "Known bugs or infelicities" section in the Users Guide before filing a report. There are a few situations unlikely to occur in practical programs for which simplifier non-termination has been judged acceptable. To see detailed counts use -ddump-simpl-stats Total ticks: 14321 }}} GHC 8.4.4 and 8.2.2 also fail to compile this but GHC 8.0.2 can. I tried `-fsimpl-tick-factor=10000`, then GHC could compile the program but quite slow (it took some minutes). I measured the total ticks in the dumps from `-ddump-simpl-stats`, while changing the length of the constant literal (`[1,2,...,10]`) in the program between 3 to 10. Here is the result. Simplifier ticks seems to be exponential in the length of the constant list. {{{ # length, Total ticks 3, 706 4, 1286 5, 2982 6, 8026 7, 23114 8, 68334 9, 203950 10,610754 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16329> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #16087: TH tests fail in ext-interp way when ghc-stage2 is built using LLVM
by GHC 25 Feb '19

25 Feb '19

#16087: TH tests fail in ext-interp way when ghc-stage2 is built using LLVM -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 (LLVM) | 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: -------------------------------------+------------------------------------- This is a continuation of #15274. Currently the testsuite fails with around 40 test failures, all in `th/` in the `ext-interp` way when building GHC with `BUILD_FLAVOUR=perf-llvm`: {{{ Unexpected results from: TEST="ClosedFam1TH T10620 T10828 T11721_TH T11797 T12478_1 T12646 T13642 T14060 T15502 T15738 T15792 T15845 T1835 T3920 T4135 T4188 T5037 T5362 T7477 T8761 T8884 T8953 T9262 T9692 T9738 TH_RichKinds TH_RichKinds2 TH_Roles3 TH_TyInstWhere2 TH_implicitParams TH_reifyDecl1 TH_reifyExplicitForAllFams TH_reifyInstances TH_reifyMkName TH_repE2 TH_repGuard TH_repPrim TH_repPrim2 TH_repUnboxedTuples" SUMMARY for test run started at Sun Dec 23 06:01:39 2018 UTC 0:10:09 spent to go through 6745 total tests, which gave rise to 26266 test cases, of which 19055 were skipped 42 had missing libraries 7040 expected passes 89 expected failures 0 caused framework failures 0 caused framework warnings 0 unexpected passes 40 unexpected failures 0 unexpected stat failures Unexpected failures: th/TH_repE2.run TH_repE2 [exit code non-0] (ext- interp) th/TH_repPrim.run TH_repPrim [exit code non-0] (ext- interp) th/TH_repPrim2.run TH_repPrim2 [exit code non-0] (ext- interp) th/TH_repUnboxedTuples.run TH_repUnboxedTuples [exit code non-0] (ext-interp) th/TH_repGuard.run TH_repGuard [exit code non-0] (ext- interp) th/TH_reifyDecl1.run TH_reifyDecl1 [exit code non-0] (ext-interp) th/TH_reifyMkName.run TH_reifyMkName [exit code non-0] (ext-interp) th/TH_reifyInstances.run TH_reifyInstances [exit code non-0] (ext-interp) th/TH_reifyExplicitForAllFams.run TH_reifyExplicitForAllFams [exit code non-0] (ext-interp) th/T3920.run T3920 [exit code non-0] (ext-interp) th/T4188.run T4188 [exit code non-0] (ext-interp) th/T1835.run T1835 [exit code non-0] (ext-interp) th/T5037.run T5037 [exit code non-0] (ext-interp) th/T5362.run T5362 [exit code non-0] (ext-interp) th/TH_RichKinds.run TH_RichKinds [exit code non-0] (ext- interp) th/TH_RichKinds2.run TH_RichKinds2 [exit code non-0] (ext-interp) th/T4135.run T4135 [exit code non-0] (ext-interp) th/TH_TyInstWhere2.run TH_TyInstWhere2 [exit code non-0] (ext-interp) th/ClosedFam1TH.run ClosedFam1TH [exit code non-0] (ext- interp) th/TH_Roles3.run TH_Roles3 [exit code non-0] (ext- interp) th/T7477.run T7477 [exit code non-0] (ext-interp) th/T8884.run T8884 [exit code non-0] (ext-interp) th/T9262.run T9262 [exit code non-0] (ext-interp) th/T9692.run T9692 [exit code non-0] (ext-interp) th/T8953.run T8953 [exit code non-0] (ext-interp) th/T9738.run T9738 [exit code non-0] (ext-interp) th/T10620.run T10620 [exit code non-0] (ext- interp) th/T10828.run T10828 [exit code non-0] (ext- interp) th/T11721_TH.run T11721_TH [exit code non-0] (ext- interp) th/T11797.run T11797 [exit code non-0] (ext- interp) th/T8761.run T8761 [exit code non-0] (ext-interp) th/T12478_1.run T12478_1 [exit code non-0] (ext- interp) th/T12646.run T12646 [exit code non-0] (ext- interp) th/T13642.run T13642 [exit code non-0] (ext- interp) th/T14060.run T14060 [exit code non-0] (ext- interp) th/T15502.run T15502 [exit code non-0] (ext- interp) th/TH_implicitParams.run TH_implicitParams [exit code non-0] (ext-interp) th/T15738.run T15738 [exit code non-0] (ext- interp) th/T15792.run T15792 [exit code non-0] (ext- interp) th/T15845.run T15845 [exit code non-0] (ext- interp) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16087> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #16357: Add `oneShot` to the implementation of foldlM
by GHC 25 Feb '19

25 Feb '19

#16357: Add `oneShot` to the implementation of foldlM -------------------------------------+------------------------------------- Reporter: autotaker | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.9 libraries/base | 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 current (473632d7671619ee08a2a0025aa22bd4f79eca2d) implementation of `Data.Foldable.foldlM` is the like this {{{#!hs foldlM :: (Foldable t, Monad m) => (b -> a -> m b) -> b -> t a -> m b foldlM f z0 xs = foldr c return xs z0 -- See Note [List fusion and continuations in 'c'] where c x k z = f z x >>= k {-# INLINE c #-} }}} It generates an inefficient core for the following example. {{{#!hs f :: Int -> IO Int f = foldlM (\a b -> pure $! (a + b)) 0 (filter even [1..n]) }}} Generated core: {{{#!hs -- RHS size: {terms: 48, types: 22, coercions: 12, joins: 0/1} Main.$wf [InlPrag=NOUSERINLINE[2]] :: GHC.Prim.Int# -> GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, Int #) [GblId, Arity=2, Caf=NoCafRefs, Str=<L,U><L,U>, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [0 0] 216 30}] Main.$wf = \ (ww_s6TZ :: GHC.Prim.Int#) (w_s6TW :: GHC.Prim.State# GHC.Prim.RealWorld) -> case GHC.Prim.># 1# ww_s6TZ of { __DEFAULT -> letrec { go_a5un [Occ=LoopBreaker] :: GHC.Prim.Int# -> Int -> IO Int [LclId, Arity=1, Str=<L,U>, Unf=OtherCon []] go_a5un = \ (x_a5uo :: GHC.Prim.Int#) -> case GHC.Prim.remInt# x_a5uo 2# of { __DEFAULT -> case GHC.Prim.==# x_a5uo ww_s6TZ of { __DEFAULT -> go_a5un (GHC.Prim.+# x_a5uo 1#); 1# -> (GHC.Base.$fApplicativeIO4 @ Int) `cast` (<Int>_R ->_R Sym (GHC.Types.N:IO[0] <Int>_R) :: (Int -> GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, Int #)) ~R# (Int -> IO Int)) }; 0# -> Main.main_c @ Int (GHC.Types.I# x_a5uo) (case GHC.Prim.==# x_a5uo ww_s6TZ of { __DEFAULT -> go_a5un (GHC.Prim.+# x_a5uo 1#); 1# -> (GHC.Base.$fApplicativeIO4 @ Int) `cast` (<Int>_R ->_R Sym (GHC.Types.N:IO[0] <Int>_R) :: (Int -> GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, Int #)) ~R# (Int -> IO Int)) }) }; } in ((go_a5un 1# Main.main4) `cast` (GHC.Types.N:IO[0] <Int>_R :: IO Int ~R# (GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, Int #)))) w_s6TW; 1# -> (# w_s6TW, Main.main4 #) } }}} It seems that the main loop `go_a5un` is not eta-expanded. I think problem is that `oneShot` is missing in the definition of `foldlM`. When I changed the definition of `foldlM` as follows, {{{#!hs import GHC.Exts(oneShot) foldlM :: (Foldable t, Monad m) => (b -> a -> m b) -> b -> t a -> m b foldlM f z0 xs = foldr c return xs z0 -- See Note [List fusion and continuations in 'c'] where c x k = oneShot (\z -> f z x >>= k) {-# INLINE c #-} }}} Then, the main loop of the `wf` is eta-expaned as expected. {{{#!hs -- RHS size: {terms: 64, types: 46, coercions: 0, joins: 1/1} Main.$wf [InlPrag=NOUSERINLINE[2]] :: GHC.Prim.Int# -> GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, Int #) [GblId, Arity=2, Caf=NoCafRefs, Str=<L,U><L,U>, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [0 0] 136 30}] Main.$wf = \ (ww_s6Xc :: GHC.Prim.Int#) (w_s6X9 :: GHC.Prim.State# GHC.Prim.RealWorld) -> case GHC.Prim.># 1# ww_s6Xc of { __DEFAULT -> joinrec { go_s6WG [Occ=LoopBreaker] :: GHC.Prim.Int# -> Int -> GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, Int #) [LclId[JoinId(3)], Arity=3, Str=<L,U><L,U(U)><L,U>, Unf=OtherCon []] go_s6WG (x_a5xy :: GHC.Prim.Int#) (eta_B2 :: Int) (eta1_Xz :: GHC.Prim.State# GHC.Prim.RealWorld) = case GHC.Prim.remInt# x_a5xy 2# of { __DEFAULT -> case GHC.Prim.==# x_a5xy ww_s6Xc of { __DEFAULT -> jump go_s6WG (GHC.Prim.+# x_a5xy 1#) eta_B2 eta1_Xz; 1# -> (# eta1_Xz, eta_B2 #) }; 0# -> case eta_B2 of { GHC.Types.I# x1_a5t8 -> case GHC.Prim.==# x_a5xy ww_s6Xc of { __DEFAULT -> jump go_s6WG (GHC.Prim.+# x_a5xy 1#) (GHC.Types.I# (GHC.Prim.+# x1_a5t8 x_a5xy)) eta1_Xz; 1# -> (# eta1_Xz, GHC.Types.I# (GHC.Prim.+# x1_a5t8 x_a5xy) #) } } }; } in jump go_s6WG 1# Main.main4 w_s6X9; 1# -> (# w_s6X9, Main.main4 #) } }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16357> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #16130: GHC Panic on OS X: Data.Binary.Get.runGet: Invalid magic number "INPUT(-l"
by GHC 25 Feb '19

25 Feb '19

#16130: GHC Panic on OS X: Data.Binary.Get.runGet: Invalid magic number "INPUT(-l" ----------------------------------------+--------------------------------- Reporter: basvandijk | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- When building the latest `opencv-extra` library on OS X I'm getting a GHC panic. To reproduce git clone https://github.com/LumiGuide/haskell-opencv, make sure Nix is installed and execute: {{{ > nix-build -A haskellPackages.opencv-extra ... [11 of 11] Compiling OpenCV.Extra ( src/OpenCV/Extra.hs, dist/build/OpenCV/Extra.p_o ) ghc: panic! (the 'impossible' happened) (GHC version 8.6.3 for x86_64-apple-darwin): Data.Binary.Get.runGet at position 8: Invalid magic number "INPUT(-l" CallStack (from HasCallStack): error, called at libraries/binary/src/Data/Binary/Get.hs:351:5 in binary-0.8.6.0:Data.Binary.Get }}} The library builds successfully on Linux. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16130> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #16100: T11627a fails sometimes on CI
by GHC 24 Feb '19

24 Feb '19

#16100: T11627a fails sometimes on CI -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- See this build - https://gitlab.haskell.org/mpickering/ghc/-/jobs/6459 Causes this panic {{{ 81384 cd "profiling/should_run/T11627b.run" && ./T11627b +RTS -hd -RTS +RTS -i0 -RTS 81385 Wrong exit code for T11627a(prof_hc_hb)(expected 0 , actual 134 ) 81386 Stdout ( T11627a ): 81387 456574 81388 Stderr ( T11627a ): 81389 T11627a: internal error: LDV_recordDead: Failed to find counter for closure 0x42000bf558 81390 (GHC version 8.7.20181227 for x86_64_unknown_linux) 81391 Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16100> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #16185: Add an AnonArgFlag to FunTy
by GHC 24 Feb '19

24 Feb '19

#16185: Add an AnonArgFlag to FunTy -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- In Trac #15952 Richard and I agreed that it makes sense to add a flag to `FunTy` to distinguish `(->)` from `(=>)`. This ticket tracks progress. See [ticket:15952#comment:7] and [ticket:15952#comment:8]. Main changes: * Define `AnonArgFlag` in `Var`, alongside `ArgFlag` {{{ data AnonArgFlag = VisArg -- Used for (->): an ordinary non-dependent arrow -- The argument is visible in source code | InvisArg -- Used for (=>): a non-dependent predicate arrow -- The argument is invisible in source code }}} * `Type` looks like this {{{ data Type = ... | FFunTy -- ^ t1 -> t2 Very common, so an important special case -- FFunTy for "full function type"; see pattern synonym for FunTy { ft_af :: AnonArgFlag -- Is this (->) or (=>)? , ft_arg :: Type -- Argument type , ft_res :: Type } -- Resuult type }}} * Add a uni-directional pattern synonym for the old `FunTy` {{{ pattern FunTy :: Type -> Type -> Type pattern FunTy arg res <- FFunTy { ft_arg = arg, ft_res = res } }}} Everything else follows routinely. A huge win is that `isPredTy` vanishes almost completely. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16185> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #16361: Non-deterministic hs_try_putmvar00 failure on CI
by GHC 24 Feb '19

24 Feb '19

#16361: Non-deterministic hs_try_putmvar00 failure on CI -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.9 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: -------------------------------------+------------------------------------- {{{ Wrong exit code for hs_try_putmvar003(threaded1)(expected 0 , actual 139 ) *** unexpected failure for hs_try_putmvar003(threaded1) }}} A quick search suggests that 139 might mean a segfault (SIGSEGV). This is a non-deterministic CI failure that happened to me at least two times (Feb 12 and Feb 24), and forced me to restart the build job to get a green build status. Both times it was the `validate-x86_64-linux-fedora27` job, but on different runners (`ghc-ci-gce-x86_64-1` and `maurer.smart- cactus.org`). Note that another failure that seems to happen only on Fedora is #16350 – could it be a problem with the Fedora image? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16361> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3