December 2015 - ghc-tickets

[GHC] #11236: Illegal instruction on ARMv7 with official build and simple program (IMX53 board)
by GHC 17 Dec '15

17 Dec '15

#11236: Illegal instruction on ARMv7 with official build and simple program (IMX53 board) -------------------------------------+------------------------------------- Reporter: varosi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: ARMv7 | Operating System: Linux Architecture: arm | Type of failure: Incorrect result | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- On IMX53 Quick Start board http://www.nxp.com/products/interface-and-connectivity/interface-and- system-management/switch-monitoring-ics/i.mx53-quick-start-board:IMX53QSB With Debian Jessie I'm installing: https://www.haskell.org/ghc/download_ghc_7_10_2#linux_armv7 ghc-7.10.2-arm-unknown-linux.tar.xz (108 MB) When I compile simple program as: import System.IO main = putStrLn "Hello World in ARM!" and then compile and run I got: "Illegal instruction" message When we debug it it seems that there is missing end of function and going straight into main function without changing to ARM Thumb instructions. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11236> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #7414: plugins always trigger recompilation
by GHC 17 Dec '15

17 Dec '15

#7414: plugins always trigger recompilation -------------------------------------+------------------------------------- Reporter: jwlato | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: plugin, | recompilation Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): Plugin interface hash is insufficient, since you want to recompile if the plugin implementation changes (even if its unfoldings do not.) It's almost as if you just want the file modification time... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7414#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[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] #11232: Panic whilst compiling syb due to OptCoercion
by GHC 17 Dec '15

17 Dec '15

#11232: Panic whilst compiling syb due to OptCoercion -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: high | 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: -------------------------------------+------------------------------------- Here is the minimised test case with most definitions inlined. {{{ module Data.Generics.Aliases where import Control.Monad import Data.Data mkMp :: ( MonadPlus m , Typeable a , Typeable b ) => (b -> m b) -> a -> m a mkMp ext = unM (maybe (M (const mzero)) id (gcast (M ext))) newtype M m x = M { unM :: x -> m x } }}} Panics with `-O2` as follows, {{{ ~/Documents/haskell/syb-0.6:ghc-7.11.20151214 Aliases.hs -O2 [1 of 1] Compiling Data.Generics.Aliases ( Aliases.hs, Aliases.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.11.20151214 for x86_64-apple-darwin): ASSERT failed! file compiler/types/OptCoercion.hs, line 234 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11232> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11235: Haddock shows no class members
by GHC 17 Dec '15

17 Dec '15

#11235: Haddock shows no class members -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: high | Milestone: 8.0.1 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: -------------------------------------+------------------------------------- At least since Haddock commit 0fc8cfd532f5dfd12b5504f44a2b3c9fb659cd87 on the `ghc-head` branch Haddock's HTML output has shown no class members. I'll need to work out why this is before the release. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11235> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #11215: Line endings in quasiquotations are not normalised
by GHC 17 Dec '15

17 Dec '15

#11215: Line endings in quasiquotations are not normalised -------------------------------------+------------------------------------- Reporter: refold | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following [http://hackage.haskell.org/package/raw-strings-qq simple quasiquoter]: {{{#!hs foo = QuasiQuoter { quoteExp = return . LitE . StringL [...] }}} When used like this: {{{#!hs bar :: String bar = [foo|FOO BAR BAZ|] }}} the string `bar` will contain either LF or CRLF line endings depending on which convention is used in the file. This is consistent with documentation, if a bit surprising. However, the problem is that version control systems (e.g. Git) usually store text files using Unix line endings, but allow checking them out in a platform- specific format. So this behaviour gives rise to subtle semantics changes in the compiled program that depend on the user's VCS settings. Therefore IMO it makes sense to always normalise CRLF to LF in quasiquotations. Originally reported [https://github.com/23Skidoo/raw-strings-qq/issues/1 here], a test case can be found [https://github.com/23Skidoo/raw-strings- qq/blob/master/test/Test.hs here]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11215> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[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] #11237: Type synonyms are not expanded in the data type declaration return kind
by GHC 16 Dec '15

16 Dec '15

#11237: Type synonyms are not expanded in the data type declaration return kind -------------------------------------+------------------------------------- Reporter: thomasw | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (Type checker) | 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: -------------------------------------+------------------------------------- I was playing around with the cool new `-XTypeInType` stuff when I encountered the following issue: {{{#!hs {-# LANGUAGE TypeInType #-} {-# LANGUAGE GADTs #-} module TypeInTypeBug where import qualified Data.Kind -- This works, using Data.Kind.Type as return kind --------------vvvvvvvvvvvvvv data Works :: Data.Kind.Type where WorksConstr :: Works type Set = Data.Kind.Type -- This doesn't work, using a type synonym for Data.Kind.Type as return kind ---------------vvv data Doesnt :: Set where DoesntConstr :: Doesnt }}} {{{ TypeInTypeBug.hs:17:1: error: • Kind signature on data type declaration has non-* return kind Set • In the data declaration for ‘Doesnt’ }}} I suppose type synonyms should be expanded in the return kind of a data type declaration before checking it is `*`. I also think the error message is not totally correct, take the following '''valid''' data declaration: {{{#!hs data Foo :: Bool -> Data.Kind.Type where Tru :: Foo True Fal :: Foo False }}} The return kind of the data declaration is actually `Bool -> Data.Kind.Type` (or `Bool -> *`), which is not `*`. I assume the error message is talking about the return kind (`*`) of the return kind (`Bool -> *`) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11237> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6