October 2014 - ghc-tickets

[GHC] #9480: Segfault in GHC API code using Shelly
by GHC 01 Dec '14

01 Dec '14

#9480: Segfault in GHC API code using Shelly -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: Runtime Difficulty: Unknown | crash Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- A segfault occurs when using the GHC API with Shelly. I do not know why. Here is a code snippet that triggers it: {{{#!hs import GHC import GHC.Paths ( libdir ) import DynFlags main = runGhc (Just libdir) $ do dflags <- getSessionDynFlags setSessionDynFlags $ dflags { hscTarget = HscInterpreted, ghcLink = LinkInMemory } imports <- mapM parseImportDecl ["import Shelly", "import Prelude"] setContext $ map IIDecl imports runStmt "shelly undefined" RunToCompletion }}} Note that on Mac OS X, this has no output whatsoever. The segfault occurs on Ubuntu 14.04, with `uname -a` outputting the following: {{{ Linux yed 3.13.0-34-generic #60-Ubuntu SMP Wed Aug 13 15:45:27 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux }}} I cannot find any way to get this to work and have no idea what's up with this or why shelly triggers it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9480> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #9186: GHC panic when compiling compdata
by GHC 01 Dec '14

01 Dec '14

#9186: GHC panic when compiling compdata ------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 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: | ------------------------------------+------------------------------------- When testing ghc-7.8.2.20140609 with Stackage, I came across the following ghc panic: [51 of 62] Compiling Data.Comp.Ordering ( src/Data/Comp/Ordering.hs, dist/build/Data/Comp/Ordering.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.8.2.20140609 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc4836_0/ghc4836_257.so: undefined symbol: compdatazm0zi8zi1zi0_DataziCompziDeriveziUtils_zdwabstractConType_info Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Failed to install compdata-0.8.1.0 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9186> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 30

[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] #9005: Ship default bash completion file with ghc
by GHC 01 Dec '14

01 Dec '14

#9005: Ship default bash completion file with ghc ------------------------------------+------------------------------------- Reporter: td123 | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: None | 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: | ------------------------------------+------------------------------------- Now that ticket #7843 has been closed, it would be great to ship a default implementation of a bash completion file for ghc. Since there isn't a standard location to install completion files across distros, it might be good to have an optional flag during configure to specify a location and if one is specified, install the bash completion file into that location. The following links provide implementations that have worked for me: http://www.reddit.com/r/haskell/comments/236qkb/autocomplete_command_line_o… https://ghc.haskell.org/trac/ghc/wiki/AutocompleteGHCFlags -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9005> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8815: confusing language in error message
by GHC 30 Nov '14

30 Nov '14

#8815: confusing language in error message ------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Late last night I was finding myself very confused by the following (in retrospect obvious error message) {{{ src/Numerical/OpenBLAS/BLAS.hs:41:44: A pattern match on a GADT requires GADTs or TypeFamilies In the pattern: SRow In the pattern: DenseMatrix SRow _ _ _ _ In an equation for ‛encodeNiceOrderHelper’: encodeNiceOrderHelper (DenseMatrix SRow _ _ _ _) = encodeOrder BLASRowMajor }}} the error is correct per se, but reading (at least late at night) made me think "wait, how is my type not a GADT or TypeFamily?!!?!" I'm thinking (perhaps ) that ``` A pattern match on a GADT requires GADTs or TypeFamilies `` ` could perhaps be more clearly communicated as ```A pattern match on a GADT requires that GADTs or TypeFamilies Language extensions be enabled in the use site module``` (or something similar) relatedly: whats the current reasoning for why GADT related matching logic isn't enabled in client modules that use GADTs? (i'm not questioning it, just wondering why) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8815> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[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] #9736: Constant folding rules are wrong for GHCJS
by GHC 27 Nov '14

27 Nov '14

#9736: Constant folding rules are wrong for GHCJS -------------------------------------+------------------------------------- Reporter: luite | Owner: luite Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- GHCJS currently has a complete copy of PrelRules to work around some issues where the rules depend on the build environment instead of the target. - shiftRightLogical - removeOp32 I'd like to get rid of the copy for 7.10 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9736> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9715: The most minimal Gloss project causes the profiler to fail silently.
by GHC 26 Nov '14

26 Nov '14

#9715: The most minimal Gloss project causes the profiler to fail silently. -------------------------------------+------------------------------------- Reporter: Yxven | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.8.3 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Runtime Difficulty: Unknown | performance bug Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- If you do this: cabal clean cabal configure --enable-library-profiling cabal configure --enable-executable-profiling cabal build dist\build\rogue\rogue.exe +RTS -p and run it for a few seconds before closing it. it will create a rogue.prof file that contains nothing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9715> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

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

24 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