August 2014 - ghc-tickets

[GHC] #8897: Can't change "Full Name" in preferences
by GHC 24 Sep '14

24 Sep '14

#8897: Can't change "Full Name" in preferences ------------------------------------+------------------------------------- Reporter: novadenizen | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I mistyped my Full Name when I registered my account. I try to change it from preferences and I get an error message "Warning: The email address specified is already in use. Please specify a different one." -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8897> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8070: Use a captcha for trac registrations
by GHC 24 Sep '14

24 Sep '14

#8070: Use a captcha for trac registrations ------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: high | Milestone: Component: None | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Use a captcha for trac registrations. These all seem to be 0.11-only: * http://trac-hacks.org/wiki/CaptchaAuthPlugin * http://trac-hacks.org/wiki/CaptchaAuthPlusPlugin * http://trac-hacks.org/wiki/SimpleCaptchaPlugin so the simplest answer might be recaptcha, although I believe that needs to be set up to be associated with a Google account: * http://trac-hacks.org/wiki/RecaptchaRegisterPlugin -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8070> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #8836: ghc 7.6.3 (Linux) hangs on -O2
by GHC 23 Sep '14

23 Sep '14

#8836: ghc 7.6.3 (Linux) hangs on -O2 ------------------------------+-------------------------------------------- Reporter: tsuraan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC doesn't work at all Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- I haven't had any luck finding a minimal test case for this, but the following replicates the issue on my two Linux machines running ghc 7.6.3: git clone https://github.com/tsuraan/optimal-blocks cd optimal-blocks git checkout bceee69f9f03d2e559f96cdf58412ada09c96a8c cabal sandbox init cabal install --only-dependencies cabal configure cabal build Cabal build will successfully build Algorithm.OptimalBlocks.SipHash and Algorithm.OptimalBlocks.BuzzHash, and it will attempt to build Algorithm.OptimalBlocks, but it will hang forever, using 100% of a single core. I have no idea how to debug this, but in src/Algorithm/OptimalBlocks.hs, if you replace the "in Blocks (reverse rlist) end" with "in Blocks [] bs", it will compile. Also, if that same file starts with the line "{-# OPTIONS_GHC -O1 #-}" it will compile. This also happens on my Mac running OSX 10.8.5 and ghc 7.4.2 without llvm; I have to tweak the .cabal file a little to drop the lower bound on base and to get rid of the "-fllvm" flag, but if I do that I see the exact same behaviour. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8836> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #8918: Network package doesn't load under GHC 7.8 RC on windows (?)
by GHC 22 Sep '14

22 Sep '14

#8918: Network package doesn't load under GHC 7.8 RC on windows (?) -------------------------------------+--------------------------------- Reporter: dmcclean | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 7.8.1-rc1 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+--------------------------------- (Please note that I am not certain that this issue is related to the 7.8 release candidate specifically, it may be some peculiarity of my system. But the same thing does work for me under 7.6.3 on the same machine. I don't understand exactly what the message is complaining about, so I don't feel confident in making a diagnosis. I don't know if the problem is me, the library, or ghc.) Under the GHC 7.8 rc1 build for Windows that I installed, I can't load the network package. In the course of upgrading one of my projects, I cabal install'd the network-conduit package, and network is one of the dependencies. The install worked fine, with the usual sprinkling of deprecation warnings and "rule might not fire because..." warnings, nothing that seemed unusual or alarming. I can't however actually load the package. {{{ GHCi, version 7.8.20140130: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package bytestring-0.10.4.0 ... linking ... done. Loading package containers-0.5.4.0 ... linking ... done. Loading package Win32-2.3.0.1 ... linking ... done. Loading package filepath-1.3.0.2 ... linking ... done. Loading package old-locale-1.0.0.6 ... linking ... done. Loading package time-1.4.1 ... linking ... done. Loading package directory-1.2.0.2 ... linking ... done. Loading package base-unicode-symbols-0.2.2.4 ... linking ... done. Loading package transformers-0.3.0.0 ... linking ... done. Loading package transformers-base-0.4.1 ... linking ... done. Loading package monad-control-0.3.2.3 ... linking ... done. Loading package lifted-base-0.2.2.1 ... linking ... done. Loading package mmorph-1.0.2 ... linking ... done. Loading package mtl-2.1.2 ... linking ... done. Loading package resourcet-0.4.10 ... linking ... done. Loading package text-1.1.0.1 ... linking ... done. Loading package text-stream-decode-0.1.0.4 ... linking ... done. Loading package hashable-1.2.1.0 ... linking ... done. Loading package nats-0.1.2 ... linking ... done. Loading package unordered-containers-0.2.3.3 ... linking ... done. Loading package semigroups-0.12.2 ... linking ... done. Loading package void-0.6.1 ... linking ... done. Loading package conduit-1.0.15.1 ... linking ... done. Loading package parsec-3.1.5 ... linking ... done. Loading package network-2.4.2.2 ... linking ... ghc.exe: warning: inet_ntoa from ws2_32 is linked instead of __imp_inet_ntoa ghc.exe: C:\Users\Doug\Documents\GitHub\bird-brain\.cabal-sandbox\x86_64 -windows-ghc-7.8.20140130\network-2.4.2.2\libHSnetwork-2.4.2.2.a: unknown symbol `WspiapiGetNameInfo' ghc.exe: unable to load package `network-2.4.2.2' }}} (The good bit was way at the end of a line, so repeated where you can see it...) {{{ network-2.4.2.2\libHSnetwork-2.4.2.2.a: unknown symbol `WspiapiGetNameInfo' }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8918> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 6

[GHC] #9528: typo in man-page/docs
by GHC 19 Sep '14

19 Sep '14

#9528: typo in man-page/docs -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Documentation | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- "rrestriction" in ghc/docs/users_guide/flags.xml -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9528> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8097: internal error: getMBlock: mmap: Operation not permitted
by GHC 18 Sep '14

18 Sep '14

#8097: internal error: getMBlock: mmap: Operation not permitted ------------------------------+---------------------------------- Reporter: singpolyma | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.2 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------+---------------------------------- I get the following: {{{ <interactive>: internal error: getMBlock: mmap: Operation not permitted (GHC version 7.4.2 for i386_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) }}} when running {{{parseOnly queryKeyParse (Data.Text.pack "hello")}}} where: {{{ queryKeyParse :: Attoparsec.Parser [T.Text] queryKeyParse = do top <- Attoparsec.takeTill (=='[') keys <- many key return (top:keys) where key = many (Attoparsec.char '[') *> Attoparsec.takeTill (==']') <* many (Attoparsec.char ']') }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8097> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8899: StdGen does not generate 0
by GHC 17 Sep '14

17 Sep '14

#8899: StdGen does not generate 0 ------------------------------------+------------------------------------- Reporter: novadenizen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/random | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- `genRange` for `StdGen` returns `(0,2147483562)`. However, as far as I can tell, `StdGen` doesn't generate 0. This code performs 200 billion iterations of `next` on a `StdGen`. I ran it and it output `Nothing`. The probability that no 0 was generated by chance is approximately ''e^-200/2.147^'' =~ ''10^-40^''. {{{#!haskell import System.Random import Data.Int find0 :: StdGen -> Int64 -> Maybe Int64 find0 g0 n0 = aux g0 n0 where aux _ 0 = Nothing aux g r = let (v,g') = next g in if v == 0 then Just (n0 - r + 1) else aux g' (r-1) main :: IO () main = print $ find0 (mkStdGen 1234) 200000000000 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8899> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #9400: poor performance when compiling modules with many Text literals at -O1
by GHC 16 Sep '14

16 Sep '14

#9400: poor performance when compiling modules with many Text literals at -O1 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Compile- Blocked By: | time performance bug Related Tickets: #9370 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- (Spawned from #9370; see there for original discussion) Unpack the xmlhtml package and edit `src/Text/XmlHtml/HTML/Meta.hs` and remove the `OPTIONS_GHC` line at the top of the file that disables optimizations and build with `cabal buidl`. Then GHC takes ~1.5GB and over a minute to build this single module. Preliminary investigation indicates that Text's fromString and its constituent parts is being inlined repeatedly: {{{ Inlining done: Data.String.fromString Inlining done: Data.Text.$fIsStringText Inlining done: Data.Text.pack Inlining done: Data.Text.Internal.Fusion.unstream Inlining done: Data.Text.Internal.Fusion.Common.map Inlining done: Data.Text.Internal.Fusion.Common.streamList Inlining done: Data.Text.Internal.safe Inlining done: Data.Bits.$fBitsInt_$c.&. Inlining done: Data.Text.Internal.Fusion.Types.$WYield [ repeats ~4000 times ] }}} resulting in a very large intermediate program: {{{ *** Checking old interface for xmlhtml-0.2.3.2:Text.XmlHtml.HTML.Meta: [ 1 of 10] Compiling Text.XmlHtml.HTML.Meta ( src/Text/XmlHtml/HTML/Meta.hs, dist/build/Text/XmlHtml/HTML/Meta.o ) *** Parser: *** Renamer/typechecker: *** Desugar: Result size of Desugar (after optimization) = {terms: 26,260, types: 20,021, coercions: 0} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 1,446,658, types: 953,432, coercions: 314,352} ... }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9400> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #9534: IEEE Standard 754 for Binary Floating-Point Arithmetic by Prof. W. Kahan, UCB
by GHC 10 Sep '14

10 Sep '14

#9534: IEEE Standard 754 for Binary Floating-Point Arithmetic by Prof. W. Kahan, UCB -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Keywords: IEEE754 | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less | Type of failure: Incorrect than a day) | result at runtime Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The attached is an implementation of the floating point accuracy test described in ''The Baleful Influence of Benchmarks'' section of http://www.eecs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF {{{ Results for Float: r = 4098.0 produces 12.0 and 12.0 sig. bits r = 4098.25 fails: root 0.99989897 isn't at least 1 <<<< r = 4097.004 produces 12.0 and 11.999298 sig. bits : Worst accuracy is 11.999298 sig. bits : Results for Double: r = 4098.0 produces Infinity and Infinity sig. bits r = 4098.25 produces Infinity and 53.0 sig. bits r = 4097.00390625 produces Infinity and 53.451178091541244 sig. bits r = 1.6777218e7 produces Infinity and Infinity sig. bits r = 1.677721825e7 produces Infinity and 75.0 sig. bits r = 1.6777219e7 produces Infinity and 71.0 sig. bits r = 9.4906267e7 produces 26.499999994288153 and 26.499999986733027 sig. bits r = 9.490626725e7 fails: root 0.999999995635551 isn't at least 1 <<< r = 2.684354505e8 produces 28.0 and 27.999999919383132 sig. bits r = 2.684354515e8 produces 28.0 and 27.99999993013205 sig. bits r = 2.68435458e8 produces 28.0 and 28.0 sig. bits r = 2.6843545825e8 produces 28.0 and 28.00000000268723 sig. bits r = 2.6843545700000006e8 produces 28.0 and 27.999999989251084 sig. bits r = 4.294967298e9 produces 32.0 and 32.0 sig. bits r = 4.29496729825e9 produces 32.0 and 32.00000000016795 sig. bits Worst accuracy is 26.499999986733027 sig. bits }}} This seems to be comparable to a clang version, but seems to be fairly poor in comparison to some other machines, back in the day (1997). '''The attached could, possibly be turned into a testsuite test, by removing the QuickCheck tests that are included.''' Observations: * There are a couple of failures (could be the implementation of sqrt or log). * signum seems incorrect (signum Nan = -1.0) * The prelude should have a copysign function * min fails to produce the other argument if one argument is NaN * The CFloat and CDouble variants seem to produce the same result as the native Float and Double versions * The Haskell coding style could be improved to remove some boilerplate, make the code more idiomatic * There may be a better way of entering the test values of r to ensure that they are accurate -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9534> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9449: GHC.Prim documentation says "Safe Inferred"
by GHC 05 Sep '14

05 Sep '14

#9449: GHC.Prim documentation says "Safe Inferred" -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Documentation | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The Haddock docs for GHC.Prim (for example, [http://haddocks.fpcomplete.com/fp/7.7/20131212-1/ghc-prim/GHC-Prim.html here]) says that it is Safe-Inferred. This is very bogus. When testing, I was (happily) unable to import `GHC.Prim` into a `Safe` module, so I think this is just a documentation bug. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9449> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4