January 2016 - ghc-tickets

Re: [GHC] #2140: cpuTimePrecision is wrong
by GHC 05 Jan '16

05 Jan '16

#2140: cpuTimePrecision is wrong -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Core Libraries | Version: 6.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * failure: None/Unknown => Documentation bug -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2140#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10728: Add e.g. "-N<=4" in addition to the fixed "-N4" and variable "-N" RTS options
by GHC 05 Jan '16

05 Jan '16

#10728: Add e.g. "-N<=4" in addition to the fixed "-N4" and variable "-N" RTS options -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: simonmar Type: feature | Status: new request | Priority: normal | Milestone: Component: Runtime | 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: | -------------------------------------+------------------------------------- As discussed in this issue: https://github.com/commercialhaskell/stack/issues/680 stack is one example of a program that optimistically turned on "-N". Indeed, it feels like a reasonable and even safe option for a multithreaded program. Unfortunately, -N currently guarantees bad performance on large machines and especially on large machines with hyperthreading. Pretty much one should ship an executable with -N by default as of GHC 7.8 and 7.10 IMHO. Unfortunately, even if stack did get a speedup at, say, 4 or 8 cores, it would not be good to ship it with "-N8" either. This would be an unreasonable choice on small, one or two core machines. What we need is a way to say that the program can productively use parallelism up to a certain upper bound, but that fewer threads should be used if there are not enough cores available. I propose "-N<=8" as a potential syntax. Currently, this behavior can be achieved with `setNumCapabilities`/`getNumProcessors`, but I think it's worth a command line RTS option. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10728> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 25

Re: [GHC] #2140: cpuTimePrecision is wrong (was: cpuTimePrecision is wrong for me on Windows (XP))
by GHC 05 Jan '16

05 Jan '16

#2140: cpuTimePrecision is wrong -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Core Libraries | Version: 6.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: ekmett (added) * failure: => None/Unknown * architecture: x86_64 (amd64) => Unknown/Multiple * milestone: 8.0.1 => * os: Windows => Unknown/Multiple Comment: The module `CPUTime` is part of the [https://www.haskell.org/onlinereport/cputime.html Haskell 98 report] (but not the Haskell 2010 report). Computation `getCPUTime` returns the number of picoseconds of CPU time used by the current program. The precision of this result is given by `cpuTimePrecision`. This is the smallest measurable difference in CPU time that the implementation can record, and is given as an integral number of picoseconds. == getCPUTime == > getCPUTime always returns a multiple of 15625000000 http://stackoverflow.com/a/29164665 explains this as follows: the clock is updated 64 times per second, at the clock tick interrupt. Or in other words 1 / 64 = 0.015625 between ticks And `0.015625 seconds = 15625000000 picoseconds`. == cpuTimePrecision == The current implementation of `cpuTimePrecision` looks at the value of `clockTicks = clk_tck()` (see #7519), converted to picoseconds. On my Linux system, `clk_tck` calls `sysconf(_SC_CLK_TCK)` and always returns `100` (see `libraries/base/cbits/sysconf.c`, and note that `CLK_TCK` is only defined when `#undef __USE_XOPEN2K`, see `/usr/include/time.h` and `/usr/include/x86_64-linux-gnu/bits/time.h`). On Windows, `clk_tck` seems to always return `CLK_TCK = 1000` (see `./opt/ghc-7.10.3/mingw/x86_64-w64-mingw32/include/time.h`). These values don't seem related in any way to the precision of `getCPUTime`. From `man sysconf`: clock ticks - _SC_CLK_TCK The number of clock ticks per second. The corresponding vari‐ able is obsolete. It was of course called CLK_TCK. (Note: the macro CLOCKS_PER_SEC does not give information: it must equal 1000000.) According to this [http://stackoverflow.com/questions/19919881/sysconf-sc- clk-tck-what-does-it-return?rq=1#comment29641173_19919970 stackoverflow comment]: it's the number of times the timer interrupts the CPU for scheduling and other tasks, 100Hz is a common value, higher frequency equals higher timer resolution and more overhead. == Solution ? == > Does anyone happen to know where we can get real values for this for any platforms? I don't know, but on Windows, you can supposedly use [https://msdn.microsoft.com/en- us/library/windows/desktop/ms724394%28v=vs.85%29.aspx GetSystemTimeAdjustment]. Some more discussion here: http://lists.ntp.org/pipermail/questions/2011-September/030583.html. But maybe we should just give up, since `CPUTime` is not part of the Haskell report anymore. Keep the function `cpuTimePrecision` for backward compatibility, but change the docstring to say what it really does: return the number of picoseconds between clock ticks. This issue was also discussed in this thread: https://mail.haskell.org/pipermail/libraries/2008-February/009305.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2140#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8560: undeducable Typeable error with data kinds when deriving Data for GADT in GHC version 7.7.20131122
by GHC 05 Jan '16

05 Jan '16

#8560: undeducable Typeable error with data kinds when deriving Data for GADT in GHC version 7.7.20131122 ------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- This may be an artifact of issue #8128 (see https://ghc.haskell.org/trac/ghc/ticket/8128#comment:5) but I'm seeing examples involving data kinds where Typeable isn't deducible. This could be an artifact of other problems, BUT since with 7.7 onwards, we have baked in polykinded Typeable, things should always "just work™" right? the error with current head is as follows (and i'm attaching the code + current finger print too) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8560> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

Re: [GHC] #7459: deriving Generic does not work with TypeLits
by GHC 05 Jan '16

05 Jan '16

#7459: deriving Generic does not work with TypeLits -------------------------------------+------------------------------------- Reporter: maxtaldykin | Owner: dreixel Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => Generics -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7459#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9968: DeriveAnyClass fails on multi-parameter type classes
by GHC 05 Jan '16

05 Jan '16

#9968: DeriveAnyClass fails on multi-parameter type classes -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When I say {{{ {-# LANGUAGE DeriveAnyClass, MultiParamTypeClasses #-} module Bug where class C a b data X deriving (C Int) }}} and load that into GHCi, I see this: {{{ *Main> :load "/Users/rae/temp/DeriveAny.hs" [1 of 1] Compiling Bug ( /Users/rae/temp/DeriveAny.hs, interpreted ) Var/Type length mismatch: [b_a2YW] [] Var/Type length mismatch: [b_a2YW] [] Ok, modules loaded: Bug. *Bug> :info C class C a b -- Defined at /Users/rae/temp/DeriveAny.hs:5:1 instance C X -- Defined at /Users/rae/temp/DeriveAny.hs:7:13 }}} It seems my `Int` parameter to `C` is being dropped. I don't believe I have a debug build in this example, so that debugging output is shipping. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9968> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #10487: Unhelpful error from instance Generic
by GHC 05 Jan '16

05 Jan '16

#10487: Unhelpful error from instance Generic -------------------------------------+------------------------------------- Reporter: | Owner: andreas.abel | Status: new Type: bug | 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: | -------------------------------------+------------------------------------- That's the error you like too see, or rather not. ;( {{{ [180 of 289] Compiling Agda.TypeChecking.Serialise ( src/full/Agda/TypeChecking/Serialise.hs, dist-2.4.2.4/build/Agda/TypeChecking/Serialise.o ) src/full/Agda/TypeChecking/Serialise.hs:1:1: Duplicate instance declarations: instance GHC.Generics.Datatype Agda.TypeChecking.Serialise.D1Name -- Defined at src/full/Agda/TypeChecking/Serialise.hs:1:1 instance GHC.Generics.Datatype Agda.TypeChecking.Serialise.D1Name -- Defined at src/full/Agda/TypeChecking/Serialise.hs:1:1 src/full/Agda/TypeChecking/Serialise.hs:1:1: Duplicate instance declarations: instance GHC.Generics.Constructor Agda.TypeChecking.Serialise.C1_0Name -- Defined at src/full/Agda/TypeChecking/Serialise.hs:1:1 instance GHC.Generics.Constructor Agda.TypeChecking.Serialise.C1_0Name -- Defined at src/full/Agda/TypeChecking/Serialise.hs:1:1 }}} Problems: * no position in file * system generated names D1Name, C1_0Name * obvious bogus (same instance cannot be defined twice at same location) * leads me to suspect bug in Generics rather than in my code Reproduce: * git clone agda/agda from github, * checkout this commit https://github.com/agda/agda/commit/46823536559276807639488eae151a0e855fdb95 * and try to compile with {{{ make install-bin }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10487> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #10716: Metadata in GHC.Generic should give access to strictness annotation
by GHC 05 Jan '16

05 Jan '16

#10716: Metadata in GHC.Generic should give access to strictness annotation -------------------------------------+------------------------------------- Reporter: StefanWehr | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | 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 Revisions: | -------------------------------------+------------------------------------- Currently, the metadata in the GHC.Generics module do not give access to the strictness annotations attached to a field of a datatype. It would be great if this piece of information could be added. Background: we are using a class FullyStrict for ensuring that a datatype is fully strict (in the sense that all fields have bang patterns and the types of all fields are also fully strict). Currently we are using TemplateHaskell to derive the instances automatically. The TemplateHaskell function also checks that all fields have bang patterns. To improve compilation speed, I would like to derive the instances with DeriveGeneric. But this is not possible because then I cannot implement the check whether all fields have bang patterns. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10716> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

Re: [GHC] #7492: Generic1 deriving: Can we replace Rec1 f with f :.: Par1?
by GHC 05 Jan '16

05 Jan '16

#7492: Generic1 deriving: Can we replace Rec1 f with f :.: Par1? -------------------------------------+------------------------------------- Reporter: spl | Owner: dreixel Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => Generics -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7492#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5945: Lambda lifting
by GHC 05 Jan '16

05 Jan '16

#5945: Lambda lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.4.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #11284, #9476 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: #11284 => #11284, #9476 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5945#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0