- ghc-tickets - Haskell.org

Re: [GHC] #7373: When building GHC: Failed to load interface for `GHC.Fingerprint'
by GHC 01 Jun '13

01 Jun '13

#7373: When building GHC: Failed to load interface for `GHC.Fingerprint' -------------------------------+-------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: 7.6.1 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: T7373 | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Comment(by igloo): Hmm, it looks like this is making some differences to the code we generate. I discovered this when looking for differences between regular and -dynamic-too builds, and I found these false differences instead. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7373#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7953: Segfault on x86 with -O2
by GHC 01 Jun '13

01 Jun '13

#7953: Segfault on x86 with -O2 -------------------------+-------------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Keywords: | Os: Unknown/Multiple Architecture: x86 | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | -------------------------+-------------------------------------------------- Comment(by igloo): smaller testcase attached -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7953#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7953: Segfault on x86 with -O2
by GHC 31 May '13

31 May '13

#7953: Segfault on x86 with -O2 -------------------------+-------------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Keywords: | Os: Unknown/Multiple Architecture: x86 | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | -------------------------+-------------------------------------------------- Comment(by kazu-yamamoto): Note that this is not limited to MacOS. This can be reproduced on 32bit Linux, too. This segfault is caused by "prio e > pt". This happens if Prio is either Float or Double. Int does not cause this segfault. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7953#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7715: threadDelay causes segfault on Mac if compiled by 32bit GHC
by GHC 31 May '13

31 May '13

#7715: threadDelay causes segfault on Mac if compiled by 32bit GHC -----------------------------+---------------------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- The following code causes segfault {{{ main :: IO () main = do replicateM_ 100 $ forkIO $ do threadDelay 1000000 putStrLn "Hello, world!" threadDelay 5000000 }}} if compiled with 32bit GHC head on Mac. 64bit GHC head does not cause this problem. 32bit GHC 7.4.2 does not, either. I don't see this bug both on FreeBSD and Linux. "gdb" caught the following on each run: {{{ Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00000005 [Switching to process 51076 thread 0x20b] 0x00000005 in ?? () }}} {{{ Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00000019 [Switching to process 50933 thread 0x20b] 0x00000019 in ?? () }}} {{{ Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x40e40348 [Switching to process 51004 thread 0x20b] 0x00f28aa5 in base_GHCziEventziPSQ_atMostzuzdszdwatMosts_info () }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7715> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 16

Re: [GHC] #5687: Friendly Interface for auto-completion of GHCi
by GHC 31 May '13

31 May '13

#5687: Friendly Interface for auto-completion of GHCi ---------------------------------+------------------------------------------ Reporter: linsumang | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 7.6.2 Component: GHCi | Version: 7.2.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => patch -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5687#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7943: Malformed record leads to panic
by GHC 27 May '13

27 May '13

#7943: Malformed record leads to panic -------------------------------+-------------------------------------------- Reporter: scvalex | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Compile-time crash | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- The following code makes GHC panic (note the extra String after B): {{{ data Foo = A { bar :: String } | B String { bar :: String } }}} {{{ % runhaskell Bug.hs ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-unknown-linux): tc_hs_type: record Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7943> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6135: Unboxed Booleans
by GHC 27 May '13

27 May '13

#6135: Unboxed Booleans -------------------------------+-------------------------------------------- Reporter: benl | Owner: jstolarek Type: feature request | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: #605 -------------------------------+-------------------------------------------- Comment(by jstolarek): Simon M., you're right - there are no changes in the code generator. According to tests and my analysis of generated assembly everything works correct. I wish I could give an explanation of how that works in the codegen but I have to admit that I am not familiar with that part of the compiler. I'll take a look at the code and see if I can give a more professional response :) Right now I'm trying to see if I can use new primops to get more performance out of Gregory Collins' hashtables package - I'll post here if I get good results. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6135#comment:58> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7930: Nested STM Invariants are lost
by GHC 27 May '13

27 May '13

#7930: Nested STM Invariants are lost ----------------------------------------+----------------------------------- Reporter: fryguybob | Owner: fryguybob Type: bug | Status: new Priority: normal | Component: Runtime System Version: 7.6.3 | Keywords: STM Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Incorrect result at runtime | Blockedby: Blocking: | Related: ----------------------------------------+----------------------------------- Invariants from a successful nested transaction should be merged with the parent. {{{ import Control.Concurrent import Control.Concurrent.STM main = do x <- atomically $ do a <- newTVar True (always (readTVar a) >> retry) `orElse` return () return a atomically (writeTVar x False) -- Should not and does not fail y <- atomically $ do a <- newTVar True always (readTVar a) `orElse` return () return a atomically (writeTVar y False) -- Should fail, but does not! putStrLn "Ahhh!" z <- atomically $ do a <- newTVar True always (readTVar a) return a atomically (writeTVar z False) -- should and does fail }}} I know how to fix this. I'll have a patch with some tests and a fix soon. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7930> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #6135: Unboxed Booleans
by GHC 27 May '13

27 May '13

#6135: Unboxed Booleans -------------------------------+-------------------------------------------- Reporter: benl | Owner: jstolarek Type: feature request | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: #605 -------------------------------+-------------------------------------------- Comment(by simonpj): Awaiting response from Jan... -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6135#comment:57> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7938: Unbound kind variable can appear in RHS of associated type
by GHC 27 May '13

27 May '13

#7938: Unbound kind variable can appear in RHS of associated type ----------------------------------------+----------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC accepts invalid program | Blockedby: Blocking: | Related: ----------------------------------------+----------------------------------- Consider the following code: {{{ {-# LANGUAGE TypeFamilies, PolyKinds, MultiParamTypeClasses, FlexibleInstances, DataKinds #-} data KProxy (a :: *) = KP class Foo (a :: k1) (b :: k2) where type Bar a instance Foo (a :: k1) (b :: k2) where type Bar a = (KP :: KProxy k2) }}} The kind variable {{{k2}}} appears on the RHS of the instance for {{{Bar}}} but not on the left-hand side. This is disallowed for type variables, but there seems to be no check for kind variables. I will fix in an upcoming patch. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7938> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0