September 2015 - ghc-tickets

[GHC] #10866: Big discovered while installing stack.
by GHC 11 Sep '15

11 Sep '15

#10866: Big discovered while installing stack. -------------------------------------+------------------------------------- Reporter: | Owner: MichaelOChurch | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: MacOS X Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Below is a dump of the output while trying to build and install stack. Console output told me to report as a GHC bug, so that's what I'm doing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10866> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #7687: ghc panic on TH and deriveJSON
by GHC 11 Sep '15

11 Sep '15

#7687: ghc panic on TH and deriveJSON -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.4.2 Resolution: | Keywords: TH Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: 3658 | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => infoneeded Comment: I get the same error @George got. So something changed in aeson and/or hashable. I'll mark this as info needed as two people couldn't reproduce it on a newer GHC -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7687#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4426: Simplify the rules for implicit quantification
by GHC 10 Sep '15

10 Sep '15

#4426: Simplify the rules for implicit quantification -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: highest | Milestone: 7.12.1 Component: Compiler | Version: 6.12.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7880 | Differential Revisions: Phab:D211 -------------------------------------+------------------------------------- Comment (by kanetw): Is anyone working on the changes Simon mentioned? Otherwise I'll go ahead and implement them. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4426#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10861: `configure -C` yields different results on second run
by GHC 09 Sep '15

09 Sep '15

#10861: `configure -C` yields different results on second run -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.10.2 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Autoconf has a feature to cache the results of a configure run (using `configure -C`), and use it in subsequent runs. It greatly speeds up those subsequent runs. * http://www.gnu.org/software/autoconf/manual/autoconf-2.66/html_node /Cache-Files.html#Cache-Files * http://www.gnu.org/software/autoconf/manual/autoconf-2.66/html_node /Caching-Results.html At least the `FP_GCC_VERSION` macro in aclocal.m4 is currently buggy. The call to AC_CACHE_CHECK should only set the cache variable (fp_cv_gcc_version), but it also sets others (GccLT34 and GccLT44) (side question: how do those interact with clang?). This means that subsequent runs of `configure -C` won't use the right values for GccLT34 and GccLT44, when your gcc is actually older than those. There are likely other bugs. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10861> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1830: Automatic derivation of Lift
by GHC 09 Sep '15

09 Sep '15

#1830: Automatic derivation of Lift -------------------------------------+------------------------------------- Reporter: guest | Owner: | RyanGlScott Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Template Haskell | Version: 6.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1168 -------------------------------------+------------------------------------- Comment (by simonpj): See also [wiki:ValidateMonoLiterals] for a use-case. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1830#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2595: Implement record update for existential and GADT data types
by GHC 09 Sep '15

09 Sep '15

#2595: Implement record update for existential and GADT data types -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: tc244 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): See also #10856, which may be the last missing piece of the puzzle. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2595#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10157: HSCOLOUR_SRCS=YES fails mysteriously when no HsColour executable available
by GHC 09 Sep '15

09 Sep '15

#10157: HSCOLOUR_SRCS=YES fails mysteriously when no HsColour executable available -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Build | Version: 7.11 System | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- We seem to fill in the `--with-hscolour=` flag with an empty string, which causes a plain old build failure. Configure probably ought to fail if `HSCOLOUR_SRCS=YES` and there is no hscolours. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10157> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10486: Allow addTopDecls to create annotations
by GHC 08 Sep '15

08 Sep '15

#10486: Allow addTopDecls to create annotations -------------------------------------+------------------------------------- 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 addTopDecls is [https://github.com/ghc/ghc/blob/228ddb95ee137e7cef02dcfe2521233892dd61e0/co… restricted] to creating function, value, and foreign import declarations. Lifting this restriction allows one to create annotations without any issues, as far as I can tell. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10486> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL)
by GHC 08 Sep '15

08 Sep '15

#3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL) ---------------------------------+--------------------------------- Reporter: jeffz1 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: GHCi | Version: 7.4.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: 3658 | Blocking: Related Tickets: #7097 | Differential Revisions: ---------------------------------+--------------------------------- Changes (by vagarenko): * cc: vagarenko (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3242#comment:33> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10788: performance regression involving minimum (and maybe Vector)
by GHC 08 Sep '15

08 Sep '15

#10788: performance regression involving minimum (and maybe Vector) -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- This program (taken from http://stackoverflow.com/questions/32158319 /difference-in-performance-for-coin-change-between-haskell-and-c) runs about 50% slower when compiled with `ghc-7.10.1 -O` compared to `ghc-7.8.4 -O`. {{{ import Data.Vector.Unboxed as U ((!), constructN, length) coinchangev :: Int -> [Int] -> Int coinchangev n cs = v ! n where v = constructN (n+1) f f w = case U.length w of 0 -> 0 m -> 1 + minimum [w ! x | x <- map (m-) cs, x >= 0] main = print $ coinchangev 10000000 [1, 5, 10, 25, 100] }}} However if I change `minimum` to `sum`, while the runtime in 7.8.4 is unchanged, the runtime in 7.10.1 drops by a factor of 5! Allocations also decrease by a large factor. So my guess is that something has gone wrong with call arity analysis for `minimum` (and gone very right for `sum`). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10788> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16