June 2015 - ghc-tickets

[GHC] #10546: conc034 is failing with a Core Lint error
by GHC 25 Jul '15

25 Jul '15

#10546: conc034 is failing with a Core Lint error -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- {{{ =====> conc034(threaded2) 78 of 99 [0, 0, 0] cd . && "/home/smarlow/ghc/inplace/bin/ghc-stage2" -o conc034 conc034.hs -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package- db -rtsopts -fno-warn-tabs -fno-ghci-history -O -threaded -eventlog > conc034.comp.stderr 2>&1 Compile failed (status 256) errors were: [1 of 1] Compiling Main ( conc034.hs, conc034.o ) *** Core Lint errors : in result of Simplifier *** <no location info>: warning: In the expression: seq @ e10_a1ZF @ (# State# RealWorld, () #) e2_a1ZN (# eta_X16, () #) Kinds don't match in type application: Type variable: b_13 :: * Arg type: (# State# RealWorld, () #) :: # xx # }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10546> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10313: ApiAnnotations : strings in warnings do not return SourceText
by GHC 25 Jul '15

25 Jul '15

#10313: ApiAnnotations : strings in warnings do not return SourceText -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple ApiAnnotations | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The `strings` used in a `WARNING` pragma are captured via {{{ strings :: { Located ([AddAnn],[Located FastString]) } : STRING { sL1 $1 ([],[L (gl $1) (getSTRING $1)]) } .. }}} The `STRING` token has a method `getSTRINGs` that returns the original source text for a string. A warning of the form {{{#!hs {-# WARNING Logic , mkSolver , mkSimpleSolver , mkSolverForLogic , solverSetParams , solverPush , solverPop , solverReset , solverGetNumScopes , solverAssertCnstr , solverAssertAndTrack , solverCheck , solverCheckAndGetModel , solverGetReasonUnknown "New Z3 API support is still incomplete and fragile: \ \you may experience segmentation faults!" #-} }}} returns the concatenated warning string rather than the original source. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10313> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8327: Cmm sinking does not eliminate dead code in loops
by GHC 25 Jul '15

25 Jul '15

#8327: Cmm sinking does not eliminate dead code in loops ------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: | ------------------------------------+------------------------------------- Cmm code shown in #8326 is suboptimal. For this Haskell code: {{{ isTrue# :: Int# -> Bool isTrue# 1# = True isTrue# _ = False f :: Int# -> Int f x | isTrue# (x ># 0#) = I# x | otherwise = -(I# x) }}} we get Cmm that contains dead code in a loop: {{{ cFg: // False branch Hp = Hp + 16; if (Hp > HpLim) goto cFy; else goto cFx; cFy: // not enough heap, call GC HpAlloc = 16; I64[Sp - 16] = cFf; R1 = _sEV::I64; I64[Sp - 8] = _sEU::I64; Sp = Sp - 16; call stg_gc_unbx_r1(R1) returns to cFf, args: 8, res: 8, upd: 8; cFf: // re-do the False branch _sEU::I64 = I64[Sp + 8]; Sp = Sp + 16; _sEV::I64 = R1; goto cFg; cFx: // RHS of False branch I64[Hp - 8] = GHC.Types.I#_con_info; I64[Hp] = -_sEU::I64; R1 = Hp - 7; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; }}} Notice that `_sEV` is dead - we should optimize it away. This is a known deficiency in the Cmm sinking pass (i.e. it does not work for loops). I'm putting this on Trac so we have this documented. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8327> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8604: Some stack/vmem limits (ulimit) combinations causing GHC to fail
by GHC 24 Jul '15

24 Jul '15

#8604: Some stack/vmem limits (ulimit) combinations causing GHC to fail ----------------------------------+---------------------------------- Reporter: clavin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Other Architecture: x86_64 (amd64) | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------------- I have encountered a strange occurrence with GHC that was causing several GHC job failures on an SGE cluster. It turned out that there were other SGE users who needed an absurdly large stack size limit (set via 'ulimit -s') in the several gigabytes range. The default stack size limit had to be raised for the entire cluster. Any job that was run on a machine where the virtual memory limit was less than or equal to 2X the stack size limit, GHC would crash with the following message: ghc: failed to create OS thread: Cannot allocate memory I am running on GHC 7.6.3 with a 64-bit RedHat Enterprise OS, version 5.5. To reproduce the error, I was able to create the following test case: [ ~]$ ulimit -v unlimited [ ~]$ ulimit -s 10240 [ ~]$ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.6.3 [ ~]$ ulimit -v 200000 [ ~]$ ulimit -s 100000 [ ~]$ ghc --version ghc: failed to create OS thread: Cannot allocate memory Several other programs work find using these settings, but GHC consistently has problems. Is this a fundamental issue with how GHC operates or can this be addressed? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8604> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9229: Compiler memory use regression
by GHC 24 Jul '15

24 Jul '15

#9229: Compiler memory use regression -------------------------+------------------------------------------------- Reporter: | Owner: augustss | Status: new Type: bug | Milestone: Priority: | Version: 7.8.2 normal | Operating System: Windows Component: | Type of failure: Compile-time performance bug Compiler | Test Case: Keywords: | Blocking: Architecture: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- I have a module which compiles fine with ghc 7.6, but where ghc 7.8.2 runs out of memory (32-bit Windows). Sadly, I cannot supply the source code since it's proprietary, so I realize that this bug will be almost impossible to fix. It is possible to compile the module with -O0 and -O1, but not -O2. (This is a very performance critical module so I'd like -O2.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9229> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9256: Support automatic derivation of an hs-boot file from an hs file
by GHC 24 Jul '15

24 Jul '15

#9256: Support automatic derivation of an hs-boot file from an hs file ------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: backpack | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- This is essentially augustss's proposal from ticket #1409: I would settle for a solution where I annotate those entities in a module that would go in the hs-boot file. So instead of me having to go through the trouble of creating an extra file I could just say, e.g., Replying to [comment:13 augustss]: > I would settle for a solution where I annotate those entities in a module that would go in the hs-boot file. So instead of me having to go through the trouble of creating an extra file I could just say, e.g., > > {{{ > {-# MODULE_MUTUAL_RECURSION_BREAKER T, foo #-} > data T = ... > foo :: ... > foo = ... > }}} > > The values that have an annotation would have to have a type signature. This should be eminently doable. Here is a more fleshed out proposal. First, consider the definition of an hs-boot file in the absence of mutual recursion (i.e. no breakers are necessary). In this case, the hi-boot file for an hs file is precisely the hi file produced after ordinary renaming and typechecking of the module. As an optimization, we would like to avoid typechecking definitions if an explicit type signature is present (if the type signature is absent, we have no choice.) There are a few choices here: we can force users to give top-level declarations for all exported functions (so unconditionally error if something is missing, by filtering out the relevant value declarations from the source), or we can go ahead and do full typechecking when the signature is missing. (The former is probably the simplest.) Now, how to handle breakers? We need to avoid typechecking them, since their recursive dependence means that they would not type check properly. So we should also filter out their type signatures. (Furthermore, if we are inferring some signatures, we need to make sure that their definitions don't rely on any breakers. For this reason, it is probably simplest to just require explicit type signatures.) If the mechanism for specifying breakers is exclusionary (as opposed to an inclusionary method of saying what values are in the signature), there is an awkward problem of syntax for exporting only an abstract type: the logical choices mean the wrong thing (`T(..)` seem to imply the type is eliminated entirely, whereas `T` seems to imply that the type should be eliminated, but not eh constructors.) Summary: 1. Require top-level signatures in hs to hs-boot files(?) 2. Exclusionary or inclusionary signature pragma? 3. Filter out value declarations and excluded files, then rename/typecheck as normal, producing hi-boot file -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9256> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10566: Move "package key" generation to GHC
by GHC 23 Jul '15

23 Jul '15

#10566: Move "package key" generation to GHC -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Package | Version: 7.10.1 system | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Currently in GHC 7.10, we have the following situation: 1. Cabal computes a package key, which in practice (since no one is using Backpack in the wild) is a Merkle tree of the versions of each of the dependencies of the package. 2. This package key is passed to GHC via `-this-package-key` 3. GHC handles the package key opaquely Now, in recent Backpack implementation, we need GHC to be able to compute package keys. (The concrete case: you're type-checking an interface file of an indefinite package, where you want to instantiate it with some assignment of its holes: instantiating those holes you need to instantiate any package keys mentioned in the interface, in which case you really want to be able to compute the hash.) So I want to move package key generation to GHC. The primary implication is this: does Cabal continue to generate package keys? If it doesn't, we should revert from `-this-package-key` back to `-package-name` from the previous version (but maybe renamed because this name was bad). GHC then computes a package key based on `-package-name` and the explicitly mentioned `-package` dependencies, and Cabal reads it out with something akin to `--abi-hash`. If it does, we need to ensure GHC and Cabal's package key algorithms stay synchronized. I personally lean towards the first option. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10566> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #10018: Cannot define custom fixity for infix data constructors in GHCi
by GHC 23 Jul '15

23 Jul '15

#10018: Cannot define custom fixity for infix data constructors in GHCi -------------------------------------+------------------------------------- Reporter: | Owner: RyanGlScott | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.4 Component: GHCi | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect result Architecture: | at runtime Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When compiling from a module, declaring a custom fixity for an infix data constructor is valid: {{{#!hs module DataFixity where data Infix a b = a :@: b infixl 4 :@: }}} And GHCi recognizes this: {{{ $ ghci DataFixity.hs GHCi, version 7.8.4: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling DataFixity ( DataFixity.hs, interpreted ) Ok, modules loaded: DataFixity. λ> :i :@: data Infix a b = a :@: b -- Defined at DataFixity.hs:3:18 infixl 4 :@: }}} However, one cannot do this entirely in GHCi: {{{ $ ghci GHCi, version 7.8.4: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. λ> data Infix a b = a :@: b; infixl 4 :@: λ> :i (:@:) data Infix a b = a :@: b -- Defined at <interactive>:2:18 }}} GHCi simply assumes {{{:@:}}} has the default infix precedence. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10018> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #10530: Update transformers library
by GHC 21 Jul '15

21 Jul '15

#10530: Update transformers library -------------------------------------+------------------------------------- Reporter: | Owner: thoughtpolice | Status: new Type: bug | Milestone: 7.10.2 Priority: normal | Version: 7.10.2-rc1 Component: libraries | Operating System: Unknown/Multiple (other) | Type of failure: Other Keywords: | Blocked By: transformers | Related Tickets: Architecture: | Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- As noted in a reply to the RC1 announcement, we should update `transformers` to the latest version (which merely adds some new instances for `Const`). We should also do a once over for the other libraries. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10530> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #10548: Support PartialTypeSignatures in Template Haskell
by GHC 20 Jul '15

20 Jul '15

#10548: Support PartialTypeSignatures in Template Haskell -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: Template | Operating System: Unknown/Multiple Haskell | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Currently Template Haskell cannot emit [https://hackage.haskell.org/package/template-haskell-2.10.0.0/docs /Language-Haskell-TH-Syntax.html#t:Type Type]s with wildcards as in [https://ghc.haskell.org/trac/ghc/wiki/PartialTypeSignatures PartialTypeSignatures]. A data constructor for wildcards (eg. {{{WildcardT (Maybe Name)}}}) could be added to [https://hackage.haskell.org/package/template- haskell-2.10.0.0/docs/Language-Haskell-TH-Syntax.html#t:Type Type], which would be converted to wildcards in GHC. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10548> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17