- ghc-tickets - Haskell.org

[GHC] #13941: STG linter's type equality can loop
by GHC 28 Nov '17

28 Nov '17

#13941: STG linter's type equality can loop -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.2 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: -------------------------------------+------------------------------------- `stgEqType` will currently loop when given the following, {{{#!hs stgEqType (a -> IO ()) (a -> IO ()) }}} The problem is that the `(->)` tycon now takes runtime rep arguments. To see why, let's look at the (paraphrased) implementation, {{{#!hs stgEqType orig_ty1 orig_ty2 = gos (typePrimRep orig_ty1) (typePrimRep orig_ty2) where gos :: [PrimRep] -> [PrimRep] -> Bool gos [_] [_] = go orig_ty1 orig_ty2 gos reps1 reps2 = reps1 == reps2 go :: UnaryType -> UnaryType -> Bool go ty1 ty2 | Just (tc1, tc_args1) <- splitTyConApp_maybe ty1 , Just (tc2, tc_args2) <- splitTyConApp_maybe ty2 , let res = if tc1 == tc2 then equalLength tc_args1 tc_args2 && and (zipWith (gos `on` typePrimRep) tc_args1 tc_args2) else (isFamilyTyCon tc1 || isFamilyTyCon tc2) = res | otherwise = True -- Conservatively say "fine". }}} Our example will begin by looking at the `gos (typePrimRep orig_ty1) (typePrimRep orig_ty2)` and, seeing that the `orig_ty`s are unary, enter `go`. We will then split the applications such that, {{{ tc1, tc2 = (->) tc_args1, tc_args2 = ['LiftedPtrRep, 'LiftedPtrRep, a, IO ()] }}} Seeing that the tycons are equal, we will enter `gos` on each of the `tc_args`. Of course, one would think that `typePrimRep 'LiftedPtrRep` should throw an error, but because `gos` only forces the spine of the list, that error doesn't get thrown. Instead we incorrectly conclude that `'LiftedPtrRep` is a unary type and recurse into `go orig_ty1 orig_ty2`, thus looping. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13941> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #14117: stg-lint fails on unlifted-type join point binding
by GHC 28 Nov '17

28 Nov '17

#14117: stg-lint fails on unlifted-type join point binding -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- While validating GHC with `BuildFlavour=devel2` and `-dstg-lint` I found that the linter chokes when it finds a join point of unlifted type (like this one from the `Binary` module), {{{ ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.3.20170815 for x86_64-unknown-linux): *** Stg Lint ErrMsgs: in Stg2Stg *** <no location info>: warning: [RHS of $j_sDSL :: (# State# RealWorld, () #)] Let(rec) binder ‘$j_sDSL’ has unlifted type ‘(# State# RealWorld, () #)’ RHS: \r [] src<compiler/utils/Binary.hs:516:9-17> src<compiler/utils/Binary.hs:(516,21)-(518,26)> src<compiler/utils/Binary.hs:260:1-45> src<compiler/utils/Binary.hs:(239,1)-(246,34)> case readIntArray# [ww_sDSF 0# w1_sDSJ] of { ... }}} If I'm not mistaken there is no problem with join points having unlifted type (see `Note [CoreSyn let/app invariant]`). We just need to update the STG linter appropriately. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14117> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14118: stg2stg passes appear to produce invalid STG
by GHC 28 Nov '17

28 Nov '17

#14118: stg2stg passes appear to produce invalid STG -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- While building with GHC with `-dstg-lint -g3 -O0` (after fixing #14116 and #14117) I encountered a rather peculiar error, {{{ "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O -H64m -Wall -this-unit-id integer-gmp-1.0.1.0 -hide-all-packages -i -ilibraries/integer-gmp/src/ -ilibraries/integer-gmp/dist-install/build -Ilibraries/integer-gmp/dist-install/build -ilibraries/integer-gmp/dist- install/build/./autogen -Ilibraries/integer-gmp/dist- install/build/./autogen -Ilibraries/integer-gmp/include -optP-include -optPlibrari es/integer-gmp/dist-install/build/./autogen/cabal_macros.h -package-id ghc-prim-0.5.1.0 -this-unit-id integer-gmp -Wall -XHaskell2010 -O -dcore- lint -g3 -ddump-to-file -ddump-stg -dcore-lint -dstg-lint -dcmm-lin t -no-user-package-db -rtsopts -Wno-deprecated-flags -Wnoncanonical- monad-instances -odir libraries/integer-gmp/dist-install/build -hidir libraries/integer-gmp/dist-install/build -stubdir libraries/intege r-gmp/dist-install/build -dynamic-too -c libraries/integer- gmp/src//GHC/Integer/Type.hs -o libraries/integer-gmp/dist- install/build/GHC/Integer/Type.o -dyno libraries/integer-gmp/dist- install/build/GHC/Integer /Type.dyn_o ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.3.20170815 for x86_64-unknown-linux): *** Stg Lint ErrMsgs: in Stg2Stg *** <no location info>: warning: [in body of lambda with binders m0_scBy :: State# s_a2Em -> State# s_a2Em, s1_scBz :: State# s_a2Em] s'_scBA is out of scope <no location info>: warning: [in body of lambda with binders wild1_sdUv :: Int#] qr_sdUp is out of scope }}} Looking at the STG it appears that these warnings are absolutely correct, {{{#!hs svoid [InlPrag=INLINE (sat-args=1)] :: forall s. (State# s -> State# s) -> S s () [GblId, Arity=2, Caf=NoCafRefs, Str=<C(S),1*C1(U)><S,U>, Unf=OtherCon []] = \r [m0_scBy s1_scBz] src<libraries/integer-gmp/src/GHC/Integer/Type.hs:1957:1-48> case m0_scBy s1_scBz of s'_scBA { __DEFAULT -> src<libraries/integer- gmp/src/GHC/Integer/Type.hs:1957:37-48> (#,#) [s'_scBA ()]; }; }}} This is quite strange given that `s'_scBA` is clearly in scope, being bound as the case binder. We had the following from Core Prep, {{{#!hs -- RHS size: {terms: 10, types: 17, coercions: 0, joins: 0/0} GHC.Integer.Type.svoid [InlPrag=INLINE (sat-args=1)] :: forall s. (GHC.Prim.State# s -> GHC.Prim.State# s) -> GHC.Integer.Type.S s () [GblId, Arity=2, Caf=NoCafRefs, Str=<C(S),1*C1(U)><S,U>, Unf=OtherCon []] GHC.Integer.Type.svoid = \ (@ s_a2Em) (m0_scBy [Occ=Once!] :: GHC.Prim.State# s_a2Em -> GHC.Prim.State# s_a2Em) (s1_scBz [Occ=Once] :: GHC.Prim.State# s_a2Em) -> src<libraries/integer-gmp/src/GHC/Integer/Type.hs:1957:1-48> case m0_scBy s1_scBz of s'_scBA { __DEFAULT -> src<libraries/integer-gmp/src/GHC/Integer/Type.hs:1957:37-48> (# s'_scBA, GHC.Tuple.() #) } }}} The reason the linter fails here is due to the following logic in `lintStgExpr`, {{{#!hs in_scope <- MaybeT $ liftM Just $ case alts_type of AlgAlt tc -> check_bndr (tyConPrimRep tc) >> return True PrimAlt rep -> check_bndr [rep] >> return True MultiValAlt _ -> return False -- Binder is always dead in this case PolyAlt -> return True MaybeT $ addInScopeVars [bndr | in_scope] $ lintStgAlts alts scrut_ty }}} In the `svoid` case above we hit `MultiValAlt` path, which causes us to ignore the case binder. The fact that we hit `MultiValAlt` at all is a bit surprising given that the result is not an unboxed sum or tuple. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14118> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #14521: Infinite loop at runtime when a given function is not marked INLINE
by GHC 28 Nov '17

28 Nov '17

#14521: Infinite loop at runtime when a given function is not marked INLINE -------------------------------------+------------------------------------- Reporter: OlivierSohn | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: MacOS X Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hello, in https://github.com/OlivierSohn/hamazed/issues/1 I describe the following issue: When compiling on OSX with optimizations (`stack clean && stack build` with resolver `lts-9.12` (ghc 8.0.2)), the program loops infinitely (400% CPU, and execution is blocked) when an animation is triggered, if the function `Animation.animate'` is not inlined. The bug is visible at this commit : https://github.com/OlivierSohn/hamazed/commit/9f25223ef0502f91cd9633654bdb1… (to reproduce, shoot at a number in the game) The fix is the commit that follows : https://github.com/OlivierSohn/hamazed/commit/597619bb14974d2bbacfb284a9e27… stack version: `1.3.2, Git revision 3f675146590da4f3edf768b89355f798229da2a5 (4395 commits) x86_64 hpack-0.15.0` Could this be a compiler bug? The code is available at https://github.com/OlivierSohn/hamazed I could try to create another program that reproduces the issue more easily (without having to play the game), just let me know if you need it. Thank you, Olivier -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14521> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23

[GHC] #14120: stg-lint is hopelessly broken
by GHC 28 Nov '17

28 Nov '17

#14120: stg-lint is hopelessly broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Today I spent a fair amount of time looking at the STG linter, having encountered a number of times in the past six months where I noticed it broke. While I thought fixing it would just be a few small tweaks, it seems that with every issue I fix another bug rears its ugly head. So far I have encountered and fixed, * #14116 * #14117 * #14118 The solutions to each of these has seemed rather obvious. However, now I seem to have run into a bit of a more fundamental issue: Consider this excerpt extracted from `Foreign.Storable`, {{{#!hs {-# LANGUAGE BangPatterns #-} module Hi where import GHC.Word import GHC.Ptr import GHC.Base import GHC.Num import Data.Bits import GHC.Fingerprint.Type peekFingerprint :: Ptr Fingerprint -> IO Fingerprint peekFingerprint p0 = do let peekW64 :: Ptr Word8 -> Int -> Word64 -> IO Word64 peekW64 _ 0 !i = return i peekW64 !p !n !i = peekW64 (p `plusPtr` 1) (n-1) (i `shiftL` 8) high <- peekW64 (castPtr p0) 8 0 low <- peekW64 (castPtr p0 `plusPtr` 8) 8 0 return (Fingerprint high low) }}} In particular notice the `castPtr` application. This triggers the STG linter with, {{{ ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.3.20170815 for x86_64-unknown-linux): *** Stg Lint ErrMsgs: in Stg2Stg *** <no location info>: warning: [in body of lambda with binders p0_s2zB :: Ptr Fingerprint, eta_s2zC :: State# RealWorld] In a function application, function type doesn't match arg types: Function type: Ptr Word8 -> Int# -> Word# -> State# RealWorld -> (# State# RealWorld, Word64 #) Arg types: Ptr Fingerprint Int# Word# State# RealWorld Expression: $wpeekW64 p0_s2zB 8# 0## eta_s2zC }}} This is because by the time we are in Core Prep the `castPtr` is turned into a cast, which we discard in STG. Consequently, it seems that the comment attached to `stgEqType`, {{{#!hs stgEqType :: Type -> Type -> Bool -- Compare types, but crudely because we have discarded -- both casts and type applications, so types might look -- different but be the same. So reply "True" if in doubt. -- "False" means that the types are definitely different. -- -- Fundamentally this is a losing battle because of unsafeCoerce }}} is quite an understatement. Rather, there are exceedingly few cases where we can catch any type errors in STG. I think the only case which we can reliably catch is that of two types with explicitly different primreps. It's not clear what we can/should do about this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14120> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #14116: Core lint error while compiling master
by GHC 28 Nov '17

28 Nov '17

#14116: Core lint error while compiling master -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- While compiling e054c5f06451def4437d9d770ae156f034796c59 with the following `build.mk`, {{{ BuildFlavour = devel2 include mk/flavours/$(BuildFlavour).mk GhcStage2HcOpts += -eventlog GhcStage1HcOpts += -eventlog GhcLibHcOpts += -g3 -ddump-to-file -ddump-stg -dcore-lint -dstg-lint -dcmm-lint GhcRtsHcOpts += -g3 GhcStage2HcOpts += -g3 -ddump-to-file -ddump-stg -dcore-lint -dstg-lint -dcmm-lint }}} I encountered this Core lint failure while compiling `PprColour`, {{{ stgEqType: unequal PprColour [Char] ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.3.20170815 for x86_64-unknown-linux): *** Stg Lint ErrMsgs: in Stg2Stg *** compiler/utils/PprColour.hs:62:1: warning: [RHS of defaultScheme :: Scheme] In a RHS constructor application, con type doesn't match arg types: Constructor type: PprColour -> PprColour -> PprColour -> PprColour -> PprColour -> PprColour -> Scheme Arg types: [Char] PprColour String String String String *** Offending Program *** ... }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14116> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14527: Warn on recursive bindings
by GHC 28 Nov '17

28 Nov '17

#14527: Warn on recursive bindings -------------------------------------+------------------------------------- Reporter: chrisdone | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- When you accidentally write something like `let x = .. x ...` it can take hours to realize where you made your mistake. This hits me once in a while, and my colleagues often. I'd propose e.g. `-Wrecursive-bindings` that says: {{{ warning: [-Wrecursive-bindings] Recursive binding for `x` in let x = length x }}} This applies to `let`, `where` and top-level pattern bindings. I believe that in practice, I only actually use real recursive bindings once in a while. So I might be bold enough to encourage enabling it in `-Wall` for a future major GHC release. With the compromise that if you have the warning enabled but in one specific place, you want a recursive binding, you can use the `~` tilde to say "I really mean it", e.g. {{{let ~ones = 1 : ones}}} That seems like a nice balance to say "I know what I'm doing in this case". So the warning could be more helpful, like: {{{ warning: [-Wrecursive-bindings] Recursive binding for `ones` in let ones = length ones If intentional, use the tilde marker on the name like this: let ~ones = length ones }}} In Intero if I were to implement a prototype of this check, I'd probably do this, after renaming: 1. Use SYB to collect all variable bindings from the pattern. 2. Use SYB to listify all mentions of any of these variables in the RHS and any guards or where clauses. If the list is non-empty, then trigger the error. A transformation function {{{[Name] -> Pat -> Pat}}} would provide the AST with the offending name(s) tilded as {{{~x}}} for use in the error message. If there's general agreement, I could implement this change. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14527> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #14459: `make sdist-ghc` broken
by GHC 28 Nov '17

28 Nov '17

#14459: `make sdist-ghc` broken -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Build System | Version: 8.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: -------------------------------------+------------------------------------- I noticed this because it resulted in the PPA builds of GHC HEAD failing; I was able to hunt this down to bdd2d2862e248948efafa8ba4219e94825ddf21a which updated `libraries/Cabal`; Basically, the following invocation (where `ghc`/`alex`/`happy`/etc. can only be found in `/opt/ghc-stage0-toolchain/bin`, and nowhere else; so this relies on `configure` to capture their absolute locations; however, this is not what causes the failure below) {{{#!bash ./boot PATH=/opt/ghc-stage0-toolchain/bin:$PATH ./configure make sdist-ghc }}} results in {{{ ... test ! -d testsuite || make -C testsuite distclean "rm" -rf sdistprep/ghc/ghc-8.3.20171109/libraries/tarballs/ "rm" -rf sdistprep/ghc/ghc-8.3.20171109/libraries/stamp/ "rm" -rf sdistprep/ghc/ghc-8.3.20171109/compiler/stage[123] "rm" -f sdistprep/ghc/ghc-8.3.20171109/mk/build.mk for i in parallel random primitive vector dph; do rm -rf sdistprep/ghc/ghc-8.3.20171109/libraries/$i/; done cd sdistprep/ghc/ghc-8.3.20171109 && "/usr/bin/find" mk rules docs distrib bindisttest libffi includes utils docs rts compiler ghc driver libraries libffi-tarballs iserv $ -name .git -o -name "autom4te*" -o -name "*~" -o -name "\#*" -o -name ".\#*" -o -name "log" -o -name "*-SAVE" -o -name "*.orig" -o -name "*.rej" $ -print | "xargs" "rm" -rf "cp" compiler/stage2/build/CmmLex.hs sdistprep/ghc/ghc-8.3.20171109/compiler/cmm mv sdistprep/ghc/ghc-8.3.20171109/compiler/cmm/CmmLex.x sdistprep/ghc/ghc-8.3.20171109/compiler/cmm/CmmLex.x.source "/opt/ghc-stage0-toolchain/bin/happy" -agc --strict compiler/cmm/CmmParse.y -o compiler/stage2/build/CmmParse.hs "cp" compiler/stage2/build/CmmParse.hs sdistprep/ghc/ghc-8.3.20171109/compiler/cmm mv sdistprep/ghc/ghc-8.3.20171109/compiler/cmm/CmmParse.y sdistprep/ghc/ghc-8.3.20171109/compiler/cmm/CmmParse.y.source "/opt/ghc-stage0-toolchain/bin/alex" -g --latin1 compiler/parser/Lexer.x -o compiler/stage2/build/Lexer.hs "cp" compiler/stage2/build/Lexer.hs sdistprep/ghc/ghc-8.3.20171109/compiler/parser mv sdistprep/ghc/ghc-8.3.20171109/compiler/parser/Lexer.x sdistprep/ghc/ghc-8.3.20171109/compiler/parser/Lexer.x.source "/opt/ghc-stage0-toolchain/bin/happy" -agc --strict compiler/parser/Parser.y -o compiler/stage2/build/Parser.hs "cp" compiler/stage2/build/Parser.hs sdistprep/ghc/ghc-8.3.20171109/compiler/parser mv sdistprep/ghc/ghc-8.3.20171109/compiler/parser/Parser.y sdistprep/ghc/ghc-8.3.20171109/compiler/parser/Parser.y.source "inplace/bin/mkdirhier" utils/hpc/dist-install/build//. "/opt/ghc-stage0-toolchain/bin/happy" -agc --strict utils/hpc/./HpcParser.y -o utils/hpc/dist-install/build/HpcParser.hs unused terminals: 1 "cp" utils/hpc/dist-install/build/HpcParser.hs sdistprep/ghc/ghc-8.3.20171109/utils/hpc/ mv sdistprep/ghc/ghc-8.3.20171109/utils/hpc//HpcParser.y sdistprep/ghc/ghc-8.3.20171109/utils/hpc//HpcParser.y.source "inplace/bin/mkdirhier" utils/genprimopcode/dist/build//. "/opt/ghc-stage0-toolchain/bin/alex" -g utils/genprimopcode/./Lexer.x -o utils/genprimopcode/dist/build/Lexer.hs "cp" utils/genprimopcode/dist/build/Lexer.hs sdistprep/ghc/ghc-8.3.20171109/utils/genprimopcode/ mv sdistprep/ghc/ghc-8.3.20171109/utils/genprimopcode//Lexer.x sdistprep/ghc/ghc-8.3.20171109/utils/genprimopcode//Lexer.x.source "/opt/ghc-stage0-toolchain/bin/happy" -agc --strict utils/genprimopcode/./Parser.y -o utils/genprimopcode/dist/build/Parser.hs "cp" utils/genprimopcode/dist/build/Parser.hs sdistprep/ghc/ghc-8.3.20171109/utils/genprimopcode/ mv sdistprep/ghc/ghc-8.3.20171109/utils/genprimopcode//Parser.y sdistprep/ghc/ghc-8.3.20171109/utils/genprimopcode//Parser.y.source make[1]: *** No rule to make target 'libraries/Cabal/Cabal/dist- install/build/Distribution/Parsec/Lexer.hs', needed by 'sdist_libraries/Cabal/Cabal_dist-install_Lexer'. Stop. Makefile:161: recipe for target 'sdist-ghc' failed make: *** [sdist-ghc] Error 2 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14459> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14516: getGCStats was broken in 8.2
by GHC 28 Nov '17

28 Nov '17

#14516: getGCStats was broken in 8.2 -------------------------------------+------------------------------------- Reporter: chrisdone | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.2.1 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 {{{getGCStats}}} function from {{{GHC.Stats}}} defined [http://hackage.haskell.org/package/base-4.10.0.0/docs/GHC-Stats.html#g:2 here] expects the {{{numGCs}}} field to be an {{{Int64}}}, but in the new {{{RTSStats}}} API, it's a {{{Word32}}}, so the function inside is no longer correct: {{{ getGCStats = do ... allocaBytes ((232)) $ \p -> do {-# LINE 284 "GHC/Stats.hsc" #-} getRTSStats_ p bytesAllocated <- ((\hsc_ptr -> peekByteOff hsc_ptr 8)) p {-# LINE 286 "GHC/Stats.hsc" #-} numGcs <- ((\hsc_ptr -> peekByteOff hsc_ptr 0)) p {-# LINE 287 "GHC/Stats.hsc" #-} numByteUsageSamples <- ((\hsc_ptr -> peekByteOff hsc_ptr 4)) p }}} The {{{numGcs}}} line peeks off 8 bytes instead of 4, and so it leads to packages like my {{{weigh}}} package claiming that you've done "4,294,967,299" garbage collections. I've updated {{{weigh}}} to use the new API with some CPP {{{#if}}}'s. Given that the new API changes pretty much everything, both names and types (it took a couple hours to make weigh support the old and the new one), and that the old "compatibility" API is returning bad results, honestly I wouldn't have minded if the old API was just removed in 8.2. Leaving it up to you whether this should be fixed in an 8.2.3 bugfix release or just leave it to be removed in 8.4. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14516> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #2401: aborting an STM transaction should throw an exception
by GHC 28 Nov '17

28 Nov '17

#2401: aborting an STM transaction should throw an exception -------------------------------------+------------------------------------- Reporter: sclv | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Runtime System | Version: 6.8.3 Resolution: | 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 akio): * cc: akio (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2401#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0