- ghc-tickets - Haskell.org

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 17 May '16

17 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 17 May '16

17 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 17 May '16

17 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 17 May '16

17 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 17 May '16

17 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

Re: [GHC] #7672: boot file entities are sometimes invisible and are not (semantically) unified with corresponding entities in implementing module
by GHC 17 May '16

17 May '16

#7672: boot file entities are sometimes invisible and are not (semantically) unified with corresponding entities in implementing module -------------------------------------+------------------------------------- Reporter: skilpat | Owner: ezyang Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.4.2 checker) | Keywords: backpack, hs- Resolution: fixed | boot Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: GHC rejects | Test Case: valid program | rename/should_compile/T7672 Blocked By: | Blocking: 10336 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: backpack => backpack, hs-boot -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7672#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10333: hs-boot modification doesn't induce recompilation
by GHC 17 May '16

17 May '16

#10333: hs-boot modification doesn't induce recompilation -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Consider these modules: X.hs-boot {{{ module X where }}} Y.hs {{{ module Y where import {-# SOURCE #-} X data T = T data S = S T }}} X.hs {{{ module X where import Y }}} `ghc --make Y.hs` will compile fine. Now, modify `X.hs-boot` to add a `data T` (which will cause an ambiguous identifier error in Y.hx`. Run `ghc --make Y.hs` and nothing happens! (You might also notice something else a bit funny, which is that `X.hs` gets compiled, even though it's not directly in the import chain of Y. I think this might be intentional but I'm not sure.) Discovered this while poking around #10182. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10333> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

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

16 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:"21fe4ffd049c8ab4b9ee36af3cf8f70b46d6beda/ghc" 21fe4ff/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="21fe4ffd049c8ab4b9ee36af3cf8f70b46d6beda" Kill varSetElems in tcInferPatSynDecl varSetElems introduces unnecessary non-determinism and while I didn't estabilish experimentally that this matters here I'm convinced that it will, because I expect pattern synonyms to end up in interface files. Test Plan: ./validate Reviewers: austin, simonmar, bgamari, mpickering, simonpj Reviewed By: simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2206 GHC Trac Issues: #4012 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:169> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0