May 2016 - ghc-tickets

Re: [GHC] #12037: Shutdown interacts badly with requestSync()
by GHC 19 May '16

19 May '16

#12037: Shutdown interacts badly with requestSync() -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 7.10.3 Resolution: duplicate | 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): * status: new => closed * resolution: => duplicate Comment: Duplicate of #12038. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12037#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11831: Illegal Instruction when running byte operations in ghci
by GHC 19 May '16

19 May '16

#11831: Illegal Instruction when running byte operations in ghci ----------------------------------+------------------------------- Reporter: Kritzefitz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.3 Keywords: | Operating System: Linux Architecture: arm | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------+------------------------------- On a Debian armel machine I started ghci through `cabal repl` in bytes-0.15.2 an run the following commands, which reproducibly (for me) run into a crash: {{{#!hs > :m Data.Word Data.Binary.Put Data.Bits Data.Bytes.Put > runPut $ Data.Bytes.Put.putWord8 1 "\SOH" -- Exactly the same again: > runPut $ Data.Bytes.Put.putWord8 1 "Illegal instruction }}} Using `Data.Binary.Put.putWord8` instead of `Data.Bytes.Put.putWord8` doesn't lead to a crash, even though the only difference between the two is that the bytes version is an instance method. Using an installed version of `bytes` instead of compiling it with GHCi (in my case with `cabal repl`) doesn't crash. Some strange reactions during debugging this lead me to believe, that running some calculations between the two shown above can avert the crash, but I couldn't figure out, what exactly had to be done. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11831> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12013: CallStack is available from base 4.8, not 4.9
by GHC 19 May '16

19 May '16

#12013: CallStack is available from base 4.8, not 4.9 -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Documentation | Version: 7.10.3 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: -------------------------------------+------------------------------------- The documentation for `CallStack` claims it's available since 4.9 (ghc 8.0), but actually it's available since 4.8 (ghc 7.10). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12013> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12011: should runRW# (of GHC.Magic) be reexported by GHC.Exts?
by GHC 19 May '16

19 May '16

#12011: should runRW# (of GHC.Magic) be reexported by GHC.Exts? -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.0.1 libraries/base | 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: -------------------------------------+------------------------------------- GHC.Magic says that GHC.Exts should be used instead, but only 'lazy' and 'inline' are rexported there, 'oneshot' and 'runRW#' are both not provided by GHC.Exts is this an oversight or deliberate? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12011> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11996: coverage checker iteration flag isn't documented outside of release notes!
by GHC 19 May '16

19 May '16

#11996: coverage checker iteration flag isn't documented outside of release notes! -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.0.1 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: -------------------------------------+------------------------------------- as per https://ghc.haskell.org/trac/ghc/ticket/11195#comment:9 and the ghc 8.0rc release notes,`-fmax-pmcheck-iterations` is now a flag! its not listed as a documented flag, aside from mention in the release notes (though a search for pattern or matching will have a hard time turning it up) is this deliberate or not? (nb: not that i've used it, but making note of that subtlety) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11996> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #11992: RFC, add Suc to base
by GHC 19 May '16

19 May '16

#11992: RFC, add Suc to base -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: 8.1 libraries/base | 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: -------------------------------------+------------------------------------- {{{#!hs hasSuc :: Int -> Maybe Int hasSuc n = [ n - 1 | n > 0 ] pattern Suc :: Int -> Int pattern Suc n <- (hasSuc -> Just n) where Suc n = n + 1 }}} with a more general type -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11992> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9059: Excessive space usage while generating code for fractional literals with big exponents
by GHC 19 May '16

19 May '16

#9059: Excessive space usage while generating code for fractional literals with big exponents ------------------------------------+------------------------------------- Reporter: basvandijk | 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: | ------------------------------------+------------------------------------- Generating (byte-)code for fractional literals with big exponents causes excessive space usage: {{{ $ ghci -ddump-bcos GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> let r=1e1000 :: Rational ==================== Proto-BCOs ==================== ProtoBCO ExprTopLevel_E0#0 []: let sat_so4 = ... in ... bitmap: 0 [] ALLOC_AP 0 PUSH_BCO ProtoBCO sat_so4#0 []: let sat_snX = ... in ... bitmap: 0 [] PUSH_UBX (1) 1 PACK GHC.Integer.Type.S# 1 ALLOC_AP 0 PUSH_BCO ProtoBCO sat_snY#0 []: let sat_siH = ... in ... bitmap: 0 [] STKCHECK 544 PUSH_UBX (1) 30 PACK GHC.Types.I# 1 PUSH_G GHC.Types.[] PUSH_L 1 PACK : 2 PUSH_UBX (1) 953884573 PACK GHC.Types.I# 1 PUSH_LL 1 0 PACK : 2 PUSH_UBX (1) 1777164331 PACK GHC.Types.I# 1 PUSH_LL 1 0 PACK : 2 PUSH_UBX (1) 1665817172 PACK GHC.Types.I# 1 PUSH_LL 1 0 PACK : 2 PUSH_UBX (1) 1937337765 PACK GHC.Types.I# 1 PUSH_LL 1 0 PACK : 2 PUSH_UBX (1) 799142572 PACK GHC.Types.I# 1 PUSH_LL 1 0 PACK : 2 PUSH_UBX (1) 1439062260 PACK GHC.Types.I# 1 PUSH_LL 1 0 PACK : 2 PUSH_UBX (1) 1049546550 PACK GHC.Types.I# 1 PUSH_LL 1 0 PACK : 2 PUSH_UBX (1) 580758741 PACK GHC.Types.I# 1 PUSH_LL 1 0 PACK : 2 PUSH_UBX (1) 139570364 PACK GHC.Types.I# 1 PUSH_LL 1 0 PACK : 2 ... }}} Increasing the exponent to say a 1000000 will quickly fill up the memory of my machine. A similar problem occurs while compiling: !BigExponentBug.hs: {{{ module BigExponentBug (r) where r = 1e100 :: Rational }}} {{{ ghc --make BigExponentBug.hs -ddump-simpl [1 of 1] Compiling BigExponentBug ( BigExponentBug.hs, BigExponentBug.o ) ==================== Tidy Core ==================== Result size of Tidy Core = {terms: 9, types: 5, coercions: 0} BigExponentBug.r :: GHC.Real.Rational [GblId] BigExponentBug.r = GHC.Real.fromRational @ GHC.Real.Rational (GHC.Real.$fFractionalRatio @ GHC.Integer.Type.Integer (GHC.Real.$fNumRatio @ GHC.Integer.Type.Integer GHC.Real.$fIntegralInteger) GHC.Real.$fIntegralInteger) (GHC.Real.:% @ GHC.Integer.Type.Integer (__integer 10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000) (__integer 1)) }}} Again increasing the exponent to 1000000 quickly invokes the OOM killer on my machine. P.S. This bug was discovered while fixing a [https://github.com/bos/aeson/issues/198 related bug] in `aeson`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9059> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11989: Performance bug reading large-exponent float without explicit type
by GHC 19 May '16

19 May '16

#11989: Performance bug reading large-exponent float without explicit type -------------------------------------+------------------------------------- Reporter: bpearlmutter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.10.3 System | Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Test Case: 1e1000000 :: | Blocked By: (RealFloat a => a) | Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ $ time echo '1e700000' | ghci GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help Prelude> Infinity Prelude> Leaving GHCi. real 1m25.799s user 0m20.828s sys 0m9.624s $ time echo '1e700000::Double' | ghci GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help Prelude> Infinity Prelude> Leaving GHCi. real 0m0.196s user 0m0.120s sys 0m0.032s $ time echo 1e-800000 | ghci GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help Prelude> Killed real 2m8.879s user 0m6.684s sys 0m10.256s }}} Giving an explicit type `(RealFloat a => a)` doesn't make any difference. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11989> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11988: All ghc-compiled binaries seg-fault (on Windows)
by GHC 19 May '16

19 May '16

#11988: All ghc-compiled binaries seg-fault (on Windows) -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.1 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: -------------------------------------+------------------------------------- Bad news. On Windows, every binary built with GHC seg-faults. Even {{{ main = print “Hello” }}} Thus {{{ /cygdrive/c/tmp$ c:/code/HEAD/inplace/bin/ghc-stage1 Hello.hs [1 of 1] Compiling Main ( Hello.hs, Hello.o ) Linking Hello.exe ... /cygdrive/c/tmp$ ./Hello Segmentation fault/access violation in generated code }}} (And of course including the stage-2 compiler.) This started happening sometime in the last day or two; I don’t know exactly when. This is with a fresh tree, downloaded from the git repo, with config settings for validation. Might someone look at this? It’s pretty serious! Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11988> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11956: on osx 10.11 haddock --hyperlinked-source on ghc source fails with file resource exhausted
by GHC 19 May '16

19 May '16

#11956: on osx 10.11 haddock --hyperlinked-source on ghc source fails with file resource exhausted --------------------------------------+--------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc3 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- {{{ Warning: Module: moduleUnitId is exported separately but will be documented under Module. Consider exporting it together with its parent(s) for code clarity. Warning: Module: moduleName is exported separately but will be documented under Module. Consider exporting it together with its parent(s) for code clarity. Warning: Couldn't find .haddock for export typeKind Warning: Couldn't find .haddock for export liftedTypeKind haddock: internal error: compiler/HsVersions.h: openBinaryFile: resource exhausted (Too many open files) }}} theres also quite a few "cannot find link destination" style errors, see the attached file for that NB: the key bit for fixing this, at least in my local environment, is to do `ulimit -n 10000` before invoking make. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11956> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2