January 2014 - ghc-tickets

[GHC] #8548: Coercible does not resolve type family application
by GHC 02 Dec '14

02 Dec '14

#8548: Coercible does not resolve type family application -------------------------------------------+------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: #8503 | Test Case: | Blocking: -------------------------------------------+------------------------------- With GND implemented using `Coercible` (See #8503) the test for #4185 fails. A minimal example is: {{{ {-# LANGUAGE TypeFamilies #-} module CoerceNewtypeFamily where import GHC.Exts data family Foo k newtype instance Foo Int = FooInt Int x :: Foo Int -> Int x = coerce }}} yielding {{{ [1 of 1] Compiling CoerceNewtypeFamily ( CoerceNewtypeFamily.hs, CoerceNewtypeFamily.o ) CoerceNewtypeFamily.hs:11:5: No instance for (Coercible (Foo Int) Int) because ‛Foo Int’ and ‛Int’ are different types. arising from a use of ‛coerce’ In the expression: coerce In an equation for ‛x’: x = coerce }}} I guess the `Coercible` finding code needs to simply type family equations if possible. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8548> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8304: more lenient operator sections (RelaxedSections extension)
by GHC 01 Dec '14

01 Dec '14

#8304: more lenient operator sections (RelaxedSections extension) -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler (Parser) | 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: | -------------------------------------+------------------------------------- Some operator sections are rejected which could have some meaning. {{{ (a ++ b ++ ) could mean \x -> a ++ b ++ c (++ a ++) could mean \x y -> x ++ a ++ y }}} The attached quasiquoter implements this, but for various reasons it would be better if ghc supported this directly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8304> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8100: Standalone deriving using template haskell
by GHC 01 Dec '14

01 Dec '14

#8100: Standalone deriving using template haskell ------------------------------------+------------------------------------- Reporter: acube | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Currently, there seems to be no support for standalone deriving in TemplateHaskell: {{{ Prelude Data.Typeable Language.Haskell.TH> :set -XStandaloneDeriving Prelude Data.Typeable Language.Haskell.TH> data Weird a (b :: * -> * -> *) c = Weird Prelude Data.Typeable Language.Haskell.TH> runQ $ [d| deriving instance Typeable Weird |] [] }}} ''Use case'': The library [http://hackage.haskell.org/package/typeable-th typeable-th] can already generate Typeable instances using TH for GHC 7.4 and 7.6. To add support for GHC 7.8 in a way that the user doesn't have to care about the version, there has to be a way to make Typeable instances via TH in GHC 7.8. This is currently impossible, but with StandaloneDeriving support for TH, it would be possible. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8100> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #8323: explore ways to possibly use more tag bits in x86_64 pointers
by GHC 28 Nov '14

28 Nov '14

#8323: explore ways to possibly use more tag bits in x86_64 pointers ------------------------------------+------------------------------------- Reporter: carter | Owner: Type: task | 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: | ------------------------------------+------------------------------------- on x86_64, pointers only use 48 bits! currently we use 3bits for tagging / arity etc info on x86_64, we should explore more uses! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8323> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault
by GHC 28 Nov '14

28 Nov '14

#8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault ----------------------------------+---------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------------- I am getting segfaults when a statically linked executable uses a GHC API. When the same executable is however dynamically linked it runs without error. In case of the statically-linked version, I think that one of GHC API functions that tries to do dynamic-linking is causing the segfault. The reason why I think this, is because the segfault shows up when Template-Haskell is used, or when {{{ {-# ANN ... #-} }}} annotations are used. An example of this strange behaviour can be shown using haddock, and running it on the source-code for the lens library [1]: {{{ ~/Documents/devel/lens/src (master *)$ haddock -v3 Control/Lens/Internal/ByteString.hs Creating interfaces... Haddock coverage: Checking module Control.Lens.Internal.Setter... Creating interface... 100% ( 3 / 3) in 'Control.Lens.Internal.Setter' <MORE LOG MESSAGE> Checking module Control.Lens.Reified... Creating interface... 100% ( 20 / 20) in 'Control.Lens.Reified' Checking module Control.Lens.Setter... Bus error: 10 <-- SEGFAULT }}} And the GDB output: {{{ (gdb) run -v3 Control/Lens/Internal/ByteString.hs Starting program: /Users/christiaan/.ghc- config/cabal/7.7.20130924/bin/haddock -v3 Control/Lens/Internal/ByteString.hs Reading symbols for shared libraries +++.............................. done Creating interfaces... Haddock coverage: Checking module Control.Lens.Internal.Setter... Creating interface... 100% ( 3 / 3) in 'Control.Lens.Internal.Setter' <MORE LOG MESSAGES> Checking module Control.Lens.Reified... Creating interface... 100% ( 20 / 20) in 'Control.Lens.Reified' Checking module Control.Lens.Setter... Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x000000010828b982 0x000000010828b982 in ?? () }}} I should note that until now I've been unable to produce a _small_ test case that shows the above behaviour. The statically linked haddock actually runs successfully on many packages. The lens[1] package is the first widely used library that I've been able to get haddock to exhibit the above behaviour. Also, when I built a dynamically-linked version of haddock, it runs succesfully for the above test-case (and the other test-cases where the statically-linked version would give a segfault). The source-code for lens[1] contains many {{{ {-# ANN ... #-} }}} annotations; removing all those annotations make the statically-linked version of haddock run successfully, with out segfaults. Halfway through removing the {{{ {-# ANN ... #-} }}} annotation, I also encountered the following error: {{{ Checking module Control.Lens.Fold... haddock: internal error: ARR_WORDS object entered! (GHC version 7.7.20130924 for x86_64_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Abort trap: 6 }}} I've also encountered the segfault while running the statically-linked haddock on my own clash library [2]. In this case I think it might have something to do with the use of template-haskell. Again, running the dynamically-linked version of haddock does not show any problems. Here is some extra information about my development environment:[[BR]] OS: OS X 10.8.5[[BR]] X-Code: XCode CL-Tools 4.6.2[[BR]] GHC: GHC-HEAD (commit 94ab5d2984514f92dd919fbf3611a07d32105546)[[BR]] Output of {{{make show VALUE=GhcLibWays}}}: v dyn[[BR]] build.mk: {{{ SRC_HC_OPTS = -O -H64m GhcStage1HcOpts = -O -fasm GhcStage2HcOpts = -O2 -fasm GhcHcOpts = -Rghc-timing GhcLibHcOpts = -O2 HADDOCK_DOCS = NO }}} I create statically-linked binaries by setting {{{executable-dynamic}}} in {{{.cabal/config}}} to {{{False}}}[[BR]] I create dynamically-linked binaries by setting {{{executable-dynamic}}} in {{{.cabal/config}}} to {{{True}}}[[BR]] I created the {{{haddock}}} executables by running {{{cabal install}}} in {{{"up-to-date build tree of GHC"/utils/haddock}}} [1] https://github.com/ekmett/lens[[BR]] [2] http://hackage.haskell.org/package/clash-lib -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8376> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #8338: Incoherent instances without -XIncoherentInstances
by GHC 25 Nov '14

25 Nov '14

#8338: Incoherent instances without -XIncoherentInstances ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | 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: | ------------------------------------+------------------------------------- Consider the following 4 modules: {{{ {-# LANGUAGE GADTs #-} module A where data One = One data ShowInstFor a = Show a => MkSIF incoherent :: ShowInstFor One -> ShowInstFor One -> String incoherent MkSIF MkSIF = show One }}} {{{ module B where import A instance Show One where show _ = "from module B" fromB :: ShowInstFor One fromB = MkSIF }}} {{{ module C where import A instance Show One where show _ = "from module C" fromC :: ShowInstFor One fromC = MkSIF }}} {{{ module D where import A import B import C oops1 = incoherent fromB fromC oops2 = incoherent fromC fromB }}} According to ghci, `oops1` is `"from moduleB"` and `oops2` is `"from module C"`. This seems bad. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8338> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8044: "Inaccessible code" error reported in wrong place
by GHC 24 Nov '14

24 Nov '14

#8044: "Inaccessible code" error reported in wrong place -------------------------------------------+------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.7 Keywords: GADTs | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- Here is my file `Bug.hs`: {{{ {-# LANGUAGE GADTs, TypeFamilies #-} module Bug where data X a where XInt :: X Int XBool :: X Bool XChar :: X Char type family Frob a where Frob Int = Int Frob x = Char frob :: X a -> X (Frob a) frob XInt = XInt frob _ = XChar }}} Compiling this file produces the error {{{ Bug.hs:15:6: Couldn't match type ‛Int’ with ‛Char’ Inaccessible code in a pattern with constructor XInt :: X Int, in an equation for ‛frob’ In the pattern: XInt In an equation for ‛frob’: frob XInt = XInt }}} The line/column number single out the pattern `XInt` in the first clause of the function `frob`. But, the real problem (as I see it), is the right- hand side of the ''second'' clause of `frob`. Indeed, when I comment out the second line of the function, the error goes away, even though it was reported on the first line. I do not believe that this error is caused by closed type families, per se, because I have run across it without them, just in code that was too hard to pare down enough to make a bug report out of. This was tested on 7.7.20130702. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8044> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8046: Make the timer management scale better across multicore
by GHC 22 Nov '14

22 Nov '14

#8046: Make the timer management scale better across multicore ------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | 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 recent commit {{{ commit e843e73690f828498f6e33bb89f47a50c3ab2ac9 Author: Ian Lynagh <ian(a)well-typed.com> Date: Sat Jun 8 20:19:59 2013 +0100 IO manager: Edit the timeout queue directly, rather than using an edit list Fixes #7653. }}} undid an optimization to the management of timeouts (to fix a bug, which is good). We should check how much this hurt performance, but it might be better to rewrite the timeout management altogether. The current scheme scales poorly to several cores. We should probably have one priority queue per core and use an efficient mutable data structure. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8046> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8054: Undefined symbol during linking
by GHC 22 Nov '14

22 Nov '14

#8054: Undefined symbol during linking ------------------------------------+------------------------------------- Reporter: case | Owner: Type: bug | 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: | ------------------------------------+------------------------------------- On OSX, using GHC 7.6.3 and the package recursion-schemes 3.0.0.2, the following code causes the compiler to emit an error about undefined symbols. Code: {{{ import Data.Functor.Foldable x = project 1 :: Integer main = x `seq` return () }}} Error: {{{ λ ~/ ghc test.hs Linking test ... Undefined symbols for architecture x86_64: "_Main_x_closure", referenced from: _Main_main_info in test.o _Main_main_srt in test.o ld: symbol(s) not found for architecture x86_64 collect2: ld returned 1 exit status }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8054> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8056: Make Install fails on HEAD
by GHC 22 Nov '14

22 Nov '14

#8056: Make Install fails on HEAD ------------------------------------+------------------------------------- Reporter: fryguybob | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I'm trying to build the `perf` flavor of head and I'm getting an error with `make install`. The `quick` flavor works as expected. {{{ $ uname -a Linux ... 3.6.5-1.fc17.x86_64 ... $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.6.3 $ cabal --version cabal-install version 1.16.0.2 using version 1.16.0.3 of the Cabal library $ gcc --version gcc (GCC) 4.7.2 20120921 (Red Hat 4.7.2-2) ... $ git clone http://darcs.haskell.org/ghc.git/ ghc-7.8/ ... $ cd ghc-7.8 $ ./sync-all --testsuite get ... $ cp mk/build.mk.sample mk/build.mk $ vi mk/build.mk $ diff mk/build.mk mk/build.mk.sample 12c12 < BuildFlavour = perf --- > #BuildFlavour = perf $ perl boot ... $ ./configure --prefix=/localdisk/ryates/ghc-7.8-build/ ... $ make -j8 ... $ make install ... Installing library in /localdisk/ryates/ghc-7.8-build/lib/ghc-7.7.20130711/haskell2010-1.1.1.0 "/localdisk/ryates/ghc-7.8-build/lib/ghc-7.7.20130711/bin/ghc-pkg" --force --global-package-db "/localdisk/ryates/ghc-7.8-build/lib/ghc-7.7.20130711/package.conf.d" update rts/dist/package.conf.install /localdisk/ryates/ghc-7.8-build/lib/ghc-7.7.20130711/bin/ghc-pkg: symbol lookup error: /localdisk/ryates/ghc-7.8-build/lib/ghc-7.7.20130711/bin /ghc-pkg: undefined symbol: base_DataziList_intercalatezuzdspolyzugo_info make[1]: *** [install_packages] Error 127 make: *** [install] Error 2 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8056> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1