June 2016 - ghc-tickets

[GHC] #12095: GHC and LLVM don't agree on what to do with byteSwap16#
by GHC 21 Jul '16

21 Jul '16

#12095: GHC and LLVM don't agree on what to do with byteSwap16# -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 (LLVM) | Keywords: codegen, llvm | 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: -------------------------------------+------------------------------------- Consider this test case (taken from [https://github.com/well-typed/binary- serialise-cbor/issues/67 here] and lightly modified to work on big/little endian machines): {{{#!hs {-# LANGUAGE BangPatterns #-} {-# LANGUAGE MagicHash #-} {-# LANGUAGE CPP #-} module Main ( main -- :: IO () ) where #include "ghcconfig.h" import GHC.Prim import GHC.Word data T = T !Addr# t :: T #ifndef WORDS_BIGENDIAN t = T "\xcf\xb1"# #else t = T "\xb1\xcf"# #endif grabWord16 :: T -> Word64 grabWord16 (T addr#) = W64# (byteSwap16# (indexWord16OffAddr# addr# 0#)) trip :: Int trip = fromIntegral (grabWord16 t) main :: IO () main = print trip }}} With GHC 7.10.3 using the NCG, the results given are correct: {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.10.3 $ ghc -Wall -fforce-recomp -O2 Issue67.hs && ./Issue67 [1 of 1] Compiling Main ( Issue67.hs, Issue67.o ) Linking Issue67 ... 53169 }}} This also is the same on GHC 8.0.1 using the NCG, on both PowerPC and AMD64 as well. This answer is correct: `53169` is `0xCFB1` in hex, so the `byteSwap16#` primitive correctly works to decode the swapped-endian number. However, the story is not the same with GHC 7.10.3+LLVM 3.5, or GHC 8.0.1+LLVM 3.7: {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.10.3 $ llc --version | head -2 LLVM (http://llvm.org/) LLVM version 3.5.2 $ ghc -Wall -fforce-recomp -O2 Issue67.hs -fllvm && ./Issue67 [1 of 1] Compiling Main ( Issue67.hs, Issue67.o ) Linking Issue67 ... -12367 }}} Note: {{{#!hs -12367 == (fromIntegral (53169 :: Word16) :: Int16) }}} The relevant snippet looks like this at the CMM level (GHC 7.10.3): {{{ ==================== Output Cmm ==================== [section "data" { Main.main2_closure: const Main.main2_info; const 0; const 0; const 0; }, section "readonly" { c3rq_str: I8[] [207,177] }, section "readonly" { c3rr_str: I8[] [207,177] }, Main.main2_entry() // [R1] { info_tbl: [(c3ru, label: Main.main2_info rep:HeapRep static { Thunk }), (c3rD, label: block_c3rD_info rep:StackRep [])] stack_info: arg_space: 8 updfr_space: Just 8 } {offset c3ru: ... c3ro: I64[Sp - 16] = stg_bh_upd_frame_info; I64[Sp - 8] = _c3rn::I64; (_c3rw::I64) = call MO_BSwap W16(%MO_UU_Conv_W16_W64(I16[c3rr_str])); I64[Sp - 24] = c3rD; R4 = GHC.Types.[]_closure+1; R3 = _c3rw::I64; R2 = 0; Sp = Sp - 24; call GHC.Show.$wshowSignedInt_info(R4, R3, R2) returns to c3rD, args: 8, res: 8, upd: 24; ... }}} Pre-optimized LLVM basic block: {{{ c3rB: %ln3sc = ptrtoint i8* @stg_bh_upd_frame_info to i64 %ln3sb = load i64** %Sp_Var %ln3sd = getelementptr inbounds i64* %ln3sb, i32 -2 store i64 %ln3sc, i64* %ln3sd, !tbaa !1 %ln3sf = load i64* %lc3rA %ln3se = load i64** %Sp_Var %ln3sg = getelementptr inbounds i64* %ln3se, i32 -1 store i64 %ln3sf, i64* %ln3sg, !tbaa !1 %ln3sh = ptrtoint %c3rE_str_struct* @c3rE_str$def to i64 %ln3si = inttoptr i64 %ln3sh to i16* %ln3sj = load i16* %ln3si, !tbaa !5 %ln3sk = zext i16 %ln3sj to i64 %ln3sl = trunc i64 %ln3sk to i16 %ln3sm = call ccc i16 (i16)* @llvm.bswap.i16( i16 %ln3sl ) %ln3sn = sext i16 %ln3sm to i64 store i64 %ln3sn, i64* %lc3rJ %ln3sp = ptrtoint void (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64)* @c3rQ_info$def to i64 %ln3so = load i64** %Sp_Var %ln3sq = getelementptr inbounds i64* %ln3so, i32 -3 store i64 %ln3sp, i64* %ln3sq, !tbaa !1 %ln3sr = ptrtoint i8* @ghczmprim_GHCziTypes_ZMZN_closure to i64 %ln3ss = add i64 %ln3sr, 1 store i64 %ln3ss, i64* %R4_Var %ln3st = load i64* %lc3rJ store i64 %ln3st, i64* %R3_Var store i64 0, i64* %R2_Var %ln3su = load i64** %Sp_Var %ln3sv = getelementptr inbounds i64* %ln3su, i32 -3 %ln3sw = ptrtoint i64* %ln3sv to i64 %ln3sx = inttoptr i64 %ln3sw to i64* store i64* %ln3sx, i64** %Sp_Var %ln3sy = bitcast i8* @base_GHCziShow_zdwshowSignedInt_info to void (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64)* }}} Post-optimized block (`opt --enable-tbaa=true -O2 out-llvm-orig.ll -o out- llvm.bc`): {{{ c3rB: ; preds = %c3rU %ln3s8 = ptrtoint i8* %ln3s7 to i64 %ln3sd = getelementptr inbounds i64* %Sp_Arg, i64 -2 store i64 ptrtoint (i8* @stg_bh_upd_frame_info to i64), i64* %ln3sd, align 8, !tbaa !5 %ln3sg = getelementptr inbounds i64* %Sp_Arg, i64 -1 store i64 %ln3s8, i64* %ln3sg, align 8, !tbaa !5 store i64 ptrtoint (void (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64)* @"c3rQ_info$def" to i64), i64* %ln3rZ, align 8, !tbaa !5 tail call cc10 void bitcast (i8* @base_GHCziShow_zdwshowSignedInt_info to void (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64)*)(i64* %Base_Arg, i64* %ln3rZ, i64* %Hp_Arg, i64 %R1_Arg, i64 0, i64 -12367, i64 add (i64 ptrtoint (i8* @ghczmprim_GHCziTypes_ZMZN_closure to i64), i64 1), i64 undef, i64 undef, i64 %SpLim_Arg) #0 ret void }}} Folds it right into a constant! I haven't spent time diagnosing this much further, yet. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12095> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12169: libraries/base/dist-install/build/HSbase-4.9.0.0.o: unknown symbol `stat'
by GHC 20 Jul '16

20 Jul '16

#12169: libraries/base/dist-install/build/HSbase-4.9.0.0.o: unknown symbol `stat' -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System (Linker) | 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 I make the following change: {{{ --- a/mk/flavours/validate.mk +++ b/mk/flavours/validate.mk @@ -2,7 +2,7 @@ SRC_HC_OPTS = -O0 -H64m SRC_HC_OPTS_STAGE1 = -fllvm-fill-undef-with-garbage # See Trac 11487 GhcStage1HcOpts = -O -DDEBUG GhcStage2HcOpts = -O -dcore-lint -GhcLibHcOpts = -O -dcore-lint +GhcLibHcOpts = -O0 -dcore-lint BUILD_PROF_LIBS = NO SplitObjs = NO HADDOCK_DOCS = YES }}} And push to Travis (`DYNAMIC_GHC_PROGRAMS = NO`, `GhcLibWays = v`), a [https://api.travis-ci.org/jobs/136229053/log.txt?deansi=true gazillion tests fail] with: {{{ libraries/base/dist-install/build/HSbase-4.9.0.0.o: unknown symbol `stat' }}} Originally reported in https://github.com/snowleopard/hadrian/issues/259. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12169> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11357: Regression when deriving Generic1 on poly-kinded data family
by GHC 20 Jul '16

20 Jul '16

#11357: Regression when deriving Generic1 on poly-kinded data family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.1 (CodeGen) | Keywords: Generics, | Operating System: Unknown/Multiple TypeInType | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- On GHC 7.10.3, the following code compiles: {{{#!hs {-# LANGUAGE DeriveGeneric #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeFamilies #-} module ProxyFam where import GHC.Generics (Generic1) data family ProxyFam (a :: k) data instance ProxyFam (a :: k) = ProxyCon deriving Generic1 }}} But on GHC 8.1, it fails: {{{ $ /opt/ghc/head/bin/ghc ProxyFam.hs [1 of 1] Compiling ProxyFam ( ProxyFam.hs, ProxyFam.o ) ProxyFam.hs:10:53: error: • Can't make a derived instance of ‘Generic1 ProxyFam’: ProxyFam must not be instantiated; try deriving `ProxyFam k a' instead • In the data instance declaration for ‘ProxyFam’ }}} I'm not sure what exactly is going on here, but I have a hunch. The `Generic1` typeclass is of kind `* -> *`, which means that in a `Generic1 ProxyFam` instance, the kind of `a` is instantiated to `*`. Curiously, though, the same error does ''not'' appear when `deriving Generic` for a normal datatype (e.g., `data ProxyFam (a :: k) = ProxyCon deriving Generic1`). Richard, I'm stuck as to how to fix this. I suspect this was triggered by `-XTypeInType`-related changes, specifically, [http://git.haskell.org/ghc.git/blobdiff/6e56ac58a6905197412d58e32792a04a63b… this change]: {{{#!diff diff --git a/compiler/typecheck/TcGenGenerics.hs b/compiler/typecheck/TcGenGenerics.hs index 2c5b80e..fb18517 100644 (file) --- a/compiler/typecheck/TcGenGenerics.hs +++ b/compiler/typecheck/TcGenGenerics.hs @@ -147,7 +146,7 @@ canDoGenerics tc tc_args -- -- Data family indices can be instantiated; the `tc_args` here are -- the representation tycon args - (if (all isTyVarTy (filterOut isKind tc_args)) + (if (all isTyVarTy (filterOutInvisibleTypes tc tc_args)) then IsValid else NotValid (tc_name <+> text "must not be instantiated;" <+> text "try deriving `" <> tc_name <+> tc_tys <> }}} What exactly does `filterOutInvisibleTypes` do? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11357> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #11094: Cost-center heap profiler should be able to emit samples to eventlog
by GHC 20 Jul '16

20 Jul '16

#11094: Cost-center heap profiler should be able to emit samples to eventlog -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Often when looking at heap profiles I find myself wishing that I had better tools for aligning the heap behavior to various events in the lifetime of my program. The eventlog provides a nice facility for marking these events, why not record heap profile samples in the eventlog as well? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11094> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #11348: Local open type families instances ignored during type checking
by GHC 20 Jul '16

20 Jul '16

#11348: Local open type families instances ignored during type checking -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeInType #-} import Data.Kind import Data.Proxy type family TrivialFamily t :: Type type instance TrivialFamily (t :: Type) = Bool data R where R :: Proxy Bool -> R type ProblemType t = 'R ('Proxy :: Proxy (TrivialFamily t)) }}} Compiling this program as-is, GHC rejects it! {{{#!sh error: • Expected kind ‘Proxy Bool’, but ‘'Proxy’ has kind ‘Proxy (TrivialFamily t)’ • In the first argument of ‘R’, namely ‘(Proxy :: Proxy (TrivialFamily t))’ In the type ‘R (Proxy :: Proxy (TrivialFamily t))’ In the type declaration for ‘ProblemType’ }}} But if we move `TrivialFamily` to another module and import it, GHC discovers that `TrivialFamily t = Bool` and the program is accepted. When compiling the rejected program (with the local family instance) I observe that the instance environments given by `FamInst.tcGetFamInstEnvs` contain no instances! The renamer processes the local instance, but no `FamInst` is created for it, and nothing enters the `TcGblEnv`'s family instance record. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11348> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23

[GHC] #12082: Typeable on RealWorld fails
by GHC 20 Jul '16

20 Jul '16

#12082: Typeable on RealWorld fails -------------------------------------+------------------------------------- Reporter: bgamari | 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: -------------------------------------+------------------------------------- This, {{{#!hs import GHC.Prim import Data.Typeable main = print $ typeRep (Proxy :: Proxy RealWorld) }}} fails with, {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.0.20160421 for x86_64-unknown-linux): tyConRep RealWorld Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12082> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #12271: Remove magic from type defaulting
by GHC 19 Jul '16

19 Jul '16

#12271: Remove magic from type defaulting -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The Prelude is great, but there are reasons people use drop-in replacements as well. In particular, I'm using [numeric-prelude] for its more mathematical numeric type class hierarchy. Unfortunately, I don't get type defaulting with their numeric type class replacements, which makes some operations a real pain to use. For example, GHC accepts the following: {{{ main :: IO () main = print $ 2^2 }}} but not {{{ {-# LANGUAGE NoImplicitPrelude, RebindableSyntax #-} import Algebra.Ring as Ring (C) import Algebra.ToInteger as ToInteger (C) import NumericPrelude hiding ((^)) (^) :: (Ring.C a, ToInteger.C i) => a -> i -> a x0 ^ y0 = undefined main :: IO () main = print $ 2^2 }}} (there are ambiguous types on both occurrences of `2`.) The [https://www.haskell.org/onlinereport/haskell2010/haskellch4.html#x10-790004… HaskellReport] seems to suggest that there is no way to use the `default` keyword to get type defaulting in this case. What I'm asking for is a programmatic way to set defaulting rules for non- standard numeric classes. In terms of implementation, my naive approach would be to remove `Num` from the process altogether: if we ever see a "integer-looking" literal and its type cannot be inferred, always default it to the `IntDefault` type (which could be the same as the current "automatic" default, or the value in the `default` tuple if present). I'm guessing that this approach has some flaws; perhaps someone can point them out? Barring that, I suppose we need a way to specify a `Num` replacement. In the case of numeric-prelude, it would be `Algebra.Additive.C`. An even more flexible approach would be to allow defaulting for constants with a specific constraint. (That's equivalent to specifying a default type for constants with the constraint `Num a => a` and a possibly different default for `Integral a => a`.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12271> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12238: Many tests fail when BuildFlavour == perf-llvm and DYNAMIC_GHC_PROGRAMS == NO
by GHC 19 Jul '16

19 Jul '16

#12238: Many tests fail when BuildFlavour == perf-llvm and DYNAMIC_GHC_PROGRAMS == NO --------------------------------------+--------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: #12230 Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------- Ticket spawned from #12240. Some time just before commit a33b498d5f648a576dac6d219115866f05721196 about 40 tests started failing with `BuildFlavour` set to `perf-llvm`. @simonmar suggested also testing with `DYNAMIC_GHC_PROGRAMS` set to `NO` which results on over 700 of the tests failing. @simonmar suggests something is broken in the LLVM backend or in the linker. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12238> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12132: Type representations missing for promoted boxed tuples
by GHC 19 Jul '16

19 Jul '16

#12132: Type representations missing for promoted boxed tuples -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.0.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: -------------------------------------+------------------------------------- This is a continuation of #11120. It seems there is something odd happening with type representations for boxed tuples, {{{ $ inplace/bin/ghc-stage2 --interactive GHCi, version 8.1.20160528: http://www.haskell.org/ghc/ :? for help Prelude> :set -XDataKinds Prelude> :m + Data.Typeable Data.Proxy Prelude Data.Typeable Data.Proxy> typeOf (Proxy :: Proxy (Int,Int)) Proxy * (Int,Int) Prelude Data.Typeable Data.Proxy> typeOf (Proxy :: Proxy '(Int,Int)) GHC error in desugarer lookup in Ghci2: Can't find interface-file declaration for variable $tc'(,) Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20160528 for x86_64-unknown-linux): initDs IOEnv failure Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Prelude Data.Typeable Data.Proxy> }}} This is odd since the `$tc'(,)` binding is present in the interface file for `GHC.Tuple`, {{{ $ inplace/bin/ghc-stage2 --show-iface libraries/ghc-prim/dist- install/build/GHC/Tuple.dyn_hi |less ... 14e44400752f4580e52ed2a760b9633f $tc'(,) :: TyCon {- HasNoCafRefs, Strictness: m, Unfolding: (TyCon 14407099369839560749## 10712746223293009168## $trModule $tc'(,)1) -} 543be63d698612591d2e75b0b60ad643 $tc'(,)1 :: TrName {- HasNoCafRefs, Strictness: m1, Unfolding: (TrNameS "'(,)"#) -} 469b4ffe716da12a5be1f5ab03864791 $tc'(,,) :: TyCon {- HasNoCafRefs, Strictness: m, Unfolding: (TyCon 3540448346642256323## 9150387332266490903## $trModule $tc'(,,)1) -} ... }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12132> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #11717: Way to dump cmm only once
by GHC 18 Jul '16

18 Jul '16

#11717: Way to dump cmm only once -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.1 (CodeGen) | Keywords: newcomer | 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 way to dump Cmm output is `-ddump-cmm`, but that dumps Cmm repeatedly, of every stage, similar to `-ddump-verbose-core2core`. This is often confusing. I propose that `-ddump-cmm` dumps only the initial Cmm code, that the flag `-ddump-simpl-cmm` dumps the final Cmm code, and that `-ddump-verbose-cmm` dumps every stage. Shoudn’t be hard to do for a newcomer. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11717> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6