April 2016 - ghc-tickets

[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

[GHC] #11950: Eventlog should include delimiters showing when the process writes to the .eventlog file
by GHC 19 May '16

19 May '16

#11950: Eventlog should include delimiters showing when the process writes to the .eventlog file -------------------------------------+------------------------------------- Reporter: JamesFisher | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Runtime | Version: 7.10.3 System | 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: -------------------------------------+------------------------------------- Quoting a comment I just added at https://ghc.haskell.org/trac/ghc/wiki/EventLog#Limitations : > Event logging can produce "observer effects". In particular, programs can pause while writing to the `.eventlog` file. These display in Threadscope as periods of 100% CPU use with no obvious cause. This effect is exacerbated by heavy use of debug tools which expand the eventlog file, such as `Trace.traceMarkerIO`. (This effect was at least seen on OS X. In an extreme case, a program doing nothing but writing 200,000 trace markers, which took 120 ms to run, showed a single 10ms pause in the middle to write them to the `.eventlog` file. These periods were shown to be due to writing the `.eventlog` file by using `dtruss -a`, which shows long periods of `write_nocancel` syscalls, writing to the `.eventlog` file opened earlier with `open_nocancel`.) This behavior caused a few hours of investigation for us. It would make it much more obvious what is happening if this behavior were logged in the eventlog. Specifically, I would like for the eventlog to include a "starting writing eventlog file" event at the start of each of these periods, and a "stopped" event at the end of each period. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11950> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #11946: Provide a `make uninstall` target
by GHC 19 May '16

19 May '16

#11946: Provide a `make uninstall` target -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: -------------------------------------+------------------------------------- Currently there is no clean way to uninstall GHC built from source. The makefiles should provide an uninstall target that allows this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11946> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11808: nofib's cryptarithm1 regresses due to deferred inlining of Int's Ord operations
by GHC 19 May '16

19 May '16

#11808: nofib's cryptarithm1 regresses due to deferred inlining of Int's Ord operations -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Commit d1179c4bff6d05cc9e86eee3e2d2cee707983c90 [[https://perf.haskell.org/ghc/#revision/d1179c4bff6d05cc9e86eee3e2d2cee70798…]] causes a ~5% regression in runtime in nofib's `cryptarithm1` benchmark. Need to work out why. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11808> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11805: Ability to use record fields for automatic derivation of user-defined classes.
by GHC 19 May '16

19 May '16

#11805: Ability to use record fields for automatic derivation of user-defined classes. -------------------------------------+------------------------------------- Reporter: Tientuine | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | 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: -------------------------------------+------------------------------------- I propose that the compiler be empowered to automatically derive a user- defined class when a data type has fields that match (in both name and type) methods sufficient for a minimal complete definition of the class. (There is some overlap between this idea and the much larger and more contentious issue of extensible records generally.) I am relatively new to Haskell, but have quickly run into the problem of field namespacing. As a simple example, suppose we are creating a game with data types for Room and Item, and values of each of these types will have a short name and a long description (possibly among other fields not detailed here). Currently, we must name our fields differently, as in: {{{#!hs -- ugh! prefixing the field names is ugly and tedious data Room = Room { rname :: String, rdescribe :: String, item :: Maybe Item } data Item = Item { iname :: String, idescribe :: String, value :: Int } }}} Classes seem a natural solution to this problem, but then we must either have superfluous field names or drop the use of field names altogether: {{{#!hs -- extracting a common interface as a class makes sense type Desc d where name :: d -> String describe :: d -> String -- but now we either keep the ugly prefixed fields or drop fields entirely data Room = Room String String (Maybe Item) data Item = Item String String Int -- furthermore, it is tedious to implement these trivial observers instance Desc Room where name (Room n _ _) = n describe (Room _ d _) = d instance Desc Item where name (Item n _ _) = n describe (Item _ d _) = d }}} My proposal is to allow the compiler to rely on fields in order to automatically derive a user-defined class. This solves a couple of problems in a way that (I hope) is not excessively complex to implement. Such a feature would allow us to write code like the following: {{{#!hs -- class as a common interface still feels natural type Desc d where name :: d -> String describe :: d -> String -- now we get shared field names and let the compiler do some of the work data Room = Room { name :: String, describe :: String, item :: (Maybe Item) } deriving Desc data Item = Item { name :: String, describe :: String, value :: Int } deriving Desc }}} Obviously, there are a couple of restrictions here: * fields of the same name in different records must have the same type * fields of the same name in different records are still ambiguous (no different than the current situation) if we do //not// derive a class that declares those field names * this is //not// intended to be a general solution for either extensible records or deriving classes automatically, it is very limited in scope P.S. This is my first Ticket and attempt to get involved in the community, and I'm not yet sure of the correct tags to use. Please be gentle. :) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11805> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11429: Make unrecognised `-W` flags a warning rather than an error
by GHC 19 May '16

19 May '16

#11429: Make unrecognised `-W` flags a warning rather than an error -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature | Status: new request | Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 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: Design/Warnings -------------------------------------+------------------------------------- Currently, it's a fatal error to pass GHC a warning flag it doesn't recognise: {{{ $ ghc-8.1.20160111 -Wfoobar -c foobar.hs ghc: unrecognised flag: -Wfoobar Usage: For basic information, try the `--help' option. }}} However, in order to gain more flexibility adding/removing warning flags without requiring users to carefully guard which flags a given GHC version supports, it was suggested to make GHC more tolerating in case of unrecognised warning flags (which may either have been removed, or not yet available in the current GHC version). Specifically, I propose the following: 1. Handle `-Wno-<token>` or `-W<token>` for an unknown `<token>` as a warning rather than an error 2. This warning gets its own token `unrecognised-warning-flag` (turned on by default), so that it can be controlled via the general warning facilities as well: - `-Wno-unrecognised-warning-flag` turns off such warnings - `-Wunrecognised-warning-flag` turns on such warnings explicitly - `-Werror=unrecognised-warning-flag` (once we have #11219) emulates the old behaviour - various other combinations with warning-sets, `-Werror` specifications -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11429> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11