November 2015 - ghc-tickets

[GHC] #11022: Invalid ELF "note" section format
by GHC 17 Dec '15

17 Dec '15

#11022: Invalid ELF "note" section format ----------------------------------------+--------------------------- Reporter: hsyl20 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 7.10.2 Keywords: | Operating System: POSIX Architecture: Unknown/Multiple | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------- GHC adds a section called ".debug-ghc-link-info" to ELF binaries (see compiler/main/DriverPipeline.hs:1660). The section type is "note" (SHT_NOTE) but the format is not compliant with the ELF specification (see http://refspecs.linuxbase.org/elf/elf.pdf section 2 "Note section"). It makes tools reading sections with "note" type fail. I think we should change the section type to "progbits". Is there any problem with that? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11022> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #10662: GHC warning shows technical summary of AST instead of the user's code
by GHC 17 Dec '15

17 Dec '15

#10662: GHC warning shows technical summary of AST instead of the user's code -------------------------------------+------------------------------------- Reporter: kolmodin | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.2-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- I got a warning for some code I wrote; {{{#!hs forkIO (....) }}} Naturally GHC warns me that I'm throwing away the result, and should write like this; {{{#!hs _ <- forkIO (...) }}} However, the warning is expressed in a somewhat confusing way, not sure this is intentional. {{{ examples/route_guide_client.hs:84:5: Warning: A do-notation statement discarded a result of type ‘ThreadId’ Suppress this warning by saying ‘_ <- ($) forkIO let AbsBinds [] [] {Exports: [go <= go <>] Exported types: go :: [L.ByteString] -> IO () [LclId, Str=DmdType] Binds: go acc = ...} in go []’ or by using the flag -fno-warn-unused-do-bind }}} I find it confusing that the warning mentions AbsBinds, exports and types. I'd expect a snippet of my code in the warning. However, doesn't look like this is a (recent) regression. The same happens GHC 7.8.4 and 7.10.1. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10662> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #10034: Regression in mapM_ performance
by GHC 16 Dec '15

16 Dec '15

#10034: Regression in mapM_ performance -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.10.1-rc2 Libraries | Operating System: Unknown/Multiple Keywords: | Type of failure: Runtime Architecture: | performance bug Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: Phab:D632 | -------------------------------------+------------------------------------- The current `mapM_` is sometimes worse than the version in 7.8.3. This can be fixed easily by eta-expansion, matching `mapM`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10034> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #11067: Spurious superclass cycle error with type equalities
by GHC 16 Dec '15

16 Dec '15

#11067: Spurious superclass cycle error with type equalities -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Some of us today had an idea how to repair Edward Kmett's regrettably unsound `Data.Constraint.Forall` module. The method works fine in some cases, but seems to occasionally trigger a spurious superclass cycle error. In the cases I've seen so far, it seems to happen when a class is defined with a `Forall` superclass, where that `Forall` itself has as parameter another class, that itself has a type equality superclass. Example file (a bit larger than necessary to show how a similar example without a type equality ''doesn't'' give an error): {{{#!haskell {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE TypeFamilies #-} import Data.Monoid import GHC.Exts (Constraint) type family Skolem (p :: k -> Constraint) :: k type family SkolemF (p :: k2 -> Constraint) (f :: k1 -> k2) :: k1 -- | A quantified constraint type Forall (p :: k -> Constraint) = p (Skolem p) type ForallF (p :: k2 -> Constraint) (f :: k1 -> k2) = p (f (SkolemF p f)) -- These work class ForallF Monoid t => Monoid1 t instance ForallF Monoid t => Monoid1 t class ForallF Monoid1 t => Monoid2 t instance ForallF Monoid1 t => Monoid2 t -- Changing f a ~ g a to, (Ord (f a), Ord (g a)), say, removes the error class (f a ~ g a) => H f g a instance (f a ~ g a) => H f g a -- This one gives a superclass cycle error. class Forall (H f g) => H1 f g instance Forall (H f g) => H1 f g }}} And the resulting error: {{{ Test.hs:31:1: Cycle in class declaration (via superclasses): H1 -> Forall -> H -> H In the class declaration for ‘H1’ Test.hs:31:1: Cycle in class declaration (via superclasses): H1 -> Forall -> H -> H In the class declaration for ‘H1’ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11067> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #9276: audit ghc floating point support for IEEE (non)compliance
by GHC 16 Dec '15

16 Dec '15

#9276: audit ghc floating point support for IEEE (non)compliance ------------------------------------+------------------------------------- Reporter: carter | Owner: carter Type: task | Status: new Priority: high | Milestone: 7.10.1 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: | ------------------------------------+------------------------------------- As best I can determine, ghc has never been closely audited for conformance to IEEE-754 (floating point) standard and currently is a bit far from providing a compliant implementation. This impacts both a number of other tasks i wish to do for ghc **and** much of my own use of haskell is in a floating point heavy workloads, I will do a bit of leg work to: a) improve test suite support for checking for compliance b) write some patches to provide portable compliant primops for the operations which need compiler support c) try to determine how to allow ghc optimizer to be a bit more aggressive in a sound way in the presence of floating point. (this may grow into a few subtickets, we'll see) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9276> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #9304: Floating point woes; Different behavior on Mac vs Linux
by GHC 16 Dec '15

16 Dec '15

#9304: Floating point woes; Different behavior on Mac vs Linux ------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.3 Keywords: floating point | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I've the following snippet: {{{ x, y, r :: Double x = -4.4 y = 2.4999999999999956 r = x * y }}} Using GHC 7.8.3, on a Mac, I get the following response from ghci: {{{ *Main> decodeFloat r (-6192449487634421,-49) }}} Using GHC 7.8.3, on a Linux machine, I get the following response: {{{ *Main> decodeFloat r (-6192449487634422,-49) }}} Note that off-by-one difference in the first component of the output. I'm not 100% sure as to which one is actually correct; but the point is that these are IEEE floating point numbers running on the same architecture (Intel X86), and thus should decode in precisely the same way. While I observed this with 7.8.3; I don't think this is a new regression; I suspect it'll show up in older versions as well. Also, for full disclosure: I ran the Mac version naively; but the Linux version on top of a VirtualBox image. I'd very much doubt that would make a difference, but there might be 32/64-bit concerns. So, if someone can validate the Linux output on a true 64-bit Linux machine, that would really help track down the issue further. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9304> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 32

[GHC] #9306: Crash when shifting Integers too much
by GHC 16 Dec '15

16 Dec '15

#9306: Crash when shifting Integers too much ------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- When shifting an Integer by `fromIntegral (maxBound::Int) + 2` or more, the RTS crashes. The attached program gives the following output (on x86_64, at least): [dfeuer@lemur src]$ ./shiftcrash Okay 0 gmp: overflow in mpz type Aborted I found the bug in 7.6.3, but it's been verified to be present also in 7.8.3. The crash also occurs when running similar code in GHCi. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9306> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11102: `ghc --supported-extension` shall not list `TemplateHaskell` when unsupported
by GHC 16 Dec '15

16 Dec '15

#11102: `ghc --supported-extension` shall not list `TemplateHaskell` when unsupported -------------------------------------+------------------------------------- Reporter: hvr | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.0.1 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 Rev(s): phab:D1484 | Wiki Page: -------------------------------------+------------------------------------- Currently GHC advertises `TemplateHaskell` even though it's statically known to fail: {{{ $ ghc --supported-extensions | grep Template TemplateHaskell NoTemplateHaskell # `NoTemplateHaskell` works: $ ghc -XNoTemplateHaskell -c hello.hs # `TemplateHaskell` however fails even though advertised: $ ghc -XTemplateHaskell -c hello.hs ghc: on the commandline: Template Haskell requires GHC with interpreter support Perhaps you are using a stage-1 compiler? Usage: For basic information, try the `--help' option. }}} Having properly advertised extensions is particularly useful in combination with [[https://github.com/haskell/cabal/issues/2644|Cabal#2644]] allowing the solver to toggle flags depending on the availability of `-XTemplateHaskell`. For instance, cross-compilers and/or unregisterised GHC builds often don't have TemplateHaskell support. Having support for toggling flags based on availability of `-XTemplateHaskell` allows `cabal` to support such environments with less manual intervention. (See also https://github.com/haskell/cabal/pull/2930 for pre-GHC8 emulation of this feature) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11102> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11083: Documentation clarification for Data.List.isSubsequenceOf
by GHC 16 Dec '15

16 Dec '15

#11083: Documentation clarification for Data.List.isSubsequenceOf -------------------------------------+------------------------------------- Reporter: jura | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Documentation | Version: 7.10.2 Keywords: Data.List, | Operating System: Unknown/Multiple isSubsequenceOf | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In order to clarify the difference between isInfixOf and isSubsequenceOf, I submit a patch which changes the wording from "The 'isSubsequenceOf' function takes two lists and returns 'True' if the first list is a subsequence of the second list." to "The 'isSubsequenceOf' function takes two lists and returns 'True' if all the elements of the first list occur, in order, in the second. The elements do not have to occur consecutively." -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11083> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8347: Add a Strict LANGUAGE pragma
by GHC 16 Dec '15

16 Dec '15

#8347: Add a Strict LANGUAGE pragma ------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | 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: | ------------------------------------+------------------------------------- A `Strict` `LANGUAGE` pragma would allow us to experiment with writing in a strict sub-language. Since this pragma works on a per module basis, it needs to be modular. I propose the following semantics: * Patterns are strict at the top-level, as if they had a top-level bang, unless an explicit ~ is used to make the pattern lazy. * Functions evaluate their parameters to WHNF. * Data type fields are strict (as if they had a bang-pattern). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8347> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14