From trac at galois.com Thu Oct 1 03:35:52 2009 From: trac at galois.com (GHC) Date: Thu Oct 1 03:13:50 2009 Subject: [GHC] #3554: ASSERT failed! file TcMType.lhs line 349 In-Reply-To: <047.d25d30bbfd2ca44b41deb2a3c8a4f5bd@localhost> References: <047.d25d30bbfd2ca44b41deb2a3c8a4f5bd@localhost> Message-ID: <056.6b8fb08068880c9a9a55cbc53082a862@localhost> #3554: ASSERT failed! file TcMType.lhs line 349 ----------------------------------------+----------------------------------- Reporter: simonmar | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: Compiler (Type checker) | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: T2627b | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------+----------------------------------- Comment (by chak): This is one of the remaining cases, where a type variable is instantiated twice, due to the current imperfect interaction between the equality solver and the rest of TcSimplify. This will probably only get fixed once we have the new implementation of implications constraints. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 1 10:58:43 2009 From: trac at galois.com (GHC) Date: Thu Oct 1 10:36:37 2009 Subject: [GHC] #3555: Vectorisation error with negative Double const Message-ID: <042.76488390a8c998c2738bb2a24f69b062@localhost> #3555: Vectorisation error with negative Double const -----------------------------+---------------------------------------------- Reporter: ams | Owner: Type: bug | Status: new Priority: normal | Component: Data Parallel Haskell Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Negative Double constants cause an error in parallel comprehensions. This function negs xs = [: -1.0 | x <- xs :] doesn't make it through the compiler; this negs xs = [: (0.0 - 1.0) | x <- xs :] does. The error text is *** Vectorisation error *** Tycon not vectorised: GHC.Num.T:Num -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 1 11:15:52 2009 From: trac at galois.com (GHC) Date: Thu Oct 1 10:53:45 2009 Subject: [GHC] #3555: Vectorisation error with negative Double const In-Reply-To: <042.76488390a8c998c2738bb2a24f69b062@localhost> References: <042.76488390a8c998c2738bb2a24f69b062@localhost> Message-ID: <051.e8f34cc94f209ecc4e81aa60bfcd239d@localhost> #3555: Vectorisation error with negative Double const -----------------------------------+---------------------------------------- Reporter: ams | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Data Parallel Haskell | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Testcase: Os: Linux | Architecture: x86_64 (amd64) -----------------------------------+---------------------------------------- Changes (by ams): * os: Unknown/Multiple => Linux * architecture: Unknown/Multiple => x86_64 (amd64) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 1 11:16:17 2009 From: trac at galois.com (GHC) Date: Thu Oct 1 10:54:09 2009 Subject: [GHC] #3555: Vectorisation error with negative Double const In-Reply-To: <042.76488390a8c998c2738bb2a24f69b062@localhost> References: <042.76488390a8c998c2738bb2a24f69b062@localhost> Message-ID: <051.3a6551b024f871dfe1e3b57287bb5b47@localhost> #3555: Vectorisation error with negative Double const -----------------------------------+---------------------------------------- Reporter: ams | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Data Parallel Haskell | Version: 6.11 Severity: normal | Resolution: Keywords: | Testcase: Os: Linux | Architecture: x86_64 (amd64) -----------------------------------+---------------------------------------- Changes (by ams): * version: 6.10.4 => 6.11 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 1 11:18:05 2009 From: trac at galois.com (GHC) Date: Thu Oct 1 10:55:59 2009 Subject: [GHC] #3555: Vectorisation error with negative Double const In-Reply-To: <042.76488390a8c998c2738bb2a24f69b062@localhost> References: <042.76488390a8c998c2738bb2a24f69b062@localhost> Message-ID: <051.b51996a9653c6971388a48057372cb85@localhost> #3555: Vectorisation error with negative Double const -----------------------------------+---------------------------------------- Reporter: ams | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Data Parallel Haskell | Version: 6.11 Severity: normal | Resolution: Keywords: | Testcase: Os: Linux | Architecture: x86_64 (amd64) -----------------------------------+---------------------------------------- Comment (by ams): Version is actually 6.13.20090929. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 1 15:14:05 2009 From: trac at galois.com (GHC) Date: Thu Oct 1 14:53:26 2009 Subject: [GHC] #2965: GHC on OS X does not compile 64-bit In-Reply-To: <045.2214e7d1fe4dd43486128c197fdb9227@localhost> References: <045.2214e7d1fe4dd43486128c197fdb9227@localhost> Message-ID: <054.e3a6778718a5767bb43121ed39f56be0@localhost> #2965: GHC on OS X does not compile 64-bit --------------------------------+------------------------------------------- Reporter: Axman6 | Owner: thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: Severity: normal | Resolution: Keywords: 64bit | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86_64 (amd64) | --------------------------------+------------------------------------------- Changes (by skrap): * cc: skrap+haskell@spflrc.org (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 1 15:33:10 2009 From: trac at galois.com (GHC) Date: Thu Oct 1 15:11:12 2009 Subject: [GHC] #3550: Dynamic libraries don't work on Mac OS/X In-Reply-To: <056.c6f0034a4d5f342c60f11476270241e0@localhost> References: <056.c6f0034a4d5f342c60f11476270241e0@localhost> Message-ID: <065.3efffc38ffda02a0114616e8457721ba@localhost> #3550: Dynamic libraries don't work on Mac OS/X ----------------------------------------------------------------+----------- Reporter: StephenBlackheath | Owner: StephenBlackheath Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: major | Resolution: Keywords: dynamic mac osx | Difficulty: Unknown Testcase: http://upcycle.it/~blackh/ghc/test-case.tar.bz2 | Os: MacOS X Architecture: Unknown/Multiple | ----------------------------------------------------------------+----------- Comment (by StephenBlackheath): Version 5 changes the name of the new option to -dylib-install-name and adds documentation for it to the Users Guide. The corresponding Cabal patch (also needed) it #591 at http://hackage.haskell.org/trac/hackage/ticket/591 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 1 16:06:56 2009 From: trac at galois.com (GHC) Date: Thu Oct 1 15:45:39 2009 Subject: [GHC] #2965: GHC on OS X does not compile 64-bit In-Reply-To: <045.2214e7d1fe4dd43486128c197fdb9227@localhost> References: <045.2214e7d1fe4dd43486128c197fdb9227@localhost> Message-ID: <054.d226591ea44be36ff7b771119ddbe1e1@localhost> #2965: GHC on OS X does not compile 64-bit --------------------------------+------------------------------------------- Reporter: Axman6 | Owner: thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: Severity: normal | Resolution: Keywords: 64bit | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86_64 (amd64) | --------------------------------+------------------------------------------- Changes (by mokus): * cc: mokus@deepbondi.net (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From dagit at codersbase.com Thu Oct 1 19:01:02 2009 From: dagit at codersbase.com (Jason Dagit) Date: Thu Oct 1 18:38:54 2009 Subject: Fwd: GHC Bug report In-Reply-To: References: Message-ID: [I just found out that there is a dedicated bugs email address so forwarding the original message there.] Hello, I've created a small example of the program I have at this URL with the output of -ddump-simpl: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=10109#a10109 Notice that on line 139, I would like it if the Word8 could be passed without boxing. The full program text is here also in case the link above disappears: \begin{code} {-# LANGUAGE BangPatterns, MagicHash #-} module Main where import GHC.Word ( Word8(W8#) ) import GHC.Exts ( Int#, Int(I#), Ptr(..), Word#, Word(W#) ) import GHC.Prim ( indexWord8OffAddr#, (==#), (>=#), (+#), word2Int#, Addr# ) isSpaceWord8 :: Word8 -> Bool isSpaceWord8 !w = w == 0x20 || -- ' ' w == 0x09 || -- '\t' w == 0x0A || -- '\n' w == 0x0D -- '\r' {-# INLINE isSpaceWord8 #-} firstnonspace :: Ptr Word8 -> Int -> Int -> Int firstnonspace (Ptr p) (I# n) (I# m) = I# (first p n m) where first :: Addr# -> Int# -> Int# -> Int# first addr n' m' | n' >=# m' = n' | otherwise = if (not (isSpaceWord8 ch)) then n' else first addr (n' +# 1#) m' where ch = W8# (indexWord8OffAddr# addr n') {-# INLINE firstnonspace #-} main = return () \end{code} The output from ghc -O2 -ddump-simpl is: \begin{core} ==================== Tidy Core ==================== Main.a :: GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, () #) [GlobalId] [Arity 1 NoCafRefs Str: DmdType L] Main.a = \ (s_aHK :: GHC.Prim.State# GHC.Prim.RealWorld) -> (# s_aHK, GHC.Unit.() #) Main.a1 :: GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, () #) [GlobalId] [Arity 1 Str: DmdType L] Main.a1 = GHC.TopHandler.a5 @ () (Main.a `cast` (sym ((GHC.IOBase.:CoIO) ()) :: GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, () #) ~ GHC.IOBase.IO ())) Main.main :: GHC.IOBase.IO () [GlobalId] [Arity 1 NoCafRefs Str: DmdType L] Main.main = Main.a `cast` (sym ((GHC.IOBase.:CoIO) ()) :: GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, () #) ~ GHC.IOBase.IO ()) Main.lit :: GHC.Word.Word8 [GlobalId] [NoCafRefs Str: DmdType m] Main.lit = GHC.Word.W8# __word 13 Main.lit1 :: GHC.Word.Word8 [GlobalId] [NoCafRefs Str: DmdType m] Main.lit1 = GHC.Word.W8# __word 10 Main.lit2 :: GHC.Word.Word8 [GlobalId] [NoCafRefs Str: DmdType m] Main.lit2 = GHC.Word.W8# __word 9 Main.lit3 :: GHC.Word.Word8 [GlobalId] [NoCafRefs Str: DmdType m] Main.lit3 = GHC.Word.W8# __word 32 Main.isSpaceWord8 :: GHC.Word.Word8 -> GHC.Bool.Bool [GlobalId] [Arity 1 NoCafRefs Str: DmdType U(L)] Main.isSpaceWord8 = __inline_me (\ (w_ap1 :: GHC.Word.Word8) -> GHC.Classes.|| (GHC.Word.==2 w_ap1 Main.lit3) (GHC.Classes.|| (GHC.Word.==2 w_ap1 Main.lit2) (GHC.Classes.|| (GHC.Word.==2 w_ap1 Main.lit1) (GHC.Word.==2 w_ap1 Main.lit)))) Main.firstnonspace :: GHC.Ptr.Ptr GHC.Word.Word8 -> GHC.Types.Int -> GHC.Types.Int -> GHC.Types.Int [GlobalId] [Arity 3 NoCafRefs Str: DmdType U(L)U(L)U(L)m] Main.firstnonspace = __inline_me (\ (ds_dGa :: GHC.Ptr.Ptr GHC.Word.Word8) (ds1_dGb :: GHC.Types.Int) (ds2_dGc :: GHC.Types.Int) -> case ds_dGa of wild_B1 { GHC.Ptr.Ptr p_ap6 -> case ds1_dGb of wild1_XB { GHC.Types.I# n_ap8 -> case ds2_dGc of wild2_XG { GHC.Types.I# m_apa -> letrec { first_sH5 :: GHC.Prim.Addr# -> GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.Int# [Arity 3 Str: DmdType LLL] first_sH5 = \ (addr_ape :: GHC.Prim.Addr#) (n'_apg :: GHC.Prim.Int#) (m'_api :: GHC.Prim.Int#) -> case GHC.Prim.>=# n'_apg m'_api of wild3_XS { GHC.Bool.False -> case GHC.Classes.not (Main.isSpaceWord8 (GHC.Word.W8# (GHC.Prim.indexWord8OffAddr# addr_ape n'_apg))) of wild4_XU { GHC.Bool.False -> first_sH5 addr_ape (GHC.Prim.+# n'_apg 1) m'_api; GHC.Bool.True -> n'_apg }; GHC.Bool.True -> n'_apg }; } in case first_sH5 p_ap6 n_ap8 m_apa of wild3_XN { __DEFAULT -> GHC.Types.I# wild3_XN } } } }) :Main.main :: GHC.IOBase.IO () [GlobalId] [Arity 1 Str: DmdType L] :Main.main = Main.a1 `cast` (sym ((GHC.IOBase.:CoIO) ()) :: GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, () #) ~ GHC.IOBase.IO ()) ==================== Tidy Core Rules ==================== \end{core} Of note is that isSpaceWord8 is not inlined and the Word8 that it takes is strict, but it gets boxed before it is passed there creating an allocation that I would prefer to avoid. My GHC version is 6.10.4. It may be related to this bug: http://hackage.haskell.org/trac/ghc/ticket/3181 Thanks, Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-bugs/attachments/20091001/1815114b/attachment.html From trac at galois.com Thu Oct 1 21:08:59 2009 From: trac at galois.com (GHC) Date: Thu Oct 1 20:46:50 2009 Subject: [GHC] #3390: Upgrade the Windows build to use gcc 4.4.0 In-Reply-To: <047.29bca0c885caf29d0340fe02876b5659@localhost> References: <047.29bca0c885caf29d0340fe02876b5659@localhost> Message-ID: <056.3dedc20e62a2de23630557e9edb636d3@localhost> #3390: Upgrade the Windows build to use gcc 4.4.0 -----------------------------+---------------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 6.14.1 Component: Build System | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -----------------------------+---------------------------------------------- Changes (by igloo): * priority: high => normal * owner: igloo => * summary: Make the Windows build work with mingw gcc 4.4.0 => Upgrade the Windows build to use gcc 4.4.0 * milestone: 6.12.1 => 6.14.1 Comment: We now put the mingw tarballs we use in the source tree, so we always use the same version no matter what is installed. We should upgrade to gcc 4.4.0 at some point, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 1 21:10:51 2009 From: trac at galois.com (GHC) Date: Thu Oct 1 20:48:42 2009 Subject: [GHC] #3556: Build the bootstrapping ghc-pkg with ghc-cabal Message-ID: <044.67ca5f0d38da2c2c1eba80992f3ceec9@localhost> #3556: Build the bootstrapping ghc-pkg with ghc-cabal -------------------------------+-------------------------------------------- Reporter: igloo | Owner: Type: task | Status: new Priority: normal | Milestone: 6.14.1 Component: Build System | Version: 6.11 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- The current build rules for ghc-pkg are getting increasingly intricate. It should be possible to build the bootstrapping ghc-pkg with ghc-cabal instead, which should simplify things. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 2 00:53:18 2009 From: trac at galois.com (GHC) Date: Fri Oct 2 00:31:14 2009 Subject: [GHC] #3555: Vectorisation error with negative Double const In-Reply-To: <042.76488390a8c998c2738bb2a24f69b062@localhost> References: <042.76488390a8c998c2738bb2a24f69b062@localhost> Message-ID: <051.7c5b936452073062ba6d9045941c6a7e@localhost> #3555: Vectorisation error with negative Double const -----------------------------------+---------------------------------------- Reporter: ams | Owner: rl Type: bug | Status: new Priority: normal | Milestone: Component: Data Parallel Haskell | Version: 6.13 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------------+---------------------------------------- Changes (by chak): * owner: => rl * cc: rl@cse.unsw.edu.au (added) * version: 6.11 => 6.13 * os: Linux => Unknown/Multiple * architecture: x86_64 (amd64) => Unknown/Multiple Comment: The current version of the vectoriser can't handle type classes yet; hence, the error. BTW, in the current version of DPH, you need to use the simple mock Prelude from package dph in all code that ought to be vectorised ? if you use the standard Prelude, you will get similar errors (even without using type classes). We will lift these restrictions in future versions. -- Ticket URL: GHC The Glasgow Haskell Compiler From simonpj at microsoft.com Fri Oct 2 03:40:22 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Oct 2 03:18:14 2009 Subject: GHC Bug report In-Reply-To: References: Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C367C6C4B687@EA-EXMSG-C334.europe.corp.microsoft.com> Two things to say. First, you've said INLINE for both functions. GHC understands that as saying "replace a call to this function by the RHS that I'm writing right here". So GHC doesn't optimise them much, if at all. It waits until it sees a call, then inlines, then optimises *that*. So try calling 'firstnonspace' and see what you get. The only bad thing is that if you write (map firstnonspace xs), then there's no visible call to firstnonspace, so the non-optimised version will get executed. I'm in the middle of fixing that, with an upheaval of the way inlining works. Simon From: glasgow-haskell-bugs-bounces@haskell.org [mailto:glasgow-haskell-bugs-bounces@haskell.org] On Behalf Of Jason Dagit Sent: 02 October 2009 00:01 To: glasgow-haskell-bugs@haskell.org Cc: Simon Marlow; Ian Lynagh Subject: Fwd: GHC Bug report [I just found out that there is a dedicated bugs email address so forwarding the original message there.] Hello, I've created a small example of the program I have at this URL with the output of -ddump-simpl: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=10109#a10109 Notice that on line 139, I would like it if the Word8 could be passed without boxing. The full program text is here also in case the link above disappears: \begin{code} {-# LANGUAGE BangPatterns, MagicHash #-} module Main where import GHC.Word ( Word8(W8#) ) import GHC.Exts ( Int#, Int(I#), Ptr(..), Word#, Word(W#) ) import GHC.Prim ( indexWord8OffAddr#, (==#), (>=#), (+#), word2Int#, Addr# ) isSpaceWord8 :: Word8 -> Bool isSpaceWord8 !w = w == 0x20 || -- ' ' w == 0x09 || -- '\t' w == 0x0A || -- '\n' w == 0x0D -- '\r' {-# INLINE isSpaceWord8 #-} firstnonspace :: Ptr Word8 -> Int -> Int -> Int firstnonspace (Ptr p) (I# n) (I# m) = I# (first p n m) where first :: Addr# -> Int# -> Int# -> Int# first addr n' m' | n' >=# m' = n' | otherwise = if (not (isSpaceWord8 ch)) then n' else first addr (n' +# 1#) m' where ch = W8# (indexWord8OffAddr# addr n') {-# INLINE firstnonspace #-} main = return () \end{code} The output from ghc -O2 -ddump-simpl is: \begin{core} ==================== Tidy Core ==================== Main.a :: GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, () #) [GlobalId] [Arity 1 NoCafRefs Str: DmdType L] Main.a = \ (s_aHK :: GHC.Prim.State# GHC.Prim.RealWorld) -> (# s_aHK, GHC.Unit.() #) Main.a1 :: GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, () #) [GlobalId] [Arity 1 Str: DmdType L] Main.a1 = GHC.TopHandler.a5 @ () (Main.a `cast` (sym ((GHC.IOBase.:CoIO) ()) :: GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, () #) ~ GHC.IOBase.IO ())) Main.main :: GHC.IOBase.IO () [GlobalId] [Arity 1 NoCafRefs Str: DmdType L] Main.main = Main.a `cast` (sym ((GHC.IOBase.:CoIO) ()) :: GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, () #) ~ GHC.IOBase.IO ()) Main.lit :: GHC.Word.Word8 [GlobalId] [NoCafRefs Str: DmdType m] Main.lit = GHC.Word.W8# __word 13 Main.lit1 :: GHC.Word.Word8 [GlobalId] [NoCafRefs Str: DmdType m] Main.lit1 = GHC.Word.W8# __word 10 Main.lit2 :: GHC.Word.Word8 [GlobalId] [NoCafRefs Str: DmdType m] Main.lit2 = GHC.Word.W8# __word 9 Main.lit3 :: GHC.Word.Word8 [GlobalId] [NoCafRefs Str: DmdType m] Main.lit3 = GHC.Word.W8# __word 32 Main.isSpaceWord8 :: GHC.Word.Word8 -> GHC.Bool.Bool [GlobalId] [Arity 1 NoCafRefs Str: DmdType U(L)] Main.isSpaceWord8 = __inline_me (\ (w_ap1 :: GHC.Word.Word8) -> GHC.Classes.|| (GHC.Word.==2 w_ap1 Main.lit3) (GHC.Classes.|| (GHC.Word.==2 w_ap1 Main.lit2) (GHC.Classes.|| (GHC.Word.==2 w_ap1 Main.lit1) (GHC.Word.==2 w_ap1 Main.lit)))) Main.firstnonspace :: GHC.Ptr.Ptr GHC.Word.Word8 -> GHC.Types.Int -> GHC.Types.Int -> GHC.Types.Int [GlobalId] [Arity 3 NoCafRefs Str: DmdType U(L)U(L)U(L)m] Main.firstnonspace = __inline_me (\ (ds_dGa :: GHC.Ptr.Ptr GHC.Word.Word8) (ds1_dGb :: GHC.Types.Int) (ds2_dGc :: GHC.Types.Int) -> case ds_dGa of wild_B1 { GHC.Ptr.Ptr p_ap6 -> case ds1_dGb of wild1_XB { GHC.Types.I# n_ap8 -> case ds2_dGc of wild2_XG { GHC.Types.I# m_apa -> letrec { first_sH5 :: GHC.Prim.Addr# -> GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.Int# [Arity 3 Str: DmdType LLL] first_sH5 = \ (addr_ape :: GHC.Prim.Addr#) (n'_apg :: GHC.Prim.Int#) (m'_api :: GHC.Prim.Int#) -> case GHC.Prim.>=# n'_apg m'_api of wild3_XS { GHC.Bool.False -> case GHC.Classes.not (Main.isSpaceWord8 (GHC.Word.W8# (GHC.Prim.indexWord8OffAddr# addr_ape n'_apg))) of wild4_XU { GHC.Bool.False -> first_sH5 addr_ape (GHC.Prim.+# n'_apg 1) m'_api; GHC.Bool.True -> n'_apg }; GHC.Bool.True -> n'_apg }; } in case first_sH5 p_ap6 n_ap8 m_apa of wild3_XN { __DEFAULT -> GHC.Types.I# wild3_XN } } } }) :Main.main :: GHC.IOBase.IO () [GlobalId] [Arity 1 Str: DmdType L] :Main.main = Main.a1 `cast` (sym ((GHC.IOBase.:CoIO) ()) :: GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, () #) ~ GHC.IOBase.IO ()) ==================== Tidy Core Rules ==================== \end{core} Of note is that isSpaceWord8 is not inlined and the Word8 that it takes is strict, but it gets boxed before it is passed there creating an allocation that I would prefer to avoid. My GHC version is 6.10.4. It may be related to this bug: http://hackage.haskell.org/trac/ghc/ticket/3181 Thanks, Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-bugs/attachments/20091002/abfe475d/attachment-0001.html From trac at galois.com Fri Oct 2 04:05:25 2009 From: trac at galois.com (GHC) Date: Fri Oct 2 03:43:17 2009 Subject: [GHC] #3540: Parser accepts malformed types with implicit parameters In-Reply-To: <043.a36047b0c114003b419dbf8833abfb27@localhost> References: <043.a36047b0c114003b419dbf8833abfb27@localhost> Message-ID: <052.d6f6934eeb48afacea39f927de3d1d19@localhost> #3540: Parser accepts malformed types with implicit parameters --------------------------------------------+------------------------------- Reporter: benl | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler (Parser) | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: typecheck/should_fail/T3540 | Os: Unknown/Multiple Architecture: Unknown/Multiple | --------------------------------------------+------------------------------- Changes (by simonpj): * testcase: => typecheck/should_fail/T3540 * owner: => igloo * type: bug => merge Comment: Fixed by {{{ Wed Sep 30 03:47:03 PDT 2009 simonpj@microsoft.com * Fix Trac #3540: malformed types Ignore-this: bbd5543b88e6beadd1a9ae9d0ebce15e Tidy up the way that predicates are handled inside types M ./compiler/typecheck/TcBinds.lhs -12 +15 M ./compiler/typecheck/TcHsType.lhs -19 +24 M ./compiler/typecheck/TcMType.lhs -10 +9 }}} Worth merging to 6.12 if easy Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 2 04:11:13 2009 From: trac at galois.com (GHC) Date: Fri Oct 2 03:49:05 2009 Subject: [GHC] #3540: Parser accepts malformed types with implicit parameters In-Reply-To: <043.a36047b0c114003b419dbf8833abfb27@localhost> References: <043.a36047b0c114003b419dbf8833abfb27@localhost> Message-ID: <052.9bf2f8894a1871d143f04cc488f84192@localhost> #3540: Parser accepts malformed types with implicit parameters --------------------------------------------+------------------------------- Reporter: benl | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler (Parser) | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: typecheck/should_fail/T3540 | Os: Unknown/Multiple Architecture: Unknown/Multiple | --------------------------------------------+------------------------------- Comment (by simonpj): These two testsuite patches belong with the above change {{{ Wed Sep 30 04:07:42 PDT 2009 simonpj@microsoft.com * Track error message changes Ignore-this: cac29e62d8f2e0a6293db4969ad9e8c3 M ./tests/ghc-regress/indexed-types/should_compile/Simple13.hs +3 M ./tests/ghc-regress/indexed-types/should_fail/Simple14.stderr -1 +1 M ./tests/ghc-regress/typecheck/should_compile/all.T +1 M ./tests/ghc-regress/typecheck/should_fail/T2994.hs +2 M ./tests/ghc-regress/typecheck/should_fail/T2994.stderr -5 +9 }}} and {{{ Wed Sep 30 04:07:12 PDT 2009 simonpj@microsoft.com * Test Trac #3540 Ignore-this: 1329e8d3902ccf4080c3f4dfe4c90b9d A ./tests/ghc-regress/typecheck/should_fail/T3540.hs A ./tests/ghc-regress/typecheck/should_fail/T3540.stderr M ./tests/ghc-regress/typecheck/should_fail/all.T +1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 2 05:08:47 2009 From: trac at galois.com (GHC) Date: Fri Oct 2 04:46:40 2009 Subject: [GHC] #2273: inlining defeats seq In-Reply-To: <044.9c3223a55b4d3223b10ccf35be7e7d4f@localhost> References: <044.9c3223a55b4d3223b10ccf35be7e7d4f@localhost> Message-ID: <053.e0155479d5653e300620df29717f1163@localhost> #2273: inlining defeats seq ---------------------------------+------------------------------------------ Reporter: igloo | Owner: igloo Type: merge | Status: reopened Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * status: closed => reopened * resolution: fixed => Comment: See also this thread, http://www.haskell.org/pipermail/cvs- ghc/2009-September/050164.html, which describes another instance of the very same thing. Furthermore, this instance is NOT FIXED by the above patch. So I'm re-opening. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 2 09:03:47 2009 From: trac at galois.com (GHC) Date: Fri Oct 2 08:41:40 2009 Subject: [GHC] #2273: inlining defeats seq In-Reply-To: <044.9c3223a55b4d3223b10ccf35be7e7d4f@localhost> References: <044.9c3223a55b4d3223b10ccf35be7e7d4f@localhost> Message-ID: <053.6b9b5fee92d091f59753d1fbeb051e38@localhost> #2273: inlining defeats seq ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: merge | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: reopened => new * owner: igloo => -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 2 10:46:37 2009 From: trac at galois.com (GHC) Date: Fri Oct 2 10:24:33 2009 Subject: [GHC] #3555: Vectorisation error with negative Double const In-Reply-To: <042.76488390a8c998c2738bb2a24f69b062@localhost> References: <042.76488390a8c998c2738bb2a24f69b062@localhost> Message-ID: <051.e7d952be3ec1a7593af20e8790df05f5@localhost> #3555: Vectorisation error with negative Double const -----------------------------------+---------------------------------------- Reporter: ams | Owner: rl Type: bug | Status: new Priority: normal | Milestone: Component: Data Parallel Haskell | Version: 6.13 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------------+---------------------------------------- Comment (by ams): Thanks for the prompt response. Still a bit confused -- not seeing how type classes come into play with -1.0. Is it an overloaded constant? Even in that case, I've given its type as Double explicitly. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 2 12:41:40 2009 From: trac at galois.com (GHC) Date: Fri Oct 2 12:19:29 2009 Subject: [GHC] #3557: SIMD operations in GHC.Prim Message-ID: <044.db8b087837e05fdd9a6c4304c2acd80c@localhost> #3557: SIMD operations in GHC.Prim -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler (NCG) Version: 6.11 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- It would be nice to have support for vector unit (MMX, SSE, AltiVec, and so on) operations in GHC. Currently Data Parallel Haskell cannot utilize vector units due to GHC's lack of support. Those vector operations could be nicely used to get e.g. stereo signal processing for the price of mono signal processing. Maybe those operations could be added to GHC.Prim, or because there are so many, to a new module, GHC.Prim.Vector. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 2 14:19:28 2009 From: trac at galois.com (GHC) Date: Fri Oct 2 13:57:20 2009 Subject: [GHC] #3540: Parser accepts malformed types with implicit parameters In-Reply-To: <043.a36047b0c114003b419dbf8833abfb27@localhost> References: <043.a36047b0c114003b419dbf8833abfb27@localhost> Message-ID: <052.7a799c9abc018dd0b05a620b6749de5c@localhost> #3540: Parser accepts malformed types with implicit parameters --------------------------------------------+------------------------------- Reporter: benl | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.12 branch Component: Compiler (Parser) | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: typecheck/should_fail/T3540 | Os: Unknown/Multiple Architecture: Unknown/Multiple | --------------------------------------------+------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 2 20:36:32 2009 From: trac at galois.com (GHC) Date: Fri Oct 2 20:14:20 2009 Subject: [GHC] #3558: Make haddock compilable without ghci being enabled Message-ID: <044.b8b389feb5e456baa4a248a5d7edff3d@localhost> #3558: Make haddock compilable without ghci being enabled -------------------------------+-------------------------------------------- Reporter: igloo | Owner: Type: task | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.10.4 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- Make haddock compilable without ghci being enabled, and set `HADDOCK_DOCS` default back to just YES. It was changed in this patch: {{{ Sun Sep 20 19:13:19 BST 2009 Matthias Kilian * Don't build haddock if HADDOC_DOCS = NO, and disable HADDOC_DOCS if GhcWithInterpreter = NO Ignore-this: 1268ae31d74e746b09287814ee435f65 Haddock uses TcRnDriver.tcRnGetInfo, which is only available if GHCI is built. Set HADDOC_DOCS to NO if GhcWithInterpreter is NO, and disable the haddock build if HADDOC_DOCS = NO. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 2 20:46:48 2009 From: trac at galois.com (GHC) Date: Fri Oct 2 20:24:35 2009 Subject: [GHC] #3559: split ghci modules off into their own package Message-ID: <044.482aa0aa1f1cefce182fab9f2b16a74b@localhost> #3559: split ghci modules off into their own package -------------------------------+-------------------------------------------- Reporter: igloo | Owner: Type: task | Status: new Priority: normal | Milestone: 6.14.1 Component: GHCi | Version: 6.10.4 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- ghci code should be split into bits that are always compiled (and always work), and modules that are in a separate `ghci` package. The current situation means that clients of the GHC API cannot specify whether or not they need the ghci modules (or other code inside `GHCI` ifdefs), and means that clients may accidentally end up using ghci-only interfaces without realising it. This is not just hypothetical: haddock has grown a dependency on ghci code: #3558. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 2 21:16:53 2009 From: trac at galois.com (GHC) Date: Fri Oct 2 20:54:50 2009 Subject: [GHC] #3560: Template Haskell attempts to load unnecessary packages Message-ID: <047.da0beb5a47d42976e7e20de3cbe48963@localhost> #3560: Template Haskell attempts to load unnecessary packages -----------------------------+---------------------------------------------- Reporter: heatsink | Owner: Type: bug | Status: new Priority: normal | Component: Template Haskell Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- To run TH splices, GHC's interpreter loads all packages specified on the command line, even if they are not needed. This causes compilation to fail when an unused package works with the compiler, but not with the interpreter. Consider the one-line program {{{{-# LANGUAGE TemplateHaskell #-} main = print $([|1|])}}}. I can compile it with {{{ghc --make Main.hs}}}. If I add the extra command line parameter {{{-package WeakTest}}}, compilation fails when attempting to load the WeakTest package. (This package demonstrates a GHCi bug and is attached to #3333). Why put a superfluous package on the command line? This may happen because a build system uses the same set of flags to compile every file. This is the current behavior of Cabal. A possible solution would be for GHC to reuse the mechanism that GHC --make uses for deciding which command line packages to actually load. This way, extra packages won't prevent compilation. This would make it easier to use TH in a project that relies on non-interpreted packages. See also #3333. Possibly related #2555. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 3 00:57:41 2009 From: trac at galois.com (GHC) Date: Sat Oct 3 00:35:36 2009 Subject: [GHC] #3555: Vectorisation error with negative Double const In-Reply-To: <042.76488390a8c998c2738bb2a24f69b062@localhost> References: <042.76488390a8c998c2738bb2a24f69b062@localhost> Message-ID: <051.d0c67d43fe3a5f31050f9f2296828ab6@localhost> #3555: Vectorisation error with negative Double const -----------------------------------+---------------------------------------- Reporter: ams | Owner: rl Type: bug | Status: new Priority: normal | Milestone: Component: Data Parallel Haskell | Version: 6.13 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------------+---------------------------------------- Comment (by rl): This is because `-1.0` gets desugared to `negate 1.0` and `negate` is a method of `Num`. Unfortunately, Haskell doesn't have negative literals. It would be possible to add support to the vectoriser for this particular case but I'm not sure it's worth it since there is an easy workaround and the problem will go away once we are able to vectorise the prelude. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 3 04:46:18 2009 From: trac at galois.com (GHC) Date: Sat Oct 3 04:24:07 2009 Subject: [GHC] #3560: Template Haskell attempts to load unnecessary packages In-Reply-To: <047.da0beb5a47d42976e7e20de3cbe48963@localhost> References: <047.da0beb5a47d42976e7e20de3cbe48963@localhost> Message-ID: <056.27e44eb7cfd2716fefe659438cccbc75@localhost> #3560: Template Haskell attempts to load unnecessary packages ------------------------------+--------------------------------------------- Reporter: heatsink | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by duncan): I should note that this would also improve the compile times in large projects that use TH. For example, in a happstack server a little bit of TH in one module ends up loading about 40 packages. The TH/ghci package load time is what actually dominates. That said, this performance problem will also go away if we use shared libs. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 3 14:44:28 2009 From: trac at galois.com (GHC) Date: Sat Oct 3 14:22:36 2009 Subject: [GHC] #3531: Haddock needs tcRnGetInfo, hence GhcWithInterpreter YES In-Reply-To: <043.f3ae9723755c0a36083ac743990981c8@localhost> References: <043.f3ae9723755c0a36083ac743990981c8@localhost> Message-ID: <052.7d8ce5a7566e38f8e333eb7c71364f65@localhost> #3531: Haddock needs tcRnGetInfo, hence GhcWithInterpreter YES -----------------------------+---------------------------------------------- Reporter: donn | Owner: simonmar Type: bug | Status: reopened Priority: high | Milestone: 6.12.1 Component: Build System | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: NetBSD Architecture: x86 | -----------------------------+---------------------------------------------- Comment (by kili): Replying to [comment:3 igloo]: > Is there a reason for this function to be enabled only if GHCi is? It would be possible to compile and export tcRnGetInfo (and some other functions used by it) unconditionally. In addition, tcRnLookupName would have to be exported unconditionally, and the definition of InteractiveEval.lookupName would have to be copied to haddock. I could make a patch, but imho this would be a very ugly workaround. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 4 03:55:54 2009 From: trac at galois.com (GHC) Date: Sun Oct 4 03:33:40 2009 Subject: [GHC] #3557: SIMD operations in GHC.Prim In-Reply-To: <044.db8b087837e05fdd9a6c4304c2acd80c@localhost> References: <044.db8b087837e05fdd9a6c4304c2acd80c@localhost> Message-ID: <053.159080124ecf045740deea04085d217d@localhost> #3557: SIMD operations in GHC.Prim ------------------------------+--------------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 6.11 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by Axman6): * cc: axman6@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 4 10:40:29 2009 From: trac at galois.com (GHC) Date: Sun Oct 4 10:18:26 2009 Subject: [GHC] #3231: Permission denied error with runProcess/openFile In-Reply-To: <051.9654be8110cd7a09257c98a211221fb3@localhost> References: <051.9654be8110cd7a09257c98a211221fb3@localhost> Message-ID: <060.57830e58fd3ad949196df5bd5efaf307@localhost> #3231: Permission denied error with runProcess/openFile ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Runtime System | Version: 6.10.4 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by yugr): Hi all, Sorry to bother you once again but I think we may still have problem with #3231 (http://hackage.haskell.org/trac/ghc/ticket/3231). Before I go into details have a look at the code below - is it free from problem with lazy IO which you mentioned above? I am still running into errors with a small multi-process program: bug.exe: mytempfile.txt: openFile: permission denied (Permission denied) or if I remove if-then-else bug.exe: DeleteFile: permission denied ... {{{ module Main where import System import System.IO import System.Process (runProcess, waitForProcess) import System.Directory (removeFile) import Control.Monad (replicateM_) import Control.Parallel (pseq) import qualified Data.ByteString as B run :: FilePath -> IO () run exe = do let tempFile = "mytempfile.txt" h <- openFile tempFile WriteMode exitCode <- waitForProcess =<< runProcess exe [] Nothing Nothing Nothing (Just h) (Just h) hClose h >> (if exitCode /= ExitSuccess then return () else B.readFile tempFile >>= B.putStr) >> removeFile tempFile main = replicateM_ 100 (putStrLn "Next:" >> run "a.exe") }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 4 17:14:09 2009 From: trac at galois.com (GHC) Date: Sun Oct 4 16:51:52 2009 Subject: [GHC] #3556: Build the bootstrapping ghc-pkg with ghc-cabal In-Reply-To: <044.67ca5f0d38da2c2c1eba80992f3ceec9@localhost> References: <044.67ca5f0d38da2c2c1eba80992f3ceec9@localhost> Message-ID: <053.55c84c8ac1a2a1e5c9014f5ff0bdc897@localhost> #3556: Build the bootstrapping ghc-pkg with ghc-cabal ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: task | Status: new Priority: normal | Milestone: 6.14.1 Component: Build System | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by igloo): It may also be worth building stage1 earlier, so that we don't need the dummy-ghc hack. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 4 18:08:40 2009 From: trac at galois.com (GHC) Date: Sun Oct 4 17:46:22 2009 Subject: [GHC] #3561: Incorrect code generation on x86 Message-ID: <046.830b8d22811c2db4fef4cbd450983c13@localhost> #3561: Incorrect code generation on x86 -----------------------------+---------------------------------------------- Reporter: aleksey | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: major Keywords: | Testcase: Os: Unknown/Multiple | Architecture: x86 -----------------------------+---------------------------------------------- This program prints "0" on x86 with ghc-6.10.4 and "-O" optimization at least under Linux and FreeBSD: {{{ main = print $ pqr' 0 1 pqr' :: Int -> Int -> Integer pqr' a b | a == b - 1 = rab | otherwise = ram * rmb where m = (a + b) `div` 2 ram = pqr' a m rmb = pqr' m b rab = toInteger (6 * b - 5) * toInteger (2 * b - 1) * toInteger (6 * b - 1) }}} It prints the correct value "5" with either "-O0", or "-fvia-C", or on x86_64. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 5 07:27:20 2009 From: trac at galois.com (GHC) Date: Mon Oct 5 07:05:03 2009 Subject: [GHC] #3551: Tests conc069 and conc070 failing for unregistered build In-Reply-To: <045.94f74b3da2564c9807512be40aa93367@localhost> References: <045.94f74b3da2564c9807512be40aa93367@localhost> Message-ID: <054.e381752ad3c5560ee37b3898d269276b@localhost> #3551: Tests conc069 and conc070 failing for unregistered build ---------------------------------+------------------------------------------ Reporter: dterei | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Test Suite | Version: Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: conc069 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => fixed * milestone: => 6.12.1 Comment: Fixed, thanks for the report {{{ Tue Sep 29 07:55:26 PDT 2009 Simon Marlow * Fix #3551: conc0{69,70} should be skipped when -threaded is not available }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 5 07:39:25 2009 From: trac at galois.com (GHC) Date: Mon Oct 5 07:17:05 2009 Subject: [GHC] #3559: split ghci modules off into their own package In-Reply-To: <044.482aa0aa1f1cefce182fab9f2b16a74b@localhost> References: <044.482aa0aa1f1cefce182fab9f2b16a74b@localhost> Message-ID: <053.03a647baf0029b935c83e684c804d7e7@localhost> #3559: split ghci modules off into their own package ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: task | Status: new Priority: normal | Milestone: 6.14.1 Component: GHCi | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): I don't think we can split off a separate ghci package, because it would be mutually recursive with the ghc package. The main reason for the GHCI `#ifdef` is that we can only use GHCi in stage 2 when the libraries we dynamically load are the same as the ones that GHC itself is linked with, so that data representations etc. are compatible. We never ship a `ghc` package without GHCi support, so clients don't need to worry about this. Now, it's possible we could pull enough code out from inside GHCI to fix the Haddock issue described above, and that's not a bad thing. But I don't think this is an issue that affects any other clients. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 5 07:51:01 2009 From: trac at galois.com (GHC) Date: Mon Oct 5 07:28:43 2009 Subject: [GHC] #3560: Template Haskell attempts to load unnecessary packages In-Reply-To: <047.da0beb5a47d42976e7e20de3cbe48963@localhost> References: <047.da0beb5a47d42976e7e20de3cbe48963@localhost> Message-ID: <056.ea71f376059d18442e8b4c05d54bbe77@localhost> #3560: Template Haskell attempts to load unnecessary packages ---------------------------------+------------------------------------------ Reporter: heatsink | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Template Haskell | Version: 6.10.4 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: This is a dup of #2437, but I forgive you for not finding it, it took me quite a bit of searching to track the ticket down. Using the actual dependencies is a good idea, so I'll point to this ticket from #2437. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 5 07:52:06 2009 From: trac at galois.com (GHC) Date: Mon Oct 5 07:30:21 2009 Subject: [GHC] #2437: More accurate package dependencies In-Reply-To: <047.68fd28011c214b441523af716564e799@localhost> References: <047.68fd28011c214b441523af716564e799@localhost> Message-ID: <056.3de56b9c7863843b355cd476bba600f6@localhost> #2437: More accurate package dependencies ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 6.12 branch Component: Package system | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): See #2437. One suggestion there is for GHC to use the actual dependencies for TH code rather than linking in every package mentioned in a `-package` flag. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 5 12:12:29 2009 From: trac at galois.com (GHC) Date: Mon Oct 5 11:50:42 2009 Subject: [GHC] #2437: More accurate package dependencies In-Reply-To: <047.68fd28011c214b441523af716564e799@localhost> References: <047.68fd28011c214b441523af716564e799@localhost> Message-ID: <056.0706b396905b80a51576c7b61303d792@localhost> #2437: More accurate package dependencies ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 6.12 branch Component: Package system | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by heatsink): After seeing #2437, see #3560. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 6 04:59:40 2009 From: trac at galois.com (GHC) Date: Tue Oct 6 04:37:19 2009 Subject: [GHC] #3562: syb package on Hackage does not work with 6.12 Message-ID: <047.ca75d0163023fb07d978a0b10f3fc7bc@localhost> #3562: syb package on Hackage does not work with 6.12 -------------------------------+-------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.10.4 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- The syb package on Hackage (0.1.0.1) has `-package-name syb`, which was needed for 6.10 but breaks with 6.12. The version in darcs lacks the flag, which works for 6.12 but will break with 6.10. We need to upload a version of syb that works with both 6.10 and 6.12 to Hackage before the 6.12.1 release. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 6 05:52:27 2009 From: trac at galois.com (GHC) Date: Tue Oct 6 05:30:11 2009 Subject: [GHC] #3562: syb package on Hackage does not work with 6.12 In-Reply-To: <047.ca75d0163023fb07d978a0b10f3fc7bc@localhost> References: <047.ca75d0163023fb07d978a0b10f3fc7bc@localhost> Message-ID: <056.1cc59e5315ccb61f70b5924449f4b4ad@localhost> #3562: syb package on Hackage does not work with 6.12 ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by dreixel): * cc: jpm@cs.uu.nl (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 6 06:12:24 2009 From: trac at galois.com (GHC) Date: Tue Oct 6 05:50:07 2009 Subject: [GHC] #3557: SIMD operations in GHC.Prim In-Reply-To: <044.db8b087837e05fdd9a6c4304c2acd80c@localhost> References: <044.db8b087837e05fdd9a6c4304c2acd80c@localhost> Message-ID: <053.113028244a38bc58a4f6dc9548510713@localhost> #3557: SIMD operations in GHC.Prim ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler (NCG) | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * difficulty: => Unknown * milestone: => _|_ Comment: Yes, this is a good idea, though it would be a fair amount of work. We need new primitive types for the vector data types, and new primitives for each operation. Cmm would need new vector data types, and the native code generator(s) need to know how to allocate registers. We'd have to decide whether/how to use vector registers for argument passing. This might be easier with the new backend. A good student project, or SoC project perhaps? Leaving the milestone at _|_ for now. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 6 06:39:00 2009 From: trac at galois.com (GHC) Date: Tue Oct 6 06:16:39 2009 Subject: [GHC] #3561: Incorrect code generation on x86 In-Reply-To: <046.830b8d22811c2db4fef4cbd450983c13@localhost> References: <046.830b8d22811c2db4fef4cbd450983c13@localhost> Message-ID: <055.1f52b2b5f0419c75074e07c52c2556fe@localhost> #3561: Incorrect code generation on x86 -------------------------+-------------------------------------------------- Reporter: aleksey | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.10.4 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by simonmar): * priority: normal => high * difficulty: => Unknown * milestone: => 6.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 6 11:02:21 2009 From: trac at galois.com (GHC) Date: Tue Oct 6 10:41:11 2009 Subject: [GHC] #2965: GHC on OS X does not compile 64-bit In-Reply-To: <045.2214e7d1fe4dd43486128c197fdb9227@localhost> References: <045.2214e7d1fe4dd43486128c197fdb9227@localhost> Message-ID: <054.faa47a2a79aa6e33e32022a94b859ad6@localhost> #2965: GHC on OS X does not compile 64-bit --------------------------------+------------------------------------------- Reporter: Axman6 | Owner: thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: Severity: normal | Resolution: Keywords: 64bit | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86_64 (amd64) | --------------------------------+------------------------------------------- Changes (by j0ni): * cc: ghc@tapdancingmonkey.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 6 11:38:41 2009 From: trac at galois.com (GHC) Date: Tue Oct 6 11:16:19 2009 Subject: [GHC] #3553: parallel gc suffers badly if one thread is descheduled In-Reply-To: <047.48e7cf5ad32bf05ce8bca6e11b9273f8@localhost> References: <047.48e7cf5ad32bf05ce8bca6e11b9273f8@localhost> Message-ID: <056.e87481d179dea95ba274ee267c91e0f5@localhost> #3553: parallel gc suffers badly if one thread is descheduled ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: Runtime System | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): I tried using condition variables, but it was significantly slower than spinlocks. Experimental patch attached (or would be, if it wasn't so large). {{{ Tue Oct 6 16:32:58 BST 2009 Simon Marlow * EXPERIMENT: use condition variables instead of spinlocks for the GC barrier This was significantly slower, averaging +20% with 7 cores on nofib/parallel. { hunk ./rts/sm/GC.c 132 +#if defined(THREADED_RTS) +Mutex gc_threads_ready_lock; +Condition gc_threads_ready_cond; +nat gc_threads_ready; + +Mutex gc_threads_go_lock; +Condition gc_threads_go_cond; +rtsBool gc_threads_go; +#endif + hunk ./rts/sm/GC.c 885 - initSpinLock(&t->gc_spin); - initSpinLock(&t->mut_spin); - ACQUIRE_SPIN_LOCK(&t->gc_spin); hunk ./rts/sm/GC.c 937 + + initMutex(&gc_threads_ready_lock); + initCondition(&gc_threads_ready_cond); + gc_threads_ready = 0; + initMutex(&gc_threads_go_lock); + initCondition(&gc_threads_go_cond); + gc_threads_go = rtsFalse; hunk ./rts/sm/GC.c 1094 - // Wait until we're told to wake up - RELEASE_SPIN_LOCK(&gct->mut_spin); hunk ./rts/sm/GC.c 1095 + + // Wait until we're told to wake up + ACQUIRE_LOCK(&gc_threads_ready_lock); + gc_threads_ready++; + debugTrace(DEBUG_gc, "GC thread %d: gc_threads_ready = %d", gct->thread_index, gc_threads_ready); + if (gc_threads_ready >= RtsFlags.ParFlags.nNodes-1) { + signalCondition(&gc_threads_ready_cond); + } + RELEASE_LOCK(&gc_threads_ready_lock); + hunk ./rts/sm/GC.c 1106 - ACQUIRE_SPIN_LOCK(&gct->gc_spin); + + ACQUIRE_LOCK(&gc_threads_go_lock); + while (!gc_threads_go) { + waitCondition(&gc_threads_go_cond, &gc_threads_go_lock); + } + RELEASE_LOCK(&gc_threads_go_lock); hunk ./rts/sm/GC.c 1134 - // Wait until we're told to continue - RELEASE_SPIN_LOCK(&gct->gc_spin); hunk ./rts/sm/GC.c 1135 + + // Wait until we're told to continue + ACQUIRE_LOCK(&gc_threads_ready_lock); + gc_threads_ready++; + if (gc_threads_ready >= RtsFlags.ParFlags.nNodes-1) { + signalCondition(&gc_threads_ready_cond); + } + RELEASE_LOCK(&gc_threads_ready_lock); + hunk ./rts/sm/GC.c 1146 - ACQUIRE_SPIN_LOCK(&gct->mut_spin); + + ACQUIRE_LOCK(&gc_threads_go_lock); + while (gc_threads_go) { + waitCondition(&gc_threads_go_cond, &gc_threads_go_lock); + } + RELEASE_LOCK(&gc_threads_go_lock); + hunk ./rts/sm/GC.c 1155 + gct->wakeup = GC_THREAD_INACTIVE; + hunk ./rts/sm/GC.c 1169 - nat i, j; + nat i; hunk ./rts/sm/GC.c 1172 - while(retry) { - for (i=0; i < n_threads; i++) { - if (i == me) continue; - if (gc_threads[i]->wakeup != GC_THREAD_STANDING_BY) { - prodCapability(&capabilities[i], cap->running_task); - } - } - for (j=0; j < 10000000; j++) { - retry = rtsFalse; - for (i=0; i < n_threads; i++) { - if (i == me) continue; - write_barrier(); - setContextSwitches(); - if (gc_threads[i]->wakeup != GC_THREAD_STANDING_BY) { - retry = rtsTrue; - } - } - if (!retry) break; + for (i=0; i < n_threads; i++) { + if (i == me) continue; + if (gc_threads[i]->wakeup != GC_THREAD_STANDING_BY) { + prodCapability(&capabilities[i], cap->running_task); hunk ./rts/sm/GC.c 1178 + setContextSwitches(); + $ + gc_threads_go = rtsFalse; + $ + ACQUIRE_LOCK(&gc_threads_ready_lock); + while (gc_threads_ready < n_threads-1) { + debugTrace(DEBUG_gc, "waitForGcThreads: gc_threads_ready = %d", gc_threads_ready); + waitCondition(&gc_threads_ready_cond, &gc_threads_ready_lock); + } $ + gc_threads_ready = 0; + RELEASE_LOCK(&gc_threads_ready_lock); hunk ./rts/sm/GC.c 1213 - ACQUIRE_SPIN_LOCK(&gc_threads[i]->mut_spin); - RELEASE_SPIN_LOCK(&gc_threads[i]->gc_spin); +// ACQUIRE_SPIN_LOCK(&gc_threads[i]->mut_spin); +// RELEASE_SPIN_LOCK(&gc_threads[i]->gc_spin); hunk ./rts/sm/GC.c 1216 + + ACQUIRE_LOCK(&gc_threads_go_lock); + gc_threads_go = rtsTrue; + broadcastCondition(&gc_threads_go_cond); + RELEASE_LOCK(&gc_threads_go_lock); hunk ./rts/sm/GC.c 1231 - nat i; - for (i=0; i < n_threads; i++) { - if (i == me) continue; - while (gc_threads[i]->wakeup != GC_THREAD_WAITING_TO_CONTINUE) { write_barrier(); } + ACQUIRE_LOCK(&gc_threads_ready_lock); + while (gc_threads_ready < n_threads-1) { + debugTrace(DEBUG_gc, "shutdown_gc_threads: %d", gc_threads_ready); + waitCondition(&gc_threads_ready_cond, &gc_threads_ready_lock); hunk ./rts/sm/GC.c 1236 + gc_threads_ready = 0; + RELEASE_LOCK(&gc_threads_ready_lock); hunk ./rts/sm/GC.c 1243 -releaseGCThreads (Capability *cap USED_IF_THREADS) +releaseGCThreads (Capability *cap STG_UNUSED) hunk ./rts/sm/GC.c 1245 - nat n_threads = RtsFlags.ParFlags.nNodes; - nat me = cap->no; - nat i; - for (i=0; i < n_threads; i++) { - if (i == me) continue; - if (gc_threads[i]->wakeup != GC_THREAD_WAITING_TO_CONTINUE) $ - barf("releaseGCThreads"); - $ - gc_threads[i]->wakeup = GC_THREAD_INACTIVE; - ACQUIRE_SPIN_LOCK(&gc_threads[i]->gc_spin); - RELEASE_SPIN_LOCK(&gc_threads[i]->mut_spin); - } + debugTrace(DEBUG_gc, "releaseGCThreads"); + ACQUIRE_LOCK(&gc_threads_go_lock); + gc_threads_go = rtsFalse; + broadcastCondition(&gc_threads_go_cond); + RELEASE_LOCK(&gc_threads_go_lock); hunk ./rts/sm/GCThread.h 119 - SpinLock gc_spin; - SpinLock mut_spin; } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 6 12:02:25 2009 From: trac at galois.com (GHC) Date: Tue Oct 6 11:40:12 2009 Subject: [GHC] #3561: Incorrect code generation on x86 In-Reply-To: <046.830b8d22811c2db4fef4cbd450983c13@localhost> References: <046.830b8d22811c2db4fef4cbd450983c13@localhost> Message-ID: <055.75fffc43de1828a7422b4a7ba7360117@localhost> #3561: Incorrect code generation on x86 -------------------------+-------------------------------------------------- Reporter: aleksey | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.10.4 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86 | -------------------------+-------------------------------------------------- Comment (by igloo): I can reproduce this with 6.10.1 but not 6.12.0.20091005, so it looks like it is already fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 7 02:56:10 2009 From: trac at galois.com (GHC) Date: Wed Oct 7 02:33:49 2009 Subject: [GHC] #1185: can't do I/O in the child of forkProcess with -threaded In-Reply-To: <047.505ed9940eff9ef82094c96c7212dfa3@localhost> References: <047.505ed9940eff9ef82094c96c7212dfa3@localhost> Message-ID: <056.84387727727ddc5edf2f28e88459fc21@localhost> #1185: can't do I/O in the child of forkProcess with -threaded ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Runtime System | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by kazu-yamamoto): * cc: kazu@iij.ad.jp (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 7 03:40:55 2009 From: trac at galois.com (GHC) Date: Wed Oct 7 03:18:29 2009 Subject: [GHC] #3563: A couple of additions to Data.Bits Message-ID: <045.1f98bcf2b0cef8bd6c1373dcce0d242a@localhost> #3563: A couple of additions to Data.Bits -----------------------------+---------------------------------------------- Reporter: porges | Owner: Type: proposal | Status: new Priority: normal | Component: libraries/base Version: 6.11 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Population count is an often-needed function when bitfiddling, so I think a version should be supplied. I also have included functions for converting to and from lists of Booleans: {{{ -- population count popCount :: (Bits a, Num t) => a -> t popCount x = count' (bitSize x) x 0 where count' 0 _ acc = acc count' n x acc = count' (n-1) (x `shiftR` 1) (acc + if x .&. 1 == 1 then 1 else 0) -- this weird if/else is to preserve the nice type signature :) -- converts a list of bools to a number fromBools :: (Bits a) => [Bool] -> a fromBools = foldl' (\i b -> (i `shiftL` 1) .|. if b then 1 else 0) 0 -- likewise -- converts a number to a list of bools toBools :: (Bits a) => a -> [Bool] toBools x = reverse (toBools' (bitSize x) x) where toBools' 0 _ = [] toBools' n x = (x .&. 1 == 1) : toBools' (n-1) (x `shiftR` 1) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 7 12:37:05 2009 From: trac at galois.com (GHC) Date: Wed Oct 7 12:14:38 2009 Subject: [GHC] #3526: Inliner behaviour with instances is confusing In-Reply-To: <042.8258495ea2dc159620716346effd3b92@localhost> References: <042.8258495ea2dc159620716346effd3b92@localhost> Message-ID: <051.f4468ace70ff338828d08ce54499ab58@localhost> #3526: Inliner behaviour with instances is confusing ---------------------------------+------------------------------------------ Reporter: bos | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * owner: => simonpj Comment: I'll look at this when I've got the new INLINE patch done. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 7 19:31:32 2009 From: trac at galois.com (GHC) Date: Wed Oct 7 19:09:09 2009 Subject: [GHC] #3564: Drop-in replacements for integer library no longer work Message-ID: <042.3e37fb5244f087d1815ce1d37432dd30@localhost> #3564: Drop-in replacements for integer library no longer work -----------------------------+---------------------------------------------- Reporter: tim | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- I was trying to replace the integer-gmp library with integer-simple in a recent GHC tree, as described at: http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes Unfortunately, simply adding "INTEGER_LIBRARY=integer-simple" to the build.mk no longer works, because compiler/PrelNames has a hard-wired reference to the module GHC.Integer.Internals, which integer-simple doesn't provide. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 7 20:01:00 2009 From: trac at galois.com (GHC) Date: Wed Oct 7 19:38:37 2009 Subject: [GHC] #3564: Drop-in replacements for integer library no longer work In-Reply-To: <042.3e37fb5244f087d1815ce1d37432dd30@localhost> References: <042.3e37fb5244f087d1815ce1d37432dd30@localhost> Message-ID: <051.6159c8493097f774ad2b380c000c702e@localhost> #3564: Drop-in replacements for integer library no longer work ---------------------------------+------------------------------------------ Reporter: tim | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: Thanks for the report. You mean it doesn't work with 6.10.4, right? That's expected; it will work in 6.12.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 7 20:04:01 2009 From: trac at galois.com (GHC) Date: Wed Oct 7 19:41:38 2009 Subject: [GHC] #3564: Drop-in replacements for integer library no longer work In-Reply-To: <042.3e37fb5244f087d1815ce1d37432dd30@localhost> References: <042.3e37fb5244f087d1815ce1d37432dd30@localhost> Message-ID: <051.e8c6239b3134b344c3e1f1811c1ba8c8@localhost> #3564: Drop-in replacements for integer library no longer work ---------------------------------+------------------------------------------ Reporter: tim | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by tim): That's right, 6.10.4. Does that mean that currently it works in the HEAD? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 7 20:17:31 2009 From: trac at galois.com (GHC) Date: Wed Oct 7 19:55:09 2009 Subject: [GHC] #3564: Drop-in replacements for integer library no longer work In-Reply-To: <042.3e37fb5244f087d1815ce1d37432dd30@localhost> References: <042.3e37fb5244f087d1815ce1d37432dd30@localhost> Message-ID: <051.08cd246f2d49c302cfb306b2571766bb@localhost> #3564: Drop-in replacements for integer library no longer work ---------------------------------+------------------------------------------ Reporter: tim | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by igloo): Replying to [comment:2 tim]: > > Does that mean that currently it works in the HEAD? Yes, HEAD and the 6.12 branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 8 07:13:08 2009 From: trac at galois.com (GHC) Date: Thu Oct 8 06:50:39 2009 Subject: [GHC] #3565: Wrong gcc being used Message-ID: <046.1a75409f814cd8c2531fe45e1f2aa63b@localhost> #3565: Wrong gcc being used -------------------------------+-------------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.4 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- SimonM and I have just spent two hours tracking down a horrible gcc- related problem. The current story is that we ship GHC complete with a Mingw `gcc`. Nowadays we go further, and put a Mingw installation into the GHC repo, so that someone building GHC doesn't need to download Mingw. This is good. The problem is this. The configure script includes {{{ AC_CHECK_FUNCS(__mingw_vfprintf) }}} It turns out that this check * Should say "no" with the Mingw stuff in the current GHC repo * But actually says "yes" Because of the wrong answer, compilation of `Linker.c` in the RTS fails with {{{ rts\Linker.c:904:0: error: `__mingw_vfprintf' undeclared here (not in a function) }}} Why is the answer wrong? Because: * The test correctly invokes `c:/code/HEAD/inplace/mingw/bin/gcc.exe`; ie the one in the tree * But, when linking, that `gcc` looks in `/mingw/lib`, where I just happen to have a (different) Mingw blob of files. That makes the link succeed when it should fail. Here's an example. Here is `foo.c`: {{{ char __mingw_vfprintf (); char (*f) () = __mingw_vfprintf; int main () { return 0; } }}} Now watch: {{{ bash-3.1$ c:/code/HEAD/inplace/mingw/bin/gcc.exe foo.c bash-3.1$ mv c:/mingw c:/mingw-save bash-3.1$ c:/code/HEAD/inplace/mingw/bin/gcc.exe foo.c C:/DOCUME~1/simonpj/LOCALS~1/Temp/ccuJ4q8y.o:foo.c:(.data+0x0): undefined reference to `__mingw_vfprintf' collect2: ld returned 1 exit status }}} Moving `c:/mingw` out of the way changes the behaviour!!! If you give a -B flag you can make it behave more predictably: {{{ bash-3.1$ mv c:/mingw-save c:/mingw bash-3.1$ c:/code/HEAD/inplace/mingw/bin/gcc.exe foo.c -Bc:/code/HEAD/inplace/mingw/lib C:/DOCUME~1/simonpj/LOCALS~1/Temp/ccuJ4q8y.o:foo.c:(.data+0x0): undefined reference to `__mingw_vfprintf' collect2: ld returned 1 exit status }}} That is, even with `c:/mingw` existing, the `-B` flag makes it do the right thing. Mind you, if you add `-v` you'll see that there are ''still'' references to `/mingw`, so it's still not really right. So far as we can see, the path "`/mingw`" is hard-wired into `gcc.exe`. It's not clear how to fix this. Probably the easiest path is to build a shim for `gcc.exe`, which lives in the same directory as `ghc.exe`, and which simply invokes the real `gcc` adding the `-B` flag. Fixing it is urgent for 6.12. If GHC 6.12 invokes `gcc` without passing a `-B` flag (and without a shim) we may link against libraries that happen randomly to be on the user's machine, rather than against the libraries that come with GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 8 07:42:52 2009 From: trac at galois.com (GHC) Date: Thu Oct 8 07:20:24 2009 Subject: [GHC] #3566: Install fails on Windows Message-ID: <046.53c3e977cd2a3f2d06ab45a50a92a739@localhost> #3566: Install fails on Windows -------------------------------+-------------------------------------------- Reporter: simonpj | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- When I do `sh validate` I get {{{ for i in utils/hp2ps/dist/build/tmp/hp2ps.exe driver/ghci/dist/build/tmp/ghci.exe driver/ghci/dist/build/tmp/ghci-6.13.20091007.exe driver/ghc/dist/build/tmp/ghc-6.13.20091007 utils/haddock/dist/build/tmp/haddock.exe utils/hsc2hs/dist- install/build/tmp/hsc2hs.exe utils/ghc-pkg/dist-install/build/tmp/ghc-pkg utils/hpc/dist/build/tmp/hpc.exe utils/runghc/dist/build/tmp/runghc.exe ghc/stage2/build/tmp/ghc-stage2.exe; do \ /usr/bin/install -c -m 755 $i /c/code/HEAD/inst/bin ; \ if test "" = "1"; then \ sh mk/fix_install_names.sh /c/code/HEAD/inst/lib /c/code/HEAD/inst/bin/$i ; \ fi ; \ done "cp" /c/code/HEAD/inst/bin/runghc.exe /c/code/HEAD/inst/bin/runhaskell.exe "rm" -f /c/code/HEAD/inst/bin/ghc.exe "mv" -f /c/code/HEAD/inst/bin/ghc-stage2.exe /c/code/HEAD/inst/bin/ghc.exe "cp" -Rp inplace/mingw /c/code/HEAD/inst c:/code/HEAD/inplace/mingw/bin/gcc.exe -E -undef -traditional -P -DINSTALLING -DLIB_DIR='"$topdir"' -DINCLUDE_DIR='"$topdir/include"' -x c -Iincludes libffi/package.conf.in | grep -v '^#pragma GCC' | sed -e 's/""//g' -e 's/:[ ]*,/: /g' >libffi/package.conf.install c:/code/HEAD/inplace/mingw/bin/gcc.exe -E -undef -traditional -P -DINSTALLING -DLIB_DIR='"$topdir"' -DINCLUDE_DIR='"$topdir/include"' -DPAPI_INCLUDE_DIR="" -DPAPI_LIB_DIR="" -DHAVE_LIBMINGWEX -x c -Iincludes rts/package.conf.in | grep -v '^#pragma GCC' | sed -e 's/""//g' -e 's/:[ ]*,/: /g' >rts/package.conf.install /usr/bin/install -c -m 755 -d /c/code/HEAD/inst/lib for i in ; do \ /usr/bin/install -c -m 755 $i /c/code/HEAD/inst/lib; \ done /bin/sh: -c: line 1: syntax error near unexpected token `;' /bin/sh: -c: line 1: `for i in ; do \' make[1]: *** [install_libexecs] Error 2 make: *** [install] Error 2 }}} Turns out that INSTALL_LIBEXECS is empty: {{{ sh-2.04$ make show VALUE=INSTALL_LIBEXECS make -r --no-print-directory -f ghc.mk show INSTALL_LIBEXECS="" }}} Simon did a patch on ghc.mk for this {{{ sh-2.04$ darcs what ghc.mk What's new in "ghc.mk": hunk ./ghc.mk 756 +ifneq "$(INSTALL_LIBEXECS)" "" hunk ./ghc.mk 760 +endif }}} But then something similar happens later: {{{ Registering dph-prim-interface-0.4.0... Installing library in c:/code/HEAD/inst/lib\dph-prim-seq-0.4.0 Registering dph-prim-seq-0.4.0... Installing library in c:/code/HEAD/inst/lib\dph-prim-par-0.4.0 Registering dph-prim-par-0.4.0... Installing library in c:/code/HEAD/inst/lib\dph-seq-0.4.0 Registering dph-seq-0.4.0... Installing library in c:/code/HEAD/inst/lib\dph-par-0.4.0 Registering dph-par-0.4.0... /c/code/HEAD/inst/bin/ghc-pkg.exe --global-conf /c/code/HEAD/inst/lib/package.conf.d hide binary && true "inplace/bin/ghc-cabal.exe" install \ /c/code/HEAD/inst/bin/ghc.exe \ /c/code/HEAD/inst/bin/ghc-pkg.exe \ /c/code/HEAD/inst/lib \ compiler stage2 \ '' '/c/code/HEAD/inst' '/c/code/HEAD/inst/lib' '/c/code/HEAD/inst/doc/html/libraries' \ YES Installing library in c:/code/HEAD/inst/lib\ghc-6.13.20091007 Registering ghc-6.13.20091007... /usr/bin/install -c -m 755 -d /c/code/HEAD/inst/lib for i in driver/ghc-usage.txt driver/ghci-usage.txt libffi/libHSffi.a libffi/HSffi.o extra-gcc-opts; do \ case $i in \ *.a) \ /usr/bin/install -c -m 644 $i /c/code/HEAD/inst/lib; \ : /c/code/HEAD/inst/lib/`basename $i` ;; \ *.dll) \ /usr/bin/install -c -m 644 -s $i /c/code/HEAD/inst/lib ;; \ *.so) \ /usr/bin/install -c -m 755 $i /c/code/HEAD/inst/lib ;; \ *.dylib) \ /usr/bin/install -c -m 755 $i /c/code/HEAD/inst/lib; \ install_name_tool -id /c/code/HEAD/inst/lib/`basename $i` /c/code/HEAD/inst/lib/`basename $i` ;; \ *) \ /usr/bin/install -c -m 644 $i /c/code/HEAD/inst/lib; \ esac; \ done /usr/bin/install -c -m 755 -d /c/code/HEAD/inst/lib/include for i in libffi/ffi.h; do \ /usr/bin/install -c -m 644 $i /c/code/HEAD/inst/lib/include; \ done /usr/bin/install -c -m 755 -d /c/code/HEAD/inst/lib for i in ; do \ /usr/bin/install -c -m 755 $i /c/code/HEAD/inst/lib; \ done /bin/sh: -c: line 1: syntax error near unexpected token `;' /bin/sh: -c: line 1: `for i in ; do \' make[1]: *** [install_libexec_scripts] Error 2 make: *** [install] Error 2 }}} I give up. Ian, can you fix this please? I'll discard Simon's patch... it's not even clear to me that INSTALL_LIBEXECS should ever be empty. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 8 07:45:10 2009 From: trac at galois.com (GHC) Date: Thu Oct 8 07:22:41 2009 Subject: [GHC] #3567: Configure script looks for ld too early Message-ID: <046.01ebc2924afd98045f37408ffa49da8f@localhost> #3567: Configure script looks for ld too early -------------------------------+-------------------------------------------- Reporter: simonpj | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.4 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- Because of #3565, I tried moving `c:/mingw` out of the way. But now 'configure' falls over saying {{{ checking for ld... no configure: error: cannot find ld in your PATH, no idea how to link }}} This is because 'configure' checks for ld before doing any of the mingw- tar-ball-unpacking stuff. (Somehow the treatment of `gcc`, just before, is different.) This is a show-stopper * because of #3565 the build fails if I have c:/mingw * because of the above, the configure fails if I don't have c:/mingw It'd be best to fix this before #3565; then people can at least make progress by moving c:/mingw to something else. Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 8 07:59:38 2009 From: trac at galois.com (GHC) Date: Thu Oct 8 07:37:21 2009 Subject: [GHC] #3231: Permission denied error with runProcess/openFile In-Reply-To: <051.9654be8110cd7a09257c98a211221fb3@localhost> References: <051.9654be8110cd7a09257c98a211221fb3@localhost> Message-ID: <060.6efc46ad8ca87df0ddbc95b015cd6210@localhost> #3231: Permission denied error with runProcess/openFile ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Runtime System | Version: 6.10.4 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): I don't see any problems with the code, although I don't know what the "a.exe" program is supposed to be. I substitued "ls" and it seemed to work for me with 6.12. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 8 09:01:44 2009 From: trac at galois.com (GHC) Date: Thu Oct 8 08:39:15 2009 Subject: [GHC] #3566: Install fails on Windows In-Reply-To: <046.53c3e977cd2a3f2d06ab45a50a92a739@localhost> References: <046.53c3e977cd2a3f2d06ab45a50a92a739@localhost> Message-ID: <055.929526f2ba65d34564d1ca8817183c06@localhost> #3566: Install fails on Windows ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by igloo): Is this building in msys or cygwin? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 8 09:04:34 2009 From: trac at galois.com (GHC) Date: Thu Oct 8 08:42:04 2009 Subject: [GHC] #3566: Install fails on Windows In-Reply-To: <046.53c3e977cd2a3f2d06ab45a50a92a739@localhost> References: <046.53c3e977cd2a3f2d06ab45a50a92a739@localhost> Message-ID: <055.1f2aa9b8cfe7288b86c34aa2316a2392@localhost> #3566: Install fails on Windows ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonpj): Msys. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 8 09:42:27 2009 From: trac at galois.com (GHC) Date: Thu Oct 8 09:19:59 2009 Subject: [GHC] #1185: can't do I/O in the child of forkProcess with -threaded In-Reply-To: <047.505ed9940eff9ef82094c96c7212dfa3@localhost> References: <047.505ed9940eff9ef82094c96c7212dfa3@localhost> Message-ID: <056.c3fa4d70c51960a9f21f254d65a0909c@localhost> #1185: can't do I/O in the child of forkProcess with -threaded ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Runtime System | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by bsdemon): What is the status of this issue? I see it marked as new, but will it be fixed for 6.12 or later? I am interested in daemonizing threaded programs. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 8 09:59:31 2009 From: trac at galois.com (GHC) Date: Thu Oct 8 09:37:12 2009 Subject: [GHC] #3231: Permission denied error with runProcess/openFile In-Reply-To: <051.9654be8110cd7a09257c98a211221fb3@localhost> References: <051.9654be8110cd7a09257c98a211221fb3@localhost> Message-ID: <060.8541f80b99338fb6cf75060f553ae70f@localhost> #3231: Permission denied error with runProcess/openFile ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Runtime System | Version: 6.10.4 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by yugr): Thanks, Simon. Now goes the tricky part. Below you will find the text of {{{a.exe}}}. It is a simple WinAPI program which starts a few processes, sleeps a bit, terminates them and exits. With this program I receive the errors which I mentioned above: {{{bug.exe: mytempfile.txt: openFile: permission denied (Permission denied)}}} or if I remove if-then-else {{{bug.exe: DeleteFile}}} Here is my idea of what is happening. As you may know {{{TerminateProcess}}} does not necesseraly terminate the process immediatelly (or even terminate it at all). This is especially common if process holds some system resource (pipe handle in this case). So when main process exits some children may still be alive and keep handles for stdout and stderr open for writing (for a few milliseconds). This causes errors when I try to read file in Haskell (via {{{B.readFile}}}) or even if I try to remove it (via {{{removeFile}}}). Now the question - should this problem (error when trying to read stdout/stderr of multiprocess program) be considered a feature or a bug? If it is a feature - can I handle it from inside Haskell (e.g. imagine that I do not have access to source of {{{a.exe}}})? Here is the program text. Error occurs both when compiled with Cygwin's gcc (just {{{gcc tmp.c}}}) and with Visual Studio's {{{cl}}}. If someone needs a Makefile or M$VS project - let me know and I will send you one. {{{ #include #include #include #include #define PIPE_NAME "\\\\.\\pipe\\MySmallPipe" #define PIPE_BUF_SIZE 10 #define TIMEOUT 1000 #define NCLIENTS 30 int main(int argc, char *argv[]) { if( 1 == argc ) { //Caller struct { HANDLE hProcess; HANDLE hPipe; OVERLAPPED ov; } data[NCLIENTS]; //Start clients int i; for(i = 0; i < NCLIENTS; ++i) { fprintf(stderr, "Starting %d\n", i); data[i].hPipe = CreateNamedPipe( PIPE_NAME, PIPE_ACCESS_DUPLEX | FILE_FLAG_OVERLAPPED, PIPE_TYPE_BYTE | PIPE_READMODE_BYTE | PIPE_WAIT, 100, PIPE_BUF_SIZE, PIPE_BUF_SIZE, TIMEOUT, 0 ); assert(INVALID_HANDLE_VALUE != data[i].hPipe); STARTUPINFO si; memset(&si, 0, sizeof (STARTUPINFO)); si.cb = sizeof(STARTUPINFO); PROCESS_INFORMATION pi; BOOL res = CreateProcess(0, strdup("a.exe 1"), 0, 0, TRUE, 0, 0, 0, &si, &pi); assert(res); data[i].hProcess = pi.hProcess; ConnectNamedPipe(data[i].hPipe, &data[i].ov); } //i fprintf(stderr, "Delay\n"); Sleep(TIMEOUT); //Kill clients for(i = 0; i < NCLIENTS; ++i) { fprintf(stderr, "Terminating %d\n", i); BOOL res = TerminateProcess(data[i].hProcess, 0); DisconnectNamedPipe(data[i].hPipe); CloseHandle(data[i].hPipe); } //i } else { //Callee fprintf(stderr, "Started\n"); BOOL res = WaitNamedPipe(PIPE_NAME, TIMEOUT); assert(res); HANDLE hPipe = CreateFile( PIPE_NAME, GENERIC_READ | GENERIC_WRITE, 0, 0, OPEN_EXISTING, 0, 0 ); //Sleep forever char buf[PIPE_BUF_SIZE]; DWORD n; res = ReadFile( hPipe, buf, PIPE_BUF_SIZE, &n, 0 ); } return 0; } }}} Best regards, Yuri -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 8 11:54:50 2009 From: trac at galois.com (GHC) Date: Thu Oct 8 11:32:23 2009 Subject: [GHC] #3561: Incorrect code generation on x86 In-Reply-To: <046.830b8d22811c2db4fef4cbd450983c13@localhost> References: <046.830b8d22811c2db4fef4cbd450983c13@localhost> Message-ID: <055.3445a9403470802a1639a97971448d85@localhost> #3561: Incorrect code generation on x86 -------------------------+-------------------------------------------------- Reporter: aleksey | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.10.4 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86 | -------------------------+-------------------------------------------------- Comment (by dmp): I can also reproduce this with 6.10.4 but not 6.12.0.20091007 on mac os x 10.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 8 12:07:50 2009 From: trac at galois.com (GHC) Date: Thu Oct 8 11:45:26 2009 Subject: [GHC] #1185: can't do I/O in the child of forkProcess with -threaded In-Reply-To: <047.505ed9940eff9ef82094c96c7212dfa3@localhost> References: <047.505ed9940eff9ef82094c96c7212dfa3@localhost> Message-ID: <056.034e65de50b4d85bf9df470108e424c5@localhost> #1185: can't do I/O in the child of forkProcess with -threaded ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Runtime System | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by bsdemon): * cc: 8mayday@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 8 14:45:44 2009 From: trac at galois.com (GHC) Date: Thu Oct 8 14:23:16 2009 Subject: [GHC] #3568: Command line flag "exclude-module" not recognized Message-ID: <047.e9cec7601a3bdc25f2dadaabece68727@localhost> #3568: Command line flag "exclude-module" not recognized -----------------------------+---------------------------------------------- Reporter: heatsink | Owner: Type: bug | Status: new Priority: normal | Component: Driver Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- The exclude-module flag used with {{{ghc -M}}} does not work as advertised. The deprecated syntax works correctly, but the new syntax is parsed incorrectly. {{{ module Foo where import Bar -- Bar.hs does not exist -- On the command line: $ ghc -M Foo.hs Foo.hs:4:7: Could not find module `Bar': Use -v to see a list of the files searched for. $ ghc -M Foo.hs -optdep --exclude-module=Bar on the commandline: Warning: -optdep--exclude-module=Bar is deprecated: Use -exclude- module instead $ ghc -M Foo.hs -exclude-module=Bar ghc: cannot use `-M' with `-e' }}} The command line parsing was apparently changed to resolve #1248. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 8 17:01:43 2009 From: trac at galois.com (GHC) Date: Thu Oct 8 16:40:21 2009 Subject: [GHC] #2965: GHC on OS X does not compile 64-bit In-Reply-To: <045.2214e7d1fe4dd43486128c197fdb9227@localhost> References: <045.2214e7d1fe4dd43486128c197fdb9227@localhost> Message-ID: <054.6e3ec40e92fb632eafdd58748b1e24a0@localhost> #2965: GHC on OS X does not compile 64-bit --------------------------------+------------------------------------------- Reporter: Axman6 | Owner: thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: Severity: normal | Resolution: Keywords: 64bit | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86_64 (amd64) | --------------------------------+------------------------------------------- Changes (by barney_stratford): * cc: barney_stratford@fastmail.fm (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 8 17:51:03 2009 From: trac at galois.com (GHC) Date: Thu Oct 8 17:29:19 2009 Subject: [GHC] #2965: GHC on OS X does not compile 64-bit In-Reply-To: <045.2214e7d1fe4dd43486128c197fdb9227@localhost> References: <045.2214e7d1fe4dd43486128c197fdb9227@localhost> Message-ID: <054.7c18d6c929818b5fcd1a0a3e10aeb123@localhost> #2965: GHC on OS X does not compile 64-bit --------------------------------+------------------------------------------- Reporter: Axman6 | Owner: thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: Severity: normal | Resolution: Keywords: 64bit | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86_64 (amd64) | --------------------------------+------------------------------------------- Changes (by pweaver): * cc: philip.weaver@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 8 21:35:13 2009 From: trac at galois.com (GHC) Date: Thu Oct 8 21:14:05 2009 Subject: [GHC] #2965: GHC on OS X does not compile 64-bit In-Reply-To: <045.2214e7d1fe4dd43486128c197fdb9227@localhost> References: <045.2214e7d1fe4dd43486128c197fdb9227@localhost> Message-ID: <054.17eefd41a8d5a34a252745b0e16369ab@localhost> #2965: GHC on OS X does not compile 64-bit --------------------------------+------------------------------------------- Reporter: Axman6 | Owner: thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: Severity: normal | Resolution: Keywords: 64bit | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86_64 (amd64) | --------------------------------+------------------------------------------- Changes (by guest): * cc: wmealing@gmail.com (removed) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 9 02:49:56 2009 From: trac at galois.com (GHC) Date: Fri Oct 9 02:27:27 2009 Subject: [GHC] #3569: ghci can't handle utf-8 chinese char correctly when modify. Message-ID: <044.9c568ba4db1530f0bbd9af30f9b67dee@localhost> #3569: ghci can't handle utf-8 chinese char correctly when modify. -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: x86_64 (amd64) -----------------------------+---------------------------------------------- ubuntu 8.04, ghc 6.10.4,gnome-terminal if you can't display chinese char and under ubuntu, may be you can use ubuntu's language support. ======================================================= Using chinese string inside ghci such as: Prelude> "??????????" when use backspace, left arrow or any other action cause the cursor relocate.Will find out that the cursor can't relocate correctly, i.e. i use backspace to delete the whole string, ghci still display thing like below: Prelude> "????? if now use to execute, resault just "Prelude>" After several test i find out that, ghci "display part" treat every chinese char as two chars/bytes(or maybe longer), but ghci "inside" treat chinese char as one unicode char correctly. Chinese can encode 2 to 4 bytes long, under Linux 2 to 4 bytes under diffrent locale setting, under Windows 2 bytes long. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 9 05:03:02 2009 From: trac at galois.com (GHC) Date: Fri Oct 9 04:40:30 2009 Subject: [GHC] #3570: :~/base-4.0.0.0$ sudo runghc Setup.hs configure Message-ID: <044.a415e073f7bfe26fd5da575cd9569097@localhost> #3570: :~/base-4.0.0.0$ sudo runghc Setup.hs configure -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- :1:22: attempting to use module `System.IO' (System/IO.hs) which is not loaded :1:22: Not in scope: `System.IO.stderr' :1:22: Not in scope: `System.IO.stdin' ghc-6.8.2: panic! (the 'impossible' happened) (GHC version 6.8.2 for i386-unknown-linux): interactiveUI:setBuffering Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 9 06:59:31 2009 From: trac at galois.com (GHC) Date: Fri Oct 9 06:37:01 2009 Subject: [GHC] #1185: can't do I/O in the child of forkProcess with -threaded In-Reply-To: <047.505ed9940eff9ef82094c96c7212dfa3@localhost> References: <047.505ed9940eff9ef82094c96c7212dfa3@localhost> Message-ID: <056.dc7949d4d962c3b1303246d66b68e068@localhost> #1185: can't do I/O in the child of forkProcess with -threaded ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Runtime System | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): It's not likely to be fixed in 6.12.1, I'm afraid. If there's a lot of interest we can schedule it for 6.12.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 9 07:02:05 2009 From: trac at galois.com (GHC) Date: Fri Oct 9 06:39:33 2009 Subject: [GHC] #3570: :~/base-4.0.0.0$ sudo runghc Setup.hs configure In-Reply-To: <044.a415e073f7bfe26fd5da575cd9569097@localhost> References: <044.a415e073f7bfe26fd5da575cd9569097@localhost> Message-ID: <053.51bd559e3836e1812899f5908c1b99e8@localhost> #3570: :~/base-4.0.0.0$ sudo runghc Setup.hs configure ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: This one has been fixed in later releases, please upgrade GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 9 07:02:50 2009 From: trac at galois.com (GHC) Date: Fri Oct 9 06:40:20 2009 Subject: [GHC] #1185: can't do I/O in the child of forkProcess with -threaded In-Reply-To: <047.505ed9940eff9ef82094c96c7212dfa3@localhost> References: <047.505ed9940eff9ef82094c96c7212dfa3@localhost> Message-ID: <056.63091adc5f71ae3200201a8752d95603@localhost> #1185: can't do I/O in the child of forkProcess with -threaded ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Runtime System | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by bsdemon): For me, as mostly being network programmer, it is "must have" feature. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 9 10:40:53 2009 From: trac at galois.com (GHC) Date: Fri Oct 9 10:18:21 2009 Subject: [GHC] #3571: Bizzarely bloated binaries Message-ID: <044.a58781a47fed5e173c154c742b96ee46@localhost> #3571: Bizzarely bloated binaries -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Compiling a trivial test program: {{{ module Main where main = print "Hello World" }}} Using GHC 6.10.4 produces a VERY suspicious PE file. (NB: this applies to DLL as well as EXE output). The two problems that I have observed are: 1) The PE always contains a .stab and .stabstr section totalling 0x2A00 of debug data. Looking at the contents of stabstr, this appears to originate from a libffi object file. Perhaps we could disable stabs when building libffi to remove this bloat from output binaries. 2) The PE contains *A LOT* of trailing junk. My hello world program is 691K, and the PE contains 0x4FAFC = 318K of data which doesn't live in any section! Trimming this data appears to have no effect on the correctness of the program! The amount of junk grows proportionally to the amount of real code and data - I have observed e.g. 18Mb DLLs of which 9Mb are trailing junk. To repeat: we could potentially *halve* GHC binary sizes by fixing this linker behaviour. I'm not sure where exactly the fault lies - whether it is a GHC problem or some bug in Ld. To test trimming your executables and DLLs, you can use this utility I whipped up. Usage is "trimpe ... ". It will trim useless data from the end of the files in place: {{{ {-# LANGUAGE ScopedTypeVariables #-} module Main (main) where import Control.Monad import Data.Binary import Data.Binary.Get import qualified Data.ByteString.Lazy as ByteString import Data.Word import System.Environment import Debug.Trace assertM :: Monad m => Bool -> m () assertM True = return () assertM False = fail "assertM" newtype PEImageLength = PEImageLength Word32 -- http://www.microsoft.com/whdc/system/platform/firmware/PECOFF.mspx instance Binary PEImageLength where get = do -- Skip the MS DOS stub skip 0x3c pe_sig_offset <- getWord32le -- Skip to the PE signature skip (fromIntegral pe_sig_offset - (0x4 + 0x3c)) -- Read the PE signature itself -- NB: this will always be the string "PE\0\0" _sig <- getWord32le assertM (_sig == 0x00004550) -- Read COFF file header _machine <- getWord16le _no_of_sects <- getWord16le _time_date_stamp <- getWord32le _ptr_to_sym_tab <- getWord32le _no_of_syms <- getWord32le _size_of_opt_header <- getWord16le assertM (_size_of_opt_header /= 0) _characteristics <- getWord16le -- Read the "optional" header magic <- getWord16le let pe32plus = magic == 0x20B _maj_link_ver :: Word8 <- get _min_link_ver :: Word8 <- get _size_of_code <- getWord32le _size_of_init_data <- getWord32le _size_of_uninit_data <- getWord32le _addr_of_entry_point <- getWord32le _base_of_code <- getWord32le when (not pe32plus) $ do _base_of_data <- getWord32le; return () -- Read the optional header Windows fields if pe32plus then do _image_base <- getWord64le; return () else do _image_base <- getWord32le; return () _sect_alignment <- getWord32le _file_alignment <- getWord32le _maj_os_version <- getWord16le _min_os_version <- getWord16le _maj_image_version <- getWord16le _min_image_version <- getWord16le _maj_subsys_version <- getWord16le _min_subsys_version <- getWord16le _win32_version <- getWord32le size_of_image <- getWord32le -- There is more stuff later, but I simply don't care about it -- NB: we could trim a little more agressively if we interpreted -- the sections as well... return $ PEImageLength size_of_image put = error "Binary PEImageLength: put" main :: IO () main = do files <- getArgs forM_ files trimPEToImageSize trimPEToImageSize :: FilePath -> IO () trimPEToImageSize file = do putStrLn $ file pe_contents <- ByteString.readFile file let PEImageLength image_size = decode pe_contents -- Force the file to close so that the write may succeed (ByteString.last pe_contents) `seq` return () when (ByteString.length pe_contents > fromIntegral image_size) $ do putStrLn $ "* Trimming to image size (" ++ show image_size ++ ")" let pe_contents' = ByteString.take (fromIntegral image_size) pe_contents ByteString.writeFile file pe_contents' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 9 11:44:24 2009 From: trac at galois.com (GHC) Date: Fri Oct 9 11:21:53 2009 Subject: [GHC] #3569: ghci can't handle utf-8 chinese char correctly when modify. In-Reply-To: <044.9c568ba4db1530f0bbd9af30f9b67dee@localhost> References: <044.9c568ba4db1530f0bbd9af30f9b67dee@localhost> Message-ID: <053.01fd2006590f5e10f9eb98c055069fc5@localhost> #3569: ghci can't handle utf-8 chinese char correctly when modify. ------------------------------+--------------------------------------------- Reporter: guest | Owner: judah Type: bug | Status: assigned Priority: normal | Milestone: Component: GHCi | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: x86_64 (amd64) ------------------------------+--------------------------------------------- Changes (by judah): * status: new => assigned * owner: => judah Comment: Thanks for the report! This is an issue which needs to be fixed in Haskeline: http://trac.haskell.org/haskeline/ticket/81 I'll update this ticket with progress from that one. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 9 11:53:52 2009 From: trac at galois.com (GHC) Date: Fri Oct 9 11:31:20 2009 Subject: [GHC] #3571: Bizzarely bloated binaries In-Reply-To: <044.a58781a47fed5e173c154c742b96ee46@localhost> References: <044.a58781a47fed5e173c154c742b96ee46@localhost> Message-ID: <053.b62b666f2ba9d354dda2b74a8482c38d@localhost> #3571: Bizzarely bloated binaries ------------------------------+--------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by guest): I'm finding it very hard to believe that this data really is useless. It remains in the object file whether I used ld 2.17.50, 2.18.50 or 2.19.1 to do the final link. However, running "strip" on the executable has a similar effect and indeed ensures that the PE image size is not exceeded by the file length. The actual binary contents of the EXE's useless rump is strange. It is a mixture of z-encoded symbols, section names (.rodata, .bss, .data, .txt), and purely binary data. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 9 18:47:14 2009 From: trac at galois.com (GHC) Date: Fri Oct 9 18:24:41 2009 Subject: [GHC] #3571: Bizzarely bloated binaries In-Reply-To: <044.a58781a47fed5e173c154c742b96ee46@localhost> References: <044.a58781a47fed5e173c154c742b96ee46@localhost> Message-ID: <053.19cdf46b90264dac022ed47c8047042c@localhost> #3571: Bizzarely bloated binaries ------------------------------+--------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by guest): I'm also confirming that using strip is the normal thing to do, I've done this for years, usually followed by a upx which further reduces the size to about 120KB. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 10 03:29:12 2009 From: trac at galois.com (GHC) Date: Sat Oct 10 03:06:49 2009 Subject: [GHC] #3231: Permission denied error with runProcess/openFile In-Reply-To: <051.9654be8110cd7a09257c98a211221fb3@localhost> References: <051.9654be8110cd7a09257c98a211221fb3@localhost> Message-ID: <060.d6ecf440464420acc75662292cfa1015@localhost> #3231: Permission denied error with runProcess/openFile ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: simonmar Type: bug | Status: reopened Priority: normal | Milestone: 6.12.1 Component: Runtime System | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by yugr): * status: closed => reopened * resolution: invalid => Comment: Report as bug until proven otherwise. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 10 13:36:58 2009 From: trac at galois.com (GHC) Date: Sat Oct 10 13:14:26 2009 Subject: [GHC] #3572: Empty types are prettyprinted with trailing "=" Message-ID: <045.a913ce8d59080e93f1d9fb9091a05960@localhost> #3572: Empty types are prettyprinted with trailing "=" -------------------+-------------------------------------------------------- Reporter: FSalad | Owner: Type: bug | Status: new Priority: normal | Component: Template Haskell Version: 6.10.4 | Severity: trivial Keywords: | Testcase: Os: Linux | Architecture: Unknown/Multiple -------------------+-------------------------------------------------------- This prints the invalid declaration "data Void ="; should be "data Void": {{{ {-# LANGUAGE EmptyDataDecls #-} import Language.Haskell.TH import Language.Haskell.TH.Ppr main = putStrLn . pprint =<< runQ [d| data Void |] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 10 14:54:45 2009 From: trac at galois.com (GHC) Date: Sat Oct 10 14:32:09 2009 Subject: [GHC] #3567: Configure script looks for ld too early In-Reply-To: <046.01ebc2924afd98045f37408ffa49da8f@localhost> References: <046.01ebc2924afd98045f37408ffa49da8f@localhost> Message-ID: <055.4456058f22a645532a5b522d5cfb55d4@localhost> #3567: Configure script looks for ld too early ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: This is now fixed in HEAD and 6.12. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 10 15:52:29 2009 From: trac at galois.com (GHC) Date: Sat Oct 10 15:29:54 2009 Subject: [GHC] #3565: Wrong gcc being used In-Reply-To: <046.1a75409f814cd8c2531fe45e1f2aa63b@localhost> References: <046.1a75409f814cd8c2531fe45e1f2aa63b@localhost> Message-ID: <055.f102a6e4f252598a7e2019aedd4924c6@localhost> #3565: Wrong gcc being used ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * priority: normal => high -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 10 23:21:13 2009 From: trac at galois.com (GHC) Date: Sat Oct 10 22:58:37 2009 Subject: [GHC] #1185: can't do I/O in the child of forkProcess with -threaded In-Reply-To: <047.505ed9940eff9ef82094c96c7212dfa3@localhost> References: <047.505ed9940eff9ef82094c96c7212dfa3@localhost> Message-ID: <056.9fd5b5b55de273474e859c72fb7018fd@localhost> #1185: can't do I/O in the child of forkProcess with -threaded ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Runtime System | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by kazu-yamamoto): This is a MUST. Without forkProcess which does not kill the IO thread, we cannot create even a simple deamon nor Apache's prefok model, etc... -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 11 07:54:01 2009 From: trac at galois.com (GHC) Date: Sun Oct 11 07:31:47 2009 Subject: [GHC] #635: Replace use of select() in the I/O manager with epoll/kqueue/etc. In-Reply-To: <047.158ac52b7977b3e9f47680935a918275@localhost> References: <047.158ac52b7977b3e9f47680935a918275@localhost> Message-ID: <056.34a36150816cb99eba832fc22de30e6d@localhost> #635: Replace use of select() in the I/O manager with epoll/kqueue/etc. ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: _|_ Component: libraries/base | Version: 6.4.1 Severity: normal | Resolution: Keywords: | Difficulty: Difficult (1 week) Testcase: N/A | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by bsdemon): * cc: 8mayday@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 11 18:50:07 2009 From: trac at galois.com (GHC) Date: Sun Oct 11 18:27:30 2009 Subject: [GHC] #3573: ghc-6.12 source tarball README still mentions extralibs Message-ID: <047.0687d1b6afa74888700ec2815f556c69@localhost> #3573: ghc-6.12 source tarball README still mentions extralibs -----------------------------+---------------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Component: Documentation Version: | Severity: minor Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- The README in the source tarball http://darcs.haskell.org/~ghc/dist/6.12.1rc1/ghc-6.12.0.20091010-src.tar.bz2 is unchanged since ghc-6.10.1. In particular it describes an extralibs source tarball, which as far as I know no longer exists in ghc-6.12. This section should be removed, and possibly replaced by a description of how to obtain more libraries beyond "using Cabal". -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 11 22:47:24 2009 From: trac at galois.com (GHC) Date: Sun Oct 11 22:24:44 2009 Subject: [GHC] #3574: The install-docs target no longer works in 6.12 Message-ID: <042.6969e8944815003a61072e556f07b172@localhost> #3574: The install-docs target no longer works in 6.12 -----------------------------+---------------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.11 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- In the README file of GHC 6.12.1 RC 1, the method listed for installing docs, "make install-docs", seems to no longer be necessary. This cost me a little confusion. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 12 00:45:05 2009 From: trac at galois.com (GHC) Date: Mon Oct 12 00:22:25 2009 Subject: [GHC] #3575: mkStdGen and split conspire to make some programs predictable Message-ID: <047.6485fb2275f266e278f6578e798e2d4e@localhost> #3575: mkStdGen and split conspire to make some programs predictable -----------------------------+---------------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Component: libraries/random Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- The following program `random.hs` is intended to produce a line containing 30 random 0s or 1s. It is not an example of the best way to use System.Random, but it looks innocuous enough. {{{ import Control.Monad import System.Random print0or1 = do g <- newStdGen putStr . show . fst $ randomR (0, 1 :: Int) g main = replicateM_ 30 print0or1 >> putStrLn "" }}} Let's try running it a thousand times: {{{ rwbarton@functor:/tmp$ ghc-6.10.1 -O2 --make random [1 of 1] Compiling Main ( random.hs, random.o ) Linking random ... rwbarton@functor:/tmp$ for i in `seq 1 1000` ; do ./random >> random.out ; done rwbarton@functor:/tmp$ sort random.out | uniq | wc -l 60 }}} That's odd... there are 2^30^ possible output lines, but when I tried to generate 1000 random ones, I only got 60 distinct outputs. Why did that happen? One might think this is due to poor initial seeding of the random number generator (due to the time not changing very much during the test), but this is not the case. Attached is a fancier version of the program which reads an initial seed from `/dev/urandom`; it exhibits the same behavior. This phenomenon is not too hard to explain. It is ultimately due to a poor interaction between `mkStdGen` and `split`. First, we need to know a bit about the design of System.Random (some statements simplified slightly for this discussion). * The state of the RNG consists of two `Int32`s, `s1` and `s2`. * The initial state produced by mkStdGen almost always has `s2` equal to 1. (Extremely rarely, it might have `s2` equal to 2. We'll ignore this as it doesn't affect the argument.) * To generate a random 0 or 1, we first generate a new state using some simple functions `s1' = next1(s1)`, `s2' = next2(s2)`. (Note that `s1` and `s2` "evolve" independently.) The random value returned is the lowest bit of `s1'` minus `s2'`. * Splitting the generator `(s1, s2)` yields the two generators `(s1+1, next2(s2))` and `(next1(s1), s2-1)`. Our program functions as follows. * Initialize the generator stored in `theStdGen` (`s1` is some varying value `a`, `s2` is 1). * Repeatedly split the generator, replacing it with the first output, and use the second output to generate a 0 or 1. If we watch `theStdGen` while our program runs, we will see that `s1` is incremented by 1 at each step, while `s2` follows the fixed sequence `1`, `next2(1)`, `next2(next2(1))`, etc. The 0 or 1 we output at the `k`th step is thus the lowest bit of `next1(next1(a+k-1))` minus `b`,,k,,, where `b`,,k,, is some fixed sequence. And as `k` varies, `next1(next1(a+k-1))` turns out to be just an arithmetic sequence with fixed difference modulo a fixed prime so its lowest bits are extremely predictable even without knowing `a`. This issue can be fixed to some extent, without breaking backwards compatibility, by adding another method (besides `mkStdGen`) to create a generator, which does not have predictable `s2`, and using it to initialize the system RNG. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 12 00:55:55 2009 From: trac at galois.com (GHC) Date: Mon Oct 12 00:33:14 2009 Subject: [GHC] #3575: mkStdGen and split conspire to make some programs predictable In-Reply-To: <047.6485fb2275f266e278f6578e798e2d4e@localhost> References: <047.6485fb2275f266e278f6578e798e2d4e@localhost> Message-ID: <056.4ac65c7e8b1a7e4ff39f63a2e02643ef@localhost> #3575: mkStdGen and split conspire to make some programs predictable ------------------------------+--------------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/random | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by rwbarton): Thanks to Michael Rice for suggesting that there may be a problem: http://www.haskell.org/pipermail/haskell-cafe/2009-October/067655.html -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 12 01:05:14 2009 From: trac at galois.com (GHC) Date: Mon Oct 12 00:42:33 2009 Subject: [GHC] #3575: mkStdGen and split conspire to make some programs predictable In-Reply-To: <047.6485fb2275f266e278f6578e798e2d4e@localhost> References: <047.6485fb2275f266e278f6578e798e2d4e@localhost> Message-ID: <056.5ef2a95116c498a43c8af42e7b1d433b@localhost> #3575: mkStdGen and split conspire to make some programs predictable ------------------------------+--------------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/random | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by guest): * cc: kfrdbs@gmail.com (added) Comment: Thread in one long page [http://www.nabble.com/Simple-program.-Simple- problem--td25848131.html here] -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 12 02:10:06 2009 From: trac at galois.com (GHC) Date: Mon Oct 12 01:47:25 2009 Subject: [GHC] #3576: minor errors in docs/users_guide/6.12.1-notes.xml Message-ID: <047.a378ff8311d09257eac4556aec15ebbf@localhost> #3576: minor errors in docs/users_guide/6.12.1-notes.xml -----------------------------+---------------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Component: Documentation Version: 6.11 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- * `listitem` is misspelled a total of 4 times as `listierm` (two open tags, two close tags). * The `-fwarn-unused-do-bind` flag is documented in two items. Probably the second item should be removed. It would be nice to include a link to the relevant part of Section 4.7 in the first item. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 12 02:30:01 2009 From: trac at galois.com (GHC) Date: Mon Oct 12 02:07:22 2009 Subject: [GHC] #3263: Warnings for monadic values not used In-Reply-To: <051.2ba77802c306560898b377ae21be4ade@localhost> References: <051.2ba77802c306560898b377ae21be4ade@localhost> Message-ID: <060.44d18d9490d535d571a435e3a327a1a0@localhost> #3263: Warnings for monadic values not used ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: igloo Type: feature request | Status: closed Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by rwbarton): Testing this in 6.12.1 RC 1--when I `:load` an offending file in ghci I get a warning like this: {{{ Warning: A do-notation statement discarded a result of type IO Bool. Suppress this warning by saying "_ <- tick<1>(return (tick<0>(doesFileExist "foo")))", or by using the flag -fno-warn-wrong-do-bind }}} There's no `tick` stuff when I compile with ghc. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 12 05:14:07 2009 From: trac at galois.com (GHC) Date: Mon Oct 12 04:51:33 2009 Subject: [GHC] #3544: Add instance IsString ShowS where fromString = showString In-Reply-To: <049.9e51a8e67140bc1cfbcf407623a0d367@localhost> References: <049.9e51a8e67140bc1cfbcf407623a0d367@localhost> Message-ID: <058.de26ff6624675b0ebe0ffc18c2291033@localhost> #3544: Add instance IsString ShowS where fromString = showString ------------------------------+--------------------------------------------- Reporter: basvandijk | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 6.10.4 Severity: normal | Resolution: wontfix Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by basvandijk): * status: new => closed * resolution: => wontfix -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 12 06:27:34 2009 From: trac at galois.com (GHC) Date: Mon Oct 12 06:04:53 2009 Subject: [GHC] #3577: Complete support for Data Parallel Haskell Message-ID: <041.e54cf544394515fd2960400b723e2495@localhost> #3577: Complete support for Data Parallel Haskell -----------------------------+---------------------------------------------- Reporter: rl | Owner: rl Type: feature request | Status: new Priority: normal | Component: Data Parallel Haskell Version: 6.13 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- I'm going to open this as a placeholder for all the things the vectoriser can't do yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 12 06:29:42 2009 From: trac at galois.com (GHC) Date: Mon Oct 12 06:07:05 2009 Subject: [GHC] #3555: Vectorisation error with negative Double const In-Reply-To: <042.76488390a8c998c2738bb2a24f69b062@localhost> References: <042.76488390a8c998c2738bb2a24f69b062@localhost> Message-ID: <051.41be25cd07d79cfdb1aae42945ba7126@localhost> #3555: Vectorisation error with negative Double const -----------------------------------+---------------------------------------- Reporter: ams | Owner: rl Type: feature request | Status: closed Priority: normal | Milestone: Component: Data Parallel Haskell | Version: 6.13 Severity: normal | Resolution: duplicate Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------------+---------------------------------------- Changes (by rl): * status: new => closed * type: bug => feature request * resolution: => duplicate Comment: I've opened #3577 as a placeholder for issues related to incomplete DPH support. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 12 06:32:58 2009 From: trac at galois.com (GHC) Date: Mon Oct 12 06:10:17 2009 Subject: [GHC] #2984: Vectorized dph code doesn't terminate In-Reply-To: <042.776c42012cc46c4d8dc7e12433e5e6d8@localhost> References: <042.776c42012cc46c4d8dc7e12433e5e6d8@localhost> Message-ID: <051.94fb2dadaa8700a36307cab631f9815a@localhost> #2984: Vectorized dph code doesn't terminate --------------------------------------+------------------------------------- Reporter: fre | Owner: rl Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Data Parallel Haskell | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | --------------------------------------+------------------------------------- Changes (by rl): * owner: => rl * os: Linux => Unknown/Multiple * architecture: x86 => Unknown/Multiple Comment: I am making several changes to DPH at the moment. I'll revisit this once I'm done. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 12 07:08:57 2009 From: trac at galois.com (GHC) Date: Mon Oct 12 06:46:18 2009 Subject: [GHC] #3576: minor errors in docs/users_guide/6.12.1-notes.xml In-Reply-To: <047.a378ff8311d09257eac4556aec15ebbf@localhost> References: <047.a378ff8311d09257eac4556aec15ebbf@localhost> Message-ID: <056.ec141d947bf14b6f177d9015e7175239@localhost> #3576: minor errors in docs/users_guide/6.12.1-notes.xml ---------------------------------+------------------------------------------ Reporter: rwbarton | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Documentation | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * priority: normal => high * difficulty: => Unknown * owner: => simonmar * milestone: => 6.12.1 Comment: validating.. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 12 08:36:13 2009 From: trac at galois.com (GHC) Date: Mon Oct 12 08:13:33 2009 Subject: [GHC] #3573: ghc-6.12 source tarball README still mentions extralibs In-Reply-To: <047.0687d1b6afa74888700ec2815f556c69@localhost> References: <047.0687d1b6afa74888700ec2815f556c69@localhost> Message-ID: <056.f009a58bdace0f908f996259381395da@localhost> #3573: ghc-6.12 source tarball README still mentions extralibs ---------------------------------+------------------------------------------ Reporter: rwbarton | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: Thanks for the report; I've updated the README. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 12 08:36:42 2009 From: trac at galois.com (GHC) Date: Mon Oct 12 08:14:01 2009 Subject: [GHC] #3574: The install-docs target no longer works in 6.12 In-Reply-To: <042.6969e8944815003a61072e556f07b172@localhost> References: <042.6969e8944815003a61072e556f07b172@localhost> Message-ID: <051.2cca87e537e25d3bf1117907a211cbf4@localhost> #3574: The install-docs target no longer works in 6.12 ---------------------------------+------------------------------------------ Reporter: bos | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: Thanks for the report; I've removed that section of the README. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 12 09:01:47 2009 From: trac at galois.com (GHC) Date: Mon Oct 12 08:39:16 2009 Subject: [GHC] #3568: Command line flag "exclude-module" not recognized In-Reply-To: <047.e9cec7601a3bdc25f2dadaabece68727@localhost> References: <047.e9cec7601a3bdc25f2dadaabece68727@localhost> Message-ID: <056.f77c806c727030a14f2874ad91e43965@localhost> #3568: Command line flag "exclude-module" not recognized ---------------------------------+------------------------------------------ Reporter: heatsink | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * owner: => igloo * difficulty: => Unknown Comment: Thanks for the report. I'll take a look. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 12 09:19:38 2009 From: trac at galois.com (GHC) Date: Mon Oct 12 08:56:58 2009 Subject: [GHC] #3578: internal error: evacuate(static): strange closure type 42 Message-ID: <043.5afd3bca71e73869953acaf1347724a9@localhost> #3578: internal error: evacuate(static): strange closure type 42 -------------------+-------------------------------------------------------- Reporter: nccb | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 6.13 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86 -------------------+-------------------------------------------------------- I have a concurrent program (using CHP, which sits on top of STM+forkIO), that is able to produce this error on GHC 6.12.1-rc1 (which doesn't appear on your version drop-down): chp-boids: internal error: evacuate(static): strange closure type 42 (GHC version 6.12.0.20091010 for i386_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted It produces it much sooner with +RTS -N2 than +RTS -N1, but both settings can produce the error. The output doesn't look like it will be very useful to you -- what can I run to give a better output? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 12 09:41:14 2009 From: trac at galois.com (GHC) Date: Mon Oct 12 09:19:03 2009 Subject: [GHC] #1185: can't do I/O in the child of forkProcess with -threaded In-Reply-To: <047.505ed9940eff9ef82094c96c7212dfa3@localhost> References: <047.505ed9940eff9ef82094c96c7212dfa3@localhost> Message-ID: <056.7fe7739f4215abed5a85dfae9be044f0@localhost> #1185: can't do I/O in the child of forkProcess with -threaded ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Runtime System | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by bsdemon): Maybe a stupid question, but... After reading sources, it seems that '''GHC.Conc.ensureIOManagerIsRunning''' is exported from module. Why we cannot use it for starting I/O Manager after '''forkProcess'''? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 12 11:16:22 2009 From: trac at galois.com (GHC) Date: Mon Oct 12 10:53:45 2009 Subject: [GHC] #1185: can't do I/O in the child of forkProcess with -threaded In-Reply-To: <047.505ed9940eff9ef82094c96c7212dfa3@localhost> References: <047.505ed9940eff9ef82094c96c7212dfa3@localhost> Message-ID: <056.e717d23b2969cf64763b8f4f928fa9f6@localhost> #1185: can't do I/O in the child of forkProcess with -threaded ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Runtime System | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * difficulty: Easy (1 hr) => Moderate (1 day) Comment: Replying to [comment:20 bsdemon]: > Maybe a stupid question, but... > > After reading sources, it seems that '''GHC.Conc.ensureIOManagerIsRunning''' is exported from module. Why we cannot use it for starting I/O Manager after '''forkProcess'''? Unfortunately it's not that simple. The IO manager is started by an `unsafePerformIO` in the definition of `pendingEvents`, and `ensureIOManagerIsRunning` just seqs the thunk, so it won't do anything to call it after forking. I think we probably have to keep track of the IO manager thread explicitly in the RTS. -- Ticket URL: GHC The Glasgow Haskell Compiler From mechvel at botik.ru Mon Oct 12 13:31:41 2009 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Mon Oct 12 13:18:55 2009 Subject: bug in 6.12.1-pre Message-ID: <20091012173141.GA30001@scico.botik.ru> Dear GHC team, I tried ghc-6.12.0.20091010-src.tar.bz2 on Linux, Debian, i386-* And it cannot compile my Dumatel project. It fails at the segment: module Bug where compose :: [a -> a] -> a -> a compose = foldr (.) id class Compose a where compose1 :: a -> a -> a ghc -c -O Bug.hs reports /tmp/ghc29984_0/ghc29984_0.s: Assembler messages: /tmp/ghc29984_0/ghc29984_0.s:23:0: Error: symbol `Bug_compose1_closure' is already defined /tmp/ghc29984_0/ghc29984_0.s:102:0: Error: symbol `Bug_compose1_info' is already defined `-O' is essential here. Regards, ----------------- Serge Mechveliani mechvel@botik.ru From trac at galois.com Mon Oct 12 14:27:28 2009 From: trac at galois.com (GHC) Date: Mon Oct 12 14:04:50 2009 Subject: [GHC] #3579: Error: symbol `Bug_compose1_closure' is already defined Message-ID: <044.8d0cee2189cb326f04528793a172ebca@localhost> #3579: Error: symbol `Bug_compose1_closure' is already defined -------------------------------+-------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.13 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- In http://www.haskell.org/pipermail/glasgow-haskell- bugs/2009-October/020608.html Serge reports: {{{ module Bug where compose :: [a -> a] -> a -> a compose = foldr (.) id class Compose a where compose1 :: a -> a -> a }}} {{{ $ ghc -c -O p.hs /tmp/ghc12944_0/ghc12944_0.s: Assembler messages: /tmp/ghc12944_0/ghc12944_0.s:22:0: Error: symbol `Bug_compose1_closure' is already defined /tmp/ghc12944_0/ghc12944_0.s:98:0: Error: symbol `Bug_compose1_info' is already defined }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From igloo at earth.li Mon Oct 12 14:28:52 2009 From: igloo at earth.li (Ian Lynagh) Date: Mon Oct 12 14:06:12 2009 Subject: bug in 6.12.1-pre In-Reply-To: <20091012173141.GA30001@scico.botik.ru> References: <20091012173141.GA30001@scico.botik.ru> Message-ID: <20091012182852.GA9095@matrix.chaos.earth.li> On Mon, Oct 12, 2009 at 09:31:41PM +0400, Serge D. Mechveliani wrote: > Dear GHC team, > > I tried ghc-6.12.0.20091010-src.tar.bz2 > on Linux, Debian, i386-* > And it cannot compile my Dumatel project. It fails at the segment: Great bug report, thanks. I've filed a ticket for it here: http://hackage.haskell.org/trac/ghc/ticket/3579 Thanks Ian From trac at galois.com Mon Oct 12 15:47:15 2009 From: trac at galois.com (GHC) Date: Mon Oct 12 15:24:34 2009 Subject: [GHC] #3576: minor errors in docs/users_guide/6.12.1-notes.xml In-Reply-To: <047.a378ff8311d09257eac4556aec15ebbf@localhost> References: <047.a378ff8311d09257eac4556aec15ebbf@localhost> Message-ID: <056.e7ba47ed403b233988a8c94e04f95dbc@localhost> #3576: minor errors in docs/users_guide/6.12.1-notes.xml ---------------------------------+------------------------------------------ Reporter: rwbarton | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 6.12.1 Component: Documentation | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 12 15:49:19 2009 From: trac at galois.com (GHC) Date: Mon Oct 12 15:26:40 2009 Subject: [GHC] #3568: Command line flag "exclude-module" not recognized In-Reply-To: <047.e9cec7601a3bdc25f2dadaabece68727@localhost> References: <047.e9cec7601a3bdc25f2dadaabece68727@localhost> Message-ID: <056.1db75d94d4a816f5582d3d3b94a42f9d@localhost> #3568: Command line flag "exclude-module" not recognized ---------------------------------+------------------------------------------ Reporter: heatsink | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: Component: Driver | Version: 6.10.4 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed in HEAD and 6.12. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 13 04:23:06 2009 From: trac at galois.com (GHC) Date: Tue Oct 13 04:00:24 2009 Subject: [GHC] #3579: Error: symbol `Bug_compose1_closure' is already defined In-Reply-To: <044.8d0cee2189cb326f04528793a172ebca@localhost> References: <044.8d0cee2189cb326f04528793a172ebca@localhost> Message-ID: <053.798b5700217bef6350ee3f1f1f1945d9@localhost> #3579: Error: symbol `Bug_compose1_closure' is already defined ---------------------------------+------------------------------------------ Reporter: igloo | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.13 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 13 04:34:39 2009 From: trac at galois.com (GHC) Date: Tue Oct 13 04:13:15 2009 Subject: [GHC] #3400: OS X: ghc broken on Snow Leopard In-Reply-To: <042.42f8ee6f478d8beecc65fea9d7e2b0b4@localhost> References: <042.42f8ee6f478d8beecc65fea9d7e2b0b4@localhost> Message-ID: <051.0a9a2fae939b4edf4ba2c2e445324b97@localhost> #3400: OS X: ghc broken on Snow Leopard -------------------------+-------------------------------------------------- Reporter: bbb | Owner: chak Type: bug | Status: reopened Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.11 Severity: blocker | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------+-------------------------------------------------- Comment (by simonmar): Manuel, can this ticket be closed now? Does hsc2hs pass the correct flags to gcc when invoked from Cabal? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 13 04:35:58 2009 From: trac at galois.com (GHC) Date: Tue Oct 13 04:13:22 2009 Subject: [GHC] #3530: GHCi does not work on Snow Leopard In-Reply-To: <043.67172119f9bd273a2158fec836b33117@localhost> References: <043.67172119f9bd273a2158fec836b33117@localhost> Message-ID: <052.1cd38acf0dfa20beeef920fc00c569c2@localhost> #3530: GHCi does not work on Snow Leopard -------------------------+-------------------------------------------------- Reporter: chak | Owner: chak Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: GHCi | Version: 6.11 Severity: critical | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by simonmar): * owner: => chak -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 13 04:37:00 2009 From: trac at galois.com (GHC) Date: Tue Oct 13 04:14:18 2009 Subject: [GHC] #781: GHCi on x86_64, cannot link to static data in shared libs In-Reply-To: <044.a73c522b97030f99c5fa39d521657f06@localhost> References: <044.a73c522b97030f99c5fa39d521657f06@localhost> Message-ID: <053.6f2430d85f9d189c457ab6fe8c560417@localhost> #781: GHCi on x86_64, cannot link to static data in shared libs ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: high | Milestone: 6.14.1 Component: Compiler | Version: 6.5 Severity: normal | Resolution: Keywords: getEnvironment | Difficulty: Unknown Testcase: getEnvironment01 | Os: Linux Architecture: x86_64 (amd64) | ---------------------------------+------------------------------------------ Changes (by simonmar): * milestone: 6.12.1 => 6.14.1 Comment: Let's look into this for 6.14.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 13 04:40:22 2009 From: trac at galois.com (GHC) Date: Tue Oct 13 04:17:41 2009 Subject: [GHC] #781: GHCi on x86_64, cannot link to static data in shared libs In-Reply-To: <044.a73c522b97030f99c5fa39d521657f06@localhost> References: <044.a73c522b97030f99c5fa39d521657f06@localhost> Message-ID: <053.ded60f8c46a26a94a22bdbf3412a9b0c@localhost> #781: GHCi on x86_64, cannot link to static data in shared libs ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: high | Milestone: 6.14.1 Component: Compiler | Version: 6.5 Severity: normal | Resolution: Keywords: getEnvironment | Difficulty: Unknown Testcase: getEnvironment01 | Os: Linux Architecture: x86_64 (amd64) | ---------------------------------+------------------------------------------ Comment (by simonmar): Ok, to elaborate on this. The solution would be to compile everything with `-fPIC` on x86-64, ie. enable `-fPIC` by default. We have to measure the performance impact of doing that, which might not be a problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 13 04:41:57 2009 From: trac at galois.com (GHC) Date: Tue Oct 13 04:19:17 2009 Subject: [GHC] #3486: Data.ByteString.elemIndices causes SEGV In-Reply-To: <042.edd017489a67f7a628a8510b09ab86e5@localhost> References: <042.edd017489a67f7a628a8510b09ab86e5@localhost> Message-ID: <051.a1c817b8afdb947318a9ae26b60f6538@localhost> #3486: Data.ByteString.elemIndices causes SEGV -------------------------------+-------------------------------------------- Reporter: nwn | Owner: duncan Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: libraries/base | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------------+-------------------------------------------- Comment (by simonmar): Duncan, can this be closed now? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 13 04:44:32 2009 From: trac at galois.com (GHC) Date: Tue Oct 13 04:21:50 2009 Subject: [GHC] #3561: Incorrect code generation on x86 In-Reply-To: <046.830b8d22811c2db4fef4cbd450983c13@localhost> References: <046.830b8d22811c2db4fef4cbd450983c13@localhost> Message-ID: <055.c7bbde8f8891571981edec1adb8ef9a0@localhost> #3561: Incorrect code generation on x86 -------------------------+-------------------------------------------------- Reporter: aleksey | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.10.4 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by simonmar): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 13 04:49:00 2009 From: trac at galois.com (GHC) Date: Tue Oct 13 04:26:21 2009 Subject: [GHC] #3562: syb package on Hackage does not work with 6.12 In-Reply-To: <047.ca75d0163023fb07d978a0b10f3fc7bc@localhost> References: <047.ca75d0163023fb07d978a0b10f3fc7bc@localhost> Message-ID: <056.7e15ce2616072e4a08830931eccac4ea@localhost> #3562: syb package on Hackage does not work with 6.12 ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): Pedro, as the maintainer of syb, will you have a chance to fix this soon? (Also, BTW, the package doesn't currently list you as the maintainer, perhaps you could update that at the same time). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 13 04:49:31 2009 From: trac at galois.com (GHC) Date: Tue Oct 13 04:26:50 2009 Subject: [GHC] #3546: Use of float type in unregistered build freezes program In-Reply-To: <045.6ea33c309ca87fd9faa6c939333fbcac@localhost> References: <045.6ea33c309ca87fd9faa6c939333fbcac@localhost> Message-ID: <054.7daac9bf6178ba4ec8c35ae1b0604ec1@localhost> #3546: Use of float type in unregistered build freezes program -------------------------------------------+-------------------------------- Reporter: dterei | Owner: igloo Type: merge | Status: closed Priority: high | Milestone: 6.12.1 Component: Compiler | Version: Severity: critical | Resolution: fixed Keywords: float unregistered freezes | Difficulty: Unknown Testcase: arith006 | Os: Unknown/Multiple Architecture: Unknown/Multiple | -------------------------------------------+-------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 13 05:06:59 2009 From: trac at galois.com (GHC) Date: Tue Oct 13 04:44:16 2009 Subject: [GHC] #3532: haddock should support content indexing of versioned package dirs In-Reply-To: <050.349010e190ff2a924354f840d1a8ec2b@localhost> References: <050.349010e190ff2a924354f840d1a8ec2b@localhost> Message-ID: <059.6a1d0798bb87e7081171397807a4b6a5@localhost> #3532: haddock should support content indexing of versioned package dirs ---------------------------------+------------------------------------------ Reporter: juhpetersen | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Documentation | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * owner: => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 13 05:57:22 2009 From: trac at galois.com (GHC) Date: Tue Oct 13 05:34:43 2009 Subject: [GHC] #3562: syb package on Hackage does not work with 6.12 In-Reply-To: <047.ca75d0163023fb07d978a0b10f3fc7bc@localhost> References: <047.ca75d0163023fb07d978a0b10f3fc7bc@localhost> Message-ID: <056.93717e5d8d19c027c0341e09ba937466@localhost> #3562: syb package on Hackage does not work with 6.12 ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: dreixel Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by dreixel): * owner: => dreixel -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 13 05:57:59 2009 From: trac at galois.com (GHC) Date: Tue Oct 13 05:35:18 2009 Subject: [GHC] #3562: syb package on Hackage does not work with 6.12 In-Reply-To: <047.ca75d0163023fb07d978a0b10f3fc7bc@localhost> References: <047.ca75d0163023fb07d978a0b10f3fc7bc@localhost> Message-ID: <056.6dbd79059cfe847b0eeeda880d770a85@localhost> #3562: syb package on Hackage does not work with 6.12 ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: dreixel Type: bug | Status: closed Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by dreixel): * status: new => closed * resolution: => wontfix Comment: GHC 6.12 comes with its own syb-0.1.0.2. GHC 6.14 will not come with syb, but by then there will be a version on Hackage lacking the flag. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 13 07:02:48 2009 From: trac at galois.com (GHC) Date: Tue Oct 13 06:40:07 2009 Subject: [GHC] #3578: internal error: evacuate(static): strange closure type 42 In-Reply-To: <043.5afd3bca71e73869953acaf1347724a9@localhost> References: <043.5afd3bca71e73869953acaf1347724a9@localhost> Message-ID: <052.70c65d8c88b75d64868951f18a23b598@localhost> #3578: internal error: evacuate(static): strange closure type 42 -------------------------------+-------------------------------------------- Reporter: nccb | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Runtime System | Version: 6.13 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by simonmar): * priority: normal => high * difficulty: => Unknown * owner: => simonmar * milestone: => 6.12.1 Comment: Can you supply the program please? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 13 08:50:32 2009 From: trac at galois.com (GHC) Date: Tue Oct 13 08:27:48 2009 Subject: [GHC] #3577: Complete support for Data Parallel Haskell In-Reply-To: <041.e54cf544394515fd2960400b723e2495@localhost> References: <041.e54cf544394515fd2960400b723e2495@localhost> Message-ID: <050.981379b60983f0f5095fd9e88aaf3f01@localhost> #3577: Complete support for Data Parallel Haskell --------------------------------------+------------------------------------- Reporter: rl | Owner: rl Type: feature request | Status: new Priority: normal | Milestone: Component: Data Parallel Haskell | Version: 6.13 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | --------------------------------------+------------------------------------- Changes (by simonpj): * difficulty: => Unknown Comment: See #3555 for one example of incomplete support (closed in favour of this catch-all ticket). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 13 10:13:53 2009 From: trac at galois.com (GHC) Date: Tue Oct 13 09:51:11 2009 Subject: [GHC] #3578: internal error: evacuate(static): strange closure type 42 In-Reply-To: <043.5afd3bca71e73869953acaf1347724a9@localhost> References: <043.5afd3bca71e73869953acaf1347724a9@localhost> Message-ID: <052.8c5c968148f3e57a8947c8f61da8cdbd@localhost> #3578: internal error: evacuate(static): strange closure type 42 -------------------------------+-------------------------------------------- Reporter: nccb | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Runtime System | Version: 6.13 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------------+-------------------------------------------- Comment (by nccb): I've attached it. I get the error with CHP version 1.4.0 (available on Hackage), it may occur with earlier versions. I just configure the attached package without any special options on GHC 6.12.1-rc1, build it, and then when I run it I get the error -- especially if a higher number of cores are used, e.g. dist/build/chp-boids/chp-boids +RTS -N6. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 13 11:42:19 2009 From: trac at galois.com (GHC) Date: Tue Oct 13 11:19:40 2009 Subject: [GHC] #3580: ghc-6.12.1rc1 on Nix: ghci does not work Message-ID: <047.87fc0e02fbdf92a08407bcd8577f2851@localhost> #3580: ghc-6.12.1rc1 on Nix: ghci does not work -----------------------------+---------------------------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.11 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: x86 -----------------------------+---------------------------------------------- After building the ghc-6.12.1 release candidate on a 32-bit Arch Linux machine using Nix, ghci fails to start with the following error: {{{ GHCi, version 6.12.0.20091010: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. ghc-stage2: /nix/store/nkg79yilgrdcfpkrfvr15jrg2v49svrn- ghc-6.12.0.20091010/lib/ghc-6.12.0.20091010/HSffi.o: no string tables, or too many Loading package ffi-1.0 ... ghc-stage2: panic! (the 'impossible' happened) (GHC version 6.12.0.20091010 for i386-unknown-linux): loadObj: failed Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I know that I encountered this problem before when trying to build the HEAD a couple of months before, but I didn't ever have this problem with ghc-6.10.* using Nix. Any ideas? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 13 13:46:16 2009 From: trac at galois.com (GHC) Date: Tue Oct 13 13:28:35 2009 Subject: [GHC] #3581: Compiling with optimizations on hurts performance Message-ID: <048.d876b81c29f04d74d296e08f87f1f592@localhost> #3581: Compiling with optimizations on hurts performance -----------------------------+---------------------------------------------- Reporter: gchrupala | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: major Keywords: optimization | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- The attached program runs many times slower when compiled with optimizations (4.5 seconds vs. 1.5 minutes on my machine). I wasn't able to reduce the program to a small snippet so I attach the whole thing (including data files to process). I compiled and ran like this: > ghc --make test2.hs > time ./test2 And then > ghc --make test2 -fforce-recomp -O > time ./test2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 13 13:52:20 2009 From: trac at galois.com (GHC) Date: Tue Oct 13 13:34:38 2009 Subject: [GHC] #3582: Compiling with optimizations on hurts performance Message-ID: <048.4bb5f69a00bcb236ccbbc2a5b2badbb3@localhost> #3582: Compiling with optimizations on hurts performance -----------------------------+---------------------------------------------- Reporter: gchrupala | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: major Keywords: optimization | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- The attached program runs many times slower when compiled with optimizations (4.5 seconds vs. 1.5 minutes on my machine). I wasn't able to reduce the program to a small snippet so I attach the whole thing (including data files to process). I compiled and ran like this: > ghc --make test2.hs > time ./test2 And then > ghc --make test2 -fforce-recomp -O > time ./test2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 13 14:00:07 2009 From: trac at galois.com (GHC) Date: Tue Oct 13 13:42:24 2009 Subject: [GHC] #3581: Compiling with optimizations on hurts performance In-Reply-To: <048.d876b81c29f04d74d296e08f87f1f592@localhost> References: <048.d876b81c29f04d74d296e08f87f1f592@localhost> Message-ID: <057.9fe531ef72b2bbe22196219ffb8a61ac@localhost> #3581: Compiling with optimizations on hurts performance ------------------------------+--------------------------------------------- Reporter: gchrupala | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: major | Resolution: duplicate Keywords: optimization | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by gchrupala): * status: new => closed * resolution: => duplicate -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 13 15:09:43 2009 From: trac at galois.com (GHC) Date: Tue Oct 13 14:46:59 2009 Subject: [GHC] #3486: Data.ByteString.elemIndices causes SEGV In-Reply-To: <042.edd017489a67f7a628a8510b09ab86e5@localhost> References: <042.edd017489a67f7a628a8510b09ab86e5@localhost> Message-ID: <051.8541d6073852a2f74845d7bd5c678cee@localhost> #3486: Data.ByteString.elemIndices causes SEGV -------------------------------+-------------------------------------------- Reporter: nwn | Owner: duncan Type: bug | Status: closed Priority: high | Milestone: 6.12.1 Component: libraries/base | Version: 6.10.4 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by duncan): * status: new => closed * resolution: => fixed Comment: Replying to [comment:5 simonmar]: > Duncan, can this be closed now? Yes, the fix is in bytestring-0.9.1.5 which is included with ghc-6.12 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 13 15:09:47 2009 From: trac at galois.com (GHC) Date: Tue Oct 13 14:47:04 2009 Subject: [GHC] #3487: Data.ByteString.Lazy.elemIndices returns wrong results In-Reply-To: <042.4f1103cc60c42d21bbc9fb56583d59f1@localhost> References: <042.4f1103cc60c42d21bbc9fb56583d59f1@localhost> Message-ID: <051.6fbe318ec39aeb57e2f513d3e689eebc@localhost> #3487: Data.ByteString.Lazy.elemIndices returns wrong results -------------------------------+-------------------------------------------- Reporter: nwn | Owner: duncan Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: libraries/base | Version: 6.10.4 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by duncan): * status: new => closed * resolution: => fixed Comment: Fix is in bytestring-0.9.1.5 which is included with ghc-6.12. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 13 19:24:29 2009 From: trac at galois.com (GHC) Date: Tue Oct 13 19:01:45 2009 Subject: [GHC] #3496: GHC panic while building the base library with Cabal In-Reply-To: <047.5c600ae82cf71150830a6ede7f6640ea@localhost> References: <047.5c600ae82cf71150830a6ede7f6640ea@localhost> Message-ID: <056.2116154dfc091e2de35931f22fa218a6@localhost> #3496: GHC panic while building the base library with Cabal ---------------------------------+------------------------------------------ Reporter: elliottt | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.4 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by elliottt): When building with ghc 6.12.0 rc1, I encountered the same panic when the Foreign.Ptr module was reached. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 13 19:28:16 2009 From: trac at galois.com (GHC) Date: Tue Oct 13 19:05:30 2009 Subject: [GHC] #3583: Default view patterns Message-ID: <042.09c0286c1bb4575dcdfed8f2d7712a89@localhost> #3583: Default view patterns -----------------------------+---------------------------------------------- Reporter: ksf | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- as useful for code like http://hpaste.org/fastcgi/hpaste.fcgi/view?id=10699#a10699 : Provide a unified left-hand interface for [] and Seq with the same syntax as current lists. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 14 01:36:05 2009 From: trac at galois.com (GHC) Date: Wed Oct 14 01:13:29 2009 Subject: [GHC] #3580: ghc-6.12.1rc1 on Nix: ghci does not work In-Reply-To: <047.87fc0e02fbdf92a08407bcd8577f2851@localhost> References: <047.87fc0e02fbdf92a08407bcd8577f2851@localhost> Message-ID: <056.7b7e94e107fc22142eccf6e3a994611a@localhost> #3580: ghc-6.12.1rc1 on Nix: ghci does not work ------------------------------+--------------------------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: x86 ------------------------------+--------------------------------------------- Comment (by kosmikus): I have investigated a bit. The error message puts the error in HSffi.o. I compared that file with the file in the binary distribution for Linux, and they are indeed different. In my build, the output of {{{objdump -sx}}} is: {{{ /nix/store/nkg79yilgrdcfpkrfvr15jrg2v49svrn- ghc-6.12.0.20091010/lib/ghc-6.12.0.20091010/HSffi.o: file format elf32-i386 /nix/store/nkg79yilgrdcfpkrfvr15jrg2v49svrn- ghc-6.12.0.20091010/lib/ghc-6.12.0.20091010/HSffi.o architecture: i386, flags 0x00000000: start address 0x00000000 Sections: Idx Name Size VMA LMA File off Algn 0 .text 00000000 00000000 00000000 00000034 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .data 00000000 00000000 00000000 00000034 2**2 CONTENTS, ALLOC, LOAD, DATA 2 .bss 00000000 00000000 00000000 00000034 2**2 ALLOC 3 .comment 00000012 00000000 00000000 00000034 2**0 CONTENTS, READONLY 4 .note.GNU-stack 00000000 00000000 00000000 00000046 2**0 CONTENTS, READONLY SYMBOL TABLE: no symbols Contents of section .comment: 0000 00474343 3a202847 4e552920 342e332e .GCC: (GNU) 4.3. 0010 3300 3. }}} In the precompiled 32-bit Linux binary I get: {{{ libffi/HSffi.o: file format elf32-i386 libffi/HSffi.o architecture: i386, flags 0x00000010: HAS_SYMS start address 0x00000000 Sections: Idx Name Size VMA LMA File off Algn 0 .text 00000000 00000000 00000000 00000034 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .data 00000000 00000000 00000000 00000034 2**2 CONTENTS, ALLOC, LOAD, DATA 2 .bss 00000000 00000000 00000000 00000034 2**2 ALLOC 3 .comment 0000002d 00000000 00000000 00000034 2**0 CONTENTS, READONLY 4 .note.GNU-stack 00000000 00000000 00000000 00000061 2**0 CONTENTS, READONLY SYMBOL TABLE: 00000000 l df *ABS* 00000000 empty.c 00000000 l d .text 00000000 .text 00000000 l d .data 00000000 .data 00000000 l d .bss 00000000 .bss 00000000 l d .note.GNU-stack 00000000 .note.GNU-stack 00000000 l d .comment 00000000 .comment Contents of section .comment: 0000 00474343 3a202847 4e552920 342e332e .GCC: (GNU) 4.3. 0010 30203230 30383034 32382028 52656420 0 20080428 (Red 0020 48617420 342e332e 302d3829 00 Hat 4.3.0-8). }}} Replacing the file HSffi.o in my build with the one from the binary distribution actually makes GHCi start up correctly. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 14 03:56:29 2009 From: trac at galois.com (GHC) Date: Wed Oct 14 03:33:42 2009 Subject: [GHC] #3583: Default view patterns In-Reply-To: <042.09c0286c1bb4575dcdfed8f2d7712a89@localhost> References: <042.09c0286c1bb4575dcdfed8f2d7712a89@localhost> Message-ID: <051.bc8ba61bf7c878ea978b569f16f75680@localhost> #3583: Default view patterns ---------------------------------+------------------------------------------ Reporter: ksf | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * difficulty: => Unknown Comment: You are making a feature request, but I was unable to determine what the feature is that you want. Would you like to update the description above to be 100% explicit? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 14 04:08:58 2009 From: trac at galois.com (GHC) Date: Wed Oct 14 03:46:16 2009 Subject: [GHC] #3584: type signature involving a type family rejected Message-ID: <048.c49cd8f6581150501f12653a3821d1e8@localhost> #3584: type signature involving a type family rejected -----------------------------+---------------------------------------------- Reporter: baramoglo | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 6.10.2 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: x86 -----------------------------+---------------------------------------------- `add1` is rejected in the following program: {{{ {-# LANGUAGE EmptyDataDecls, FlexibleContexts, FlexibleInstances, GADTs, TypeFamilies, TypeOperators, UndecidableInstances #-} data False type family IsNegative x type family x :+: y class Natural x instance (IsNegative x ~ False) => Natural x data A n where A :: Natural n => Int -> A n getA :: A n -> Int getA (A n) = n add1 :: Natural (m:+:n) => A m -> A n -> A (m:+:n) add1 (A a) (A b) = A (a+b) add2 (A a) (A b) = A (a+b) add3 :: (IsNegative (m:+:n) ~ False) => A m -> A n -> A (m:+:n) add3 (A a) (A b) = A (a+b) add4 :: Natural (m:+:n) => A m -> A n -> A (m:+:n) add4 a b = A (getA a + getA b) add5 :: Natural (m:+:n) => A m -> A n -> A (m:+:n) add5 (A a) _ = A a }}} The following modifications of `add1` work fine: * Removing the type signature (`add2`) * Using the type inferred for `add2` (`add3`) * Using the projection function `getA` instead of pattern matching (`add4`) * Only pattern match on the first argument -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 14 04:33:08 2009 From: trac at galois.com (GHC) Date: Wed Oct 14 04:10:25 2009 Subject: [GHC] #3575: mkStdGen and split conspire to make some programs predictable In-Reply-To: <047.6485fb2275f266e278f6578e798e2d4e@localhost> References: <047.6485fb2275f266e278f6578e798e2d4e@localhost> Message-ID: <056.647585fedc483c189dfc3b3ecc3d723d@localhost> #3575: mkStdGen and split conspire to make some programs predictable ---------------------------------+------------------------------------------ Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/random | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * difficulty: => Unknown Comment: Another thread here http://article.gmane.org/gmane.comp.lang.haskell.cafe/64741/ It concerns `Control.Monad.Random` rather than `System.Random`, but `Control.Monad.Random` in turn may depend on the same underlying infrastructure; anyway it looked related. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 14 04:35:45 2009 From: trac at galois.com (GHC) Date: Wed Oct 14 04:13:00 2009 Subject: [GHC] #3575: mkStdGen and split conspire to make some programs predictable In-Reply-To: <047.6485fb2275f266e278f6578e798e2d4e@localhost> References: <047.6485fb2275f266e278f6578e798e2d4e@localhost> Message-ID: <056.fa644a386ec315d95f10fb3e1c6ca58d@localhost> #3575: mkStdGen and split conspire to make some programs predictable ---------------------------------+------------------------------------------ Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/random | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonpj): Fantastic bug report from Reid Barton! Thanks. His report, and perhaps the other thread above, identifies serious shortcomings in `System.Random`. Does anyone feel able to help fix them? I think it's unlikely that GHC HQ will; we're snowed under, and we have zero expertise in random number generators. Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 14 06:31:31 2009 From: trac at galois.com (GHC) Date: Wed Oct 14 06:08:46 2009 Subject: [GHC] #3579: Error: symbol `Bug_compose1_closure' is already defined In-Reply-To: <044.8d0cee2189cb326f04528793a172ebca@localhost> References: <044.8d0cee2189cb326f04528793a172ebca@localhost> Message-ID: <053.85abb5fa645b0a78dd5388eabb2d6bcf@localhost> #3579: Error: symbol `Bug_compose1_closure' is already defined ---------------------------------+------------------------------------------ Reporter: igloo | Owner: igloo Type: merge | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.13 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: Fixed (test to follow) {{{ Wed Oct 14 10:51:53 BST 2009 Simon Marlow * Fix #3579: avoid clashing with names of implicit bindings }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 14 07:01:10 2009 From: trac at galois.com (GHC) Date: Wed Oct 14 06:38:29 2009 Subject: [GHC] #3585: runhaskell displays an UTF-8 decoding error Message-ID: <043.f9ca24ebfc551d0441ed44a2e4d9df86@localhost> #3585: runhaskell displays an UTF-8 decoding error -----------------------+---------------------------------------------------- Reporter: chak | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.12.0 RC1 | Severity: normal Keywords: | Testcase: Os: MacOS X | Architecture: x86 -----------------------+---------------------------------------------------- I have the following problem with the 6.12.1RC1 Mac installer package on Snow Leopard: {{{ WithinReason chak 9 (.../Code/haskell): file HelloWorld.hs HelloWorld.hs: ASCII text WithinReason chak 10 (.../Code/haskell): cat HelloWorld.hs main = putStrLn "Hello World!" WithinReason chak 11 (.../Code/haskell): runhaskell HelloWorld HelloWorld:1:0: lexical error (UTF-8 decoding error) WithinReason chak 12 (.../Code/haskell): }}} I reckon that this is not Snow Leopard-specific, but I didn't verify that. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 14 08:07:05 2009 From: trac at galois.com (GHC) Date: Wed Oct 14 07:44:23 2009 Subject: [GHC] #3585: runhaskell displays an UTF-8 decoding error In-Reply-To: <043.f9ca24ebfc551d0441ed44a2e4d9df86@localhost> References: <043.f9ca24ebfc551d0441ed44a2e4d9df86@localhost> Message-ID: <052.20411ddba4a9b9a527d84ef749441459@localhost> #3585: runhaskell displays an UTF-8 decoding error ----------------------+----------------------------------------------------- Reporter: chak | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.12.0 RC1 Severity: normal | Resolution: invalid Keywords: | Testcase: Os: MacOS X | Architecture: x86 ----------------------+----------------------------------------------------- Changes (by chak): * status: new => closed * resolution: => invalid Comment: It's trying to load the binary, so not really a bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 14 08:27:15 2009 From: trac at galois.com (GHC) Date: Wed Oct 14 08:05:50 2009 Subject: [GHC] #3400: OS X: ghc broken on Snow Leopard In-Reply-To: <042.42f8ee6f478d8beecc65fea9d7e2b0b4@localhost> References: <042.42f8ee6f478d8beecc65fea9d7e2b0b4@localhost> Message-ID: <051.9cd1d757ed161697f76313c7449f39d2@localhost> #3400: OS X: ghc broken on Snow Leopard -------------------------+-------------------------------------------------- Reporter: bbb | Owner: chak Type: bug | Status: reopened Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.11 Severity: blocker | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------+-------------------------------------------------- Comment (by chak): Replying to [comment:11 simonmar]: > Manuel, can this ticket be closed now? Does hsc2hs pass the correct flags to gcc when invoked from Cabal? No, hsc2hs doesn't get the right flags. Specifically, what is missing is that if we have i386_TARGET_ARCH and darwin_TARGET_OS, we need to pass -m32 to the compile and link flags that hsc2hs passes to gcc. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 14 10:03:43 2009 From: trac at galois.com (GHC) Date: Wed Oct 14 09:40:57 2009 Subject: [GHC] #3578: internal error: evacuate(static): strange closure type 42 In-Reply-To: <043.5afd3bca71e73869953acaf1347724a9@localhost> References: <043.5afd3bca71e73869953acaf1347724a9@localhost> Message-ID: <052.e90ab85b0a7ba2e17eca251d8c2d7894@localhost> #3578: internal error: evacuate(static): strange closure type 42 -------------------------------+-------------------------------------------- Reporter: nccb | Owner: igloo Type: merge | Status: new Priority: high | Milestone: 6.12.1 Component: Runtime System | Version: 6.13 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: Thanks, nice bug report, and good to catch it before the release. {{{ Wed Oct 14 14:16:19 BST 2009 Simon Marlow * Fix #3578: return a dummy result when an STM transaction is aborted }}} Might as well merge this too: {{{ Wed Oct 14 14:17:27 BST 2009 Simon Marlow * micro-opt: replace stmGetEnclosingTRec() with a field access While fixing #3578 I noticed that this function was just a field access to StgTRecHeader, so I inlined it manually. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 14 10:42:31 2009 From: trac at galois.com (GHC) Date: Wed Oct 14 10:19:50 2009 Subject: [GHC] #3561: Incorrect code generation on x86 In-Reply-To: <046.830b8d22811c2db4fef4cbd450983c13@localhost> References: <046.830b8d22811c2db4fef4cbd450983c13@localhost> Message-ID: <055.eac5258ba4e8c3d8be1da19c788cb436@localhost> #3561: Incorrect code generation on x86 -------------------------+-------------------------------------------------- Reporter: aleksey | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.10.4 Severity: major | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Test added. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 14 11:02:15 2009 From: trac at galois.com (GHC) Date: Wed Oct 14 10:44:31 2009 Subject: [GHC] #3584: type signature involving a type family rejected In-Reply-To: <048.c49cd8f6581150501f12653a3821d1e8@localhost> References: <048.c49cd8f6581150501f12653a3821d1e8@localhost> Message-ID: <057.055ae8eca63a804e627d0c6e9c8835e1@localhost> #3584: type signature involving a type family rejected ----------------------------------------+----------------------------------- Reporter: baramoglo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86 | ----------------------------------------+----------------------------------- Changes (by simonpj): * difficulty: => Unknown Comment: The problem is your instance for `Natural x`. You are saying "If you want to prove `Natural x`, then please prove (`IsNegative x ~ False`)". Now in the RHS of `add1`, GHC is faced with thee following problem: {{{ From (Natural (m:+:n), -- From signature Natural n, -- From first pattern match Natural m) -- From second pattern match please prove Natural (m:+:n) }}} That seems easy enough, since the thing to prove is one of the premises. But a possible reasoning step is to use the instance declaration first, leading to {{{ please prove IsNegative (m:+:n) ~ False }}} which we obviously can't do. Your instance declaration promises an alternative way to prove a constraint `(Natural ty)`, but one which turns out to be a blind alley. But GHC does not ''search'' for a proof; it follows just one path. (In general the search could be very complicated.) Nevertheless, I think there is a bug here: GHC should really ''not'' use an instance declaration if there is any possibility that one of the local premises might match, rather in the same way that it refrains from committing to one instance if more than one matches. Thanks for pointing this out. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 14 11:15:22 2009 From: trac at galois.com (GHC) Date: Wed Oct 14 10:52:35 2009 Subject: [GHC] #3586: Slow array code Message-ID: <046.d37b803347b32ce78018550b0e0c0244@localhost> #3586: Slow array code ---------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ---------------------------------------+------------------------------------ On the Clean mailing list, Philippos Apolinarius [phi500ac@yahoo.ca] describes a small array program (using the ST monad) that runs 400x more slowly in Haskell than Clean. I can understand a bit slower (e.g. maybe they do a better job of array-bound checks), but 400x seems large. This ticket is an invitation for someone to investigate. He writes: I wrote a very simple program to check whether Haskell improved its array processing libraries or not. Here is how to compile and run the program arr.hs in Haskell (I have used the GHC compiler): {{{ >ghc -O arr.hs -o arr.exe $ time arr.exe +RTS -K32000000 2.8e8 real 0m3.938s user 0m0.031s sys 0m0.000s }}} The same program in Clean: {{{ C:\Clean 2.2\exemplos\console>arraytest.exe 280000000 Execution: 0.01 Garbage collection: 0.01 Total: 0.03 C:\Clean 2.2\exemplos\console>arraytest.exe 280000000 Execution: 0.01 Garbage collection: 0.01 Total: 0.03 }}} This means that Clean is 390 times faster than Haskell in this particular problem. These results makes me worder whether Haskell is safer than Clean. It turns out that Haskell checks index out of range at runtime, exactly like Clean. Larger problems make the difference between Clean and Haskell even worse. For instance, neural networks like the one described in Schmidtt et al. run 400 times faster in Clean. Below you will find the array examples. You can check that Clean is really much faster than Haskell. I wonder why the Benchmarks Game site does not report such a large difference between Haskell and Clean performances. I believe that people who wrote Haskell benchmarks for the Benchmarks Game site cheated in using foreign pointers to access arrays. {{{ -- arr.hs import Control.Monad.ST import Data.Array.ST main = print $ runST (do arr <- newArray (1,2000000) 137.0 :: ST s (STArray s Int Double) a <- readArray arr 1 b <- readArray arr 1 fn 2000000 arr 0.0 ) fn i a acc | i < 1 = do (return acc) fn i a acc= do b <- readArray a i writeArray a i (b+3.0) c <- readArray a i fn (i-1) a (acc+c) }}} Clean version {{{ module arraytest import StdEnv fn i a acc | i<1 = acc fn i a=:{[i]=b} acc # a= {a&[i]= b+3.0} # (c, a)= a![i] = fn (i-1) a (c+acc) Start= fn 2000000 vt 0.0 where vt:: .{#Real} vt = createArray 2000001 137.0 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 14 12:33:13 2009 From: trac at galois.com (GHC) Date: Wed Oct 14 12:10:26 2009 Subject: [GHC] #3586: Slow array code In-Reply-To: <046.d37b803347b32ce78018550b0e0c0244@localhost> References: <046.d37b803347b32ce78018550b0e0c0244@localhost> Message-ID: <055.413564ca0688e54d25cf13a42fac7687@localhost> #3586: Slow array code -----------------------------------------+---------------------------------- Reporter: simonpj | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Comment (by dons): Isn't the problem here that you're using unboxed arrays in Clean, but boxed arrays in Haskell? Secondly, there's a space leak in the fn function, and a bunch of things that aren't in the Clean code. Fixing things: Correcting the space leak: {{{ {-# LANGUAGE BangPatterns #-} import Control.Monad.ST import Data.Array.ST main = print $ runST (do arr <- newArray (1,2000000) 137.0 :: ST s (STArray s Int Double) a <- readArray arr 1 b <- readArray arr 1 fn 2000000 arr 0.0 ) fn i !a !acc | i < 1 = do (return acc) fn i a acc= do b <- readArray a i writeArray a i (b+3.0) c <- readArray a i fn (i-1) a (acc+c) }}} Results in: {{{ $ time ./B +RTS -sstderr ./B +RTS -sstderr 2.8e8 ./B +RTS -sstderr 2.95s user 0.07s system 99% cpu 3.034 total }}} 3.034s Where 98.6% of the time is spent in GC (this is why you don't use boxed mutable arrays when you can use unboxed ones. Increasing the GC thresholds, improves performance 20 fold: {{{ $ time ./B +RTS -sstderr -A200M ./B +RTS -sstderr -A200M 2.8e8 ./B +RTS -sstderr -A200M 0.06s user 0.12s system 100% cpu 0.176 total }}} 0.176s using boxed arrays. Switching to an STUArray, and adding some type annotations: {{{ {-# LANGUAGE BangPatterns #-} {-# OPTIONS -fexcess-precision #-} import Control.Monad.ST import Data.Array.ST import Data.Array.Base main = print $ runST (do arr <- newArray (1,2000000) 137.0 :: ST s (STUArray s Int Double) fn 2000000 arr 0.0 ) fn :: Int -> STUArray s Int Double -> Double -> ST s Double fn i !a !acc | i < 1 = return acc fn i a acc = do b <- unsafeRead a i unsafeWrite a i (b+3.0) c <- unsafeRead a i fn (i-1) a (c + acc) ./B +RTS -sstderr 0.26s user 0.01s system 97% cpu 0.283 total }}} So still not great. Perhaps someone can look into it further? The original bug report is a duplicate of the boxed, mutable arrays ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 14 12:57:11 2009 From: trac at galois.com (GHC) Date: Wed Oct 14 12:34:27 2009 Subject: [GHC] #3586: Slow array code In-Reply-To: <046.d37b803347b32ce78018550b0e0c0244@localhost> References: <046.d37b803347b32ce78018550b0e0c0244@localhost> Message-ID: <055.09210cd5cdf624dfb653eb861a8eb7e1@localhost> #3586: Slow array code -----------------------------------------+---------------------------------- Reporter: simonpj | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Comment (by dons): How I'd write it: {{{ {-# LANGUAGE BangPatterns #-} {-# OPTIONS -fvia-C -optc-O3 -fexcess-precision -optc-msse3 #-} import Control.Monad.ST import Data.Array.ST import Data.Array.Base main = print $ runST (do arr <- newArray (1,2000000) 137.0 :: ST s (STUArray s Int Double) go arr 2000000 0.0 ) go :: STUArray s Int Double -> Int -> Double -> ST s Double go !a i !acc | i < 1 = return acc | otherwise = do b <- unsafeRead a i unsafeWrite a i (b+3.0) c <- unsafeRead a i go a (i-1) (c+acc) }}} Which yield this loop for 'go': {{{ Main_zdwa_info: leaq 16(%r12), %rax cmpq %r15, %rax movq %rax, %r12 ja .L4 testq %rdi, %rdi jle .L5 leaq 16(%rsi,%rdi,8), %rdx leaq -16(%rax), %r12 leaq -1(%rdi), %rdi movsd (%rdx), %xmm0 addsd .LC0(%rip), %xmm0 addsd %xmm0, %xmm5 movsd %xmm0, (%rdx) jmp Main_zdwa_info }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 14 13:06:49 2009 From: trac at galois.com (GHC) Date: Wed Oct 14 12:44:02 2009 Subject: [GHC] #3586: Slow array code In-Reply-To: <046.d37b803347b32ce78018550b0e0c0244@localhost> References: <046.d37b803347b32ce78018550b0e0c0244@localhost> Message-ID: <055.87451ab063909b7eacf11ffee4577e3f@localhost> #3586: Slow array code -----------------------------------------+---------------------------------- Reporter: simonpj | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Comment (by dons): Rewriting to use uvector: {{{ import Data.Array.Vector main = print . sumU . mapU (+3) $ replicateU 2000000 (137.0 :: Double) }}} Compiling: {{{ $ ghc -O2 --make Z.hs -fvia-C -optc-O3 -fforce-recomp -optc-msse4 $ time ./Z 2.8e8 ./Z 0.01s user 0.00s system 108% cpu 0.012 tota }}} Which I believe is both purely functional, and twice as fast as the Clean code. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 14 13:08:27 2009 From: trac at galois.com (GHC) Date: Wed Oct 14 12:45:41 2009 Subject: [GHC] #3586: Slow array code In-Reply-To: <046.d37b803347b32ce78018550b0e0c0244@localhost> References: <046.d37b803347b32ce78018550b0e0c0244@localhost> Message-ID: <055.4bbbac45a098f1963251e5cf6444216e@localhost> #3586: Slow array code -----------------------------------------+---------------------------------- Reporter: simonpj | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Comment (by dons): The uvector version generates an inner loop of: {{{ Main_zdwfold_info: cmpq $2000000, %rsi je .L8 .L4: addsd .LC0(%rip), %xmm5 leaq 1(%rsi), %rsi jmp Main_zdwfold_info }}} Fusion FTW. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 14 13:21:16 2009 From: trac at galois.com (GHC) Date: Wed Oct 14 12:58:30 2009 Subject: [GHC] #3586: Slow array code In-Reply-To: <046.d37b803347b32ce78018550b0e0c0244@localhost> References: <046.d37b803347b32ce78018550b0e0c0244@localhost> Message-ID: <055.1261c78b99918b4a1db5f21fbc6cd0dd@localhost> #3586: Slow array code -----------------------------------------+---------------------------------- Reporter: simonpj | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Comment (by dons): The problem in the STUArray version is newArray_, which uses the generic newArray, which fills from a list. It does not fuse. Rewriting the STUArray version to initialize directly and we get identical results to Clean. {{{ {-# LANGUAGE BangPatterns #-} {-# OPTIONS -fvia-C -optc-O3 -fexcess-precision -optc-msse3 #-} import Control.Monad.ST import Data.Array.ST import Data.Array.Base main = print $ runST (do a <- unsafeNewArray_ (1,2000000) let init i | i >= 2000000 = return () | otherwise = unsafeWrite a i 137 >> init (i+1) init 0 go a 2000000 0.0 ) go :: STUArray s Int Double -> Int -> Double -> ST s Double go !a i !acc | i < 1 = return acc | otherwise = do b <- unsafeRead a i unsafeWrite a i (b+3.0) c <- unsafeRead a i go a (i-1) (c+acc) $ ghc -O2 --make B.hs -fvia-C -optc-O3 -optc-msse4 [1 of 1] Compiling Main ( B.hs, B.o ) Linking B ... $ time ./B 2.79999863e8 ./B 0.01s user 0.02s system 108% cpu 0.031 total }}} Recommendation: custom newArray_ methods in the Data.Array.Base module that fill directly with a tail recursive loop. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 14 13:48:17 2009 From: trac at galois.com (GHC) Date: Wed Oct 14 13:25:30 2009 Subject: [GHC] #3583: Default view patterns In-Reply-To: <042.09c0286c1bb4575dcdfed8f2d7712a89@localhost> References: <042.09c0286c1bb4575dcdfed8f2d7712a89@localhost> Message-ID: <051.15b1f92d112161817c0176390ce22bd6@localhost> #3583: Default view patterns ---------------------------------+------------------------------------------ Reporter: ksf | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by ksf): Erm yes. The idea is to desugar {{{ foo Bar = baz }}} into {{{ foo (view -> Bar) = baz }}} , "view" being a member of a magic typeclass types have to instantiate to be eligible for this transformation. The rationale is to make the syntax as free of clutter as is the case with matching on plain constructors, to facilitate usage of view patterns and abstraction from concrete representations. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 14 14:04:48 2009 From: trac at galois.com (GHC) Date: Wed Oct 14 13:41:59 2009 Subject: [GHC] #3586: Slow array code In-Reply-To: <046.d37b803347b32ce78018550b0e0c0244@localhost> References: <046.d37b803347b32ce78018550b0e0c0244@localhost> Message-ID: <055.d626c0b4ee03cd0024216774281be7b6@localhost> #3586: Slow array code -----------------------------------------+---------------------------------- Reporter: simonpj | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Comment (by int-e): Apparently, newArray isn't getting inlined as intended, and thus not getting specialized for the STU array types. Simply moving the implementation of newArray to its own function (which is marked inline) helps a lot. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 14 14:11:07 2009 From: trac at galois.com (GHC) Date: Wed Oct 14 13:48:19 2009 Subject: [GHC] #3586: Slow array code In-Reply-To: <046.d37b803347b32ce78018550b0e0c0244@localhost> References: <046.d37b803347b32ce78018550b0e0c0244@localhost> Message-ID: <055.ccdd3e9862162613faffc07537efb62d@localhost> #3586: Slow array code -----------------------------------------+---------------------------------- Reporter: simonpj | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Comment (by int-e): Addendum: The code generated for forM_ [0..n-1] ... is just as fast as a hand-written loop in my tests, if compiled with optimisations enabled. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 14 18:36:06 2009 From: trac at galois.com (GHC) Date: Wed Oct 14 18:13:19 2009 Subject: [GHC] #3587: provide a cross-platform way to set environment variables Message-ID: <044.64206ec8ce180cb0620df1ffe1482d34@localhost> #3587: provide a cross-platform way to set environment variables ---------------------------------+------------------------------------------ Reporter: shahn | Owner: Type: task | Status: new Priority: normal | Component: libraries/base Version: 6.10.4 | Severity: minor Keywords: environment variable | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ---------------------------------+------------------------------------------ System.Environment contains cross-platform operations to query environment variables, not to modify them. System.Posix.Env (package unix) provides operations to set environment variables on Linux (and probably other unices). This ticket requests adding cross-platform operations to set env vars to the module System.Environment. As a workaround i copied the implementation of [http://hackage.haskell.org/packages/archive/unix/2.3.2.0/doc/html/src /System-Posix-Env.html#putEnv System.Posix.Env.putEnv] into a new module. That seems to work on windows and linux (for me. Maybe this is due to using mingw/msys, though). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 15 03:18:19 2009 From: trac at galois.com (GHC) Date: Thu Oct 15 02:55:30 2009 Subject: [GHC] #3586: Slow array code In-Reply-To: <046.d37b803347b32ce78018550b0e0c0244@localhost> References: <046.d37b803347b32ce78018550b0e0c0244@localhost> Message-ID: <055.d5be414e97a5537021f498bfa8040e86@localhost> #3586: Slow array code -----------------------------------------+---------------------------------- Reporter: simonpj | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Comment (by simonpj): Adrian Hey points out that #650 (a long-standing performance bug in GC of mutable arrays) may be relevant here. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 15 04:29:52 2009 From: trac at galois.com (GHC) Date: Thu Oct 15 04:07:02 2009 Subject: [GHC] #3586: Slow array code In-Reply-To: <046.d37b803347b32ce78018550b0e0c0244@localhost> References: <046.d37b803347b32ce78018550b0e0c0244@localhost> Message-ID: <055.7339cdc9964b6efa524efeb8dd52521b@localhost> #3586: Slow array code -----------------------------------------+---------------------------------- Reporter: simonpj | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Comment (by int-e): Replying to [comment:8 simonpj]: > Adrian Hey points out that #650 (a long-standing performance bug in GC of mutable arrays) may be relevant here. Yes, that explains that most of the time is spent doing GC in the boxed array version without increasing the heap size. It does not explain why switching to unboxed arrays makes the program slower. (We have tracked down the reason for that, see earlier comments.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 15 04:50:03 2009 From: trac at galois.com (GHC) Date: Thu Oct 15 04:27:14 2009 Subject: [GHC] #3583: Default view patterns In-Reply-To: <042.09c0286c1bb4575dcdfed8f2d7712a89@localhost> References: <042.09c0286c1bb4575dcdfed8f2d7712a89@localhost> Message-ID: <051.4aa8f0138e91a966a967c7c91d4fea64@localhost> #3583: Default view patterns ---------------------------------+------------------------------------------ Reporter: ksf | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonpj): Aha. Yes, see http://hackage.haskell.org/trac/ghc/wiki/ViewPatterns, the section "Implicit View patterns". There's a syntactic question about whether the implicit view should be totally silent, or signalled by ''some'' syntax. In the above writeup, the suggestion is to write {{{ foo (->Bar) = baz }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 15 05:19:12 2009 From: trac at galois.com (GHC) Date: Thu Oct 15 04:56:25 2009 Subject: [GHC] #1185: can't do I/O in the child of forkProcess with -threaded In-Reply-To: <047.505ed9940eff9ef82094c96c7212dfa3@localhost> References: <047.505ed9940eff9ef82094c96c7212dfa3@localhost> Message-ID: <056.8c72f56ef23f1ee58b6d015f9bee7506@localhost> #1185: can't do I/O in the child of forkProcess with -threaded ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Runtime System | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by nakanowatari): * cc: takanori.nakanowatari@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 15 05:18:24 2009 From: trac at galois.com (GHC) Date: Thu Oct 15 04:56:44 2009 Subject: [GHC] #2965: GHC on OS X does not compile 64-bit In-Reply-To: <045.2214e7d1fe4dd43486128c197fdb9227@localhost> References: <045.2214e7d1fe4dd43486128c197fdb9227@localhost> Message-ID: <054.ed8dc1047250ad23c5ca04545729ad27@localhost> #2965: GHC on OS X does not compile 64-bit --------------------------------+------------------------------------------- Reporter: Axman6 | Owner: thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: Severity: normal | Resolution: Keywords: 64bit | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86_64 (amd64) | --------------------------------+------------------------------------------- Changes (by nakanowatari): * cc: takanori.nakanowatari@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 15 07:39:54 2009 From: trac at galois.com (GHC) Date: Thu Oct 15 07:17:05 2009 Subject: [GHC] #3587: provide a cross-platform way to set environment variables In-Reply-To: <044.64206ec8ce180cb0620df1ffe1482d34@localhost> References: <044.64206ec8ce180cb0620df1ffe1482d34@localhost> Message-ID: <053.23f3578264ac37f29a692704df6083ed@localhost> #3587: provide a cross-platform way to set environment variables -------------------------------------+-------------------------------------- Reporter: shahn | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.10.4 Severity: minor | Resolution: Keywords: environment variable | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -------------------------------------+-------------------------------------- Changes (by simonmar): * difficulty: => Unknown * type: task => proposal * milestone: => Not GHC Comment: Please submit a library proposal: [http://www.haskell.org/haskellwiki/Library_submissions]. I'll leave the ticket here so you don't have to create a new one. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 15 07:43:29 2009 From: trac at galois.com (GHC) Date: Thu Oct 15 07:20:44 2009 Subject: [GHC] #3572: Empty types are prettyprinted with trailing "=" In-Reply-To: <045.a913ce8d59080e93f1d9fb9091a05960@localhost> References: <045.a913ce8d59080e93f1d9fb9091a05960@localhost> Message-ID: <054.ab3cf5f554833a849edb29ebd9ebd479@localhost> #3572: Empty types are prettyprinted with trailing "=" ---------------------------------+------------------------------------------ Reporter: FSalad | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 6.10.4 Severity: trivial | Resolution: Keywords: | Difficulty: Unknown Testcase: th/T3572 | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * testcase: => th/T3572 * difficulty: => Unknown * type: bug => merge * owner: => igloo Comment: Thanks! I pushed an identical patch before seeing yours. {{{ Thu Oct 15 12:41:04 BST 2009 simonpj@microsoft.com * Fix Trac #3572 (pls merge) M ./Language/Haskell/TH/Ppr.hs -1 +1 }}} Ian pls merge to 6.12. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 15 07:48:47 2009 From: trac at galois.com (GHC) Date: Thu Oct 15 07:25:58 2009 Subject: [GHC] #3263: Warnings for monadic values not used In-Reply-To: <051.2ba77802c306560898b377ae21be4ade@localhost> References: <051.2ba77802c306560898b377ae21be4ade@localhost> Message-ID: <060.256a0ccce2191a133c5a7d8009f827d8@localhost> #3263: Warnings for monadic values not used -----------------------------------+---------------------------------------- Reporter: NeilMitchell | Owner: igloo Type: merge | Status: reopened Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: ghci/scripts/T3263 | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------+---------------------------------------- Changes (by simonpj): * testcase: => ghci/scripts/T3263 * status: closed => reopened * resolution: fixed => * type: feature request => merge Comment: Good point. Fixed by: {{{ Thu Oct 15 12:44:37 BST 2009 simonpj@microsoft.com * Fix Trac #3263: don't print Hpc tick stuff unless -dppr-debug is on In general, when pretty-printing HsSyn, we omit the extra info added by GHC (type appplications and abstractions, etc) when printing stuff for the user. But we weren't applying that guideline to the HsTick stuff for Hpc. This patch adds the necessary tests. M ./compiler/hsSyn/HsBinds.lhs -13 +23 M ./compiler/hsSyn/HsExpr.lhs -8 +11 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 15 07:49:09 2009 From: trac at galois.com (GHC) Date: Thu Oct 15 07:26:19 2009 Subject: [GHC] #3263: Warnings for monadic values not used In-Reply-To: <051.2ba77802c306560898b377ae21be4ade@localhost> References: <051.2ba77802c306560898b377ae21be4ade@localhost> Message-ID: <060.d7079d135dbd60c9062597acc23b01f7@localhost> #3263: Warnings for monadic values not used -----------------------------------+---------------------------------------- Reporter: NeilMitchell | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: ghci/scripts/T3263 | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------+---------------------------------------- Changes (by simonpj): * status: reopened => new Comment: Ian pls merge to 6.12 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 15 07:53:00 2009 From: trac at galois.com (GHC) Date: Thu Oct 15 07:30:11 2009 Subject: [GHC] #3588: ghc -M should emit dependencies on CPP headers Message-ID: <047.8807ddae9fc52a8b9ff0f721787e425c@localhost> #3588: ghc -M should emit dependencies on CPP headers -------------------------------+-------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14 branch Component: Compiler | Version: 6.10.4 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- When using CPP, ghc -M should emit dependencies on header files that are `#included` into Haskell source code. It could do this by running `gcc -M`, perhaps. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 15 07:56:45 2009 From: trac at galois.com (GHC) Date: Thu Oct 15 07:33:56 2009 Subject: [GHC] #3589: Recompilation checker doesn't take into account CPP headers Message-ID: <047.5d4e10ff362a5a53fb60efa7fea2fd88@localhost> #3589: Recompilation checker doesn't take into account CPP headers -------------------------------+-------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14 branch Component: Compiler | Version: 6.10.4 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- When using CPP, the recompilation checker doesn't check the date on any header files that might be `#included`. We already have to run CPP on the file anyway in order to extract the imports and module name, so we might as find the `#included` files and check their modification times. See also #3588. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 15 08:33:00 2009 From: trac at galois.com (GHC) Date: Thu Oct 15 08:10:18 2009 Subject: [GHC] #959: Debugging info(?) leaks out: "Urk! Inventing strangely-kinded void TyCon" In-Reply-To: <044.3bf1d700079be84fe2d08b3da62c85d3@localhost> References: <044.3bf1d700079be84fe2d08b3da62c85d3@localhost> Message-ID: <053.a4ec30e27f6dded092dfcfe21ede444f@localhost> #959: Debugging info(?) leaks out: "Urk! Inventing strangely-kinded void TyCon" ----------------------------------------+----------------------------------- Reporter: igloo | Owner: Type: bug | Status: closed Priority: normal | Milestone: _|_ Component: Compiler (Type checker) | Version: 6.6 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: tcfail188 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------+----------------------------------- Changes (by simonpj): * status: new => closed * cc: Ben.Lippmeier@anu.edu.au (added) * resolution: => fixed Comment: I finally got around to fixing this {{{ Thu Oct 15 13:28:10 BST 2009 simonpj@microsoft.com * Fix Trac #959: a long-standing bug in instantiating otherwise-unbound type variables DO NOT MERGE TO GHC 6.12 branch (Reason: interface file format change.) The typechecker needs to instantiate otherwise-unconstraint type variables to an appropriately-kinded constant type, but we didn't have a supply of arbitrarily-kinded tycons for this purpose. Now we do. The details are described in Note [Any types] in TysPrim. The fundamental change is that there is a new sort of TyCon, namely AnyTyCon, defined in TyCon. There's a small change to interface-file binary format, because the new AnyTyCons have to be serialised. I tided up the handling of uniques a bit too, so that mkUnique is not exported, so that we can see all the different name spaces in one module. M ./compiler/basicTypes/OccName.lhs -10 +11 M ./compiler/basicTypes/Unique.lhs -4 +20 M ./compiler/deSugar/DsBinds.lhs -25 +23 M ./compiler/iface/BinIface.hs -1 +5 M ./compiler/iface/IfaceType.lhs -11 +22 M ./compiler/iface/TcIface.lhs +3 M ./compiler/nativeGen/Reg.hs -2 +2 M ./compiler/nativeGen/RegAlloc/Graph/ArchBase.hs -2 +2 M ./compiler/nativeGen/RegAlloc/Graph/SpillClean.hs -3 +3 M ./compiler/nativeGen/RegClass.hs -3 +3 M ./compiler/prelude/PrelNames.lhs -5 +3 M ./compiler/prelude/TysPrim.lhs -56 +120 M ./compiler/prelude/TysWiredIn.lhs -4 +2 M ./compiler/stgSyn/CoreToStg.lhs -1 +1 M ./compiler/typecheck/TcHsSyn.lhs -75 +1 M ./compiler/types/TyCon.lhs -16 +44 M ./compiler/types/TypeRep.lhs -8 +5 M ./compiler/vectorise/VectUtils.hs -1 +1 }}} '''IAN''': Don't merge to the 6.12 branch, because it changes interface file formats slightly. tcfail188 now compiles ok. '''BEN''': as part of the `mkUnique` tidy-up I moved a few lines from `nativeGen` to `Unique`. Can you just review the patch (the bits affecting nativeGen are only a few lines) to check it's ok. It seems to validate. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 15 08:47:20 2009 From: trac at galois.com (GHC) Date: Thu Oct 15 08:24:33 2009 Subject: [GHC] #3580: ghc-6.12.1rc1 on Nix: ghci does not work In-Reply-To: <047.87fc0e02fbdf92a08407bcd8577f2851@localhost> References: <047.87fc0e02fbdf92a08407bcd8577f2851@localhost> Message-ID: <056.4a20e30bd402f35e21b99c59030a4fec@localhost> #3580: ghc-6.12.1rc1 on Nix: ghci does not work ------------------------------+--------------------------------------------- Reporter: kosmikus | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: normal | Resolution: invalid Keywords: | Testcase: Os: Unknown/Multiple | Architecture: x86 ------------------------------+--------------------------------------------- Changes (by kosmikus): * status: new => closed * resolution: => invalid Comment: Ok, I have been able to fix the problem. It was caused by Nix automatically stripping {{{.o}}} files (with flag {{{-S}}}) on installation. Apparently, calling {{{strip -S}}} on {{{HSffi.o}}} results in a file that can no longer be loaded by GHCi. I find that curious, but it's easy enough to fix by not calling {{{strip}}} on that file. I can now report that ghc-6.12.1rc1 works for me. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 15 11:10:58 2009 From: trac at galois.com (GHC) Date: Thu Oct 15 10:48:17 2009 Subject: [GHC] #959: Debugging info(?) leaks out: "Urk! Inventing strangely-kinded void TyCon" In-Reply-To: <044.3bf1d700079be84fe2d08b3da62c85d3@localhost> References: <044.3bf1d700079be84fe2d08b3da62c85d3@localhost> Message-ID: <053.3bce4824cf8847ef40a9da3d7965aa60@localhost> #959: Debugging info(?) leaks out: "Urk! Inventing strangely-kinded void TyCon" ----------------------------------------+----------------------------------- Reporter: igloo | Owner: Type: bug | Status: closed Priority: normal | Milestone: _|_ Component: Compiler (Type checker) | Version: 6.6 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: tcfail188 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------+----------------------------------- Changes (by guest): * cc: kfrdbs@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 15 11:34:11 2009 From: trac at galois.com (GHC) Date: Thu Oct 15 11:11:21 2009 Subject: [GHC] #3586: Initialisation of unboxed arrays is too slow In-Reply-To: <046.d37b803347b32ce78018550b0e0c0244@localhost> References: <046.d37b803347b32ce78018550b0e0c0244@localhost> Message-ID: <055.a418a3ce2f747cf6b627c5e2bf2d55a0@localhost> #3586: Initialisation of unboxed arrays is too slow -----------------------------------------+---------------------------------- Reporter: simonpj | Owner: Type: run-time performance bug | Status: new Priority: high | Milestone: 6.12.2 Component: libraries (other) | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Comment (by dons): Assuming int-e's patch is corret, that looks like a good approach. Float out the initializer, and switch to forM_, yielding proper specialization. Who can go ahead and apply the patch? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 15 15:33:18 2009 From: trac at galois.com (GHC) Date: Thu Oct 15 15:10:29 2009 Subject: [GHC] #3590: panic (the impossible happened) when compiling with -O2 Message-ID: <046.ec4c1739f3567725a37e4c4cfcc214a3@localhost> #3590: panic (the impossible happened) when compiling with -O2 --------------------+------------------------------------------------------- Reporter: yairchu | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: MacOS X | Architecture: x86 --------------------+------------------------------------------------------- when compiling the attached program with -O2 I get the following error: {{{ [1 of 1] Compiling Main ( crashTest.hs, crashTest.o ) ghc: panic! (the 'impossible' happened) (GHC version 6.10.4 for i386-apple-darwin): Coercion.splitCoercionKindOf ghc-prim:GHC.Prim.left{(w) tc 34B} (ghc-prim:GHC.Prim.trans{(w) tc 34y} (List-0.3:Data.List.Class.ItemM{tc r28} (List-0.3:Control.Monad.ListT.ListT{tc r34} (ghc-prim:GHC.Prim.(->){(w) tc 3D} a{tv ayS} [sk])) (List-0.3:Control.Monad.ListT.ListT{tc r34} (ghc-prim:GHC.Prim.(->){(w) tc 3D} a{tv ayS} [sk]) c{tv ayR} [sk])) (ghc-prim:GHC.Prim.(->){(w) tc 3D} a{tv ayS} [sk] List-0.3:Control.Monad.ListT.:CoF:R5ItemM{tc r29} List-0.3:Control.Monad.ListT.ListT{tc r34} (ghc- prim:GHC.Prim.(->){(w) tc 3D} a{tv ayS} [sk]) c{tv ayR} [sk])) List-0.3:Data.List.Class.ItemM{tc r28} (List-0.3:Control.Monad.ListT.ListT{tc r34} (ghc-prim:GHC.Prim.(->){(w) tc 3D} a{tv ayS} [sk])) ~ ghc-prim:GHC.Prim.(->){(w) tc 3D} a{tv ayS} [sk] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} When compiling without -O2, it works. I am using TypeFamilies (for the List class) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 15 18:09:22 2009 From: trac at galois.com (GHC) Date: Thu Oct 15 17:47:43 2009 Subject: [GHC] #2965: GHC on OS X does not compile 64-bit In-Reply-To: <045.2214e7d1fe4dd43486128c197fdb9227@localhost> References: <045.2214e7d1fe4dd43486128c197fdb9227@localhost> Message-ID: <054.1b4bff5a0635fb15ba687f139ae05e03@localhost> #2965: GHC on OS X does not compile 64-bit --------------------------------+------------------------------------------- Reporter: Axman6 | Owner: thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: Severity: normal | Resolution: Keywords: 64bit | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86_64 (amd64) | --------------------------------+------------------------------------------- Changes (by tty645): * cc: adhocrocker@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 15 20:22:30 2009 From: trac at galois.com (GHC) Date: Thu Oct 15 19:59:38 2009 Subject: [GHC] #3591: A working program reports <> when compiled with -O Message-ID: <047.0475174377feb22d7d802e2794561872@localhost> #3591: A working program reports <> when compiled with -O ---------------------+------------------------------------------------------ Reporter: blamario | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86_64 (amd64) ---------------------+------------------------------------------------------ If the attached module Trampoline.hs is compiled with no optimizations it works: {{{ $ ghc --make Trampoline.hs [1 of 1] Compiling Main ( Trampoline.hs, Trampoline.o ) Linking Trampoline ... $ ./Trampoline ... ((5,2),(1,2,6)) $ }}} With optimizations on, it hangs: {{{ $ ghc --make Trampoline.hs -O [1 of 1] Compiling Main ( Trampoline.hs, Trampoline.o ) Linking Trampoline ... $ ./Trampoline bounce start bounce end liftOut inject suspend Trampoline: <> }}} That doesn't seem right. Oh, GHCi runs it with no problem as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 15 23:01:09 2009 From: trac at galois.com (GHC) Date: Thu Oct 15 22:38:31 2009 Subject: [GHC] #2972: ppc ghci segfaults at startup In-Reply-To: <046.36c84703d6f462149fdd781bf29492ec@localhost> References: <046.36c84703d6f462149fdd781bf29492ec@localhost> Message-ID: <055.59539cf1dbe17ca6e2965f50b49cf9ee@localhost> #2972: ppc ghci segfaults at startup ------------------------+--------------------------------------------------- Reporter: cemeyer | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: GHCi | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: powerpc | ------------------------+--------------------------------------------------- Changes (by juhpetersen): * version: 6.10.1 => 6.10.4 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 15 23:00:53 2009 From: trac at galois.com (GHC) Date: Thu Oct 15 22:38:36 2009 Subject: [GHC] #2972: ppc ghci segfaults at startup In-Reply-To: <046.36c84703d6f462149fdd781bf29492ec@localhost> References: <046.36c84703d6f462149fdd781bf29492ec@localhost> Message-ID: <055.b36f0e0fbb52780ffff09552e62c311f@localhost> #2972: ppc ghci segfaults at startup ------------------------+--------------------------------------------------- Reporter: cemeyer | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: powerpc | ------------------------+--------------------------------------------------- Changes (by juhpetersen): * summary: GHCi broken in GHC 6.10.1 => ppc ghci segfaults at startup Comment: Just to update that still happens with 6.10.4 on ppc. #7 0x0fbfc4fc in generic_start_main (main=, argc=, ubp_av=, auxvec=, init=, fini=, rtld_fini=, stack_end=) at ../csu/libc-start.c:220 #8 0x0fbfc6a0 in __libc_start_main (argc=, ubp_av=, ubp_ev=, auxvec=, rtld_fini=, stinfo=, stack_on_entry=) at ../sysdeps/unix/sysv/linux/powerpc/libc-start.c:92 is about all from gdb (without ghc debuginfo). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 16 05:30:55 2009 From: trac at galois.com (GHC) Date: Fri Oct 16 05:08:07 2009 Subject: [GHC] #2273: inlining defeats seq In-Reply-To: <044.9c3223a55b4d3223b10ccf35be7e7d4f@localhost> References: <044.9c3223a55b4d3223b10ccf35be7e7d4f@localhost> Message-ID: <053.85eb986acb2e630acbe7c8821f2cd6f3@localhost> #2273: inlining defeats seq ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: merge | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonpj): Note to self. I think the Right Solution is simply not to inline things that are "cheap", but only things that are "values". This is easy to achieve: {{{ hunk ./compiler/coreSyn/CoreUnfold.lhs 637 - yes_or_no = active_inline && is_cheap && consider_safe + yes_or_no = active_inline && is_value && consider_safe }}} But it's not quite so easy: this change makes allocation go up in a couple of programs, and runtime goes up quite a bit. (We'd need to double-check that the runtime figures are right.) {{{ -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed -------------------------------------------------------------------------------- fulsom -2.8% +17.2% +39.1% +39.8% puzzle +1.0% +8.1% +15.2% +18.6% atom +0.7% +7.3% +55.7% +64.7% circsim +0.5% -0.0% +35.2% +37.1% compress2 +0.7% -0.0% +25.8% +29.9% lcss +0.7% -0.0% +42.8% +48.1% -------------------------------------------------------------------------------- Min -2.8% -4.3% -4.8% -10.0% Max +1.0% +17.2% +55.7% +64.7% Geometric Mean +0.5% +0.5% +18.2% +21.4% }}} So, annoyingly, more investigation required. I can't do it today, so I'm recording the breadcrumbs here for when I get back to it. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 16 05:47:31 2009 From: trac at galois.com (GHC) Date: Fri Oct 16 05:24:40 2009 Subject: [GHC] #3586: Initialisation of unboxed arrays is too slow In-Reply-To: <046.d37b803347b32ce78018550b0e0c0244@localhost> References: <046.d37b803347b32ce78018550b0e0c0244@localhost> Message-ID: <055.5d2c980f73a2c329e36364e96cb84d55@localhost> #3586: Initialisation of unboxed arrays is too slow -----------------------------------------+---------------------------------- Reporter: simonpj | Owner: Type: run-time performance bug | Status: new Priority: high | Milestone: 6.12.2 Component: libraries (other) | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Comment (by simonpj): Concerning int-e's patch, why do you say that {{{ }}} That should not happen. I've just tried it with this module: {{{ module Seq where import Control.Monad import Data.Array.Base newArrayImplSeq (l,u) initialValue = do let n = safeRangeSize (l,u) marr <- unsafeNewArray_ (l,u) sequence_ [unsafeWrite marr i initialValue | i <- [0 .. n - 1]] return marr newArrayImplFor (l,u) initialValue = do let n = safeRangeSize (l,u) marr <- unsafeNewArray_ (l,u) forM_ [0 .. n - 1] (\i -> unsafeWrite marr i initialValue) return marr doSeq :: Monad m => (Int -> m ()) -> Int -> m () doSeq f n = sequence_ [f i | i <- [1..n]] doFor :: Monad m => (Int -> m ()) -> Int -> m () doFor f n = forM_ [1..n] f }}} Both versions yield identical code. So why do you think one is better than t'other? Secondly, it's absolutely true that GHC's current inlining of default methods is flaky, but that is something I'm fixing as part of a long running project called "the never-ending INLINE patch". When I'm done, your work-around shouldn't be ncessary (although it's not harmful). Stay tuned. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 16 08:23:55 2009 From: trac at galois.com (GHC) Date: Fri Oct 16 08:01:15 2009 Subject: [GHC] #3592: ghc: panic! on overloaded type synonym Message-ID: <044.9fe7c2d56e2221c8747528de7b8c0b31@localhost> #3592: ghc: panic! on overloaded type synonym --------------------+------------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.3 | Severity: normal Keywords: | Testcase: Os: MacOS X | Architecture: x86 --------------------+------------------------------------------------------- Consider the following program: {{{ module Main where type T a = Show a => a f :: T a -> String f = show }}} Compiling this with GHC 6.10.3 and -fglasgow-exts gives: {{{ [1 of 1] Compiling Main ( Test.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 6.10.3 for i386-apple-darwin): TcTyFuns.flattenType: unexpected PredType }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 16 10:56:44 2009 From: trac at galois.com (GHC) Date: Fri Oct 16 10:33:57 2009 Subject: [GHC] #3593: Where has readline gone? Message-ID: <045.76493d1c4c1b7c04e29d1d3c65eb4fb8@localhost> #3593: Where has readline gone? -----------------------------+---------------------------------------------- Reporter: spivey | Owner: Type: bug | Status: new Priority: normal | Component: Package system Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- In going from 6.8.x to 6.10.x, I find that Readline has dissappeared. Apparently, it was replaced by Editline for a short time, and now by Haskeline. But the standard installation doesn't seem to have either one installed as a library I can use. Can we have one of them back, please? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 16 11:36:55 2009 From: trac at galois.com (GHC) Date: Fri Oct 16 11:14:02 2009 Subject: [GHC] #3591: A working program reports <> when compiled with -O In-Reply-To: <047.0475174377feb22d7d802e2794561872@localhost> References: <047.0475174377feb22d7d802e2794561872@localhost> Message-ID: <056.20568bb769a92c1716d7010343c19293@localhost> #3591: A working program reports <> when compiled with -O -------------------------------+-------------------------------------------- Reporter: blamario | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by simonpj): * owner: => simonpj * difficulty: => Unknown Comment: Glarp. Great bug. It exposes a long-standing bogosity in the specialiser. I have spent most of today tracking it down and fixing it. How embarrassing. Anyway I'll take it. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 16 11:53:18 2009 From: trac at galois.com (GHC) Date: Fri Oct 16 11:30:25 2009 Subject: [GHC] #3590: panic (the impossible happened) when compiling with -O2 In-Reply-To: <046.ec4c1739f3567725a37e4c4cfcc214a3@localhost> References: <046.ec4c1739f3567725a37e4c4cfcc214a3@localhost> Message-ID: <055.497b16721137292df089a823ffb5a723@localhost> #3590: panic (the impossible happened) when compiling with -O2 -------------------------+-------------------------------------------------- Reporter: yairchu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by simonpj): * difficulty: => Unknown Comment: To avoid using the List package, I just copied the relevant code into the file. I get the attached file T3590.hs. But it doesn't compile, with multiple type errors. Can you elucidate? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 16 12:18:10 2009 From: trac at galois.com (GHC) Date: Fri Oct 16 11:55:17 2009 Subject: [GHC] #3590: panic (the impossible happened) when compiling with -O2 In-Reply-To: <046.ec4c1739f3567725a37e4c4cfcc214a3@localhost> References: <046.ec4c1739f3567725a37e4c4cfcc214a3@localhost> Message-ID: <055.7290a756be082b3dcb4415f5bb2745bc@localhost> #3590: panic (the impossible happened) when compiling with -O2 -------------------------+-------------------------------------------------- Reporter: yairchu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------+-------------------------------------------------- Comment (by yairchu): T3590.hs was lacking required instances for ListT. I added them and now it works. see attached standalone.hs re: elucidate. just learned a new word :) Yair -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 16 13:13:40 2009 From: trac at galois.com (GHC) Date: Fri Oct 16 12:50:50 2009 Subject: [GHC] #3586: Initialisation of unboxed arrays is too slow In-Reply-To: <046.d37b803347b32ce78018550b0e0c0244@localhost> References: <046.d37b803347b32ce78018550b0e0c0244@localhost> Message-ID: <055.8495935442b0704bf89d2e23ac7158ea@localhost> #3586: Initialisation of unboxed arrays is too slow -----------------------------------------+---------------------------------- Reporter: simonpj | Owner: Type: run-time performance bug | Status: new Priority: high | Milestone: 6.12.2 Component: libraries (other) | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Comment (by int-e): Replying to [comment:12 simonpj]: > Both versions yield identical code. So why do you think one is better than t'other? I'm afraid I must have imagined that. In any case, I'm unable to reproduce my measurements although I remember a distinct decrease in runtime with a variant of dons' testcase, from 0.090 to 0.060 seconds, with multiple measurements. Perhaps I mixed up user and total execution time? Oh well. So that part of the patch should be left out. On to more serious matters - the explicitely inlined worker trick works for ghc 6.10.4, but is not sufficient for the 6.12 RC, so that will need a different fix. One idea that works is to add {{{ newArray = newArrayImpl }}} to all {{{MArray (STUArray ...) ...}}} instances. Of course getting inlining for default methods to work would be preferable. In fact, for default method it would be nice to have a special form of the SPECIALIZE pragma as well, one that duplicates the definition for all instances and optimizes it in that context. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 16 14:02:31 2009 From: trac at galois.com (GHC) Date: Fri Oct 16 13:39:38 2009 Subject: [GHC] #3590: panic (the impossible happened) when compiling with -O2 In-Reply-To: <046.ec4c1739f3567725a37e4c4cfcc214a3@localhost> References: <046.ec4c1739f3567725a37e4c4cfcc214a3@localhost> Message-ID: <055.adcec2e7e8ff63ed21a47b6ba74bdc8e@localhost> #3590: panic (the impossible happened) when compiling with -O2 -------------------------+-------------------------------------------------- Reporter: yairchu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------+-------------------------------------------------- Comment (by yairchu): see attached compact.hs for a much shorter program replicating the same error -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 16 17:20:37 2009 From: trac at galois.com (GHC) Date: Fri Oct 16 16:57:44 2009 Subject: [GHC] #3586: Initialisation of unboxed arrays is too slow In-Reply-To: <046.d37b803347b32ce78018550b0e0c0244@localhost> References: <046.d37b803347b32ce78018550b0e0c0244@localhost> Message-ID: <055.3269ee3166c0b33a014403628547959c@localhost> #3586: Initialisation of unboxed arrays is too slow -----------------------------------------+---------------------------------- Reporter: simonpj | Owner: Type: run-time performance bug | Status: new Priority: high | Milestone: 6.12.2 Component: libraries (other) | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Comment (by Philippos): I have a genetic programming code that I am trying to translate to Haskell. I applied suggestions received here to a slightly more realistic situation, where array ar contains a tree population. Function fn updates the array randomly, in order to simulate crossover and mutation of individuals of the population. The result seems to be very good, i.e., Haskell is from 3 to 5 times slower than Clean. I would rather not use unsafe features. Therefore, I will appreciate if someone substitute something else for (unsafePerformIO (randomList (1, 2000000))). I wonder whether a member of this forum could make the gap between Clean and Haskell even smaller. Here are the programs: {{{ -- Haskell version data Op = AND | OR | NOT; data Tree= L Double | T Op [Tree] main = print $ runST (do arr <- newArray (1,2000000) (L 0.0) :: ST s (STArray s Int Tree) go arr 2000000 0.0 (unsafePerformIO (randomList (1, 2000000)))) go :: STArray s Int Tree -> Int -> Double -> [Int] -> ST s Double go a i acc (x1:x2:xs) | i < 1 = return acc | otherwise=do b <- readArray a x1 writeArray a x2 (setDouble ((getDouble b)+3.0)) c <- readArray a i go a (i-1) (acc+ (getDouble c)) xs -- What I really need is a random index in Haskell. getDouble (L r)= r getDouble _ = 0.0 setDouble r= L r randomList r = do g <- getStdGen return $ randomRs r g -- ghc -O2 --make bingo.hs -fvia-C -optc-O3 -optc-msse3 -o bingo.exe -- bingo.exe +RTS -sstderr -K100m -H100 }}} {{{ module boxed; import StdEnv, MersenneTwister, StdTime; ::Op = AND | OR | NOT; ::Tree= L Real | T Op [Tree]; fn i a acc xs | i<1 = acc; fn i a acc [x1:x2:xs] # (i1, i2)= (ri x1, ri x2); # (b, a)= a![i1]; # a= {a&[i2]= setDouble ((getDouble b)+3.0)}; # (c, a)= a![i]; = fn (i-1) a ((getDouble c)+acc) xs; ri x= (abs x) rem 2000000; getDouble (L r)= r; getDouble _ = 0.0; setDouble r= L r; Start w # (ct,w)= getCurrentTime w; seed= 1+ct.seconds; xs= genRandInt seed; = fn (2000000-1) vt 0.0 xs; where{ vt:: *{Tree}; vt = createArray 2000000 (L 137.0);} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 16 17:58:21 2009 From: trac at galois.com (GHC) Date: Fri Oct 16 17:35:27 2009 Subject: [GHC] #3586: Initialisation of unboxed arrays is too slow In-Reply-To: <046.d37b803347b32ce78018550b0e0c0244@localhost> References: <046.d37b803347b32ce78018550b0e0c0244@localhost> Message-ID: <055.7ef17222bb9e7d801c62fdb3d9898f82@localhost> #3586: Initialisation of unboxed arrays is too slow -----------------------------------------+---------------------------------- Reporter: simonpj | Owner: Type: run-time performance bug | Status: new Priority: high | Milestone: 6.12.2 Component: libraries (other) | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Comment (by dons): Hello Philippos, you should take up these general design questions on the haskell-cafe@haskell.org mailing list, not on the bug tracker. Some quick points: since you use the mersenne-twister in Clean, you should use it in Haskell too: http://hackage.haskell.org/package/mersenne-random. Also, you should never need to increase the stack size with the -K option. Finally, it is faster to thread around a seed to the random generator, than to generate the infinite list of randoms. Here's how I would translate your Clean program to Haskell: {{{ {-# LANGUAGE BangPatterns #-} {-# OPTIONS -funbox-strict-fields #-} -- -- Compile with: ghc -O2 -fvia-C -optc-O3 --make A.hs -- Run with : ./A +RTS -H200M -- -- $ time ./A +RTS -H200M -- 2.77000034e8 -- ./A +RTS -H200M 0.62s user 0.10s system 96% cpu 0.751 total -- import Control.Monad.ST import Control.Monad import Data.Array.ST import Data.Array.Base import System.Random.Mersenne data Op = And | Or | Not data Tree = L !Double | T !Op [Tree] main = do g <- getStdGen print $ runST $ do let l = 0 u = 2000000 - 1 vt <- unsafeNewArray_ (l,u) forM_ [l..u] $ \i -> unsafeWrite vt i (L 137) fn u vt 0 g fn :: Int -> STArray s Int Tree -> Double -> MTGen -> ST s Double fn i a !acc g | i < 1 = return acc fn i a acc g = do i1 <- ri `fmap` unsafeIOToST (random g) :: ST s Int i2 <- ri `fmap` unsafeIOToST (random g) :: ST s Int b <- a `readArray` i1 writeArray a i2 (set (get b + 3)) c <- a `readArray` i1 fn (i-1) a (get c + acc) g ri :: Int -> Int ri x = (abs x) `rem` 2000000 get :: Tree -> Double get (L r) = r get _ = 0.0 set :: Double -> Tree set r = L r }}} Your Haskell version completes for me in just over 2 minutes. The above Haskell version completes in 0.7s. I'd imagine this is very competitive with the Clean implementation? I give detailed instructions on how to compile this for best results. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 16 17:59:36 2009 From: trac at galois.com (GHC) Date: Fri Oct 16 17:36:42 2009 Subject: [GHC] #3586: Initialisation of unboxed arrays is too slow In-Reply-To: <046.d37b803347b32ce78018550b0e0c0244@localhost> References: <046.d37b803347b32ce78018550b0e0c0244@localhost> Message-ID: <055.9f5fb386d6e422623cad19d477c42247@localhost> #3586: Initialisation of unboxed arrays is too slow -----------------------------------------+---------------------------------- Reporter: simonpj | Owner: Type: run-time performance bug | Status: new Priority: high | Milestone: 6.12.2 Component: libraries (other) | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Comment (by dons): And how to run it: {{{ $ ghc A.hs -O2 -fvia-C -optc-O3 --make [1 of 1] Compiling Main ( A.hs, A.o ) Linking A ... $ time ./A +RTS -H200M 2.7700091e8 ./A +RTS -H200M 0.63s user 0.12s system 93% cpu 0.806 total }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 16 23:17:55 2009 From: trac at galois.com (GHC) Date: Fri Oct 16 22:55:01 2009 Subject: [GHC] #3586: Initialisation of unboxed arrays is too slow In-Reply-To: <046.d37b803347b32ce78018550b0e0c0244@localhost> References: <046.d37b803347b32ce78018550b0e0c0244@localhost> Message-ID: <055.51f0a9f6257cc7facd7969b3f1990969@localhost> #3586: Initialisation of unboxed arrays is too slow -----------------------------------------+---------------------------------- Reporter: simonpj | Owner: Type: run-time performance bug | Status: new Priority: high | Milestone: 6.12.2 Component: libraries (other) | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Comment (by dons): And an analysis by int-e of how different optimizations affects performance http://www.imn.htwk-leipzig.de/~felgenha/test3586/summary Worth a read to see why I went straight to the fast version. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 17 09:04:45 2009 From: trac at galois.com (GHC) Date: Sat Oct 17 08:41:50 2009 Subject: [GHC] #3594: ppc stage1 panic for --enable-shared Message-ID: <050.949f308a1cc216a980b2b9af5455bce4@localhost> #3594: ppc stage1 panic for --enable-shared ------------------------+--------------------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.12.0 RC1 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: powerpc ------------------------+--------------------------------------------------- Not sure if this is expected but ghc-6.12 panics on ppc when it starts to build shared libraries: {{{ /usr/bin/ar: creating libraries/haskeline/dist- install/build/libHShaskeline-0.6.2.1.a "inplace/bin/ghc-stage1" -fPIC -dynamic -H32m -O -package-name ghc- prim-0.2.0.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc- prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist- install/build/autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package rts-1.0 -package-name ghc-prim -XCPP -XMagicHash -XForeignFunctionInterface -XUnliftedFFITypes -XUnboxedTuples -XEmptyDataDecls -XNoImplicitPrelude -O2 -XGenerics -fno-warn-deprecated- flags -odir libraries/ghc-prim/dist-install/build -hidir libraries /ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist- install/build -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -c libraries/ghc- prim/./GHC/Generics.hs -o libraries/ghc-prim/dist- install/build/GHC/Generics.dyn_o ghc-stage1: panic! (the 'impossible' happened) (GHC version 6.12.0.20091010 for powerpc-unknown-linux): getRegisterReg-memory PicBaseReg Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/Generics.dyn_o] Error 1 make: *** [all] Error 2 }}} so reporting it here. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 17 14:35:04 2009 From: trac at galois.com (GHC) Date: Sat Oct 17 14:12:09 2009 Subject: [GHC] #3595: The forefathers of Haskell ... Message-ID: <044.9f2eda7b081b76311de605c5957ef198@localhost> #3595: The forefathers of Haskell ... -----------------------------+---------------------------------------------- Reporter: JohnD | Owner: Type: proposal | Status: new Priority: normal | Component: Build System Version: | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- 17 October 2009 I am something of a new face. I wish to introduce myself by doing what I can to make a contribution and so I am making a proposal. It would make sense before undertaking the project to determine whether or not it makes any sense with those who are better acquainted with Haskell and more specifically GHC, and are closer to the problem. Haskell is an expressive language. GHC is needed to build GHC as it is. Why not create a build system that does not rely on shell scripts and make files? We would have all the benefits of a type safe language, type inference and the like. It seems to me that the build system is a weak link. Since when is the software developer's time unimportant? Strike that, it makes me sound like I was born yesterday. :-) At one time the lack of a type system would have been regarded as an asset, less bureaucracy. Haskell has type inference. It wouldn't be a burden, it would be an asset. You get to find out if the build system is broken without having to learn the hard way and having wasted hours or days of your precious time on something that is silly. GHC produces better error messages and is better at catching mistakes. It furthermore has an interpreter. From a theoretical point of view that's everything. What came first the chicken or the egg? What came first was the interpreter, then came the chicken. So technically it isn't an interpreter--it's a translator! He he. Unix/GNU is a mature product. It's ancient as in stone age, but mature. Some things might be missed. I recently installed Windows Vista on my computer. As usual there is what they got wrong, but also all the things they got right. It will take time to get used to it. So I suppose I can relate to those who might oppose change. I made a investment becoming familiar with Windows XP. It was comfortable. Equally many of you are vested in the old way of doing things. It has been around for so long that no one questions it. What exactly is unique about make files that you can't do in any other language? Well, the syntax lends itself to the task. Why couldn't Prolog be used? With Prolog you don't always have an interactive environment. The forefathers of Haskell weren't short sited and understood the value of having both a compiler and interactive environment. Is it merely convenience and something that aids in debugging? or is there more to it? There is the Curry language which is based on Haskell and it is my understanding that some of the features of the Curry language are now GHC extensions. Make files are a poor man's Prolog whereas Prolog is the tool of aristocrats. If you take an objective look at the stone age tools, you will see something grotesque. It has to be survival of the fittest. It just isn't fit. It shouldn't survive. It would be wrong for it to survive. All that Haskell represents is what needs to survive. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 17 14:45:33 2009 From: trac at galois.com (GHC) Date: Sat Oct 17 14:22:39 2009 Subject: [GHC] #3595: The forefathers of Haskell ... In-Reply-To: <044.9f2eda7b081b76311de605c5957ef198@localhost> References: <044.9f2eda7b081b76311de605c5957ef198@localhost> Message-ID: <053.64412c5a449890407feaed512fd05615@localhost> #3595: The forefathers of Haskell ... ------------------------------+--------------------------------------------- Reporter: JohnD | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: Build System | Version: Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by JohnD): 17 October 2009 I am something of a new face. I wish to introduce myself by doing what I can to make a contribution and so I am making a proposal. It would make sense before undertaking the project to determine whether or not it makes any sense with those who are better acquainted with Haskell and more specifically GHC, and are closer to the problem. Haskell is an expressive language. GHC is needed to build GHC as it is. Why not create a build system that does not rely on shell scripts and make files? We would have all the benefits of a type safe language, type inference and the like. It seems to me that the build system is a weak link. Since when is the software developer's time unimportant? Strike that, it makes me sound like I was born yesterday. :-) At one time the lack of a type system would have been regarded as an asset, less bureaucracy. Haskell has type inference. It wouldn't be a burden, it would be an asset. You get to find out if the build system is broken without having to learn the hard way and having wasted hours or days of your precious time on something that is silly. GHC produces better error messages and is better at catching mistakes. It furthermore has an interpreter. From a theoretical point of view that's everything. What came first the chicken or the egg? What came first was the interpreter, then came the chicken. So technically it isn't an interpreter--it's a translator! He he. Unix/GNU is a mature product. It's ancient as in stone age, but mature. Some things might be missed. I recently installed Windows Vista on my computer. As usual there is what they got wrong, but also all the things they got right. It will take time to get used to it. So I suppose I can relate to those who might oppose change. I made a investment becoming familiar with Windows XP. It was comfortable. Equally many of you are vested in the old way of doing things. It has been around for so long that no one questions it. What exactly is unique about make files that you can't do in any other language? Well, the syntax lends itself to the task. Why couldn't Prolog be used? With Prolog you don't always have an interactive environment. The forefathers of Haskell weren't short sighted and understood the value of having both a compiler and interactive environment. Is it merely convenience and something that aids in debugging? or is there more to it? There is the Curry language which is based on Haskell and it is my understanding that some of the features of the Curry language are now GHC extensions. Make files are a poor man's Prolog whereas Prolog is the tool of aristocrats. If you take an objective look at the stone age tools, you will see something grotesque. It has to be survival of the fittest. It just isn't fit. It shouldn't survive. It would be wrong for it to survive. All that Haskell represents is what needs to survive. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 17 17:13:43 2009 From: trac at galois.com (GHC) Date: Sat Oct 17 16:50:57 2009 Subject: [GHC] #3596: getOptions'.parseLanguage(1) went past eof token Message-ID: <049.62fba1fe2701e51d41ed452c7c76c4d6@localhost> #3596: getOptions'.parseLanguage(1) went past eof token -----------------------------+---------------------------------------------- Reporter: Paczesiowa | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Parser) Version: 6.10.4 | Severity: minor Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- this (19char) "code" crashes ghc-6.10.4: {{{ {-#LANGUAGE CPP #-} }}} ghc: panic! (the 'impossible' happened) (GHC version 6.10.4 for i386-unknown-linux): getOptions'.parseLanguage(1) went past eof token -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 18 06:46:45 2009 From: trac at galois.com (GHC) Date: Sun Oct 18 06:23:50 2009 Subject: [GHC] #959: Debugging info(?) leaks out: "Urk! Inventing strangely-kinded void TyCon" In-Reply-To: <044.3bf1d700079be84fe2d08b3da62c85d3@localhost> References: <044.3bf1d700079be84fe2d08b3da62c85d3@localhost> Message-ID: <053.c1cd8a32768cd41062816c09f64fe965@localhost> #959: Debugging info(?) leaks out: "Urk! Inventing strangely-kinded void TyCon" ----------------------------------------+----------------------------------- Reporter: igloo | Owner: Type: bug | Status: closed Priority: normal | Milestone: _|_ Component: Compiler (Type checker) | Version: 6.6 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: tcfail188 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------+----------------------------------- Comment (by benl): Looks ok to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 19 20:43:36 2009 From: trac at galois.com (GHC) Date: Mon Oct 19 20:20:33 2009 Subject: [GHC] #3597: trying to build ghc 6.10.4 from src tarball: haddock: Can't find package.conf Message-ID: <044.585f719d9b9b61e199c03c9c4cb510dc@localhost> #3597: trying to build ghc 6.10.4 from src tarball: haddock: Can't find package.conf -------------------+-------------------------------------------------------- Reporter: zooko | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86 -------------------+-------------------------------------------------------- Folks: Trying to build from the ghc-6.10.4 source tarball on Ubuntu Hardy i686, the "make" step ends with: {{{ Preprocessing library terminfo-0.3.1... Running Haddock for terminfo-0.3.1... Warning: The documentation for the following packages are not installed. No links will be generated to these packages: rts-1.0 Documentation created: dist/doc/html/terminfo/index.html if ifBuildable/ifBuildable /home/zooko/playground/ghc/ghc-6.10.4/packages haskeline; then \ cd haskeline && /home/zooko/playground/ghc/ghc-6.10.4/libraries /cabal-bin /usr/bin/ghc /home/zooko/playground/ghc/ghc-6.10.4/libraries/bootstrapping.conf 1.6.0.3 haddock --html-location='../$pkg' \ --with- haddock=/home/zooko/playground/ghc/ghc-6.10.4/utils/haddock/install- inplace/bin/haddock; \ fi ./Setup haddock --html-location=../$pkg --with- haddock=/home/zooko/playground/ghc/ghc-6.10.4/utils/haddock/install- inplace/bin/haddock Preprocessing library haskeline-0.6.1.5... Running Haddock for haskeline-0.6.1.5... Warning: The documentation for the following packages are not installed. No links will be generated to these packages: rts-1.0 Warning: System.Console.Haskeline.History: could not find link destinations for: System.Console.Haskeline.Monads.MonadState Warning: System.Console.Haskeline.MonadException: could not find link destinations for: System.Console.Haskeline.Backend.Terminfo.Draw System.Console.Haskeline.Backend.DumbTerm.DumbTerm GHC.IOBase.IOError GHC.IOBase.ioe_handle GHC.IOBase.ioe_type GHC.IOBase.ioe_location GHC.IOBase.ioe_description GHC.IOBase.ioe_filename Warning: System.Console.Haskeline: could not find link destinations for: System.Console.Haskeline.Monads.MonadState System.Console.Haskeline.Monads.MonadReader System.Console.Haskeline.Term.RunTerm Documentation created: dist/doc/html/haskeline/index.html sh gen_contents_index --inplace haddock: Can't find package.conf as /home/zooko/playground/ghc/ghc-6.10.4/utils/haddock/install-inplace/share /./inplace-datadir/package.conf make[2]: *** [doc] Error 1 make[2]: Leaving directory `/home/zooko/playground/ghc/ghc-6.10.4/libraries' make[1]: *** [stage2] Error 2 make[1]: Leaving directory `/home/zooko/playground/ghc/ghc-6.10.4' make: *** [bootstrap2] Error 2 real 43m43.936s user 36m2.463s sys 7m22.284s }}} Googling for this error message shows me: http://bugs.debian.org/cgi- bin/bugreport.cgi?bug=538157 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 19 21:48:41 2009 From: trac at galois.com (GHC) Date: Mon Oct 19 21:25:38 2009 Subject: [GHC] #3539: internal error: ASSERTION FAILED: file sm/Evac.c, line 368 In-Reply-To: <047.ce838bf90bf0705c86e1a5b8acf0114d@localhost> References: <047.ce838bf90bf0705c86e1a5b8acf0114d@localhost> Message-ID: <056.5cebf86181bff353c8f182ead1065981@localhost> #3539: internal error: ASSERTION FAILED: file sm/Evac.c, line 368 -------------------------------+-------------------------------------------- Reporter: elaforge | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Runtime System | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------------+-------------------------------------------- Comment (by elaforge): I'm just noting that this is still happening, with some regularity. I haven't updated because I don't have much more info yet. I tried disabling parallel GC with -g1 but it still happens. It usually happens at startup, but has happened while running as well. Further logging shows that on startup it's happening either in between marshal and a foreign call, or right after the foreign call (but before the foreign call starts running). I'm suspicious of marshaling code because it's an opportunity to stomp on memory, but of the pokes called, one is withCString and the two custom ones are simply lines of "(#poke Struct, attr) structp val" so nothing is obviously wrong there. My guess is something is stomping on memory in a way that the GC is tripping over it, so the stomper could have been a while in the past. There's a reasonable chance this is simply my own code since I do have to marshal structs for C, but this didn't show up on 6.10, so if it's not a ghc problem then it's something ghc does differently now that didn't used to trip over it. Clues on how to track this beyond putting in prints would be much appreciated! Since it's a GC thing, and occurs unpredictably, prints in my code probably won't help much anyway. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 20 03:14:46 2009 From: trac at galois.com (GHC) Date: Tue Oct 20 02:51:41 2009 Subject: [GHC] #3598: ghc-stage2 binary name confusing for users Message-ID: <050.0c9e6d70bcb7f6d45f2e902acf2e7ba0@localhost> #3598: ghc-stage2 binary name confusing for users -----------------------------+---------------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.12.0 RC1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- ghc-6.12.0.20091010 create a binary called $libdir/ghc-6.12.0.20091010/ghc-stage2 and then causing the program name ghc-stage2 to appear in compiler output and help etc which is confusing for users and a regression compared to 6.10.x IMHO. eg $ ghc ghc-stage2: no input files Usage: For basic information, try the `--help' option. $ ghc --help Usage: ghc-stage2 [command-line-options-and-input-files] To compile and link a complete Haskell program, run the compiler like so: ghc-stage2 --make Main : Alternatively, ghc-stage2 can be used to compile files individually. Each input file is guided through (some of the) possible phases of a compilation: : Given the above, here are some TYPICAL invocations of ghc-stage2: # compile a Haskell module to a .o file, optimising: % ghc-stage2 -c -O Foo.hs # link three .o files into an executable called "test": % ghc-stage2 -o test Foo.o Bar.o Baz.o # compile a Haskell module to C (a .hc file), using a bigger heap: % ghc-stage2 -C -H16m Foo.hs # compile Haskell-produced C (.hc) to assembly language: % ghc-stage2 -S Foo.hc etc I think either the output text should be changed or ghc-stage2 renamed to ghc. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 20 03:17:24 2009 From: trac at galois.com (GHC) Date: Tue Oct 20 02:54:19 2009 Subject: [GHC] #3598: ghc-stage2 binary name confusing for users In-Reply-To: <050.0c9e6d70bcb7f6d45f2e902acf2e7ba0@localhost> References: <050.0c9e6d70bcb7f6d45f2e902acf2e7ba0@localhost> Message-ID: <059.4e620676c3829ebdd25b5b7c2ba0525b@localhost> #3598: ghc-stage2 binary name confusing for users ------------------------------+--------------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.12.0 RC1 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by juhpetersen): Sorry keep forgeting trac using wiki markup... {{{ > $ ghc > ghc-stage2: no input files > Usage: For basic information, try the `--help' option. }}} {{{ > $ ghc --help > Usage: > > ghc-stage2 [command-line-options-and-input-files] > > To compile and link a complete Haskell program, run the compiler like > so: > > ghc-stage2 --make Main > : > Alternatively, ghc-stage2 can be used to compile files individually. Each > input file is guided through (some of the) possible phases of a > compilation: > : > Given the above, here are some TYPICAL invocations of ghc-stage2: > > # compile a Haskell module to a .o file, optimising: > % ghc-stage2 -c -O Foo.hs > # link three .o files into an executable called "test": > % ghc-stage2 -o test Foo.o Bar.o Baz.o > # compile a Haskell module to C (a .hc file), using a bigger heap: > % ghc-stage2 -C -H16m Foo.hs > # compile Haskell-produced C (.hc) to assembly language: > % ghc-stage2 -S Foo.hc }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 20 03:28:17 2009 From: trac at galois.com (GHC) Date: Tue Oct 20 03:05:13 2009 Subject: [GHC] #3599: haddock assumes $libdir/ghc-6.12.0.20091010/html/haddock.css Message-ID: <050.bebf295c09f55c5c53a40fbdb001dd53@localhost> #3599: haddock assumes $libdir/ghc-6.12.0.20091010/html/haddock.css ------------------------+--------------------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.12.0 RC1 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: Unknown/Multiple ------------------------+--------------------------------------------------- I build rc1 with docs living in /usr/share/doc/ghc/html but haddock seems to assume $libdir/ghc-$version/html: {{{ $ runghc Setup haddock Running Haddock for zlib-0.5.0.0... Preprocessing library zlib-0.5.0.0... Warning: The documentation for the following packages are not installed. No links will be generated to these packages: ffi-1.0, rts-1.0 haddock: internal Haddock or GHC error: /usr/lib64/ghc-6.12.0.20091010/html/haddock.css: openFile: does not exist (No such file or directory) $ rpm -ql ghc-doc | grep html/haddock.css /usr/share/doc/ghc/html/html/haddock.css }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 20 03:29:59 2009 From: trac at galois.com (GHC) Date: Tue Oct 20 03:06:56 2009 Subject: [GHC] #3600: Template Haskell mis-coverting empty list to empty string Message-ID: <046.8bf02926d3cbcc535bf50979d483cc00@localhost> #3600: Template Haskell mis-coverting empty list to empty string -------------------------------+-------------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Template Haskell | Version: 6.10.4 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- Antoine Latter aslatter@gmail.com writes: the program Demo.hs compiles on 6.10, but not on 6.12rc1. The output --ddump-splices for 6.10: {{{ Demo.hs:1:0: Demo.hs:1:0: Splicing declarations test ======> Demo.hs:6:2-5 myFunction[aLQ] = Demo2.testFun [] Ok, modules loaded: Demo2, Main. }}} In 6.12rc1: {{{ Demo.hs:1:0: Demo.hs:1:0: Splicing declarations test ======> Demo.hs:6:2-5 myFunction[aNX] = testFun "" Demo.hs:6:2: Couldn't match expected type `[Char]' against inferred type `Char' Expected type: [String] Inferred type: [Char] In the first argument of `testFun', namely `""' In the expression: testFun "" Failed, modules loaded: Demo2. }}} The code is short: {{{ ---------- Demo.hs --------------- {-# LANGUAGE TemplateHaskell #-} module Demo where import Demo2 $(test) ---------- Demo2.hs --------------- {-# LANGUAGE TemplateHaskell #-} module Demo2 where import Language.Haskell.TH test :: Q [Dec] test = do let args = [] :: [String] body = [| testFun args |] decNm <- newName "myFunction" (:[]) `fmap` funD decNm [clause [] (normalB body) []] testFun :: [String] -> String testFun _ = "hello" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 20 04:05:53 2009 From: trac at galois.com (GHC) Date: Tue Oct 20 03:42:48 2009 Subject: [GHC] #3600: Template Haskell mis-coverting empty list to empty string In-Reply-To: <046.8bf02926d3cbcc535bf50979d483cc00@localhost> References: <046.8bf02926d3cbcc535bf50979d483cc00@localhost> Message-ID: <055.4c05a5ff8a2ffb6a06908bfb94ca6ade@localhost> #3600: Template Haskell mis-coverting empty list to empty string ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.12.1 Component: Template Haskell | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: th/T3600 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * testcase: => th/T3600 * owner: => igloo * type: bug => merge * cc: aslatter@gmail.com (added) Comment: Fixed by {{{ Tue Oct 20 00:26:16 PDT 2009 simonpj@microsoft.com * Fix Trac #3600: Template Haskell bug in Convert This bug was introduced when I added an optimisation, described in Note [Converting strings] in Convert.lhs. It was treating *all* empty lists as strings, not just string-typed ones! The fix is easy. Pls MERGE to stable branch. M ./compiler/hsSyn/Convert.lhs -4 +10 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 20 04:10:33 2009 From: trac at galois.com (GHC) Date: Tue Oct 20 03:47:29 2009 Subject: [GHC] #3586: Initialisation of unboxed arrays is too slow In-Reply-To: <046.d37b803347b32ce78018550b0e0c0244@localhost> References: <046.d37b803347b32ce78018550b0e0c0244@localhost> Message-ID: <055.969d0010a6a1392080ff768a0fa4c5cb@localhost> #3586: Initialisation of unboxed arrays is too slow -----------------------------------------+---------------------------------- Reporter: simonpj | Owner: Type: run-time performance bug | Status: new Priority: high | Milestone: 6.12.2 Component: libraries (other) | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Comment (by simonpj): Replying to [comment:13 int-e]: > On to more serious matters - the explicitely inlined worker trick works for ghc 6.10.4, but is not sufficient for the 6.12 RC, so that will need a different fix. One idea that works is to add > {{{ > newArray = newArrayImpl > }}} > to all {{{MArray (STUArray ...) ...}}} instances. Of course getting inlining for default methods to work would be preferable. In fact, for default method it would be nice to have a special form of the SPECIALIZE pragma as well, one that duplicates the definition for all instances and optimizes it in that context. There's an underlying problem, which is the fragility of inlining of default methods. I'm in the midst of fixing that (the long-awaited INLINE patch), so I propose not to contort the libraries meanwhile. I'll ping when I commit the patch so that you can check that it does improve matters. The only downside is that this perf boost won't get into 6.12, but I think it's too bad. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 20 04:45:57 2009 From: trac at galois.com (GHC) Date: Tue Oct 20 04:22:56 2009 Subject: [GHC] #650: Improve interaction between mutable arrays and GC In-Reply-To: <047.44b951cd4b5aa8536d862412c8d86597@localhost> References: <047.44b951cd4b5aa8536d862412c8d86597@localhost> Message-ID: <056.1b79527d6c2e614c0bca3a7fb0c8249c@localhost> #650: Improve interaction between mutable arrays and GC -----------------------------------------+---------------------------------- Reporter: simonmar | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: _|_ Component: Runtime System | Version: 6.4.1 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Changes (by ganesh): * cc: ganesh (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 20 06:27:36 2009 From: trac at galois.com (GHC) Date: Tue Oct 20 06:04:33 2009 Subject: [GHC] #3595: The forefathers of Haskell ... In-Reply-To: <044.9f2eda7b081b76311de605c5957ef198@localhost> References: <044.9f2eda7b081b76311de605c5957ef198@localhost> Message-ID: <053.39111ebd6d4fa0c3d3c0d10290b4308c@localhost> #3595: The forefathers of Haskell ... ------------------------------+--------------------------------------------- Reporter: JohnD | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: Build System | Version: Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by JohnD): What I am going to do is create a web page to discuss this matter more fully. I do not see a way to create a blog that is linked to http://haskell.org/ghc and I couldn't find any Haskell web rings. I found Haskell mailing lists. Perhaps this is the way to go. Email though convenient doesn't allow you to organize things. Perhaps I need to create a project web page under hackage even though what I am doing at present is exploratory. This ticket system is certainly not the way to go though it may be a way to introduce a URL to a web page. You can't edit the content and I doubt anyone would appreciate a long list of comments from me here. My original post appears in duplicate. I noticed a few minutes after I posted it that I meant "sighted" and not "sited". I made the correction assuming that the "Add/Change ..." heading meant that I could make a correction to the original. "/Change" should be elided. The heading should read simply as "Add Comment ...". -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 20 06:37:05 2009 From: trac at galois.com (GHC) Date: Tue Oct 20 06:14:02 2009 Subject: [GHC] #3595: The forefathers of Haskell ... In-Reply-To: <044.9f2eda7b081b76311de605c5957ef198@localhost> References: <044.9f2eda7b081b76311de605c5957ef198@localhost> Message-ID: <053.2980800750edab48add0286edace3ebe@localhost> #3595: The forefathers of Haskell ... ---------------------------------+------------------------------------------ Reporter: JohnD | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Component: Build System | Version: Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: Could you take this to the mailing list please? As you say, this is not the right place to discuss it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 20 10:02:30 2009 From: trac at galois.com (GHC) Date: Tue Oct 20 09:39:30 2009 Subject: [GHC] #3590: panic (the impossible happened) when compiling with -O2 In-Reply-To: <046.ec4c1739f3567725a37e4c4cfcc214a3@localhost> References: <046.ec4c1739f3567725a37e4c4cfcc214a3@localhost> Message-ID: <055.5947ea451e446cf2b2458c940a2509b2@localhost> #3590: panic (the impossible happened) when compiling with -O2 -------------------------+-------------------------------------------------- Reporter: yairchu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------+-------------------------------------------------- Comment (by simonpj): Thank you; very helpful. It turned out to be a bug in the type-checking for sections. I'll commit a fix shortly. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 20 10:32:45 2009 From: trac at galois.com (GHC) Date: Tue Oct 20 10:10:36 2009 Subject: [GHC] #3531: Haddock needs tcRnGetInfo, hence GhcWithInterpreter YES In-Reply-To: <043.f3ae9723755c0a36083ac743990981c8@localhost> References: <043.f3ae9723755c0a36083ac743990981c8@localhost> Message-ID: <052.51cebbb2e8c4534639e5a6891aee9237@localhost> #3531: Haddock needs tcRnGetInfo, hence GhcWithInterpreter YES -----------------------------+---------------------------------------------- Reporter: donn | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Build System | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: NetBSD Architecture: x86 | -----------------------------+---------------------------------------------- Changes (by simonmar): * status: reopened => new * owner: simonmar => igloo Comment: Igloo is going to merge this ticket with #3558 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 20 10:37:27 2009 From: trac at galois.com (GHC) Date: Tue Oct 20 10:14:22 2009 Subject: [GHC] #3539: internal error: ASSERTION FAILED: file sm/Evac.c, line 368 In-Reply-To: <047.ce838bf90bf0705c86e1a5b8acf0114d@localhost> References: <047.ce838bf90bf0705c86e1a5b8acf0114d@localhost> Message-ID: <056.636c6431123f291fd8e3a44b76ef5927@localhost> #3539: internal error: ASSERTION FAILED: file sm/Evac.c, line 368 -------------------------------+-------------------------------------------- Reporter: elaforge | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Runtime System | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------------+-------------------------------------------- Comment (by simonmar): It looks like you already have `-debug`, since you're getting an assertion failure. `+RTS -DS` will turn on extra sanity checking. If the problem often occurs during startup, is it possible to cut the program down to one that just does the startup routines and still reproduce the problem? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 20 11:55:06 2009 From: trac at galois.com (GHC) Date: Tue Oct 20 11:32:02 2009 Subject: [GHC] #3601: When running two or more instances of GHCi, persistent history is only kept for the first one Message-ID: <044.3e95c237b5aba9c3bbec0ec0c9a5aaba@localhost> #3601: When running two or more instances of GHCi, persistent history is only kept for the first one -----------------------------+---------------------------------------------- Reporter: arnar | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.10.4 | Severity: minor Keywords: ghci history | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- The file `~/.ghc/ghci_history` maintains the command history for the first running GHCi instance. No persistent history is kept for concurrently running ghci processes. See #2050. bash provides an option of setting `shopt -s histappend`, which makes all bash instances share the same history file. Perhaps writing to the same file would be somewhat silly in the case of GHCi, but writing to .ghci_history.2 or similar could be one solution. Alternatively, a command within GHCi to dump the current instance's command history to a file would work also. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 20 11:58:14 2009 From: trac at galois.com (GHC) Date: Tue Oct 20 11:35:12 2009 Subject: [GHC] #1185: can't do I/O in the child of forkProcess with -threaded In-Reply-To: <047.505ed9940eff9ef82094c96c7212dfa3@localhost> References: <047.505ed9940eff9ef82094c96c7212dfa3@localhost> Message-ID: <056.bd69059c8bd2c0ac968e7a1b20e4c4d0@localhost> #1185: can't do I/O in the child of forkProcess with -threaded ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Runtime System | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: => simonmar Comment: I have a patch that seems to work; will tidy up and commit soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 20 12:54:07 2009 From: trac at galois.com (GHC) Date: Tue Oct 20 12:31:02 2009 Subject: [GHC] #1185: can't do I/O in the child of forkProcess with -threaded In-Reply-To: <047.505ed9940eff9ef82094c96c7212dfa3@localhost> References: <047.505ed9940eff9ef82094c96c7212dfa3@localhost> Message-ID: <056.75ca895e1a941d9c95f1f15e6efaabea@localhost> #1185: can't do I/O in the child of forkProcess with -threaded ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Runtime System | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by bsdemon): It is awesome. I was trying to fix it by myself but failed, mostly due to the lack of knowledge of how RTS works. So, please, include revision number of that bug fix, when it will be applied, in comment to this ticket. I want to take a look. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 20 14:55:55 2009 From: trac at galois.com (GHC) Date: Tue Oct 20 14:32:50 2009 Subject: [GHC] #3597: trying to build ghc 6.10.4 from src tarball: haddock: Can't find package.conf In-Reply-To: <044.585f719d9b9b61e199c03c9c4cb510dc@localhost> References: <044.585f719d9b9b61e199c03c9c4cb510dc@localhost> Message-ID: <053.ccd4b08c11ed33c9d9d06c5c026e3400@localhost> #3597: trying to build ghc 6.10.4 from src tarball: haddock: Can't find package.conf --------------------------+------------------------------------------------- Reporter: zooko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Testcase: Os: Linux | Architecture: x86 --------------------------+------------------------------------------------- Comment (by zooko): int-e asked, and I answer: {{{ zooko@hanford:~$ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.8.2 zooko@hanford:~$ cabal --version bash: cabal: command not found }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 20 14:56:49 2009 From: trac at galois.com (GHC) Date: Tue Oct 20 14:33:43 2009 Subject: [GHC] #3597: trying to build ghc 6.10.4 from src tarball: haddock: Can't find package.conf In-Reply-To: <044.585f719d9b9b61e199c03c9c4cb510dc@localhost> References: <044.585f719d9b9b61e199c03c9c4cb510dc@localhost> Message-ID: <053.a593950b08a832dec3050ba4403a8c43@localhost> #3597: trying to build ghc 6.10.4 from src tarball: haddock: Can't find package.conf --------------------------+------------------------------------------------- Reporter: zooko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Testcase: Os: Linux | Architecture: x86 --------------------------+------------------------------------------------- Comment (by zooko): creating an {{{mk/build.mk}}} with {{{HADDOCK_DOCS = NO}}} worked-around the problem and I was able to build. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 20 14:58:14 2009 From: trac at galois.com (GHC) Date: Tue Oct 20 14:35:12 2009 Subject: [GHC] #3597: trying to build ghc 6.10.4 from src tarball: haddock: Can't find package.conf In-Reply-To: <044.585f719d9b9b61e199c03c9c4cb510dc@localhost> References: <044.585f719d9b9b61e199c03c9c4cb510dc@localhost> Message-ID: <053.5fb1348949e322d786f942543b2e8438@localhost> #3597: trying to build ghc 6.10.4 from src tarball: haddock: Can't find package.conf --------------------------+------------------------------------------------- Reporter: zooko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Testcase: Os: Linux | Architecture: x86 --------------------------+------------------------------------------------- Comment (by zooko): {{{ zooko@hanford:~$ ghc-pkg list Cabal /usr/lib/ghc-6.8.2/package.conf: Cabal-1.2.3.0 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 20 16:25:57 2009 From: trac at galois.com (GHC) Date: Tue Oct 20 16:02:52 2009 Subject: [GHC] #3602: cabal-install bootstrap script emits error message with no detail Message-ID: <044.45dbd2964e04a76c7721be65da1b5d9b@localhost> #3602: cabal-install bootstrap script emits error message with no detail -------------------+-------------------------------------------------------- Reporter: zooko | Owner: Type: bug | Status: new Priority: normal | Component: None Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86 -------------------+-------------------------------------------------------- I am trying to install cabal-install, and it ended with: {{{ Sorry, something went wrong. }}} It would have been helpful if it had instead said {{{ Sorry, the 'cabal' executable was not successfully installed into '/usr/local/stow/ghc-6.10.4-from-srctarball/bin/'. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 20 16:28:38 2009 From: trac at galois.com (GHC) Date: Tue Oct 20 16:05:31 2009 Subject: [GHC] #3603: cabal-install bootstrap script respects PREFIX inconsistently, fails Message-ID: <044.a68a6b948186800a193aa94b0f82082e@localhost> #3603: cabal-install bootstrap script respects PREFIX inconsistently, fails -----------------------------+---------------------------------------------- Reporter: zooko | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- The bootstrap.sh script that comes with cabal-install is documented as respecting a PREFIX environment variable, but if you pass one it will ignore it during the installation of the executable: {{{ ./Setup configure --user "--prefix=${HOME}/.cabal" \ --with-compiler=${GHC} --with-hc-pkg=${GHC_PKG} \ ${EXTRA_CONFIGURE_OPTS} ${VERBOSE} \ || die "Configuring the ${PKG} package failed" }}} But then respect it during the post-install self-test: {{{ CABAL_BIN="$PREFIX/bin" if [ -x "$CABAL_BIN/cabal" ] then }}} ... {{{ else echo "Sorry, something went wrong." fi }}} Which means that it always emits the "Sorry, something went wrong." message and not the success message when PREFIX was specified. Also that it installed into the wrong directory. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 20 16:34:27 2009 From: trac at galois.com (GHC) Date: Tue Oct 20 16:11:23 2009 Subject: [GHC] #3603: cabal-install bootstrap script respects PREFIX inconsistently, fails In-Reply-To: <044.a68a6b948186800a193aa94b0f82082e@localhost> References: <044.a68a6b948186800a193aa94b0f82082e@localhost> Message-ID: <053.16951783e113b878cac49ac9f12a6aec@localhost> #3603: cabal-install bootstrap script respects PREFIX inconsistently, fails ------------------------------+--------------------------------------------- Reporter: zooko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by zooko): This patch fixes it: {{{ zooko@hanford:~/playground/cabal-install-0.6.2$ diff -u bootstrap.sh.orig bootstrap.sh --- bootstrap.sh.orig 2009-10-20 13:33:35.000000000 -0700 +++ bootstrap.sh 2009-10-20 13:33:50.000000000 -0700 @@ -132,7 +132,7 @@ || die "Compiling the Setup script failed" [ -x Setup ] || die "The Setup script does not exist or cannot be run" - ./Setup configure --user "--prefix=${HOME}/.cabal" \ + ./Setup configure --user "--prefix=${PREFIX}" \ --with-compiler=${GHC} --with-hc-pkg=${GHC_PKG} \ ${EXTRA_CONFIGURE_OPTS} ${VERBOSE} \ || die "Configuring the ${PKG} package failed" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 20 17:21:04 2009 From: trac at galois.com (GHC) Date: Tue Oct 20 16:57:57 2009 Subject: [GHC] #3603: cabal-install bootstrap script respects PREFIX inconsistently, fails In-Reply-To: <044.a68a6b948186800a193aa94b0f82082e@localhost> References: <044.a68a6b948186800a193aa94b0f82082e@localhost> Message-ID: <053.9da25a84d541d343a5b3234e13708f07@localhost> #3603: cabal-install bootstrap script respects PREFIX inconsistently, fails ------------------------------+--------------------------------------------- Reporter: zooko | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: invalid Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by duncan): * status: new => closed * resolution: => invalid Comment: Already fixed. http://hackage.haskell.org/trac/hackage/ticket/541 For future reference, Cabal tickets should be filed in the Cabal/Hackage trac, not the ghc one. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 20 17:24:00 2009 From: trac at galois.com (GHC) Date: Tue Oct 20 17:00:53 2009 Subject: [GHC] #3602: cabal-install bootstrap script emits error message with no detail In-Reply-To: <044.45dbd2964e04a76c7721be65da1b5d9b@localhost> References: <044.45dbd2964e04a76c7721be65da1b5d9b@localhost> Message-ID: <053.9f906429923b7317cb41c507e24964e2@localhost> #3602: cabal-install bootstrap script emits error message with no detail --------------------+------------------------------------------------------- Reporter: zooko | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: None | Version: 6.10.4 Severity: normal | Resolution: invalid Keywords: | Testcase: Os: Linux | Architecture: x86 --------------------+------------------------------------------------------- Changes (by duncan): * status: new => closed * resolution: => invalid Comment: Thanks, suggestion taken. For future reference, Cabal tickets should be filed in the Cabal/Hackage trac, not the ghc one. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 21 03:39:47 2009 From: trac at galois.com (GHC) Date: Wed Oct 21 03:16:41 2009 Subject: [GHC] #2972: ppc ghci segfaults at startup In-Reply-To: <046.36c84703d6f462149fdd781bf29492ec@localhost> References: <046.36c84703d6f462149fdd781bf29492ec@localhost> Message-ID: <055.0f5c4ab2bfd26a0a3e5d7c9df50c4047@localhost> #2972: ppc ghci segfaults at startup ------------------------+--------------------------------------------------- Reporter: cemeyer | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: GHCi | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: powerpc | ------------------------+--------------------------------------------------- Comment (by juhpetersen): (Thought I already added this, but just to note that ghc-6.12 RC1 also segfaults.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 21 09:20:44 2009 From: trac at galois.com (GHC) Date: Wed Oct 21 08:58:02 2009 Subject: [GHC] #3593: Where has readline gone? In-Reply-To: <045.76493d1c4c1b7c04e29d1d3c65eb4fb8@localhost> References: <045.76493d1c4c1b7c04e29d1d3c65eb4fb8@localhost> Message-ID: <054.e10502ddd1c938955a22c86582be6f55@localhost> #3593: Where has readline gone? ---------------------------------+------------------------------------------ Reporter: spivey | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Package system | Version: 6.10.4 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => wontfix Comment: GHC now ships with only a small set of packages, namely those required to bootstrap GHC itself. To get a wider range of packages, you should install the [http://hackage.haskell.org/platform/ Haskell Platform]. The current Haskell Platform release comes with editline it seems, but I would recommend installing Haskeline instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 21 09:22:34 2009 From: trac at galois.com (GHC) Date: Wed Oct 21 08:59:39 2009 Subject: [GHC] #3596: getOptions'.parseLanguage(1) went past eof token In-Reply-To: <049.62fba1fe2701e51d41ed452c7c76c4d6@localhost> References: <049.62fba1fe2701e51d41ed452c7c76c4d6@localhost> Message-ID: <058.09edd351b3783fadc6f434b00ac496a6@localhost> #3596: getOptions'.parseLanguage(1) went past eof token ----------------------------------+----------------------------------------- Reporter: Paczesiowa | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Parser) | Version: 6.10.4 Severity: minor | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: Thanks for the report. Dup of #3153. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 21 09:28:10 2009 From: trac at galois.com (GHC) Date: Wed Oct 21 09:05:05 2009 Subject: [GHC] #3599: haddock assumes $libdir/ghc-6.12.0.20091010/html/haddock.css In-Reply-To: <050.bebf295c09f55c5c53a40fbdb001dd53@localhost> References: <050.bebf295c09f55c5c53a40fbdb001dd53@localhost> Message-ID: <059.d765490be774711c7c99c96b45339b0c@localhost> #3599: haddock assumes $libdir/ghc-6.12.0.20091010/html/haddock.css ---------------------------------+------------------------------------------ Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Build System | Version: 6.12.0 RC1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * priority: normal => high * difficulty: => Unknown * milestone: => 6.12.1 Comment: Confirmed; thanks for the report. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 21 09:31:43 2009 From: trac at galois.com (GHC) Date: Wed Oct 21 09:08:35 2009 Subject: [GHC] #3586: Initialisation of unboxed arrays is too slow In-Reply-To: <046.d37b803347b32ce78018550b0e0c0244@localhost> References: <046.d37b803347b32ce78018550b0e0c0244@localhost> Message-ID: <055.540425122c07eac218777d5e07cc1355@localhost> #3586: Initialisation of unboxed arrays is too slow -----------------------------------------+---------------------------------- Reporter: simonpj | Owner: Type: run-time performance bug | Status: new Priority: high | Milestone: 6.12.2 Component: libraries (other) | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Comment (by simonmar): I suggest that: * after the INLINE patch lands in HEAD, test that it fixes this issue * for 6.12.2 (or 6.12.1 if there's time), apply the workaround of extracting `newArray` to a top-level function -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 22 04:14:12 2009 From: trac at galois.com (GHC) Date: Thu Oct 22 03:51:05 2009 Subject: [GHC] #3604: Use of template-haskell is broken with shared libraries Message-ID: <044.80a0861c1656d96474979b0b59adc47b@localhost> #3604: Use of template-haskell is broken with shared libraries -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.12.0 RC1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Consider the following program: TH.hs: {{{ {-# LANGUAGE TemplateHaskell #-} module TH where import Language.Haskell.TH spliceMe = [| (\xs -> tail xs ++ init xs) |] }}} Library.hs {{{ {-# LANGUAGE TemplateHaskell #-} module Library where import TH main = print ($(spliceMe) [1, 2]) }}} Build it like so: {{{ ghc --make -package-name foo-0.2.3 -hide-all-packages -fbuilding-cabal- package -no-user-package-conf -i -idist/build -i. -idist/build/autogen -Idist/build/a utogen -Idist/build -optP-include -optPdist/build/autogen/cabal_macros.h -odir dist/build -hidir dist/build -stubdir dist/build -package-id base-4.2.0.0-e0460a0a4effe0aca049da0e 12eab4d3 -package-id template- haskell-2.4.0.0-fa9ea4aecb54a2910620fe9afd9f40f1 -O Library -dynamic -hisuf dyn_hi -osuf dyn_o -fPIC }}} And observe the wonderful error: {{{ Creating dist/build (and its parents) Creating dist/build/autogen (and its parents) Preprocessing library foo-0.2.3... Building foo-0.2.3... Building library... Creating dist/build (and its parents) /home/a1333478/bin/ghc --make -package-name foo-0.2.3 -hide-all-packages -fbuilding-cabal-package -no-user-package-conf -i -idist/build -i. -idist/build/autogen -Idist/build/autogen -Idist/build -optP-include -optPdist/build/autogen/cabal_macros.h -odir dist/build -hidir dist/build -stubdir dist/build -package-id base-4.2.0.0-e0460a0a4effe0aca049da0e12eab4d3 -package-id template- haskell-2.4.0.0-fa9ea4aecb54a2910620fe9afd9f40f1 -O Library /home/a1333478/bin/ghc --make -package-name foo-0.2.3 -hide-all-packages -fbuilding-cabal-package -no-user-package-conf -i -idist/build -i. -idist/build/autogen -Idist/build/autogen -Idist/build -optP-include -optPdist/build/autogen/cabal_macros.h -odir dist/build -hidir dist/build -stubdir dist/build -package-id base-4.2.0.0-e0460a0a4effe0aca049da0e12eab4d3 -package-id template- haskell-2.4.0.0-fa9ea4aecb54a2910620fe9afd9f40f1 -O Library -dynamic -hisuf dyn_hi -osuf dyn_o -fPIC [2 of 2] Compiling Library ( Library.hs, dist/build/Library.dyn_o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package array-0.3.0.0 ... linking ... done. Loading package containers-0.3.0.0 ... linking ... done. Loading package pretty-1.0.1.1 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package ffi-1.0 ... linking ... done. ghc-stage2: dist/build/TH.dyn_o: unknown symbol `__stginit_base_Prelude_dyn' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 22 04:16:25 2009 From: trac at galois.com (GHC) Date: Thu Oct 22 03:53:14 2009 Subject: [GHC] #3604: Use of template-haskell is broken with shared libraries In-Reply-To: <044.80a0861c1656d96474979b0b59adc47b@localhost> References: <044.80a0861c1656d96474979b0b59adc47b@localhost> Message-ID: <053.89c8a25bf7c2cfbea87fbf45f67be06b@localhost> #3604: Use of template-haskell is broken with shared libraries ------------------------------+--------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.12.0 RC1 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by guest): By the way, I tracked the origin of the error down to Linker.lhs:linkDependencies. Is it going to be possible to fix this before 6.12.1? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 22 10:11:45 2009 From: trac at galois.com (GHC) Date: Thu Oct 22 09:48:35 2009 Subject: [GHC] #3604: Use of template-haskell is broken with shared libraries In-Reply-To: <044.80a0861c1656d96474979b0b59adc47b@localhost> References: <044.80a0861c1656d96474979b0b59adc47b@localhost> Message-ID: <053.6b54809a83e446d262ed368054b67e2b@localhost> #3604: Use of template-haskell is broken with shared libraries ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.12.1 RC1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * priority: normal => high * difficulty: => Unknown * milestone: => 6.12.1 Comment: I talked to Simon M before he went on holiday. We think there is no reason in principle why this should not work. And hence we should try to fix it for 6.12. Does anyone feel able to look at it? If it turns out to be a deeper problem we may have to punt it, but meanwhile I'll put it as high priority for 6.12.1 Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 22 12:18:27 2009 From: trac at galois.com (GHC) Date: Thu Oct 22 11:55:16 2009 Subject: [GHC] #3605: Dll's freeze with -threaded Message-ID: <051.1aad4f74c417c7c8dcc312c4764dd078@localhost> #3605: Dll's freeze with -threaded -----------------------------+---------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.12.1 RC1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Attached are two source files (one .c, one .hs), which are compiled (using mk.sh) into DsoHsDemo.dll. When this library is loaded, using the following C snippet: {{{ int main(int argc, char* argv[]) { printf("Started LoadLibrary\n"); LoadLibrary("DsoHsDemo.dll"); printf("Finished LoadLibrary\n"); } }}} The program freezes: {{{ $ ./mk.sh && ./CSnippet The Glorious Glasgow Haskell Compilation System, version 6.12.0.20091010 Creating library file: DsoHsDemo.dll.a Started LoadLibrary pre hs_init }}} The freeze only occurs when the dll is linked with -threaded, and happens within either startupHaskell, or (if you call hs_init/hs_add_root instead) within hs_add_root. This happens with GHC 6.10.4 and 6.12rc1 on Windows XP. This bug appears to make it impossible to successfully build a DLL for multithreaded use. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 22 12:21:01 2009 From: trac at galois.com (GHC) Date: Thu Oct 22 11:57:51 2009 Subject: [GHC] #3605: Dll's freeze with -threaded In-Reply-To: <051.1aad4f74c417c7c8dcc312c4764dd078@localhost> References: <051.1aad4f74c417c7c8dcc312c4764dd078@localhost> Message-ID: <060.3b5a9464e9c66a2a2969c7f4d637df06@localhost> #3605: Dll's freeze with -threaded ------------------------------+--------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.12.1 RC1 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by NeilMitchell): Please ignore HsDemo.2.hs, I clicked on the wrong file. Either HsDemo file will cause the freeze. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 22 14:13:55 2009 From: trac at galois.com (GHC) Date: Thu Oct 22 13:50:48 2009 Subject: [GHC] #3605: Dll's freeze with -threaded In-Reply-To: <051.1aad4f74c417c7c8dcc312c4764dd078@localhost> References: <051.1aad4f74c417c7c8dcc312c4764dd078@localhost> Message-ID: <060.3729114fbd4b11a6a2461d6d25f218f4@localhost> #3605: Dll's freeze with -threaded ------------------------------+--------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.12.1 RC1 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by duncan): My initial reaction is that calling `startupHaskell` from within `DllMain` is a tad dodgy. The [http://msdn.microsoft.com/en- us/library/ms682583(VS.85).aspx MSDN docs] say there are pretty severe limitations on what can be done in it. In particular no calls to LoadLibrary (or other functions that call LoadLibrary). This is because the `DllMain` is called with a loader lock. So this is one possibility that is consistent with the observed freeze. It also says: {{{ Calling functions that require DLLs other than Kernel32.dll may result in problems that are difficult to diagnose. For example, calling User, Shell, and COM functions can cause access violation errors, because some functions load other system components. }}} So to determine if `startupHaskell` is safe would require a full audit of all the code it calls. Another approach would be to trace the library load and see what OS / library calls it is making. There are more reasons to suggest that `startupHaskell` cannot safely be run from within `DllMain`, the [http://www.microsoft.com/whdc/driver/kernel/DLL_bestprac.mspx MSDN Best Practices for Creating DLLs] document states that: {{{ You should never perform the following tasks from within DllMain: }}} including: {{{ Call CreateThread. Creating a thread can work if you do not synchronize with other threads, but it is risky. }}} Of course this is exactly what `startupHaskell` does, though only in the case of multiple capabilities. {{{ Use the memory management function from the dynamic C Run-Time (CRT). If the CRT DLL is not initialized, calls to these functions can cause the process to crash. }}} I expect the rts does this too. Someone else should look this over but I suspect the thing to do is to change the user guide (section 11.6) to stop recommending calling `startupHaskell` inside `DllMain` and indeed to recommend never to do that. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 22 16:48:52 2009 From: trac at galois.com (GHC) Date: Thu Oct 22 16:25:43 2009 Subject: [GHC] #3606: The Ord instance for unboxed arrays is very inefficient Message-ID: <046.5524abf7655d34a8f91d5dca7267dc7d@localhost> #3606: The Ord instance for unboxed arrays is very inefficient -----------------------------+---------------------------------------------- Reporter: blarsen | Owner: Type: bug | Status: new Priority: normal | Component: libraries (other) Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- The Ord instance for unboxed arrays defined in Data.Array.Base results in code that makes lots of heap allocations and is very slow. For the record, the Ord instance is defined as so in Data.Array.Base: {{{ instance (Ix ix, Ord e, IArray UArray e) => Ord (UArray ix e) where compare = cmpUArray {-# INLINE cmpUArray #-} cmpUArray :: (IArray UArray e, Ix i, Ord e) => UArray i e -> UArray i e -> Ordering cmpUArray arr1 arr2 = compare (assocs arr1) (assocs arr2) }}} The 'assocs' calls don't appear to be deforested away, and hence, when using the Ord functions on unboxed arrays, the performance is bad to the point of making them unusable. It seems reasonable to me that 'compare' for unboxed arrays could be implemented strictly, in a tight loop, without any heap allocations at all. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 22 16:49:34 2009 From: trac at galois.com (GHC) Date: Thu Oct 22 16:26:22 2009 Subject: [GHC] #3606: The Ord instance for unboxed arrays is very inefficient In-Reply-To: <046.5524abf7655d34a8f91d5dca7267dc7d@localhost> References: <046.5524abf7655d34a8f91d5dca7267dc7d@localhost> Message-ID: <055.ad9dad997808ae7fa6b23943a2d51438@localhost> #3606: The Ord instance for unboxed arrays is very inefficient -------------------------------------+-------------------------------------- Reporter: blarsen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 6.10.4 Severity: normal | Resolution: Keywords: array, performance, Ord | Testcase: Os: Linux | Architecture: x86_64 (amd64) -------------------------------------+-------------------------------------- Changes (by blarsen): * keywords: => array, performance, Ord * os: Unknown/Multiple => Linux * architecture: Unknown/Multiple => x86_64 (amd64) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 22 17:05:23 2009 From: trac at galois.com (GHC) Date: Thu Oct 22 16:42:11 2009 Subject: [GHC] #3606: The Ord instance for unboxed arrays is very inefficient In-Reply-To: <046.5524abf7655d34a8f91d5dca7267dc7d@localhost> References: <046.5524abf7655d34a8f91d5dca7267dc7d@localhost> Message-ID: <055.6b4e0dd9c696eb3e15c4e0d2f063b058@localhost> #3606: The Ord instance for unboxed arrays is very inefficient -------------------------------------+-------------------------------------- Reporter: blarsen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 6.10.4 Severity: normal | Resolution: Keywords: array, performance, Ord | Testcase: Os: Linux | Architecture: x86_64 (amd64) -------------------------------------+-------------------------------------- Comment (by duncan): And we cannot make it fuse using build/foldr because it is a zipWith consumed by a foldl. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 22 17:15:19 2009 From: trac at galois.com (GHC) Date: Thu Oct 22 16:52:06 2009 Subject: [GHC] #3607: index variable for array traversal worker function is not unboxed Message-ID: <046.d0a8edddda5b84dbb9470f811143a19b@localhost> #3607: index variable for array traversal worker function is not unboxed -------------------------------+-------------------------------------------- Reporter: blarsen | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: normal Keywords: unboxed array, Ord | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- See also [http://hackage.haskell.org/trac/ghc/ticket/3606]. In an attempt to write a better comparison function for unboxed arrays, I wrote the following code: {{{ {-# LANGUAGE BangPatterns #-} {-# OPTIONS -Wall #-} module BadArrayCmp where import Data.Array.Base import Data.Array.Unboxed cmpArrays :: (IArray a1 e, IArray a2 e, Ix i, Ord e) => a1 i e -> a2 i e -> Ordering cmpArrays a1 a2 = case compare (bounds a1) (bounds a2) of LT -> LT EQ -> go 0 GT -> GT where iMaxPlusOne :: Int iMaxPlusOne = numElements a1 go :: Int -> Ordering go !i = if i == iMaxPlusOne then EQ else case compare (unsafeAt a1 i) (unsafeAt a2 i) of LT -> LT EQ -> go (i+1) GT -> GT {-# INLINE cmpArrays #-} }}} I have attached this code as a test case. Examining the core generated by ghc 6.10.4 using -O2 on Ubuntu 9.04 x86_64, the code generated for 'go' uses a boxed Int for the index variable. Because of this boxed int (and perhaps other problems in the generated code, I'm not sure), in a particular application of mine, ~60% of the total time is used and %80% of the total allocation is done in 'cmpArrays'. (These percentages obtained via profiling.) I imagine that 'go' _could_ be compiled so that the only potential allocation done is for the Ordering value at the end. Using a boxed index variable instead of something kept in a register really kills performance! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 22 19:33:05 2009 From: trac at galois.com (GHC) Date: Thu Oct 22 19:10:03 2009 Subject: [GHC] #3605: Dll's freeze with -threaded In-Reply-To: <051.1aad4f74c417c7c8dcc312c4764dd078@localhost> References: <051.1aad4f74c417c7c8dcc312c4764dd078@localhost> Message-ID: <060.5f1ebc4810899e75d3def3df5dadecca@localhost> #3605: Dll's freeze with -threaded ------------------------------+--------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.12.1 RC1 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by augustss): Perhaps calling startupHaskell is from DllMain() is not allowed, but this is what the ghc documentation suggests that you do. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 23 12:23:11 2009 From: trac at galois.com (GHC) Date: Fri Oct 23 12:01:16 2009 Subject: [GHC] #3400: OS X: ghc broken on Snow Leopard In-Reply-To: <042.42f8ee6f478d8beecc65fea9d7e2b0b4@localhost> References: <042.42f8ee6f478d8beecc65fea9d7e2b0b4@localhost> Message-ID: <051.16da718fde923ff737cca35a0ac03035@localhost> #3400: OS X: ghc broken on Snow Leopard -------------------------+-------------------------------------------------- Reporter: bbb | Owner: chak Type: bug | Status: reopened Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.11 Severity: blocker | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by korpios): * cc: korpios@korpios.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 23 18:20:14 2009 From: trac at galois.com (GHC) Date: Fri Oct 23 17:56:59 2009 Subject: [GHC] #2273: inlining defeats seq In-Reply-To: <044.9c3223a55b4d3223b10ccf35be7e7d4f@localhost> References: <044.9c3223a55b4d3223b10ccf35be7e7d4f@localhost> Message-ID: <053.d1ed06daea4a24ea071e40c7dc34f4a1@localhost> #2273: inlining defeats seq ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * type: merge => bug -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 23 19:21:17 2009 From: trac at galois.com (GHC) Date: Fri Oct 23 18:58:05 2009 Subject: [GHC] #3578: internal error: evacuate(static): strange closure type 42 In-Reply-To: <043.5afd3bca71e73869953acaf1347724a9@localhost> References: <043.5afd3bca71e73869953acaf1347724a9@localhost> Message-ID: <052.e561965ce46ac3f9ce0bd4a257c68d97@localhost> #3578: internal error: evacuate(static): strange closure type 42 -------------------------------+-------------------------------------------- Reporter: nccb | Owner: igloo Type: merge | Status: closed Priority: high | Milestone: 6.12.1 Component: Runtime System | Version: 6.13 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Both merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 23 19:22:43 2009 From: trac at galois.com (GHC) Date: Fri Oct 23 18:59:29 2009 Subject: [GHC] #3579: Error: symbol `Bug_compose1_closure' is already defined In-Reply-To: <044.8d0cee2189cb326f04528793a172ebca@localhost> References: <044.8d0cee2189cb326f04528793a172ebca@localhost> Message-ID: <053.56312471ef4c6885f4c7fc40106d362f@localhost> #3579: Error: symbol `Bug_compose1_closure' is already defined ---------------------------------+------------------------------------------ Reporter: igloo | Owner: igloo Type: merge | Status: closed Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.13 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 23 19:23:33 2009 From: trac at galois.com (GHC) Date: Fri Oct 23 19:00:22 2009 Subject: [GHC] #3572: Empty types are prettyprinted with trailing "=" In-Reply-To: <045.a913ce8d59080e93f1d9fb9091a05960@localhost> References: <045.a913ce8d59080e93f1d9fb9091a05960@localhost> Message-ID: <054.a7ef040708c9c59c5d3c211eb9da2171@localhost> #3572: Empty types are prettyprinted with trailing "=" ---------------------------------+------------------------------------------ Reporter: FSalad | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: Component: Template Haskell | Version: 6.10.4 Severity: trivial | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: th/T3572 | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 23 19:25:03 2009 From: trac at galois.com (GHC) Date: Fri Oct 23 19:01:50 2009 Subject: [GHC] #3263: Warnings for monadic values not used In-Reply-To: <051.2ba77802c306560898b377ae21be4ade@localhost> References: <051.2ba77802c306560898b377ae21be4ade@localhost> Message-ID: <060.ca9d11eda4974f765f43c880502223d9@localhost> #3263: Warnings for monadic values not used -----------------------------------+---------------------------------------- Reporter: NeilMitchell | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: ghci/scripts/T3263 | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------+---------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 23 19:26:01 2009 From: trac at galois.com (GHC) Date: Fri Oct 23 19:02:47 2009 Subject: [GHC] #3600: Template Haskell mis-coverting empty list to empty string In-Reply-To: <046.8bf02926d3cbcc535bf50979d483cc00@localhost> References: <046.8bf02926d3cbcc535bf50979d483cc00@localhost> Message-ID: <055.cdcebd491c301cd6060fa0cccd812f29@localhost> #3600: Template Haskell mis-coverting empty list to empty string ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.12.1 Component: Template Haskell | Version: 6.10.4 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: th/T3600 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 25 09:44:21 2009 From: trac at galois.com (GHC) Date: Sun Oct 25 09:21:01 2009 Subject: [GHC] #3608: Build the ghc-bin package in the standard way Message-ID: <044.3e8ad06a15a88bccf4286d63f937750d@localhost> #3608: Build the ghc-bin package in the standard way -------------------------------+-------------------------------------------- Reporter: igloo | Owner: Type: task | Status: new Priority: normal | Milestone: 6.14.1 Component: Build System | Version: 6.10.4 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- In `ghc/ghc.mk` we have {{{ # ToDo ghc_USES_CABAL = NO }}} which I think is responsible for these (non-fatal) errors during the build: {{{ "inplace/bin/mkdependC" -f ghc/stage1/build/.depend.tmp -- -Wall -Werror -- ghc/hschooks.c ghc/hschooks.c:7:17: error: Rts.h: No such file or directory ghc/hschooks.c:9:22: error: RtsFlags.h: No such file or directory ghc/hschooks.c:12:19: error: HsFFI.h: No such file or directory ghc/hschooks.c:7:17: error: Rts.h: No such file or directory ghc/hschooks.c:9:22: error: RtsFlags.h: No such file or directory ghc/hschooks.c:12:19: error: HsFFI.h: No such file or directory }}} We should build ghc-bin in the standard way, without `ghc_USES_CABAL = NO`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 25 10:45:08 2009 From: trac at galois.com (GHC) Date: Sun Oct 25 10:21:51 2009 Subject: [GHC] #3599: haddock assumes $libdir/ghc-6.12.0.20091010/html/haddock.css In-Reply-To: <050.bebf295c09f55c5c53a40fbdb001dd53@localhost> References: <050.bebf295c09f55c5c53a40fbdb001dd53@localhost> Message-ID: <059.2a81e16b7a319c67c189459848587e74@localhost> #3599: haddock assumes $libdir/ghc-6.12.0.20091010/html/haddock.css ---------------------------------+------------------------------------------ Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Build System | Version: 6.12.1 RC1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by greenrd): * cc: greenrd@greenrd.org (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 25 15:15:35 2009 From: trac at galois.com (GHC) Date: Sun Oct 25 14:52:16 2009 Subject: [GHC] #3599: haddock assumes $libdir/ghc-6.12.0.20091010/html/haddock.css In-Reply-To: <050.bebf295c09f55c5c53a40fbdb001dd53@localhost> References: <050.bebf295c09f55c5c53a40fbdb001dd53@localhost> Message-ID: <059.5627d195afc53fca37fabc6139b65b67@localhost> #3599: haddock assumes $libdir/ghc-6.12.0.20091010/html/haddock.css ---------------------------------+------------------------------------------ Reporter: juhpetersen | Owner: Type: bug | Status: closed Priority: high | Milestone: 6.12.1 Component: Build System | Version: 6.12.1 RC1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed in HEAD and 6.12 by: {{{ Sun Oct 25 17:26:40 GMT 2009 Ian Lynagh * Fix installation in the GHC build system }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From igloo at earth.li Sun Oct 25 15:34:47 2009 From: igloo at earth.li (Ian Lynagh) Date: Sun Oct 25 15:11:24 2009 Subject: mkdirhier fails on Ubuntu Hardy i686 with dash shell In-Reply-To: References: Message-ID: <20091025193447.GA26087@matrix.chaos.earth.li> On Mon, Oct 19, 2009 at 12:49:44PM -0600, Zooko Wilcox-O'Hearn wrote: > > Replacing the contents of mkdirhier and mkdirhier.sh with "mkdir -p $*" > works-around the problem. Does anyone know why we don't just call "mkdir -p" normally? Are there portability problems with it? Thanks Ian From trac at galois.com Mon Oct 26 04:28:53 2009 From: trac at galois.com (GHC) Date: Mon Oct 26 04:05:36 2009 Subject: [GHC] #3008: Strange behavior when using newtyped version of IO monad in FFI import declarations In-Reply-To: <044.36e848c5758ff29e66ba18e678751e7c@localhost> References: <044.36e848c5758ff29e66ba18e678751e7c@localhost> Message-ID: <053.c122e5feed9403f3860fe1776f58bf44@localhost> #3008: Strange behavior when using newtyped version of IO monad in FFI import declarations -------------------------------+-------------------------------------------- Reporter: waern | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: FFI | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by simonpj): * owner: => chak Comment: The bug in the FFI spec is fixed in the 2009 Haskell Prime iteration. Manuel says that now we need to * Fix GHC to refuse to transparently marshal opaque newtypes * Fix the FFI libraries not to expect GHC to do so Moreover he generously says "I'm happy to apply those changes, but it won't be right now, as I have a backlog of things to get through." So I'll assign this ticket to you, Manuel. Thanks. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 26 05:06:44 2009 From: trac at galois.com (GHC) Date: Mon Oct 26 04:43:20 2009 Subject: [GHC] #3609: ar.exe: Bad file number Message-ID: <046.6971073bd0dd34bb84a681dc5bdcec98@localhost> #3609: ar.exe: Bad file number -------------------------------+-------------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- John Earle writes: * Hardware. Operating System: 32-Bit Edition of Windows Vista with Service Pack 2 applied. CPU: Intel Pentium 4 * Software. MinGW 5.1.6 which is the current stable release. MinGW 5.1.6 does not install the latest version of gcc, however. It installs gcc 3.4.5. * MSYS 1.0.11 which is the current version of MSYS. It installs GNU Make 3.81 among other things. The version of MSYS available at http://hackage.haskell.org/trac/ghc/wiki/Building/Preparation/Windows is 1.0.10. * msysDTK-1.0.1 which is the current stable release and is the same version available at http://hackage.haskell.org/trac/ghc/wiki/Building/Preparation/Windows. * Preexisting version of GHC is 6.10.4 which is the current stable release of GHC which was used to build GHC 6.10.4 from source. * Those additional Haskell tools that were needed were downloaded from http://hackage.haskell.org/trac/ghc/wiki/Building/Preparation/Windows. * !ActiveState Python 2.6.3.7 (current is 3.1.1.2, but is not appropriate). A build script along with a build procedure was prepared. These results do not reflect what was needed to reach this point. Many hours of work were required to achieve these results. These results were not the results that were achieved initially. The directions provided for how to build GHC from source proved insufficient. A workaround which was not described is needed. The build script runs make, the fast test suite, and make install. The documentation is not built. In order for the test suite to complete Windows Firewall had to be turned off which was something that was also not specified in the directions. Where the test suite needed to be unpacked to or should be named was furthermore not specified. These issues among others make the build process very expensive. Once you have all your ducks in the row, it is easier going, but that is how it usually is in life. Before proceeding remove the xargs shell script from the path. The xargs shell script is the workaround described above. Wait 1 hour and 1 minute. {{{ make -C libraries all make[2]: Entering directory `/Z/dev/ghc-6.10.4/src/libraries/ghc-prim' (echo dist/build/cbits/longlong.o `find dist/build -name "*_stub.o" -print`; find dist/build/GHC/Bool_split dist/build/GHC/Generics_split dist/build/GHC/Ordering_split dist/build/GHC/PrimopWrappers_split dist/build/GHC/IntWord32_split dist/build/GHC/IntWord64_split dist/build/GHC/Tuple_split dist/build/GHC/Types_split dist/build/GHC/Unit_split -name '*.o' -print) | xargs c:/MinGW/bin/ar.exe q dist/build/libHSghc-prim-0.1.0.0.a xargs: c:/MinGW/bin/ar.exe: Bad file number make[2]: *** [dist/build/libHSghc-prim-0.1.0.0.a] Error 126 }}} In prior attempts I did not receive this error so early. Notice that the version of ar is c:/MinGW/bin/ar.exe. In http://hackage.haskell.org/trac/ghc/wiki/Building/Preparation/Windows c:/MinGW/bin/ occurs in the path before the preexisting instance of GHC just as is the case here. On a previous attempts I have gotten "xargs: c:/ghc/ghc-6.10.4/bin/ar.exe: Argument list too long" and "xargs: c:/ghc/ghc-6.10.4/bin/ar.exe: Bad file number". The path to ar appeared hard coded which is confusing. I moved the xargs shell script so that it appeared front most in the path once more and resumed the build process from where it left off. Wait 3 hours and 5 minutes. The build process completed successfully. At 2 hours and 42 minutes later after the build process was resumed an empty null file is created in the "Z:\dev" parent directory which an immediate child of the root directory. Regardless of how deeply nested the project directory is, it always appears in the dev directory. If all goes well the build process has consistently taken 4 hours and 6 minutes. The day before the build was completed with the workaround applied prior to carrying out the procedure. Today, when the workaround was applied only once an error was encountered and this resulted in additional unexpected test suite failure, namely: conc049(normal). These were yesterdays results: {{{ OVERALL SUMMARY for test run started at The current date is: 2009.10.22 Enter the new date: (yy-mm-dd) 2403 total tests, which gave rise to 12815 test cases, of which 0 caused framework failures 10766 were skipped 1955 expected passes 76 expected failures 1 unexpected passes 17 unexpected failures Unexpected passes: system001(normal) Unexpected failures: 2816(ghci) DoParamM(normal) cabal01(normal) drvfail006(normal) drvfail008(normal) getPermissions001(normal,normal) ghci028(ghci) mod133(normal) net001(normal) signals004(normal) tc183(normal) tc217(normal) tc220(normal) tc223(normal) tc232(normal) tcfail126(normal) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 26 05:11:39 2009 From: trac at galois.com (GHC) Date: Mon Oct 26 04:48:15 2009 Subject: [GHC] #3609: ar.exe: Bad file number In-Reply-To: <046.6971073bd0dd34bb84a681dc5bdcec98@localhost> References: <046.6971073bd0dd34bb84a681dc5bdcec98@localhost> Message-ID: <055.302c69a9b6f9c6284c4645eeb31ca3b9@localhost> #3609: ar.exe: Bad file number ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonpj): There seem to be several issues here * The 'ar: bad file name' problem of #3201 seems to have re-appeared. Maybe it's because he is using MSYS 1.0.11 instead of 1.0.10? * He didn't find it clear where to unpack the testsuite * A mysterious null file was created in z:/dev. (It's not clear what this file is called.) * He had to turn the Windows Firewall off to run the testsuite. I don't know why, or what error manifested if he did not do so. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 26 05:36:23 2009 From: trac at galois.com (GHC) Date: Mon Oct 26 05:13:02 2009 Subject: [GHC] #3590: panic (the impossible happened) when compiling with -O2 In-Reply-To: <046.ec4c1739f3567725a37e4c4cfcc214a3@localhost> References: <046.ec4c1739f3567725a37e4c4cfcc214a3@localhost> Message-ID: <055.dd1a59dff6a11af236c4531c0c2cd36f@localhost> #3590: panic (the impossible happened) when compiling with -O2 ---------------------------------------------------+------------------------ Reporter: yairchu | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: indexed-types/should_compile/T3590 | Os: MacOS X Architecture: x86 | ---------------------------------------------------+------------------------ Changes (by simonpj): * testcase: => indexed-types/should_compile/T3590 * owner: => igloo * type: bug => merge Comment: Here's the patch {{{ Tue Oct 20 08:55:40 PDT 2009 simonpj@microsoft.com * Fix Trac #3590: a nasty type-checker bug in left/right sections Ignore-this: ae831f2a7fe8416e2c549df7616f7139 The bug related to the fact that boxyUnify (now) returns a coercion, which was simply being ignored. (TcExpr is clearly not warning-free wrt the unused-monadic-bind thing!) Anyway, it's fine now. I added a test case to the test suite. MERGE to 6.12 please. M ./compiler/typecheck/TcExpr.lhs -21 +26 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 26 06:03:57 2009 From: trac at galois.com (GHC) Date: Mon Oct 26 05:40:34 2009 Subject: [GHC] #3610: Installer has hard-coded path /usr/bin/strip Message-ID: <047.497d60e15e84c11bbc4d65529d1dd7a9@localhost> #3610: Installer has hard-coded path /usr/bin/strip -----------------------------+---------------------------------------------- Reporter: YitzGale | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- On some systems, strip may not be located in /usr/bin. And even if it is, that might not be the version of strip we need to use, e.g., in a virtual hosting environment. See, for example, [http://substack.net/posts/ea85c2/Happstack-on-Dreamhost-Notes this blog post] about installing GHC on Dreamhost. It seems that GHC ought to locate strip using $PATH, or some other mechanism that can be configured. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 26 07:26:08 2009 From: trac at galois.com (GHC) Date: Mon Oct 26 07:03:06 2009 Subject: [GHC] #635: Replace use of select() in the I/O manager with epoll/kqueue/etc. In-Reply-To: <047.158ac52b7977b3e9f47680935a918275@localhost> References: <047.158ac52b7977b3e9f47680935a918275@localhost> Message-ID: <056.0b0191ce1d96051eed6582140df68acf@localhost> #635: Replace use of select() in the I/O manager with epoll/kqueue/etc. ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: _|_ Component: libraries/base | Version: 6.4.1 Severity: normal | Resolution: Keywords: | Difficulty: Difficult (1 week) Testcase: N/A | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by guest): * cc: cgibbard@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 26 07:26:49 2009 From: trac at galois.com (GHC) Date: Mon Oct 26 07:04:13 2009 Subject: [GHC] #635: Replace use of select() in the I/O manager with epoll/kqueue/etc. In-Reply-To: <047.158ac52b7977b3e9f47680935a918275@localhost> References: <047.158ac52b7977b3e9f47680935a918275@localhost> Message-ID: <056.6bc1ee16a8e7a5d267204935ab890dae@localhost> #635: Replace use of select() in the I/O manager with epoll/kqueue/etc. ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: _|_ Component: libraries/base | Version: 6.4.1 Severity: normal | Resolution: Keywords: | Difficulty: Difficult (1 week) Testcase: N/A | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by morrow): * cc: morrow@moonpatio.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 26 07:29:47 2009 From: trac at galois.com (GHC) Date: Mon Oct 26 07:07:10 2009 Subject: [GHC] #635: Replace use of select() in the I/O manager with epoll/kqueue/etc. In-Reply-To: <047.158ac52b7977b3e9f47680935a918275@localhost> References: <047.158ac52b7977b3e9f47680935a918275@localhost> Message-ID: <056.44f8d54a558918d822ba593056487600@localhost> #635: Replace use of select() in the I/O manager with epoll/kqueue/etc. ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: _|_ Component: libraries/base | Version: 6.4.1 Severity: normal | Resolution: Keywords: | Difficulty: Difficult (1 week) Testcase: N/A | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by lvh): * cc: lvh@laurensvh.be (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 26 07:33:51 2009 From: trac at galois.com (GHC) Date: Mon Oct 26 07:11:17 2009 Subject: [GHC] #635: Replace use of select() in the I/O manager with epoll/kqueue/etc. In-Reply-To: <047.158ac52b7977b3e9f47680935a918275@localhost> References: <047.158ac52b7977b3e9f47680935a918275@localhost> Message-ID: <056.2fb412770a683a52a527c1bf3fa095f0@localhost> #635: Replace use of select() in the I/O manager with epoll/kqueue/etc. ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: _|_ Component: libraries/base | Version: 6.4.1 Severity: normal | Resolution: Keywords: | Difficulty: Difficult (1 week) Testcase: N/A | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by YitzGale): * cc: gale@sefer.org (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 26 07:55:43 2009 From: trac at galois.com (GHC) Date: Mon Oct 26 07:33:04 2009 Subject: [GHC] #635: Replace use of select() in the I/O manager with epoll/kqueue/etc. In-Reply-To: <047.158ac52b7977b3e9f47680935a918275@localhost> References: <047.158ac52b7977b3e9f47680935a918275@localhost> Message-ID: <056.f85f09e7975cea3dcf5a97a94677ac33@localhost> #635: Replace use of select() in the I/O manager with epoll/kqueue/etc. ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: _|_ Component: libraries/base | Version: 6.4.1 Severity: normal | Resolution: Keywords: | Difficulty: Difficult (1 week) Testcase: N/A | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by jystic): * cc: jystic@jystic.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 26 08:37:09 2009 From: trac at galois.com (GHC) Date: Mon Oct 26 08:13:46 2009 Subject: [GHC] #3610: Installer has hard-coded path /usr/bin/strip In-Reply-To: <047.497d60e15e84c11bbc4d65529d1dd7a9@localhost> References: <047.497d60e15e84c11bbc4d65529d1dd7a9@localhost> Message-ID: <056.12fc182f4d6cd08a50ef9d36e0bc57ae@localhost> #3610: Installer has hard-coded path /usr/bin/strip ------------------------------+--------------------------------------------- Reporter: YitzGale | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by YitzGale): To be more clear, the problem described in the blog post occurred while trying to install the binary build of GHC 6.10.4 for x86_64. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 26 15:42:30 2009 From: trac at galois.com (GHC) Date: Mon Oct 26 15:19:06 2009 Subject: [GHC] #3611: X11-xft-0.3 for xmonad-0.9 on Ubuntu karmic koala Message-ID: <049.a78879da6dc9806206186e2997ef3773@localhost> #3611: X11-xft-0.3 for xmonad-0.9 on Ubuntu karmic koala -----------------------+---------------------------------------------------- Reporter: neuroserve | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86 -----------------------+---------------------------------------------------- toens@wintermute:~/src/X11-xft-0.3$ runhaskell Setup.lhs build Preprocessing library X11-xft-0.3... Building X11-xft-0.3... Binary: Int64 truncated to fit in 32 bit Int ghc: panic! (the 'impossible' happened) (GHC version 6.10.4 for i386-unknown-linux): Prelude.chr: bad argument Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug I don't know really much about haskell. I just wanted to compile X11 and X11-xft for xmonad-0.9. I'm ready to answer any questions about this. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 26 16:00:03 2009 From: trac at galois.com (GHC) Date: Mon Oct 26 15:37:02 2009 Subject: [GHC] #2859: Reduce coercion terms to normal form In-Reply-To: <046.917b9c8dce2bb6503705b21f0c69b712@localhost> References: <046.917b9c8dce2bb6503705b21f0c69b712@localhost> Message-ID: <055.1890c6896a38047faf5e0c5cb033d205@localhost> #2859: Reduce coercion terms to normal form ---------------------------------------------+------------------------------ Reporter: simonpj | Owner: Type: compile-time performance bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------------------+------------------------------ Changes (by guest): * cc: tom.schrijvers@cs.kuleuven.be (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 26 18:12:33 2009 From: trac at galois.com (GHC) Date: Mon Oct 26 17:49:08 2009 Subject: [GHC] #3612: Installing the binary tarball requires build tools (binutils, gcc, etc.) Message-ID: <047.24fbf86abe74d373d1eb2c5e5e6641fc@localhost> #3612: Installing the binary tarball requires build tools (binutils, gcc, etc.) -----------------------------+---------------------------------------------- Reporter: matthijs | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- When installing the binary tarball (e.g., http://www.haskell.org/ghc/dist/6.10.4/ghc-6.10.4-i386-unknown- linux-n.tar.bz2), you need to run {{{./configure && make install}}}. However, configure does the full build-time set of checks, complaining about the lack of binutils, gcc, and whatnot. I'm trying to build a small system which doesn't have any build tools, and I'd rather not install them just for satisfying configure :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 26 19:06:36 2009 From: trac at galois.com (GHC) Date: Mon Oct 26 18:43:11 2009 Subject: [GHC] #3612: Installing the binary tarball requires build tools (binutils, gcc, etc.) In-Reply-To: <047.24fbf86abe74d373d1eb2c5e5e6641fc@localhost> References: <047.24fbf86abe74d373d1eb2c5e5e6641fc@localhost> Message-ID: <056.17e2a30ac13ccd2aac1ccc124b5f6ef0@localhost> #3612: Installing the binary tarball requires build tools (binutils, gcc, etc.) ------------------------------+--------------------------------------------- Reporter: matthijs | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by matthijs): Also see [http://trac.haskell.org/haskell-platform/ticket/95 Haskell Platform ticket #95] which also doesn't work without build utilities installed (but due to completely different reasons). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 26 19:36:33 2009 From: trac at galois.com (GHC) Date: Mon Oct 26 19:13:12 2009 Subject: [GHC] #3557: SIMD operations in GHC.Prim In-Reply-To: <044.db8b087837e05fdd9a6c4304c2acd80c@localhost> References: <044.db8b087837e05fdd9a6c4304c2acd80c@localhost> Message-ID: <053.20b26ee898f0e390530726a5ef795c2f@localhost> #3557: SIMD operations in GHC.Prim ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler (NCG) | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by guest): I have tried some SSE instructions using harpy in GHC-6.10, but the test program terminates with: {{{ghci: pthread_mutex_lock.c:82: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed.}}} Of course, this can be due to a programming error. However, is the Haskell runtime prepared for SSE instructions at all? If two threads use XMM registers - do their usage of these registers interfer? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 27 02:18:46 2009 From: trac at galois.com (GHC) Date: Tue Oct 27 01:55:37 2009 Subject: [GHC] #2859: Reduce coercion terms to normal form In-Reply-To: <046.917b9c8dce2bb6503705b21f0c69b712@localhost> References: <046.917b9c8dce2bb6503705b21f0c69b712@localhost> Message-ID: <055.49fb868cd1ba652a3b93940f14e63e64@localhost> #2859: Reduce coercion terms to normal form ---------------------------------------------+------------------------------ Reporter: simonpj | Owner: Type: compile-time performance bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------------------+------------------------------ Changes (by kfrdbs): * cc: kfrdbs@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 27 05:18:00 2009 From: trac at galois.com (GHC) Date: Tue Oct 27 04:54:34 2009 Subject: [GHC] #3611: X11-xft-0.3 for xmonad-0.9 on Ubuntu karmic koala In-Reply-To: <049.a78879da6dc9806206186e2997ef3773@localhost> References: <049.a78879da6dc9806206186e2997ef3773@localhost> Message-ID: <058.3337f1cce333b37fd7065449db6f1716@localhost> #3611: X11-xft-0.3 for xmonad-0.9 on Ubuntu karmic koala ---------------------------+------------------------------------------------ Reporter: neuroserve | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ---------------------------+------------------------------------------------ Changes (by simonpj): * difficulty: => Unknown Comment: Looks like a dup of #3635 and #3477. Have you removed all .hi files? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 27 05:25:41 2009 From: trac at galois.com (GHC) Date: Tue Oct 27 05:02:16 2009 Subject: [GHC] #3613: Better error messages for do-notation Message-ID: <046.85938a15dfc94a0396b655296d53527a@localhost> #3613: Better error messages for do-notation --------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.10.4 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple --------------------------------------+------------------------------------- C Rodrigues [red5_2@hotmail.com] writes: In this example, fun1 and fun2 are basically the same. The type error is because they try to run an IO () together with a Maybe (). {{{ > import Control.Monad > > foo :: Maybe () > foo = return () > > bar :: IO () > bar = return () > > fun1 = let fooThen m = foo>> m > in fooThen (bar>> undefined) > > fun2 = let fooThen m = foo>> m > in fooThen (do {bar; undefined}) }}} With ghc 6.10.4, both functions attribute the error message to `bar'. However, the expected and inferred monads are swapped. * fun1 produces the error message: {{{ Couldn't match expected type `Maybe a' against inferred type `IO ()' In the first argument of `(>>=)', namely `bar' }}} * fun2 produces the error message: {{{ Couldn't match expected type `IO ()' against inferred type `Maybe ()' In a stmt of a 'do' expression: bar }}} It's confusing because 'bar' is inferred to have type Maybe (), even though it's explicitly declared to be an IO (). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 27 05:29:30 2009 From: trac at galois.com (GHC) Date: Tue Oct 27 05:06:03 2009 Subject: [GHC] #3613: Better error messages for do-notation In-Reply-To: <046.85938a15dfc94a0396b655296d53527a@localhost> References: <046.85938a15dfc94a0396b655296d53527a@localhost> Message-ID: <055.effb7a6d9e63c1df60ae00a3051c6d02@localhost> #3613: Better error messages for do-notation ----------------------------------------+----------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------+----------------------------------- Comment (by simonpj): I agree this is confusing. I had a look at the code. When typechecking `x <- rhs`, GHC does this (`TcMatches.tcDoStmt`) * First infers the type of `rhs` * Then feed that into a typecheck of the bind operator `>>=` Instead, the programmer expects the reverse, so that information about which monad is involved gets fed into the argument. I don't expect anyone else to understand this note; it's an aide-memoire for me to remind me to fix this. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 27 07:16:56 2009 From: trac at galois.com (GHC) Date: Tue Oct 27 06:53:31 2009 Subject: [GHC] #3612: Installing the binary tarball requires build tools (binutils, gcc, etc.) In-Reply-To: <047.24fbf86abe74d373d1eb2c5e5e6641fc@localhost> References: <047.24fbf86abe74d373d1eb2c5e5e6641fc@localhost> Message-ID: <056.31c6821ce7dc42825e0b2a0572da3b05@localhost> #3612: Installing the binary tarball requires build tools (binutils, gcc, etc.) ------------------------------+--------------------------------------------- Reporter: matthijs | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by duncan): You need gcc etc to be able to use ghc, so surely it is right for the ./configure script to check for them. What do you expect to be able to do with ghc but without gcc et al? I suppose it'd be possible to use ghci and runghc but not use ghc to compile standalone programs. Is that what you're trying to do? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 27 07:33:33 2009 From: trac at galois.com (GHC) Date: Tue Oct 27 07:10:06 2009 Subject: [GHC] #3612: Installing the binary tarball requires build tools (binutils, gcc, etc.) In-Reply-To: <047.24fbf86abe74d373d1eb2c5e5e6641fc@localhost> References: <047.24fbf86abe74d373d1eb2c5e5e6641fc@localhost> Message-ID: <056.0b44c7cc42f342e3e380fcf758adbdd6@localhost> #3612: Installing the binary tarball requires build tools (binutils, gcc, etc.) ------------------------------+--------------------------------------------- Reporter: matthijs | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by matthijs): I hadn't thought ahead that far, turned out I needed ghc for building the platform and other packages anyway... So, perhaps you're right and this is not an issue at all, though I was kinda confused by needing compile tools for installing a binary tarball. Perhaps the configure script could output a message for this stuff, though I think that's not too easy in autoconf? Anyway, feel free to close this ticket :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 27 10:39:49 2009 From: trac at galois.com (GHC) Date: Tue Oct 27 10:16:25 2009 Subject: [GHC] #3614: Cabal file parser can't handle colon in description Message-ID: <042.a1fcf46934be35bcc5f0659de5b6d5ca@localhost> #3614: Cabal file parser can't handle colon in description -----------------------------+---------------------------------------------- Reporter: dsf | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 6.12.1 RC1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- The description field of the cabal file in the haskell-mtl package currently in debian sid contains an url with a colon, which leads to this error: ghc-pkg: 13: unrecognised field or section: "()," This comes from Cabal.Distribution.ParseUtils. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 27 12:03:32 2009 From: trac at galois.com (GHC) Date: Tue Oct 27 11:40:10 2009 Subject: [GHC] #3615: GHCi doesn't allow the use of imported data contructors Message-ID: <047.8819d6591abc7952ad9279636b532fe8@localhost> #3615: GHCi doesn't allow the use of imported data contructors ---------------------+------------------------------------------------------ Reporter: blamario | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86 ---------------------+------------------------------------------------------ There are two modules in this simplified scenario. The main module is Main.hs and contains the following three lines of code. {{{ module Main where import Imp (D(..)) main = print D1 }}} Module Imp contains a single data type definition: {{{ module Imp where data D = D1 | D2 deriving Show }}} Now, when I compile Main everything works. GHCi doesn't complain when it loads the main module either, but it doesn't allow me to construct D on its command line. This makes no sense to me. {{{ $ ghc --make Main.hs [1 of 2] Compiling Imp ( Imp.hs, Imp.o ) [2 of 2] Compiling Main ( Main.hs, Main.o ) Linking Main ... $ ./Main D1 $ ghci Main.hs GHCi, version 6.10.4: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Ok, modules loaded: Main, Imp. Prelude Main> D1 :1:0: Not in scope: data constructor `D1' Prelude Main> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 27 13:58:43 2009 From: trac at galois.com (GHC) Date: Tue Oct 27 13:35:19 2009 Subject: [GHC] #3557: SIMD operations in GHC.Prim In-Reply-To: <044.db8b087837e05fdd9a6c4304c2acd80c@localhost> References: <044.db8b087837e05fdd9a6c4304c2acd80c@localhost> Message-ID: <053.5051062b712dd96436faa1a841cea868@localhost> #3557: SIMD operations in GHC.Prim ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler (NCG) | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by guest): Replying to [comment:3 guest]: > {{{ghci: pthread_mutex_lock.c:82: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed.}}} Yes, this was a stupid stack error. My program does now work with SSE commands in a single thread. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 27 16:28:48 2009 From: trac at galois.com (GHC) Date: Tue Oct 27 16:05:20 2009 Subject: [GHC] #3611: X11-xft-0.3 for xmonad-0.9 on Ubuntu karmic koala In-Reply-To: <049.a78879da6dc9806206186e2997ef3773@localhost> References: <049.a78879da6dc9806206186e2997ef3773@localhost> Message-ID: <058.04ce96e05eb8580c6880e8d5b2900324@localhost> #3611: X11-xft-0.3 for xmonad-0.9 on Ubuntu karmic koala ---------------------------+------------------------------------------------ Reporter: neuroserve | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ---------------------------+------------------------------------------------ Comment (by neuroserve): No, I had not. Now I have - and everything compiles like a charm. Thx. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 27 16:36:23 2009 From: trac at galois.com (GHC) Date: Tue Oct 27 16:12:55 2009 Subject: [GHC] #3611: X11-xft-0.3 for xmonad-0.9 on Ubuntu karmic koala In-Reply-To: <049.a78879da6dc9806206186e2997ef3773@localhost> References: <049.a78879da6dc9806206186e2997ef3773@localhost> Message-ID: <058.5c6f1f36a9e2a1549570a4b2e24db8e6@localhost> #3611: X11-xft-0.3 for xmonad-0.9 on Ubuntu karmic koala ---------------------------+------------------------------------------------ Reporter: neuroserve | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ---------------------------+------------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => invalid Comment: Thanks for the confirmation. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 28 05:36:43 2009 From: trac at galois.com (GHC) Date: Wed Oct 28 05:13:14 2009 Subject: [GHC] #3616: ghci crash from :l Message-ID: <047.24d1ad3dc7106d0841f03798edf8d963@localhost> #3616: ghci crash from :l ---------------------+------------------------------------------------------ Reporter: eflister | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.3 | Severity: normal Keywords: | Testcase: Os: MacOS X | Architecture: Unknown/Multiple ---------------------+------------------------------------------------------ i got the following from trying to :l this file Prelude> :l tmp.hs ghc: panic! (the 'impossible' happened) (GHC version 6.10.3 for i386-apple-darwin): getOptions'.parseLanguage(2) went past eof token Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 28 05:39:48 2009 From: trac at galois.com (GHC) Date: Wed Oct 28 05:16:18 2009 Subject: [GHC] #3616: ghci crash from :l In-Reply-To: <047.24d1ad3dc7106d0841f03798edf8d963@localhost> References: <047.24d1ad3dc7106d0841f03798edf8d963@localhost> Message-ID: <056.bbe6b794d16ea24d8c3abf2bd9ba6221@localhost> #3616: ghci crash from :l ----------------------+----------------------------------------------------- Reporter: eflister | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Testcase: Os: MacOS X | Architecture: x86 ----------------------+----------------------------------------------------- Changes (by eflister): * architecture: Unknown/Multiple => x86 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 28 05:42:54 2009 From: trac at galois.com (GHC) Date: Wed Oct 28 05:19:25 2009 Subject: [GHC] #3616: ghci crash from :l In-Reply-To: <047.24d1ad3dc7106d0841f03798edf8d963@localhost> References: <047.24d1ad3dc7106d0841f03798edf8d963@localhost> Message-ID: <056.fca2c9dd53e64eaf4103e23f12e37ea1@localhost> #3616: ghci crash from :l ----------------------+----------------------------------------------------- Reporter: eflister | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Testcase: Os: MacOS X | Architecture: x86 ----------------------+----------------------------------------------------- Changes (by eflister): * cc: erik.flister@gmail.com (added) Comment: consistently occurs even in a fresh ghci session. i'm on osx 10.5.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 28 05:50:17 2009 From: trac at galois.com (GHC) Date: Wed Oct 28 05:26:47 2009 Subject: [GHC] #3616: ghci crash from :l In-Reply-To: <047.24d1ad3dc7106d0841f03798edf8d963@localhost> References: <047.24d1ad3dc7106d0841f03798edf8d963@localhost> Message-ID: <056.ac4c96ef842bc6fd68296fa8377f2d8e@localhost> #3616: ghci crash from :l ----------------------+----------------------------------------------------- Reporter: eflister | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Testcase: Os: MacOS X | Architecture: x86 ----------------------+----------------------------------------------------- Comment (by eflister): ha ha, i tracked it down to having added -XNoMonomo... to the pragmas (copied and pasted from the error), rather than omitting the -X. would be nice for the error to print out both the -X and {-# LANGUAGE #-} versions for easy cut and pasting. i prefer the latter if you only have one. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 28 07:05:35 2009 From: trac at galois.com (GHC) Date: Wed Oct 28 06:42:08 2009 Subject: [GHC] #3617: There is no -debug runtime in 6.12 RC1 Message-ID: <044.eb7d8be022ebe7b2d677ab67a54a54d6@localhost> #3617: There is no -debug runtime in 6.12 RC1 -----------------------+---------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.12.1 RC1 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86_64 (amd64) -----------------------+---------------------------------------------------- {{{ $ cat Hello.hs module Main where main = print "Hello world" }}} {{{ $ ghc -debug --make Hello.hs [1 of 1] Compiling Main ( Hello.hs, Hello.o ) Linking Hello ... /usr/bin/ld: cannot find -lHSrts_debug collect2: ld returned 1 exit status }}} Interestingly there is a debug runtime .so, but no .a. This seems like an oversight. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 28 07:17:51 2009 From: trac at galois.com (GHC) Date: Wed Oct 28 06:54:22 2009 Subject: [GHC] #3618: getStablePtr is called too early with dynamic libraries Message-ID: <044.ace7007dd565206bf92f9640eed34f4d@localhost> #3618: getStablePtr is called too early with dynamic libraries -----------------------+---------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.12.1 RC1 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86_64 (amd64) -----------------------+---------------------------------------------------- {{{ $ cat Hello.hs module Main where main = print "Hello world" }}} {{{ $ ghc -debug -dynamic --make Hello.hs && ./Hello +RTS -DS Linking Hello ... "Hello world" Warning: Freeing non-allocated memory at 0x1ff87850 Warning: Freeing non-allocated memory at 0x1ff85820 Warning: Freeing non-allocated memory at 0x1ff85010 Warning: Freeing non-allocated memory at 0x1ff89860 Warning: Freeing non-allocated memory at 0x1ff8b860 Warning: 192 bytes at 0x1ff9b920 still allocated at shutdown Warning: 2048 bytes at 0x1ff8ef50 still allocated at shutdown Warning: 48 bytes at 0x1ff8eef0 still allocated at shutdown Warning: 2048 bytes at 0x1ff8e6c0 still allocated at shutdown Warning: 48 bytes at 0x1ff8e660 still allocated at shutdown Warning: 2048 bytes at 0x1ff8de30 still allocated at shutdown Warning: 48 bytes at 0x1ff8ddd0 still allocated at shutdown Warning: 4100 bytes at 0x1ff8cca0 still allocated at shutdown Warning: 16 bytes at 0x1ff8c980 still allocated at shutdown Warning: 16 bytes at 0x1ff8c940 still allocated at shutdown Warning: 4 bytes at 0x1ff8c880 still allocated at shutdown Warning: 5 bytes at 0x1ff8c840 still allocated at shutdown Warning: 8 bytes at 0x1ff8c800 still allocated at shutdown Warning: 32 bytes at 0x1ff8c7b0 still allocated at shutdown }}} Note the freeing of non-allocated memory. This is because "base" contains a foreign export of forkOS_entry. Foreign exports are desugared to uses of __attribute__((constructor)) which call getStablePtr (in this case initializing stginit_export_base_ControlziConcurrent_zdfforkOSzuentryzua1bd). On our system this initializer is being run when libHSbase-4.2.0.0-ghc6.12.0.20091010.so gets loaded, which is before the runtime is actually initialized. This leads to a call to allocHashTable (from initStablePtrTable) which allocates memory. This allocation is recorded in the allocs linked list but when the runtime is initialized initAllocator gets called which overwrites that entry. Hence when we come to free that hash table we free a pointer which is not in the allocs list and get the warning. I don't get this message with static linking on 6.10 - I can't check 6.12 because there is no static debug runtime for 6.12 RC1 by default. This makes me suspect that this is a peculiarity of shared object initialization, and the call to getStablePtr will happen more lazily with static linking (probably on the first reference to a function in base), such that it comes after RTS initialization is complete. I observed this behaviour when trying to use -DS to isolate a segfault in Haskell code in a very large program using -dynamic and Haskell shared libraries. I'm not sure if this problem is actually causing my segfault, but it certainly feels like it has the potential to do so, especially as I tend to get my segfaults from Evac.c, which could be affected by the stable ptr table. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 28 09:48:13 2009 From: trac at galois.com (GHC) Date: Wed Oct 28 09:24:43 2009 Subject: [GHC] #3619: allow to set ghc search path globally (a'la CPATH) Message-ID: <045.08cbe5d68bcc5ce3a0c356e18d98ad1a@localhost> #3619: allow to set ghc search path globally (a'la CPATH) -----------------------------+---------------------------------------------- Reporter: tari3x | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- I'd like a mechanism for ghc similar to setting the CPATH variable for gcc. I'd like ghc to look in the given list of paths every time it compiles something, without me having to retype the flags. For ghci there is .ghci, but it gets ignored when I run ghc. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 28 11:07:43 2009 From: trac at galois.com (GHC) Date: Wed Oct 28 10:47:52 2009 Subject: [GHC] #3620: The seeds generated by split are not independent Message-ID: <052.ef1abc8d66f675d62b108c409dd80993@localhost> #3620: The seeds generated by split are not independent -----------------------------+---------------------------------------------- Reporter: NickSmallbone | Owner: Type: bug | Status: new Priority: normal | Component: libraries/random Version: 6.11 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Suppose we split a seed into two like this: {{{ split' :: StdGen -> (StdGen, StdGen) split' g = (g12, g21) where (_, g12) = split g1 (g21, _) = split g2 (g1, g2) = split g }}} Since g1 and g2 are independent, g12 and g21 ought to be too. But they're not! If we use both of g12 and g21 to generate a random number in the range [0..10], then the two numbers ought to be equal 1/11 of the time. In fact, they're never equal. Here is a test program that ought to return True 1/11 of the time but actually always returns False: {{{ sample :: StdGen -> (Int, Int) sample g = (fst (randomR (0, 10) g1), fst (randomR (0, 10) g2)) where (g1, g2) = split' g test :: StdGen -> Bool test g = fst (sample g) == snd (sample g) }}} I attached a program that prints the distribution of values from {{{test}}} for other ranges than [0..10]. The distribution is always quite bad no matter what the range is. The upshot of all this is that the following QuickCheck (version 2) property always passes, even though it's false: {{{ import Test.QuickCheck import Text.Show.Functions newtype Eleven = Eleven Int deriving Eq instance Arbitrary Eleven where arbitrary = fmap Eleven (choose (0, 10)) prop :: (Int -> Eleven) -> Bool prop f = f 5 /= f 6 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 28 11:58:14 2009 From: trac at galois.com (GHC) Date: Wed Oct 28 11:34:43 2009 Subject: [GHC] #3575: mkStdGen and split conspire to make some programs predictable In-Reply-To: <047.6485fb2275f266e278f6578e798e2d4e@localhost> References: <047.6485fb2275f266e278f6578e798e2d4e@localhost> Message-ID: <056.e0c5c669c85b69e94749773f1a822c44@localhost> #3575: mkStdGen and split conspire to make some programs predictable ---------------------------------+------------------------------------------ Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/random | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonpj): See also #3620 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 28 11:58:03 2009 From: trac at galois.com (GHC) Date: Wed Oct 28 11:35:15 2009 Subject: [GHC] #3620: The seeds generated by split are not independent In-Reply-To: <052.ef1abc8d66f675d62b108c409dd80993@localhost> References: <052.ef1abc8d66f675d62b108c409dd80993@localhost> Message-ID: <061.58e4c8e7ef67453fcbd3851589f869d9@localhost> #3620: The seeds generated by split are not independent ---------------------------------+------------------------------------------ Reporter: NickSmallbone | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/random | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * difficulty: => Unknown Comment: Indeed that looks bad. This is a Random library problem, like #3575. Can anyone help fix it, please? It would make sense to tackle #3575 at the same time. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 28 12:06:07 2009 From: trac at galois.com (GHC) Date: Wed Oct 28 11:42:37 2009 Subject: [GHC] #3439: Improve the setup for ticky In-Reply-To: <046.97ec1b5f2b20c06c8559b26055a95a61@localhost> References: <046.97ec1b5f2b20c06c8559b26055a95a61@localhost> Message-ID: <055.4890cba095eaa7cb0ce7964051ca1cd8@localhost> #3439: Improve the setup for ticky ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: simonmar Type: feature request | Status: new Priority: high | Milestone: 6.14.1 Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * owner: => simonmar Comment: Not quite: when linking you have to specify `-debug`, whereas `-ticky` should do. Also in the implementation there is still at ticky "way", and that just isn't right. So the ticket should stay open. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 28 12:16:23 2009 From: trac at galois.com (GHC) Date: Wed Oct 28 11:52:51 2009 Subject: [GHC] #3613: Better error messages for do-notation In-Reply-To: <046.85938a15dfc94a0396b655296d53527a@localhost> References: <046.85938a15dfc94a0396b655296d53527a@localhost> Message-ID: <055.f0c38d365de7d3b843adb07a20f8cb21@localhost> #3613: Better error messages for do-notation ----------------------------------------+----------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14 branch Component: Compiler (Type checker) | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------+----------------------------------- Changes (by simonpj): * milestone: => 6.14 branch Comment: I've improved matters as a side consequence of {{{ Wed Oct 28 06:35:54 PDT 2009 simonpj@microsoft.com * Add 'rec' to stmts in a 'do', and deprecate 'mdo' The change is this (see Trac #2798). ... }}} However the interaction of GADTs and impredicative polymorphism defeated me, so I only dealt with `(>>)` and not `(>>=)`. When the long-heralded re-engineering of type inference for GADTs takes place, I'll come back to this. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 28 13:26:17 2009 From: trac at galois.com (GHC) Date: Wed Oct 28 13:02:48 2009 Subject: [GHC] #3621: "No match in record selector Var.tcTyVarDetails" with incorrect multi-parameter newtype derivation Message-ID: <042.f63ab5c4610c49adbe9ab2375f16d852@localhost> #3621: "No match in record selector Var.tcTyVarDetails" with incorrect multi- parameter newtype derivation -----------------------------+---------------------------------------------- Reporter: pwb | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: minor Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- {{{ {-# LANGUAGE GeneralizedNewtypeDeriving #-} import Control.Monad.State newtype WrappedState s a = WS { runWS :: State s a } deriving (Monad, MonadState state) }}} Note that the 'deriving' for {{{MonadState}}} has the wrong variable name. It should be rejected with something like "not in scope: type variable 'state'" but instead this happens: {{{ [pwb@rhuidean tmp]$ ghc bug.hs ghc: panic! (the 'impossible' happened) (GHC version 6.10.4 for x86_64-unknown-linux): No match in record selector Var.tcTyVarDetails }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 28 13:35:52 2009 From: trac at galois.com (GHC) Date: Wed Oct 28 13:12:24 2009 Subject: [GHC] #3590: panic (the impossible happened) when compiling with -O2 In-Reply-To: <046.ec4c1739f3567725a37e4c4cfcc214a3@localhost> References: <046.ec4c1739f3567725a37e4c4cfcc214a3@localhost> Message-ID: <055.9a346355591ae4f9c495b5a363c05046@localhost> #3590: panic (the impossible happened) when compiling with -O2 ---------------------------------------------------+------------------------ Reporter: yairchu | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: indexed-types/should_compile/T3590 | Os: MacOS X Architecture: x86 | ---------------------------------------------------+------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 28 14:53:06 2009 From: trac at galois.com (GHC) Date: Wed Oct 28 14:29:37 2009 Subject: [GHC] #2273: inlining defeats seq In-Reply-To: <044.9c3223a55b4d3223b10ccf35be7e7d4f@localhost> References: <044.9c3223a55b4d3223b10ccf35be7e7d4f@localhost> Message-ID: <053.66127e925a60af1276f4c3a0b56c65c6@localhost> #2273: inlining defeats seq ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * milestone: => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 28 14:55:41 2009 From: trac at galois.com (GHC) Date: Wed Oct 28 14:32:11 2009 Subject: [GHC] #3494: missing build system dependency In-Reply-To: <045.8de98aacac9d8b317157450367a72303@localhost> References: <045.8de98aacac9d8b317157450367a72303@localhost> Message-ID: <054.29cfdaf7dd9683cd004f7b2a2e60a64e@localhost> #3494: missing build system dependency ---------------------------------+------------------------------------------ Reporter: duncan | Owner: igloo Type: bug | Status: reopened Priority: high | Milestone: 6.12.1 Component: Build System | Version: 6.11 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * priority: normal => high * milestone: => 6.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 28 14:57:46 2009 From: trac at galois.com (GHC) Date: Wed Oct 28 14:34:17 2009 Subject: [GHC] #3541: Allow local foreign imports In-Reply-To: <044.f182d5c0327086f8b5193630cf333bb0@localhost> References: <044.f182d5c0327086f8b5193630cf333bb0@localhost> Message-ID: <053.6103891c861f83ba5341de600de7632d@localhost> #3541: Allow local foreign imports ---------------------------------+------------------------------------------ Reporter: mokus | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler (FFI) | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.14.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 28 15:20:47 2009 From: trac at galois.com (GHC) Date: Wed Oct 28 14:57:22 2009 Subject: [GHC] #3543: -fext-core doesn't force recompilation when .hcr file doesn't exist In-Reply-To: <042.a500bc81bb090118bd5e70ada170bc6f@localhost> References: <042.a500bc81bb090118bd5e70ada170bc6f@localhost> Message-ID: <051.375d91ede80b0c34273e98e874c9a097@localhost> #3543: -fext-core doesn't force recompilation when .hcr file doesn't exist ---------------------------------+------------------------------------------ Reporter: tim | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: Driver | Version: 6.10.4 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 28 15:22:27 2009 From: trac at galois.com (GHC) Date: Wed Oct 28 14:58:56 2009 Subject: [GHC] #3545: As-patterns for type signatures In-Reply-To: <053.fe8bf7158bc08565495d5ddfb70742d3@localhost> References: <053.fe8bf7158bc08565495d5ddfb70742d3@localhost> Message-ID: <062.f4a89ffe8eebca40e236a59f9a5edf50@localhost> #3545: As-patterns for type signatures ----------------------------------------+----------------------------------- Reporter: LouisWasserman | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler (Type checker) | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------+----------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.14.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 28 15:46:28 2009 From: trac at galois.com (GHC) Date: Wed Oct 28 15:22:57 2009 Subject: [GHC] #3547: Improve granularity of UndecidableInstances In-Reply-To: <042.ab1d6403ab4b4f4b9e3a8bbdc17f05e1@localhost> References: <042.ab1d6403ab4b4f4b9e3a8bbdc17f05e1@localhost> Message-ID: <051.0acbbe8c1a3042f1ee0547febf0a84c7@localhost> #3547: Improve granularity of UndecidableInstances ---------------------------------+------------------------------------------ Reporter: ksf | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.14.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 28 15:51:44 2009 From: trac at galois.com (GHC) Date: Wed Oct 28 15:28:14 2009 Subject: [GHC] #3548: test T3294 incorrectly reported as error for unregistered build In-Reply-To: <045.3508f93b8c2d71a124ee09b2c47fcd9e@localhost> References: <045.3508f93b8c2d71a124ee09b2c47fcd9e@localhost> Message-ID: <054.8831f156fe85830b707a602ca5b83b18@localhost> #3548: test T3294 incorrectly reported as error for unregistered build ---------------------------------+------------------------------------------ Reporter: dterei | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Test Suite | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: T3294 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * owner: => igloo * difficulty: => Unknown * milestone: => 6.12.1 Comment: Thanks for the report. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 28 15:52:16 2009 From: trac at galois.com (GHC) Date: Wed Oct 28 15:29:34 2009 Subject: [GHC] #3549: unlit does not follow H98 spec In-Reply-To: <045.eacb9764be0b8b701a8c620148ff0200@localhost> References: <045.eacb9764be0b8b701a8c620148ff0200@localhost> Message-ID: <054.7a43e14bf8acaa3018aee3140b89c71a@localhost> #3549: unlit does not follow H98 spec ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * milestone: => 6.14.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 28 15:58:26 2009 From: trac at galois.com (GHC) Date: Wed Oct 28 15:35:08 2009 Subject: [GHC] #3550: Dynamic libraries don't work on Mac OS/X In-Reply-To: <056.c6f0034a4d5f342c60f11476270241e0@localhost> References: <056.c6f0034a4d5f342c60f11476270241e0@localhost> Message-ID: <065.482551c52023c2270827a7b532ca68d8@localhost> #3550: Dynamic libraries don't work on Mac OS/X ----------------------------------------------------------------+----------- Reporter: StephenBlackheath | Owner: StephenBlackheath Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: Compiler | Version: 6.11 Severity: major | Resolution: Keywords: dynamic mac osx | Difficulty: Unknown Testcase: http://upcycle.it/~blackh/ghc/test-case.tar.bz2 | Os: MacOS X Architecture: Unknown/Multiple | ----------------------------------------------------------------+----------- Changes (by igloo): * milestone: => 6.12.2 Comment: Too late for 6.12.1, but let's see if this is suitable for a point release in the 6.12 branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 28 15:58:45 2009 From: trac at galois.com (GHC) Date: Wed Oct 28 15:35:14 2009 Subject: [GHC] #3563: A couple of additions to Data.Bits In-Reply-To: <045.1f98bcf2b0cef8bd6c1373dcce0d242a@localhost> References: <045.1f98bcf2b0cef8bd6c1373dcce0d242a@localhost> Message-ID: <054.00011de54c6d6b126e67ae0f943c3af0@localhost> #3563: A couple of additions to Data.Bits ---------------------------------+------------------------------------------ Reporter: porges | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => Not GHC -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 28 17:14:06 2009 From: trac at galois.com (GHC) Date: Wed Oct 28 16:50:36 2009 Subject: [GHC] #3566: Install fails on Windows In-Reply-To: <046.53c3e977cd2a3f2d06ab45a50a92a739@localhost> References: <046.53c3e977cd2a3f2d06ab45a50a92a739@localhost> Message-ID: <055.22676d6994a54d9666f5986e5324fddb@localhost> #3566: Install fails on Windows ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Now fixed in HEAD and 6.12. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 28 17:15:38 2009 From: trac at galois.com (GHC) Date: Wed Oct 28 16:52:07 2009 Subject: [GHC] #3569: ghci can't handle utf-8 chinese char correctly when modify. In-Reply-To: <044.9c568ba4db1530f0bbd9af30f9b67dee@localhost> References: <044.9c568ba4db1530f0bbd9af30f9b67dee@localhost> Message-ID: <053.b9da73ec37f48f1ba8dd4c657802e69e@localhost> #3569: ghci can't handle utf-8 chinese char correctly when modify. -------------------------------+-------------------------------------------- Reporter: guest | Owner: judah Type: bug | Status: assigned Priority: normal | Milestone: Not GHC Component: GHCi | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => Not GHC -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 28 17:16:29 2009 From: trac at galois.com (GHC) Date: Wed Oct 28 16:52:58 2009 Subject: [GHC] #3571: Bizzarely bloated binaries In-Reply-To: <044.a58781a47fed5e173c154c742b96ee46@localhost> References: <044.a58781a47fed5e173c154c742b96ee46@localhost> Message-ID: <053.5f77340ef9ef81934d6f703805ebfde5@localhost> #3571: Bizzarely bloated binaries ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12 branch Comment: Thanks for the report. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 28 17:28:40 2009 From: trac at galois.com (GHC) Date: Wed Oct 28 17:05:10 2009 Subject: [GHC] #3575: mkStdGen and split conspire to make some programs predictable In-Reply-To: <047.6485fb2275f266e278f6578e798e2d4e@localhost> References: <047.6485fb2275f266e278f6578e798e2d4e@localhost> Message-ID: <056.76c216f48ac399384cc6e665c33d36fa@localhost> #3575: mkStdGen and split conspire to make some programs predictable ---------------------------------+------------------------------------------ Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: libraries/random | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * milestone: => _|_ -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 28 17:28:58 2009 From: trac at galois.com (GHC) Date: Wed Oct 28 17:05:29 2009 Subject: [GHC] #3577: Complete support for Data Parallel Haskell In-Reply-To: <041.e54cf544394515fd2960400b723e2495@localhost> References: <041.e54cf544394515fd2960400b723e2495@localhost> Message-ID: <050.444fad4386fc5950854d3d072ec2f70f@localhost> #3577: Complete support for Data Parallel Haskell --------------------------------------+------------------------------------- Reporter: rl | Owner: rl Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Data Parallel Haskell | Version: 6.13 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | --------------------------------------+------------------------------------- Changes (by igloo): * milestone: => _|_ -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 28 19:20:36 2009 From: trac at galois.com (GHC) Date: Wed Oct 28 18:57:06 2009 Subject: [GHC] #3584: type signature involving a type family rejected In-Reply-To: <048.c49cd8f6581150501f12653a3821d1e8@localhost> References: <048.c49cd8f6581150501f12653a3821d1e8@localhost> Message-ID: <057.71c0e2e9a34be720bd3047740db37eab@localhost> #3584: type signature involving a type family rejected ----------------------------------------+----------------------------------- Reporter: baramoglo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler (Type checker) | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86 | ----------------------------------------+----------------------------------- Changes (by igloo): * milestone: => 6.14.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 28 19:32:32 2009 From: trac at galois.com (GHC) Date: Wed Oct 28 19:09:01 2009 Subject: [GHC] #3582: Compiling with optimizations on hurts performance In-Reply-To: <048.4bb5f69a00bcb236ccbbc2a5b2badbb3@localhost> References: <048.4bb5f69a00bcb236ccbbc2a5b2badbb3@localhost> Message-ID: <057.d011215faa76e8de5fc00a56ea6719e7@localhost> #3582: Compiling with optimizations on hurts performance ---------------------------------+------------------------------------------ Reporter: gchrupala | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: major | Resolution: fixed Keywords: optimization | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: Thanks for the report. I can reproduce this with 6.10.4, but not the HEAD or 6.12, so it looks like it's already fixed. Without optimisation: {{{ ./test2 7.22s user 0.12s system 99% cpu 7.375 total }}} With optimisation: {{{ ./test2 5.61s user 0.12s system 99% cpu 5.761 total }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 28 19:33:05 2009 From: trac at galois.com (GHC) Date: Wed Oct 28 19:09:33 2009 Subject: [GHC] #3583: Default view patterns In-Reply-To: <042.09c0286c1bb4575dcdfed8f2d7712a89@localhost> References: <042.09c0286c1bb4575dcdfed8f2d7712a89@localhost> Message-ID: <051.616db7fe4bc5a9f9394a555a84206d04@localhost> #3583: Default view patterns ---------------------------------+------------------------------------------ Reporter: ksf | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * milestone: => 6.14.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 29 04:45:12 2009 From: trac at galois.com (GHC) Date: Thu Oct 29 04:21:41 2009 Subject: [GHC] #3582: Compiling with optimizations on hurts performance In-Reply-To: <048.4bb5f69a00bcb236ccbbc2a5b2badbb3@localhost> References: <048.4bb5f69a00bcb236ccbbc2a5b2badbb3@localhost> Message-ID: <057.87b5cf77011aaefbd2647bcd5d1d018b@localhost> #3582: Compiling with optimizations on hurts performance ---------------------------------+------------------------------------------ Reporter: gchrupala | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: major | Resolution: fixed Keywords: optimization | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonpj): Good! And, just to check, are both faster than the corresponding 6.10.4 figures? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 29 06:52:38 2009 From: trac at galois.com (GHC) Date: Thu Oct 29 06:29:07 2009 Subject: [GHC] #3582: Compiling with optimizations on hurts performance In-Reply-To: <048.4bb5f69a00bcb236ccbbc2a5b2badbb3@localhost> References: <048.4bb5f69a00bcb236ccbbc2a5b2badbb3@localhost> Message-ID: <057.53eafba34e04c900fae1165caea59375@localhost> #3582: Compiling with optimizations on hurts performance ---------------------------------+------------------------------------------ Reporter: gchrupala | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: major | Resolution: fixed Keywords: optimization | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by igloo): Non-optimised 6.10.4 is: {{{ ./test2 6.90s user 0.05s system 99% cpu 6.957 total }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 29 07:04:36 2009 From: trac at galois.com (GHC) Date: Thu Oct 29 06:41:03 2009 Subject: [GHC] #3582: Compiling with optimizations on hurts performance In-Reply-To: <048.4bb5f69a00bcb236ccbbc2a5b2badbb3@localhost> References: <048.4bb5f69a00bcb236ccbbc2a5b2badbb3@localhost> Message-ID: <057.1c1970eddb1ecc2855caa2cc16572d89@localhost> #3582: Compiling with optimizations on hurts performance ---------------------------------+------------------------------------------ Reporter: gchrupala | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: major | Resolution: fixed Keywords: optimization | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonpj): Interesting. So non-optimised is slower in 6.12. But optimised is faster in 6.12. OK, I guess that's enough for this bug. gchrupala, please let us know if you encounter this kind of thing again Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 29 07:30:28 2009 From: trac at galois.com (GHC) Date: Thu Oct 29 07:06:55 2009 Subject: [GHC] #3594: ppc stage1 panic for --enable-shared In-Reply-To: <050.949f308a1cc216a980b2b9af5455bce4@localhost> References: <050.949f308a1cc216a980b2b9af5455bce4@localhost> Message-ID: <059.cfda75fe286d918433659f34e08e5c4c@localhost> #3594: ppc stage1 panic for --enable-shared ----------------------------+----------------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.12.1 RC1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: powerpc | ----------------------------+----------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => _|_ Comment: Thanks for the report. PPC/Linux isn't a tier-1 platform, so I'm setting the milestone to _|_. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 29 09:06:30 2009 From: trac at galois.com (GHC) Date: Thu Oct 29 08:43:02 2009 Subject: [GHC] #3530: GHCi does not work on Snow Leopard In-Reply-To: <043.67172119f9bd273a2158fec836b33117@localhost> References: <043.67172119f9bd273a2158fec836b33117@localhost> Message-ID: <052.a3e3e27c2d9c3fa154db15ca3afa3b20@localhost> #3530: GHCi does not work on Snow Leopard -------------------------+-------------------------------------------------- Reporter: chak | Owner: chak Type: bug | Status: closed Priority: high | Milestone: 6.12.1 Component: GHCi | Version: 6.11 Severity: critical | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by chak): * status: new => closed * resolution: => fixed Comment: Fixed by {{{ Thu Oct 29 23:41:59 EST 2009 Manuel M T Chakravarty * Fix a dynamic linker bug that killed ghci on Snow Leopard }}} '''Please MERGE to the 6.12 branch! ''' -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 29 12:41:00 2009 From: trac at galois.com (GHC) Date: Thu Oct 29 12:17:28 2009 Subject: [GHC] #3621: "No match in record selector Var.tcTyVarDetails" with incorrect multi-parameter newtype derivation In-Reply-To: <042.f63ab5c4610c49adbe9ab2375f16d852@localhost> References: <042.f63ab5c4610c49adbe9ab2375f16d852@localhost> Message-ID: <051.dd9a0f36d93773791cb81a2355ccb604@localhost> #3621: "No match in record selector Var.tcTyVarDetails" with incorrect multi- parameter newtype derivation -------------------------------------------+-------------------------------- Reporter: pwb | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: deriving/should_fail/T3621 | Os: Unknown/Multiple Architecture: Unknown/Multiple | -------------------------------------------+-------------------------------- Changes (by simonpj): * testcase: => deriving/should_fail/T3621 * difficulty: => Unknown * status: new => closed * resolution: => fixed Comment: Actually it shouldn't be rejected. For example {{{ class C a b data S = MkS instance C a S newtype T = MkT S deriving( C a ) }}} Here, the derived instance declaration looks like {{{ instance C a T }}} which is fine, although 'a' is not a parameter of T. However the compiler should not crash. And, happily, here's what the HEAD says (and hence 6.12): {{{ T3621.hs:11:21: Couldn't match expected type `state' against inferred type `s' `state' is a rigid type variable bound by the instance declaration at T3621.hs:11:32 `s' is a rigid type variable bound by the instance declaration at T3621.hs:10:21 When using functional dependencies to combine MonadState s (State s), arising from the dependency `m -> s' in the instance declaration at T3621.hs:8:9 MonadState state (State s), arising from the instance declaration at T3621.hs:11:21-36 When checking the super-classes of an instance declaration In the instance declaration for `MonadState state (WrappedState s)' }}} Which seems plausible. I'll add your program to our regression tests though. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 29 12:46:47 2009 From: trac at galois.com (GHC) Date: Thu Oct 29 12:23:14 2009 Subject: [GHC] #3622: ghci ignores LANGUAGE TemplateHaskell pragma Message-ID: <044.7dfa5c40d61cba8b59351f570466f2ba@localhost> #3622: ghci ignores LANGUAGE TemplateHaskell pragma -----------------------------+---------------------------------------------- Reporter: fasta | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Save the following in Foo.hs {{{ {-# LANGUAGE TemplateHaskell #-} import Language.Haskell.TH.Syntax }}} {{{$ ghci Foo.hs}}} Paste runQ [| (\x y -> compare x y == EQ) |] in ghci and press enter Instead of getting a useful result, I get an error. If I explicitly load TH on the command line, it does work. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 29 13:01:26 2009 From: trac at galois.com (GHC) Date: Thu Oct 29 12:37:54 2009 Subject: [GHC] #3622: ghci ignores LANGUAGE TemplateHaskell pragma In-Reply-To: <044.7dfa5c40d61cba8b59351f570466f2ba@localhost> References: <044.7dfa5c40d61cba8b59351f570466f2ba@localhost> Message-ID: <053.1b65b62780cc378a059d005363e30fd1@localhost> #3622: ghci ignores LANGUAGE TemplateHaskell pragma ---------------------------------+------------------------------------------ Reporter: fasta | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * difficulty: => Unknown Comment: This is (currently) by design, I believe. The LANGUAGE options at the head of a module apply to that module, not to the command-line. Maybe the command line should get the LANGUAGE options of any modules currently open? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 29 13:19:01 2009 From: trac at galois.com (GHC) Date: Thu Oct 29 12:55:30 2009 Subject: [GHC] #3622: ghci ignores LANGUAGE TemplateHaskell pragma In-Reply-To: <044.7dfa5c40d61cba8b59351f570466f2ba@localhost> References: <044.7dfa5c40d61cba8b59351f570466f2ba@localhost> Message-ID: <053.35f58a6709831e2582a6c9064448e56c@localhost> #3622: ghci ignores LANGUAGE TemplateHaskell pragma ---------------------------------+------------------------------------------ Reporter: fasta | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by fasta): Replying to [comment:1 simonpj]: > Maybe the command line should get the LANGUAGE options of any modules currently open? > That's what I would consider the expected behaviour. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 29 14:25:42 2009 From: trac at galois.com (GHC) Date: Thu Oct 29 14:02:09 2009 Subject: [GHC] #3623: Host's C info ending up in .hc files while cross-bootstrapping Message-ID: <042.0cd0316cb050b18626d967bb12b2f739@localhost> #3623: Host's C info ending up in .hc files while cross-bootstrapping -----------------------------+---------------------------------------------- Reporter: ksf | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.12.1 RC1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- hsc2hs does not seem to have access to the target's info, or at least not enough of it, at least in the posix package. I was able to hack around a differently-layout struct stat by hand which fixes obvious symptoms, and I'm strongly suspecting this also to be the cause of other strange behaviour that renders the compiled stage2 useless (it can't locate its builtin packages) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 29 16:27:15 2009 From: trac at galois.com (GHC) Date: Thu Oct 29 16:03:44 2009 Subject: [GHC] #3624: Parse fails when foreign import declarations contain path information (like those generated by c2hs). Message-ID: <048.e18b59101dfab8616bf0f6866665ebfc@localhost> #3624: Parse fails when foreign import declarations contain path information (like those generated by c2hs). -----------------------------+---------------------------------------------- Reporter: twadleigh | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Parser) Version: 6.12.1 RC1 | Severity: major Keywords: FFI, c2hs | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- An import declaration like: {{{ foreign import ccall safe "path/to/test.h test" test :: IO () }}} fails with: {{{ test.hs:7:26: Malformed entity string }}} I've marked this as a major issue because it ought to affect, for instance, any library that depends on c2hs (which generates bindings of this kind). I'm not sure if this is a GHC regression or actually an improvement in fidelity to the FFI spec (although I didn't see anything in the spec that would preclude qualifying the header name with path info). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 30 01:09:21 2009 From: trac at galois.com (GHC) Date: Fri Oct 30 00:45:46 2009 Subject: [GHC] #3625: GHCI doesn't work with dtrace on OS X Message-ID: <041.efc4099a4816c68174bfd27196e4a151@localhost> #3625: GHCI doesn't work with dtrace on OS X --------------------+------------------------------------------------------- Reporter: rl | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: MacOS X | Architecture: Unknown/Multiple --------------------+------------------------------------------------------- On OS X, user-defined dtrace probes are implemented as special symbols of the form `___dtrace_probe$...` which are magically resolved by the linker. In the attached package, we have this dtrace script: {{{ provider haskell { probe demo__trace(char*); }; }}} and this C file: {{{ void demo_trace( char *s ) { HASKELL_DEMO_TRACE(s); } }}} When we compile it, we get: {{{ newbie:dtrace-demo rl$ nm demo-trace.o U ___dtrace_probe$haskell$demo__trace$v1$63686172202a U ___dtrace_stability$haskell$v1$1_1_0_1_1_0_1_1_0_1_1_0_1_1_0 U ___dtrace_typedefs$haskell$v1 00000000 T _demo_trace }}} When linked as a dynamic library, the undefined symbols disappear: {{{ newbie:dtrace-demo rl$ ld -dylib -o demo-trace.dylib demo-trace.o newbie:dtrace-demo rl$ nm demo-trace.dylib 00000000 t __mh_dylib_header 000008b0 T _demo_trace }}} But GHCI's linker can't resolve the symbols which means that GHCI will fail if it tries to load demo-trace.o or a package file that contains demo-trace.o. For the attached package, `ghci -package dtrace-demo` produces this error: {{{ unknown symbol `___dtrace_probe$haskell$demo__trace$v1$63686172202a' Loading package dtrace-demo-1.0 ... linking ... ghc: unable to load package `dtrace-demo-1.0' }}} Unless I'm mistaken, the only solution is to use dlopen instead of a hand- written linker as the dtrace symbols are actually resolved by the kernel. The problem came up while implementing dtrace-based profiling for DPH. DPH uses Template Haskell so GHC tries to load a package which uses dtrace and dies. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 30 03:01:09 2009 From: trac at galois.com (GHC) Date: Fri Oct 30 02:37:33 2009 Subject: [GHC] #3626: Template Haskell silently boxes tuples Message-ID: <041.aae6d6091d1a73cffea424b9ad5d9c00@localhost> #3626: Template Haskell silently boxes tuples -----------------------------+---------------------------------------------- Reporter: rl | Owner: Type: bug | Status: new Priority: normal | Component: Template Haskell Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Here is a small program: {{{ {-# LANGUAGE TemplateHaskell, UnboxedTuples #-} module T where $(id [d| f g x = case g x of (# _, _ #) -> x |]) }}} Output of `ghci -ddump-splices`: {{{ f g[aR4] x[aR5] = case g[aR4] x[aR5] of { (_, _) -> x[aR5] } }}} Note how the tuple has been silently converted to a boxed one. TH shouldn't accept this program since it can't deal with unboxed tuples. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 30 05:02:32 2009 From: trac at galois.com (GHC) Date: Fri Oct 30 04:39:01 2009 Subject: [GHC] #3472: Porting through .hc files broken In-Reply-To: <046.fbcd146ac7544c3ae31be3ef2ccbd0d8@localhost> References: <046.fbcd146ac7544c3ae31be3ef2ccbd0d8@localhost> Message-ID: <055.472ff8bd4de0820a11a09f3ef271929c@localhost> #3472: Porting through .hc files broken ---------------------------------+------------------------------------------ Reporter: pumpkin | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Build System | Version: 6.12.1 RC1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by ksf): * version: 6.11 => 6.12.1 RC1 * summary: Porting through .hc files seems broken (seems general but parts of it may be osx-specific) => Porting through .hc files broken Comment: {{{make[1]: *** No rule to make target `rts/dist/build/Apply.o', needed by `rts/dist/build/libHSrts.a'. Stop.}}} I've encountered the same, I moved all .hc files to .c files, including AutoApply.hc, which lives in dist. Seems to work out fine. the NO_REGS/MINI_INTERPRETER issue is fixed in 6.12.0-rc1. the primopcodes are copied over from the host according to the port process docs, but the build system doesn't get that they're already there and tries to build genprimopcode, anyway. I nuked the respective make rules, and stuff seems to work out fine (that is, it compiles). I've also encountered various linker issues (and missing symbols beforehand, as haiku e.g. doesn't come with siginfo_t), but I guess these are quite normal while porting to a new platform. A stub for getlocale won't hurt the system, too. I've also experienced segfaults in Data.List.last, but can say that ghc would have failed differently, anyway, due to wrong args etc. However, there's two very, very important bits missing to the porting process: 1) Hs*Config.h (those for the libraries) aren't taken from the target system, but the host while generating .hc's (I'm looking into making the build system eat them, the naive approach didn't work (made make error out due to looping)) 2) the intermediate .c files generated from .hsc files are compiled with the host's headers (which leads to fun bugs like ghc being confused about what consists a directory and what not, due to struct stat having a different layout). This can either be fixed by moving the intermediate files onto the target and compile+run them there (which is awkward), or pre-processing them on the host using the target's headers, then compiling+running them on the host (which is convenient, and should be safe to do). Another possibility, of course, is to switch to c2hs, which knows of cross-compiling. I've also had issues with too big constants in .hc files, but instead of investigating the source, I switched to a 32-bit chroot for my host. I'm going to flag my other bug as a duplicate of this. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 30 05:03:43 2009 From: trac at galois.com (GHC) Date: Fri Oct 30 04:40:07 2009 Subject: [GHC] #3623: Host's C info ending up in .hc files while cross-bootstrapping In-Reply-To: <042.0cd0316cb050b18626d967bb12b2f739@localhost> References: <042.0cd0316cb050b18626d967bb12b2f739@localhost> Message-ID: <051.d279b54e06b74f250344779c67cf3437@localhost> #3623: Host's C info ending up in .hc files while cross-bootstrapping ------------------------------+--------------------------------------------- Reporter: ksf | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 6.12.1 RC1 Severity: normal | Resolution: duplicate Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by ksf): * status: new => closed * resolution: => duplicate Comment: See #3472 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 30 05:41:15 2009 From: trac at galois.com (GHC) Date: Fri Oct 30 05:17:39 2009 Subject: [GHC] #3472: Porting through .hc files broken In-Reply-To: <046.fbcd146ac7544c3ae31be3ef2ccbd0d8@localhost> References: <046.fbcd146ac7544c3ae31be3ef2ccbd0d8@localhost> Message-ID: <055.349643ce1dddbdf30f9f3edb1d47f1ea@localhost> #3472: Porting through .hc files broken ---------------------------------+------------------------------------------ Reporter: pumpkin | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Build System | Version: 6.12.1 RC1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by ksf): * cc: barsoap@web.de (added) Comment: Solution 2 to issue 2 (running hsc2hs with the target's headers on the host) needs a cross-compiler, at least if the system's bytesizes differ. Otherwise, offsetof is going to return borkage, even if given the right headers. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 30 06:09:06 2009 From: trac at galois.com (GHC) Date: Fri Oct 30 05:45:30 2009 Subject: [GHC] #3626: Template Haskell silently boxes tuples In-Reply-To: <041.aae6d6091d1a73cffea424b9ad5d9c00@localhost> References: <041.aae6d6091d1a73cffea424b9ad5d9c00@localhost> Message-ID: <050.48a77e7eaa244efd68339b80b50db76d@localhost> #3626: Template Haskell silently boxes tuples ---------------------------------+------------------------------------------ Reporter: rl | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * owner: => igloo * difficulty: => Unknown * type: bug => merge Comment: Thank you. Fixed by {{{ Fri Oct 30 02:19:28 PDT 2009 simonpj@microsoft.com * Fix Trac #3626: TH should reject unboxed tuples This was just a missing test in DsMeta M ./compiler/deSugar/DsMeta.hs -1 +3 }}} Pls merge -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 30 06:12:22 2009 From: trac at galois.com (GHC) Date: Fri Oct 30 05:48:47 2009 Subject: [GHC] #3622: ghci ignores LANGUAGE TemplateHaskell pragma In-Reply-To: <044.7dfa5c40d61cba8b59351f570466f2ba@localhost> References: <044.7dfa5c40d61cba8b59351f570466f2ba@localhost> Message-ID: <053.d5ce7894f4b13e68298e5d037710d763@localhost> #3622: ghci ignores LANGUAGE TemplateHaskell pragma ---------------------------------+------------------------------------------ Reporter: fasta | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * type: bug => feature request Comment: OK, a feature request then. Currently we don't record the flags in each interface file, so it's not trivial. Not really hard either. Does anyone else care about this? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 30 07:04:41 2009 From: trac at galois.com (GHC) Date: Fri Oct 30 06:41:05 2009 Subject: [GHC] #3615: GHCi doesn't allow the use of imported data contructors In-Reply-To: <047.8819d6591abc7952ad9279636b532fe8@localhost> References: <047.8819d6591abc7952ad9279636b532fe8@localhost> Message-ID: <056.03daba68a13dc040dc52c273c81b81b7@localhost> #3615: GHCi doesn't allow the use of imported data contructors --------------------------------+------------------------------------------- Reporter: blamario | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.4 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | --------------------------------+------------------------------------------- Changes (by simonpj): * difficulty: => Unknown * type: bug => feature request Comment: I can at least explain what is going on. * You compiled Imp and Main * So ghci can load them fast (by linking their .o files) and run them fast (using their compiled code). * But the downside is that all GHC knows about the module is what is recorded in the interface file, Main.hi and Imp.hi * You did not export D(..) from Main, so the interface file Main.hi didn't mention the data type D at all. * If, instead, you load Main ''interpreted'' (this is what `:load *Main` does) you get access to its entire top-level scope. The compiled/interpreted distinction is unfortunate, because it's really an implementation matter, but it shows up to users. We could make it less obtrusive by recording more in interface files (e.g. recording enough info to reproduce the top-level environment of Main). But it's more than just recording extra info; doing a full job would require doing less optimisation. For example suppose you have {{{ module Foo(b) where f x = g y = f (x+x) }}} When compiled, GHC inlines 'f' at its only call (in 'g'), and so there ''is'' no compiled code for 'f'. Hence GHCi can't call it. I'm reluctant to prevent non-exported things from being inlined in this way. (I suppose it could be an -O2 thing.) Anyway, that's the explanation. * Would someone like to add a description to http://haskell.org/haskellwiki/GHC/GHCi? The situation could be improved with some effort. * Any volunteers? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 30 07:15:50 2009 From: trac at galois.com (GHC) Date: Fri Oct 30 06:52:14 2009 Subject: [GHC] #3607: index variable for array traversal worker function is not unboxed In-Reply-To: <046.d0a8edddda5b84dbb9470f811143a19b@localhost> References: <046.d0a8edddda5b84dbb9470f811143a19b@localhost> Message-ID: <055.1b364e7b615a28db8f9907b294ba49b0@localhost> #3607: index variable for array traversal worker function is not unboxed -----------------------------------+---------------------------------------- Reporter: blarsen | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: worksforme Keywords: unboxed array, Ord | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------+---------------------------------------- Changes (by simonpj): * status: new => closed * difficulty: => Unknown * resolution: => worksforme Comment: With HEAD the inner loop looks like this: {{{ $wgo_sE2 [Occ=LoopBreaker] :: GHC.Prim.Int# -> GHC.Ordering.Ordering [LclId, Arity=1, Str=DmdType L] $wgo_sE2 = \ (ww6_sD3 :: GHC.Prim.Int#) -> case GHC.Prim.==# ww6_sD3 ww5_sCY of _ { GHC.Bool.False -> let { i_sE4 :: GHC.Types.Int [LclId] i_sE4 = GHC.Types.I# ww6_sD3 } in case GHC.Classes.compare @ e_aos w1_sDx (ww2_sDh @ i_aou w_sDw w2_sDy i_sE4) (ww4_sDr @ i_aou w_sDw w3_sDz i_sE4) of _ { GHC.Ordering.LT -> GHC.Ordering.LT; GHC.Ordering.EQ -> $wgo_sE2 (GHC.Prim.+# ww6_sD3 1); GHC.Ordering.GT -> GHC.Ordering.GT }; GHC.Bool.True -> GHC.Ordering.EQ }}} So the parameter is unboxed, but alas it's boxed every time, and necessarily so, in order to pass it to the (higher-order) indexing operations. If you specialise to a particular type, say {{{ {-# SPECIALISE cmpArrays :: Ord e => Array Int e -> Array Int e -> Ordering #-} }}} the inner loop seems reasonable (no boxing): {{{ letrec { $wgo_sGY [Occ=LoopBreaker] :: GHC.Prim.Int# -> GHC.Ordering.Ordering [LclId, Arity=1, Str=DmdType L] $wgo_sGY = \ (ww8_sFl :: GHC.Prim.Int#) -> case GHC.Prim.==# ww8_sFl ww2_sFz of _ { GHC.Bool.False -> case GHC.Classes.compare @ e_aB3 w_sFr (case GHC.Prim.indexArray# @ e_aB3 ww3_sFA ww8_sFl of _ { (# e_aEf #) -> e_aEf }) (case GHC.Prim.indexArray# @ e_aB3 ww7_sFK ww8_sFl of _ { (# e_aEf #) -> e_aEf }) of _ { GHC.Ordering.LT -> GHC.Ordering.LT; GHC.Ordering.EQ -> $wgo_sGY (GHC.Prim.+# ww8_sFl 1); GHC.Ordering.GT -> GHC.Ordering.GT }; GHC.Bool.True -> GHC.Ordering.EQ }; } in $wgo_sGY 0 }}} An INLINE pragma will do the same, albeit at every call site. I'll close this ticket, but do re-open it if you think there's still an issue. (I have not checked 6.12, but I don't think we'll fix that anyway, even if it doesn't generate as good code.) Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 30 07:26:06 2009 From: trac at galois.com (GHC) Date: Fri Oct 30 07:02:30 2009 Subject: [GHC] #3627: Profiling loses eta-expansion opportunities unnecessarily Message-ID: <046.6f702d96fc1994a638f81e082a1a0776@localhost> #3627: Profiling loses eta-expansion opportunities unnecessarily ---------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: run-time performance bug | Status: new Priority: low | Milestone: _|_ Component: Compiler | Version: 6.10.4 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ---------------------------------------+------------------------------------ If I have {{{ f = scc "f" let x = scc "g" y in \z -> ... }}} then we don't see that f has arity 1. Because `SimplUtils.mkLam` only does eta expansion if there is at least one value lambda. I'm making a ticket for this so that we don't forget it, but it's not very high priority. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 30 07:40:38 2009 From: trac at galois.com (GHC) Date: Fri Oct 30 07:17:15 2009 Subject: [GHC] #3592: Eta-contraction gives a rather bogus type error message In-Reply-To: <044.9fe7c2d56e2221c8747528de7b8c0b31@localhost> References: <044.9fe7c2d56e2221c8747528de7b8c0b31@localhost> Message-ID: <053.1372ca47ffe040c0f7f9cb8619d4aa74@localhost> #3592: Eta-contraction gives a rather bogus type error message -------------------------+-------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by simonpj): * difficulty: => Unknown * summary: ghc: panic! on overloaded type synonym => Eta-contraction gives a rather bogus type error message Comment: With the HEAD (and I think 6.12) we get {{{ T3592.hs:7:4: Could not deduce (Show (T a)) from the context () arising from a use of `show' at T3592.hs:7:4-7 Possible fix: add (Show (T a)) to the context of the type signature for `f' or add an instance declaration for (Show (T a)) In the expression: show In the definition of `f': f = show }}} which at least is not a crash. So that has already been fixed. Your type signature means this {{{ f :: forall a. (Show a => a) -> String }}} If we eta-expand the definition of f to {{{ f x = show x }}} then we get the totally reasonable error message: {{{ T3592.hs:7:11: Could not deduce (Show a) from the context () arising from a use of `x' at T3592.hs:7:11 Possible fix: add (Show a) to the context of the type signature for `f' In the first argument of `show', namely `x' In the expression: show x In the definition of `f': f x = show x }}} I think we should get the same error from the eta-contracted version, so I'm going to re-title this bug report, and put it in my list for the type inference overhaul. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 30 08:29:34 2009 From: trac at galois.com (GHC) Date: Fri Oct 30 08:05:59 2009 Subject: [GHC] #3625: GHCI doesn't work with dtrace on OS X In-Reply-To: <041.efc4099a4816c68174bfd27196e4a151@localhost> References: <041.efc4099a4816c68174bfd27196e4a151@localhost> Message-ID: <050.27ee07ab877dbcfaf5b9b85981ed1600@localhost> #3625: GHCI doesn't work with dtrace on OS X ---------------------+------------------------------------------------------ Reporter: rl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Testcase: Os: MacOS X | Architecture: Unknown/Multiple ---------------------+------------------------------------------------------ Comment (by duncan): `dlopen()` cannot load .o files, only .so / .dynlib files. As I understand it that's the reason for the ghci linker in the first place. The system linker is already used for the cases it can cope with. Moving to building Haskell packages as shared libs would solve this problem for packages but not for .o files in the local build tree. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 30 08:36:36 2009 From: trac at galois.com (GHC) Date: Fri Oct 30 08:12:59 2009 Subject: [GHC] #3615: GHCi doesn't allow the use of imported data contructors In-Reply-To: <047.8819d6591abc7952ad9279636b532fe8@localhost> References: <047.8819d6591abc7952ad9279636b532fe8@localhost> Message-ID: <056.34c79915099d1ab5eb4b49a3288a1532@localhost> #3615: GHCi doesn't allow the use of imported data contructors --------------------------------+------------------------------------------- Reporter: blamario | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.4 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | --------------------------------+------------------------------------------- Comment (by duncan): It should be possible in principle to provide an explanation in this case, something like "Constructor `D' is not exported from module `M'. To get access to the internals you can reload the module in interpreted mode using :set -fobject-code and :reload" The names of the internal things would have to be recorded in the .hi file for this to be possible (even if there's no corresponding object code since it all got inlined away). Of course it may not be trivial to keep this info. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 30 08:37:55 2009 From: trac at galois.com (GHC) Date: Fri Oct 30 08:14:20 2009 Subject: [GHC] #3616: ghci crash from :l In-Reply-To: <047.24d1ad3dc7106d0841f03798edf8d963@localhost> References: <047.24d1ad3dc7106d0841f03798edf8d963@localhost> Message-ID: <056.cedc3d9e066b632ce5d6488a1301d33b@localhost> #3616: ghci crash from :l ----------------------+----------------------------------------------------- Reporter: eflister | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Testcase: Os: MacOS X | Architecture: x86 ----------------------+----------------------------------------------------- Comment (by eflister): please also allow this format: {-# LANGUAGE EmptyDataDecls , MultiParamTypeClasses #-} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 30 10:37:41 2009 From: trac at galois.com (GHC) Date: Fri Oct 30 10:14:16 2009 Subject: [GHC] #3592: Eta-contraction gives a rather bogus type error message In-Reply-To: <044.9fe7c2d56e2221c8747528de7b8c0b31@localhost> References: <044.9fe7c2d56e2221c8747528de7b8c0b31@localhost> Message-ID: <053.3c43292930a9c91ee86b529fe9d24993@localhost> #3592: Eta-contraction gives a rather bogus type error message -------------------------+-------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by igloo): * milestone: => 6.14.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 30 10:38:57 2009 From: trac at galois.com (GHC) Date: Fri Oct 30 10:15:21 2009 Subject: [GHC] #3597: trying to build ghc 6.10.4 from src tarball: haddock: Can't find package.conf In-Reply-To: <044.585f719d9b9b61e199c03c9c4cb510dc@localhost> References: <044.585f719d9b9b61e199c03c9c4cb510dc@localhost> Message-ID: <053.d68ab9ec574e5ec2bd71449f38c628d3@localhost> #3597: trying to build ghc 6.10.4 from src tarball: haddock: Can't find package.conf -----------------------------+---------------------------------------------- Reporter: zooko | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 6.10.4 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -----------------------------+---------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: The build system has completely changed in 6.12, and it sounds like you have worked around the problem, so I'm closing this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 30 10:39:50 2009 From: trac at galois.com (GHC) Date: Fri Oct 30 10:16:13 2009 Subject: [GHC] #3598: ghc-stage2 binary name confusing for users In-Reply-To: <050.0c9e6d70bcb7f6d45f2e902acf2e7ba0@localhost> References: <050.0c9e6d70bcb7f6d45f2e902acf2e7ba0@localhost> Message-ID: <059.a05349509a7d41d939066555dd2d111f@localhost> #3598: ghc-stage2 binary name confusing for users ---------------------------------+------------------------------------------ Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.12.1 RC1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown Old description: > ghc-6.12.0.20091010 create a binary called > $libdir/ghc-6.12.0.20091010/ghc-stage2 and then causing > the program name ghc-stage2 to appear in compiler output > and help etc which is confusing for users and a regression > compared to 6.10.x IMHO. > > eg > $ ghc > ghc-stage2: no input files > Usage: For basic information, try the `--help' option. > $ ghc --help > Usage: > > ghc-stage2 [command-line-options-and-input-files] > > To compile and link a complete Haskell program, run the compiler like > so: > > ghc-stage2 --make Main > : > Alternatively, ghc-stage2 can be used to compile files individually. > Each > input file is guided through (some of the) possible phases of a > compilation: > : > Given the above, here are some TYPICAL invocations of ghc-stage2: > > # compile a Haskell module to a .o file, optimising: > % ghc-stage2 -c -O Foo.hs > # link three .o files into an executable called "test": > % ghc-stage2 -o test Foo.o Bar.o Baz.o > # compile a Haskell module to C (a .hc file), using a bigger heap: > % ghc-stage2 -C -H16m Foo.hs > # compile Haskell-produced C (.hc) to assembly language: > % ghc-stage2 -S Foo.hc > > etc > > I think either the output text should be changed > or ghc-stage2 renamed to ghc. New description: ghc-6.12.0.20091010 create a binary called $libdir/ghc-6.12.0.20091010/ghc-stage2 and then causing the program name ghc-stage2 to appear in compiler output and help etc which is confusing for users and a regression compared to 6.10.x IMHO. eg {{{ $ ghc ghc-stage2: no input files Usage: For basic information, try the `--help' option. }}} {{{ $ ghc --help Usage: ghc-stage2 [command-line-options-and-input-files] To compile and link a complete Haskell program, run the compiler like so: ghc-stage2 --make Main : Alternatively, ghc-stage2 can be used to compile files individually. Each input file is guided through (some of the) possible phases of a compilation: : Given the above, here are some TYPICAL invocations of ghc-stage2: # compile a Haskell module to a .o file, optimising: % ghc-stage2 -c -O Foo.hs # link three .o files into an executable called "test": % ghc-stage2 -o test Foo.o Bar.o Baz.o # compile a Haskell module to C (a .hc file), using a bigger heap: % ghc-stage2 -C -H16m Foo.hs # compile Haskell-produced C (.hc) to assembly language: % ghc-stage2 -S Foo.hc }}} etc I think either the output text should be changed or ghc-stage2 renamed to ghc. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 30 10:43:47 2009 From: trac at galois.com (GHC) Date: Fri Oct 30 10:20:10 2009 Subject: [GHC] #3598: ghc-stage2 binary name confusing for users In-Reply-To: <050.0c9e6d70bcb7f6d45f2e902acf2e7ba0@localhost> References: <050.0c9e6d70bcb7f6d45f2e902acf2e7ba0@localhost> Message-ID: <059.07766d563862fe402a53e467e61339bf@localhost> #3598: ghc-stage2 binary name confusing for users ---------------------------------+------------------------------------------ Reporter: juhpetersen | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Build System | Version: 6.12.1 RC1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * priority: normal => high * owner: => igloo * milestone: => 6.12.1 Comment: Good point, thanks for the report. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 30 12:14:34 2009 From: trac at galois.com (GHC) Date: Fri Oct 30 11:51:01 2009 Subject: [GHC] #3628: exceptions reported to stderr when they propagate past forkIO Message-ID: <045.1fd3d7941c00c82461fdc1db8e459688@localhost> #3628: exceptions reported to stderr when they propagate past forkIO -----------------------------+---------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- It's not entirely obvious what to do with exceptions that do not get handled within a `forkIO` however reporting them on stderr (or on Windows popping up a message dialog) does not seem right. We do not have other cases where errors are logged to stderr. The only such case is an exception terminating Main.main (and that's special because it terminates the whole process). If it is vital that someone do something with exceptions in forkIO threads then they should be propagated to another thread, in the worst case the main thread. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 30 15:04:06 2009 From: trac at galois.com (GHC) Date: Fri Oct 30 14:40:29 2009 Subject: [GHC] #3614: Cabal file parser can't handle colon in description In-Reply-To: <042.a1fcf46934be35bcc5f0659de5b6d5ca@localhost> References: <042.a1fcf46934be35bcc5f0659de5b6d5ca@localhost> Message-ID: <051.d57a6fd57c2c83677d43db51b4e35da4@localhost> #3614: Cabal file parser can't handle colon in description ---------------------------------+------------------------------------------ Reporter: dsf | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: libraries/base | Version: 6.12.1 RC1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * priority: normal => high * difficulty: => Unknown * owner: => igloo * milestone: => 6.12.1 Comment: Thanks for the report; we'll take a look. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 30 15:05:17 2009 From: trac at galois.com (GHC) Date: Fri Oct 30 14:41:40 2009 Subject: [GHC] #3612: Installing the binary tarball requires build tools (binutils, gcc, etc.) In-Reply-To: <047.24fbf86abe74d373d1eb2c5e5e6641fc@localhost> References: <047.24fbf86abe74d373d1eb2c5e5e6641fc@localhost> Message-ID: <056.fd1fe43571d89258f90e9805c6ad698a@localhost> #3612: Installing the binary tarball requires build tools (binutils, gcc, etc.) ---------------------------------+------------------------------------------ Reporter: matthijs | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 6.10.4 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: Closed, thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 30 16:14:19 2009 From: trac at galois.com (GHC) Date: Fri Oct 30 15:50:43 2009 Subject: [GHC] #3610: Installer has hard-coded path /usr/bin/strip In-Reply-To: <047.497d60e15e84c11bbc4d65529d1dd7a9@localhost> References: <047.497d60e15e84c11bbc4d65529d1dd7a9@localhost> Message-ID: <056.a0bcf815db0dc1e2e09c9f9b8b727679@localhost> #3610: Installer has hard-coded path /usr/bin/strip ---------------------------------+------------------------------------------ Reporter: YitzGale | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Build System | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * priority: normal => high * difficulty: => Unknown * milestone: => 6.12.1 Comment: Ah, I was confused as to where this path was hard coded at first, but it turns out it's in the Cabal `setup-config` files. I guess we'll have to override this in `ghc-cabal`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 30 16:23:12 2009 From: trac at galois.com (GHC) Date: Fri Oct 30 15:59:35 2009 Subject: [GHC] #3609: ar.exe: Bad file number In-Reply-To: <046.6971073bd0dd34bb84a681dc5bdcec98@localhost> References: <046.6971073bd0dd34bb84a681dc5bdcec98@localhost> Message-ID: <055.b5b8218f97b874bd26f2a2cfe1c5500d@localhost> #3609: ar.exe: Bad file number ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * milestone: => 6.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 30 16:28:20 2009 From: trac at galois.com (GHC) Date: Fri Oct 30 16:04:41 2009 Subject: [GHC] #3606: The Ord instance for unboxed arrays is very inefficient In-Reply-To: <046.5524abf7655d34a8f91d5dca7267dc7d@localhost> References: <046.5524abf7655d34a8f91d5dca7267dc7d@localhost> Message-ID: <055.f263c7e7ba299c4833084add32ee26b0@localhost> #3606: The Ord instance for unboxed arrays is very inefficient ----------------------------------------+----------------------------------- Reporter: blarsen | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: libraries (other) | Version: 6.10.4 Severity: normal | Resolution: Keywords: array, performance, Ord | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | ----------------------------------------+----------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 30 16:29:08 2009 From: trac at galois.com (GHC) Date: Fri Oct 30 16:05:40 2009 Subject: [GHC] #3605: Dll's freeze with -threaded In-Reply-To: <051.1aad4f74c417c7c8dcc312c4764dd078@localhost> References: <051.1aad4f74c417c7c8dcc312c4764dd078@localhost> Message-ID: <060.e57c5f118e607a6834e37c840c01d15f@localhost> #3605: Dll's freeze with -threaded ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Documentation | Version: 6.12.1 RC1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * priority: normal => high * difficulty: => Unknown * milestone: => 6.12.1 Comment: Let's fix the docs for 6.12.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 30 16:35:47 2009 From: trac at galois.com (GHC) Date: Fri Oct 30 16:12:14 2009 Subject: [GHC] #3615: GHCi doesn't allow the use of imported data contructors In-Reply-To: <047.8819d6591abc7952ad9279636b532fe8@localhost> References: <047.8819d6591abc7952ad9279636b532fe8@localhost> Message-ID: <056.498c25b1aec6d16eb9246064d3e3fed2@localhost> #3615: GHCi doesn't allow the use of imported data contructors --------------------------------+------------------------------------------- Reporter: blamario | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.14.1 Component: GHCi | Version: 6.10.4 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | --------------------------------+------------------------------------------- Changes (by igloo): * milestone: => 6.14.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 30 16:36:12 2009 From: trac at galois.com (GHC) Date: Fri Oct 30 16:12:34 2009 Subject: [GHC] #3616: ghci crash from :l In-Reply-To: <047.24d1ad3dc7106d0841f03798edf8d963@localhost> References: <047.24d1ad3dc7106d0841f03798edf8d963@localhost> Message-ID: <056.c6b77008b862cd81b1df48e0707612d0@localhost> #3616: ghci crash from :l -------------------------+-------------------------------------------------- Reporter: eflister | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by igloo): * difficulty: => Unknown Old description: > i got the following from trying to :l this file > > Prelude> :l tmp.hs > ghc: panic! (the 'impossible' happened) > (GHC version 6.10.3 for i386-apple-darwin): > getOptions'.parseLanguage(2) went past eof token > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug New description: i got the following from trying to :l this file {{{ Prelude> :l tmp.hs ghc: panic! (the 'impossible' happened) (GHC version 6.10.3 for i386-apple-darwin): getOptions'.parseLanguage(2) went past eof token Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 30 16:43:36 2009 From: trac at galois.com (GHC) Date: Fri Oct 30 16:20:00 2009 Subject: [GHC] #3617: There is no -debug runtime in 6.12 RC1 In-Reply-To: <044.eb7d8be022ebe7b2d677ab67a54a54d6@localhost> References: <044.eb7d8be022ebe7b2d677ab67a54a54d6@localhost> Message-ID: <053.92ed241e01bac65f9ed0682d7a9cee81@localhost> #3617: There is no -debug runtime in 6.12 RC1 -------------------------------+-------------------------------------------- Reporter: guest | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.12.1 RC1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by igloo): * priority: normal => high * difficulty: => Unknown * owner: => igloo * milestone: => 6.12.1 Comment: Looks like it; thanks for the report. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 30 16:45:59 2009 From: trac at galois.com (GHC) Date: Fri Oct 30 16:22:22 2009 Subject: [GHC] #3618: getStablePtr is called too early with dynamic libraries In-Reply-To: <044.ace7007dd565206bf92f9640eed34f4d@localhost> References: <044.ace7007dd565206bf92f9640eed34f4d@localhost> Message-ID: <053.60b0dbbbe3b40c007c8cb0de47dd36f3@localhost> #3618: getStablePtr is called too early with dynamic libraries -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.12.1 RC1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 30 16:46:33 2009 From: trac at galois.com (GHC) Date: Fri Oct 30 16:22:57 2009 Subject: [GHC] #3619: allow to set ghc search path globally (a'la CPATH) In-Reply-To: <045.08cbe5d68bcc5ce3a0c356e18d98ad1a@localhost> References: <045.08cbe5d68bcc5ce3a0c356e18d98ad1a@localhost> Message-ID: <054.09c493d020d9f1841bab270fc4e7c878@localhost> #3619: allow to set ghc search path globally (a'la CPATH) ---------------------------------+------------------------------------------ Reporter: tari3x | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.14.1 Comment: Thanks for the suggestion. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 30 16:48:25 2009 From: trac at galois.com (GHC) Date: Fri Oct 30 16:25:02 2009 Subject: [GHC] #3620: The seeds generated by split are not independent In-Reply-To: <052.ef1abc8d66f675d62b108c409dd80993@localhost> References: <052.ef1abc8d66f675d62b108c409dd80993@localhost> Message-ID: <061.9a8c8fff14c237dea2c16402ea8fb0ef@localhost> #3620: The seeds generated by split are not independent ---------------------------------+------------------------------------------ Reporter: NickSmallbone | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: libraries/random | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * milestone: => _|_ -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 30 16:55:16 2009 From: trac at galois.com (GHC) Date: Fri Oct 30 16:31:40 2009 Subject: [GHC] #3624: Parse fails when foreign import declarations contain path information (like those generated by c2hs). In-Reply-To: <048.e18b59101dfab8616bf0f6866665ebfc@localhost> References: <048.e18b59101dfab8616bf0f6866665ebfc@localhost> Message-ID: <057.b2b23c69cb68daeac63ac3d107f76684@localhost> #3624: Parse fails when foreign import declarations contain path information (like those generated by c2hs). ----------------------------------+----------------------------------------- Reporter: twadleigh | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler (Parser) | Version: 6.12.1 RC1 Severity: major | Resolution: Keywords: FFI, c2hs | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by igloo): * priority: normal => high * difficulty: => Unknown * milestone: => 6.12.1 Comment: If 6.10 accepted those decls, then we should look into what's changed and why. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 30 17:00:43 2009 From: trac at galois.com (GHC) Date: Fri Oct 30 16:37:05 2009 Subject: [GHC] #3625: GHCI doesn't work with dtrace on OS X In-Reply-To: <041.efc4099a4816c68174bfd27196e4a151@localhost> References: <041.efc4099a4816c68174bfd27196e4a151@localhost> Message-ID: <050.8718a4b8ed8ee25f8d3418c8901bf556@localhost> #3625: GHCI doesn't work with dtrace on OS X ---------------------------------+------------------------------------------ Reporter: rl | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: GHCi | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.14.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 30 17:03:52 2009 From: trac at galois.com (GHC) Date: Fri Oct 30 16:40:14 2009 Subject: [GHC] #3628: exceptions reported to stderr when they propagate past forkIO In-Reply-To: <045.1fd3d7941c00c82461fdc1db8e459688@localhost> References: <045.1fd3d7941c00c82461fdc1db8e459688@localhost> Message-ID: <054.b33985172ef1656d987a08374120b780@localhost> #3628: exceptions reported to stderr when they propagate past forkIO ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.14.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 30 17:05:05 2009 From: trac at galois.com (GHC) Date: Fri Oct 30 16:41:29 2009 Subject: [GHC] #3626: Template Haskell silently boxes tuples In-Reply-To: <041.aae6d6091d1a73cffea424b9ad5d9c00@localhost> References: <041.aae6d6091d1a73cffea424b9ad5d9c00@localhost> Message-ID: <050.122d2a7abdc3de2b608e7a0224dc166e@localhost> #3626: Template Haskell silently boxes tuples ---------------------------------+------------------------------------------ Reporter: rl | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: Component: Template Haskell | Version: 6.10.4 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 30 17:10:36 2009 From: trac at galois.com (GHC) Date: Fri Oct 30 16:48:15 2009 Subject: [GHC] #3400: OS X: ghc broken on Snow Leopard In-Reply-To: <042.42f8ee6f478d8beecc65fea9d7e2b0b4@localhost> References: <042.42f8ee6f478d8beecc65fea9d7e2b0b4@localhost> Message-ID: <051.2cb72057214d674c995dfa7f17850308@localhost> #3400: OS X: ghc broken on Snow Leopard -------------------------+-------------------------------------------------- Reporter: bbb | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.11 Severity: blocker | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by igloo): * status: reopened => new * owner: chak => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 30 17:55:02 2009 From: trac at galois.com (GHC) Date: Fri Oct 30 17:31:26 2009 Subject: [GHC] #3494: missing build system dependency In-Reply-To: <045.8de98aacac9d8b317157450367a72303@localhost> References: <045.8de98aacac9d8b317157450367a72303@localhost> Message-ID: <054.052dec80a694979411cc1690cf7eae5e@localhost> #3494: missing build system dependency ---------------------------------+------------------------------------------ Reporter: duncan | Owner: igloo Type: bug | Status: closed Priority: high | Milestone: 6.12.1 Component: Build System | Version: 6.11 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: reopened => closed * resolution: => fixed Comment: Yes, although it might drift out of sync. I guess it's better than nothing, though. {{{ Fri Oct 30 21:19:28 GMT 2009 Ian Lynagh * Add ghc-cabal dependencies; fixes #3494 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 30 18:41:51 2009 From: trac at galois.com (GHC) Date: Fri Oct 30 18:18:13 2009 Subject: [GHC] #3614: Cabal file parser can't handle colon in description In-Reply-To: <042.a1fcf46934be35bcc5f0659de5b6d5ca@localhost> References: <042.a1fcf46934be35bcc5f0659de5b6d5ca@localhost> Message-ID: <051.b77bb29bf4560213eb38eb402239676c@localhost> #3614: Cabal file parser can't handle colon in description ---------------------------------+------------------------------------------ Reporter: dsf | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: libraries/base | Version: 6.12.1 RC1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Old description: > The description field of the cabal file in the haskell-mtl package > currently in debian sid contains an url with a colon, which leads to this > error: > > ghc-pkg: 13: unrecognised field or section: > "()," > > This comes from Cabal.Distribution.ParseUtils. New description: The description field of the cabal file in the haskell-mtl package currently in debian sid contains an url with a colon, which leads to this error: {{{ ghc-pkg: 13: unrecognised field or section: "()," }}} This comes from `Cabal.Distribution.ParseUtils`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 30 18:46:22 2009 From: trac at galois.com (GHC) Date: Fri Oct 30 18:22:46 2009 Subject: [GHC] #3614: Cabal file parser can't handle colon in description In-Reply-To: <042.a1fcf46934be35bcc5f0659de5b6d5ca@localhost> References: <042.a1fcf46934be35bcc5f0659de5b6d5ca@localhost> Message-ID: <051.8b73251eaed16fbcbbda07509c7fe840@localhost> #3614: Cabal file parser can't handle colon in description ---------------------------------+------------------------------------------ Reporter: dsf | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: libraries/base | Version: 6.12.1 RC1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by igloo): I can't reproduce this. Can you please say exactly what commands you're using? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 30 19:18:26 2009 From: trac at galois.com (GHC) Date: Fri Oct 30 18:54:49 2009 Subject: [GHC] #3565: Wrong gcc being used In-Reply-To: <046.1a75409f814cd8c2531fe45e1f2aa63b@localhost> References: <046.1a75409f814cd8c2531fe45e1f2aa63b@localhost> Message-ID: <055.8b6b662e1bbda29a29299d983e86ccc7@localhost> #3565: Wrong gcc being used ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: closed Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: We now have a gcc wrapper on Windows in HEAD and 6.12. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 30 19:19:18 2009 From: trac at galois.com (GHC) Date: Fri Oct 30 18:55:40 2009 Subject: [GHC] #3558: Make haddock compilable without ghci being enabled In-Reply-To: <044.b8b389feb5e456baa4a248a5d7edff3d@localhost> References: <044.b8b389feb5e456baa4a248a5d7edff3d@localhost> Message-ID: <053.f47a4e486f34deeec624fbbe8e7a0057@localhost> #3558: Make haddock compilable without ghci being enabled ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: task | Status: new Priority: high | Milestone: 6.14.1 Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * milestone: 6.12.1 => 6.14.1 Comment: Punting. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 30 20:24:19 2009 From: trac at galois.com (GHC) Date: Fri Oct 30 20:00:41 2009 Subject: [GHC] #3614: Cabal file parser can't handle colon in description In-Reply-To: <042.a1fcf46934be35bcc5f0659de5b6d5ca@localhost> References: <042.a1fcf46934be35bcc5f0659de5b6d5ca@localhost> Message-ID: <051.ccb132587a3181143ec7ba45c451728f@localhost> #3614: Cabal file parser can't handle colon in description ---------------------------------+------------------------------------------ Reporter: dsf | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: libraries/base | Version: 6.12.1 RC1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by dsf): Replying to [comment:3 igloo]: > I can't reproduce this. Can you please say exactly what commands you're using? It happens if I put the attached mtl.cabal file into /tmp and run cd /tmp; echo "[]" > tmp.conf; ghc-pkg register tmp.conf strace says its not opening anything other than standard system libraries. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 31 04:53:51 2009 From: trac at galois.com (GHC) Date: Sat Oct 31 04:30:13 2009 Subject: [GHC] #3614: Cabal file parser can't handle colon in description In-Reply-To: <042.a1fcf46934be35bcc5f0659de5b6d5ca@localhost> References: <042.a1fcf46934be35bcc5f0659de5b6d5ca@localhost> Message-ID: <051.2a5ee66f653d768de99f6b91040dd050@localhost> #3614: Cabal file parser can't handle colon in description ---------------------------------+------------------------------------------ Reporter: dsf | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: libraries/base | Version: 6.12.1 RC1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by igloo): I don't understand; you don't seem to be using `mtl.cabal` in that command. When I run it I get: {{{ Reading package info from "tmp.conf" ... ghc-pkg: 1: unrecognised field or section: "[]" }}} which seems reasonable to me. Also, note that `mtl.cabal` is meant to be used by Cabal, not by ghc-pkg directly. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 31 05:17:42 2009 From: trac at galois.com (GHC) Date: Sat Oct 31 04:54:06 2009 Subject: [GHC] #3617: There is no -debug runtime in 6.12 RC1 In-Reply-To: <044.eb7d8be022ebe7b2d677ab67a54a54d6@localhost> References: <044.eb7d8be022ebe7b2d677ab67a54a54d6@localhost> Message-ID: <053.15ec09fb2ecb2d9a08c8ef4c2122c377@localhost> #3617: There is no -debug runtime in 6.12 RC1 -------------------------------+-------------------------------------------- Reporter: guest | Owner: igloo Type: bug | Status: closed Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.12.1 RC1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed in HEAD and 6.12: {{{ Sat Oct 31 08:44:26 GMT 2009 Ian Lynagh * Define BootingFromHc in bindists; fixes #3617 This variable is tested when deciding whether or not to add debug to the list of RTS ways, so it needs to be correctly defined. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 31 08:12:11 2009 From: trac at galois.com (GHC) Date: Sat Oct 31 07:48:33 2009 Subject: [GHC] #3629: Code compiled WITHOUT profiling many times slower than compiled WITH profiling on Message-ID: <048.82a42937ecf77e5d0d0af3b5fdd87592@localhost> #3629: Code compiled WITHOUT profiling many times slower than compiled WITH profiling on -----------------------------+---------------------------------------------- Reporter: gchrupala | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.13 | Severity: major Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- I have a program which runs extremely slow when I compile it with profiling disabled. It only becomes usable when compiled with profiling options on (-prof -auto-all). I reproduced it with GHC 6.10, 6.12 and 6.13. The source is attached. I compiled and ran like this: {{{ ghc-6.13.20091027 --make -O2 runST.hs -fforce-recomp time ./runST > /dev/null real 5m9.670s user 5m7.627s sys 0m0.468s ghc-6.13.20091027 --make -O2 runST.hs -fforce-recomp -prof -auto-all real 0m39.544s user 0m39.050s sys 0m0.148s }}} In the meantime, is there is a workaround other than compiling with profiling options on? I would prefer to modify the source rather than ask users to install profiling libraries and mess with compiler options. Best, -- Grzegorz Chrupala -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 31 10:10:51 2009 From: trac at galois.com (GHC) Date: Sat Oct 31 09:47:13 2009 Subject: [GHC] #3610: Installer has hard-coded path /usr/bin/strip In-Reply-To: <047.497d60e15e84c11bbc4d65529d1dd7a9@localhost> References: <047.497d60e15e84c11bbc4d65529d1dd7a9@localhost> Message-ID: <056.87a8c68151da6611a570a0515c1c0d41@localhost> #3610: Installer has hard-coded path /usr/bin/strip ---------------------------------+------------------------------------------ Reporter: YitzGale | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Build System | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by duncan): So is the problem that we're configuring on one machine (the bindist builder) and then installing on another (the target)? So paths from the builder end up in the config and do not match on the target. Strictly speaking that's not a supported mode of operation for Cabal. It supports building an installable image on one machine and installing and registering that on another. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 31 10:48:11 2009 From: trac at galois.com (GHC) Date: Sat Oct 31 10:24:31 2009 Subject: [GHC] #3614: Cabal file parser can't handle colon in description In-Reply-To: <042.a1fcf46934be35bcc5f0659de5b6d5ca@localhost> References: <042.a1fcf46934be35bcc5f0659de5b6d5ca@localhost> Message-ID: <051.4bac33f687f7c383814e4d512425777b@localhost> #3614: Cabal file parser can't handle colon in description ---------------------------------+------------------------------------------ Reporter: dsf | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: libraries/base | Version: 6.12.1 RC1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by dsf): I'm sorry, I simplified the problem away and then didn't notice that the message had changed. It turns out that the problem arises when processing the installed-pkg-config file generated by dh_haskell_install, which dh_haskell_shlibdeps then picks up using the find_config_for_ghc6 function. I don't speak perl very well, but I suspect this: {{{ if (/([^\s:]+):(.*)/) { $field = $1; print OUTCONFIG "$field:"; $_ = $2; } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 31 10:51:15 2009 From: trac at galois.com (GHC) Date: Sat Oct 31 10:27:36 2009 Subject: [GHC] #3614: Cabal file parser can't handle colon in description In-Reply-To: <042.a1fcf46934be35bcc5f0659de5b6d5ca@localhost> References: <042.a1fcf46934be35bcc5f0659de5b6d5ca@localhost> Message-ID: <051.d72519557d83f730b9890048d2f5b39d@localhost> #3614: Cabal file parser can't handle colon in description ---------------------------------+------------------------------------------ Reporter: dsf | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: libraries/base | Version: 6.12.1 RC1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by dsf): (This makes it a haskell-devscripts bug, so I guess it doesn't belong here.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 31 20:29:35 2009 From: trac at galois.com (GHC) Date: Sat Oct 31 20:05:56 2009 Subject: [GHC] #3630: Suggested algorithm to control upper bound of space "leaks" Message-ID: <051.72af98bc6de8e1372fe3431e4a8c348a@localhost> #3630: Suggested algorithm to control upper bound of space "leaks" -----------------------------+---------------------------------------------- Reporter: shelbymoore3 | Owner: Type: proposal | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- An idea for an algorithm to mitigate space "leaks". Limited research (thus far) reveals that space "leaks" due to laziness are desireable function of the matrix of design choices and may be better automatically controlled in runtime (read both links to fully understand): http://www.haskell.org/pipermail/haskell-cafe/2009-October/068382.html [[BR]] http://www.haskell.org/pipermail/cvs-ghc/2009-October/050928.html Proposes to fix to this bug (in theory): http://hackage.haskell.org/trac/ghc/ticket/917 May you can cross-link from the bug, so people can read my links above to get a deeper understanding of why space "leaks" are really a feature, not a bug. And others can think about my idea at links above for a deterministic runtime upper bound solution (that proposes to be orthogonal to profiling and static optimization). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 31 20:44:45 2009 From: trac at galois.com (GHC) Date: Sat Oct 31 20:21:05 2009 Subject: [GHC] #3630: Suggested algorithm to control upper bound of space "leaks" In-Reply-To: <051.72af98bc6de8e1372fe3431e4a8c348a@localhost> References: <051.72af98bc6de8e1372fe3431e4a8c348a@localhost> Message-ID: <060.5d0f98b77e1baa5512dce296863b1ddf@localhost> #3630: Suggested algorithm to control upper bound of space "leaks" ------------------------------+--------------------------------------------- Reporter: shelbymoore3 | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by shelbymoore3): I cover in my links above the concept that: Lazy space "leaks" are a desirable slider? The point is that we should have both granular and brute-force (global) control, both at compile+profile and at run-time, over the static<->lazy trade-off. Then there is no significant disadvantage relative to other languages/run-times, and more advantages. And I offer suggested algorithm for the brute-force control at run-time. -- Ticket URL: GHC The Glasgow Haskell Compiler