- ghc-tickets - Haskell.org

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

14 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 14 Jan '16

14 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 14 Jan '16

14 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] #11412: Trouble parsing arithmetic sequence syntax
by GHC 14 Jan '16

14 Jan '16

#11412: Trouble parsing arithmetic sequence syntax -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 Haskell-98 program {{{#!hs module Bug where blah = [True..] }}} does not compile. I assume this is because GHC thinks that I'm accessing the operator `.` from the module `True`. It took me a little while to figure out what was going on here! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11412> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11047: Provide call stacks in GHCi
by GHC 13 Jan '16

13 Jan '16

#11047: Provide call stacks in GHCi -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #545, #4837 Differential Rev(s): Phab:D1407 | Wiki Page: -------------------------------------+------------------------------------- I want call stacks to be available in GHCi with no effort on the part of the user, or changes to the source code. The call stack will be available both programatically and via GHCi commands: * `GHC.Stack.currentCallStack` returns the current call stack as `[String]`. This can be used from `error` and copied into the exception string. * `Debug.Trace.traceStack` prints out the stack anywhere. * GHCi will have a new command `:where` to print out the stack when stopped at a breakpoint The stack trace will be the accurate (i.e. not exposing details of lazy evaluation or tail calls) and detailed (including locations of calls, not just the enclosing function definition). = Implmeentation = Here's how it's going to work: * We make GHCi work with profiling (done: Phab:D1407) * We make breakpoint ticks behave like SCC annotations, and update the interpreter to implement the cost-centre-stack semantics. = Exmaple = Here's an example from my prototype: {{{ g :: Int -> [Int] g n = traceStack "g" [n] h :: Int -> Bool h n = case g n of [] -> True (x:xs) -> False map :: (a -> b) -> [a] -> [b] map f [] = [] map f (x:xs) = f x : map f xs k n = map h [n] }}} {{{ [1 of 1] Compiling Main ( /home/smarlow/scratch/dbg1.hs, interpreted ) Ok, modules loaded: Main. *Main> k 1 [g Stack trace: Main.g (/home/smarlow/scratch/dbg1.hs:13:7-24) Main.g (/home/smarlow/scratch/dbg1.hs:13:1-24) Main.h (/home/smarlow/scratch/dbg1.hs:16:12-14) Main.h (/home/smarlow/scratch/dbg1.hs:(16,7)-(18,24)) Main.h (/home/smarlow/scratch/dbg1.hs:(16,1)-(18,24)) Main.map (/home/smarlow/scratch/dbg1.hs:22:16-18) Main.map (/home/smarlow/scratch/dbg1.hs:22:16-29) Main.map (/home/smarlow/scratch/dbg1.hs:(21,1)-(22,29)) Main.k (/home/smarlow/scratch/dbg1.hs:24:7-15) Main.k (/home/smarlow/scratch/dbg1.hs:24:1-15) False] *Main> }}} We could trim some of the extra detail from the stack trace so that each function appears once; there are several choices here, currently I'm collecting and displaying the most detail. = Deployment = One disadvantage of this is that it requires GHCi to be built with profiling, and all the libraries have to be built with profiling too. There are two options for deployment: 1. We deploy two versions of GHCi (profiled and non-profiled), or 2. We expand on what GHCJS did, and make the interpreted code run in a separate process, thus separating the GHCi binary itself from the code being interpreted. This would allow the interpreted code to be run with the profiled RTS while GHCi itself is unprofiled. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11047> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #10864: arm: strange closure type 64008 from cabal-install
by GHC 13 Jan '16

13 Jan '16

#10864: arm: strange closure type 64008 from cabal-install ------------------------------------+---------------------------------- Reporter: muhmuhten | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Linux Architecture: arm | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ------------------------------------+---------------------------------- This is occurring on fedora 22 with ghc and cabal-install directly from the repos; I haven't checked whether the bug is actually downstream. {{{ # dnf install -y cabal-install $ cabal sandbox init cabal: internal error: evacuate(static): strange closure type 65200 (GHC version 7.8.4 for arm_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) $ cabal update Downloading the latest package list from hackage.haskell.org cabal: internal error: evacuate(static): strange closure type 64008 (GHC version 7.8.4 for arm_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10864> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[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] #10969: Arm: Investigate Thumb2/Arm interworking
by GHC 13 Jan '16

13 Jan '16

#10969: Arm: Investigate Thumb2/Arm interworking -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (CodeGen) | Keywords: arm, thumb | Operating System: Unknown/Multiple Architecture: arm | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #10375 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Arm (32 bit) has two commonly used instruction sets; Thumb2 and Arm. The former is encoded in two bytes per instruction and the latter in four bytes. The CPU also has a bit in the flags register specifyng which code execution mode the CPU is currently in. The important thing to note is that executing Arm code when in Thumb2 mode (or vice versa) will sooner or later result in an illegal insruction or segfault. During debugging of #10375, I found that Haskell code compiled via the LLVM backend was generating Arm instructions, while C code compiled via GCC was generating Thumb2 code. When object code from these two paths are linked by the system linker everything is fine because the system linker knows how to link Thumb code to Arm code to produce a valid binary. The problem in #10375 was that in GHCi, the runtime linker was loading object files without the correct fixups between Thumb2 and Arm so that Thumb2 code in the `StgRun` function was jumping correctly into Arm code in the loaded object and returning to the Thumb2 code in `StgRun` while still in Arm execution mode and then crashing. In commit [changeset:"933adc0f31164cb651d11ecfcfe612ac429f714f/ghc" 933adc0f/ghc] I fixed GHCi for Arm by forcing GHC to generate only Arm code. As discussed in the associated Phab:D1323 it would be nice to investigate this further to see if its possible to make GHC generate Thumb2 code (which potentially has some performance benefits since it encodes all instructions in two bytes) and/or fix Thumb2/Arm interop. However, that interop may not be possible. In one of the comments in the Phab:D1323, @bgamari said: > That being said, I don't think we'll ever be able to support linking of Thumb Haskell code with ARM Haskell code. The reason for this is that interop requires the use of a trampoline, which breaks tables-next-to- code. Two possible outcomes for this ticket are: * We somehow get proper Thumb2/Arm code interoperation working. * We decide that interop is too difficult or not worthwhile and a) document this somewhere in the code and b) remove the Thumb2 relocation code in `rts/Linker.c` and all other references to Thumb2. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10969> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #5642: Deriving Generic of a big type takes a long time and lots of space
by GHC 13 Jan '16

13 Jan '16

#5642: Deriving Generic of a big type takes a long time and lots of space -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.3 Resolution: | Keywords: deriving-perf Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: T5642 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by gidyn): * cc: gidyn (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5642#comment:29> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5642: Deriving Generic of a big type takes a long time and lots of space
by GHC 13 Jan '16

13 Jan '16

#5642: Deriving Generic of a big type takes a long time and lots of space -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.3 Resolution: | Keywords: deriving-perf Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: T5642 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by wilx): * cc: vhaisman@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5642#comment:28> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0