May 2016 - ghc-tickets

[GHC] #11704: Word and Int literals not correctly truncated when cross compiling 64 -> 32 bit
by GHC 18 May '16

18 May '16

#11704: Word and Int literals not correctly truncated when cross compiling 64 -> 32 bit -------------------------------------+------------------------------------- Reporter: luite | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 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 does not take the target word size into account for some of the rules in `PrelRules`: {{{#!hs rule_convert "integerToWord" integerToWordName mkWordLitWord, rule_convert "integerToInt" integerToIntName mkIntLitInt, }}} The relevant code from `CoreSyn`: {{{#!hs -- | Create a machine word literal expression of type @Word#@ from a @Word@. -- If you want an expression of type @Word@ use 'MkCore.mkWordExpr' mkWordLitWord :: DynFlags -> Word -> Expr b mkWordLit dflags w = Lit (mkMachWord dflags w) mkWordLitWord dflags w = Lit (mkMachWord dflags (toInteger w)) -- | Create a machine integer literal expression of type @Int#@ from an @Int@. -- If you want an expression of type @Int@ use 'MkCore.mkIntExpr' mkIntLitInt :: DynFlags -> Int -> Expr b mkIntLitInt dflags n = Lit (mkMachInt dflags (toInteger n)) }}} If a literal is bigger than the target word size, these rules can lead to loss of truncation when optimizing a `fromInteger` / `toInteger` pair. This makes testcase `codeGen/5785.hs` fail when compiled with optimization with GHCJS on 64 bit GHC. It probably also affects targeting 64 platforms with 32 bit compilers, where literals would be truncated too much, but I don't have a way of testing that. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11704> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12078: ghc-boot-th package reveals issue with build system's treatment of transitive dependencies
by GHC 17 May '16

17 May '16

#12078: ghc-boot-th package reveals issue with build system's treatment of transitive dependencies -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | 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: -------------------------------------+------------------------------------- The `ghc-boot-th` introduced in the resolution of #12052 seems to have uncovered a bug in the build system's treatment of transitive dependencies. Namely, it seems to be possible for the build system to attempt to link `ghc-pkg` before `libghc-boot-th` has been produced. This is odd since `ghc-pkg` has a dependency on `ghc-boot`, which in turn has a dependency on `ghc-boot-th`. In the interest of moving the 8.0.1 release along I'm going to work around this for the time being by adding -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12078> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 17 May '16

17 May '16

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: 11362 | Blocking: Related Tickets: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, | Phab:D1268, Phab:D1360, Phab:D1373, Wiki Page: | Phab:D1396, Phab:D1457, Phab:D1468, DeterministicBuilds | Phab:D1487, Phab:D1504, Phab:D1508 -------------------------------------+------------------------------------- Comment (by nh2): I just want to leave a quick note here saying that it's great to see this stream of improvements on deterministic compilation. It's super appreciated that you invest your time into this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:171> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 17 May '16

17 May '16

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: 11362 | Blocking: Related Tickets: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, | Phab:D1268, Phab:D1360, Phab:D1373, Wiki Page: | Phab:D1396, Phab:D1457, Phab:D1468, DeterministicBuilds | Phab:D1487, Phab:D1504, Phab:D1508 -------------------------------------+------------------------------------- Comment (by Bartosz Nitka <niteria@…>): In [changeset:"dc94914eb0da985a2f006e2bd390fa1fdbafcc33/ghc" dc94914e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="dc94914eb0da985a2f006e2bd390fa1fdbafcc33" Document determinism in shortOutIndirections varEnvElts didn't introduce nondeterminism here. This makes it obvious that it could and explains why it doesn't. Test Plan: ./validate Reviewers: bgamari, simonmar, austin, simonpj Reviewed By: simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2228 GHC Trac Issues: #4012 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:170> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8207: Show instance for Language in DynFlags
by GHC 17 May '16

17 May '16

#8207: Show instance for Language in DynFlags ------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: GHC API | 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: | ------------------------------------+------------------------------------- I feel that the GHC API could benefit from a Show instance for Language in DynFlags.hs. Currently, if we want to display the language being used we have to do something like {{{ foo inf = case hmi_language inf of Nothing -> Nothing Just Haskell98 -> Just "Haskell98" Just Haskell2010 -> Just "Haskell2010" }}} This is pretty much just the Show instance (over Maybe) and Haskell can derive it for us automatically: we just need to change `deriving Enum` to `deriving (Enum, Show)`. The above solution is not the most robust ever as if this data type is ever changed, this starts to form an incomplete pattern. If we have a catch all `_`, GHC complains about overlapping patterns. Easily solved with `show <$> hmi_language inf`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8207> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #2260: Non-ideal error message for misplaced LANGUAGE pragma
by GHC 16 May '16

16 May '16

#2260: Non-ideal error message for misplaced LANGUAGE pragma -------------------------------------+------------------------------------- Reporter: TomMD | Owner: Type: bug | Status: closed Priority: lowest | Milestone: Component: Compiler | Version: 6.8.2 (Parser) | Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #12002 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #12002 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2260#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12054: PowerPC: Unsupported relocation against x0
by GHC 16 May '16

16 May '16

#12054: PowerPC: Unsupported relocation against x0 -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.1 (CodeGen) | Keywords: | Operating System: Unknown/Multiple Architecture: powerpc | Type of failure: Building GHC | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- On PowerPC/Linux, the `perf` build is failing for the file `compiler/cmm/PprC.hs` with a large number of errors like: {{{ tmp/ghc29102_0/ghc_3.s:310927:0: error: Error: unsupported relocation against x0 tmp/ghc29102_0/ghc_3.s:310938:0: error: Error: unsupported relocation against x0 tmp/ghc29102_0/ghc_3.s:310959:0: error: Error: unsupported relocation against x0 }}} All of the above error lines are of the form: {{{ stwu x0, 1 , 13 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12054> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #12074: RULE too complicated to desugar
by GHC 16 May '16

16 May '16

#12074: RULE too complicated to desugar -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Another example of specialization failing. Unlike #12068, this example doesn't use constraint/type synonyms. {{{ {-# LANGUAGE FlexibleContexts #-} data Bar a instance (Num a) => Num (Bar a) data Foo q instance (C1 q) => Num (Foo q) class C1 a class (Num r, Num (Bar r)) => C2 r instance (C1 q) => C2 (Foo q) instance (C2 r) => C2 (Bar r) {-# SPECIALIZE f :: (C1 q) => Foo q -> Foo q #-} f :: (C2 r, C2 (Bar r)) => r -> r f = undefined }}} Warning: {{{ RULE left-hand side too complicated to desugar Optimised lhs: let { $dNum_aFp :: Num (Foo q) [LclId, Str=DmdType] $dNum_aFp = Main.$fNumFoo @ q $dC1_aEj } in let { $dNum_aFq :: Num (Bar (Foo q)) [LclId, Str=DmdType] $dNum_aFq = Main.$fNumBar @ (Foo q) $dNum_aFp } in f @ (Foo q) $dC2_aEl (Main.$fC2Bar @ (Foo q) $dNum_aFq (Main.$fNumBar @ (Bar (Foo q)) $dNum_aFq) $dC2_aEl) Orig lhs: let { $dNum_aFp :: Num (Foo q) [LclId, Str=DmdType] $dNum_aFp = Main.$fNumFoo @ q $dC1_aEj } in let { $dNum_aFq :: Num (Bar (Foo q)) [LclId, Str=DmdType] $dNum_aFq = Main.$fNumBar @ (Foo q) $dNum_aFp } in let { $dNum_aFr :: Num (Bar (Bar (Foo q))) [LclId, Str=DmdType] $dNum_aFr = Main.$fNumBar @ (Bar (Foo q)) $dNum_aFq } in let { $dC2_aEl :: C2 (Foo q) [LclId, Str=DmdType] $dC2_aEl = Main.$fC2Foo @ q $dNum_aFp $dNum_aFq $dC1_aEj } in let { $dC2_aEm :: C2 (Bar (Foo q)) [LclId, Str=DmdType] $dC2_aEm = Main.$fC2Bar @ (Foo q) $dNum_aFq $dNum_aFr $dC2_aEl } in f @ (Foo q) $dC2_aEl $dC2_aEm }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12074> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #11783: Very large slowdown when using parallel garbage collector
by GHC 16 May '16

16 May '16

#11783: Very large slowdown when using parallel garbage collector -------------------------------------+------------------------------------- Reporter: luispedro | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.10.3 System | Keywords: performance, | Operating System: Unknown/Multiple garbage collector | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- As part of debugging some performance issues on an application I am writing, I concluded that the issue is in the parallel GC implemented in the GHC RTS. I extracted the code attached to make a self-contained use- case, but in my system the code runs in 16s when using a single thread, in 18s when using 6 threads but no parallel GC and in over a minute when using 6 threads with parallel GC! The true slowdown in the full code is actually worse and relevant for the application (some steps take >1 hour instead of <1 minute!). Parts of the code do take full advantage of parallel processing, this is just one simple test case -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11783> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #12070: SMP primitives broken on power(pc)
by GHC 16 May '16

16 May '16

#12070: SMP primitives broken on power(pc) -------------------------------------+------------------------------------- Reporter: hvr | Owner: trommler Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Runtime | Version: 8.0.1-rc4 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I originally noticed this when working on the AIX port (32-bit powerpc), and recently saw this also on Linux/powerpc64, which lead to talking to Peter Trommler who already had a suspicion: Here's for example the CAS definition (in `<stg/SMP.h>`): {{{#!c StgWord cas(StgVolatilePtr p, StgWord o, StgWord n) { StgWord result; __asm__ __volatile__ ( "1: ldarx %0, 0, %3\n" " cmpd %0, %1\n" " bne 2f\n" " stdcx. %2, 0, %3\n" " bne- 1b\n" "2:" :"=&r" (result) :"r" (o), "r" (n), "r" (p) :"cc", "memory" ); return result; }}} The important detail is the lack any barrier instructions, such as `isync` at the end. This results in infrequent heap-corruptions which in turn result in all sorts of infrequent and hard to track down runtime-crashes (including in `ghc -j`). Peter has already a patch in the works which simply replaces the atomic powerpc primitives with `__sync_*` intrinsics which turn out to be more portable than inline-asm. I've been testing the patch already and it seems to have made all issues I experienced so far disappear, as well as fixing the `concprog01` test which was also failing infrequently. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12070> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7