July 2015 - ghc-tickets

[GHC] #9215: GHC 7.8.2 mingw-w64: symbol not found in link
by GHC 21 Jan '16

21 Jan '16

#9215: GHC 7.8.2 mingw-w64: symbol not found in link ------------------------------------+------------------------------------- Reporter: stuartallenmills | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- This includes calls such as strdup, stat, , and snprintf. These calls are not available in the 64 bit libraries (though 64 bit versions are such as _strdup, _snprintf) These problems have occurred in building yaml and unix-compat. They also occurred in system-fileio but jmilikin generated a patch for that library -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9215> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #9182: Empty case analysis for function clauses
by GHC 20 Jan '16

20 Jan '16

#9182: Empty case analysis for function clauses ------------------------------------+------------------------------------- Reporter: dfranke | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Thanks to `-XEmptyCase`, the following is legal: {{{ module Empty where data Empty empty :: Empty -> a empty x = case x of { } }}} However, if I leave off the last line, GHC will complain that `The type signature for ‘empty’ lacks an accompanying binding`. I think this program should be accepted. It isn't that I'm not giving a definition for `empty`; it's that I'm defining it to be a function with no accompanying equations, as could be represented in Template Haskell by $(return [FunD (mkName "empty") []]) Currently, this too is rejected, with GHC complaining `Function binding for ‘empty’ has no equations`. I think this should be legal, with an empty list of clauses in a function definition being treated the same way as an empty list of matches in a case expression. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9182> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9202: Strange Closure Type
by GHC 20 Jan '16

20 Jan '16

#9202: Strange Closure Type -------------------------------------+------------------------------------- Reporter: athanclark | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: strange-closure- | Operating System: Linux type | Type of failure: Compile-time Architecture: x86_64 (amd64) | crash Difficulty: Project (more | Test Case: than a week) | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Hello masters of the universe, I am here with a plea. I have recently installed GHC 7.8.2 and cabal-install 1.20.0.0 (following [https://gist.github.com/wting/8498731 this] guide), and have ran into a fun road block on the way to installing yesod-platform. I have had a few incidents of the 'strange closure type ###' error on this machine before, on the 7.6.x version available in Ubuntu's repository. I believe this failure is occuring when installing text, because that was the error that I got when installing attoparsec alone, but without a sandbox. I know (barely) better now, so when I went to install yesod-platform, I did a {{{cabal unpack $1 && cd $1* && cabal sandbox init && cabal install --only-dependencies && cabal build}}}, but I failed at preventing the error, still :( I've attached the output as output.txt, and I've also included my `lspci` and `lshw` outputs just for giggles :) I hope someone can direct me in the right direction, I would appreciate it tremendously. Thank you! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9202> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #10581: Recommend ScopedTypeVariables
by GHC 20 Jan '16

20 Jan '16

#10581: Recommend ScopedTypeVariables -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The !ScopedTypeVariables extension is one of the few that doesn't recommend itself when it should be used. I recognize that this may be hard to do, but here is a strawman proposal: Always behave as if !ScopedTypeVariables is on at binding sites for type variables (in an annotation with `forall`). Then, at ''occurrences'' of type variables, check if the extension is on. If a type variable is in scope but the extension is off, remember that the user probably wants the extension, but then rename the type variable occurrence away from the in- scope one. If a type error ensues, we've remembered that the lack of !ScopedTypeVariables may be to blame, and we recommend turning it on. There may be better approaches, too. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10581> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8114: GHC panic when building `thyme`
by GHC 16 Jan '16

16 Jan '16

#8114: GHC panic when building `thyme` -----------------------------------+--------------------------------------- Reporter: Ptharien's | Owner: Flame | Status: new Type: bug | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Operating System: MacOS X Keywords: | Type of failure: Compile-time crash Architecture: x86_64 (amd64) | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- While attempting to build `thyme` from Hackage with core, stg, and cmm linting and -O2 enabled, GHC crashed with an internal panic. See attached terminal log. {{{ rrdhcp-10-32-234-247:thyme-0.2.4.1 Alexander$ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.6.3 rrdhcp-10-32-234-247:thyme-0.2.4.1 Alexander$ cabal --version cabal-install version 1.16.0.2 using version 1.16.0 of the Cabal library rrdhcp-10-32-234-247:thyme-0.2.4.1 Alexander$ which ghc /usr/local/bin/ghc rrdhcp-10-32-234-247:thyme-0.2.4.1 Alexander$ which cabal /Users/Alexander/Library/Haskell/bin/cabal }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8114> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #8613: simplifier ticks exhausted
by GHC 13 Jan '16

13 Jan '16

#8613: simplifier ticks exhausted ----------------------------------+---------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------- (Sent by chrisreade(a)mac.com ) Compiler giving up with simplifier ticks exhausted. Large amount of simplification may be going on to cause this. The problem goes away when using -fsimpl-tick-factor=1000 and the code runs. This is the session output without the flag (asking to have bug reported): chris$ ghc -O2 -rtsopts RedBlackStencilOpt.hs -v Glasgow Haskell Compiler, Version 7.6.3, stage 2 booted by GHC version 7.4.2 Using binary package database: /Library/Frameworks/GHC.framework/Versions/7.6.3-x86_64/usr/lib/ghc-7.6.3/package.conf.d/package.cache Using binary package database: /Users/chris/.ghc/x86_64-darwin-7.6.3/package.conf.d/package.cache hiding package binary-0.5.1.1 to avoid conflict with later version binary-0.6.4.0 hiding package Cabal-1.16.0 to avoid conflict with later version Cabal-1.18.1.1 wired-in package ghc-prim mapped to ghc- prim-0.3.0.0-d5221a8c8a269b66ab9a07bdc23317dd wired-in package integer-gmp mapped to integer- gmp-0.5.0.0-2f15426f5b53fe4c6490832f9b20d8d7 wired-in package base mapped to base-4.6.0.1-6c351d70a24d3e96f315cba68f3acf57 wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template- haskell-2.8.0.0-c2c1b21dbbb37ace4b7dc26c966ec664 wired-in package dph-seq not found. wired-in package dph-par not found. Hsc static flags: -static *** Chasing dependencies: Chasing modules from: *RedBlackStencilOpt.hs Stable obj: [] Stable BCO: [] Ready for upsweep [NONREC ModSummary { ms_hs_date = 2013-12-13 13:12:37 UTC ms_mod = main:RedBlackStencilOpt, ms_textual_imps = [import (implicit) Prelude, import Data.Array.Repa.Stencil.Dim2 as A, import Data.Array.Repa.Stencil as A, import Data.Array.Repa as A] ms_srcimps = [] }] *** Deleting temp files: Deleting: compile: input file RedBlackStencilOpt.hs Created temporary directory: /var/folders/dz/m1mks1yn1bsft72zgh105sw40000gn/T/ghc93155_0 *** Checking old interface for main:RedBlackStencilOpt: [1 of 1] Compiling RedBlackStencilOpt ( RedBlackStencilOpt.hs, RedBlackStencilOpt.o ) *** Parser: *** Renamer/typechecker: *** Simplify: *** CorePrep: *** ByteCodeGen: Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. *** gcc: '/usr/bin/gcc' '-m64' '-fno-stack-protector' '-m64' '-L/Library/Frameworks/GHC.framework/Versions/7.6.3-x86_64/usr/lib/ghc-7.6.3/base-4.6.0.1' '--print-file-name' 'libiconv.dylib' Loading package base ... linking ... done. Loading package pretty-1.1.1.0 ... linking ... done. Loading package array-0.4.0.1 ... linking ... done. Loading package deepseq-1.3.0.1 ... linking ... done. Loading package containers-0.5.0.0 ... linking ... done. Loading package old-locale-1.0.0.5 ... linking ... done. Loading package time-1.4.0.1 ... linking ... done. Loading package random-1.0.1.1 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package QuickCheck-2.6 ... linking ... done. Loading package bytestring-0.10.0.2 ... linking ... done. Loading package primitive-0.5.0.1 ... linking ... done. Loading package vector-0.10.0.1 ... linking ... done. Loading package repa-3.2.3.3 ... linking ... done. *** Simplify: *** CorePrep: *** ByteCodeGen: *** Desugar: Result size of Desugar (after optimization) = {terms: 900, types: 1,810, coercions: 340} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 834, types: 1,757, coercions: 567} Result size of Simplifier iteration=2 = {terms: 830, types: 1,721, coercions: 567} Result size of Simplifier = {terms: 830, types: 1,721, coercions: 567} *** Specialise: Result size of Specialise = {terms: 830, types: 1,721, coercions: 567} *** Float out(FOS {Lam = Just 0, Consts = True, PAPs = False}): Result size of Float out(FOS {Lam = Just 0, Consts = True, PAPs = False}) = {terms: 993, types: 2,131, coercions: 567} *** Float inwards: Result size of Float inwards = {terms: 993, types: 2,131, coercions: 567} *** Simplifier: *** Deleting temp files: Deleting: /var/folders/dz/m1mks1yn1bsft72zgh105sw40000gn/T/ghc93155_0/ghc93155_0.s Warning: deleting non-existent /var/folders/dz/m1mks1yn1bsft72zgh105sw40000gn/T/ghc93155_0/ghc93155_0.s *** Deleting temp dirs: Deleting: /var/folders/dz/m1mks1yn1bsft72zgh105sw40000gn/T/ghc93155_0 ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-apple-darwin): Simplifier ticks exhausted When trying RuleFired Class op szipWith To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 60402 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8613> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10697: Change template-haskell API to allow NOUNPACK, lazy annotations
by GHC 13 Jan '16

13 Jan '16

#10697: Change template-haskell API to allow NOUNPACK, lazy annotations -------------------------------------+------------------------------------- Reporter: | Owner: RyanGlScott | Type: feature | Status: new request | Priority: normal | Milestone: Component: Template | Version: 7.10.1 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #8347 Differential Revisions: | -------------------------------------+------------------------------------- Currently, the {{{template-haskell}}} API is lagging behind what is possible with GHC's strictness annotations in data types, especially since the advent of {{{StrictData}}}. Currently, {{{template-haskell}}} has {{{Strict}}}: {{{#!hs data Strict = IsStrict | NotStrict | Unpacked }}} But it appears that there are actually nine different combinations of packedness and strictness annotations: {{{#!hs data A = A Int -- No unpackedness, no strictness data A = A !Int -- No unpackedness, strict data A = A ~Int -- No unpackedness, lazy data A = A {-# NOUNPACK #-} A Int -- NOUNPACK, no strictness data A = A {-# NOUNPACK #-} A !Int -- NOUNPACK, strict data A = A {-# NOUNPACK #-} A ~Int -- NOUNPACK, lazy data A = A {-# UNPACK #-} A Int -- UNPACK, no strictness data A = A {-# UNPACK #-} A !Int -- UNPACK, strict data A = A {-# UNPACK #-} A ~Int -- UNPACK, lazy }}} It seems like the most consistent thing to do would be change {{{Strict}}} and add {{{Unpack}}} to the {{{template-haskell}}} API: {{{#!hs data Strict = IsStrict | NotStrict | IsLazy data Unpack = Unpack | NoUnpack | NotUnpacked type UnpackStrictType = (Unpack, Strict, Type) type VarUnpackStrictType = (Name, Unpack, Strict, Type) }}} And so on. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10697> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24

[GHC] #10070: Cross compiling from Linux to Windows with mising Win32 library
by GHC 13 Jan '16

13 Jan '16

#10070: Cross compiling from Linux to Windows with mising Win32 library -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Build | Version: 7.11 System | Operating System: Unknown/Multiple Keywords: cross- | Type of failure: Building GHC compiling | failed Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- After applying the proposed patch from #9524, building a Linux to Windows cross-compiler terminates with: {{{ Configuring time-1.5.0.1... ghc-cabal: At least the following dependencies are missing: Win32 -any }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10070> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9048: armel: evacuate(static): strange closure type 0
by GHC 13 Jan '16

13 Jan '16

#9048: armel: evacuate(static): strange closure type 0 ------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I guess I need to document the build failures here, instead of just mentioning them on the mailing list: Building 7.8 on armel on Debian fails with {{{ chmod +x inplace/bin/runghc inplace/bin/dll-split compiler/stage2/build/.depend-v-p-dyn.haskell "DynFlags" "Annotations Avail Bag BasicTypes BinIface Binary Bitmap BlockId BooleanFormula BreakArray BufWrite BuildTyCl ByteCodeAsm ByteCodeInstr ByteCodeItbls CLabel Class CmdLineParser Cmm CmmCallConv CmmExpr CmmInfo CmmMachOp CmmNode CmmType CmmUtils CoAxiom ConLike CodeGen.Platform CodeGen.Platform.ARM CodeGen.Platform.NoRegs CodeGen.Platform.PPC CodeGen.Platform.PPC_Darwin CodeGen.Platform.SPARC CodeGen.Platform.X86 CodeGen.Platform.X86_64 Coercion Config Constants CoreArity CoreFVs CoreLint CoreSubst CoreSyn CoreTidy CoreUnfold CoreUtils CostCentre DataCon Demand Digraph DriverPhases DsMonad DynFlags Encoding ErrUtils Exception ExtsCompat46 FamInstEnv FastBool FastFunctions FastMutInt FastString FastTypes Finder Fingerprint FiniteMap ForeignCall Hooks Hoopl Hoopl.Dataflow HsBinds HsDecls HsDoc HsExpr HsImpExp HsLit HsPat HsSyn HsTypes HsUtils HscTypes IOEnv Id IdInfo IfaceEnv IfaceSyn IfaceType InstEnv InteractiveEvalTypes Kind ListSetOps Literal LoadIface Maybes MkCore MkGraph MkId Module MonadUtils Name NameEnv NameSet OccName OccurAnal OptCoercion OrdList Outputable PackageConfig Packages Pair Panic PatSyn PipelineMonad Platform PlatformConstants PprCmm PprCmmDecl PprCmmExpr PprCore PrelInfo PrelNames PrelRules Pretty PrimOp RdrName Reg RegClass Rules SMRep Serialized SrcLoc StaticFlags StgCmmArgRep StgCmmClosure StgCmmEnv StgCmmLayout StgCmmMonad StgCmmProf StgCmmTicky StgCmmUtils StgSyn Stream StringBuffer TcEvidence TcIface TcRnMonad TcRnTypes TcType TcTypeNats TrieMap TyCon Type TypeRep TysPrim TysWiredIn Unify UniqFM UniqSet UniqSupply Unique Util Var VarEnv VarSet" dll-split: internal error: evacuate(static): strange closure type 0 (GHC version 7.8.2 for arm_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[2]: *** [compiler/stage2/dll-split.stamp] Aborted make[2]: *** Waiting for unfinished jobs.... make[1]: *** [all] Error 2 }}} Unfortunately, I’m no expert in strange architectures, so I need help from all you arm-lovers out there... Can someone, for starters, confirm this on an arm machine, or is this Debian specific somehow? (Hardening flags have been disabled.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9048> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10719: Malformed data type quotation accepted
by GHC 11 Jan '16

11 Jan '16

#10719: Malformed data type quotation accepted -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- This is accepted: Prelude Language.Haskell.TH> {{{$(stringE . show =<< [d| data A where C :: C |])}}} "[DataD [] A_1627402878 [] [ForallC [] [] (NormalC C_1627402879 [])] []]" In contrast this is rejected: Prelude Language.Haskell.TH> {{{$(stringE . show =<< [d| data A p where C :: C |])}}} <interactive>:29:22: Malformed constructor result type: C However it would make sense to form an equality constraint (for later kind/type checking) in these cases, something along the lines of: {{{#!hs data A p where C :: (A p ~ C) => C }}} as there could be type synonym (or family) `C`. I have tested various versions >= 7.8.3 and all seem to behave the same. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10719> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8