November 2015 - ghc-tickets

[GHC] #11065: Outdated documentation for foldl and friends
by GHC 21 Jan '16

21 Jan '16

#11065: Outdated documentation for foldl and friends -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Documentation | Version: 7.10.2 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: -------------------------------------+------------------------------------- Straight from `Data.Foldable`, here is the documentation for `foldl`: {{{ -- | Left-associative fold of a structure. -- -- @'foldl' f z = 'Prelude.foldl' f z . 'toList'@ }}} But, of course, `Prelude.foldl` is the same `foldl`! There are other functions with similar problems. When revising these, please put in (back?) examples of how these work, at least on lists. I've been doing functional programming for some time, and I still like to look at examples to make sure that I'm getting my `foldl` and `foldr` straight. Maybe it's because my brain is small, but we don't want to exclude people with small brains! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11065> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[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] #11051: GHCi with +t option set shows type representations
by GHC 21 Jan '16

21 Jan '16

#11051: GHCi with +t option set shows type representations -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- hvr reported this morning that defining a data type in GHCi with the show types (`:set +t`) option set results in additional unexpected output. For instance, {{{ $ inplace/bin/ghc-stage2 --interactive GHCi, version 7.11.20151101: http://www.haskell.org/ghc/ :? for help Prelude> :set +t Prelude> data Hi $tcHi :: TyCon $trModule :: Module data Hi Prelude> }}} The `$tcHi` and `$trModule` bindings are details of the Typeable implementation introduced in Phab:D1404 and should likely be hidden from the user. This would be trivial to fix except for the fact that we currently have no way to identify this sort of `Name`. In fact any knowledge that the name was generated appears to have been thrown away as early as `OccName.mkTyConRepSysOcc`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11051> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[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] #10958: "Annotating pure code for parallelism" docs based on old par/pseq primitives
by GHC 18 Jan '16

18 Jan '16

#10958: "Annotating pure code for parallelism" docs based on old par/pseq primitives -------------------------------------+------------------------------------- Reporter: robstewartuk | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Documentation | Version: 7.10.2 Keywords: parallelim | 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 example code in GHC 7.10.2 docs "7.28. Concurrent and Parallel Haskell", then in "7.15.4. Annotating pure code for parallelism" the recommendation is to use `par` and `pseq`. These primitives pre-dates the strategy combinators `rpar` and `rseq`. The example given is: {{{#!hs import Control.Parallel nfib :: Int -> Int nfib n | n <= 1 = 1 | otherwise = par n1 (seq n2 (n1 + n2 + 1)) where n1 = nfib (n-1) n2 = nfib (n-2) }}} The paper "Seq no more: Better Strategies for Parallel Haskell" ([http://www.macs.hw.ac.uk/~hwloidl/publications/strategies10.pdf] advocates `Eval` as an "evaluation order" monad, as preferable (versus `par` and `seq`) for loose control of evaluation order of parallelism. Moreover, Simon Marlow's "Parallel and Concurrent Programming in Haskell" doesn't mention the `par` and `seq` primitives at all. Should the GHC docs for "Concurrent and Parallel Haskell" encourage the use Eval combinators, either in addition to or instead of the `par` and `seq` primitives? I'd be happy to contribute an update to the docs if people agree to a shift in emphasis towards the Eval monad in the docs. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10958> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11058: selected processor does not support ARM mode
by GHC 18 Jan '16

18 Jan '16

#11058: selected processor does not support ARM mode --------------------------------+---------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: arm | Type of failure: Building GHC failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+---------------------------------------- Building GHC-7.10.3-rc1 on Debian armel produces: {{{ "inplace/bin/ghc-stage1" -static -H32m -O -lffi -optl-pthread -optl-B/usr/bin/ld.gold -Iincludes -Iincludes/dist -Iincludes/dist- derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-package-key rts -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -c rts/StgStartup.cmm -o rts/dist/build/StgStartup.o /tmp/ghcd0b9_0/ghc_7.s: Assembler messages: /tmp/ghcd0b9_0/ghc_7.s:96:0: Error: selected processor does not support ARM mode `ldrd r0,r1,[r3,#64]' /tmp/ghcd0b9_0/ghc_7.s:99:0: Error: selected processor does not support ARM mode `strd r0,r1,[r3,#64]' /tmp/ghcd0b9_0/ghc_7.s:210:0: Error: selected processor does not support ARM mode `ldrd r0,r1,[r7,#64]' /tmp/ghcd0b9_0/ghc_7.s:214:0: Error: selected processor does not support ARM mode `strd r0,r1,[r7,#64]' rts/ghc.mk:236: recipe for target 'rts/dist/build/StgStartup.o' failed make[3]: *** [rts/dist/build/StgStartup.o] Error 1 Makefile:71: recipe for target 'all' failed make[2]: *** [all] Error 2 }}} According to Austin, this is fallout from changeset:933adc0f31164cb651d11ecfcfe612ac429f714f/ghc / #10375. But it is also a regression from GHC-7.10.2. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11058> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15