August 2015 - ghc-tickets

[GHC] #9037: Add option to make selected warnings errors
by GHC 21 Jan '16

21 Jan '16

#9037: Add option to make selected warnings errors ------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: feature request | 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: | ------------------------------------+------------------------------------- It would be great if GHC offered a `-ferror-*` flag for every `-fwarn-*` flag, that turns the given type of warning into an error. For example, I would like to always error on uninitialized record fields, but don't want to go full `-Werror`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9037> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10137: Rewrite switch code generation
by GHC 21 Jan '16

21 Jan '16

#10137: Rewrite switch code generation -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 (CodeGen) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Inspired by #10124 I looked at the code generation for enumeration and integer types, and I think this can be improved in a few ways. My goals are: * Fancier code for integer types. Currently, the code for enumeration types will emit jump tables for dense choices; there is no reason to treat integer types differently. * The ability to behave differently if some of the cases are equal, and, as an extension of that, * The possibility to create branchless code if multiple checks would go to the same jump. The current scheme is roughly: * When we generate Cmm code for a STG case expression, we handle enumeration types and literals separately. * At this point, the decisions about what code to generate are made (jump tables (but only for enumeration types) or if-then-else trees). * The Common Block Optimization on Cmm happens later in the pipeline, making it non-trivial to detect branches that do the same thing. My plan is the following: * In the STG→Cmm transformation, floats will be handled separately. Matching against literals literals is fishy anyways, so my suggestion is to simply generate a linear list of equality checks here – turning the intended operation (equality test) into something else (comparisons in a if-then-else tree) feels wrong to me for floats. And the rest would not work well for floats, so I’d like to have them out of the way. * The case of enumeration types will be reduced to word literals, and treated the same from now on. * For integer types, no code generation decisions is made at this point. Instead, always a `CmmSwitch` statement is generated. * In a separate Cmm transformation pass, which will run /after/ the common block optimization, we visit all `CmmSwitches` and create proper code for them. I’d like to separate the algorithm that plans the code generation into a function (possibly even module) of its own, so that the decisions can easily by analyized and modified. The algorithm has a few choices to make: * If multiple values point to the same code, we can generate branchless code (`y := x == 1 || x == 5 || x = 7; if (y==0) then goto l1 else goto l2`). * If there are whole ranges pointing to the same code, the above can also use comparisons. * If there are dense ranges (i.e. a range with more than half of the possible values mapped to something), we want to generate jump tables from them (still `CmmSwitch` values). * Unless all options are handled by one of these possibilities, they need to be combined using `if-then-else` trees. The `CmmSwitch` constructor needs to change for that. It currently takes a `[Maybe Label]` argument, which is not suitable for before that pass, when its table may be sparse. I think an `IntMap Label` would work nicely. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10137> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #9357: Kind-polymorphic type family accepts unlifted type arguments
by GHC 21 Jan '16

21 Jan '16

#9357: Kind-polymorphic type family accepts unlifted type arguments -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: GHC Difficulty: Unknown | accepts invalid program Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The following code is accepted by ghc-7.8.2 and ghc-7.6.3: {{{#!hs {-# LANGUAGE TypeFamilies, MagicHash, PolyKinds #-} import GHC.Exts type family F (a :: k) :: * type instance F Int# = () }}} In nearly all other places, it seems that unlifted types are explicitly forbidden. I'm also not allowed to actually apply `F` to `Int#` after defining the type family like this. So I think the compiler should probably reject the `type instance`. (BTW, is it actually clear that using `#` as an argument kind to a type family or as an index kind for a GADT is in any way harmful?) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9357> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[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