From trac at galois.com Fri Feb 1 10:54:28 2008 From: trac at galois.com (GHC) Date: Fri Feb 1 10:53:45 2008 Subject: [GHC] #2066: Building 6.9 with 6.4.1 fails In-Reply-To: <043.7f13a3423ee9fec021c7bc30d46308ff@localhost> References: <043.7f13a3423ee9fec021c7bc30d46308ff@localhost> Message-ID: <052.b0bb3bb3d7c3a7b43289f1b92605af10@localhost> #2066: Building 6.9 with 6.4.1 fails ----------------------+----------------------------------------------------- Reporter: pejo | Owner: Type: bug | Status: closed Priority: high | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: minor | Resolution: fixed Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Fixed this, and a few other problems. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 1 11:34:38 2008 From: trac at galois.com (GHC) Date: Fri Feb 1 11:34:39 2008 Subject: [GHC] #1537: do notation translation In-Reply-To: <051.002894fe88bc6a156c09bce0721f2c76@localhost> References: <051.002894fe88bc6a156c09bce0721f2c76@localhost> Message-ID: <060.d8c692a8fa560f00ca34c43ef13d9a2e@localhost> #1537: do notation translation -------------------------------------+-------------------------------------- Reporter: Isaac Dupree | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.7 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: rebindable8 | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Comment (by mnislaih): It looks like ghc still enforces a signature of the form {{{ (>>=) :: rhs_ty -> (pat_ty -> res_ty) -> res_ty }}} Is it reasonable to demand that res_ty is preserved? Even with the patch, the parameterized monads referenced by the blog post above cannot be made to use do notation I can prepare a new test that shows this -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 1 13:22:50 2008 From: trac at galois.com (GHC) Date: Fri Feb 1 13:22:05 2008 Subject: [GHC] #1537: do notation translation In-Reply-To: <051.002894fe88bc6a156c09bce0721f2c76@localhost> References: <051.002894fe88bc6a156c09bce0721f2c76@localhost> Message-ID: <060.d76c04d703ffd3f6e988aca0d856c270@localhost> #1537: do notation translation -------------------------------------+-------------------------------------- Reporter: Isaac Dupree | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.7 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: rebindable8 | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Comment (by simonpj): An example would be good. I think I see what you mean, but I'd like to be sure. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 1 14:29:55 2008 From: trac at galois.com (GHC) Date: Fri Feb 1 14:29:11 2008 Subject: [GHC] #1537: do notation translation In-Reply-To: <051.002894fe88bc6a156c09bce0721f2c76@localhost> References: <051.002894fe88bc6a156c09bce0721f2c76@localhost> Message-ID: <060.1169e7496f1058c210ff1373c003df49@localhost> #1537: do notation translation --------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.7 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: rebindable8, rebindable9 | Architecture: Unknown Os: Unknown | --------------------------------------+------------------------------------- Changes (by mnislaih): * testcase: rebindable8 => rebindable8, rebindable9 Comment: Stolen from the parameterized monads framework, in test rebindable8 we have {{{ class Bind m1 m2 m3 where (>>=) :: m1 a -> (a -> m2 b) -> m3 b class Return m where return :: a -> m a fail :: String -> m a }}} And the simple instance {{{ instance Bind Maybe [] [] where ... instance Return [] where ... }}} Now consider the following instances {{{ instance Bind Identity m m where ... instance Bind m Identity m where ... }}} The second one does not play well with ghc HEAD currently, since (>>=) gets the type {{{ (>>=) :: (...)=> m a -> (a -> Identity b) -> m b }}} I have pushed a test 'rebindable9' that shows the issue in detail. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 2 11:01:13 2008 From: trac at galois.com (GHC) Date: Sat Feb 2 11:00:23 2008 Subject: [GHC] #2067: ALUT fails to build on Mac OS X In-Reply-To: <044.9bc97f7b0dfe54927240854201c62c44@localhost> References: <044.9bc97f7b0dfe54927240854201c62c44@localhost> Message-ID: <053.2fa29df3cb2a2234aa488a87e1c8595e@localhost> #2067: ALUT fails to build on Mac OS X --------------------------+------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 6.8.2 Severity: normal | Resolution: invalid Keywords: ALUT, build | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | --------------------------+------------------------------------------------- Comment (by guest): The situation seems to be somewhat messier than that. If I understand the situation correctly, Apple only removed the ALUT header files, but the old, deprecated ALUT 1.0 code is still linked into the OpenAL framework together with the new OpenAL 1.1 code. Now, the function names in ALUT 1.0 (linked into the framework) collide with the new ALUT 1.1 names, so one cannot simply link with an ALUT 1.1 library (provided by Creative under the name `freealut`, see http://openal.org/downloads.html) and the OpenAL framework included in Mac OS X. You can change the colliding names in the `freealut` source, which is un ugly hack; nevertheless I did that, and managed to build this `freealut` library; however I couldn't make it work with GHC, as the the Cabal build system of the Haskell ALUT wanted a (nonexisting) ALUT.framework (I had a `libalut.a` or something like that instead, as the result of the above hacking). All in all, I think the current situation is not acceptable, at least with ALUT being on the list of bundled libraries (of course, the main source of the problem is Apple, but still). And while OpenAL 1.1 in theory should work without ALUT, I couldn't make it work. By the way, the Windows binary distribution of GHC 6.8.2 seems to completely miss both OpenAL and ALUT. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 2 21:28:06 2008 From: trac at galois.com (GHC) Date: Sat Feb 2 21:27:28 2008 Subject: [GHC] #2073: ghci records empty input lines in readline history In-Reply-To: <045.754f0911fd9e82aafab4d99a7c2d2f12@localhost> References: <045.754f0911fd9e82aafab4d99a7c2d2f12@localhost> Message-ID: <054.846f6b7b26a4dacd80deca1e095c98fd@localhost> #2073: ghci records empty input lines in readline history -------------------------------+-------------------------------------------- Reporter: Eelis- | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: GHCi | Version: 6.8.2 Severity: minor | Resolution: Keywords: readline, history | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.8.3 Comment: Thanks for the report. Sounds like it should be easy to fix for 6.8.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 3 15:32:26 2008 From: trac at galois.com (GHC) Date: Sun Feb 3 15:31:34 2008 Subject: [GHC] #1168: Optimisation sometimes decreases sharing in IO code In-Reply-To: <047.1e9bce153303809272446b6c0aede02d@localhost> References: <047.1e9bce153303809272446b6c0aede02d@localhost> Message-ID: <056.017596991366cb56b54d31f627952a89@localhost> #1168: Optimisation sometimes decreases sharing in IO code -------------------------------------+-------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: nofib/spectral/calendar | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Comment (by ChrisKuklewicz): This just came up on the mailing list again. The program was slow unless (-fno-state-hack) was used. Is it possible to have GHC emit a warning (as part of -Wall) to let the use know that GHC is applying a potentially risky simplification? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 3 15:47:57 2008 From: trac at galois.com (GHC) Date: Sun Feb 3 15:47:05 2008 Subject: [GHC] #2048: Add split and splitWith to Data.List In-Reply-To: <045.7155003e42a360739f457ed29bf408d6@localhost> References: <045.7155003e42a360739f457ed29bf408d6@localhost> Message-ID: <054.391fddf4fa840bb0f93476bc5791e5db@localhost> #2048: Add split and splitWith to Data.List ----------------------------+----------------------------------------------- Reporter: twanvl | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => Not GHC -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 3 15:48:18 2008 From: trac at galois.com (GHC) Date: Sun Feb 3 15:47:24 2008 Subject: [GHC] #2053: Add read_history and write_history bindings to readline In-Reply-To: <042.660e67c9ae82ef2f50c4766a74e43bc8@localhost> References: <042.660e67c9ae82ef2f50c4766a74e43bc8@localhost> Message-ID: <051.28d5600a985a4f443913c3b25a53baf8@localhost> #2053: Add read_history and write_history bindings to readline -------------------------------+-------------------------------------------- Reporter: ajd | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => Not GHC -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 3 15:51:07 2008 From: trac at galois.com (GHC) Date: Sun Feb 3 15:50:14 2008 Subject: [GHC] #2051: -hide-package doesn't allow hiding uninstalled package In-Reply-To: <053.fd935e025acfb737c5e2348105b5b118@localhost> References: <053.fd935e025acfb737c5e2348105b5b118@localhost> Message-ID: <062.1fab15d863caaca719fddf876536a76f@localhost> #2051: -hide-package doesn't allow hiding uninstalled package -----------------------------+---------------------------------------------- Reporter: MagnusTherning | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: trivial | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | -----------------------------+---------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch Comment: This just needs us to decide what the best behaviour is. I think we should at least warn if the package isn't installed, to catch people making typos. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 3 15:52:24 2008 From: trac at galois.com (GHC) Date: Sun Feb 3 15:51:31 2008 Subject: [GHC] #2052: hpc ignores files containing LINES pragmas that refer to .hsc files In-Reply-To: <043.13a31077ae5ebb133355743a92fc5086@localhost> References: <043.13a31077ae5ebb133355743a92fc5086@localhost> Message-ID: <052.41816d9e8f25dbfa535f4ea33cb10257@localhost> #2052: hpc ignores files containing LINES pragmas that refer to .hsc files ---------------------------+------------------------------------------------ Reporter: dons | Owner: andy@galois.com Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Code Coverage | Version: 6.8.2 Severity: normal | Resolution: Keywords: hpc, hsc2hs | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ---------------------------+------------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.8.3 Comment: This sounds like it should be trivial to fix, so let's aim to do so for 6.8.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 3 15:54:38 2008 From: trac at galois.com (GHC) Date: Sun Feb 3 15:53:45 2008 Subject: [GHC] #2057: inconsistent .hi file error gets ignored In-Reply-To: <045.e53c768183aca8a1a40fddc456cadee9@localhost> References: <045.e53c768183aca8a1a40fddc456cadee9@localhost> Message-ID: <054.5a3298a31293dc44172a6cbf967be23d@localhost> #2057: inconsistent .hi file error gets ignored ----------------------+----------------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * milestone: => _|_ -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 3 21:33:19 2008 From: trac at galois.com (GHC) Date: Sun Feb 3 21:32:28 2008 Subject: [GHC] #2047: ghc compiled program crashes with segfault when using -M and/or -c In-Reply-To: <042.76ffc0b2217121d0a72a366715d60678@localhost> References: <042.76ffc0b2217121d0a72a366715d60678@localhost> Message-ID: <051.dc1ed4aafa174050d2be24b6dd0b4646@localhost> #2047: ghc compiled program crashes with segfault when using -M and/or -c ----------------------------+----------------------------------------------- Reporter: mte | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Runtime System | Version: 6.8.2 Severity: critical | Resolution: Keywords: gc segfault | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------------+----------------------------------------------- Changes (by guest): * cc: orielmaxime@yahoo.com (added) Comment: Simon - I also have seen this behavior. If you are still looking for code, email me at orielmaxime@yahoo.com and I can provide. I've added myself to the cc. This bug is sad for me because I often run programs that solve puzzles, and need to run with a lot of memory. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 4 04:50:17 2008 From: trac at galois.com (GHC) Date: Mon Feb 4 04:49:22 2008 Subject: [GHC] #1168: Optimisation sometimes decreases sharing in IO code In-Reply-To: <047.1e9bce153303809272446b6c0aede02d@localhost> References: <047.1e9bce153303809272446b6c0aede02d@localhost> Message-ID: <056.2ae3716834f87ea2f5c85715d4362ba7@localhost> #1168: Optimisation sometimes decreases sharing in IO code -------------------------------------+-------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: nofib/spectral/calendar | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Comment (by simonmar): A warning would be good, but I see two potential problems: * there would be a lot of false positives * the warning has to be generated by the simplifier, and source-location information has been stripped off by this point, so we don't have a good way to report the location of the warning. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 4 06:38:57 2008 From: trac at galois.com (GHC) Date: Mon Feb 4 06:38:02 2008 Subject: [GHC] #2047: ghc compiled program crashes with segfault when using -M and/or -c In-Reply-To: <042.76ffc0b2217121d0a72a366715d60678@localhost> References: <042.76ffc0b2217121d0a72a366715d60678@localhost> Message-ID: <051.87d537a6d0c4399a62da43f6fa092f86@localhost> #2047: ghc compiled program crashes with segfault when using -M and/or -c ----------------------------+----------------------------------------------- Reporter: mte | Owner: Type: bug | Status: new Priority: high | Milestone: 6.8.3 Component: Runtime System | Version: 6.8.2 Severity: critical | Resolution: Keywords: gc segfault | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------------+----------------------------------------------- Changes (by simonmar): * priority: normal => high -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 4 08:21:51 2008 From: trac at galois.com (GHC) Date: Mon Feb 4 08:20:55 2008 Subject: [GHC] #1168: Optimisation sometimes decreases sharing in IO code In-Reply-To: <047.1e9bce153303809272446b6c0aede02d@localhost> References: <047.1e9bce153303809272446b6c0aede02d@localhost> Message-ID: <056.e892fbbcf35133b15526531363e19c41@localhost> #1168: Optimisation sometimes decreases sharing in IO code -------------------------------------+-------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: nofib/spectral/calendar | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Comment (by simonpj): Adding a link to the recent email thread http://www.haskell.org/pipermail/glasgow-haskell- users/2008-February/014259.html -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 4 11:00:41 2008 From: trac at galois.com (GHC) Date: Mon Feb 4 10:59:46 2008 Subject: [GHC] #1136: High memory use when compiling many let bindings. In-Reply-To: <044.2f9aae100a9caba688d31e410efb3444@localhost> References: <044.2f9aae100a9caba688d31e410efb3444@localhost> Message-ID: <053.85fdd348bcb81ffcf3f02f16fd61b00b@localhost> #1136: High memory use when compiling many let bindings. ------------------------------------------+--------------------------------- Reporter: igloo | Owner: Type: compile-time performance bug | Status: new Priority: high | Milestone: 6.8.3 Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: performance | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ------------------------------------------+--------------------------------- Comment (by igloo): For J2, consider this module: {{{ module J where data Foo a b c d = Foo a b c d a = let a0 = a3 a1 = a0 a2 = a1 a3 = a2 in Foo a0 a1 a2 a3 }}} We get (tidied up a bit): {{{ ==================== Desugar ==================== Rec { J.a :: forall t0 t1 t2 t3. J.Foo t0 t1 t2 t3 J.a = \ (@ t0) (@ t1) (@ t2) (@ t3) -> letrec { res :: J.Foo t0 t1 t2 t3 res = letrec { tup :: forall ttup. (ttup, ttup, ttup, ttup) tup = \ (@ ttup) -> letrec { tupa1 :: ttup tupa1 = tupa0; tupa2 :: ttup tupa2 = tupa1; tupa3 :: ttup tupa3 = tupa2; tupa0 :: ttup tupa0 = tupa3; } in (tupa0, tupa3, tupa2, tupa1); a0 :: forall ttup. ttup a0 = \ (@ ttup) -> case tup @ ttup of _ { (tup0, _, _, _) -> tup0 }; a3 :: forall ttup. ttup a3 = \ (@ ttup) -> case tup @ ttup of _ { (_, tup1, _, _) -> tup1 }; a2 :: forall ttup. ttup a2 = \ (@ ttup) -> case tup @ ttup of _ { (_, _, tup2, _) -> tup2 }; a1 :: forall ttup. ttup a1 = \ (@ ttup) -> case tup @ ttup of _ { (_, _, _, tup3) -> tup3 }; } in J.Foo @ t0 @ t1 @ t2 @ t3 (a0 @ t0) (a1 @ t1) (a2 @ t2) (a3 @ t3); } in res end Rec } }}} I think that most of the space usage comes from the tuple deconstructors. We should look into desugaring into something like this instead: {{{ ==================== Desugar ==================== Rec { J.a :: forall t0 t1 t2 t3. J.Foo t0 t1 t2 t3 J.a = \ (@ t0) (@ t1) (@ t2) (@ t3) -> letrec { res :: J.Foo t0 t1 t2 t3 res = letrec { a0 :: forall ttup. ttup a0 = \ (@ ttup) -> a3; a3 :: forall ttup. ttup a3 = \ (@ ttup) -> a2; a2 :: forall ttup. ttup a2 = \ (@ ttup) -> a1; a1 :: forall ttup. ttup a1 = \ (@ ttup) -> a0; } in J.Foo @ t0 @ t1 @ t2 @ t3 (a0 @ t0) (a1 @ t1) (a2 @ t2) (a3 @ t3); } in res end Rec } }}} Simon was worried about losing dictionary sharing if we did so, so we need to check into whether that causes a performance problem, and whether we can get the sharing some other way. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 4 17:31:16 2008 From: trac at galois.com (GHC) Date: Mon Feb 4 17:30:25 2008 Subject: [GHC] #2075: hpc should render information about the run in its html markup Message-ID: <043.efa0d0e9e80dc67976454293fca2d82f@localhost> #2075: hpc should render information about the run in its html markup --------------------------------+------------------------------------------- Reporter: dons | Owner: andy@galois.com Type: feature request | Status: new Priority: normal | Component: Code Coverage Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Multiple --------------------------------+------------------------------------------- To check if a generated coverage test is up to date, it would be useful to have hpc annotate its generated output with the date of the run, the compiler version, and OS info. Perhaps also information about which packages were included in the build. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 5 01:28:12 2008 From: trac at galois.com (GHC) Date: Tue Feb 5 01:27:16 2008 Subject: [GHC] #2076: rational infinities don't compare correctly to each other Message-ID: <050.a969a55392b5039df51d6053d2d690a6@localhost> #2076: rational infinities don't compare correctly to each other ----------------------------+----------------------------------------------- Reporter: uhollerbach | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Multiple | Os: Unknown ----------------------------+----------------------------------------------- Let pinf = 1%0, and ninf = (-1)%0; then (min ninf pinf) is correctly reported as (-1)%0, but (min pinf ninf) is reported as 1%0. Similar problems exist with max, (<), (>), (<=), and (>=). The (hopefully attached) test program shows the trouble. I have checked this on both 32-bit x86 and 64-bit amd64, both with ghc 6.8.2, both linux; both show the same trouble. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 5 04:26:54 2008 From: trac at galois.com (GHC) Date: Tue Feb 5 04:25:56 2008 Subject: [GHC] #1168: Optimisation sometimes decreases sharing in IO code In-Reply-To: <047.1e9bce153303809272446b6c0aede02d@localhost> References: <047.1e9bce153303809272446b6c0aede02d@localhost> Message-ID: <056.8db6876e36d1819dcf85274de3730567@localhost> #1168: Optimisation sometimes decreases sharing in IO code -------------------------------------+-------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: nofib/spectral/calendar | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Changes (by simonpj): * cc: adam@thejenkins.org (added) Comment: Adding Adam Jenkins to the cc list. At the end of the above thread he writes (reasonably enough): Thank you for the explanation. Inlining does explain the behavior I was seeing, and `-fno-state-hack` does make the program behave the way I'd expect. I would like to humbly submit that perhaps this optimization should be off by default. It seems to me that any compiler optimization which can potentially increase your program's runtime by an order of complexity is dangerous. Also, while the Haskell Report doesn't seem to specify anything about lazy evaluation behavior, it seems to me that in order to program in Haskell, assuming that a computation assigned to a variable won't be recomputed multiple times is almost as necessary an assumption as assuming that the compiler will optimize away tail recursion. For instance GHC FAQ entry 7.2 implicitly assumes this is true: http://haskell.org/haskellwiki/GHC:FAQ#Does_GHC_do_common_subexpression_elimination.3F In my real program where I ran into this problem it took me quite a while to figure out why my program's performance wasn't making any sense, and why seemingly irrelevant changes to my code made the performance problem go away. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 5 04:32:51 2008 From: trac at galois.com (GHC) Date: Tue Feb 5 04:31:54 2008 Subject: [GHC] #1168: Optimisation sometimes decreases sharing in IO code In-Reply-To: <047.1e9bce153303809272446b6c0aede02d@localhost> References: <047.1e9bce153303809272446b6c0aede02d@localhost> Message-ID: <056.a831237a497a746f7a4c1ffae5e36c24@localhost> #1168: Optimisation sometimes decreases sharing in IO code -------------------------------------+-------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: nofib/spectral/calendar | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Comment (by simonpj): I agree that the current behaviour sometimes bites badly, as it did for you here. Trouble is, removing the hack has (or used to have) a significant negative effect on performance of lots of programs. Still, I think that there are various other possibilities to try. For example, compiling the I/O libraries (only) with the state-hack on, and with it off by default elsewhere, might gather most of the benefits without the costs. Or restricting it to top level functions. Or something like that. It needs someone who's willing to do some measurements and try variations. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 5 05:22:56 2008 From: trac at galois.com (GHC) Date: Tue Feb 5 05:21:58 2008 Subject: [GHC] #2047: ghc compiled program crashes with segfault when using -M and/or -c In-Reply-To: <042.76ffc0b2217121d0a72a366715d60678@localhost> References: <042.76ffc0b2217121d0a72a366715d60678@localhost> Message-ID: <051.f6e4f378a5f1905ada4df3e68da201f2@localhost> #2047: ghc compiled program crashes with segfault when using -M and/or -c ----------------------------+----------------------------------------------- Reporter: mte | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.8.3 Component: Runtime System | Version: 6.8.2 Severity: critical | Resolution: Keywords: gc segfault | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------------+----------------------------------------------- Changes (by simonmar): * owner: => simonmar Comment: I'm validating a fix for this -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 5 05:57:19 2008 From: trac at galois.com (GHC) Date: Tue Feb 5 05:56:21 2008 Subject: [GHC] #2070: Record field selectors are not optimized In-Reply-To: <045.8e094bc4214e699ba9a0f23a87d8a407@localhost> References: <045.8e094bc4214e699ba9a0f23a87d8a407@localhost> Message-ID: <054.32bcfb94b35a167b75de6c8027445d85@localhost> #2070: Record field selectors are not optimized ----------------------+----------------------------------------------------- Reporter: twanvl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonpj): * difficulty: => Unknown Comment: Here's another example, found by Twan van Laarhoven, in GHC itself, module `Var.lhs`. When also trying to change the `FastInt` in `Var` to an unpacked `Unique` I ran into #2070. If I write it out `varUnique` manually I do get a good result, but not exactly the same. In particular I get: {{{ NewVar.varUnique = \r [ds] case ds of wild { NewVar.TyVar ds1 rb ds2 ds3 -> GHC.Base.I# [rb]; NewVar.TcTyVar ds1 rb ds2 ds3 -> GHC.Base.I# [rb]; NewVar.GlobalId ds1 rb ds2 ds3 ds4 -> GHC.Base.I# [rb]; NewVar.LocalId ds1 rb ds2 ds3 ds4 -> GHC.Base.I# [rb]; }; }}} But the automatically generated one looks like this: {{{ OldVar.varUnique = \r [var] case case var of tpl { OldVar.TyVar ipv ipv1 ipv2 ipv3 -> ipv1; OldVar.TcTyVar ipv ipv1 ipv2 ipv3 -> ipv1; OldVar.GlobalId ipv ipv1 ipv2 ipv3 ipv4 -> ipv1; OldVar.LocalId ipv ipv1 ipv2 ipv3 ipv4 -> ipv1; } of wild { __DEFAULT -> GHC.Base.I# [wild]; }; }}} In other words, the boxing is taken out of the case branches. I don't know whether this is an improvement or not. It might reduce code size. This function is inlined in the comparison operators, here the difference becomes larger. The new code looks like (pseudocode): {{{ NewVar.== a b = case a of TyVar _ c _ _ -> case b of TyVar _ d _ _ -> c ==# d TcTyVar _ d _ _ -> c ==# d GlobalId _ d _ _ _ -> c ==# d LocalId _ d _ _ _ -> c ==# d TcTyVar _ c _ _ -> etc. }}} Here `varUnique b` is inlined for each branch of `varUnique a`. Whereas the old code is a lot shorter, because the unique of the first parameter is first put into a variable, {{{ OldVar.== a b = case (case a of TyVar _ c _ _ -> c TcTyVar _ c _ _ -> c GlobalId _ c _ _ _ -> c LocalId _ c _ _ _ -> c ) of c -> case (case b of TyVar _ d _ _ -> d TcTyVar _ d _ _ -> d GlobalId _ d _ _ _ -> d LocalId _ d _ _ _ -> d ) of d -> c ==# d }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 5 10:01:06 2008 From: trac at galois.com (GHC) Date: Tue Feb 5 10:00:08 2008 Subject: [GHC] #1476: Template Haskell: splicing types and patterns In-Reply-To: <044.82d6405cd82a3ed24c1f19d7ab79c38b@localhost> References: <044.82d6405cd82a3ed24c1f19d7ab79c38b@localhost> Message-ID: <053.489c89066f89de761322d098d71f0659@localhost> #1476: Template Haskell: splicing types and patterns ------------------------------+--------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Template Haskell | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ------------------------------+--------------------------------------------- Changes (by fons): * cc: alfonso.acosta@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 5 10:06:46 2008 From: trac at galois.com (GHC) Date: Tue Feb 5 10:05:58 2008 Subject: [GHC] #1475: Adding imports and exports with Template Haskell In-Reply-To: <044.e6912bf72a7a61e5dd62c8e0004e6c4e@localhost> References: <044.e6912bf72a7a61e5dd62c8e0004e6c4e@localhost> Message-ID: <053.c12fbc72c923f801654ac2bfd96e2f1c@localhost> #1475: Adding imports and exports with Template Haskell ------------------------------+--------------------------------------------- Reporter: igloo | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Template Haskell | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ------------------------------+--------------------------------------------- Changes (by fons): * cc: alfonso.acosta@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 5 11:28:15 2008 From: trac at galois.com (GHC) Date: Tue Feb 5 11:27:18 2008 Subject: [GHC] #1476: Template Haskell: splicing types and patterns In-Reply-To: <044.82d6405cd82a3ed24c1f19d7ab79c38b@localhost> References: <044.82d6405cd82a3ed24c1f19d7ab79c38b@localhost> Message-ID: <053.31834eb618b985dcb38b3aebc6a579ee@localhost> #1476: Template Haskell: splicing types and patterns ------------------------------+--------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Template Haskell | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ------------------------------+--------------------------------------------- Comment (by simonpj): GHC HEAD now has Geoff Mainland's quasi-quoting patch, which does allow splicing into patterns. (But not types.) See http://www.haskell.org/ghc/dist/current/docs/users_guide/template- haskell.html#th-quasiquotation I wonder if that helps? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 5 11:49:38 2008 From: trac at galois.com (GHC) Date: Tue Feb 5 11:48:40 2008 Subject: [GHC] #1537: do notation translation In-Reply-To: <051.002894fe88bc6a156c09bce0721f2c76@localhost> References: <051.002894fe88bc6a156c09bce0721f2c76@localhost> Message-ID: <060.fad406f39142987614805176bd207654@localhost> #1537: do notation translation --------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.7 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: rebindable8, rebindable9 | Architecture: Unknown Os: Unknown | --------------------------------------+------------------------------------- Comment (by simonpj): Oleg remarks: It seems this fix should make the do notation work both for restricted and parameterized monads. The article mentioned in the ticket did not make it clear that the restricted and parameterized monads are distinct. Here is the interface that should work both for parameterized and restricted monads: {{{ class MonadB m1 m2 m3 a b | m1 m2 -> m3 where bind:: m1 a -> (a -> m2 b) -> m3 b class MonadR m a where ret:: a -> m a fail:: String -> m a }}} Parameterized monads parameterize on `m` (or `m1`, `m2`, `m3`) whereas restricted monads specialize 'a' or 'b' (one can imagine `monads' that do both). Incidentally, http://okmij.org/ftp/Haskell/RestrictedMonad.lhs http://okmij.org/ftp/Computation/VarStateM.hs can be used (with small adjustments) as tests of the new do-notation. The adjustments is in replacing `bind2/ret2` or `gbind/gret` and the corresponding infix operators with the do-notation. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 5 12:04:08 2008 From: trac at galois.com (GHC) Date: Tue Feb 5 12:03:09 2008 Subject: [GHC] #2070: Record field selectors are not optimized In-Reply-To: <045.8e094bc4214e699ba9a0f23a87d8a407@localhost> References: <045.8e094bc4214e699ba9a0f23a87d8a407@localhost> Message-ID: <054.c6dbe95a64d5d7fe47afe66797074a9a@localhost> #2070: Record field selectors are not optimized ----------------------+----------------------------------------------------- Reporter: twanvl | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: This patch should fix it {{{ Tue Feb 5 16:55:07 GMT Standard Time 2008 simonpj@microsoft.com * Inject implicit bindings before the simplifier (Trac #2070) }}} No need to merge to the 6.8 branch. I'm not sure how to make a decent test for this, so I'm just closing it. If someone can dream up a test, that'd be good. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 5 12:06:25 2008 From: trac at galois.com (GHC) Date: Tue Feb 5 12:05:26 2008 Subject: [GHC] #1537: do notation translation In-Reply-To: <051.002894fe88bc6a156c09bce0721f2c76@localhost> References: <051.002894fe88bc6a156c09bce0721f2c76@localhost> Message-ID: <060.a285cb1805510c0e7b960e03583b8021@localhost> #1537: do notation translation --------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: simonpj Type: merge | Status: reopened Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: rebindable8, rebindable9 | Architecture: Unknown Os: Unknown | --------------------------------------+------------------------------------- Changes (by simonpj): * status: closed => reopened * type: bug => merge * resolution: fixed => * cc: oleg@okmij.org (added) Comment: OK here's a fix: {{{ Tue Feb 5 16:48:16 GMT Standard Time 2008 simonpj@microsoft.com * Make do-notation a bit more flexible (Trac #1537) }}} Probably worth merging, hence re-opening. I hope Oleg will produce a more interesting test. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 5 12:33:15 2008 From: trac at galois.com (GHC) Date: Tue Feb 5 12:32:16 2008 Subject: [GHC] #1537: do notation translation In-Reply-To: <051.002894fe88bc6a156c09bce0721f2c76@localhost> References: <051.002894fe88bc6a156c09bce0721f2c76@localhost> Message-ID: <060.c9e61526ad4d478bdd372941d171b516@localhost> #1537: do notation translation --------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: simonpj Type: merge | Status: reopened Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: rebindable8, rebindable9 | Architecture: Unknown Os: Unknown | --------------------------------------+------------------------------------- Comment (by mnislaih): I gather that you think the test rebindable 9 is not interesting. It may seem that the instances {{{ instance Bind Identity m m where ... instance Bind m Identity m where ... }}} are artificial and don't show up in real code. But on the contrary, they are at the heart of the parameterized monads framework! These types show up all the time. On the other hand, testing the new rebindable code with Oleg's restricted monads is definitely interesting too. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 5 12:54:58 2008 From: trac at galois.com (GHC) Date: Tue Feb 5 12:54:00 2008 Subject: [GHC] #1476: Template Haskell: splicing types and patterns In-Reply-To: <044.82d6405cd82a3ed24c1f19d7ab79c38b@localhost> References: <044.82d6405cd82a3ed24c1f19d7ab79c38b@localhost> Message-ID: <053.56d01c550aa403e5cfc679d06e416c70@localhost> #1476: Template Haskell: splicing types and patterns ------------------------------+--------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Template Haskell | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ------------------------------+--------------------------------------------- Comment (by fons): Replying to [comment:2 simonpj]: > GHC HEAD now has Geoff Mainland's quasi-quoting patch, which does allow splicing into patterns. (But not types.) Cool! I have just read the paper and seems to add a lot of possibilities for embedding DSLs in Haskell. > I wonder if that helps? Yes, it would certainly help (assuming there is a Haskell quasiquote parser available). The fact that custom quasiquotes (I don't know if it's an appropiate term to call Mainland's work) are already working with GHC 6.9, makes me think that implementing TH pattern quasiquoting/splicing should be indeed very similar. In fact, Mainland's quasiquotes could be viewed as syntactic sugar for TH quasiquotes Using the new quasiquotes one can do something like {{{ expParser :: String -> Q Exp patParser :: String -> Q Pat expr = QuasiQuoter expParser patParser [$exp|randomstring|] }}} Which would be equivalent to (quasiquoting/splicing was working for patterns for TH). {{{ expParser :: String -> Q Exp patParser :: String -> Q Pat $(expParser "randomstring") $(patParser "randomstring") }}} The only major difference I see is that with Mainland's implementation the pattern or expression parser is dynamically chosen depending on its context. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 5 13:16:49 2008 From: trac at galois.com (GHC) Date: Tue Feb 5 13:16:02 2008 Subject: [GHC] #1992: 6.8.2 intermittent build failure on multiple OS X versions In-Reply-To: <044.6e3d43e6297883ec96aae365685c0c7d@localhost> References: <044.6e3d43e6297883ec96aae365685c0c7d@localhost> Message-ID: <053.d9868af8c23a32a01ee045785be06da6@localhost> #1992: 6.8.2 intermittent build failure on multiple OS X versions ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: MacOS X | ----------------------+----------------------------------------------------- Comment (by gwright): I suspect that this bug has been seen before. In early December, Duncan Coutts sent a message to the Cabal list saying that he had fixed a problem in which the ghc's version wasn't detected. I saw the same thing when building 6.8.1 on Panther/ppc. It was caused by a lock error on the temporary file that received the output of ghc --numeric-version. (Cabal had caught the error and discarded it, returning "" for the version string.) Duncan's patch was to move the temporary file from the current directory to that returned by getTemporaryDirectory. I tried a similar thing --- I just hard coded "/tmp" as the temp file's directory --- but still got lock errors. But it's been difficult to make this bug consistently reproducible. The most repeatable setup has been to build in an eshell or just a comint buffer running under Aquamacs. This fails almost every time with a linker error complaining that libHShaskell98-1.0.1.0.a doesn't have a table of contents. It looks like ranlib wasn't run on it. Strangely, vanilla emacs 22.1 is OK. Building under MacPorts fails about a quarter of the time, usually with a lock error. MacPorts runs it scripts under a tclsh, but I've not been able to reproduce the bug running under a bare tclsh. I had thought that this might be related to the fix for bug #724, which avoids putting file descriptors inherited from external processes into nonblocking mode. I backed out the change and built a new bootstrap compiler (using MacPorts), then built in an eshell under Aquamacs a fresh tree that had the #724 change backed out. No dice. The build still failed with a link error because ranlib had not been run on libHShaskell98-1.0.1.0.a. Here's one thing that may or may not be significant: when libHShaskell-98 is registered, the build logs under Aquamacs and bash/terminal show a different order of operations. Under bash/terminal, {{{ ar: creating archive dist/build/libHShaskell98-1.0.1.0.a /usr/bin/ld -x -r -o dist/build/HShaskell98-1.0.1.0.o -L/opt/local/lib dist/build/Array.o dist/build/CPUTime.o dist/build/Char.o dist/build/Complex.o dist/build/Directory.o dist/build/IO.o dist/build/Ix.o dist/build/List.o dist/build/Locale.o dist/build/Maybe.o dist/build/Monad.o dist/build/Random.o dist/build/Ratio.o dist/build/System.o dist/build/Time.o dist/build/Bits.o dist/build/CError.o dist/build/CForeign.o dist/build/CString.o dist/build/CTypes.o dist/build/ForeignPtr.o dist/build/Int.o dist/build/MarshalAlloc.o dist/build/MarshalArray.o dist/build/MarshalError.o dist/build/MarshalUtils.o dist/build/Ptr.o dist/build/StablePtr.o dist/build/Storable.o dist/build/Word.o `find dist/build -name "*_stub.o" -print` Reading package info from "dist/inplace-pkg-config" ... done. Saving old package config file... done. Writing new package config file... done. Registering haskell98-1.0.1.0... create dist/inplace-pkg-config ("../../utils/ghc-pkg/ghc-pkg-inplace",["update","dist/inplace-pkg- config"]) }}} while Aquamacs shows {{{ ar: creating archive dist/build/libHShaskell98-1.0.1.0.a /usr/bin/ld -x -r -o dist/build/HShaskell98-1.0.1.0.o -L/opt/local/lib dist/build/Array.o dist/build/CPUTime.o dist/build/Char.o dist/build/Complex.o dist/build/Directory.o dist/build/IO.o dist/build/Ix.o dist/build/List.o dist/build/Locale.o dist/build/Maybe.o dist/build/Monad.o dist/build/Random.o dist/build/Ratio.o dist/build/System.o dist/build/Time.o dist/build/Bits.o dist/build/CError.o dist/build/CForeign.o dist/build/CString.o dist/build/CTypes.o dist/build/ForeignPtr.o dist/build/Int.o dist/build/MarshalAlloc.o dist/build/MarshalArray.o dist/build/MarshalError.o dist/build/MarshalUtils.o dist/build/Ptr.o dist/build/StablePtr.o dist/build/Storable.o dist/build/Word.o `find dist/build -name "*_stub.o" -print` Registering haskell98-1.0.1.0... create dist/inplace-pkg-config ("../../utils/ghc-pkg/ghc-pkg-inplace",["update","dist/inplace-pkg- config"]) Reading package info from "dist/inplace-pkg-config" ... done. Saving old package config file... done. Writing new package config file... done. }}} and the build fails shortly afterward when stage2 begins because libHSHaskell98.a has no table of contents. Ranlib should have been run by installLib (in Cabal/Distribution/Simple/GHC.hs), but for some reason it wasn't. But the different order of output may not mean anything. When I build under vanilla emacs I get the same order of output as under Aquamacs, but the build succeeds. I modified installLib to force the verbosity of calls to rawSystemProgram to "deafening". This should have at least printed out when ranlib was called. In this case, the build failed with a lock error: {{{ Creating main/Config.hs ... done. Creating stage1/ghc_boot_platform.h... Done. gcc -E -I/opt/local/include -undef -traditional -P -I../includes -x c prelude/primops.txt.pp | \ grep -v '^#pragma GCC' > prelude/primops.txt ../utils/genprimopcode/genprimopcode --data-decl < prelude/primops.txt > primop-data-decl.hs-incl ../utils/genprimopcode/genprimopcode --primop-tag < prelude/primops.txt > primop-tag.hs-incl ../utils/genprimopcode/genprimopcode --primop-list < prelude/primops.txt > primop-list.hs-incl ../utils/genprimopcode/genprimopcode --has-side-effects < prelude/primops.txt > primop-has-side-effects.hs-incl ../utils/genprimopcode/genprimopcode --out-of-line < prelude/primops.txt > primop-out-of-line.hs-incl ../utils/genprimopcode/genprimopcode --commutable < prelude/primops.txt > primop-commutable.hs-incl ../utils/genprimopcode/genprimopcode --needs-wrapper < prelude/primops.txt > primop-needs-wrapper.hs-incl ../utils/genprimopcode/genprimopcode --can-fail < prelude/primops.txt > primop-can-fail.hs-incl ../utils/genprimopcode/genprimopcode --strictness < prelude/primops.txt > primop-strictness.hs-incl ../utils/genprimopcode/genprimopcode --primop-primop-info < prelude/primops.txt > primop-primop-info.hs-incl touch .depend-BASE /opt/local/bin/ghc -M -optdep-f -optdep.depend-BASE -osuf o -I../includes -optdep--exclude-module=Compat.RawSystem -optdep--exclude- module=Compat.Directory -optdep--exclude-module=Compat.Unicode -optdep --exclude-module=Distribution.Compat.FilePath -optdep--exclude- module=Distribution.Compat.ReadP -optdep--exclude- module=Distribution.Extension -optdep--exclude-module=Distribution.GetOpt -optdep--exclude-module=Distribution.InstalledPackageInfo -optdep --exclude-module=Distribution.License -optdep--exclude- module=Distribution.Package -optdep--exclude- module=Distribution.ParseUtils -optdep--exclude- module=Distribution.Compiler -optdep--exclude-module=Distribution.Version -optdep--exclude-module=System.FilePath -optdep--exclude- module=System.FilePath.Posix -optdep--exclude- module=System.FilePath.Windows -optdep--exclude- module=System.Directory.Internals -optdep--exclude-module=Trace.Hpc.Mix -optdep--exclude-module=Trace.Hpc.Tix -optdep--exclude- module=Trace.Hpc.Util -H128m -O -fasm -Rghc-timing -I/opt/local/include -L/opt/local/lib -iutils -ibasicTypes -itypes -ihsSyn -iprelude -irename -itypecheck -ideSugar -icoreSyn -ivectorise -ispecialise -isimplCore -istranal -istgSyn -isimplStg -icodeGen -imain -iprofiling -iparser -icprAnalysis -indpFlatten -iiface -icmm -inativeGen -Wall -fno-warn-name- shadowing -fno-warn-orphans -Istage1 -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -Iparser -package unix -ignore-package lang -recomp -Rghc-timing -O0 -DDEBUG -W -H16M '-#include "cutils.h"' -DUSING_COMPAT -i../compat -ignore-package Cabal -package directory -package pretty -package containers basicTypes/BasicTypes.lhs basicTypes/DataCon.lhs basicTypes/Demand.lhs basicTypes/Id.lhs basicTypes/IdInfo.lhs basicTypes/Literal.lhs basicTypes/MkId.lhs basicTypes/Module.lhs basicTypes/Name.lhs basicTypes/NameEnv.lhs basicTypes/NameSet.lhs basicTypes/NewDemand.lhs basicTypes/OccName.lhs basicTypes/RdrName.lhs basicTypes/SrcLoc.lhs basicTypes/UniqSupply.lhs basicTypes/Unique.lhs basicTypes/Var.lhs basicTypes/VarEnv.lhs basicTypes/VarSet.lhs cmm/CLabel.hs cmm/Cmm.hs cmm/CmmBrokenBlock.hs cmm/CmmCPS.hs cmm/CmmCPSGen.hs cmm/CmmCallConv.hs cmm/CmmInfo.hs cmm/CmmLex.hs cmm/CmmLint.hs cmm/CmmLive.hs cmm/CmmOpt.hs cmm/CmmParse.hs cmm/CmmProcPoint.hs cmm/CmmUtils.hs cmm/Dataflow.hs cmm/MachOp.hs cmm/PprC.hs cmm/PprCmm.hs codeGen/Bitmap.hs codeGen/CgBindery.lhs codeGen/CgCallConv.hs codeGen/CgCase.lhs codeGen/CgClosure.lhs codeGen/CgCon.lhs codeGen/CgExpr.lhs codeGen/CgForeignCall.hs codeGen/CgHeapery.lhs codeGen/CgHpc.hs codeGen/CgInfoTbls.hs codeGen/CgLetNoEscape.lhs codeGen/CgMonad.lhs codeGen/CgParallel.hs codeGen/CgPrimOp.hs codeGen/CgProf.hs codeGen/CgStackery.lhs codeGen/CgTailCall.lhs codeGen/CgTicky.hs codeGen/CgUtils.hs codeGen/ClosureInfo.lhs codeGen/CodeGen.lhs codeGen/SMRep.lhs coreSyn/CoreFVs.lhs coreSyn/CoreLint.lhs coreSyn/CorePrep.lhs coreSyn/CoreSubst.lhs coreSyn/CoreSyn.lhs coreSyn/CoreTidy.lhs coreSyn/CoreUnfold.lhs coreSyn/CoreUtils.lhs coreSyn/ExternalCore.lhs coreSyn/MkExternalCore.lhs coreSyn/PprCore.lhs coreSyn/PprExternalCore.lhs cprAnalysis/CprAnalyse.lhs deSugar/Check.lhs deSugar/Coverage.lhs deSugar/Desugar.lhs deSugar/DsArrows.lhs deSugar/DsBinds.lhs deSugar/DsCCall.lhs deSugar/DsExpr.lhs deSugar/DsForeign.lhs deSugar/DsGRHSs.lhs deSugar/DsListComp.lhs deSugar/DsMonad.lhs deSugar/DsUtils.lhs deSugar/Match.lhs deSugar/MatchCon.lhs deSugar/MatchLit.lhs hsSyn/HsBinds.lhs hsSyn/HsDecls.lhs hsSyn/HsDoc.hs hsSyn/HsExpr.lhs hsSyn/HsImpExp.lhs hsSyn/HsLit.lhs hsSyn/HsPat.lhs hsSyn/HsSyn.lhs hsSyn/HsTypes.lhs hsSyn/HsUtils.lhs iface/BinIface.hs iface/BuildTyCl.lhs iface/IfaceEnv.lhs iface/IfaceSyn.lhs iface/IfaceType.lhs iface/LoadIface.lhs iface/MkIface.lhs iface/TcIface.lhs main/BreakArray.hs main/CmdLineParser.hs main/CodeOutput.lhs main/Config.hs main/Constants.lhs main/DriverMkDepend.hs main/DriverPhases.hs main/DriverPipeline.hs main/DynFlags.hs main/ErrUtils.lhs main/Finder.lhs main/GHC.hs main/HeaderInfo.hs main/HscMain.lhs main/HscStats.lhs main/HscTypes.lhs main/InteractiveEval.hs main/Main.hs main/PackageConfig.hs main/Packages.lhs main/ParsePkgConf.hs main/PprTyThing.hs main/StaticFlags.hs main/SysTools.lhs main/TidyPgm.lhs nativeGen/AsmCodeGen.lhs nativeGen/GraphBase.hs nativeGen/GraphColor.hs nativeGen/GraphOps.hs nativeGen/GraphPpr.hs nativeGen/MachCodeGen.hs nativeGen/MachInstrs.hs nativeGen/MachRegs.lhs nativeGen/NCGMonad.hs nativeGen/PositionIndependentCode.hs nativeGen/PprMach.hs nativeGen/RegAllocColor.hs nativeGen/RegAllocInfo.hs nativeGen/RegAllocLinear.hs nativeGen/RegAllocStats.hs nativeGen/RegArchBase.hs nativeGen/RegArchX86.hs nativeGen/RegCoalesce.hs nativeGen/RegLiveness.hs nativeGen/RegSpill.hs nativeGen/RegSpillClean.hs nativeGen/RegSpillCost.hs ndpFlatten/FlattenInfo.hs ndpFlatten/FlattenMonad.hs ndpFlatten/Flattening.hs ndpFlatten/NDPCoreUtils.hs ndpFlatten/PArrAnal.hs parser/Ctype.lhs parser/HaddockLex.hs parser/HaddockParse.hs parser/HaddockUtils.hs parser/LexCore.hs parser/Lexer.hs parser/Parser.hs parser/ParserCore.hs parser/ParserCoreUtils.hs parser/RdrHsSyn.lhs prelude/ForeignCall.lhs prelude/PrelInfo.lhs prelude/PrelNames.lhs prelude/PrelRules.lhs prelude/PrimOp.lhs prelude/TysPrim.lhs prelude/TysWiredIn.lhs profiling/CostCentre.lhs profiling/SCCfinal.lhs rename/RnBinds.lhs rename/RnEnv.lhs rename/RnExpr.lhs rename/RnHsDoc.hs rename/RnHsSyn.lhs rename/RnNames.lhs rename/RnSource.lhs rename/RnTypes.lhs simplCore/CSE.lhs simplCore/FloatIn.lhs simplCore/FloatOut.lhs simplCore/LiberateCase.lhs simplCore/OccurAnal.lhs simplCore/SAT.lhs simplCore/SATMonad.lhs simplCore/SetLevels.lhs simplCore/SimplCore.lhs simplCore/SimplEnv.lhs simplCore/SimplMonad.lhs simplCore/SimplUtils.lhs simplCore/Simplify.lhs simplStg/SRT.lhs simplStg/SimplStg.lhs simplStg/StgStats.lhs specialise/Rules.lhs specialise/SpecConstr.lhs specialise/Specialise.lhs stgSyn/CoreToStg.lhs stgSyn/StgLint.lhs stgSyn/StgSyn.lhs stranal/DmdAnal.lhs stranal/SaAbsInt.lhs stranal/SaLib.lhs stranal/StrictAnal.lhs stranal/WorkWrap.lhs stranal/WwLib.lhs typecheck/FamInst.lhs typecheck/Inst.lhs typecheck/TcArrows.lhs typecheck/TcBinds.lhs typecheck/TcClassDcl.lhs typecheck/TcDefaults.lhs typecheck/TcDeriv.lhs typecheck/TcEnv.lhs typecheck/TcExpr.lhs typecheck/TcForeign.lhs typecheck/TcGadt.lhs typecheck/TcGenDeriv.lhs typecheck/TcHsSyn.lhs typecheck/TcHsType.lhs typecheck/TcInstDcls.lhs typecheck/TcMType.lhs typecheck/TcMatches.lhs typecheck/TcPat.lhs typecheck/TcRnDriver.lhs typecheck/TcRnMonad.lhs typecheck/TcRnTypes.lhs typecheck/TcRules.lhs typecheck/TcSimplify.lhs typecheck/TcTyClsDecls.lhs typecheck/TcTyDecls.lhs typecheck/TcTyFuns.lhs typecheck/TcType.lhs typecheck/TcUnify.lhs types/Class.lhs types/Coercion.lhs types/FamInstEnv.lhs types/FunDeps.lhs types/Generics.lhs types/InstEnv.lhs types/TyCon.lhs types/Type.lhs types/TypeRep.lhs types/Unify.lhs utils/Bag.lhs utils/Binary.hs utils/BufWrite.hs utils/Digraph.lhs utils/Encoding.hs utils/FastMutInt.lhs utils/FastString.lhs utils/FastTypes.lhs utils/FiniteMap.lhs utils/IOEnv.hs utils/ListSetOps.lhs utils/Maybes.lhs utils/OrdList.lhs utils/Outputable.lhs utils/Panic.lhs utils/Pretty.lhs utils/State.hs utils/StringBuffer.lhs utils/UniqFM.lhs utils/UniqSet.lhs utils/Util.lhs vectorise/VectBuiltIn.hs vectorise/VectCore.hs vectorise/VectMonad.hs vectorise/VectType.hs vectorise/VectUtils.hs vectorise/Vectorise.hs main/InteractiveEval.hs: openBinaryFile: resource busy (file is locked) <> make[1]: *** [depend] Error 1 make: *** [stage1] Error 1 }}} Just like playing whack-a-mole. The bug has now moved somewhere else. The common factor may be process handing. I've been trying to use dtrace to trace process (alas, ktrace is gone on Leopard). Unfortunately, on OS X, dtrace is at best beta quality. For example, you can not reliably get at least some of the arguments to a process that is execve'd as you can on Solaris. Since the error I can easily reproduce is the missed ranlib, I will keep working with dtrace to try to get some kind of usable trace. I am travelling and only have my MacBook running Leopard, but next week I will have access to my wife's iBook running Panther. I can do a ktrace with hers. The debugging process has been slow since I'm building 6.8.2 with a 6.8.2 bootstrap compiler. When I make a patch, I rebuild the bootstrap compiler until it succeeds, then do a test build. By keeping the bootstrap compiler tree identical to the test tree I hope to avoid chasing my tail with a buggy bootstrap. But if there are any suggestions to safely speed up the process, I would welcome them. Any hints as to what might have changed from 6.6 to 6.8 that might cause this problem? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 5 16:59:15 2008 From: trac at galois.com (GHC) Date: Tue Feb 5 16:58:22 2008 Subject: [GHC] #2077: GHC ignores pragma due to preceding comment Message-ID: <042.0b4c0b8e9e9744fc81cbbbf2d6e1e185@localhost> #2077: GHC ignores pragma due to preceding comment -------------------------------+-------------------------------------------- Reporter: tbh | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Parser) Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Linux -------------------------------+-------------------------------------------- GHC ignores a {{{ {-# OPTIONS -fglasgow-exts #-} }}} pragma because something in the preceding comment block seems to irritate the parser. The attached files demonstrate this, in Trie1.hs the compiler ignores the pragma while Trie2.hs works fine. The only differences are the deleted lines in the comment block on top of the file. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 6 03:17:15 2008 From: trac at galois.com (GHC) Date: Wed Feb 6 03:16:25 2008 Subject: [GHC] #1476: Template Haskell: splicing types and patterns In-Reply-To: <044.82d6405cd82a3ed24c1f19d7ab79c38b@localhost> References: <044.82d6405cd82a3ed24c1f19d7ab79c38b@localhost> Message-ID: <053.166cb8b54e4f27f75575e8cdc1bda07b@localhost> #1476: Template Haskell: splicing types and patterns ------------------------------+--------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Template Haskell | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ------------------------------+--------------------------------------------- Comment (by simonpj): No, there's another major difference: a QQ splice is the result of applying a constant function (the parser) to a string. The QQ splice is run in the renamer, before type checking even begins, while scopes are being resolved. In contrast TH splices run an arbitrary Haskell expression, which must be typechecked first. This is therefore done during type checking. It's much harder to deal with patterns. See the discussion of TH splices that bind variables in http://research.microsoft.com/~simonpj/tmp/notes2.ps. So they are similar, yes, which is why the documentation appears in the TH section of the manual, but QQ splices have a very particular form (as you describe above). Bottom line: I don't yet see a good design for full TH splices in patterns. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 6 03:59:36 2008 From: trac at galois.com (GHC) Date: Wed Feb 6 03:58:36 2008 Subject: [GHC] #1537: do notation translation In-Reply-To: <051.002894fe88bc6a156c09bce0721f2c76@localhost> References: <051.002894fe88bc6a156c09bce0721f2c76@localhost> Message-ID: <060.f1cabfd7aa80fc0a526aac747d886fb4@localhost> #1537: do notation translation --------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: simonpj Type: merge | Status: reopened Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: rebindable8, rebindable9 | Architecture: Unknown Os: Unknown | --------------------------------------+------------------------------------- Comment (by simonpj): Oh no, I didn't say that rebindable9 was uninteresting; just that more tests are better. I'd like to be sure that we handle Oleg's case, and having it in the test suite makes sure it'll stay working too. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 6 04:19:07 2008 From: trac at galois.com (GHC) Date: Wed Feb 6 04:18:08 2008 Subject: [GHC] #2047: ghc compiled program crashes with segfault when using -M and/or -c In-Reply-To: <042.76ffc0b2217121d0a72a366715d60678@localhost> References: <042.76ffc0b2217121d0a72a366715d60678@localhost> Message-ID: <051.27e697c79ea2a99e3fc1a6a37a86a644@localhost> #2047: ghc compiled program crashes with segfault when using -M and/or -c ----------------------------+----------------------------------------------- Reporter: mte | Owner: igloo Type: merge | Status: new Priority: high | Milestone: 6.8.3 Component: Runtime System | Version: 6.8.2 Severity: critical | Resolution: Keywords: gc segfault | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------------+----------------------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: To merge: {{{ Tue Feb 5 02:14:25 PST 2008 Simon Marlow * FIX #2047: Windows (and older Unixes): align info tables to 4 bytes, not 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 6 04:24:13 2008 From: trac at galois.com (GHC) Date: Wed Feb 6 04:23:15 2008 Subject: [GHC] #2077: GHC ignores pragma due to preceding comment In-Reply-To: <042.0b4c0b8e9e9744fc81cbbbf2d6e1e185@localhost> References: <042.0b4c0b8e9e9744fc81cbbbf2d6e1e185@localhost> Message-ID: <051.79738f54c868b59810e338a253d7fe4c@localhost> #2077: GHC ignores pragma due to preceding comment -------------------------------+-------------------------------------------- Reporter: tbh | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Parser) | Version: 6.8.2 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | -------------------------------+-------------------------------------------- Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: Thanks for the report - we already have this one as #1736 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 6 04:24:26 2008 From: trac at galois.com (GHC) Date: Wed Feb 6 04:23:24 2008 Subject: [GHC] #1736: GHC doesn't spot OPTIONS_GHC pragmas after 1k of comments In-Reply-To: <044.d708ffe9ab9e53de96c4a2740c911bb4@localhost> References: <044.d708ffe9ab9e53de96c4a2740c911bb4@localhost> Message-ID: <053.934c38172a13484910683e9cd2d14eb1@localhost> #1736: GHC doesn't spot OPTIONS_GHC pragmas after 1k of comments -----------------------+---------------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Driver | Version: 6.8 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: pragma001 | Architecture: Unknown Os: Unknown | -----------------------+---------------------------------------------------- Comment (by simonmar): Also reported as #2077 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 6 05:25:29 2008 From: trac at galois.com (GHC) Date: Wed Feb 6 05:24:33 2008 Subject: [GHC] #2078: INLINE and strictness Message-ID: <046.ec2465d43c714bfe8387201a59766658@localhost> #2078: INLINE and strictness -----------------------------------------+---------------------------------- Reporter: simonpj | Owner: simonpj Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown -----------------------------------------+---------------------------------- Consider this code {{{ module A where {-# INLINE [0] foo #-} {#- RULE foo (reverse xs) = xs #-} foo xs = reverse $ xs module B where import A( foo ) g b ys = foo (case b of True -> reverse ys False -> ys) h xs = map foo xs }}} At the moment the body of `foo` is not optimised at all, because it's going to be inlined. But that means that * The `foo` executed by the `map` in `h` is very inefficient, because it actually calls `$` etc. * The strictness analyser doesn't see that `foo` is strict, because again the `$` gets in the way. So the rule for `foo` does not match in the RHS of `g`. (If `foo` were strict, we'd push the call to `foo` inside the case branches.) For both reasons it'd be better to * Retain the original RHS of `foo` for inlining purposes * But otherwise optimise `foo` normally, so that if it is not inlined, we get the efficient version, and so that strictness analysis does the right thing. Hmm. Maybe INLINE should turn into a RULE, rather than (as now) a `Note` in Core? Anyway, this ticket is to make sure I don't forget this point. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 6 05:25:58 2008 From: trac at galois.com (GHC) Date: Wed Feb 6 05:24:59 2008 Subject: [GHC] #2078: INLINE and strictness In-Reply-To: <046.ec2465d43c714bfe8387201a59766658@localhost> References: <046.ec2465d43c714bfe8387201a59766658@localhost> Message-ID: <055.c392c90fcf2ba8b214a8efc61c3bbfb8@localhost> #2078: INLINE and strictness --------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------------------+------------------------------------- Comment (by simonpj): Here's a concrete example when this came up: {{{ Wed Jan 23 16:12:07 PST 2008 Roman Leshchinskiy * Make zipD strict in both arguments The strictness analyser doesn't seem to be able to figure this out. This change improves fusion. M ./Data/Array/Parallel/Unlifted/Distributed/Types.hs -2 +2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 7 07:33:35 2008 From: trac at galois.com (GHC) Date: Thu Feb 7 07:32:30 2008 Subject: [GHC] #2079: GHC 6.8.* doesn't recognize type variables Message-ID: <056.62a26a1278f77580b6bb16d54151ba36@localhost> #2079: GHC 6.8.* doesn't recognize type variables ----------------------------------+----------------------------------------- Reporter: daniel.is.fischer | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: Linux ----------------------------------+----------------------------------------- The module {{{ {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FunctionalDependencies #-} {- # LANGUAGE FlexibleInstances # -} module Leandro where data Abb a b = Branch a b (Abb a b) (Abb a b) | Leaf data ListAssoc a b = Node a b (ListAssoc a b) | Empty class Container c a b |c -> a, c -> b where empty :: c add :: c -> a -> b -> c search :: c -> a -> Maybe b del :: c -> a -> c toListPair :: c -> [(a,b)] instance (Ord a) => Container (Abb a b) a b where empty = Leaf add Leaf x y = Branch x y Leaf Leaf add arb@(Branch ni nd ri rd) x y |x == ni = arb |x > ni = Branch ni nd ri (add rd x y) |otherwise = Branch ni nd (add ri x y) rd search Leaf x = Nothing search (Branch ni nd ri rd) x |x == ni = Just nd |x > ni = search rd x |x < ni = search ri x }}} triggers the following error in ghci (6.8.1 and 6.8.2): {{{ dafis@linux:~/Documents/haskell/move> ghci Leandro GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. [1 of 1] Compiling Leandro ( Leandro.hs, interpreted ) Leandro.hs:17:0: Illegal instance declaration for `Container (Abb a b) a b' (All instance types must be of the form (T a1 ... an) where a1 ... an are distinct type *variables* Use -XFlexibleInstances if you want to disable this.) In the instance declaration for `Container (Abb a b) a b' Failed, modules loaded: none. }}} To the best of my knowledge, a and b in 'instance Container (Abb a b) a b where' are distinct type variables and neither hugs nor ghci-6.6.1 complain. Converting the third line to a language pragma makes the code acceptable to 6.8.*. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 7 08:22:06 2008 From: trac at galois.com (GHC) Date: Thu Feb 7 08:21:02 2008 Subject: [GHC] #2079: GHC 6.8.* doesn't recognize type variables In-Reply-To: <056.62a26a1278f77580b6bb16d54151ba36@localhost> References: <056.62a26a1278f77580b6bb16d54151ba36@localhost> Message-ID: <065.b0711377484ca4a9d4f15ce90357e682@localhost> #2079: GHC 6.8.* doesn't recognize type variables -------------------------------+-------------------------------------------- Reporter: daniel.is.fischer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | -------------------------------+-------------------------------------------- Changes (by simonpj): * difficulty: => Unknown Comment: This is really an error message bug. Without `-XFlexibleInstances`, the restriction is that there must be no repeated type variables in the instance head. Whether this is a useful restriction to separate from multi-parameter type classes is moot. As it stands I agree it's confusing. I can think of three possibilities: * We could make `-XMultiParamTypeClasses` imply `-XFlexibleInstances`. * We could collapse the two options into one option. * We could leave the language pragmas unchanged, but change the error message to say "...where the a1..an are type *variables*, and each type variable appears at most once in the instance head". Would that have helped? Of these, the third is least likely to cause trouble others. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 7 09:14:49 2008 From: trac at galois.com (GHC) Date: Thu Feb 7 09:13:44 2008 Subject: [GHC] #2080: Bug in CmmOpt Message-ID: <047.290f3cd941004144cf5ab81d6bdfe1f5@localhost> #2080: Bug in CmmOpt -------------------------+-------------------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- Two bugs are demonstrated by the following code. The first one is wrong code generated for the comparison, and the second is the panic (see the comment): {{{ module Test where import GHC.Base utf8DecodeChar# :: Addr# -> Bool -> Bool {-# NOINLINE utf8DecodeChar# #-} utf8DecodeChar# a# fred = case () of _ | word2Int# (indexWord8OffAddr# a# 0#) <=# 0x7F# -> True -- Omitting the next line gives an ASSERT error: -- ghc-6.9: panic! (the 'impossible' happened) -- (GHC version 6.9 for x86_64-unknown-linux): -- ASSERT failed! file nativeGen/MachCodeGen.hs line 1049 -- %MO_S_Le_I8(I8[R2], 127 :: I8) | fred -> True | otherwise -> False }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 7 09:26:05 2008 From: trac at galois.com (GHC) Date: Thu Feb 7 09:25:00 2008 Subject: [GHC] #2079: GHC 6.8.* doesn't recognize type variables In-Reply-To: <056.62a26a1278f77580b6bb16d54151ba36@localhost> References: <056.62a26a1278f77580b6bb16d54151ba36@localhost> Message-ID: <065.b2db07220481746edf5c73dd09314445@localhost> #2079: GHC 6.8.* doesn't recognize type variables -------------------------------+-------------------------------------------- Reporter: daniel.is.fischer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | -------------------------------+-------------------------------------------- Comment (by daniel.is.fischer): I suppose the third would also be easiest to do :) It would certainly have helped, so do that, by all means. Though it's still a little confusing that 6.6.1 behaved differently. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 7 11:04:28 2008 From: trac at galois.com (GHC) Date: Thu Feb 7 11:03:25 2008 Subject: [GHC] #1537: do notation translation In-Reply-To: <051.002894fe88bc6a156c09bce0721f2c76@localhost> References: <051.002894fe88bc6a156c09bce0721f2c76@localhost> Message-ID: <060.62091863a668c93849bc0a0327e22653@localhost> #1537: do notation translation --------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: simonpj Type: merge | Status: reopened Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: rebindable8, rebindable9 | Architecture: Unknown Os: Unknown | --------------------------------------+------------------------------------- Comment (by simonpj): Incidentally, as a result of this change, the tests `rebindable5` and `rebindable6` now fail. I think they should fail (they get ambiguous types) but someone might want to check. Meanwhile I have so marked them in the testsuite repo. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 8 02:16:13 2008 From: trac at galois.com (GHC) Date: Fri Feb 8 02:15:07 2008 Subject: [GHC] #2081: On a strained PPC Mac OS X 10.4, GHC reports internal error: stg_ap_v_ret Message-ID: <050.436412791af8536dabd2387bab7c6cbf@localhost> #2081: On a strained PPC Mac OS X 10.4, GHC reports internal error: stg_ap_v_ret ----------------------------+----------------------------------------------- Reporter: thorkilnaur | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: powerpc | Os: MacOS X ----------------------------+----------------------------------------------- On a PPC Mac OS X 10.4 running {{{ while true; do du -k >/dev/null; done }}} to spend some resources, in about 50% of the cases, a GHC compile using a recent HEAD fails with this report: {{{ $ /Users/thorkilnaur/tn/GHCDarcsRepository/ghc-HEAD-complete-for-pulling- and-copying-20070713_1212/ghc/compiler/stage2/ghc-inplace --make -fforce- recomp -v0 concio001 -o concio001 ghc-6.9.20080203: internal error: stg_ap_v_ret (GHC version 6.9.20080203 for powerpc_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Abort trap }}} This reaction does not seem to depend on what is being compiled. Best regards Thorkil -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 8 09:02:34 2008 From: trac at galois.com (GHC) Date: Fri Feb 8 09:01:26 2008 Subject: [GHC] #2080: Bug in CmmOpt In-Reply-To: <047.290f3cd941004144cf5ab81d6bdfe1f5@localhost> References: <047.290f3cd941004144cf5ab81d6bdfe1f5@localhost> Message-ID: <056.fc64f274bd14d0ca935961150519369c@localhost> #2080: Bug in CmmOpt ----------------------+----------------------------------------------------- Reporter: simonmar | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: Fixed: {{{ Thu Feb 7 06:38:05 PST 2008 Simon Marlow * remove a bogus assertion Fri Feb 8 04:42:19 PST 2008 Simon Marlow * FIX #2080: an optimisation to remove a widening was wrong }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 8 09:41:58 2008 From: trac at galois.com (GHC) Date: Fri Feb 8 09:40:49 2008 Subject: [GHC] #1969: enormous compile times In-Reply-To: <045.1ab99ac1a52ae6b35a7131dc801608a9@localhost> References: <045.1ab99ac1a52ae6b35a7131dc801608a9@localhost> Message-ID: <054.94d9bc888212b8de96acb4e54ce7c660@localhost> #1969: enormous compile times ------------------------------------------+--------------------------------- Reporter: duncan | Owner: Type: compile-time performance bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: performance | Difficulty: Difficult (1 week) Testcase: | Architecture: Multiple Os: Multiple | ------------------------------------------+--------------------------------- Comment (by igloo): This program: {{{ main :: IO () main = writeFile "W.hs" $ unlines $ map unlines foo foo :: [[String]] foo = [ "module J where", "class C a where", " c :: a -> String", " d :: a -> String", " d x = c x", " e :: a -> String", " e x = c x" ] : [ ["data " ++ d ++ " = " ++ d, "instance C " ++ d ++ " where", " c " ++ d ++ " = \"" ++ d ++ "\""] | i <- [1..1000], let d = 'A' : show i ] }}} generates a `W.hs` with lots of instances like {{{ data A24 = A24 instance C A24 where c A24 = "A24" }}} Compiling with {{{ ghc -fforce-recomp -O -c W.hs +RTS -p }}} this is the interesting bit of the profile: {{{ individual COST CENTRE MODULE no. entries %time %alloc specProgram Specialise 8794 2006 0.0 0.0 specBind Specialise 8804 6006 0.0 0.0 splitUDs Specialise 8883 2002 3.1 4.0 elemVarSet VarSet 9174 1998000 0.1 0.2 listToCallDetails Specialise 8985 2000002 1.0 2.3 unionCalls Specialise 9182 1998000 31.1 37.6 tcCmpType Type 9186 57864047 9.3 0.0 intersectsVarSet VarSet 8885 4006001 0.2 0.0 }}} The number of entries for the last 5 grows quadratically with the number of instances. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 8 10:28:30 2008 From: trac at galois.com (GHC) Date: Fri Feb 8 10:27:23 2008 Subject: [GHC] #2047: ghc compiled program crashes with segfault when using -M and/or -c In-Reply-To: <042.76ffc0b2217121d0a72a366715d60678@localhost> References: <042.76ffc0b2217121d0a72a366715d60678@localhost> Message-ID: <051.48831be73ec0e8cdc83a86690954dbcb@localhost> #2047: ghc compiled program crashes with segfault when using -M and/or -c ----------------------------+----------------------------------------------- Reporter: mte | Owner: igloo Type: merge | Status: closed Priority: high | Milestone: 6.8.3 Component: Runtime System | Version: 6.8.2 Severity: critical | Resolution: fixed Keywords: gc segfault | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------------+----------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 8 10:29:57 2008 From: trac at galois.com (GHC) Date: Fri Feb 8 10:29:26 2008 Subject: [GHC] #1838: do not use getEnv "HOME", use System.Directory.getHomeDirectory In-Reply-To: <044.7c14aad23d72fc1f99272ac17d7d5b67@localhost> References: <044.7c14aad23d72fc1f99272ac17d7d5b67@localhost> Message-ID: <053.f4898df78f7458fd262fcdbcc436c8a0@localhost> #1838: do not use getEnv "HOME", use System.Directory.getHomeDirectory ---------------------+------------------------------------------------------ Reporter: guest | Owner: igloo Type: merge | Status: closed Priority: high | Milestone: 6.8.3 Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Windows | ---------------------+------------------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Both merged -- Ticket URL: GHC The Glasgow Haskell Compiler From pgavin at gmail.com Fri Feb 8 11:32:12 2008 From: pgavin at gmail.com (Peter Gavin) Date: Fri Feb 8 11:31:07 2008 Subject: building under MacOSX 10.5 with macports Message-ID: <47AC840C.9030600@gmail.com> Hello, I've been trying to build GHC-6.8 on Mac OSX 10.5 using the GMP and readline provided by macports. I'm not sure if others have been having this problem, but I've been having a low of trouble. I finally got it to build, but it required patching Cabal to do so. The problem seems to be that ranlib isn't being run from the cabal-generated makefiles after each libHS.a under libraries/ is built. At some point the build fails when trying to link to libHShaskell98.a, complaining about a missing index, so I ran ranlib on the library, and the build continued. I ended up patching cabal to add a ranlib call from the makefiles, and the build proceeded from start to finish, without failing. If anyone is interested in seeing the patch, I've sent it to the Cabal-devel list: http://www.haskell.org/pipermail/cabal-devel/2008-February/002033.html Has anyone else using Mac OSX 10.5 had this problem? Peter Gavin From trac at galois.com Fri Feb 8 12:45:02 2008 From: trac at galois.com (GHC) Date: Fri Feb 8 12:43:54 2008 Subject: [GHC] #1969: enormous compile times In-Reply-To: <045.1ab99ac1a52ae6b35a7131dc801608a9@localhost> References: <045.1ab99ac1a52ae6b35a7131dc801608a9@localhost> Message-ID: <054.8a9dfa09ceb387efb7f24c17b1813b60@localhost> #1969: enormous compile times ------------------------------------------+--------------------------------- Reporter: duncan | Owner: Type: compile-time performance bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: performance | Difficulty: Difficult (1 week) Testcase: | Architecture: Multiple Os: Multiple | ------------------------------------------+--------------------------------- Comment (by simonpj): Very interesting, and entirely unexpected (to me). No time to look now, but good progress. S -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 8 13:27:14 2008 From: trac at galois.com (GHC) Date: Fri Feb 8 13:26:11 2008 Subject: [GHC] #2082: In ghci, :i leaves out parens in type Message-ID: <052.f371aa73fee3aae45f7806e8fd54c670@localhost> #2082: In ghci, :i leaves out parens in type ------------------------------+--------------------------------------------- Reporter: chad.scherrer | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: Linux ------------------------------+--------------------------------------------- In ghci, :i sometimes leaves out parentheses in the type. For example, in Data.Stream, Prelude Data.Stream> :i Stream data Stream a where Stream :: forall a s. (Data.Stream.Unlifted s) => !s -> Step a s -> !s -> Stream a -- Defined in Data.Stream instance Functor Stream -- Defined in Data.Stream Here the type (Data.Stream.Unlifted s) => !s -> Step a s -> !s -> Stream a should instead be (Data.Stream.Unlifted s) => (!s -> Step a s) -> !s -> Stream a -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 8 16:13:57 2008 From: trac at galois.com (GHC) Date: Fri Feb 8 16:13:04 2008 Subject: [GHC] #2083: linker reports missing symbols Main.c:(.text+0x12): undefined reference to `__stginit_ZCMain' Main.c:(.text+0x2c): undefined reference to `ZCMain_main_closure' Message-ID: <054.f4411cf09d2804f4c2a24a7055f19618@localhost> #2083: linker reports missing symbols Main.c:(.text+0x12): undefined reference to `__stginit_ZCMain' Main.c:(.text+0x2c): undefined reference to `ZCMain_main_closure' --------------------------------+------------------------------------------- Reporter: Andrew U. Frank | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- i use 6.8.2 on linux (ubuntu 7.10). i use mainly eclipse and ghci, but when i try to compile a program, the linker reports the undefined references. for the minimal program 'hello world' i get Main.c:(.text+0x12): undefined reference to `__stginit_ZCMain' Main.c:(.text+0x2c): undefined reference to `ZCMain_main_closure' for more interesting programs i get a lot more (i have experimented with wxhaskell and phooey, tv, eros -- and some problems with compiling them in the right order etc..) suprisingly the problem goes away if the program is called Main.hs - then it links properly, but not when it is called Test.hs. the same program with main = putStr.... according to the ghc documentation, it is permitted to have in file Test.hs the module main. (and it works properly in ghci) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 8 17:38:41 2008 From: trac at galois.com (GHC) Date: Fri Feb 8 17:37:33 2008 Subject: [GHC] #2084: GHC panic Message-ID: <047.2af7ef94b11d6e7558fa16d6fcecb781@localhost> #2084: GHC panic -------------------------+-------------------------------------------------- Reporter: stimberm | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.1 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: MacOS X -------------------------+-------------------------------------------------- GHC crashed with the following output, but I don't know what this is about. Do you need other kind of information? ghc output: ghc-6.8.1: panic! (the 'impossible' happened) (GHC version 6.8.1 for i386-apple-darwin): tcIfaceGlobal (local): not found: main:Eval.$fx2{v r4H} [(r4J, Class `main:Eval.JustReturn{tc r4J}'), (r4L, Type constructor `main:Eval.:Co:TJustReturn{tc r4L}'), (r4M, Type constructor `main:Eval.:TJustReturn{tc r4M}'), (r4N, Data constructor `main:Eval.:DJustReturn{d r4N}'), (r4O, Identifier `main:Eval.:DJustReturn{v r4O}'), (r4P, Identifier `main:Eval.justReturn{v r4P}'), (r7Z, Class `main:Eval.Evaluator{tc r7Z}'), (r80, Identifier `main:Eval.eval{v r80}'), (r81, Class `main:Eval.ContextProceed{tc r81}'), (r82, Identifier `main:Eval.proceed{v r82}'), (ra8, Data constructor `main:Eval.:DEvaluator{d ra8}'), (ra9, Type constructor `main:Eval.:TEvaluator{tc ra9}'), (raf, Data constructor `main:Eval.:DContextProceed{d raf}'), (rag, Type constructor `main:Eval.:TContextProceed{tc rag}'), (raj, Type constructor `main:Eval.:Co:TEvaluator{tc raj}'), (rak, Identifier `main:Eval.:DEvaluator{v rak}'), (rao, Type constructor `main:Eval.:Co:TContextProceed{tc rao}'), (rap, Identifier `main:Eval.:DContextProceed{v rap}')] -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 8 19:29:30 2008 From: trac at galois.com (GHC) Date: Fri Feb 8 19:28:21 2008 Subject: [GHC] #2049: GHCi doesn't fully load previously broken modules In-Reply-To: <042.e75e264362dd101a1f793da2344243d7@localhost> References: <042.e75e264362dd101a1f793da2344243d7@localhost> Message-ID: <051.cfefeaa37dcf39a269bff707f3062815@localhost> #2049: GHCi doesn't fully load previously broken modules ---------------------+------------------------------------------------------ Reporter: ajd | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.8.3 Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------+------------------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 8 19:29:57 2008 From: trac at galois.com (GHC) Date: Fri Feb 8 19:28:55 2008 Subject: [GHC] #1936: When lazy IO blocks, it blocks the whole runtime In-Reply-To: <044.f29c60445787d8d1c724ac2871ace0b4@localhost> References: <044.f29c60445787d8d1c724ac2871ace0b4@localhost> Message-ID: <053.680c64bbb8447b60e4a49f39a0842539@localhost> #1936: When lazy IO blocks, it blocks the whole runtime ------------------------------------------+--------------------------------- Reporter: guest | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.8.3 Component: None | Version: 6.8.1 Severity: normal | Resolution: fixed Keywords: lazy IO getContents blocking | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Linux | ------------------------------------------+--------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 8 21:06:33 2008 From: trac at galois.com (GHC) Date: Fri Feb 8 21:05:26 2008 Subject: [GHC] #2085: cabal uses haddock from hard-coded location Message-ID: <047.8ad2e58ccb38bc8a1047e5fee854c9fe@localhost> #2085: cabal uses haddock from hard-coded location -------------------------+-------------------------------------------------- Reporter: Frederik | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- I don't know if this is a feature or a bug. It seems that cabal doesn't search for the haddock executable in $PATH but uses a hard-coded location. Is this the best behaviour? It seems confusing to me. It makes it difficult to upgrade different pieces of the system separately. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 9 06:43:29 2008 From: trac at galois.com (GHC) Date: Sat Feb 9 06:42:19 2008 Subject: [GHC] #2085: cabal uses haddock from hard-coded location In-Reply-To: <047.8ad2e58ccb38bc8a1047e5fee854c9fe@localhost> References: <047.8ad2e58ccb38bc8a1047e5fee854c9fe@localhost> Message-ID: <056.5b00e4c69fd7aa059822fdc68afbbc36@localhost> #2085: cabal uses haddock from hard-coded location -----------------------------+---------------------------------------------- Reporter: Frederik | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown -----------------------------+---------------------------------------------- Comment (by duncan): Will need more details, symptoms, build logs or whatever. What is this hard coded location? As far as I know and from looking at the code, it uses the path to find haddock, just like it does for almost every other program. Also, it'd be helpful to know if you're talking about haddock-0.x or 2.x as they get treated somewhat differently. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 9 09:36:22 2008 From: trac at galois.com (GHC) Date: Sat Feb 9 09:35:11 2008 Subject: [GHC] #2023: Packages.lhs:mungePackagePaths doesn't handle haddock-html & haddock-interfaces In-Reply-To: <044.353c7e94c0ee9b420199f0094f141941@localhost> References: <044.353c7e94c0ee9b420199f0094f141941@localhost> Message-ID: <053.e7752b088571488d584b5cffac8abbbd@localhost> #2023: Packages.lhs:mungePackagePaths doesn't handle haddock-html & haddock- interfaces ----------------------+----------------------------------------------------- Reporter: guest | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: packages | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonmar): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 9 09:37:45 2008 From: trac at galois.com (GHC) Date: Sat Feb 9 09:36:42 2008 Subject: [GHC] #1971: unjustified warning about documentation In-Reply-To: <045.5f2dce829598b3d2d0f493e57a8d1616@localhost> References: <045.5f2dce829598b3d2d0f493e57a8d1616@localhost> Message-ID: <054.8b34f35dcae016a7aca90559e803ee9d@localhost> #1971: unjustified warning about documentation --------------------------+------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Build System | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Multiple Os: Multiple | --------------------------+------------------------------------------------- Changes (by simonmar): * difficulty: Unknown => Easy (1 hr) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 9 14:46:15 2008 From: trac at galois.com (GHC) Date: Sat Feb 9 14:45:02 2008 Subject: [GHC] #2086: Fix test openFile008(ghci) by changing testlib.py to apply cmd_prefix also for way ghci Message-ID: <050.6b6c77e639396d2575a0e929d7d41640@localhost> #2086: Fix test openFile008(ghci) by changing testlib.py to apply cmd_prefix also for way ghci ----------------------------+----------------------------------------------- Reporter: thorkilnaur | Owner: Type: bug | Status: new Priority: normal | Component: Test Suite Version: 6.9 | Severity: normal Keywords: | Testcase: openFile008 Architecture: Unknown | Os: MacOS X ----------------------------+----------------------------------------------- The test openFile008(ghci) currently fails on PPC Mac OS X 10.4 as follows: {{{ openFile008: openFile008_testdir/file247: openFile: resource exhausted (Too many open files) }}} openFile008 opens 1000 files. And since {{{ $ ulimit -n 256 $ }}} on the machine where this happens, we get the error. To be sure, in {{{testsuite/tests/ghc-regress/lib/IO/all.T}}} we find that this eventuality has been prepared for: {{{ test('openFile008', cmd_prefix('ulimit -n 1024; '), compile_and_run, ['']) }}} But the testsuite {{{driver/testlib.py}}} does not apply the cmd_prefix for way ghci. As a result, openFile008 succeeds for other ways, but not for the ghci way. The attached patch changes {{{driver/testlib.py}}} to apply the cmd_prefix also for way ghci, which is one possible solution to this problem. I have verified that other tests that use cmd_prefix have not been affected by this change. Best regards Thorkil -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 9 15:11:20 2008 From: trac at galois.com (GHC) Date: Sat Feb 9 15:10:07 2008 Subject: [GHC] #2084: GHC panic In-Reply-To: <047.2af7ef94b11d6e7558fa16d6fcecb781@localhost> References: <047.2af7ef94b11d6e7558fa16d6fcecb781@localhost> Message-ID: <056.39b2857096174143cb88e85a894d1d45@localhost> #2084: GHC panic -------------------------+-------------------------------------------------- Reporter: stimberm | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Testcase: Architecture: x86 | Os: MacOS X -------------------------+-------------------------------------------------- Comment (by thorkilnaur): Thanks a lot. Please review http://hackage.haskell.org/trac/ghc/wiki/ReportABug. You may need to supply some additional information to fulfill "The absolutely key thing is that we must be able to reproduce the bug." Best regards Thorkil -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 9 17:31:15 2008 From: trac at galois.com (GHC) Date: Sat Feb 9 17:30:03 2008 Subject: [GHC] #2085: cabal uses haddock from hard-coded location In-Reply-To: <047.8ad2e58ccb38bc8a1047e5fee854c9fe@localhost> References: <047.8ad2e58ccb38bc8a1047e5fee854c9fe@localhost> Message-ID: <056.07656995505a2b883a12c45d6d4fcf1e@localhost> #2085: cabal uses haddock from hard-coded location -----------------------------+---------------------------------------------- Reporter: Frederik | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown -----------------------------+---------------------------------------------- Comment (by Frederik): I see now that Cabal is storing the executable location in "dist/setup- config" during the configure step. Still seems somewhat strange, do other build systems do that? I think of PATH as part of my configuration already, it's not like I would have PATH set up correctly when configuring a package, and then incorrectly when building the same package. On the other hand, maybe there's a good reason I am not aware of for doing it this way. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 10 11:04:42 2008 From: trac at galois.com (GHC) Date: Sun Feb 10 11:03:27 2008 Subject: [GHC] #2085: cabal uses haddock from hard-coded location In-Reply-To: <047.8ad2e58ccb38bc8a1047e5fee854c9fe@localhost> References: <047.8ad2e58ccb38bc8a1047e5fee854c9fe@localhost> Message-ID: <056.7543e4af46fed9a574af26dc12cd0196@localhost> #2085: cabal uses haddock from hard-coded location -----------------------------+---------------------------------------------- Reporter: Frederik | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 6.8.2 Severity: normal | Resolution: wontfix Keywords: | Testcase: Architecture: Unknown | Os: Unknown -----------------------------+---------------------------------------------- Changes (by duncan): * status: new => closed * resolution: => wontfix Comment: If someone specifies a non-standard location using --happy-prog= then we have to remember that in the configuration somewhere. Even if the program is on the path we have to check that it does indeed exist, so that involves finding it and often running it to check its version. Then the choice is between remembering the unqualified or fully qualified path. There does not seem to be much to choose between the two, we somewhat arbitrarily pick the qualified path. I think other systems do this too, eg you'll see many build systems running /usr/bin/gcc even though they were only looking for gcc on the path at configure time. For example autoconf saves the path info in the Makefile, generated by ./configure. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 10 14:24:39 2008 From: trac at galois.com (GHC) Date: Sun Feb 10 14:23:24 2008 Subject: [GHC] #2081: On a strained PPC Mac OS X 10.4, GHC reports internal error: stg_ap_v_ret In-Reply-To: <050.436412791af8536dabd2387bab7c6cbf@localhost> References: <050.436412791af8536dabd2387bab7c6cbf@localhost> Message-ID: <059.277d7d1a3524a898c0b82fc4ec27edf1@localhost> #2081: On a strained PPC Mac OS X 10.4, GHC reports internal error: stg_ap_v_ret -------------------------+-------------------------------------------------- Reporter: thorkilnaur | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | -------------------------+-------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch Comment: May not be OS X specific: I just got this on amd64/Linux while validating the HEAD: {{{ ====> Running ./boxy/all.T =====> Base1(normal) cd ./boxy && '/home/ian/ghc/darcs/val/compiler/stage2/ghc-inplace' -no- recomp -dcore-lint -dcmm-lint -Dx86_64_unknown_linux -c Base1.hs >Base1.comp.stderr 2>&1 /bin/sh: line 1: 19152 Aborted '/home/ian/ghc/darcs/val/compiler/stage2/ghc-inplace' -no-recomp -dcore- lint -dcmm-lint -Dx86_64_unknown_linux -c Base1.hs >Base1.comp.stderr 2>&1 Compile failed (status 34304) errors were: ghc-6.9.20080210: internal error: stg_ap_v_ret (GHC version 6.9.20080210 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for Base1(normal) }}} Running the test again a couple of times didn't reproduce the error. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 10 16:07:00 2008 From: trac at galois.com (GHC) Date: Sun Feb 10 16:05:45 2008 Subject: [GHC] #2087: On a PPC Mac OS X 10.4, the RTS reports "Memory leak detected" running a program compiled with -debug -threaded -fhpc Message-ID: <050.7b39faa855e94ccd0c6858657071f62f@localhost> #2087: On a PPC Mac OS X 10.4, the RTS reports "Memory leak detected" running a program compiled with -debug -threaded -fhpc ----------------------------+----------------------------------------------- Reporter: thorkilnaur | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: powerpc | Os: MacOS X ----------------------------+----------------------------------------------- On a PPC Mac OS X 10.4, the RTS reports "Memory leak detected" running a program compiled with -debug, -threaded, and -fhpc. Here is a sample session: {{{ $ cat T1.hs main = putStrLn "Memory leak?" $ rm T1.o $ /Users/thorkilnaur/tn/GHCDarcsRepository/ghc-HEAD-complete-for-pulling- and-copying-20070713_1212/ghc/compiler/stage2/ghc-inplace T1.hs -o T1 -debug -threaded -fhpc $ ./T1 Memory leak detected gen 0 blocks : 2 gen 1 blocks : 1 nursery : 128 retainer : 0 arena blocks : 0 exec : 0 free : 119 total : 250 in system : 254 T1: internal error: ASSERTION FAILED: file sm/Storage.c, line 1179 (GHC version 6.9.20080203 for powerpc_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug $ ./T1 Memory leak? $ }}} Running the program usually fails the first time and succeeds on the second and subsequent attempts. The GHC version used is the HEAD from around 2008-Feb-03. Similar behaviour has been observed for the test cases {{{ ffi002(threaded1) hpc001(threaded1) hpc_fork(threaded1) tough(threaded1) }}} for both the stable and head tnaur PPC OSX builders. The last three are all hpc test cases that use the same set of flags (-debug -threaded -fhpc) used in the above sample. ffi002 is different, it is an example of a C program that sets up the GHC runtime environment and calls some Haskell code. The ffi002 test case has been failing for a while (c.f. http://haskell.org/pipermail/cvs-ghc/2007-June/036013.html). The memory leak is detected by this code in {{{rts/sm/Storage.c}}}: {{{ if (live_blocks + free_blocks != mblocks_allocated * BLOCKS_PER_MBLOCK) { debugBelch("Memory leak detected\n"); for (g = 0; g < RtsFlags.GcFlags.generations; g++) { debugBelch(" gen %d blocks : %4lu\n", g, gen_blocks[g]); } debugBelch(" nursery : %4lu\n", nursery_blocks); debugBelch(" retainer : %4lu\n", retainer_blocks); debugBelch(" arena blocks : %4lu\n", arena_blocks); debugBelch(" exec : %4lu\n", exec_blocks); debugBelch(" free : %4lu\n", free_blocks); debugBelch(" total : %4lu\n\n", live_blocks + free_blocks); debugBelch(" in system : %4lu\n", mblocks_allocated * BLOCKS_PER_MBLOCK); ASSERT(0); } }}} I have tried to move the printing of counters outside the condition and got the following result: {{{ $ rm T1.o $ /Users/thorkilnaur/tn/GHCDarcsRepository/ghc-HEAD-complete-for-pulling- and-copying-20070713_1212/ghc/compiler/stage2/ghc-inplace T1.hs -o T1 -debug -threaded -fhpc $ ./T1 memInventory: gen 0 blocks : 2 gen 1 blocks : 1 nursery : 128 retainer : 0 arena blocks : 0 exec : 0 free : 119 total : 250 in system : 254 Memory leak detected T1: internal error: ASSERTION FAILED: file sm/Storage.c, line 1181 (GHC version 6.9.20080203 for powerpc_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug $ ./T1 Memory leak? memInventory: gen 0 blocks : 2 gen 1 blocks : 1 nursery : 128 retainer : 0 arena blocks : 0 exec : 0 free : 123 total : 254 in system : 254 memInventory: gen 0 blocks : 4 gen 1 blocks : 4 nursery : 128 retainer : 0 arena blocks : 0 exec : 0 free : 118 total : 254 in system : 254 $ }}} Suggestions for further lines of investigation are most welcome. Best regards Thorkil -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 10 16:52:42 2008 From: trac at galois.com (GHC) Date: Sun Feb 10 16:51:31 2008 Subject: [GHC] #1767: :show does not conform to documented specification In-Reply-To: <044.e7adae11ca7979e3093e064a998ae30d@localhost> References: <044.e7adae11ca7979e3093e064a998ae30d@localhost> Message-ID: <053.5abda43bd2a6eac36880529c7657271e@localhost> #1767: :show does not conform to documented specification ---------------------+------------------------------------------------------ Reporter: guest | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.8.3 Component: GHCi | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------+------------------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 10 16:53:29 2008 From: trac at galois.com (GHC) Date: Sun Feb 10 16:52:14 2008 Subject: [GHC] #1771: hFileSize gives negative values In-Reply-To: <044.de7a3080a07f89d093c4293ba2bb2f42@localhost> References: <044.de7a3080a07f89d093c4293ba2bb2f42@localhost> Message-ID: <053.616d9fb9df93f4ebfff6dca64a6fbcbc@localhost> #1771: hFileSize gives negative values ----------------------------+----------------------------------------------- Reporter: guest | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.8.3 Component: libraries/base | Version: 6.6.1 Severity: normal | Resolution: fixed Keywords: hFileSize >2gb | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------------+----------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 10 16:54:11 2008 From: trac at galois.com (GHC) Date: Sun Feb 10 16:52:58 2008 Subject: [GHC] #1750: ghc-pkg stack overflow when mutually dependent packages installed In-Reply-To: <046.c7f89c65ae4e20e638696f6bfcdd5355@localhost> References: <046.c7f89c65ae4e20e638696f6bfcdd5355@localhost> Message-ID: <055.f38e6e72d68788808f022e592cbbeec7@localhost> #1750: ghc-pkg stack overflow when mutually dependent packages installed ----------------------+----------------------------------------------------- Reporter: greenrd | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.7 Severity: normal | Resolution: fixed Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Multiple Os: Multiple | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: All 3 merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 11 06:02:35 2008 From: trac at galois.com (GHC) Date: Mon Feb 11 06:01:53 2008 Subject: [GHC] #2083: linker reports missing symbols Main.c:(.text+0x12): undefined reference to `__stginit_ZCMain' In-Reply-To: <054.f4411cf09d2804f4c2a24a7055f19618@localhost> References: <054.f4411cf09d2804f4c2a24a7055f19618@localhost> Message-ID: <063.518aed38daee66ed65140747ff6796cf@localhost> #2083: linker reports missing symbols Main.c:(.text+0x12): undefined reference to `__stginit_ZCMain' -----------------------------+---------------------------------------------- Reporter: Andrew U. Frank | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by simonmar): * difficulty: => Unknown * summary: linker reports missing symbols Main.c:(.text+0x12): undefined reference to `__stginit_ZCMain' Main.c:(.text+0x2c): undefined reference to `ZCMain_main_closure' => linker reports missing symbols Main.c:(.text+0x12): undefined reference to `__stginit_ZCMain' Comment: Please supply the complete module(s) you are trying to compile. Note that a Haskell program should have a module `Main` that defines a value `main`: this is a requirement of Haskell 98. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 11 06:17:40 2008 From: trac at galois.com (GHC) Date: Mon Feb 11 06:16:22 2008 Subject: [GHC] #2087: On a PPC Mac OS X 10.4, the RTS reports "Memory leak detected" running a program compiled with -debug -threaded -fhpc In-Reply-To: <050.7b39faa855e94ccd0c6858657071f62f@localhost> References: <050.7b39faa855e94ccd0c6858657071f62f@localhost> Message-ID: <059.763b097b8b0985a6cf505434e20e113b@localhost> #2087: On a PPC Mac OS X 10.4, the RTS reports "Memory leak detected" running a program compiled with -debug -threaded -fhpc ----------------------------+----------------------------------------------- Reporter: thorkilnaur | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | ----------------------------+----------------------------------------------- Changes (by simonmar): * difficulty: => Unknown Comment: Memory leaks are easy to detect, and hard to diagnose, sadly :( I would start like this: * find the smallest (shortest-running) program that displays the bug * run it with `+RTS -DSbg -Sstderr` (sanity checking and block-alloc- debugging) If you really have a memory leak and not some free-list corruption or something else, then the aim is to find who allocated the block that leaked. Since you only have a very few blocks being allocated by the program, it should be too hard to check them all - set a breakpoint on allocGroup(). Is this happening on HEAD only, or 6.8.x too? (not sure which milestone to add it to) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 11 06:43:48 2008 From: trac at galois.com (GHC) Date: Mon Feb 11 06:42:31 2008 Subject: [GHC] #2087: On a PPC Mac OS X 10.4, the RTS reports "Memory leak detected" running a program compiled with -debug -threaded -fhpc In-Reply-To: <050.7b39faa855e94ccd0c6858657071f62f@localhost> References: <050.7b39faa855e94ccd0c6858657071f62f@localhost> Message-ID: <059.15a2d680f2c92f5c753ae296dbf0e3b6@localhost> #2087: On a PPC Mac OS X 10.4, the RTS reports "Memory leak detected" running a program compiled with -debug -threaded -fhpc ----------------------------+----------------------------------------------- Reporter: thorkilnaur | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | ----------------------------+----------------------------------------------- Comment (by thorkilnaur): Thanks a lot, I'll see what I can do. The test cases mentioned fail in both the "tnaur PPC OSX head" and the "tnaur PPC OSX stable" builders, so I guess that this makes it a 6.8.x problem as well as a HEAD problem. Best regards Thorkil -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 11 07:22:40 2008 From: trac at galois.com (GHC) Date: Mon Feb 11 07:21:21 2008 Subject: [GHC] #2087: On a PPC Mac OS X 10.4, the RTS reports "Memory leak detected" running a program compiled with -debug -threaded -fhpc In-Reply-To: <050.7b39faa855e94ccd0c6858657071f62f@localhost> References: <050.7b39faa855e94ccd0c6858657071f62f@localhost> Message-ID: <059.9620a2cad6d049c88f3d285ee913b1ac@localhost> #2087: On a PPC Mac OS X 10.4, the RTS reports "Memory leak detected" running a program compiled with -debug -threaded -fhpc ----------------------------+----------------------------------------------- Reporter: thorkilnaur | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Runtime System | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | ----------------------------+----------------------------------------------- Changes (by simonmar): * milestone: => 6.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 11 13:55:53 2008 From: trac at galois.com (GHC) Date: Mon Feb 11 13:54:41 2008 Subject: [GHC] #2088: GHC messages do not reflect argument name changes Message-ID: <052.87ed87efa8aaa066021158506aae5149@localhost> #2088: GHC messages do not reflect argument name changes ------------------------------+--------------------------------------------- Reporter: sethkurtzberg | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Multiple | Os: Multiple ------------------------------+--------------------------------------------- Recent versions of ghc use -frecordPuns. ghc 6.8.2 uses -XRecordPuns. When the flag is needed, the message says "use -frecordPuns to allow"; it should say "use -XRecordPuns to allow". -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 11 17:08:22 2008 From: trac at galois.com (GHC) Date: Mon Feb 11 17:07:03 2008 Subject: [GHC] #2089: reading the package db is slow Message-ID: <045.d775bdf76041d9776497ac4f6a221252@localhost> #2089: reading the package db is slow ---------------------------------------------+------------------------------ Reporter: duncan | Owner: Type: compile-time performance bug | Status: new Priority: normal | Component: Driver Version: 6.8.2 | Severity: minor Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Multiple ---------------------------------------------+------------------------------ With a large number of registered packages it takes ages for ghc to read the package db and it does this every time it is run so it starts to add up. I have a rather fast x86-64 machine and 160 registered packages. Here are some timings: {{{ $ time ghc-pkg list > /dev/null user 0m1.164s $ time ghc -c does-not-exist.c 2> /dev/null real 0m0.612s $ time hsc2hs does-exist.hsc --cflag=--version 2> /dev/null user 0m0.572s }}} So since cabal configure involves running all of the above it starts to take a while: {{{ $ time cabal configure Configuring cabal-install-0.4.3... real 0m2.241s user 0m1.916s }}} The obvious solution is to use a binary cache of the package db containing the most commonly needed mappings like module name -> package etc. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 11 17:11:41 2008 From: trac at galois.com (GHC) Date: Mon Feb 11 17:10:26 2008 Subject: [GHC] #2038: System.Posix.Resource.setResourceLimit gives "setResourceLimit: invalid argument (Invalid argument)" In-Reply-To: <045.9f2f177f681138fbf7d90d1273238fd5@localhost> References: <045.9f2f177f681138fbf7d90d1273238fd5@localhost> Message-ID: <054.e904d115aec26f7aa5190fa896060df3@localhost> #2038: System.Posix.Resource.setResourceLimit gives "setResourceLimit: invalid argument (Invalid argument)" -----------------------------------+---------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: high | Milestone: 6.8.3 Component: libraries/unix | Version: 6.8.2 Severity: major | Resolution: Keywords: regression, ffi, unix | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | -----------------------------------+---------------------------------------- Comment (by slyfox): Code like this would look like: {{{ -- strlimit{,64} is taken from C defines foreign import ccall unsafe "#hsc2-mega-macro setrlimit" c_setrlimit :: CInt -> Ptr RLimit -> IO CInt }}} Simply grepping by /usr/include got some of funs: {{{ ./unistd.h:# define lseek lseek64 ./unistd.h:# define pread pread64 ./unistd.h:# define pwrite pwrite64 ./unistd.h:# define truncate truncate64 ./unistd.h:# define ftruncate ftruncate64 ./unistd.h:# define lockf lockf64 ./glob.h:# define glob glob64 ./glob.h:# define globfree globfree64 ./aio.h:# define aio_read aio_read64 ./aio.h:# define aio_write aio_write64 ./aio.h:# define lio_listio lio_listio64 ./aio.h:# define aio_error aio_error64 ./aio.h:# define aio_return aio_return64 ./aio.h:# define aio_cancel aio_cancel64 ./aio.h:# define aio_suspend aio_suspend64 ./aio.h:# define aio_fsync aio_fsync64 ./fcntl.h:# define open open64 ./fcntl.h:# define lockf lockf64 ./fcntl.h:# define posix_fadvise posix_fadvise64 ./fcntl.h:# define posix_fallocate posix_fallocate64 ./sys/mman.h:# define mmap mmap64 ./sys/statvfs.h:# define statvfs statvfs64 ./sys/statvfs.h:# define fstatvfs fstatvfs64 ./sys/statfs.h:# define statfs statfs64 ./sys/statfs.h:# define fstatfs fstatfs64 ./dirent.h:# define readdir readdir64 ./dirent.h:# define readdir_r readdir64_r ./dirent.h:# define scandir scandir64 ./stdlib.h:# define mkstemp mkstemp64 }}} Is there/can be implemented such functionality hsc2hs? Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 12 00:27:20 2008 From: trac at galois.com (GHC) Date: Tue Feb 12 00:26:59 2008 Subject: [GHC] #1540: GHC on Macs In-Reply-To: <044.9d673ebafce0f2d705d8619a6f619550@localhost> References: <044.9d673ebafce0f2d705d8619a6f619550@localhost> Message-ID: <053.aae16ddefddefce421a0289bfa6b750a@localhost> #1540: GHC on Macs --------------------------+------------------------------------------------- Reporter: guest | Owner: Type: task | Status: closed Priority: high | Milestone: 6.8 branch Component: Build System | Version: 6.6.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | --------------------------+------------------------------------------------- Changes (by chak): * status: new => closed * resolution: => fixed Comment: It's done. The HEAD has all the patches, and merged patches for the 6.8 branch are waiting for Ian's approval to push. I announced a trial package on the [http://www.haskell.org/pipermail/glasgow-haskell- users/2008-February/014298.html mailing list] and there is [wiki:Building/MacOSX/Installer detailed documentation] on the wiki. I will close this ticket. There may be bugs and missing features with the current implementation, but they should be filed as separate bug reports. -- Ticket URL: GHC The Glasgow Haskell Compiler From chak at cse.unsw.edu.au Tue Feb 12 00:47:53 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Tue Feb 12 00:46:41 2008 Subject: building under MacOSX 10.5 with macports In-Reply-To: <47AC840C.9030600@gmail.com> References: <47AC840C.9030600@gmail.com> Message-ID: <26A30FC9-7E6A-42B0-B1F9-DEED62D3E34B@cse.unsw.edu.au> Peter Gavin: > The problem seems to be that ranlib isn't being run from the cabal- > generated makefiles after each libHS.a under libraries/ is built. At > some point the build fails when trying to link to libHShaskell98.a, > complaining about a missing index, so I ran ranlib on the library, > and the build continued. I ended up patching cabal to add a ranlib > call from the makefiles, and the build proceeded from start to > finish, without failing. > > If anyone is interested in seeing the patch, I've sent it to the > Cabal-devel list: > > http://www.haskell.org/pipermail/cabal-devel/2008-February/002033.html > > Has anyone else using Mac OSX 10.5 had this problem? Yes, I have seen the same problem. Interestingly, it only happens during the initial build in a fresh tree. BTW, an alternative to ranlib is to pass the -s option to ar. It will then create a table of contents straight away (which is the default behaviour of GNU ar). Manuel From trac at galois.com Tue Feb 12 11:53:42 2008 From: trac at galois.com (GHC) Date: Tue Feb 12 11:52:20 2008 Subject: [GHC] #2090: Better stack management please Message-ID: <044.19941903c8cd59d31b54331a884d96c8@localhost> #2090: Better stack management please --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Component: Runtime System Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- (From Adrian Hey) The current ghc rts stack management has a number of undesirable properties, at least as far as I understand it. The current implementation is explained in this post: http://haskell.org/pipermail/glasgow-haskell-users/2007-May/012472.html But it's worse than that. What the above post doesn't explain is that if the stack temporarily "blows up" due to deep recursion, the memory claimed from the heap for that threads stack will never be released, at least according to this post: http://www.haskell.org/pipermail/haskell-cafe/2008-February/039010.html There have been a number of threads discussing this, all of which contain too much information and too many points of view to reproduce in this ticket, so here are some relevant starting points: http://haskell.org/pipermail/glasgow-haskell-users/2007-May/012467.html http://www.haskell.org/pipermail/haskell-cafe/2008-January/038790.html What I would like is summarised here: http://www.haskell.org/pipermail/haskell-cafe/2008-February/039115.html -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 13 01:14:56 2008 From: trac at galois.com (GHC) Date: Wed Feb 13 01:13:32 2008 Subject: [GHC] #2091: heap corruption in ghc-6.8.2? Message-ID: <044.3e0a988db69b0177d74a97127f5c474c@localhost> #2091: heap corruption in ghc-6.8.2? -----------------------+---------------------------------------------------- Reporter: jeffz | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: Windows -----------------------+---------------------------------------------------- ghc-6.8.2-i386-unknown-mingw32 appears to suffer from heap corruption I encountered this problem when running ghc on wine-0.9.55, I have run runghc on wine through valgrind and also used Purify on Windows XP SP2 which confirmed that something was wrong. My initial reaction was to first file this bug with the wine project but on later investigation decided it was appropriate to open the bug here. Please see http://bugs.winehq.org/show_bug.cgi?id=11547 for logs and further details. -- Ticket URL: GHC The Glasgow Haskell Compiler From simonmar at microsoft.com Wed Feb 13 04:14:46 2008 From: simonmar at microsoft.com (Simon Marlow) Date: Wed Feb 13 04:13:26 2008 Subject: [GHC] #1540: GHC on Macs In-Reply-To: <053.aae16ddefddefce421a0289bfa6b750a@localhost> References: <044.9d673ebafce0f2d705d8619a6f619550@localhost> <053.aae16ddefddefce421a0289bfa6b750a@localhost> Message-ID: <1C6E59C47F062E42820BEE74FD3388E911F69CAA4F@EA-EXMSG-C333.europe.corp.microsoft.com> > #1540: GHC on Macs > --------------------------+----------------------------------------------- > -- > Reporter: guest | Owner: > Type: task | Status: closed > Priority: high | Milestone: 6.8 branch > Component: Build System | Version: 6.6.1 > Severity: normal | Resolution: fixed > Keywords: | Difficulty: Unknown > Testcase: | Architecture: x86 > Os: MacOS X | > --------------------------+----------------------------------------------- > -- > Changes (by chak): > > * status: new => closed > * resolution: => fixed > > Comment: > > It's done. The HEAD has all the patches, and merged patches for the 6.8 > branch are waiting for Ian's approval to push. I announced a trial > package on the [http://www.haskell.org/pipermail/glasgow-haskell- > users/2008-February/014298.html mailing list] and there is > [wiki:Building/MacOSX/Installer detailed documentation] on the wiki. > > I will close this ticket. There may be bugs and missing features with the > current implementation, but they should be filed as separate bug reports. Excellent, nice work! Simon From trac at galois.com Wed Feb 13 05:41:36 2008 From: trac at galois.com (GHC) Date: Wed Feb 13 05:40:12 2008 Subject: [GHC] #2089: reading the package db is slow In-Reply-To: <045.d775bdf76041d9776497ac4f6a221252@localhost> References: <045.d775bdf76041d9776497ac4f6a221252@localhost> Message-ID: <054.35ea895fa7f0ed42989e102fa79e82e7@localhost> #2089: reading the package db is slow ------------------------------------------+--------------------------------- Reporter: duncan | Owner: Type: compile-time performance bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Driver | Version: 6.8.2 Severity: minor | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Architecture: x86_64 (amd64) Os: Multiple | ------------------------------------------+--------------------------------- Changes (by simonmar): * difficulty: => Moderate (1 day) * milestone: => 6.10 branch Comment: The scheme we discussed before is something like this: * `ghc-pkg` would automatically generate a binary cache of the package DB whenever it changed. * we want to transition to using a directory of files for the package DB, where a new package can be installed by dropping a file into it and running `ghc-pkg update` to update the binary cache. The main sticking point here is what binary library to use. In GHC we have our own binary library, but it currently isn't available for `ghc- pkg` - we'd have to extract it, which is difficult because it has dependencies on other GHC datatypes, or use a different binary library. If GHC were first modified to use `Data.Binary` for its interface files, this would be a lot easier. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 13 05:56:56 2008 From: trac at galois.com (GHC) Date: Wed Feb 13 05:55:38 2008 Subject: [GHC] #2088: GHC messages do not reflect argument name changes In-Reply-To: <052.87ed87efa8aaa066021158506aae5149@localhost> References: <052.87ed87efa8aaa066021158506aae5149@localhost> Message-ID: <061.a6935b95012e20f34a703d7ce188e927@localhost> #2088: GHC messages do not reflect argument name changes ---------------------------+------------------------------------------------ Reporter: sethkurtzberg | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Multiple Os: Multiple | ---------------------------+------------------------------------------------ Changes (by simonmar): * difficulty: => Easy (1 hr) * milestone: => 6.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 13 06:15:03 2008 From: trac at galois.com (GHC) Date: Wed Feb 13 06:13:40 2008 Subject: [GHC] #2090: Better stack management please In-Reply-To: <044.19941903c8cd59d31b54331a884d96c8@localhost> References: <044.19941903c8cd59d31b54331a884d96c8@localhost> Message-ID: <053.28378743a06c9c6d4c586f0d47cd7865@localhost> #2090: Better stack management please -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by simonmar): * difficulty: => Unknown Comment: Essentially there are three suggestions here, I'll deal with them one at a time: === use a different default for the max stack size (+RTS -K) === I'm happy to go along with whatever is the popular opinion here. Personally I never encounter a program that exceeds the current stack limit and is not in an infinite loop, but I'm prepared to believe that others do. Please let us know. === reduce the memory allocated to a stack when it shrinks === This is not hard to implement - probably a couple of hours work, and confined to just one place. It could be done possibly without even copying the stack: just split the TSO into two, copy the TSO structure into the higher bit, and leave the low bit as a !ThreadRelocated, the GC will clean it up. Don't forget for this to be really useful we also need to do #698. === use a linked list of stack chunks instead of a single contiguous stack === This is a much harder proposition - there's lots of code in the RTS that traverses stacks, and it would all have to change (and get more complicated, at that). The current decision to use contiguous stacks was made consciously in order to keep things simple. We'd need some convincing evidence that the lack of stack chunks is really hurting, to make it worthwhile doing this. My impression is that there are more important things. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 13 06:31:44 2008 From: trac at galois.com (GHC) Date: Wed Feb 13 06:30:20 2008 Subject: [GHC] #2091: heap corruption in ghc-6.8.2? In-Reply-To: <044.3e0a988db69b0177d74a97127f5c474c@localhost> References: <044.3e0a988db69b0177d74a97127f5c474c@localhost> Message-ID: <053.43b8d94a57316a4ce53d2f675875aa48@localhost> #2091: heap corruption in ghc-6.8.2? ----------------------+----------------------------------------------------- Reporter: jeffz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------+----------------------------------------------------- Changes (by simonmar): * difficulty: => Unknown Comment: Could you explain which part(s) of the logs lead you to believe the bug is in GHC? The logs are huge, and I couldn't find any clues pointing at GHC with a quick scan, but maybe I missed something. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 13 10:06:56 2008 From: trac at galois.com (GHC) Date: Wed Feb 13 10:05:34 2008 Subject: [GHC] #2086: Fix test openFile008(ghci) by changing testlib.py to apply cmd_prefix also for way ghci In-Reply-To: <050.6b6c77e639396d2575a0e929d7d41640@localhost> References: <050.6b6c77e639396d2575a0e929d7d41640@localhost> Message-ID: <059.495386dbec12f2c69f022daca5ed23c3@localhost> #2086: Fix test openFile008(ghci) by changing testlib.py to apply cmd_prefix also for way ghci -------------------------+-------------------------------------------------- Reporter: thorkilnaur | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Test Suite | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: openFile008 | Architecture: Unknown Os: MacOS X | -------------------------+-------------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: Patch applied; thanks Thorkil! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 13 15:10:29 2008 From: trac at galois.com (GHC) Date: Wed Feb 13 15:09:05 2008 Subject: [GHC] #2091: heap corruption in ghc-6.8.2? In-Reply-To: <044.3e0a988db69b0177d74a97127f5c474c@localhost> References: <044.3e0a988db69b0177d74a97127f5c474c@localhost> Message-ID: <053.1bdfc9e442d58367acd13864f15ce861@localhost> #2091: heap corruption in ghc-6.8.2? ----------------------+----------------------------------------------------- Reporter: jeffz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------+----------------------------------------------------- Comment (by jeffz): Replying to [comment:1 simonmar]: > Could you explain which part(s) of the logs lead you to believe the bug is in GHC? The logs are huge, and I couldn't find any clues pointing at GHC with a quick scan, but maybe I missed something. Line 2962 of ghc-valgrind4.txt looks suspicious, but the purify log is more precise, specifying this exactly: [E] FIM: Freeing invalid memory in LocalFree {36 occurrences} Address 0x00265650 points into a HeapAlloc'd block in unallocated region of the default heap Location of free attempt LocalFree [C:\WINDOWS\system32\KERNEL32.dll] IsValidLocale [C:\WINDOWS\system32\kernel32.dll] -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 13 15:57:17 2008 From: trac at galois.com (GHC) Date: Wed Feb 13 15:55:53 2008 Subject: [GHC] #1558: make the testsuite work with THREADS=2 In-Reply-To: <047.86273a610439c0814c0caa79ac522fd9@localhost> References: <047.86273a610439c0814c0caa79ac522fd9@localhost> Message-ID: <056.1760f62afe05a76dcce60ae25bed8efe@localhost> #1558: make the testsuite work with THREADS=2 ------------------------+--------------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Test Suite | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | ------------------------+--------------------------------------------------- Comment (by batterseapower): [http://bugs.python.org/issue1731717 Python ticket for the issue reported by Simon above] -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 13 16:50:24 2008 From: trac at galois.com (GHC) Date: Wed Feb 13 16:49:01 2008 Subject: [GHC] #2092: Quadratic amount of code generated Message-ID: <044.4dc3ac8354cd192cb2595466e974beb4@localhost> #2092: Quadratic amount of code generated -----------------------------------------+---------------------------------- Reporter: igloo | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown -----------------------------------------+---------------------------------- Originally discovered by Twan van Laarhoven, here: http://www.haskell.org/pipermail/cvs-ghc/2008-February/040981.html On the HEAD, compiling this module: {{{ {-# LANGUAGE MagicHash #-} module M1 where import GHC.Exts type FastInt = Int# data U = Mk1 { a :: (), b :: FastInt, c :: () } | Mk2 { a :: (), b :: FastInt, c :: () } instance Eq U where x == y = b x ==# b y }}} with {{{ ghc -c M1.hs -O -ddump-simpl }}} we see {{{ M1.== :: M1.U -> M1.U -> GHC.Base.Bool [GlobalId] [Arity 2 NoCafRefs Str: DmdType SS] M1.== = \ (x_a5J :: M1.U) (y_a5L :: M1.U) -> case case y_a5L of tpl_B2 { M1.Mk1 ipv_B3 ipv1_B4 ipv2_B5 -> ipv1_B4; M1.Mk2 ipv_B3 ipv1_B4 ipv2_B5 -> ipv1_B4 } of wild_B1 { __DEFAULT -> case case x_a5J of tpl_B2 { M1.Mk1 ipv_B3 ipv1_B4 ipv2_B5 -> ipv1_B4; M1.Mk2 ipv_B3 ipv1_B4 ipv2_B5 -> ipv1_B4 } of wild1_Xk { __DEFAULT -> GHC.Prim.==# wild1_Xk wild_B1 } } }}} which looks good: Extract the !FastInt from one value, then the other, then compare. However, if we have this module instead: {{{ module M2 where import GHC.Exts newtype FastInt = FastInt Int deriving Eq data U = Mk1 { a :: (), b :: {-# UNPACK #-} !FastInt, c :: () } | Mk2 { a :: (), b :: {-# UNPACK #-} !FastInt, c :: () } instance Eq U where x == y = b x == b y }}} again compiling with {{{ ghc -c M2.hs -O -ddump-simpl }}} we see {{{ M2.== :: M2.U -> M2.U -> GHC.Base.Bool [GlobalId] [Arity 2 NoCafRefs Str: DmdType SS] M2.== = \ (x_a5M :: M2.U) (y_a5O :: M2.U) -> case x_a5M of tpl_Xj { M2.Mk1 ipv_Xn rb_B6 ipv1_B5 -> case y_a5O of tpl1_Xl { M2.Mk1 ipv2_Xp rb1_Xw ipv3_XX -> GHC.Prim.==# rb_B6 rb1_Xw; M2.Mk2 ipv2_Xp rb1_Xw ipv3_XX -> GHC.Prim.==# rb_B6 rb1_Xw }; M2.Mk2 ipv_Xn rb_B6 ipv1_B5 -> case y_a5O of tpl1_Xl { M2.Mk1 ipv2_Xp rb1_Xw ipv3_XX -> GHC.Prim.==# rb_B6 rb1_Xw; M2.Mk2 ipv2_Xp rb1_Xw ipv3_XX -> GHC.Prim.==# rb_B6 rb1_Xw } } }}} where the extraction of the second !FastInt happens inside the branches of the extraction of the first !FastInt, giving a quadratic (in the number of constructors) amount of code. We would expect to get code like that in the first example. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 13 18:03:00 2008 From: trac at galois.com (GHC) Date: Wed Feb 13 18:01:36 2008 Subject: [GHC] #2093: getSymbolicLinkStatus (and possibly other functions) broken on systems with large file system support Message-ID: <049.6b21dc8703db26b4a3f8f2aed151d2af@localhost> #2093: getSymbolicLinkStatus (and possibly other functions) broken on systems with large file system support ---------------------------+------------------------------------------------ Reporter: JeremyShaw | Owner: Type: bug | Status: new Priority: normal | Component: libraries/unix Version: 6.8.2 | Severity: major Keywords: | Testcase: Architecture: x86 | Os: Linux ---------------------------+------------------------------------------------ This thread contains more details: http://www.haskell.org/pipermail/haskell-cafe/2008-February/039549.html Basically, it appears that the unix module is built without the large filesystem support enabled, so it calls the 32-bit version of lstat. But hsc2hs includes header files that enable large file system support, so the offsets are for the stat64 struct. This means many fields in FileStatus are filled with garbage. I have attached a patch which adds the AC_SYS_LARGEFILE macro to configure.ac. This is the same macro which enables large file support in ghc. There could still be a problem however. For example, if you built ghc on a system without large file support, and but the unix module on a system with large file support -- then they would be out of sync. This patch seems better than the current situation however. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 14 02:05:59 2008 From: trac at galois.com (GHC) Date: Thu Feb 14 02:04:34 2008 Subject: [GHC] #2087: On a PPC Mac OS X 10.4, the RTS reports "Memory leak detected" running a program compiled with -debug -threaded -fhpc In-Reply-To: <050.7b39faa855e94ccd0c6858657071f62f@localhost> References: <050.7b39faa855e94ccd0c6858657071f62f@localhost> Message-ID: <059.cda6a4327c47fba73d0505423c0f7dd4@localhost> #2087: On a PPC Mac OS X 10.4, the RTS reports "Memory leak detected" running a program compiled with -debug -threaded -fhpc ----------------------------+----------------------------------------------- Reporter: thorkilnaur | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Runtime System | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | ----------------------------+----------------------------------------------- Comment (by thorkilnaur): Additional investigation strongly indicates that the uncounted blocks are the ones allocated by {{{hs_add_root}}} in {{{RtsStartup.c}}}: {{{ void hs_add_root(void (*init_root)(void)) { bdescr *bd; nat init_sp; Capability *cap = &MainCapability; if (hs_init_count <= 0) { barf("hs_add_root() must be called after hs_init()"); } /* The initialisation stack grows downward, with sp pointing to the last occupied word */ init_sp = INIT_STACK_BLOCKS*BLOCK_SIZE_W; bd = allocGroup_lock(INIT_STACK_BLOCKS); init_stack = (F_ *)bd->start; init_stack[--init_sp] = (F_)stg_init_finish; if (init_root != NULL) { init_stack[--init_sp] = (F_)init_root; } cap->r.rSp = (P_)(init_stack + init_sp); StgRun((StgFunPtr)stg_init, &cap->r); freeGroup_lock(bd); startupHpc(); // This must be done after module initialisation. // ToDo: make this work in the presence of multiple hs_add_root()s. initProfiling2(); } }}} The memory leak is reported when a garbage collection happens to be initiated before the blocks are freed again. This can be confirmed by inserting a call to memInventory between the allocation and the free: Such a call reports the memory leak every time. So it is not actually a real memory leak, merely a weakness in the memory leak detector. I will gladly concoct a repair of this problem, but the possibilities are many, so I will just hesitate for a little while and see if not somebody else might come up with just the right solution. Thanks and best regards Thorkil -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 14 04:42:35 2008 From: trac at galois.com (GHC) Date: Thu Feb 14 04:41:06 2008 Subject: [GHC] #2091: heap corruption in ghc-6.8.2? In-Reply-To: <044.3e0a988db69b0177d74a97127f5c474c@localhost> References: <044.3e0a988db69b0177d74a97127f5c474c@localhost> Message-ID: <053.d9a473c148f1c6cfbd70d0a11cedfd33@localhost> #2091: heap corruption in ghc-6.8.2? ----------------------+----------------------------------------------------- Reporter: jeffz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------+----------------------------------------------------- Comment (by simonmar): The valgrind error is this: {{{ ==1418== Thread 4: ==1418== Invalid read of size 4 ==1418== at 0xE3E0D3: ??? ==1418== by 0xE22109: ??? ==1418== by 0x7BC6AAD1: call_thread_func (thread.c:398) ==1418== by 0x7BC6AD91: start_thread (thread.c:472) ==1418== by 0x491A31A: start_thread (in /lib32/libpthread-2.5.so) ==1418== by 0x4A0179D: clone (in /lib32/libc-2.5.so) ==1418== Address 0xb52299c is not stack'd, malloc'd or (recently) free'd }}} there are a few others similar to this. The ??? probably indicates that the error occurred somewhere within GHC and the symbols aren't available. This may well be a real problem, although I can't repeat it with valgrind on Linux. It doesn't look like Purify is reporting the same thing - the purify error is an invalid free, which doesn't appear in the Valgrind log, AFAICS. Also it is in `IsValidLocale`, which is something we don't call anywhere in GHC. However, we do call `MultiByteToWideChar`, which conceivably might call `IsValidLocale` inside Wine. I can't see anything wrong with the way we call `MultiByteToWideChar` though - all the alloc/dealloc is supposed to be done by the caller. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 14 04:56:40 2008 From: trac at galois.com (GHC) Date: Thu Feb 14 04:55:12 2008 Subject: [GHC] #2087: On a PPC Mac OS X 10.4, the RTS reports "Memory leak detected" running a program compiled with -debug -threaded -fhpc In-Reply-To: <050.7b39faa855e94ccd0c6858657071f62f@localhost> References: <050.7b39faa855e94ccd0c6858657071f62f@localhost> Message-ID: <059.884cde712ab6ef2ba0e05beb1d4b7cd8@localhost> #2087: On a PPC Mac OS X 10.4, the RTS reports "Memory leak detected" running a program compiled with -debug -threaded -fhpc ----------------------------+----------------------------------------------- Reporter: thorkilnaur | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Runtime System | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | ----------------------------+----------------------------------------------- Comment (by simonmar): I don't understand how GC can occur during `hs_add_root` - that's certainly unexpected. It's obvious that memInventory doesn't take into account the blocks allocated by `hs_add_root`, the reason being that I didn't expect it to be called while these blocks were outstanding. Can you verify that the GC is really called during `hs_add_root`? If so, turn on `+RTS -Dsgb` (at least) and attach the log. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 14 05:48:21 2008 From: trac at galois.com (GHC) Date: Thu Feb 14 05:46:55 2008 Subject: [GHC] #2094: add two new forms of unsafePerformIO and one of unsafeInterleaveIO Message-ID: <045.d54cba53b418aad06e5ee73624b4d792@localhost> #2094: add two new forms of unsafePerformIO and one of unsafeInterleaveIO -------------------------+-------------------------------------------------- Reporter: duncan | Owner: Type: proposal | Status: new Priority: normal | Component: libraries/base Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- This proposal is to add two new variations on unsafePerformIO and one new form of unsafeInterleaveIO to the System.IO.Unsafe module in the base library (which already exports unsafePerformIO and unsafeInterleaveIO). The additions are documented and portable to non-ghc. Summary and documentation below, see attached patch for code details. Suggested timescale: ~2 weeks, ends Friday 29th February = Summary = * `unsafeDupablePerformIO` and `unsafeDupableInterleaveIO` When GHC added SMP support the previous `unsafePerform/InterleaveIO` got renamed to these two functions and new `unsafePerform/InterleaveIO` functions were added that provide protection against duplication in a multi-threaded context. This protection comes at some cost so there are cases where it is ok to uses these weaker forms if duplicating the IO action is safe. These are already defined and documented in `GHC.IOBase`, this patch just exports them. * `unsafeInlinePerformIO` This is an even less safe form of `unsafePerformIO`. It is used in the `Data.ByteString` implementation and is very occasionally needed in other projects. If it is needed it is better that it be supplied in a portable form from a standard module with a sensible name and with full documentation. = Haddock Documentation = This version of 'unsafePerformIO' is slightly more efficient, because it omits the check that the IO is only being performed by a single thread. Hence, when you write 'unsafeDupablePerformIO', there is a possibility that the IO action may be performed multiple times (on a multiprocessor), and you should therefore ensure that it gives the same results each time. {{{unsafeDupablePerformIO :: IO a -> a}}} TODO: Actually, unsafeDupableInterleaveIO is not yet documented, that will have to be fixed. {{{unsafeDupableInterleaveIO :: IO a -> IO a}}} This variant of 'unsafePerformIO' is quite /mind-bogglingly unsafe/. It unstitches the dependency chain that holds the IO monad together and breaks all your ordinary intuitions about IO, sequencing and side effects. Avoid it unless you really know what you are doing. It is only safe for operations which are genuinely pure (not just externally pure) for example reading from an immutable foreign data structure. In particular, you should do no memory allocation inside an 'unsafeInlinePerformIO' block. This is because an allocation is a constant and is likely to be floated out and shared. More generally, any part of any IO action that does not depend on a function argument is likely to be floated to the top level and have its result shared. It is more efficient because in addition to the checks that 'unsafeDupablePerformIO' omits, we also inline. Additionally we do not pretend that the body is lazy which allows the strictness analyser to see the strictness in the body. In turn this allows some re-ordering of operations and any corresponding side-effects. With GHC it compiles to essentially no code and it exposes the body to further inlining. {{{unsafeInlinePerformIO :: IO a -> a}}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 14 05:52:06 2008 From: trac at galois.com (GHC) Date: Thu Feb 14 05:50:38 2008 Subject: [GHC] #2095: add new forms of unsafePerformIO and unsafeInterleaveIO Message-ID: <045.5095ff0368131dd388cc57b0746afe94@localhost> #2095: add new forms of unsafePerformIO and unsafeInterleaveIO -------------------------+-------------------------------------------------- Reporter: duncan | Owner: Type: proposal | Status: new Priority: normal | Component: libraries/base Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- This proposal is to add two new variations on unsafePerformIO and one new form of unsafeInterleaveIO to the System.IO.Unsafe module in the base library (which already exports unsafePerformIO and unsafeInterleaveIO). The additions are documented and portable to non-ghc. Summary and documentation below, see attached patch for code details. Suggested timescale: ~2 weeks, ends Friday 29th February = Summary = * `unsafeDupablePerformIO` and `unsafeDupableInterleaveIO` When GHC added SMP support the previous `unsafePerform/InterleaveIO` got renamed to these two functions and new `unsafePerform/InterleaveIO` functions were added that provide protection against duplication in a multi-threaded context. This protection comes at some cost so there are cases where it is ok to uses these weaker forms if duplicating the IO action is safe. These are already defined and documented in `GHC.IOBase`, this patch just exports them. * `unsafeInlinePerformIO` This is an even less safe form of `unsafePerformIO`. It is used in the `Data.ByteString` implementation and is very occasionally needed in other projects. If it is needed it is better that it be supplied in a portable form from a standard module with a sensible name and with full documentation. = Haddock Documentation = This version of 'unsafePerformIO' is slightly more efficient, because it omits the check that the IO is only being performed by a single thread. Hence, when you write 'unsafeDupablePerformIO', there is a possibility that the IO action may be performed multiple times (on a multiprocessor), and you should therefore ensure that it gives the same results each time. {{{unsafeDupablePerformIO :: IO a -> a}}} TODO: Actually, unsafeDupableInterleaveIO is not yet documented, that will have to be fixed. {{{unsafeDupableInterleaveIO :: IO a -> IO a}}} This variant of 'unsafePerformIO' is quite /mind-bogglingly unsafe/. It unstitches the dependency chain that holds the IO monad together and breaks all your ordinary intuitions about IO, sequencing and side effects. Avoid it unless you really know what you are doing. It is only safe for operations which are genuinely pure (not just externally pure) for example reading from an immutable foreign data structure. In particular, you should do no memory allocation inside an 'unsafeInlinePerformIO' block. This is because an allocation is a constant and is likely to be floated out and shared. More generally, any part of any IO action that does not depend on a function argument is likely to be floated to the top level and have its result shared. It is more efficient because in addition to the checks that 'unsafeDupablePerformIO' omits, we also inline. Additionally we do not pretend that the body is lazy which allows the strictness analyser to see the strictness in the body. In turn this allows some re-ordering of operations and any corresponding side-effects. With GHC it compiles to essentially no code and it exposes the body to further inlining. {{{unsafeInlinePerformIO :: IO a -> a}}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 14 05:56:40 2008 From: trac at galois.com (GHC) Date: Thu Feb 14 05:55:13 2008 Subject: [GHC] #2094: add two new forms of unsafePerformIO and one of unsafeInterleaveIO In-Reply-To: <045.d54cba53b418aad06e5ee73624b4d792@localhost> References: <045.d54cba53b418aad06e5ee73624b4d792@localhost> Message-ID: <054.059b6fa09129aae6a48ab499d67fbf75@localhost> #2094: add two new forms of unsafePerformIO and one of unsafeInterleaveIO -------------------------------+-------------------------------------------- Reporter: duncan | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: duplicate Keywords: | Testcase: Architecture: Unknown | Os: Unknown -------------------------------+-------------------------------------------- Changes (by duncan): * status: new => closed * resolution: => duplicate Comment: Oops, duplicate. Don't use the back button kids! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 14 06:26:40 2008 From: trac at galois.com (GHC) Date: Thu Feb 14 06:25:13 2008 Subject: [GHC] #2087: On a PPC Mac OS X 10.4, the RTS reports "Memory leak detected" running a program compiled with -debug -threaded -fhpc In-Reply-To: <050.7b39faa855e94ccd0c6858657071f62f@localhost> References: <050.7b39faa855e94ccd0c6858657071f62f@localhost> Message-ID: <059.cb1b1c0902188ed74dfc6a01db1e7cfd@localhost> #2087: On a PPC Mac OS X 10.4, the RTS reports "Memory leak detected" running a program compiled with -debug -threaded -fhpc ----------------------------+----------------------------------------------- Reporter: thorkilnaur | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Runtime System | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | ----------------------------+----------------------------------------------- Comment (by thorkilnaur): The RTS, changed as indicated in the attached patch, has produced the slightly extended log which is also attached. The log covers a run that reports the memory leak, followed by a run that succeeds. A diff -C 1 of the two runs contains {{{ *************** *** 409,411 **** allocGroup(1102,4) -> 0x1500f40 (block split) ! 280a600: starting GC memInventory: --- 410,416 ---- allocGroup(1102,4) -> 0x1500f40 (block split) ! freeGroup(0x1500f40,4) ! free block list: ! group at 0x1503000, length 123 blocks ! Memory leak? ! a000ed88: starting GC memInventory: *************** }}} which confirms that the garbage collector is called between the alloc and free in {{{hs_add_root}}}. Best regards Thorkil -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 14 07:27:19 2008 From: trac at galois.com (GHC) Date: Thu Feb 14 07:26:07 2008 Subject: [GHC] #2087: On a PPC Mac OS X 10.4, the RTS reports "Memory leak detected" running a program compiled with -debug -threaded -fhpc In-Reply-To: <050.7b39faa855e94ccd0c6858657071f62f@localhost> References: <050.7b39faa855e94ccd0c6858657071f62f@localhost> Message-ID: <059.93ae8b8b5704426d8794cebe51053bf0@localhost> #2087: On a PPC Mac OS X 10.4, the RTS reports "Memory leak detected" running a program compiled with -debug -threaded -fhpc ----------------------------+----------------------------------------------- Reporter: thorkilnaur | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Runtime System | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | ----------------------------+----------------------------------------------- Comment (by simonmar): I think I see what is happening - but just to confirm, could you add `-Ds` to the run, and post the log again? (lower case "s", not upper case). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 14 07:55:39 2008 From: trac at galois.com (GHC) Date: Thu Feb 14 07:54:11 2008 Subject: [GHC] #2087: On a PPC Mac OS X 10.4, the RTS reports "Memory leak detected" running a program compiled with -debug -threaded -fhpc In-Reply-To: <050.7b39faa855e94ccd0c6858657071f62f@localhost> References: <050.7b39faa855e94ccd0c6858657071f62f@localhost> Message-ID: <059.fa95e4106c4615facb69444e67ebd58d@localhost> #2087: On a PPC Mac OS X 10.4, the RTS reports "Memory leak detected" running a program compiled with -debug -threaded -fhpc ----------------------------+----------------------------------------------- Reporter: thorkilnaur | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Runtime System | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | ----------------------------+----------------------------------------------- Comment (by thorkilnaur): Sorry, I was asleep there. New log attached. Best regards Thorkil -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 14 11:17:16 2008 From: trac at galois.com (GHC) Date: Thu Feb 14 11:16:06 2008 Subject: [GHC] #1555: Reverse do notation: lexer bug? In-Reply-To: <043.df5d63d77a33666dd0f364cfb5c1775b@localhost> References: <043.df5d63d77a33666dd0f364cfb5c1775b@localhost> Message-ID: <052.47197faebe179f0706b4831603464904@localhost> #1555: Reverse do notation: lexer bug? -------------------------------+-------------------------------------------- Reporter: dons | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Parser) | Version: 6.6.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Changes (by dherman): * cc: dherman@ccs.neu.edu (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 14 11:14:28 2008 From: trac at galois.com (GHC) Date: Thu Feb 14 11:16:22 2008 Subject: [GHC] #1555: Reverse do notation: lexer bug? In-Reply-To: <043.df5d63d77a33666dd0f364cfb5c1775b@localhost> References: <043.df5d63d77a33666dd0f364cfb5c1775b@localhost> Message-ID: <052.bd5c93877d9d4e7c5d874269817ba6ce@localhost> #1555: Reverse do notation: lexer bug? -------------------------------+-------------------------------------------- Reporter: dons | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Parser) | Version: 6.6.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Comment (by dherman): Would it be possible to revisit this decision? It's really a nice notation for interpreters ({{{rho |- expr -> value}}}) and type checkers that annotate their results ({{{Gamma |- expr ::: type -> expr'}}}). Don suggested an opt-in compiler flag or pragma. That would be fine with me. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 14 11:39:58 2008 From: trac at galois.com (GHC) Date: Thu Feb 14 11:38:36 2008 Subject: [GHC] #1555: Reverse do notation: lexer bug? In-Reply-To: <043.df5d63d77a33666dd0f364cfb5c1775b@localhost> References: <043.df5d63d77a33666dd0f364cfb5c1775b@localhost> Message-ID: <052.f55fa15dc40daedda8b010b06a26c654@localhost> #1555: Reverse do notation: lexer bug? -------------------------------+-------------------------------------------- Reporter: dons | Owner: Type: feature request | Status: reopened Priority: normal | Milestone: Component: Compiler (Parser) | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Changes (by simonmar): * status: closed => reopened * type: bug => feature request * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 14 11:50:15 2008 From: trac at galois.com (GHC) Date: Thu Feb 14 11:48:52 2008 Subject: [GHC] #1958: collect2: ld terminated with signal 10 [Bus error]: Building parsec on a PPC Mac OS X 10.5 Leopard as part of GHC 6.9 In-Reply-To: <050.c31695132cb1b93380c95a8b6c208782@localhost> References: <050.c31695132cb1b93380c95a8b6c208782@localhost> Message-ID: <059.32e21b75ca14c1e3e8667e7b9f67adf4@localhost> #1958: collect2: ld terminated with signal 10 [Bus error]: Building parsec on a PPC Mac OS X 10.5 Leopard as part of GHC 6.9 -------------------------+-------------------------------------------------- Reporter: thorkilnaur | Owner: thorkilnaur Type: bug | Status: new Priority: high | Milestone: 6.8.3 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | -------------------------+-------------------------------------------------- Comment (by gmh33): Is there a chance that the OS X update 10.5.2 would fix this? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 14 13:00:56 2008 From: trac at galois.com (GHC) Date: Thu Feb 14 12:59:46 2008 Subject: [GHC] #1555: Reverse do notation: lexer bug? In-Reply-To: <043.df5d63d77a33666dd0f364cfb5c1775b@localhost> References: <043.df5d63d77a33666dd0f364cfb5c1775b@localhost> Message-ID: <052.7179d34ec9497e2681db0e9ebcc88427@localhost> #1555: Reverse do notation: lexer bug? -------------------------------+-------------------------------------------- Reporter: dons | Owner: Type: feature request | Status: reopened Priority: normal | Milestone: Component: Compiler (Parser) | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Comment (by igloo): Note that similar syntax is now used by the view patterns extension, which might add confusion. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 14 13:45:39 2008 From: trac at galois.com (GHC) Date: Thu Feb 14 13:44:13 2008 Subject: [GHC] #2096: FFI file operations broken on 32-bit systems (inc many functions in unix package) Message-ID: <042.0ef58da6708c3114d6253cbce8693285@localhost> #2096: FFI file operations broken on 32-bit systems (inc many functions in unix package) -----------------------+---------------------------------------------------- Reporter: agl | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: major Keywords: | Testcase: Architecture: x86 | Os: Linux -----------------------+---------------------------------------------------- hsc2hs has a C preprocessor prelude (utils/hsc2hs/template-hsc.h) which includes some GHC header files. As a result, hsc processes files in 64-bit offset mode: {{{ % cpp -I../../includes -dM template-hsc.h | grep FILE_OFFSET_BITS #define _FILE_OFFSET_BITS 64 }}} However, when building HsUnix.c (or any c file with cabal), the environment is different and it's built in 32-bit offset mode. This leads to the case where structures which are different between 32 and 64 bit offset mode (like struct stat) are broken. The offsets in the Haskell code from hsc2hs are for the 64-bit structure, but the libc calls are made to fill in the 32-bit one. hsc2hs can be changed to compile in 32-bit offset mode by removing the includes from the beginning of the template header file. (All the GHC builds fine this way). However, this leads to a mismatch in the sizes of types between GHC and the code. So, although the offsets are now correct and the correct libc functions are called - extracting, say, an ino_t reads 64, not 32, bits. Also, mismatching GHC and the code on something as fundamental as this seems to be a recipe for trouble in the future. Thus, GHC should probably add -D_FILE_OFFSET_BITS=64 when building .c files. I believe that will fix everything. == Test case == {{{ import System.Posix.Files main = do System.Posix.Files.getFileStatus "/" >>= print . System.Posix.Files.fileID }}} Should print a garbage number. However, this depends on the contents of memory. Try both in ghci and with ghc --make -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 14 14:28:16 2008 From: trac at galois.com (GHC) Date: Thu Feb 14 14:26:50 2008 Subject: [GHC] #2096: FFI file operations broken on 32-bit systems (inc many functions in unix package) In-Reply-To: <042.0ef58da6708c3114d6253cbce8693285@localhost> References: <042.0ef58da6708c3114d6253cbce8693285@localhost> Message-ID: <051.4f9fb7be2ee1dde9bc34b5d38fb198f9@localhost> #2096: FFI file operations broken on 32-bit systems (inc many functions in unix package) -------------------------+-------------------------------------------------- Reporter: agl | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: major | Resolution: duplicate Keywords: | Testcase: Architecture: x86 | Os: Linux -------------------------+-------------------------------------------------- Changes (by JeremyShaw): * status: new => closed * resolution: => duplicate Comment: http://hackage.haskell.org/trac/ghc/ticket/2093 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 14 14:29:12 2008 From: trac at galois.com (GHC) Date: Thu Feb 14 14:27:47 2008 Subject: [GHC] #2093: getSymbolicLinkStatus (and possibly other functions) broken on systems with large file system support In-Reply-To: <049.6b21dc8703db26b4a3f8f2aed151d2af@localhost> References: <049.6b21dc8703db26b4a3f8f2aed151d2af@localhost> Message-ID: <058.1885017c3b7b2668def3905c70a01276@localhost> #2093: getSymbolicLinkStatus (and possibly other functions) broken on systems with large file system support -------------------------------+-------------------------------------------- Reporter: JeremyShaw | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/unix | Version: 6.8.2 Severity: major | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Linux -------------------------------+-------------------------------------------- Comment (by JeremyShaw): see also: http://hackage.haskell.org/trac/ghc/ticket/2096 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 14 15:56:15 2008 From: trac at galois.com (GHC) Date: Thu Feb 14 15:54:48 2008 Subject: [GHC] #2097: bug in regEnumKeys (System.Win32.Registry) Message-ID: <053.154a24ca3b071941575751aaf8747feb@localhost> #2097: bug in regEnumKeys (System.Win32.Registry) -------------------------------+-------------------------------------------- Reporter: MagnusTherning | Owner: Type: bug | Status: new Priority: normal | Component: libraries (other) Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Windows -------------------------------+-------------------------------------------- The following code throws a segmentation fault: module Main where import System.Win32.Registry listRegistry p = do putStrLn $ "HKLM\\" ++ p hkey <- regOpenKey hKEY_LOCAL_MACHINE p sub_paths <- regEnumKeys hkey let full_subs = map ((p ++ "\\") ++) sub_paths mapM_ listRegistry full_subs main = do mapM_ listRegistry ["SOFTWARE\\JavaSoft"] -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 14 16:06:21 2008 From: trac at galois.com (GHC) Date: Thu Feb 14 16:04:52 2008 Subject: [GHC] #2097: bug in regEnumKeys (System.Win32.Registry) In-Reply-To: <053.154a24ca3b071941575751aaf8747feb@localhost> References: <053.154a24ca3b071941575751aaf8747feb@localhost> Message-ID: <062.7ef49be6a153a386b884bb0729c803b6@localhost> #2097: bug in regEnumKeys (System.Win32.Registry) ----------------------------------+----------------------------------------- Reporter: MagnusTherning | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Windows ----------------------------------+----------------------------------------- Comment (by MagnusTherning): Hmm, I didn't really intend the code to look like that. I've stuck it in hpaste: http://hpaste.org/5666 Hopefully it'll survive there long enough. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 14 17:32:11 2008 From: trac at galois.com (GHC) Date: Thu Feb 14 17:30:51 2008 Subject: [GHC] #1958: collect2: ld terminated with signal 10 [Bus error]: Building parsec on a PPC Mac OS X 10.5 Leopard as part of GHC 6.9 In-Reply-To: <050.c31695132cb1b93380c95a8b6c208782@localhost> References: <050.c31695132cb1b93380c95a8b6c208782@localhost> Message-ID: <059.da8c3fc79705965f07db8f1a2e95906b@localhost> #1958: collect2: ld terminated with signal 10 [Bus error]: Building parsec on a PPC Mac OS X 10.5 Leopard as part of GHC 6.9 -------------------------+-------------------------------------------------- Reporter: thorkilnaur | Owner: thorkilnaur Type: bug | Status: new Priority: high | Milestone: 6.8.3 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | -------------------------+-------------------------------------------------- Comment (by thorkilnaur): Thanks for making me aware of the Mac OS X 10.5.2 update. I have updated the "tnaur PPC OSX ... 2" builder accordingly, so if that removes the problem, we should be able to detect it soon. (For the HEAD, we have to await the resolution of http://www.haskell.org/pipermail/cvs- ghc/2008-February/041135.html that currently makes the stage 2 build fail, rather than the problem of the present ticket.) Best regards Thorkil -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 14 23:01:46 2008 From: trac at galois.com (GHC) Date: Thu Feb 14 23:00:23 2008 Subject: [GHC] #1992: 6.8.2 intermittent build failure on multiple OS X versions In-Reply-To: <044.6e3d43e6297883ec96aae365685c0c7d@localhost> References: <044.6e3d43e6297883ec96aae365685c0c7d@localhost> Message-ID: <053.af73e2304910bba8af6cb39790da4784@localhost> #1992: 6.8.2 intermittent build failure on multiple OS X versions ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: MacOS X | ----------------------+----------------------------------------------------- Comment (by gw): Some progress: There are two distinct bugs here. The problem with apparently failed ranlibs (or ld not determining if an archive has a table of contents) has been fixed by Apple's 10.5.2 update. I guess this is what the release note item "improved stability for third party applications" meant. This bug was only seen on Leopard. This leaves only the locking bug. A Macports build of 6.8.2 still fails because .depend-BASE appears to be locked (perhaps a race that allows the file descriptor to be reused by ghc before the file is unlocked): {{{ ../utils/ghc-pkg/ghc-pkg-inplace update - --force-files > make[2]: *** [depend] Error 1 make[1]: *** [stage2] Error 2 make: *** [bootstrap2] Error 2 Warning: the following items did not execute (for ghc): org.macports.destroot org.macports.build Error: Status 1 encountered during processing. }}} As I noted before, the locking bug showed up on Tiger, so it is very likely a ghc problem. I am still puzzled by the fact that this bug doesn't seem to happen when I run make under bash in a terminal window. Building under Macports tickles the bug, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 15 01:00:42 2008 From: trac at galois.com (GHC) Date: Fri Feb 15 00:59:12 2008 Subject: [GHC] #2098: validate fails for PPC Mac OS X 10.4 Message-ID: <050.004f36944f07736217953750484b380a@localhost> #2098: validate fails for PPC Mac OS X 10.4 ----------------------------+----------------------------------------------- Reporter: thorkilnaur | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: powerpc | Os: MacOS X ----------------------------+----------------------------------------------- Lately (http://www.haskell.org/pipermail/cvs- ghc/2008-February/041135.html) validate has been failing for PPC Mac OS X 10.4 as follows: {{{ ../compiler/stage1/ghc-inplace -no-user-package-conf -Werror -H64m -Onot -fasm -istage2/utils -istage2/basicTypes -istage2/types -istage2/hsSyn -istage2/prelude -istage2/rename -istage2/typecheck -istage2/deSugar -istage2/coreSyn -istage2/vectorise -istage2/specialise -istage2/simplCore -istage2/stranal -istage2/stgSyn -istage2/simplStg -istage2/codeGen -istage2/main -istage2/profiling -istage2/parser -istage2/cprAnalysis -istage2/ndpFlatten -istage2/iface -istage2/cmm -istage2/nativeGen -istage2/ghci -Wall -fno-warn-name-shadowing -fno- warn-orphans -Istage2 -package hpc -package bytestring -DGHCI -package template-haskell -DGHCI_TABLES_NEXT_TO_CODE -package readline -DUSE_READLINE -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -Iparser -package unix -package Cabal -ignore-package lang -recomp -Rghc-timing -Onot -fasm -H16M '-#include "cutils.h"' -package-name ghc-6.9.20080208 -fgenerics -c ghci/ByteCodeFFI.lhs -o stage2/ghci/ByteCodeFFI.o -ohi stage2/ghci/ByteCodeFFI.hi ghci/ByteCodeFFI.lhs:690:18: Couldn't match expected type `PrimRep' against inferred type `CgRep' In the pattern: FloatArg In a case alternative: FloatArg | nextFPR < 14 -> (3223257088 .|. (fromIntegral haskellArgOffset .&. 65535) .|. (fromIntegral nextFPR `shiftL` 21)) : pass_parameters args (nextFPR + 1) offsetW' In the expression: let haskellArgOffset = a_offW * bytes_per_word offsetW' = offsetW + primRepSizeW a_rep pass_word w | offsetW + w < 8 = [...] | otherwise = [...] where src = ... .... in case a_rep of FloatArg | nextFPR < 14 -> (3223257088 .|. (fromIntegral haskellArgOffset .&. 65535) .|. (fromIntegral nextFPR `shiftL` 21)) : pass_parameters args (nextFPR + 1) offsetW' DoubleArg | nextFPR < 14 -> (3357474816 .|. (fromIntegral haskellArgOffset .&. 65535) .|. (fromIntegral nextFPR `shiftL` 21)) : pass_parameters args (nextFPR + 1) offsetW' _ -> concatMap pass_word ([0 .. primRepSizeW a_rep - 1]) ++ pass_parameters args nextFPR offsetW' ghci/ByteCodeFFI.lhs:705:12: Couldn't match expected type `PrimRep' against inferred type `CgRep' In the pattern: VoidArg In a case alternative: VoidArg -> [] In the expression: case r_rep of VoidArg -> [] FloatArg -> [3493789696 .|. (fromIntegral result_off .&. 65535)] DoubleArg -> [3628007424 .|. (fromIntegral result_off .&. 65535)] _ | primRepSizeW r_rep == 2 -> [2424242176 .|. (fromIntegral result_off .&. 65535), 2426339328 .|. (fromIntegral (result_off + 4) .&. 65535)] _ | primRepSizeW r_rep == 1 -> [2424242176 .|. (fromIntegral result_off .&. 65535)] <> make[2]: *** [stage2/ghci/ByteCodeFFI.o] Error 1 make[2]: *** Waiting for unfinished jobs.... <> make[1]: *** [stage2] Error 2 make: *** [bootstrap2] Error 2 }}} Best regards Thorkil -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 15 07:29:42 2008 From: trac at galois.com (GHC) Date: Fri Feb 15 07:28:58 2008 Subject: [GHC] #1544: Derived Read instances for recursive datatypes with infix constructors are too inefficient In-Reply-To: <059.876fe881e6bc9b43ab179d4b6da29ec1@localhost> References: <059.876fe881e6bc9b43ab179d4b6da29ec1@localhost> Message-ID: <068.d9f3a56b6d77716b5e480def6504342f@localhost> #1544: Derived Read instances for recursive datatypes with infix constructors are too inefficient ----------------------------------+----------------------------------------- Reporter: jcpetruzza@gmail.com | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------------+----------------------------------------- Changes (by eelco): * cc: emlempsi@cs.uu.nl (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 15 08:19:45 2008 From: trac at galois.com (GHC) Date: Fri Feb 15 08:18:28 2008 Subject: [GHC] #2099: Storable instance for Complex Message-ID: <047.c8eaa83814b0476331366f6ca4bff701@localhost> #2099: Storable instance for Complex -------------------------+-------------------------------------------------- Reporter: jedbrown | Owner: Type: proposal | Status: new Priority: normal | Component: libraries/base Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Multiple | Os: Multiple -------------------------+-------------------------------------------------- I propose that the following instance be added to base: {{{ instance (RealFloat a, Storable a) => Storable (Complex a) where sizeOf z = 2 * sizeOf (realPart z) alignment z = sizeOf (realPart z) peek p = do [r,i] <- peekArray 2 (castPtr p) return (r :+ i) poke p (r :+ i) = pokeArray (castPtr p) [r,i] }}} This instance is binary compatible with C99, C++ and Fortran complex types. It is currently needed by at least two independent packages: hmatrix and fft. Since it is natural for user code to use both of these packages, we need to move the instance to a common location. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 15 11:14:57 2008 From: trac at galois.com (GHC) Date: Fri Feb 15 11:13:27 2008 Subject: [GHC] #974: Add unzipEithers, lefts, rights to Data.Either In-Reply-To: <044.771c90fc72736a1914b3f63a62b98bc6@localhost> References: <044.771c90fc72736a1914b3f63a62b98bc6@localhost> Message-ID: <053.f13cfae6211403b6aa15bdfbcc4750aa@localhost> #974: Add unzipEithers, lefts, rights to Data.Either ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: proposal | Status: reopened Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by r6): * status: closed => reopened * resolution: wontfix => Comment: A request for this function has appeared again. Please review the old thread at . The only stumbling block is the name. I prefer partitionEithers at this point, but (like everyone) any of the possible names works just as well. This patch includes what #1695 covers and more. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 15 11:33:55 2008 From: trac at galois.com (GHC) Date: Fri Feb 15 11:32:28 2008 Subject: [GHC] #2100: [PATCH] generated FFI ccall stub prototypes are incomplete Message-ID: <042.903eb13e232c19cfd1c4fc81f12d1f06@localhost> #2100: [PATCH] generated FFI ccall stub prototypes are incomplete -------------------------+-------------------------------------------------- Reporter: pcc | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (FFI) Version: 6.9 | Severity: minor Keywords: | Testcase: Architecture: Multiple | Os: Multiple -------------------------+-------------------------------------------------- For generated C prototypes in which there are no arguments, the argument list should be "void", not blank. The GCC flag -Wstrict-prototypes warns about this. To reproduce: create file Test.hs as follows {{{ {-# OPTIONS -fffi #-} module Test where foreign export ccall "foo" foo :: IO () foo = putStrLn "hello world" }}} and file use_test.c as follows: {{{ #include "Test_stub.h" }}} Execute the following: {{{ ghc -c Test.hs gcc -Wstrict-prototypes -I/usr/lib/ghc-6.6/include -c use_test.c }}} (change path as appropriate). Expected output: nothing. Actual output: {{{ In file included from use_test.c:1: Test_stub.h:5: warning: function declaration isn?t a prototype }}} Patch attached. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 15 15:16:46 2008 From: trac at galois.com (GHC) Date: Fri Feb 15 15:15:18 2008 Subject: [GHC] #1695: library submission: Data.Either.unzipEithers :: [Either a b] -> ([a], [b]) In-Reply-To: <049.c778a978557afb433de2d63de7126c66@localhost> References: <049.c778a978557afb433de2d63de7126c66@localhost> Message-ID: <058.82234568bfef414bf83a8c7e88027829@localhost> #1695: library submission: Data.Either.unzipEithers :: [Either a b] -> ([a],[b]) ----------------------------+----------------------------------------------- Reporter: JeremyShaw | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.8 Severity: minor | Resolution: duplicate Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by igloo): * status: reopened => closed * resolution: => duplicate Comment: This ticket is a duplicate of the only part of #974 that isn't decided, so this ticket is no easier to resolve than all of #974. Thus I'm closing it as a duplicate. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 15 15:18:52 2008 From: trac at galois.com (GHC) Date: Fri Feb 15 15:17:22 2008 Subject: [GHC] #974: Add unzipEithers, lefts, rights to Data.Either In-Reply-To: <044.771c90fc72736a1914b3f63a62b98bc6@localhost> References: <044.771c90fc72736a1914b3f63a62b98bc6@localhost> Message-ID: <053.59bba6fc96d56b1d4eb049045eb70a87@localhost> #974: Add unzipEithers, lefts, rights to Data.Either ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: proposal | Status: reopened Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Comment (by igloo): Sorry Russell, I must have forgotten about the thread by the time I closed the bug. Having reread the thread, I think we are here: We are agreed that we should add {{{ lefts :: [Either a b] -> [a] rights :: [Either a b] -> [b] }}} and that we should add a function with type {{{ [Either a b] -> ([a],[b]) }}} Possible names include {{{ splitEithers unzipEithers partitionEithers catEithers leftRights leftsAndRights boths demuxEithers }}} While choosing a name, we should bear in mind that we might want to define a function with type {{{ (a -> Either b c) -> [a] -> ([b],[c]) }}} at some point in the future. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 15 16:23:33 2008 From: trac at galois.com (GHC) Date: Fri Feb 15 16:22:02 2008 Subject: [GHC] #2038: System.Posix.Resource.setResourceLimit gives "setResourceLimit: invalid argument (Invalid argument)" In-Reply-To: <045.9f2f177f681138fbf7d90d1273238fd5@localhost> References: <045.9f2f177f681138fbf7d90d1273238fd5@localhost> Message-ID: <054.57ca63b5d11263e18a5028466e6ffc66@localhost> #2038: System.Posix.Resource.setResourceLimit gives "setResourceLimit: invalid argument (Invalid argument)" -----------------------------------+---------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: high | Milestone: 6.8.3 Component: libraries/unix | Version: 6.8.2 Severity: major | Resolution: Keywords: regression, ffi, unix | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | -----------------------------------+---------------------------------------- Comment (by igloo): See also #2093 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 15 16:23:44 2008 From: trac at galois.com (GHC) Date: Fri Feb 15 16:22:13 2008 Subject: [GHC] #2093: getSymbolicLinkStatus (and possibly other functions) broken on systems with large file system support In-Reply-To: <049.6b21dc8703db26b4a3f8f2aed151d2af@localhost> References: <049.6b21dc8703db26b4a3f8f2aed151d2af@localhost> Message-ID: <058.771f7256afbad59e7b0be3776f2ba3e9@localhost> #2093: getSymbolicLinkStatus (and possibly other functions) broken on systems with large file system support ----------------------------+----------------------------------------------- Reporter: JeremyShaw | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/unix | Version: 6.8.2 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------------+----------------------------------------------- Changes (by igloo): * difficulty: => Unknown Comment: And also #2038 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 15 16:26:41 2008 From: trac at galois.com (GHC) Date: Fri Feb 15 16:25:08 2008 Subject: [GHC] #2097: bug in regEnumKeys (System.Win32.Registry) In-Reply-To: <053.154a24ca3b071941575751aaf8747feb@localhost> References: <053.154a24ca3b071941575751aaf8747feb@localhost> Message-ID: <062.2a4c8610d46b5fc8d5ed58a9f9a1f65d@localhost> #2097: bug in regEnumKeys (System.Win32.Registry) -------------------------------+-------------------------------------------- Reporter: MagnusTherning | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Windows | -------------------------------+-------------------------------------------- Changes (by igloo): * difficulty: => Unknown Old description: > The following code throws a segmentation fault: > > module Main where > > import System.Win32.Registry > > listRegistry p = do > putStrLn $ "HKLM\\" ++ p > hkey <- regOpenKey hKEY_LOCAL_MACHINE p > sub_paths <- regEnumKeys hkey > let full_subs = map ((p ++ "\\") ++) sub_paths > mapM_ listRegistry full_subs > > main = do > mapM_ listRegistry ["SOFTWARE\\JavaSoft"] New description: The following code throws a segmentation fault: {{{ module Main where import System.Win32.Registry listRegistry p = do putStrLn $ "HKLM\\" ++ p hkey <- regOpenKey hKEY_LOCAL_MACHINE p sub_paths <- regEnumKeys hkey let full_subs = map ((p ++ "\\") ++) sub_paths mapM_ listRegistry full_subs main = do mapM_ listRegistry ["SOFTWARE\\JavaSoft"] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 15 17:18:37 2008 From: trac at galois.com (GHC) Date: Fri Feb 15 17:17:07 2008 Subject: [GHC] #1389: readline checks in configure.ac can probably be removed In-Reply-To: <047.d6f3a7067b92adffac648351296fa875@localhost> References: <047.d6f3a7067b92adffac648351296fa875@localhost> Message-ID: <056.ecf2417284624aac76c6bd55c8b24e75@localhost> #1389: readline checks in configure.ac can probably be removed --------------------------+------------------------------------------------- Reporter: simonmar | Owner: igloo Type: task | Status: new Priority: normal | Milestone: 6.10 branch Component: Build System | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | --------------------------+------------------------------------------------- Changes (by igloo): * owner: => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 15 18:04:45 2008 From: trac at galois.com (GHC) Date: Fri Feb 15 18:03:13 2008 Subject: [GHC] #2101: Allow some form of type-level lemma Message-ID: <044.c52cb421307f316d7eaaefb9c7a88407@localhost> #2101: Allow some form of type-level lemma --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- See http://www.haskell.org/pipermail/haskell/2008-February/020230.html -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 15 18:27:24 2008 From: trac at galois.com (GHC) Date: Fri Feb 15 18:25:54 2008 Subject: [GHC] #2097: bug in regEnumKeys (System.Win32.Registry) In-Reply-To: <053.154a24ca3b071941575751aaf8747feb@localhost> References: <053.154a24ca3b071941575751aaf8747feb@localhost> Message-ID: <062.9a5dfb41905f3ec38954059ec0fb8814@localhost> #2097: bug in regEnumKeys (System.Win32.Registry) -------------------------------+-------------------------------------------- Reporter: MagnusTherning | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: libraries (other) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Windows | -------------------------------+-------------------------------------------- Changes (by igloo): * milestone: => 6.8.3 Comment: I can reproduce this, but it doesn't always segfault for me. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 15 19:08:17 2008 From: trac at galois.com (GHC) Date: Fri Feb 15 19:06:47 2008 Subject: [GHC] #2102: Typeclass membership doesn't bring coercion superclass requirements into scope Message-ID: <044.023554459a3970ac357a8591131972fb@localhost> #2102: Typeclass membership doesn't bring coercion superclass requirements into scope ------------------------+--------------------------------------------------- Reporter: ryani | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- {{{ -- This works: class C1 a where c1 :: a -> Int class C1 a => C2 a where c2 :: a -> Int test :: C2 a => a -> Int test a = c1 a + c2 a -- This doesn't work: class (a ~ b) => E a b cast :: E a b => a -> b cast a = a {- error: tyfam.hs:36:9: Couldn't match expected type `b' against inferred type `a' `b' is a rigid type variable bound by the type signature for `cast' at tyfam.hs:35:14 `a' is a rigid type variable bound by the type signature for `cast' at tyfam.hs:35:12 In the expression: a In the definition of `cast': cast a = a -} }}} I would expect that the requirement of membership in {{{E a b}}} would bring {{{(a ~ b)}}} into scope and allow {{{cast}}} to typecheck. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 15 19:17:11 2008 From: trac at galois.com (GHC) Date: Fri Feb 15 19:15:38 2008 Subject: [GHC] #2101: Allow some form of type-level lemma In-Reply-To: <044.c52cb421307f316d7eaaefb9c7a88407@localhost> References: <044.c52cb421307f316d7eaaefb9c7a88407@localhost> Message-ID: <053.af188d1f89cc27b4c63e08bdeadd0ad1@localhost> #2101: Allow some form of type-level lemma --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- Comment (by Isaac Dupree): can `cat_nil` already be optimized away by `ghc -O`? Or might it return `_|_`? (is it possible for its recursion not to terminate?) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 15 20:03:04 2008 From: trac at galois.com (GHC) Date: Fri Feb 15 20:01:32 2008 Subject: [GHC] #2044: "Can't unify" error in debugger In-Reply-To: <044.9de84d1571c81bf2b4030ee1192776b2@localhost> References: <044.9de84d1571c81bf2b4030ee1192776b2@localhost> Message-ID: <053.89eecbd0c961bcf14ff2820112d8e497@localhost> #2044: "Can't unify" error in debugger --------------------+------------------------------------------------------- Reporter: r6144 | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | --------------------+------------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.8.3 Comment: Thanks for the report; I can reproduce the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 15 20:05:03 2008 From: trac at galois.com (GHC) Date: Fri Feb 15 20:03:30 2008 Subject: [GHC] #2045: Link error when compiling with -fhpc In-Reply-To: <044.3e291c48a73368cfaa2c03d4b6685800@localhost> References: <044.3e291c48a73368cfaa2c03d4b6685800@localhost> Message-ID: <053.9a100d1155e82dc24f26127b5af0aef3@localhost> #2045: Link error when compiling with -fhpc ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.8.3 Comment: Thanks for the report. I don't know how easy this will be to fix, but let's put it in the 6.8.3 milestone for now. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 15 20:05:53 2008 From: trac at galois.com (GHC) Date: Fri Feb 15 20:04:22 2008 Subject: [GHC] #2050: GHCi should keep a persistent history file In-Reply-To: <042.e949aba920f4285accf4bf1e428e3654@localhost> References: <042.e949aba920f4285accf4bf1e428e3654@localhost> Message-ID: <051.c50d5fdf209fc4f8fdeeaffca5da2c38@localhost> #2050: GHCi should keep a persistent history file -----------------------------+---------------------------------------------- Reporter: ajd | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 15 20:07:07 2008 From: trac at galois.com (GHC) Date: Fri Feb 15 20:05:38 2008 Subject: [GHC] #2058: Ghci tab-completion cannot handle Unicode In-Reply-To: <047.a8886855c87afec46dd99ad6a799741e@localhost> References: <047.a8886855c87afec46dd99ad6a799741e@localhost> Message-ID: <056.febf19a99d7169ab5fe0c8931209352d@localhost> #2058: Ghci tab-completion cannot handle Unicode ----------------------+----------------------------------------------------- Reporter: desegnis | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Linux | ----------------------+----------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch Comment: Thanks for the report! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 15 20:09:37 2008 From: trac at galois.com (GHC) Date: Fri Feb 15 20:08:09 2008 Subject: [GHC] #2059: Erroneous results in trigonometric functions for > double-precision values In-Reply-To: <056.3e619538850693ad9b65e875780ac3cb@localhost> References: <056.3e619538850693ad9b65e875780ac3cb@localhost> Message-ID: <065.59e37a1e36c00e7aa359f45f8e28d020@localhost> #2059: Erroneous results in trigonometric functions for > double-precision values -------------------------------+-------------------------------------------- Reporter: daniel.is.fischer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | -------------------------------+-------------------------------------------- Changes (by igloo): * difficulty: => Unknown Old description: > For large inputs, sin, cos and tan return the input value: > {{{GHCi, version 6.8.1: http://www.haskell.org/ghc/ :? for help > Loading package base ... linking ... done. > Prelude> sin 1e20 > 1.0e20 > Prelude> cos 1e20 > 1.0e20 > Prelude> cos 1e19 > 1.0e19 > Prelude> cos 1e18 > 0.11965025504785125 > Prelude> tan 1e19 > 1.0e19}}} New description: For large inputs, sin, cos and tan return the input value: {{{ GHCi, version 6.8.1: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude> sin 1e20 1.0e20 Prelude> cos 1e20 1.0e20 Prelude> cos 1e19 1.0e19 Prelude> cos 1e18 0.11965025504785125 Prelude> tan 1e19 1.0e19 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 15 20:13:00 2008 From: trac at galois.com (GHC) Date: Fri Feb 15 20:11:27 2008 Subject: [GHC] #2059: Erroneous results in trigonometric functions for > double-precision values In-Reply-To: <056.3e619538850693ad9b65e875780ac3cb@localhost> References: <056.3e619538850693ad9b65e875780ac3cb@localhost> Message-ID: <065.c193554058e3586be1f809df225098eb@localhost> #2059: Erroneous results in trigonometric functions for > double-precision values -------------------------------+-------------------------------------------- Reporter: daniel.is.fischer | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | -------------------------------+-------------------------------------------- Changes (by igloo): * milestone: => 6.8.3 Comment: I can reproduce this on x86/Linux, but not amd64/Linux. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 15 20:20:08 2008 From: trac at galois.com (GHC) Date: Fri Feb 15 20:18:36 2008 Subject: [GHC] #2064: problems with duplicate modules In-Reply-To: <047.fdf7f2c34537ee71076b19d77bccf5a5@localhost> References: <047.fdf7f2c34537ee71076b19d77bccf5a5@localhost> Message-ID: <056.c0e574bb00391ea5e88484cd939af162@localhost> #2064: problems with duplicate modules ----------------------+----------------------------------------------------- Reporter: Frederik | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.8 branch Comment: I'm not sure when, if at all, GHC should check for things like this, especially if we allow a `package.conf.d` directory, so calling ghc-pkg isn't needed to register packages. I think the options are (in order of increasing paranoia): * Assume Cabal has done the checking for us, and don't do it ourselves * Check in ghc-pkg when (if) the package is registered * Check in GHC itself when we read the `package.conf` -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 15 20:26:51 2008 From: trac at galois.com (GHC) Date: Fri Feb 15 20:25:32 2008 Subject: [GHC] #2065: QuickCheck: coarbitrary for Double and Float is broken. In-Reply-To: <047.46288937485983cd4ba90be55ea2293b@localhost> References: <047.46288937485983cd4ba90be55ea2293b@localhost> Message-ID: <056.c137990fe3a56c70e4e85fc32c04a4ab@localhost> #2065: QuickCheck: coarbitrary for Double and Float is broken. -------------------------------+-------------------------------------------- Reporter: jedbrown | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries (other) | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: Thanks for the report. However, if this works in !QuickCheck 2 then I think we should consider this bug closed. If it is important to you that it works in QC1, then I think your best bet is to submit a patch through the [http://www.haskell.org/haskellwiki/Library_submissions library submissions] process. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 15 20:32:49 2008 From: trac at galois.com (GHC) Date: Fri Feb 15 20:31:17 2008 Subject: [GHC] #2068: need better exception names for fgl In-Reply-To: <047.e3f6170318938c8777e7bf908f91dee1@localhost> References: <047.e3f6170318938c8777e7bf908f91dee1@localhost> Message-ID: <056.c422562a2be20d697eea0849dd57f27c@localhost> #2068: need better exception names for fgl -------------------------------+-------------------------------------------- Reporter: Frederik | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: libraries (other) | Version: 6.8.2 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: fgl is, according to its cabal file, maintained by Martin Erwig; contact details are on its homepage, here: http://web.engr.oregonstate.edu/~erwig/fgl/haskell Bug reports and feature requests should be sent to Martin. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 15 20:33:14 2008 From: trac at galois.com (GHC) Date: Fri Feb 15 20:31:44 2008 Subject: [GHC] #2069: GHC crashes when both -shared and --make flags are specified In-Reply-To: <049.a76d3ffa368ec969b89faebab8692341@localhost> References: <049.a76d3ffa368ec969b89faebab8692341@localhost> Message-ID: <058.bdb87d3485d826d1bb8f253773534d9f@localhost> #2069: GHC crashes when both -shared and --make flags are specified ------------------------+--------------------------------------------------- Reporter: bchallenor | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ------------------------+--------------------------------------------------- Changes (by igloo): * difficulty: => Unknown Old description: > I'm not even sure if you're meant to be able to do this, but I wanted to > build a DLL without manually specifying the files, so I tried to do the > build and the archiving in one step. > > But I get a panic: > > >ghc -shared --make LibFunslang > ghc: panic! (the 'impossible' happened) > (GHC version 6.8.1 for i386-unknown-mingw32): > main/DriverPipeline.hs:(270,0)-(337,23): Non-exhaustive patterns > in func > tion link New description: I'm not even sure if you're meant to be able to do this, but I wanted to build a DLL without manually specifying the files, so I tried to do the build and the archiving in one step. But I get a panic: {{{ >ghc -shared --make LibFunslang ghc: panic! (the 'impossible' happened) (GHC version 6.8.1 for i386-unknown-mingw32): main/DriverPipeline.hs:(270,0)-(337,23): Non-exhaustive patterns in function link }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 15 20:35:53 2008 From: trac at galois.com (GHC) Date: Fri Feb 15 20:34:23 2008 Subject: [GHC] #2069: GHC crashes when both -shared and --make flags are specified In-Reply-To: <049.a76d3ffa368ec969b89faebab8692341@localhost> References: <049.a76d3ffa368ec969b89faebab8692341@localhost> Message-ID: <058.a226ca68dbb5e5a851921a50765e106d@localhost> #2069: GHC crashes when both -shared and --make flags are specified ------------------------+--------------------------------------------------- Reporter: bchallenor | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ------------------------+--------------------------------------------------- Changes (by igloo): * milestone: => 6.8.3 Comment: Thanks for the report. You certainly shouldn't get a "Non-exhaustive patterns" failure! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 15 20:36:11 2008 From: trac at galois.com (GHC) Date: Fri Feb 15 20:34:39 2008 Subject: [GHC] #2101: Allow some form of type-level lemma In-Reply-To: <044.c52cb421307f316d7eaaefb9c7a88407@localhost> References: <044.c52cb421307f316d7eaaefb9c7a88407@localhost> Message-ID: <053.106e2565076966a103d63ebe965839c1@localhost> #2101: Allow some form of type-level lemma --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- Comment (by ryani): Replying to [comment:1 Isaac Dupree]: > can `cat_nil` already be optimized away by `ghc -O`? Or might it return `_|_`? (is it possible for its recursion not to terminate?) I am pretty sure that cat_nil cannot be optimized away. Consider the following additions to the program: {{{ type instance Cat [a] () = [(a,a)] unsoundCoerce :: Exp (Cat [a] ()) -> Exp [a] unsoundCoerce = coerce undefined }}} If cat_nil is optimized away then unsoundCoerce exp does an invalid conversion from Exp [(a,a)] to Exp [a]. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 15 20:37:45 2008 From: trac at galois.com (GHC) Date: Fri Feb 15 20:36:22 2008 Subject: [GHC] #2071: hp2ps does not handle SCCs with spaces in the identifiers In-Reply-To: <043.db084f3257628fb450a2954b1e1b4fcc@localhost> References: <043.db084f3257628fb450a2954b1e1b4fcc@localhost> Message-ID: <052.3b6e2b3cef60f81c9cb95b8eb776af85@localhost> #2071: hp2ps does not handle SCCs with spaces in the identifiers -----------------------+---------------------------------------------------- Reporter: benl | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Profiling | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -----------------------+---------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.8.3 Comment: Rejecting SCCs containing spaces sounds like the simplest way to fix this. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 15 20:41:58 2008 From: trac at galois.com (GHC) Date: Fri Feb 15 20:40:28 2008 Subject: [GHC] #2075: hpc should render information about the run in its html markup In-Reply-To: <043.efa0d0e9e80dc67976454293fca2d82f@localhost> References: <043.efa0d0e9e80dc67976454293fca2d82f@localhost> Message-ID: <052.346a1079443cf5f4a9b44ec255b01cb8@localhost> #2075: hpc should render information about the run in its html markup -----------------------------+---------------------------------------------- Reporter: dons | Owner: andy@galois.com Type: feature request | Status: new Priority: normal | Milestone: 6.8 branch Component: Code Coverage | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Multiple | -----------------------------+---------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.8 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 15 20:49:14 2008 From: trac at galois.com (GHC) Date: Fri Feb 15 20:47:42 2008 Subject: [GHC] #2074: build of ghc-6.8.2 with extras failed In-Reply-To: <041.b1ea0f1c2d41a058090fb96d5ed514ac@localhost> References: <041.b1ea0f1c2d41a058090fb96d5ed514ac@localhost> Message-ID: <050.1d1d22baa0b42c326c0144196145d7f7@localhost> #2074: build of ghc-6.8.2 with extras failed -------------------------------------+-------------------------------------- Reporter: sk | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: strange closure type 15 | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | -------------------------------------+-------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Thanks for the report. However, the error is coming from GHC 6.6, so I'm closing this ticket. If you can reproduce it with 6.8.2, please open another bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 15 21:47:44 2008 From: trac at galois.com (GHC) Date: Fri Feb 15 21:46:12 2008 Subject: [GHC] #2102: Typeclass membership doesn't bring coercion superclass requirements into scope In-Reply-To: <044.023554459a3970ac357a8591131972fb@localhost> References: <044.023554459a3970ac357a8591131972fb@localhost> Message-ID: <053.25e0dc756d3555ef72fe42e573940aa7@localhost> #2102: Typeclass membership doesn't bring coercion superclass requirements into scope -------------------------+-------------------------------------------------- Reporter: ryani | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- Comment (by ryani): This is related to a feature request: http://hackage.haskell.org/trac/ghc/ticket/2101 Here's the motivating example: {{{ type family Cat ts0 ts type instance Cat () ts' = ts' type instance Cat (s, ts) ts' = (s, Cat ts ts') class (Cat ts () ~ ts) => Valid ts instance Valid () -- compiles OK instance Valid ts => Valid (s, ts) -- fails to compile -- need to prove Cat (s, ts) () ~ (s, Cat ts ()) -- for the superclass of class Valid. -- (1) From Valid ts: Cat ts () ~ ts -- (2) Therefore: (s, Cat ts ()) ~ (s, ts) coerce :: forall f ts. Valid ts => f (Cat ts ()) -> f ts coerce x = x }}} GHC gives the following two errors: {{{ tyfam.hs:38:0: Couldn't match expected type `ts' against inferred type `Cat ts ()' `ts' is a rigid type variable bound by the instance declaration at tyfam.hs:38:15 When checking the super-classes of an instance declaration In the instance declaration for `Valid (s, ts)' tyfam.hs:46:11: Couldn't match expected type `ts' against inferred type `Cat ts ()' `ts' is a rigid type variable bound by the type signature for `coerce' at tyfam.hs:45:19 Expected type: f ts Inferred type: f (Cat ts ()) In the expression: x In the definition of `coerce': coerce x = x }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 16 07:42:37 2008 From: trac at galois.com (GHC) Date: Sat Feb 16 07:41:04 2008 Subject: [GHC] #2103: Some functions do not work on NetBSD Message-ID: <044.1756b8af1f0088b08382108c842e3c22@localhost> #2103: Some functions do not work on NetBSD ------------------------+--------------------------------------------------- Reporter: iquiw | Owner: Type: bug | Status: new Priority: normal | Component: libraries/network Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: NetBSD ------------------------+--------------------------------------------------- I found two problems in network library that occurs on NetBSD.[[BR]] I created a patch to fix them. I tested it on NetBSD only. (1) listenOn does not work with numerical port number.[[BR]] This is caused by getAddrInfo used in listen' function.[[BR]] On NetBSD, we need to specify addrSocketType of addrinfo hints for getAddrInfo.[[BR]] I think this bug happens on FreeBSD also though I did not confirm it. (2) getNameInfo fails always.[[BR]] This is because of difference of sockaddr structure.[[BR]] struct sockaddr_* has its struct size as the first member of struct on *BSD system, but pokeSockAddr does not poke it.[[BR]] AFAIK, only NetBSD check this size strictly. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 16 07:49:46 2008 From: trac at galois.com (GHC) Date: Sat Feb 16 07:48:12 2008 Subject: [GHC] #2103: Some functions do not work on NetBSD In-Reply-To: <044.1756b8af1f0088b08382108c842e3c22@localhost> References: <044.1756b8af1f0088b08382108c842e3c22@localhost> Message-ID: <053.2eabc17880b7846e6518d8ab0855389e@localhost> #2103: Some functions do not work on NetBSD ----------------------------------+----------------------------------------- Reporter: iquiw | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/network | Version: 6.8.2 Severity: normal | Resolution: Keywords: network | Testcase: Architecture: Unknown | Os: NetBSD ----------------------------------+----------------------------------------- Changes (by iquiw): * keywords: => network Comment: Sample programs to causes the problems. (1) sample1.hs {{{ import Network main = listenOn (PortNumber 8000) }}} Before the attached patch is applied, {{{ $ runghc sample1.hs sample1.hs: getAddrInfo: does not exist (servname not supported for ai_socktype) }}} After, no error. (2) sample2.hs {{{ import Network main = print =<< getAddrInfo Nothing Nothing (Just "http") }}} Before the patch, {{{ $ runghc sample2.hs [AddrInfo {addrFlags = [], addrFamily = AF_INET6, addrSocketType = Datagram, addrProtocol = 17, addrAddress = [b.hs: getNameInfo: does not exist (Non-recoverable failure in name resolution) }}} After, {{{ $ runghc sample2.hs [AddrInfo {addrFlags = [], addrFamily = AF_INET6, addrSocketType = Datagram, addrProtocol = 17, addrAddress = [::1]:80, addrCanonName = Nothing},AddrInfo {addrFlags = [], addrFamily = AF_INET6, addrSocketType = Stream, addrProtocol = 6, addrAddress = [::1]:80, addrCanonName = Nothing},AddrInfo {addrFlags = [], addrFamily = AF_INET, addrSocketType = Datagram, addrProtocol = 17, addrAddress = 127.0.0.1:80, addrCanonName = Nothing},AddrInfo {addrFlags = [], addrFamily = AF_INET, addrSocketType = Stream, addrProtocol = 6, addrAddress = 127.0.0.1:80, addrCanonName = Nothing}] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 16 07:57:04 2008 From: trac at galois.com (GHC) Date: Sat Feb 16 07:55:30 2008 Subject: [GHC] #2103: Some functions in network library do not work on NetBSD In-Reply-To: <044.1756b8af1f0088b08382108c842e3c22@localhost> References: <044.1756b8af1f0088b08382108c842e3c22@localhost> Message-ID: <053.eaaaa958edb3d14a42c034dd51b18129@localhost> #2103: Some functions in network library do not work on NetBSD ----------------------------------+----------------------------------------- Reporter: iquiw | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/network | Version: 6.8.2 Severity: normal | Resolution: Keywords: network | Testcase: Architecture: Unknown | Os: NetBSD ----------------------------------+----------------------------------------- Changes (by iquiw): * summary: Some functions do not work on NetBSD => Some functions in network library do not work on NetBSD -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 16 08:19:41 2008 From: trac at galois.com (GHC) Date: Sat Feb 16 08:18:08 2008 Subject: [GHC] #2079: GHC 6.8.* doesn't recognize type variables In-Reply-To: <056.62a26a1278f77580b6bb16d54151ba36@localhost> References: <056.62a26a1278f77580b6bb16d54151ba36@localhost> Message-ID: <065.5674b2d163f409adea4929ff174898ee@localhost> #2079: GHC 6.8.* doesn't recognize type variables -------------------------------------+-------------------------------------- Reporter: daniel.is.fischer | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler (Type checker) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | -------------------------------------+-------------------------------------- Changes (by igloo): * owner: => igloo * type: bug => merge * component: Compiler => Compiler (Type checker) * milestone: => 6.8.3 Comment: Simon's done this in the HEAD; I'll merge it to the 6.8 branch. {{{ Adjust error message (Trac #2079) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 16 08:20:08 2008 From: trac at galois.com (GHC) Date: Sat Feb 16 08:18:35 2008 Subject: [GHC] #2082: In ghci, :i leaves out parens in type In-Reply-To: <052.f371aa73fee3aae45f7806e8fd54c670@localhost> References: <052.f371aa73fee3aae45f7806e8fd54c670@localhost> Message-ID: <061.299e41953fd6c0286e4a83b9e1370d34@localhost> #2082: In ghci, :i leaves out parens in type ---------------------------+------------------------------------------------ Reporter: chad.scherrer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ---------------------------+------------------------------------------------ Changes (by igloo): * difficulty: => Unknown Old description: > In ghci, :i sometimes leaves out parentheses in the type. For example, in > Data.Stream, > > Prelude Data.Stream> :i Stream > > data Stream a where > Stream :: forall a s. > (Data.Stream.Unlifted s) => > !s -> Step a s -> !s -> Stream a > -- Defined in Data.Stream > > instance Functor Stream -- Defined in Data.Stream > > Here the type > > (Data.Stream.Unlifted s) => !s -> Step a s -> !s -> Stream a > > should instead be > > (Data.Stream.Unlifted s) => (!s -> Step a s) -> !s -> Stream a New description: In ghci, :i sometimes leaves out parentheses in the type. For example, in Data.Stream, {{{ Prelude Data.Stream> :i Stream data Stream a where Stream :: forall a s. (Data.Stream.Unlifted s) => !s -> Step a s -> !s -> Stream a -- Defined in Data.Stream instance Functor Stream -- Defined in Data.Stream }}} Here the type {{{ (Data.Stream.Unlifted s) => !s -> Step a s -> !s -> Stream a }}} should instead be {{{ (Data.Stream.Unlifted s) => (!s -> Step a s) -> !s -> Stream a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 16 08:37:50 2008 From: trac at galois.com (GHC) Date: Sat Feb 16 08:36:15 2008 Subject: [GHC] #2082: In ghci, :i leaves out parens in type In-Reply-To: <052.f371aa73fee3aae45f7806e8fd54c670@localhost> References: <052.f371aa73fee3aae45f7806e8fd54c670@localhost> Message-ID: <061.134719d82c7fbf62963f96572d081254@localhost> #2082: In ghci, :i leaves out parens in type ---------------------------+------------------------------------------------ Reporter: chad.scherrer | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ---------------------------+------------------------------------------------ Changes (by igloo): * milestone: => 6.8.3 Comment: Thanks for the report. Here's a minimal example (we should put this into a test): {{{ {-# LANGUAGE ExistentialQuantification #-} data D = forall a . C (Int -> a) Char }}} {{{ $ ghci -v0 q.hs *Main> :i D data D where C :: forall a. Int -> a -> Char -> D -- Defined at q.hs:4:5 *Main> :i C data D where C :: forall a. Int -> a -> Char -> D -- Defined at q.hs:4:20 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 16 08:41:26 2008 From: trac at galois.com (GHC) Date: Sat Feb 16 08:40:08 2008 Subject: [GHC] #2083: linker reports missing symbols Main.c:(.text+0x12): undefined reference to `__stginit_ZCMain' In-Reply-To: <054.f4411cf09d2804f4c2a24a7055f19618@localhost> References: <054.f4411cf09d2804f4c2a24a7055f19618@localhost> Message-ID: <063.8f7d459e4119247f3af450d6aa26c11f@localhost> #2083: linker reports missing symbols Main.c:(.text+0x12): undefined reference to `__stginit_ZCMain' -----------------------------+---------------------------------------------- Reporter: Andrew U. Frank | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Old description: > i use 6.8.2 on linux (ubuntu 7.10). > i use mainly eclipse and ghci, but when i try to compile a program, the > linker reports > the undefined references. > for the minimal program 'hello world' i get > Main.c:(.text+0x12): undefined reference to `__stginit_ZCMain' > Main.c:(.text+0x2c): undefined reference to `ZCMain_main_closure' > for more interesting programs i get a lot more (i have experimented with > wxhaskell and phooey, tv, eros -- and some problems with compiling them > in the right order etc..) > > suprisingly the problem goes away if the program is called Main.hs - then > it links properly, but not when it is called Test.hs. the same program > with > main = putStr.... > > according to the ghc documentation, it is permitted to have in file > Test.hs the module main. > (and it works properly in ghci) New description: i use 6.8.2 on linux (ubuntu 7.10). i use mainly eclipse and ghci, but when i try to compile a program, the linker reports the undefined references. for the minimal program 'hello world' i get {{{ Main.c:(.text+0x12): undefined reference to `__stginit_ZCMain' Main.c:(.text+0x2c): undefined reference to `ZCMain_main_closure' }}} for more interesting programs i get a lot more (i have experimented with wxhaskell and phooey, tv, eros -- and some problems with compiling them in the right order etc..) suprisingly the problem goes away if the program is called Main.hs - then it links properly, but not when it is called Test.hs. the same program with {{{ main = putStr.... }}} according to the ghc documentation, it is permitted to have in file Test.hs the module main. (and it works properly in ghci) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 16 08:43:49 2008 From: trac at galois.com (GHC) Date: Sat Feb 16 08:42:26 2008 Subject: [GHC] #2083: linker reports missing symbols Main.c:(.text+0x12): undefined reference to `__stginit_ZCMain' In-Reply-To: <054.f4411cf09d2804f4c2a24a7055f19618@localhost> References: <054.f4411cf09d2804f4c2a24a7055f19618@localhost> Message-ID: <063.c8e6b6365f00add96e5ce39d99de4bab@localhost> #2083: linker reports missing symbols Main.c:(.text+0x12): undefined reference to `__stginit_ZCMain' -----------------------------+---------------------------------------------- Reporter: Andrew U. Frank | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * milestone: => 6.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 16 08:44:05 2008 From: trac at galois.com (GHC) Date: Sat Feb 16 08:42:31 2008 Subject: [GHC] #2084: GHC panic In-Reply-To: <047.2af7ef94b11d6e7558fa16d6fcecb781@localhost> References: <047.2af7ef94b11d6e7558fa16d6fcecb781@localhost> Message-ID: <056.13433536a605fa8c04fad72a3fed28e9@localhost> #2084: GHC panic ----------------------+----------------------------------------------------- Reporter: stimberm | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by igloo): * difficulty: => Unknown Old description: > GHC crashed with the following output, but I don't know what this is > about. Do you need other kind of information? > > ghc output: > > ghc-6.8.1: panic! (the 'impossible' happened) > (GHC version 6.8.1 for i386-apple-darwin): > tcIfaceGlobal (local): not found: > main:Eval.$fx2{v r4H} > [(r4J, Class `main:Eval.JustReturn{tc r4J}'), > (r4L, Type constructor `main:Eval.:Co:TJustReturn{tc r4L}'), > (r4M, Type constructor `main:Eval.:TJustReturn{tc r4M}'), > (r4N, Data constructor `main:Eval.:DJustReturn{d r4N}'), > (r4O, Identifier `main:Eval.:DJustReturn{v r4O}'), > (r4P, Identifier `main:Eval.justReturn{v r4P}'), > (r7Z, Class `main:Eval.Evaluator{tc r7Z}'), > (r80, Identifier `main:Eval.eval{v r80}'), > (r81, Class `main:Eval.ContextProceed{tc r81}'), > (r82, Identifier `main:Eval.proceed{v r82}'), > (ra8, Data constructor `main:Eval.:DEvaluator{d ra8}'), > (ra9, Type constructor `main:Eval.:TEvaluator{tc ra9}'), > (raf, Data constructor `main:Eval.:DContextProceed{d raf}'), > (rag, Type constructor `main:Eval.:TContextProceed{tc rag}'), > (raj, Type constructor `main:Eval.:Co:TEvaluator{tc raj}'), > (rak, Identifier `main:Eval.:DEvaluator{v rak}'), > (rao, Type constructor `main:Eval.:Co:TContextProceed{tc rao}'), > (rap, Identifier `main:Eval.:DContextProceed{v rap}')] New description: GHC crashed with the following output, but I don't know what this is about. Do you need other kind of information? ghc output: {{{ ghc-6.8.1: panic! (the 'impossible' happened) (GHC version 6.8.1 for i386-apple-darwin): tcIfaceGlobal (local): not found: main:Eval.$fx2{v r4H} [(r4J, Class `main:Eval.JustReturn{tc r4J}'), (r4L, Type constructor `main:Eval.:Co:TJustReturn{tc r4L}'), (r4M, Type constructor `main:Eval.:TJustReturn{tc r4M}'), (r4N, Data constructor `main:Eval.:DJustReturn{d r4N}'), (r4O, Identifier `main:Eval.:DJustReturn{v r4O}'), (r4P, Identifier `main:Eval.justReturn{v r4P}'), (r7Z, Class `main:Eval.Evaluator{tc r7Z}'), (r80, Identifier `main:Eval.eval{v r80}'), (r81, Class `main:Eval.ContextProceed{tc r81}'), (r82, Identifier `main:Eval.proceed{v r82}'), (ra8, Data constructor `main:Eval.:DEvaluator{d ra8}'), (ra9, Type constructor `main:Eval.:TEvaluator{tc ra9}'), (raf, Data constructor `main:Eval.:DContextProceed{d raf}'), (rag, Type constructor `main:Eval.:TContextProceed{tc rag}'), (raj, Type constructor `main:Eval.:Co:TEvaluator{tc raj}'), (rak, Identifier `main:Eval.:DEvaluator{v rak}'), (rao, Type constructor `main:Eval.:Co:TContextProceed{tc rao}'), (rap, Identifier `main:Eval.:DContextProceed{v rap}')] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 16 08:47:00 2008 From: trac at galois.com (GHC) Date: Sat Feb 16 08:45:25 2008 Subject: [GHC] #2084: GHC panic In-Reply-To: <047.2af7ef94b11d6e7558fa16d6fcecb781@localhost> References: <047.2af7ef94b11d6e7558fa16d6fcecb781@localhost> Message-ID: <056.5461dc5e169682a098977399bae2a7e6@localhost> #2084: GHC panic ----------------------+----------------------------------------------------- Reporter: stimberm | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by igloo): * milestone: => 6.8.3 Comment: As Thorkil said, if you could send us the code you are trying to compile (ideally cut down to a minimal testcase) then that would make it easier for us to fix the bug, and verify that what we fixed really is the bug that you are seeing. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 16 08:48:06 2008 From: trac at galois.com (GHC) Date: Sat Feb 16 08:46:31 2008 Subject: [GHC] #2090: Better stack management please In-Reply-To: <044.19941903c8cd59d31b54331a884d96c8@localhost> References: <044.19941903c8cd59d31b54331a884d96c8@localhost> Message-ID: <053.efce8355c663036f885de28e5c1f0407@localhost> #2090: Better stack management please -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * milestone: => _|_ -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 16 08:54:30 2008 From: trac at galois.com (GHC) Date: Sat Feb 16 08:52:56 2008 Subject: [GHC] #2091: heap corruption in ghc-6.8.2? In-Reply-To: <044.3e0a988db69b0177d74a97127f5c474c@localhost> References: <044.3e0a988db69b0177d74a97127f5c474c@localhost> Message-ID: <053.9dbcca8ddc4a671d9224ecb5abcf41e8@localhost> #2091: heap corruption in ghc-6.8.2? ----------------------+----------------------------------------------------- Reporter: jeffz | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------+----------------------------------------------------- Changes (by igloo): * milestone: => 6.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 16 08:54:52 2008 From: trac at galois.com (GHC) Date: Sat Feb 16 08:53:17 2008 Subject: [GHC] #2093: getSymbolicLinkStatus (and possibly other functions) broken on systems with large file system support In-Reply-To: <049.6b21dc8703db26b4a3f8f2aed151d2af@localhost> References: <049.6b21dc8703db26b4a3f8f2aed151d2af@localhost> Message-ID: <058.f0fea0f7f22e2a2af418f622fa798c4e@localhost> #2093: getSymbolicLinkStatus (and possibly other functions) broken on systems with large file system support ----------------------------+----------------------------------------------- Reporter: JeremyShaw | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: libraries/unix | Version: 6.8.2 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------------+----------------------------------------------- Changes (by igloo): * milestone: => 6.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 16 08:55:27 2008 From: trac at galois.com (GHC) Date: Sat Feb 16 08:53:52 2008 Subject: [GHC] #2095: add new forms of unsafePerformIO and unsafeInterleaveIO In-Reply-To: <045.5095ff0368131dd388cc57b0746afe94@localhost> References: <045.5095ff0368131dd388cc57b0746afe94@localhost> Message-ID: <054.028741a3db82ee655ad60e04295b91a5@localhost> #2095: add new forms of unsafePerformIO and unsafeInterleaveIO ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => Not GHC -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 16 08:56:02 2008 From: trac at galois.com (GHC) Date: Sat Feb 16 08:54:27 2008 Subject: [GHC] #2098: validate fails for PPC Mac OS X 10.4 In-Reply-To: <050.004f36944f07736217953750484b380a@localhost> References: <050.004f36944f07736217953750484b380a@localhost> Message-ID: <059.d483339146b77fc981e2c067818f6689@localhost> #2098: validate fails for PPC Mac OS X 10.4 -------------------------+-------------------------------------------------- Reporter: thorkilnaur | Owner: Type: bug | Status: new Priority: highest | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | -------------------------+-------------------------------------------------- Changes (by igloo): * priority: normal => highest * difficulty: => Unknown * milestone: => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 16 08:56:45 2008 From: trac at galois.com (GHC) Date: Sat Feb 16 08:55:27 2008 Subject: [GHC] #2099: Storable instance for Complex In-Reply-To: <047.c8eaa83814b0476331366f6ca4bff701@localhost> References: <047.c8eaa83814b0476331366f6ca4bff701@localhost> Message-ID: <056.2048707bf04841863aadc18eb38620ca@localhost> #2099: Storable instance for Complex ----------------------------+----------------------------------------------- Reporter: jedbrown | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ----------------------------+----------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => Not GHC -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 16 09:12:07 2008 From: trac at galois.com (GHC) Date: Sat Feb 16 09:10:36 2008 Subject: [GHC] #2100: [PATCH] generated FFI ccall stub prototypes are incomplete In-Reply-To: <042.903eb13e232c19cfd1c4fc81f12d1f06@localhost> References: <042.903eb13e232c19cfd1c4fc81f12d1f06@localhost> Message-ID: <051.10b1a1317db9983fac96afa4030d4756@localhost> #2100: [PATCH] generated FFI ccall stub prototypes are incomplete ----------------------------+----------------------------------------------- Reporter: pcc | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler (FFI) | Version: 6.9 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ----------------------------+----------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.8.3 Comment: Thanks for the report and patch! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 16 09:31:09 2008 From: trac at galois.com (GHC) Date: Sat Feb 16 09:29:42 2008 Subject: [GHC] #1555: Reverse do notation: lexer bug? In-Reply-To: <043.df5d63d77a33666dd0f364cfb5c1775b@localhost> References: <043.df5d63d77a33666dd0f364cfb5c1775b@localhost> Message-ID: <052.98b97d0470a372cfa5310c0910754005@localhost> #1555: Reverse do notation: lexer bug? -------------------------------+-------------------------------------------- Reporter: dons | Owner: Type: feature request | Status: reopened Priority: normal | Milestone: _|_ Component: Compiler (Parser) | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Changes (by igloo): * milestone: => _|_ -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 16 09:38:18 2008 From: trac at galois.com (GHC) Date: Sat Feb 16 09:36:47 2008 Subject: [GHC] #1908: Haskell code as a DLL triggers timeouts in the client program In-Reply-To: <043.a4c08a2bb875fc71c5db95aee93c8074@localhost> References: <043.a4c08a2bb875fc71c5db95aee93c8074@localhost> Message-ID: <052.426a33ec805e56912f5dafe64d9b804c@localhost> #1908: Haskell code as a DLL triggers timeouts in the client program ----------------------+----------------------------------------------------- Reporter: mafo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------+----------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch Comment: Hmm, we don't want to turn the timer off, because then pre-emptive multitasking wouldn't happen. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 16 09:39:43 2008 From: trac at galois.com (GHC) Date: Sat Feb 16 09:38:10 2008 Subject: [GHC] #1978: Error message: Undefined reference to `XXX_closure' In-Reply-To: <045.20d18fd66d659649248435a8e2071ba7@localhost> References: <045.20d18fd66d659649248435a8e2071ba7@localhost> Message-ID: <054.757df12c90f596dbc9a6788d95a88335@localhost> #1978: Error message: Undefined reference to `XXX_closure' ----------------------+----------------------------------------------------- Reporter: Andriy | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.6 Severity: major | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => invalid Comment: Reported against an old GHC version, and no contact from submitter, so closing bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 16 10:00:15 2008 From: trac at galois.com (GHC) Date: Sat Feb 16 09:58:42 2008 Subject: [GHC] #1984: weird performance drop with -O2 on x86 In-Reply-To: <044.701336bc21541f57619b15fdf9cfbadd@localhost> References: <044.701336bc21541f57619b15fdf9cfbadd@localhost> Message-ID: <053.551a16bfd3aa7d3dc5a91ae0ac7997a5@localhost> #1984: weird performance drop with -O2 on x86 ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------+----------------------------------------------------- Changes (by igloo): * milestone: => 6.8 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 16 10:01:01 2008 From: trac at galois.com (GHC) Date: Sat Feb 16 09:59:35 2008 Subject: [GHC] #2012: compiling via-C does not work on ppc In-Reply-To: <045.6ad3ccd84b7b179a5baec1657fb43453@localhost> References: <045.6ad3ccd84b7b179a5baec1657fb43453@localhost> Message-ID: <054.fe6f4ce4175fb6dbc39f76ed6e0c024e@localhost> #2012: compiling via-C does not work on ppc ----------------------+----------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by igloo): * milestone: => 6.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 16 12:49:18 2008 From: trac at galois.com (GHC) Date: Sat Feb 16 12:47:44 2008 Subject: [GHC] #2014: getLinkDeps panic In-Reply-To: <043.959b8170a1a6ec2b7cea0d1cfc8fd3ff@localhost> References: <043.959b8170a1a6ec2b7cea0d1cfc8fd3ff@localhost> Message-ID: <052.6bb0ccfa227cfdc4e8f99c8cc53f25f9@localhost> #2014: getLinkDeps panic ----------------------+----------------------------------------------------- Reporter: fons | Owner: Type: bug | Status: new Priority: high | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: blocker | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * priority: normal => high * milestone: => 6.8.3 Comment: Thanks for the report; I can reproduce it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 16 12:50:30 2008 From: trac at galois.com (GHC) Date: Sat Feb 16 12:48:56 2008 Subject: [GHC] #2022: DLL support broken In-Reply-To: <042.43c39ca72c9b8eecfec3978a18e72791@localhost> References: <042.43c39ca72c9b8eecfec3978a18e72791@localhost> Message-ID: <051.90744279a673ff3adb7a2b5f9118cc69@localhost> #2022: DLL support broken ----------------------+----------------------------------------------------- Reporter: mte | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------+----------------------------------------------------- Old description: > Creating a DLL using the -shared option does not work for me: > > 1. ghc tries to create a static library (foobar.dll.a). > > 2. The linker complains about missing symbols. > > Building an executable from the same project works fine and the resulting > executable runs all unit tests without errors. > > With 6.6 and the --mk-dll option, the DLL was built without problems. > > /vol/c/ghc/ghc-6.8.2/bin/ghc.exe \ > -fglasgow-exts -odir ../targets/i686-CYGWIN_NT-5.1/plain > -hidir ../targets/i686-CYGWIN_NT-5.1/plain > -i../targets/i686-CYGWIN_NT-5.1/plain +RTS -M64m -RTS \ > -shared \ > -o ../targets/i686-CYGWIN_NT-5.1/plain/foobar.dll \ > foobar.def \ > ../targets/i686-CYGWIN_NT-5.1/plain/*.o > Creating library file: ..\targets\i686-CYGWIN_NT-5.1\plain\foobar.dll.a > ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x1696):fake: > undefined reference to `containerszm0zi1zi0zi1_DataziSet_empty_closure' > ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x44c3):fake: > undefined reference to `containerszm0zi1zi0zi1_DataziSet_zdf3_closure' > ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x7e6d):fake: > undefined reference to `containerszm0zi1zi0zi1_DataziSet_elems_closure' > ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0xf392):fake: > undefined reference to `containerszm0zi1zi0zi1_DataziSet_delete_closure' > ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0xf3f6):fake: > undefined reference to `containerszm0zi1zi0zi1_DataziSet_insert_closure' > ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0xf8e3):fake: > undefined reference to `containerszm0zi1zi0zi1_DataziSet_elems_closure' > ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0xf933):fake: > undefined reference to `containerszm0zi1zi0zi1_DataziSet_sizze_closure' > ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0xffae):fake: > undefined reference to `containerszm0zi1zi0zi1_DataziSet_delete_closure' > ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x10012):fake: > undefined reference to `containerszm0zi1zi0zi1_DataziSet_insert_closure' > ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x10076):fake: > undefined reference to `containerszm0zi1zi0zi1_DataziSet_delete_closure' > ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x100c7):fake: > undefined reference to `containerszm0zi1zi0zi1_DataziSet_elems_closure' > ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x101ef):fake: > undefined reference to `containerszm0zi1zi0zi1_DataziSet_null_closure' > ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x125e7):fake: > undefined reference to > `containerszm0zi1zi0zi1_DataziSet_toAscList_closure' > ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x133e2):fake: > undefined reference to `containerszm0zi1zi0zi1_DataziSet_empty_closure' > ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x1c91f):fake: > undefined reference to `containerszm0zi1zi0zi1_DataziSet_elems_closure' > ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x1ca0f):fake: > undefined reference to `containerszm0zi1zi0zi1_DataziSet_sizze_closure' > ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x1cecb):fake: > undefined reference to `containerszm0zi1zi0zi1_DataziSet_sizze_closure' > ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x1cfb0):fake: > undefined reference to `containerszm0zi1zi0zi1_DataziSet_empty_closure' > ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x1f3ec):fake: > undefined reference to > `containerszm0zi1zi0zi1_DataziSet_singleton_closure' > ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x1fdd5):fake: > undefined reference to `__stginit_arrayzm0zi1zi0zi0_DataziArray_' > ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x1fdf3):fake: > undefined reference to `__stginit_containerszm0zi1zi0zi1_DataziSet_' > ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x1fdfd):fake: > undefined reference to `__stginit_haskell98_List_' > ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x1fe07):fake: > undefined reference to `__stginit_haskell98_Maybe_' > ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.data+0x124):fake: undefined > reference to `containerszm0zi1zi0zi1_DataziSet_empty_closure' > ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.data+0x3dc):fake: undefined > reference to `containerszm0zi1zi0zi1_DataziSet_zdf3_closure' > ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.data+0x4a8):fake: undefined > reference to `containerszm0zi1zi0zi1_DataziSet_elems_closure' > ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.data+0xdc0):fake: undefined > reference to `containerszm0zi1zi0zi1_DataziSet_delete_closure' > ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.data+0xdd8):fake: undefined > reference to `containerszm0zi1zi0zi1_DataziSet_insert_closure' > ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.data+0xe48):fake: undefined > reference to `containerszm0zi1zi0zi1_DataziSet_sizze_closure' > ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.data+0xe4c):fake: undefined > reference to `containerszm0zi1zi0zi1_DataziSet_elems_closure' > ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.data+0xf58):fake: undefined > reference to `containerszm0zi1zi0zi1_DataziSet_delete_closure' > ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.data+0xf70):fake: undefined > reference to `containerszm0zi1zi0zi1_DataziSet_insert_closure' > ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.data+0xf88):fake: undefined > reference to `containerszm0zi1zi0zi1_DataziSet_delete_closure' > ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.data+0xfc4):fake: undefined > reference to `containerszm0zi1zi0zi1_DataziSet_null_closure' > ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.data+0xfc8):fake: undefined > reference to `containerszm0zi1zi0zi1_DataziSet_elems_closure' > ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.data+0x118c):fake: > undefined reference to `containerszm0zi1zi0zi1_DataziSet_empty_closure' > ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.data+0x1190):fake: > undefined reference to > `containerszm0zi1zi0zi1_DataziSet_toAscList_closure' > ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.data+0x192c):fake: > undefined reference to `containerszm0zi1zi0zi1_DataziSet_empty_closure' > ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.data+0x1930):fake: > undefined reference to `containerszm0zi1zi0zi1_DataziSet_sizze_closure' > ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.data+0x1934):fake: > undefined reference to `containerszm0zi1zi0zi1_DataziSet_elems_closure' > ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.data+0x19f4):fake: > undefined reference to > `containerszm0zi1zi0zi1_DataziSet_singleton_closure' > ../targets/i686-CYGWIN_NT-5.1/plain/Types.o(.text+0xa5b9):fake: undefined > reference to `__stginit_arrayzm0zi1zi0zi0_DataziArray_' > collect2: ld returned 1 exit status New description: Creating a DLL using the -shared option does not work for me: 1. ghc tries to create a static library (foobar.dll.a). 2. The linker complains about missing symbols. Building an executable from the same project works fine and the resulting executable runs all unit tests without errors. With 6.6 and the --mk-dll option, the DLL was built without problems. {{{ /vol/c/ghc/ghc-6.8.2/bin/ghc.exe \ -fglasgow-exts -odir ../targets/i686-CYGWIN_NT-5.1/plain -hidir ../targets/i686-CYGWIN_NT-5.1/plain -i../targets/i686-CYGWIN_NT-5.1/plain +RTS -M64m -RTS \ -shared \ -o ../targets/i686-CYGWIN_NT-5.1/plain/foobar.dll \ foobar.def \ ../targets/i686-CYGWIN_NT-5.1/plain/*.o Creating library file: ..\targets\i686-CYGWIN_NT-5.1\plain\foobar.dll.a ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x1696):fake: undefined reference to `containerszm0zi1zi0zi1_DataziSet_empty_closure' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x44c3):fake: undefined reference to `containerszm0zi1zi0zi1_DataziSet_zdf3_closure' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x7e6d):fake: undefined reference to `containerszm0zi1zi0zi1_DataziSet_elems_closure' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0xf392):fake: undefined reference to `containerszm0zi1zi0zi1_DataziSet_delete_closure' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0xf3f6):fake: undefined reference to `containerszm0zi1zi0zi1_DataziSet_insert_closure' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0xf8e3):fake: undefined reference to `containerszm0zi1zi0zi1_DataziSet_elems_closure' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0xf933):fake: undefined reference to `containerszm0zi1zi0zi1_DataziSet_sizze_closure' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0xffae):fake: undefined reference to `containerszm0zi1zi0zi1_DataziSet_delete_closure' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x10012):fake: undefined reference to `containerszm0zi1zi0zi1_DataziSet_insert_closure' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x10076):fake: undefined reference to `containerszm0zi1zi0zi1_DataziSet_delete_closure' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x100c7):fake: undefined reference to `containerszm0zi1zi0zi1_DataziSet_elems_closure' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x101ef):fake: undefined reference to `containerszm0zi1zi0zi1_DataziSet_null_closure' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x125e7):fake: undefined reference to `containerszm0zi1zi0zi1_DataziSet_toAscList_closure' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x133e2):fake: undefined reference to `containerszm0zi1zi0zi1_DataziSet_empty_closure' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x1c91f):fake: undefined reference to `containerszm0zi1zi0zi1_DataziSet_elems_closure' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x1ca0f):fake: undefined reference to `containerszm0zi1zi0zi1_DataziSet_sizze_closure' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x1cecb):fake: undefined reference to `containerszm0zi1zi0zi1_DataziSet_sizze_closure' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x1cfb0):fake: undefined reference to `containerszm0zi1zi0zi1_DataziSet_empty_closure' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x1f3ec):fake: undefined reference to `containerszm0zi1zi0zi1_DataziSet_singleton_closure' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x1fdd5):fake: undefined reference to `__stginit_arrayzm0zi1zi0zi0_DataziArray_' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x1fdf3):fake: undefined reference to `__stginit_containerszm0zi1zi0zi1_DataziSet_' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x1fdfd):fake: undefined reference to `__stginit_haskell98_List_' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x1fe07):fake: undefined reference to `__stginit_haskell98_Maybe_' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.data+0x124):fake: undefined reference to `containerszm0zi1zi0zi1_DataziSet_empty_closure' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.data+0x3dc):fake: undefined reference to `containerszm0zi1zi0zi1_DataziSet_zdf3_closure' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.data+0x4a8):fake: undefined reference to `containerszm0zi1zi0zi1_DataziSet_elems_closure' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.data+0xdc0):fake: undefined reference to `containerszm0zi1zi0zi1_DataziSet_delete_closure' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.data+0xdd8):fake: undefined reference to `containerszm0zi1zi0zi1_DataziSet_insert_closure' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.data+0xe48):fake: undefined reference to `containerszm0zi1zi0zi1_DataziSet_sizze_closure' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.data+0xe4c):fake: undefined reference to `containerszm0zi1zi0zi1_DataziSet_elems_closure' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.data+0xf58):fake: undefined reference to `containerszm0zi1zi0zi1_DataziSet_delete_closure' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.data+0xf70):fake: undefined reference to `containerszm0zi1zi0zi1_DataziSet_insert_closure' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.data+0xf88):fake: undefined reference to `containerszm0zi1zi0zi1_DataziSet_delete_closure' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.data+0xfc4):fake: undefined reference to `containerszm0zi1zi0zi1_DataziSet_null_closure' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.data+0xfc8):fake: undefined reference to `containerszm0zi1zi0zi1_DataziSet_elems_closure' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.data+0x118c):fake: undefined reference to `containerszm0zi1zi0zi1_DataziSet_empty_closure' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.data+0x1190):fake: undefined reference to `containerszm0zi1zi0zi1_DataziSet_toAscList_closure' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.data+0x192c):fake: undefined reference to `containerszm0zi1zi0zi1_DataziSet_empty_closure' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.data+0x1930):fake: undefined reference to `containerszm0zi1zi0zi1_DataziSet_sizze_closure' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.data+0x1934):fake: undefined reference to `containerszm0zi1zi0zi1_DataziSet_elems_closure' ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.data+0x19f4):fake: undefined reference to `containerszm0zi1zi0zi1_DataziSet_singleton_closure' ../targets/i686-CYGWIN_NT-5.1/plain/Types.o(.text+0xa5b9):fake: undefined reference to `__stginit_arrayzm0zi1zi0zi0_DataziArray_' collect2: ld returned 1 exit status }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 16 12:53:40 2008 From: trac at galois.com (GHC) Date: Sat Feb 16 12:52:06 2008 Subject: [GHC] #2022: DLL support broken In-Reply-To: <042.43c39ca72c9b8eecfec3978a18e72791@localhost> References: <042.43c39ca72c9b8eecfec3978a18e72791@localhost> Message-ID: <051.b50290258fe22c89e829c9c3be0d976f@localhost> #2022: DLL support broken ----------------------+----------------------------------------------------- Reporter: mte | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------+----------------------------------------------------- Changes (by igloo): * milestone: => 6.8 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 16 12:54:12 2008 From: trac at galois.com (GHC) Date: Sat Feb 16 12:52:45 2008 Subject: [GHC] #2025: supply a testsuite archive together with a source release (for ghc-6.8.3) In-Reply-To: <045.0e8ff99e04b969df257e0d8f895be8f0@localhost> References: <045.0e8ff99e04b969df257e0d8f895be8f0@localhost> Message-ID: <054.27aaeecafaeedb12e3bd93dbd2dcffb0@localhost> #2025: supply a testsuite archive together with a source release (for ghc-6.8.3) -----------------------------+---------------------------------------------- Reporter: maeder | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.8.3 Component: Build System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Multiple Os: Multiple | -----------------------------+---------------------------------------------- Changes (by igloo): * milestone: => 6.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 16 13:13:08 2008 From: trac at galois.com (GHC) Date: Sat Feb 16 13:11:36 2008 Subject: [GHC] #2028: STM slightly conservative on write-only transactions In-Reply-To: <048.c06b21d8ef59b6cc153a10d02c678d4e@localhost> References: <048.c06b21d8ef59b6cc153a10d02c678d4e@localhost> Message-ID: <057.d273f7bc8df37113472e9760aa8ab2ae@localhost> #2028: STM slightly conservative on write-only transactions --------------------------------------+------------------------------------- Reporter: JulesBean | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.8 branch Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------------------+------------------------------------- Changes (by igloo): * type: proposal => run-time performance bug * milestone: => 6.8 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 16 13:13:55 2008 From: trac at galois.com (GHC) Date: Sat Feb 16 13:12:30 2008 Subject: [GHC] #2031: relocation overflow In-Reply-To: <045.02b5c8981d759aa3391df46bf05998bf@localhost> References: <045.02b5c8981d759aa3391df46bf05998bf@localhost> Message-ID: <054.746c043f50b31b538baacf8013006240@localhost> #2031: relocation overflow ----------------------+----------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by igloo): * milestone: => 6.8.3 Comment: Thanks for the report. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 16 13:14:18 2008 From: trac at galois.com (GHC) Date: Sat Feb 16 13:12:43 2008 Subject: [GHC] #2035: New version of getModificationTime In-Reply-To: <047.0169c6cb10468bb00ce33015893eb084@localhost> References: <047.0169c6cb10468bb00ce33015893eb084@localhost> Message-ID: <056.94e191bf3006608970e320fb6370af74@localhost> #2035: New version of getModificationTime ---------------------------------+------------------------------------------ Reporter: felixmar | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/directory | Version: Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------------------+------------------------------------------ Changes (by igloo): * milestone: => Not GHC -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 16 13:17:42 2008 From: trac at galois.com (GHC) Date: Sat Feb 16 13:16:15 2008 Subject: [GHC] #2015: SOE samples crash when running from ghci rather than compiling and running with ghc In-Reply-To: <047.485ea5c57b8e879f2c33305a489b8545@localhost> References: <047.485ea5c57b8e879f2c33305a489b8545@localhost> Message-ID: <056.4f7661df47ed3ff8127cf01a4bdf48b1@localhost> #2015: SOE samples crash when running from ghci rather than compiling and running with ghc ----------------------+----------------------------------------------------- Reporter: justinhj | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: SOE ghci | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Windows | ----------------------+----------------------------------------------------- Changes (by igloo): * milestone: => 6.8.3 Comment: Thanks for the report. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 16 13:20:25 2008 From: trac at galois.com (GHC) Date: Sat Feb 16 13:18:51 2008 Subject: [GHC] #2026: Simple data types in System.Posix.IO should have Eq, Ord, etc. instances In-Reply-To: <042.c7b8191d6013374955fde7ef230ffb1a@localhost> References: <042.c7b8191d6013374955fde7ef230ffb1a@localhost> Message-ID: <051.7d3b99c12825d31f1c87ae80a381620e@localhost> #2026: Simple data types in System.Posix.IO should have Eq, Ord, etc. instances -------------------------------+-------------------------------------------- Reporter: wjt | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries (other) | Version: 6.6.1 Severity: minor | Resolution: wontfix Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => wontfix Comment: Thanks for the report. I recommend creating a patch that adds a bunch of deriving Eq/Ord's and sending it through the [http://www.haskell.org/haskellwiki/Library_submissions library submissions] process. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 16 13:22:11 2008 From: trac at galois.com (GHC) Date: Sat Feb 16 13:20:36 2008 Subject: [GHC] #2101: Allow some form of type-level lemma In-Reply-To: <044.c52cb421307f316d7eaaefb9c7a88407@localhost> References: <044.c52cb421307f316d7eaaefb9c7a88407@localhost> Message-ID: <053.08ecb201a0b55fc02da6d0081740e789@localhost> #2101: Allow some form of type-level lemma -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => _|_ -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 16 13:27:22 2008 From: trac at galois.com (GHC) Date: Sat Feb 16 13:25:50 2008 Subject: [GHC] #2103: Some functions in network library do not work on NetBSD In-Reply-To: <044.1756b8af1f0088b08382108c842e3c22@localhost> References: <044.1756b8af1f0088b08382108c842e3c22@localhost> Message-ID: <053.591f0ccfbc701ebab63f37cc0a2c2594@localhost> #2103: Some functions in network library do not work on NetBSD -------------------------------+-------------------------------------------- Reporter: iquiw | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: libraries/network | Version: 6.8.2 Severity: normal | Resolution: Keywords: network | Difficulty: Unknown Testcase: | Architecture: Unknown Os: NetBSD | -------------------------------+-------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.8.3 Comment: Thanks for the report and patch! We'll take a look. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 17 05:53:56 2008 From: trac at galois.com (GHC) Date: Sun Feb 17 05:52:20 2008 Subject: [GHC] #2104: Add Labels Message-ID: <045.8e0dd3d5e2a0d3899747780f8d7a3947@localhost> #2104: Add Labels --------------------------------+------------------------------------------- Reporter: barney | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- This is an alternative to #1894 to support the implementation of ExtensibleRecords. This version is more complex, but both more orthogonal to the rest of the language, and supports better record features. 1. Add a new syntactic class[[BR]] label -> ( {{{'}}} (small | large | digit) {small | large | digit | {{{'}}} }),,,, A label {{{'name}}} is interpreted as a conid at the value level, and as a tycon at the type level, with an implicit declaration: {{{ data 'name = 'name }}} but with global scope, so the same label in different modules is the same value/type. 2. Add a built-in one-parameter type class {{{Label}}} with no methods, and for each label {{{'name}}} an implicit instance {{{ instance Label 'name where }}} No other instances of {{{Label}}} are allowed. 3. Add a built-in type synonym family {{{LabelCMP}}} of kind {{{* -> * -> *}}}. For every pair of labels {{{'name1}}} and {{{'name2}}}, one of the instances {{{ LabelCMP 'name1 'name2 = LabelLT LabelCMP 'name1 'name2 = LabelEQ LabelCMP 'name1 'name2 = LabelGT }}} is implicitly defined, depending on the lexicographic order of {{{'name1}}} and {{{'name2}}}. No other instances of {{{LabelCMP}}} are allowed. (The types {{{LabelLT}}}, {{{LabelEQ}}} and {{{LabelGT}}} are datatypes with no constructors, which can be declared in a library.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 17 10:56:36 2008 From: trac at galois.com (GHC) Date: Sun Feb 17 10:54:59 2008 Subject: [GHC] #1537: do notation translation In-Reply-To: <051.002894fe88bc6a156c09bce0721f2c76@localhost> References: <051.002894fe88bc6a156c09bce0721f2c76@localhost> Message-ID: <060.50c05ef8024f09d45e74b8875343ea04@localhost> #1537: do notation translation --------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: simonpj Type: merge | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.7 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: rebindable8, rebindable9 | Architecture: Unknown Os: Unknown | --------------------------------------+------------------------------------- Changes (by igloo): * status: reopened => closed * resolution: => fixed Comment: It doesn't merge cleanly to the 6.8 branch, so as the commit message only says {{{ We can probably merge to 6.8.3 if it goes smoothly. }}} (and it is a behaviour change anyway) I'm just closing the bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 17 12:26:26 2008 From: trac at galois.com (GHC) Date: Sun Feb 17 12:24:49 2008 Subject: [GHC] #998: Tab-completion of filenames does not work in GHCi 6.6 In-Reply-To: <061.a0a29a0da74b1264616768b293fe2c41@localhost> References: <061.a0a29a0da74b1264616768b293fe2c41@localhost> Message-ID: <070.7b555a9db1a53bb92d5c330827c3965a@localhost> #998: Tab-completion of filenames does not work in GHCi 6.6 ------------------------------------+--------------------------------------- Reporter: dm.maillists@gmail.com | Owner: igloo Type: merge | Status: closed Priority: low | Milestone: 6.8.3 Component: GHCi | Version: 6.6 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ------------------------------------+--------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Both merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 17 12:30:49 2008 From: trac at galois.com (GHC) Date: Sun Feb 17 12:29:13 2008 Subject: [GHC] #2080: Bug in CmmOpt In-Reply-To: <047.290f3cd941004144cf5ab81d6bdfe1f5@localhost> References: <047.290f3cd941004144cf5ab81d6bdfe1f5@localhost> Message-ID: <056.ddda3d9fc585f07ad9d1b5224af8b6e3@localhost> #2080: Bug in CmmOpt ----------------------+----------------------------------------------------- Reporter: simonmar | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Both merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 17 12:31:03 2008 From: trac at galois.com (GHC) Date: Sun Feb 17 12:29:24 2008 Subject: [GHC] #2079: GHC 6.8.* doesn't recognize type variables In-Reply-To: <056.62a26a1278f77580b6bb16d54151ba36@localhost> References: <056.62a26a1278f77580b6bb16d54151ba36@localhost> Message-ID: <065.89f43f7b36d7cd435fd18f4aef670b5b@localhost> #2079: GHC 6.8.* doesn't recognize type variables -------------------------------------+-------------------------------------- Reporter: daniel.is.fischer | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.8.3 Component: Compiler (Type checker) | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | -------------------------------------+-------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 17 13:12:22 2008 From: trac at galois.com (GHC) Date: Sun Feb 17 13:10:48 2008 Subject: [GHC] #2085: cabal uses haddock from hard-coded location In-Reply-To: <047.8ad2e58ccb38bc8a1047e5fee854c9fe@localhost> References: <047.8ad2e58ccb38bc8a1047e5fee854c9fe@localhost> Message-ID: <056.8b2d8967cd145a9c2ab3cd06a04e81d4@localhost> #2085: cabal uses haddock from hard-coded location -----------------------------+---------------------------------------------- Reporter: Frederik | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 6.8.2 Severity: normal | Resolution: wontfix Keywords: | Testcase: Architecture: Unknown | Os: Unknown -----------------------------+---------------------------------------------- Comment (by Frederik): OK, that makes sense. Sorry for the bogus bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 17 13:50:31 2008 From: trac at galois.com (GHC) Date: Sun Feb 17 13:48:54 2008 Subject: [GHC] #2105: garbage collection confusing in ghci for foreign objects Message-ID: <047.c0db5eee478c7a6109bfb2a89fd9f1d6@localhost> #2105: garbage collection confusing in ghci for foreign objects -----------------------------------------+---------------------------------- Reporter: Frederik | Owner: Type: run-time performance bug | Status: new Priority: normal | Component: GHCi Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown -----------------------------------------+---------------------------------- Hello, I am not sure if this is a bug or just a question. I have a linear algebra library which is allocating vectors etc. on the heap, I think mostly with newForeignPtr. When I use my library in ghci, and turn on debugging, it becomes clear that vectors I create are being garbage collected about one second after they are created: {{{ > let v = ... > v (prints debugging info as v is computed) (prints representation of v) > (one second later, prints a debugging message indicating that v has been freed) }}} Thus, the fact that ghci still has a symbol called 'v' is not enough to keep its data from being GC'ed, it seems. Is this a feature? If I create a string from the same data, then the string is ''not'' GC'ed: {{{ > let v = ... > let vstr = show v > vstr (prints debugging info as v is computed) (prints quoted representation of v) > (one second later, prints debug message indicating that v has been freed) > vstr (prints quoted representation of v as above, but no computation / no debugging messages, indicating that 'vstr' data was not GC'ed) }}} I can provide more background if necessary. In my library, the primary datatypes interfacing to foreign blocks are: {{{ -- Allocated blocks -- uses 'newForeignPtr finalizerFree' type RAlloc e i = (ForeignPtr CChar, ForeignPtr e) -- "Raw Sparse Vector" data RSV e i = RSV (ForeignPtr (RSV e i)) (RAlloc e i) deriving Typeable }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 17 15:08:59 2008 From: trac at galois.com (GHC) Date: Sun Feb 17 15:07:23 2008 Subject: [GHC] #2106: parts of Language.Haskell.TH.Ppr in wrong package? Message-ID: <047.c014a420f0474b6a03da8414cec14c2b@localhost> #2106: parts of Language.Haskell.TH.Ppr in wrong package? -------------------------+-------------------------------------------------- Reporter: Frederik | Owner: Type: bug | Status: new Priority: normal | Component: libraries/pretty Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- Hello, should the following functions (and possibly others) from 'template' be in the 'pretty' package instead? {{{ pprint :: Ppr a => a -> String pprint x = render $ to_HPJ_Doc $ ppr x class Ppr a where ppr :: a -> Doc ppr_list :: [a] -> Doc ppr_list = vcat . map ppr instance Ppr a => Ppr [a] where ppr x = ppr_list x }}} I guess they can't be moved exactly as they are because the Doc type is different between the packages, however, I was looking for a class of "pretty-printable" values and it is strange that the only such class seems to be Ppr in the 'template' package... -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 17 15:09:13 2008 From: trac at galois.com (GHC) Date: Sun Feb 17 15:07:36 2008 Subject: [GHC] #1839: need ghc-pkg dump feature In-Reply-To: <045.e765af751a0d91f5b4a56c8391184f46@localhost> References: <045.e765af751a0d91f5b4a56c8391184f46@localhost> Message-ID: <054.6537a6887e6f2c8b8fec1681fe9e8926@localhost> #1839: need ghc-pkg dump feature ----------------------+----------------------------------------------------- Reporter: duncan | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Both merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 17 15:20:36 2008 From: trac at galois.com (GHC) Date: Sun Feb 17 15:19:15 2008 Subject: [GHC] #670: External Core is broken In-Reply-To: <055.88b18fc8f73ea51f6e466f3eaf31b0f4@localhost> References: <055.88b18fc8f73ea51f6e466f3eaf31b0f4@localhost> Message-ID: <064.8e1b0931d34d76acc2bbb01847d2eda9@localhost> #670: External Core is broken ------------------------------+--------------------------------------------- Reporter: KirstenChevalier | Owner: tim Type: bug | Status: assigned Priority: low | Milestone: 6.10 branch Component: External Core | Version: 6.8.2 Severity: blocker | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Architecture: Multiple Os: Multiple | ------------------------------+--------------------------------------------- Changes (by tim): * status: new => assigned * owner: krc => tim * version: 6.4.1 => 6.8.2 * cc: chevalier@alum.wellesley.edu (added) Comment: Here's the state of things: The output path (printing out External Core) should work in the HEAD. I am currently trying to verify that and to update the ext-core documentation. The input path (reading in External Core) is a difficult problem. Aaron and I are both punting on it, for the immediate future. I would be happy to go into the deep reasons why this is hard, but I think you may know already, and am not sure how important this is to anyone. I am going to update the GHC manual to reflect that the input path isn't working and there are no immediate plans to fix it. - Tim -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 17 16:04:31 2008 From: trac at galois.com (GHC) Date: Sun Feb 17 16:03:02 2008 Subject: [GHC] #2107: "make install" doesn't install local copy of manual Message-ID: <042.eca0231bd2811cd8c01aa5a60d7a4d69@localhost> #2107: "make install" doesn't install local copy of manual ------------------------+--------------------------------------------------- Reporter: tim | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.9 | Severity: minor Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- If I pull the HEAD, build it, and do "make install", this doesn't install the users' guide under the prefix I specified in configure (AFAIK it doesn't install the users' guide anywhere.) It does install the library docs. Shouldn't "make install" imply "make install-docs" as well? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 17 16:20:37 2008 From: trac at galois.com (GHC) Date: Sun Feb 17 16:19:08 2008 Subject: [GHC] #2107: "make install" doesn't install local copy of manual In-Reply-To: <042.eca0231bd2811cd8c01aa5a60d7a4d69@localhost> References: <042.eca0231bd2811cd8c01aa5a60d7a4d69@localhost> Message-ID: <051.a7311eca7f582be1c7a0fde2c9d02800@localhost> #2107: "make install" doesn't install local copy of manual --------------------------------+------------------------------------------- Reporter: tim | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.9 Severity: minor | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- Changes (by tim): * type: bug => feature request Comment: Okay, I found: http://hackage.haskell.org/trac/ghc/wiki/Building/Docs which explains that you have to add "XMLDocWays = html ps" to your build.mk file in order for the docs to get built at all. But I find this confusing and, at minimum, perhaps the point could be emphasized a little more. So I'm changing this to a feature request of "install the HTML docs by default if DocBook is installed on the user's system." -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 17 18:23:23 2008 From: trac at galois.com (GHC) Date: Sun Feb 17 18:21:46 2008 Subject: [GHC] #2108: ghci is not tail recursive Message-ID: <054.2f47b0da651a624dc10537b6fb6d81f3@localhost> #2108: ghci is not tail recursive --------------------------------+------------------------------------------- Reporter: george.colpitts | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: powerpc | Os: MacOS X --------------------------------+------------------------------------------- Maybe ghci is not supposed to be tail recursive. I couldn't find anything specific to ghci or ghc but I found several places that said Haskell is tail recursive To duplicate the bug create a file that contains {{{ fib :: Int -> Int -> Int -> Int fib n prev curr = if n == 0 then curr else fib (n -1) curr (prev + curr) }}} then use :load to load it: GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help[[BR]] Loading package base ... linking ... done.[[BR]] Prelude> :load work[[BR]] [1 of 1] Compiling Main ( work.hs, interpreted )[[BR]] Ok, modules loaded: Main.[[BR]] *Main> fib 10 0 1[[BR]] 89[[BR]] *Main> fib 1234567 0 1[[BR]] *** Exception: stack overflow[[BR]] *Main> [[BR]] same result if I do :set -fobject-code before loading except that it happens quicker The function is tail recursive. It executes in Scheme with the same arguments (although extremely slowly because of the bignum arithmetic If ghci and/or ghc are not tail recursive it would be good to document it. Hopefully I have not missed something in the doc that explains this behavior -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 17 18:25:22 2008 From: trac at galois.com (GHC) Date: Sun Feb 17 18:23:43 2008 Subject: [GHC] #2109: hIsEOF blocks when applied to a non-closed socket with no input available Message-ID: <043.b486342fff35e2d03bc8e49e24c83b94@localhost> #2109: hIsEOF blocks when applied to a non-closed socket with no input available --------------------------------------+------------------------------------- Reporter: Mads | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 6.8.2 | Severity: normal Keywords: hIsEOF blocks sockets | Testcase: Architecture: Multiple | Os: Unknown --------------------------------------+------------------------------------- As shown with the attached test-programs, hIsEOF will block when applied to a socket-handle that is not closed and has no input available. I believe that hIsEOF blocks, as it calls hLookAhead (see libraries/base/GHC/Handle.hs), which blocks when there is no input. Note that this is only a problem when using sockets, as (local) files will either be EOF or has some content. If hIsEOF blocking nature is expected behaviour, then I think it should be noted in the haddock-documentation, as it seems non-obvious. Especially, as it will seem non-blocking when working with files. I am using GHC 6.8.2 on a Debian Linux box. To reproduce the bug, then first compile the test programs using the accompanying makefile. Then start the server. After that the client. As can be seen, the server will hang. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 17 18:28:30 2008 From: trac at galois.com (GHC) Date: Sun Feb 17 18:26:51 2008 Subject: [GHC] #2109: hIsEOF blocks when applied to a non-closed socket with no input available In-Reply-To: <043.b486342fff35e2d03bc8e49e24c83b94@localhost> References: <043.b486342fff35e2d03bc8e49e24c83b94@localhost> Message-ID: <052.2c944538c97334650d770fa7f92c21c7@localhost> #2109: hIsEOF blocks when applied to a non-closed socket with no input available --------------------------------------+------------------------------------- Reporter: Mads | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: Keywords: hIsEOF blocks sockets | Testcase: Architecture: x86 | Os: Linux --------------------------------------+------------------------------------- Changes (by Mads): * os: Unknown => Linux * architecture: Multiple => x86 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 17 20:51:21 2008 From: trac at galois.com (GHC) Date: Sun Feb 17 20:49:43 2008 Subject: [GHC] #2108: ghci is not tail recursive In-Reply-To: <054.2f47b0da651a624dc10537b6fb6d81f3@localhost> References: <054.2f47b0da651a624dc10537b6fb6d81f3@localhost> Message-ID: <063.76854cfa258fdb9edf7987befc4f3ee0@localhost> #2108: ghci is not tail recursive --------------------------------+------------------------------------------- Reporter: george.colpitts | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: invalid Keywords: | Testcase: Architecture: powerpc | Os: MacOS X --------------------------------+------------------------------------------- Changes (by JeremyShaw): * status: new => closed * resolution: => invalid Comment: The stack overflow is not due to lack of tail recursion, but rather laziness. Since the result (prev + curr) is never needed until you try to print the result, it is not evaluated until then. So you get a bunch of unevaluated (prev + curr) thunks building up until the stack overflows. This version uses $! to force (prev + curr) to be evaluated, fixing the space leak. {{{ fib :: Int -> Int -> Int -> Int fib n prev curr = if n == 0 then curr else fib (n -1) curr $! (prev + curr) }}} Also note that if you probably want Integer instead of Int for your types. Integer is unbounded. I am marking this invalid. People have been running into this since before Haskell existed (often while implementing fib). If it hasn't been consider a bug so far, it probably won't ever be ;) (for the same reason that non- tail recursive functions blowing the stack is not considered a bug). See this page for additional details: http://www.haskell.org/haskellwiki/Stack_overflow If you have more questions about this stack overflow (or anything else), consider asking on the haskell-cafe mailing list or the #haskell irc channel on irc.freenode.net. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 17 20:54:58 2008 From: trac at galois.com (GHC) Date: Sun Feb 17 20:53:23 2008 Subject: [GHC] #1860: GMP dyn link dependencies in binary distributions In-Reply-To: <043.ec0a7f5109223df1eb9f14bc703bb201@localhost> References: <043.ec0a7f5109223df1eb9f14bc703bb201@localhost> Message-ID: <052.f11777e402bf08febe878ed2f0111e9e@localhost> #1860: GMP dyn link dependencies in binary distributions --------------------------+------------------------------------------------- Reporter: chak | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Build System | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Multiple | --------------------------+------------------------------------------------- Comment (by chak): This problem does actually not only affect binary-dist distributions. When building an installer package for the Mac or an rpm for Linux, we use the vanilla "install" target with a non-empty DESTDIR to install into a temporary location from where the package contents is archived. So, I think, the Right Thing is * during stage 1 only to build those utils/ that are needed during the rest of the build process (e.g., ghc-pkg) in an '''inplace''' version and * during stage 2 build all utils/ with the stage 1 compiler (in an for- installation version). The only problem with that is if we want to install (locally, I presume) a stage 1 compiler - then some utils/ are not yet built. The question is whether we really need to support that (i.e., is it useful, it certainly makes things more complicated). If we want to retain the ability to install a stage 1 compiler, we could build all utils/ during stage 1 '''and''' stage 2, where the stage 2 build overwrites the stage 1 build (given the very small fraction of the overall build time spent on utils/, the slightly overhead of this scheme doesn't matter IMHO). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 18 05:50:15 2008 From: trac at galois.com (GHC) Date: Mon Feb 18 05:48:38 2008 Subject: [GHC] #149: missed CSE opportunity In-Reply-To: <045.82dbf1ade5f39047db873a9122708a49@localhost> References: <045.82dbf1ade5f39047db873a9122708a49@localhost> Message-ID: <054.f126b45079dbb20e73f3bd89f21673ae@localhost> #149: missed CSE opportunity --------------------------------------+------------------------------------- Reporter: nobody | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.8 branch Component: Compiler | Version: 5.04.2 Severity: minor | Resolution: None Keywords: optimisations | Difficulty: Moderate (1 day) Testcase: simplrun006 | Architecture: Unknown Os: Unknown | --------------------------------------+------------------------------------- Changes (by simonmar): * priority: high => normal * difficulty: Unknown => Moderate (1 day) * severity: normal => minor * milestone: 6.8.3 => 6.8 branch Old description: > {{{ > Don't know if this is a bug, but it was at least > _surprising_ to find that > > playerMostOccur [a] = a > playerMostOccur (x:xs)| numOccur x (x:xs) > > > numOccur > (playerMostOccur xs) xs > = x > | otherwise = > playerMostOccur xs > > was exponentially slower when compiled with ghc-5.04.2 > -O than: > > playerMostOccur [a] = a > playerMostOccur (x:xs)| numOccur x (x:xs) > > > numOccur pmo xs > = x > | otherwise = pmo > where pmo = > playerMostOccur xs > > Although the student responsible for the code couldn't > spot the > obvious optimisation, I was expecting that GHC's > optimiser would. :) > If it's not a bug, could you explain it to me? > > -Greg(gregm.at.cs.uwa.edu.au) > }}} New description: Don't know if this is a bug, but it was at least _surprising_ to find that {{{ playerMostOccur [a] = a playerMostOccur (x:xs) | numOccur x (x:xs) > numOccur (playerMostOccur xs) xs = x | otherwise = playerMostOccur xs }}} was exponentially slower when compiled with ghc-5.04.2 -O than: {{{ playerMostOccur [a] = a playerMostOccur (x:xs) | numOccur x (x:xs) > numOccur pmo xs = x | otherwise = pmo where pmo = playerMostOccur xs }}} Although the student responsible for the code couldn't spot the obvious optimisation, I was expecting that GHC's optimiser would. :) If it's not a bug, could you explain it to me? -Greg(gregm.at.cs.uwa.edu.au) Comment: The problem seems to be that Float Out isn't floating out the let expression in the guard, whereas presumably it used to. The let can't be floated out past a lambda, but nevertheless floating it would reveal an opportunity for CSE. Plan: try floating out ''all'' lets, even if they can't move past a lambda, and measure the difference on nofib. Not urgent enough for 6.8.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 18 05:57:45 2008 From: trac at galois.com (GHC) Date: Mon Feb 18 05:56:09 2008 Subject: [GHC] #1890: Regression in mandelbrot benchmark due to inlining In-Reply-To: <043.44a9b851e3c9386c0796e9d01c31dd61@localhost> References: <043.44a9b851e3c9386c0796e9d01c31dd61@localhost> Message-ID: <052.34a9c53f015df0f76c2d0e62a09ea67b@localhost> #1890: Regression in mandelbrot benchmark due to inlining --------------------------------------+------------------------------------- Reporter: dons | Owner: Type: run-time performance bug | Status: closed Priority: high | Milestone: 6.8.3 Component: Compiler (NCG) | Version: 6.8.1 Severity: normal | Resolution: duplicate Keywords: asm, double | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Unknown | --------------------------------------+------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => duplicate Comment: This will be fixed by #594 (support use of SSE2 in the x86 native codegen). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 18 05:58:58 2008 From: trac at galois.com (GHC) Date: Mon Feb 18 05:57:18 2008 Subject: [GHC] #594: Support use of SSE2 in the x86 native code genreator In-Reply-To: <047.5190f55d4ad1363b95d98c092787782f@localhost> References: <047.5190f55d4ad1363b95d98c092787782f@localhost> Message-ID: <056.5acf8db8c3d231c02fe1f2003a79ad25@localhost> #594: Support use of SSE2 in the x86 native code genreator ----------------------------+----------------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler (NCG) | Version: 6.4.1 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: N/A | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Comment (by simonmar): See #1890 for a test case (actually we could put that test into nofib). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 18 06:07:09 2008 From: trac at galois.com (GHC) Date: Mon Feb 18 06:05:35 2008 Subject: [GHC] #2014: getLinkDeps panic In-Reply-To: <043.959b8170a1a6ec2b7cea0d1cfc8fd3ff@localhost> References: <043.959b8170a1a6ec2b7cea0d1cfc8fd3ff@localhost> Message-ID: <052.803ce009b5c71055678699f3db3418f2@localhost> #2014: getLinkDeps panic ----------------------+----------------------------------------------------- Reporter: fons | Owner: Type: bug | Status: new Priority: high | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: blocker | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by simonmar): Presumably it is possible to work around this by adding extra imports (see #1012), does that work? (clearly there is a bug here, we just want to establish whether there is a workaround). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 18 06:21:32 2008 From: trac at galois.com (GHC) Date: Mon Feb 18 06:20:03 2008 Subject: [GHC] #2088: GHC messages do not reflect argument name changes In-Reply-To: <052.87ed87efa8aaa066021158506aae5149@localhost> References: <052.87ed87efa8aaa066021158506aae5149@localhost> Message-ID: <061.8be33f8291c711eb033d02b16ca9c0e4@localhost> #2088: GHC messages do not reflect argument name changes ---------------------------+------------------------------------------------ Reporter: sethkurtzberg | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Multiple Os: Multiple | ---------------------------+------------------------------------------------ Changes (by simonpj): * owner: => igloo Comment: The HEAD already has the fix. I suppose it's worth putting in 6.8.3. Probably easier to do it by hand (in `RnTypes.lhs` line 739). Ian: can you do this? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 18 06:30:22 2008 From: trac at galois.com (GHC) Date: Mon Feb 18 06:28:41 2008 Subject: [GHC] #2087: On a PPC Mac OS X 10.4, the RTS reports "Memory leak detected" running a program compiled with -debug -threaded -fhpc In-Reply-To: <050.7b39faa855e94ccd0c6858657071f62f@localhost> References: <050.7b39faa855e94ccd0c6858657071f62f@localhost> Message-ID: <059.a607ca0fbc4385947ff45471ac824572@localhost> #2087: On a PPC Mac OS X 10.4, the RTS reports "Memory leak detected" running a program compiled with -debug -threaded -fhpc ----------------------------+----------------------------------------------- Reporter: thorkilnaur | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Runtime System | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | ----------------------------+----------------------------------------------- Changes (by simonmar): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 18 06:39:28 2008 From: trac at galois.com (GHC) Date: Mon Feb 18 06:37:49 2008 Subject: [GHC] #1791: heap overflow should generate an exception In-Reply-To: <044.abdddbf09447556bb749e2aa1d8c6598@localhost> References: <044.abdddbf09447556bb749e2aa1d8c6598@localhost> Message-ID: <053.391fe85ba8bb8aab187474cbf0a5f8fe@localhost> #1791: heap overflow should generate an exception -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: Runtime System | Version: 6.8 Severity: blocker | Resolution: Keywords: | Difficulty: Unknown Testcase: outofmem2 | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Comment (by demetrix): Replying to [comment:5 simonmar]: > Another question is: which thread(s) should get the exception? Why not the thread currently executing IO action which failed to allocate memory? Such behaviour would be the same as in almost any other programming language. Perhaps the only potential problem here is when additional threads are spawned not explicitely with forkIO or forkOS but rather implicitely with `par` - maybe in that case the thread which forces the evaluation of the "parallel" value should get the exception? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 18 06:42:27 2008 From: trac at galois.com (GHC) Date: Mon Feb 18 06:40:57 2008 Subject: [GHC] #1992: 6.8.2 intermittent build failure on multiple OS X versions In-Reply-To: <044.6e3d43e6297883ec96aae365685c0c7d@localhost> References: <044.6e3d43e6297883ec96aae365685c0c7d@localhost> Message-ID: <053.7cab7806b751a75d6addf4ad0c9139d6@localhost> #1992: 6.8.2 intermittent build failure on multiple OS X versions ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: MacOS X | ----------------------+----------------------------------------------------- Comment (by simonmar): Could you perhaps get a ktrace of the "file is locked" failure? I want to see which operation is generating the error. I took a quick look at the code and can't see anything obviously wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 18 07:01:03 2008 From: trac at galois.com (GHC) Date: Mon Feb 18 06:59:23 2008 Subject: [GHC] #2098: validate fails for PPC Mac OS X 10.4 In-Reply-To: <050.004f36944f07736217953750484b380a@localhost> References: <050.004f36944f07736217953750484b380a@localhost> Message-ID: <059.4cf11805590631ba2d1f885540201983@localhost> #2098: validate fails for PPC Mac OS X 10.4 -------------------------+-------------------------------------------------- Reporter: thorkilnaur | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | -------------------------+-------------------------------------------------- Changes (by simonmar): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 18 07:12:23 2008 From: trac at galois.com (GHC) Date: Mon Feb 18 07:10:56 2008 Subject: [GHC] #2099: Storable instance for Complex In-Reply-To: <047.c8eaa83814b0476331366f6ca4bff701@localhost> References: <047.c8eaa83814b0476331366f6ca4bff701@localhost> Message-ID: <056.cf4394638c2a192031846a55de40f648@localhost> #2099: Storable instance for Complex ----------------------------+----------------------------------------------- Reporter: jedbrown | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ----------------------------+----------------------------------------------- Comment (by simonmar): This is slightly dubious. `Storable` is for types that have a single direct analogue on the C side: for example, `CInt` maps to `int`, `Double` maps to `HsDouble`. What does `Complex Int64` map to? Perhaps you don't really mean `Storable (Complex a)`, but instead the three instances for `CFloat`, `CDouble` and `CLongDouble`? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 18 07:18:11 2008 From: trac at galois.com (GHC) Date: Mon Feb 18 07:16:31 2008 Subject: [GHC] #1984: weird performance drop with -O2 on x86 In-Reply-To: <044.701336bc21541f57619b15fdf9cfbadd@localhost> References: <044.701336bc21541f57619b15fdf9cfbadd@localhost> Message-ID: <053.037451231c8ba1f095c4e3b9726e57d0@localhost> #1984: weird performance drop with -O2 on x86 ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.8 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------+----------------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => duplicate Comment: This is a result of #1589. When you turn on -O, the threads are created faster than they can complete and be GC'd, and the GC really slows down when there are lots of threads in the system. I'll be fixing this in 6.10. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 18 07:18:19 2008 From: trac at galois.com (GHC) Date: Mon Feb 18 07:16:43 2008 Subject: [GHC] #1589: Process creation and communication doesn't scale linearly In-Reply-To: <044.d2274ee12c731d087b3c981d4c934bbd@localhost> References: <044.d2274ee12c731d087b3c981d4c934bbd@localhost> Message-ID: <053.34869e7f7b54aefe77fc3af6b7c460d1@localhost> #1589: Process creation and communication doesn't scale linearly ----------------------------+----------------------------------------------- Reporter: guest | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Runtime System | Version: 6.7 Severity: minor | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Architecture: Multiple Os: Multiple | ----------------------------+----------------------------------------------- Comment (by simonmar): See also #1984 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 18 07:37:55 2008 From: trac at galois.com (GHC) Date: Mon Feb 18 07:36:13 2008 Subject: [GHC] #2105: garbage collection confusing in ghci for foreign objects In-Reply-To: <047.c0db5eee478c7a6109bfb2a89fd9f1d6@localhost> References: <047.c0db5eee478c7a6109bfb2a89fd9f1d6@localhost> Message-ID: <056.5ad5b65c3ec2367786ef2310c6637c64@localhost> #2105: garbage collection confusing in ghci for foreign objects --------------------------------------+------------------------------------- Reporter: Frederik | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------------------+------------------------------------- Changes (by simonmar): * difficulty: => Unknown Comment: I think we'll need more information here. Can you construct a small example of a `ForeignPtr` that is freed when you expect it to be retained? Since a `ForeignPtr` can only be derferenced in the `IO` monad, is `v` in your example an `IO` computation? Or perhaps you're using `unsafePerformIO` to dereference the `ForeignPtr`? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 18 08:06:33 2008 From: trac at galois.com (GHC) Date: Mon Feb 18 08:04:53 2008 Subject: [GHC] #2105: garbage collection confusing in ghci for foreign objects In-Reply-To: <047.c0db5eee478c7a6109bfb2a89fd9f1d6@localhost> References: <047.c0db5eee478c7a6109bfb2a89fd9f1d6@localhost> Message-ID: <056.312b7321b45ca12a5864d136efd66843@localhost> #2105: garbage collection confusing in ghci for foreign objects --------------------------------------+------------------------------------- Reporter: Frederik | Owner: Type: run-time performance bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------------------+------------------------------------- Changes (by Frederik): * status: new => closed * resolution: => invalid Comment: Thanks for the reply, I checked more closely and it turns out that the stuff being freed was just temporarily allocated by the 'show' instance. The thunk for the named variable is only evaluated once and isn't GC'ed. Sorry again! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 18 08:07:02 2008 From: trac at galois.com (GHC) Date: Mon Feb 18 08:06:16 2008 Subject: [GHC] #1544: Derived Read instances for recursive datatypes with infix constructors are too inefficient In-Reply-To: <059.876fe881e6bc9b43ab179d4b6da29ec1@localhost> References: <059.876fe881e6bc9b43ab179d4b6da29ec1@localhost> Message-ID: <068.f5565519b49eab296263bd5d5a5f61b7@localhost> #1544: Derived Read instances for recursive datatypes with infix constructors are too inefficient ----------------------------------+----------------------------------------- Reporter: jcpetruzza@gmail.com | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------------+----------------------------------------- Comment (by simonpj): Great news! Doaitse writes "I have found a student with whom I will embark on the endeavour to construct a solution to this (I have some hopes); either we will have to show a solution, or we will have to prove that this is "impossible". I hope to be able to use the kind of transformation techniques we have developed in the attached paper". Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 18 09:01:44 2008 From: trac at galois.com (GHC) Date: Mon Feb 18 09:00:24 2008 Subject: [GHC] #2099: Storable instance for Complex In-Reply-To: <047.c8eaa83814b0476331366f6ca4bff701@localhost> References: <047.c8eaa83814b0476331366f6ca4bff701@localhost> Message-ID: <056.e12c9fc71db23ecad5471b51220f232e@localhost> #2099: Storable instance for Complex ----------------------------+----------------------------------------------- Reporter: jedbrown | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ----------------------------+----------------------------------------------- Comment (by jedbrown): Care to write a RealFloat instance for Int64? It is true that what you describe would be sufficient for my needs, but I don't think the general instance is too general. All this instance prescribes is the ordering of real and imaginary components which is quite standard. With regard to Haskell versus C types, how likely is it that Double /= CDouble at some point? I'm curious what the best practice is for high performance numerics libraries where marshaling arrays in and out of each foreign call is not acceptable. This appears to mean that C types must extend arbitrarily deeply into the Haskell world which seems to defeat the point of having separate types. The libraries that I'm familiar with (hmatrix and fft) assume that Double == CDouble so they are broken if this doesn't hold. Note: There is now 'storable-vector' on Hackage which defines this instance. fft-0.1.1 depends on it and Alberto tells me that hmatrix will soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 18 09:55:17 2008 From: trac at galois.com (GHC) Date: Mon Feb 18 09:53:52 2008 Subject: [GHC] #2099: Storable instance for Complex In-Reply-To: <047.c8eaa83814b0476331366f6ca4bff701@localhost> References: <047.c8eaa83814b0476331366f6ca4bff701@localhost> Message-ID: <056.1336d3ef9ab3e351a366e4697d09f97a@localhost> #2099: Storable instance for Complex ----------------------------+----------------------------------------------- Reporter: jedbrown | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ----------------------------+----------------------------------------------- Comment (by igloo): A bit off-topic, but you should assume that Double /= CDouble, and convert with realToFrac (in a thin wrapper around the FFI imports, where you are doing things like checking errno and reading results in from pointers, is normally a sensible place to do the conversion). When Double == CDouble, this should be optimised away to no code. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 18 11:07:15 2008 From: trac at galois.com (GHC) Date: Mon Feb 18 11:05:34 2008 Subject: [GHC] #2110: Rules to eliminate casted id's Message-ID: <044.f3b76b9e96701f6ebb57092f8cedf6df@localhost> #2110: Rules to eliminate casted id's --------------------------------+------------------------------------------- Reporter: igloo | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- Some people (e.g. jedbrown, who originally brought this up) have/use C libraries that deal with arrays of doubles (i.e. CDouble) that they would like to use from Haskell code, with the Double type (perhaps there are instances of some classes for Double, but not CDouble). In jedbrown's case he has a CArray datastructure that wraps the C array and is an instance of Haskell's IArray. However, people doing this sort of thing tend to care a lot about performance, so don't want to spend O(n) time doing O(n) allocation. Thus the temptation is to make the assumption that CDouble == Double, and to create the `CArray i Double` directly. The more correct way to do it would be to make a `CArray i CDouble` and then use `amap realToFrac` to convert it to a `CArray i Double`. However, I don't believe that GHC is currently smart enough to optimise away `amap realToFrac`. Let's look at a simpler example: {{{ cdoubles :: [CDouble] cdoubles = read "foo" doubles :: [Double] doubles = map realToFrac cdoubles }}} (here `map` is playing the role of `amap`). The core for this looks like (very simplified) {{{ Q.a1 = \ (ds_aMc :: Foreign.C.Types.CDouble) -> ds_aMc Q.doubles = GHC.Base.map (Q.a1 `cast` ) Q.cdoubles }}} It looks to me that if we could produce {{{ Q.doubles = GHC.Base.map (id `cast` ) Q.cdoubles }}} instead then we might be able to have a rule {{{ forall mumble . map (id `cast` mumble) = id `cast` mumble' }}} The major problem, as far as I can see, is how to construct the `mumble'`. Does that sound plausible? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 18 11:15:06 2008 From: trac at galois.com (GHC) Date: Mon Feb 18 11:13:26 2008 Subject: [GHC] #2109: hIsEOF blocks when applied to a non-closed socket with no input available In-Reply-To: <043.b486342fff35e2d03bc8e49e24c83b94@localhost> References: <043.b486342fff35e2d03bc8e49e24c83b94@localhost> Message-ID: <052.d3b46a5dba136097cae3ea4acf6794c1@localhost> #2109: hIsEOF blocks when applied to a non-closed socket with no input available --------------------------------------+------------------------------------- Reporter: Mads | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: invalid Keywords: hIsEOF blocks sockets | Testcase: Architecture: x86 | Os: Linux --------------------------------------+------------------------------------- Changes (by mads): * status: new => closed * resolution: => invalid Comment: When reporting this bug I thought that hIsEOF should return False, in the case described in the bug report. However, this may lead to trouble. Consider the following program: do isEOF <- hIsEOF someHandle when (not isEOF) (hGetLine someHandle >>= ...) this program could fail, if "someHandle" was closed between the first and second line. Also I re-read the documentation for hIsEOF and it starts with: "For a readable handle hdl, ..." (http://haskell.org/ghc/docs/latest/html/libraries/base/System- IO.html#v%3AhIsEOF) so arguably the documentation actually says that hIsEOF may block. However, it would be nice, if the documentation said explicitly that hIsEOF could block. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 18 12:26:30 2008 From: trac at galois.com (GHC) Date: Mon Feb 18 12:24:52 2008 Subject: [GHC] #2111: Incorrect arrow rec {} notation crashes in ghci Message-ID: <044.65925b3e4836aa227396b3392eadc917@localhost> #2111: Incorrect arrow rec {} notation crashes in ghci -----------------------+---------------------------------------------------- Reporter: luqui | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.1 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: Linux -----------------------+---------------------------------------------------- {{{ [ ~ ]% ghci -fglasgow-exts -farrows GHCi, version 6.8.1: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude> do { rec { x <- undefined -< x }; undefined -< x } ghc-6.8.1: panic! (the 'impossible' happened) (GHC version 6.8.1 for i386-unknown-linux): tcDoStmt: unexpected Stmt rec {(x{v anj}) <- base:GHC.Err.undefined{v rle} -< x{v anj}} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Prelude> Leaving GHCi. [ ~ ]% ghc --version The Glorious Glasgow Haskell Compilation System, version 6.8.1 [ ~ ]% uname -a Linux madhatter 2.6.22-gentoo-r8 #6 PREEMPT Sat Oct 20 04:19:22 GMT 2007 i686 AMD Turion(tm) 64 Mobile Technology ML-40 AuthenticAMD GNU/Linux }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 18 18:21:01 2008 From: trac at galois.com (GHC) Date: Mon Feb 18 18:19:19 2008 Subject: [GHC] #2064: problems with duplicate modules In-Reply-To: <047.fdf7f2c34537ee71076b19d77bccf5a5@localhost> References: <047.fdf7f2c34537ee71076b19d77bccf5a5@localhost> Message-ID: <056.f7761e73c8cb2eacfb29bc38479db655@localhost> #2064: problems with duplicate modules ----------------------+----------------------------------------------------- Reporter: Frederik | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by duncan): Cabal >= 1.3.4 is doing this check, however it's cheap and easy to add to ghc-pkg. I think we can assume that package registration files dropped into a `package.conf.d` directory are correct so we need only do it when we register (it'd be useful to have a `ghc-pkg check --virtual- root=tmp_image/` command to double check this however). As I understand it, the plan is to use a binary cache of the info in a `package.conf.d` directory and this is also a suitable point to check. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 18 18:23:50 2008 From: trac at galois.com (GHC) Date: Mon Feb 18 18:22:21 2008 Subject: [GHC] #2071: hp2ps does not handle SCCs with spaces in the identifiers In-Reply-To: <043.db084f3257628fb450a2954b1e1b4fcc@localhost> References: <043.db084f3257628fb450a2954b1e1b4fcc@localhost> Message-ID: <052.a997640ccaebc204595656f0f7b9bdc4@localhost> #2071: hp2ps does not handle SCCs with spaces in the identifiers -----------------------+---------------------------------------------------- Reporter: benl | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Profiling | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -----------------------+---------------------------------------------------- Comment (by duncan): Replying to [comment:1 igloo]: > Rejecting SCCs containing spaces sounds like the simplest way to fix this. That seems unnecessarily restrictive to me. SCCs seem more like descriptions to me than identifiers. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 19 05:25:45 2008 From: trac at galois.com (GHC) Date: Tue Feb 19 05:24:01 2008 Subject: [GHC] #1984: weird performance drop with -O2 on x86 In-Reply-To: <044.701336bc21541f57619b15fdf9cfbadd@localhost> References: <044.701336bc21541f57619b15fdf9cfbadd@localhost> Message-ID: <053.fbdb1e611a87f9c3975ca25f692b9c94@localhost> #1984: weird performance drop with -O2 on x86 ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: bug | Status: reopened Priority: normal | Milestone: 6.8 branch Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------------+----------------------------------------------- Changes (by simonmar): * status: closed => reopened * component: Compiler => Runtime System * resolution: duplicate => Comment: Actually I lied - there was more to this than I thought. With -O turned on, the main thread was only allocating in forkIO, and it turned out that the fork primitive (and primitives in general) don't check the context switch flag, so we ended up creating lots of threads but not running any of them, so they didn't get a chance to die and the heap filled up with runnable threads causing GC to take a long time. I have a fix for this in my tree, will commit in due course. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 19 06:45:08 2008 From: trac at galois.com (GHC) Date: Tue Feb 19 06:43:24 2008 Subject: [GHC] #2111: Incorrect arrow rec {} notation crashes in ghci In-Reply-To: <044.65925b3e4836aa227396b3392eadc917@localhost> References: <044.65925b3e4836aa227396b3392eadc917@localhost> Message-ID: <053.d3c3244f1c6eff92a4caa70ab97c4758@localhost> #2111: Incorrect arrow rec {} notation crashes in ghci -------------------------+-------------------------------------------------- Reporter: luqui | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Linux -------------------------+-------------------------------------------------- Comment (by ross): The `-farrows` option turns on the `rec` keyword, but then you get this even without using arrow notation: {{{ Prelude> do { rec { x <- return ('a':x); }; putStrLn (take 20 x) } ghc-6.8.2: panic! (the 'impossible' happened) (GHC version 6.8.2 for i386-unknown-linux): tcDoStmt: unexpected Stmt rec {(x{v aon}) <- base:GHC.Base.return{v 01T} ('a' base:GHC.Base.:{(w) d 64} x{v aon})} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} but if `do` is replaced with `mdo`, it works: {{{ Prelude> mdo { rec { x <- return ('a':x); }; putStrLn (take 20 x) } aaaaaaaaaaaaaaaaaaaa }}} This is because tcDoStmt does not handle RecStmt. In the original example, the correct behaviour would be to object to the use of arrow application in an expression, as it does with `mdo`: {{{ Prelude> mdo { rec { x <- undefined -< x }; undefined -< x } :1:17: The arrow command undefined -< x was found where an expression was expected In an 'mdo' expression: x <- undefined -< x In an 'mdo' expression: rec {x <- undefined -< x} In the expression: mdo rec {x <- undefined -< x} undefined -< x }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 19 07:36:05 2008 From: trac at galois.com (GHC) Date: Tue Feb 19 07:34:53 2008 Subject: [GHC] #1889: Regression in concurrency performance from ghc 6.6 to 6.8 In-Reply-To: <043.e16206d260f09af870b49b2d72f0b205@localhost> References: <043.e16206d260f09af870b49b2d72f0b205@localhost> Message-ID: <052.ad8bd12219cdd297d5306d2443997f44@localhost> #1889: Regression in concurrency performance from ghc 6.6 to 6.8 -----------------------------------------------+---------------------------- Reporter: dons | Owner: simonmar Type: run-time performance bug | Status: closed Priority: high | Milestone: 6.8.3 Component: Runtime System | Version: 6.8.1 Severity: normal | Resolution: wontfix Keywords: threads, concurrency, performance | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -----------------------------------------------+---------------------------- Changes (by simonmar): * status: new => closed * resolution: => wontfix Comment: I've investigated this further. The small regression in performance is due to the introduction of a write barrier on `MVar`s. There isn't much we can do to improve this, however benchmarks that have a lot of `MVar`s (especially a lot of inactive `MVar`s) will see a big improvement in 6.8.2. This particular benchmark is not one of the winners, sadly, but the system scales to much larger numbers of `MVar`s better now. Indeed, this benchmark will regress again in 6.10 with the introduction of a write barrier on TSOs, but there will be bigger winners due to that change too. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 19 09:17:43 2008 From: trac at galois.com (GHC) Date: Tue Feb 19 09:16:00 2008 Subject: [GHC] #2098: validate fails for PPC Mac OS X 10.4 In-Reply-To: <050.004f36944f07736217953750484b380a@localhost> References: <050.004f36944f07736217953750484b380a@localhost> Message-ID: <059.f88678560de1f5512cef94787261ea6a@localhost> #2098: validate fails for PPC Mac OS X 10.4 -------------------------+-------------------------------------------------- Reporter: thorkilnaur | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | -------------------------+-------------------------------------------------- Comment (by simonmar): I just pushed this patch, could someone with a PPC please test and modify if necessary? {{{ Mon Feb 18 03:57:48 PST 2008 Simon Marlow * attempt to fix #2098 (PPC pepple please test & fix) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 19 12:35:44 2008 From: trac at galois.com (GHC) Date: Tue Feb 19 12:34:00 2008 Subject: [GHC] #2082: In ghci, :i leaves out parens in type In-Reply-To: <052.f371aa73fee3aae45f7806e8fd54c670@localhost> References: <052.f371aa73fee3aae45f7806e8fd54c670@localhost> Message-ID: <061.077fa8867701e08454ec9ddb18750554@localhost> #2082: In ghci, :i leaves out parens in type ---------------------------+------------------------------------------------ Reporter: chad.scherrer | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ---------------------------+------------------------------------------------ Changes (by simonpj): * owner: => simonpj Comment: I've fixed this (validating now). Ian, can you add a test? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 19 12:37:50 2008 From: trac at galois.com (GHC) Date: Tue Feb 19 12:36:10 2008 Subject: [GHC] #2102: Typeclass membership doesn't bring coercion superclass requirements into scope In-Reply-To: <044.023554459a3970ac357a8591131972fb@localhost> References: <044.023554459a3970ac357a8591131972fb@localhost> Message-ID: <053.8e4c79b34e7cc4f51af3c7b5dea87317@localhost> #2102: Typeclass membership doesn't bring coercion superclass requirements into scope -------------------------------------+-------------------------------------- Reporter: ryani | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Changes (by simonpj): * owner: => chak Comment: Manuel is working on equality constraints. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 19 12:51:57 2008 From: trac at galois.com (GHC) Date: Tue Feb 19 12:50:24 2008 Subject: [GHC] #2112: Bad error message for malformed GADTs Message-ID: <042.a8a3c695a5ecaa9d8d8b6be2b59a726e@localhost> #2112: Bad error message for malformed GADTs ------------------------+--------------------------------------------------- Reporter: tim | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 6.8.1 | Severity: minor Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- Compiling the following code: {{{ data Foo a where Bar :: a -> a }}} results in the following error message: {{{ $ ghc-6.8.1 gadt.hs -XGADTs gadt.hs:5:3: Malformed constructor result type: a In the result type of a data constructor: a In the data type declaration for `Foo' $ }}} It would be nice if the error message mentioned the name of the offending data constructor ({{{Bar}}} in this case) -- since there might be more than one. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 19 13:10:01 2008 From: trac at galois.com (GHC) Date: Tue Feb 19 13:08:20 2008 Subject: [GHC] #2111: Incorrect arrow rec {} notation crashes in ghci In-Reply-To: <044.65925b3e4836aa227396b3392eadc917@localhost> References: <044.65925b3e4836aa227396b3392eadc917@localhost> Message-ID: <053.d2884026fa4a4d43a86733d53db32e2d@localhost> #2111: Incorrect arrow rec {} notation crashes in ghci ----------------------+----------------------------------------------------- Reporter: luqui | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------+----------------------------------------------------- Changes (by simonpj): * owner: => simonpj * difficulty: => Unknown Comment: I'll fix -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 19 14:54:40 2008 From: trac at galois.com (GHC) Date: Tue Feb 19 14:52:55 2008 Subject: [GHC] #2113: +++ ghci panic Message-ID: <044.b017299e3b6e9ba39f454798f7e04241@localhost> #2113: +++ ghci panic -----------------------+---------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.6.1 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: MacOS X -----------------------+---------------------------------------------------- Loading package base ... linking ... done. Prelude> :module Control.Arrow Prelude Control.Arrow> [1,2]+++[3,4] ghc-6.6.1: panic! (the 'impossible' happened) (GHC version 6.6.1 for i386-apple-darwin): nameModule it{v aJ7} 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 Tue Feb 19 14:55:35 2008 From: trac at galois.com (GHC) Date: Tue Feb 19 14:53:51 2008 Subject: [GHC] #2113: +++ ghci panic In-Reply-To: <044.b017299e3b6e9ba39f454798f7e04241@localhost> References: <044.b017299e3b6e9ba39f454798f7e04241@localhost> Message-ID: <053.787869c23e5b127c84fc7d19d59d7eb6@localhost> #2113: +++ ghci panic -----------------------+---------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Testcase: Architecture: x86 | Os: MacOS X -----------------------+---------------------------------------------------- Comment (by guest): Better formatting {{{ Loading package base ... linking ... done. Prelude> :module Control.Arrow Prelude Control.Arrow> [1,2]+++[3,4] ghc-6.6.1: panic! (the 'impossible' happened) (GHC version 6.6.1 for i386-apple-darwin): nameModule it{v aJ7} 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 Tue Feb 19 16:10:24 2008 From: trac at galois.com (GHC) Date: Tue Feb 19 16:08:42 2008 Subject: [GHC] #1523: Constant overhead of threadDelay In-Reply-To: <043.96258e6610a08ae1b8ec464a182dd716@localhost> References: <043.96258e6610a08ae1b8ec464a182dd716@localhost> Message-ID: <052.bde017f818277cadfebe69d455745632@localhost> #1523: Constant overhead of threadDelay ----------------------------+----------------------------------------------- Reporter: chak | Owner: chak@cse.unsw.edu.au. Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: libraries/base | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------------+----------------------------------------------- Comment (by thorkilnaur): I see at this point (2 months later) that this is an Intel Mac ticket and I only have access to a PPC Mac. Nevertheless, can anybody say whether it would make sense to test it on a PPC Mac? Then I'll try that. Sorry about the disturbance otherwise. Best regards Thorkil -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 19 21:25:25 2008 From: trac at galois.com (GHC) Date: Tue Feb 19 21:23:43 2008 Subject: [GHC] #1860: GMP dyn link dependencies in binary distributions In-Reply-To: <043.ec0a7f5109223df1eb9f14bc703bb201@localhost> References: <043.ec0a7f5109223df1eb9f14bc703bb201@localhost> Message-ID: <052.7143bea8cadd1f3abf7009a3d892b806@localhost> #1860: GMP dyn link dependencies in binary distributions --------------------------+------------------------------------------------- Reporter: chak | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Build System | Version: 6.8.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Multiple | --------------------------+------------------------------------------------- Changes (by chak): * status: new => closed * resolution: => fixed Comment: I removed any compilation in binary-dist and moved it to stage 2 part of the build (as outlined above). As a side effect, this now also works for ''normal'' installs (i.e., install target, rather than binary-dist). However, installing a stage 1 compiler might not exactly have the desired effect now. I'd think that this does not matter, but others may disagree (I which case that problem could be fixed by a bit more cleverness in the install target - just let me know if anybody is unhappy with the current situation). Here the patch description: {{{ Mon Feb 18 17:18:09 EST 2008 Manuel M T Chakravarty * All installed Haskell prgms have an inplace and an installed version - GHC installs a range of compiled Haskell programs in addition to the actual compiler. To ensure that they all run on the platform targeted by the build (which may have different libraries installed than the build host), we need to make sure that all compiled Haskell code going into an install is build with the stage 1 compiler, not the bootstrap compiler. Getting this right is especially important on the Mac to enable builds that work on Mac OS X versions that are older than the one performing the build. - For all installed utils implemented in Haskell (i.e., ghc-pkg, hasktags, hsc2hs, runghc, hpe compile two versions, an inplace version and a version for installation. The former is build by the bootstrap compiler during the stage 1 build and the latter is build by the stage 1 compiler during the stage 2 build. - This is really very much as the setup for ghc itself, only that we don't use separate stage1/ and stage2/ build directories. Instead, we clean before each build. CAVEAT: This only works properly if invoked from the toplevel Makefile. - Instead of UseStage1=YES (as used by the previous binary-dist-specific recompilation), we now use the same $(stage) variables as used for the compiler proper - to increase uniformity and to avoid extra conditionals for the install target. }}} As far as the present bug is concerned, I think, we are done; hence, I'll close it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 20 01:28:01 2008 From: trac at galois.com (GHC) Date: Wed Feb 20 01:26:39 2008 Subject: [GHC] #2114: Bad error message for omitting -XExistentialQuantification flag Message-ID: <042.28403ebb48dbf904f743e7e47a5efd41@localhost> #2114: Bad error message for omitting -XExistentialQuantification flag ------------------------+--------------------------------------------------- Reporter: tim | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 6.8.2 | Severity: minor Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- If I compile this program: {{{ module Foo where data T = forall a . MkT a }}} with: {{{ ghc-6.8.1 extest.hs -c }}} I get the error: {{{ extest.hs:3:9: Not a constructor: `forall' }}} I think it would be a better error message to suggest passing in the -XExistentialQuantification flag. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 20 01:43:15 2008 From: trac at galois.com (GHC) Date: Wed Feb 20 01:41:28 2008 Subject: [GHC] #2115: option for ghc rts to be linked as a shared object / dll Message-ID: <042.2acb10a4f085887ab0f2c74b93ec3655@localhost> #2115: option for ghc rts to be linked as a shared object / dll --------------------------------+------------------------------------------- Reporter: jvl | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: Multiple | Os: Multiple --------------------------------+------------------------------------------- The ghc runtime is statically linked into each executable that ghc creates. This adds approximately 600K or more to each executable. Whilst for large programs this overhead is not to great, for embedded systems, where space is a premium this becomes problematic. Many C compilers offer a selection of statically linking in the C runtime library or dynamically linking it in. GHC should offer the same options. As ghc rts is considerably more complex than that of C runtime, this poses some difficulty, but with appropriate bootstrapping code statically linked to load a shared rts, when this option is selected; creating such an option should not be to difficult to do. This option, should in the first instance be made available on windows. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 20 04:13:24 2008 From: trac at galois.com (GHC) Date: Wed Feb 20 04:11:42 2008 Subject: [GHC] #1523: Constant overhead of threadDelay In-Reply-To: <043.96258e6610a08ae1b8ec464a182dd716@localhost> References: <043.96258e6610a08ae1b8ec464a182dd716@localhost> Message-ID: <052.96071bcb4fe878c33c781a764c8abeb3@localhost> #1523: Constant overhead of threadDelay ----------------------------+----------------------------------------------- Reporter: chak | Owner: chak@cse.unsw.edu.au. Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: libraries/base | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------------+----------------------------------------------- Comment (by simonmar): Yes, please test on PPC. I imagine this issue has more to do with the OS than with the processor architecture. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 20 04:51:28 2008 From: trac at galois.com (GHC) Date: Wed Feb 20 04:49:46 2008 Subject: [GHC] #1830: Automatic derivation of Lift In-Reply-To: <044.3eb409743bc4021eb94e63cb46f573bc@localhost> References: <044.3eb409743bc4021eb94e63cb46f573bc@localhost> Message-ID: <053.144e6f490a84e3af3ecdf155cca14595@localhost> #1830: Automatic derivation of Lift ------------------------------+--------------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: Template Haskell | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ------------------------------+--------------------------------------------- Comment (by fons): This haskell-cafe thread might help http://www.haskell.org/pipermail /haskell-cafe/2007-November/033955.html -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 20 06:44:52 2008 From: trac at galois.com (GHC) Date: Wed Feb 20 06:43:04 2008 Subject: [GHC] #2116: ghci should try to read erroneous modules partially Message-ID: <049.057d3d778b5cc727821ad8871b5a5e34@localhost> #2116: ghci should try to read erroneous modules partially --------------------------------+------------------------------------------- Reporter: j.waldmann | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- If ghci (re-)reads a module that contains some error, then it considers the module loading as a complete failure, and at the prompt I get the Prelude environment. It is understandable that ghci rejects modules with syntax errors, but for syntactically correct modules with type errors I wish that at least the effect of import statements would be visible. Perhaps even some partial type checking could be done, and declarations that pass this can be executed. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 20 09:18:47 2008 From: trac at galois.com (GHC) Date: Wed Feb 20 09:17:00 2008 Subject: [GHC] #2113: +++ ghci panic In-Reply-To: <044.b017299e3b6e9ba39f454798f7e04241@localhost> References: <044.b017299e3b6e9ba39f454798f7e04241@localhost> Message-ID: <053.002167d5e919eeff72e7431af05e6ca9@localhost> #2113: +++ ghci panic ---------------------+------------------------------------------------------ Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.6.1 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ---------------------+------------------------------------------------------ Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: Fixed in 6.8.1+, see #1513 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 20 09:21:35 2008 From: trac at galois.com (GHC) Date: Wed Feb 20 09:19:50 2008 Subject: [GHC] #2115: option for ghc rts to be linked as a shared object / dll In-Reply-To: <042.2acb10a4f085887ab0f2c74b93ec3655@localhost> References: <042.2acb10a4f085887ab0f2c74b93ec3655@localhost> Message-ID: <051.4e0436db5b8cd1b8783d447969b746be@localhost> #2115: option for ghc rts to be linked as a shared object / dll -----------------------------+---------------------------------------------- Reporter: jvl | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -----------------------------+---------------------------------------------- Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: We'll be adding support for dynamic linking in GHC 6.10. The basic support is already done (thanks to Clemens Fruhwirth's Summer of Code project). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 20 09:24:49 2008 From: trac at galois.com (GHC) Date: Wed Feb 20 09:23:02 2008 Subject: [GHC] #2116: ghci should try to read erroneous modules partially In-Reply-To: <049.057d3d778b5cc727821ad8871b5a5e34@localhost> References: <049.057d3d778b5cc727821ad8871b5a5e34@localhost> Message-ID: <058.edea41030a351e26d84c9e61fd1182c9@localhost> #2116: ghci should try to read erroneous modules partially -----------------------------+---------------------------------------------- Reporter: j.waldmann | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: Thanks for the report, this one will be fixed in 6.8.3. See #2049. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 20 09:26:19 2008 From: trac at galois.com (GHC) Date: Wed Feb 20 09:24:31 2008 Subject: [GHC] #2116: ghci should try to read erroneous modules partially In-Reply-To: <049.057d3d778b5cc727821ad8871b5a5e34@localhost> References: <049.057d3d778b5cc727821ad8871b5a5e34@localhost> Message-ID: <058.f9b2a6a4e53a7df34b601e33fe610d5a@localhost> #2116: ghci should try to read erroneous modules partially -----------------------------+---------------------------------------------- Reporter: j.waldmann | Owner: Type: feature request | Status: reopened Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by simonmar): * status: closed => reopened * resolution: duplicate => Comment: oops, sorry, too trigger-happy there. I mis-read the ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 20 11:12:09 2008 From: trac at galois.com (GHC) Date: Wed Feb 20 11:10:22 2008 Subject: [GHC] #1129: recvFrom blocking In-Reply-To: <049.d8e4c0d26188ed420999f8fe02d4af7f@localhost> References: <049.d8e4c0d26188ed420999f8fe02d4af7f@localhost> Message-ID: <058.db9f6f8c3eedbc155a7d0ee2ecb4aefc@localhost> #1129: recvFrom blocking -------------------------------+-------------------------------------------- Reporter: JuanMarcus | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.8.3 Component: libraries/network | Version: 6.6 Severity: blocker | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | -------------------------------+-------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: I've implemented a partial fix: it now works if you use `-threaded`. It seemed hard to get this working without `-threaded`, so I've punted on that. Please re-open the ticket if that's important to you. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 20 14:18:33 2008 From: trac at galois.com (GHC) Date: Wed Feb 20 14:16:49 2008 Subject: [GHC] #1523: Constant overhead of threadDelay In-Reply-To: <043.96258e6610a08ae1b8ec464a182dd716@localhost> References: <043.96258e6610a08ae1b8ec464a182dd716@localhost> Message-ID: <052.18b4201699508826916513c7aac16cee@localhost> #1523: Constant overhead of threadDelay ----------------------------+----------------------------------------------- Reporter: chak | Owner: thorkilnaur Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: libraries/base | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------------+----------------------------------------------- Changes (by thorkilnaur): * owner: chak@cse.unsw.edu.au. => thorkilnaur -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 20 19:35:38 2008 From: trac at galois.com (GHC) Date: Wed Feb 20 19:33:49 2008 Subject: [GHC] #2098: validate fails for PPC Mac OS X 10.4 In-Reply-To: <050.004f36944f07736217953750484b380a@localhost> References: <050.004f36944f07736217953750484b380a@localhost> Message-ID: <059.c5af9e3eaa28800b60bc33da73bec98b@localhost> #2098: validate fails for PPC Mac OS X 10.4 -------------------------+-------------------------------------------------- Reporter: thorkilnaur | Owner: simonmar Type: bug | Status: closed Priority: highest | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | -------------------------+-------------------------------------------------- Changes (by thorkilnaur): * status: new => closed * resolution: => fixed Comment: On a PPC Mac OS X 10.4, validate now completes with this summary: {{{ OVERALL SUMMARY for test run started at Wed Feb 20 22:52:28 CET 2008 2091 total tests, which gave rise to 7883 test cases, of which 0 caused framework failures 6100 were skipped 1702 expected passes 79 expected failures 0 unexpected passes 2 unexpected failures Unexpected failures: divbyzero(normal) ghci024(ghci) }}} So the patch has removed the earlier failure. Thanks and best regards Thorkil -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 21 15:33:47 2008 From: trac at galois.com (GHC) Date: Thu Feb 21 15:31:55 2008 Subject: [GHC] #974: Add partitionEithers, lefts, rights to Data.Either In-Reply-To: <044.771c90fc72736a1914b3f63a62b98bc6@localhost> References: <044.771c90fc72736a1914b3f63a62b98bc6@localhost> Message-ID: <053.b9aa3ae889fd6773fe18919711877761@localhost> #974: Add partitionEithers, lefts, rights to Data.Either ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: proposal | Status: reopened Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by r6): * summary: Add unzipEithers, lefts, rights to Data.Either => Add partitionEithers, lefts, rights to Data.Either Comment: I am setting a deadline for this proposal for March 7th. To join the latest discussion, see . -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 22 06:50:37 2008 From: trac at galois.com (GHC) Date: Fri Feb 22 06:48:53 2008 Subject: [GHC] #2117: ppc "./Setup build" seg-faults on Mac OS leopard Message-ID: <045.49291ad5dcecd52c54fd505935d3d802@localhost> #2117: ppc "./Setup build" seg-faults on Mac OS leopard ------------------------+--------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: powerpc | Os: MacOS X ------------------------+--------------------------------------------------- http://www.haskell.org//pipermail/glasgow-haskell- users/2008-February/014309.html http://www.haskell.org//pipermail/glasgow-haskell- users/2008-February/014363.html -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 22 09:51:13 2008 From: trac at galois.com (GHC) Date: Fri Feb 22 09:49:20 2008 Subject: [GHC] #1984: weird performance drop with -O2 on x86 In-Reply-To: <044.701336bc21541f57619b15fdf9cfbadd@localhost> References: <044.701336bc21541f57619b15fdf9cfbadd@localhost> Message-ID: <053.08961a12114770162ed34e34a84b8cc9@localhost> #1984: weird performance drop with -O2 on x86 ----------------------------+----------------------------------------------- Reporter: guest | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.8.3 Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------------+----------------------------------------------- Changes (by simonmar): * status: reopened => new * owner: => igloo * type: bug => merge * milestone: 6.8 branch => 6.8.3 Comment: Fixed: {{{ Tue Feb 19 10:22:12 GMT 2008 Simon Marlow * Fix #1984: missing context switches }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 22 10:46:15 2008 From: trac at galois.com (GHC) Date: Fri Feb 22 10:44:23 2008 Subject: [GHC] #2118: deriving for GRose Message-ID: <045.57b7b214a8eb05be517b22ad66f257fd@localhost> #2118: deriving for GRose ----------------------------------------------------+----------------------- Reporter: alexey | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: type classes, undecidable instances | Testcase: Architecture: x86 | Os: MacOS X ----------------------------------------------------+----------------------- GHC 6.6 used to be happy with the program below provided that i use "-fglasgow-exts -fallow-undecidable-instances" {{{ data GRose ff a = GRose a (ff (GRose ff a)) }}} The same program does NOT work with GHC 6.8, 6.8.1 and 6.8.2, even if I use the options "-fglasgow-exts -XUndecidableInstances". This is the error I get: {{{ No instance for (Show (ff (GRose ff a))) arising from the 'deriving' clause of a data type declaration at domotest.hs:2:0-56 Possible fix: add an instance declaration for (Show (ff (GRose ff a))) When deriving the instance for (Show (GRose ff a)) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 22 22:12:32 2008 From: trac at galois.com (GHC) Date: Fri Feb 22 22:10:36 2008 Subject: [GHC] #2119: explicitly importing deprecated symbols should elicit the deprecation warning Message-ID: <045.affc63bba10af8681f58c8409e4aaf99@localhost> #2119: explicitly importing deprecated symbols should elicit the deprecation warning --------------------------------+------------------------------------------- Reporter: duncan | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- If we explicitly import but do not use a deprecated function then ghc does not give the deprecation warning. {{{ module Foo where {-# DEPRECATED foo "don't use foo please, use ..." #-} foo = ... }}} {{{ module Bar where import Foo (foo) }}} This is a bit annoying since it means client packages do not get any notification that some function is going to disappear but they would break if it does disappear. Or to look at it another way, it prevents me removing old deprecated functions because I don't want to break client programs but I have no way of communicating that to the author of a program that is importing but is no longer using the deprecated function. My real world example is the Cabal lib and lhs2tex's Setup.hs file. It is importing `Distribution.Simple.LocalBuildInfo.mkDataDir` (which is deprecated in the current released Cabal version) but the Setup.hs is not actually using it, so the author got no indication that it should not be imported anymore. In the development version of Cabal I'd already removed this deprecated function since I assumed we'd given everyone plenty of warning. I'll have to go add `mkDataDir` back. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 23 07:09:25 2008 From: trac at galois.com (GHC) Date: Sat Feb 23 07:07:33 2008 Subject: [GHC] #1523: Constant overhead of threadDelay In-Reply-To: <043.96258e6610a08ae1b8ec464a182dd716@localhost> References: <043.96258e6610a08ae1b8ec464a182dd716@localhost> Message-ID: <052.27acb30939742f63991c5fcda95f3407@localhost> #1523: Constant overhead of threadDelay ----------------------------+----------------------------------------------- Reporter: chak | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: libraries/base | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------------+----------------------------------------------- Changes (by thorkilnaur): * owner: thorkilnaur => Comment: For this test, I compare these versions of GHC: {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.6.20070220 $ /Users/thorkilnaur/tn/GHCDarcsRepository/ghc-HEAD-complete-for-pulling- and-copying-20070713_1212/ghc/compiler/stage2/ghc-inplace --version The Glorious Glasgow Haskell Compilation System, version 6.9.20080219 $ }}} Initially, I have ktrace'd runs of a program (the testsuite's concio001.hs) containing a single threadDelay call using the two GHC versions and observed that the number of select calls dropped from 82 to 5. So the cure has certainly worked towards reducing the number of select calls. To measure the threadDelay overhead, I use: {{{ $ cat threadDelayTest1.hs import System import Control.Concurrent totalDelay = 1000000 main = do argv <- getArgs let stepDelay = read $ argv!!0 stepCount = totalDelay`div`stepDelay in do putStrLn $ "Performing " ++ show stepCount ++ " delays of " ++ show stepDelay ++ " microsecs" sequence_ $ replicate stepCount $ threadDelay stepDelay putStrLn "Done" $ }}} With the old GHC version, I get: {{{ $ ghc --make threadDelayTest1.hs [1 of 1] Compiling Main ( threadDelayTest1.hs, threadDelayTest1.o ) Linking threadDelayTest1 ... $ time ./threadDelayTest1 1000000 Performing 1 delays of 1000000 microsecs Done real 0m1.609s user 0m0.010s sys 0m0.042s $ time ./threadDelayTest1 1000000 Performing 1 delays of 1000000 microsecs Done real 0m1.156s user 0m0.007s sys 0m0.022s $ time ./threadDelayTest1 100000 Performing 10 delays of 100000 microsecs Done real 0m2.057s user 0m0.112s sys 0m0.339s $ time ./threadDelayTest1 10000 Performing 100 delays of 10000 microsecs Done real 0m15.069s user 0m1.222s sys 0m3.672s $ time ./threadDelayTest1 1000 Performing 1000 delays of 1000 microsecs Done real 2m30.095s user 0m12.390s sys 0m37.142s $ }}} From these measurements, the overhead can be computed as 0.1, 0.14, and 0.15 seconds for each threadDelay for the latter three runs. I also note a considerable amount of CPU being spent here. With the recent GHC, I get: {{{ $ /Users/thorkilnaur/tn/GHCDarcsRepository/ghc-HEAD-complete-for-pulling- and-copying-20070713_1212/ghc/compiler/stage2/ghc-inplace --make threadDelayTest1.hs [1 of 1] Compiling Main ( threadDelayTest1.hs, threadDelayTest1.o ) Linking threadDelayTest1 ... $ time ./threadDelayTest1 1000000 Performing 1 delays of 1000000 microsecs Done real 0m2.519s user 0m0.006s sys 0m0.045s $ time ./threadDelayTest1 1000000 Performing 1 delays of 1000000 microsecs Done real 0m1.123s user 0m0.005s sys 0m0.020s $ time ./threadDelayTest1 100000 Performing 10 delays of 100000 microsecs Done real 0m1.314s user 0m0.005s sys 0m0.020s $ time ./threadDelayTest1 10000 Performing 100 delays of 10000 microsecs Done real 0m4.131s user 0m0.007s sys 0m0.024s $ time ./threadDelayTest1 1000 Performing 1000 delays of 1000 microsecs Done real 0m40.248s user 0m0.022s sys 0m0.044s $ }}} The overheads are computed as 0.02, 0.03, and 0.04 seconds for the latter three runs. I will leave it to others to judge whether this is acceptable. Best regards Thorkil -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 23 19:46:05 2008 From: trac at galois.com (GHC) Date: Sat Feb 23 19:44:09 2008 Subject: [GHC] #886: Profiling doesn't work with -threaded In-Reply-To: <045.4eeb420dca9023055216aedeee61b5e7@localhost> References: <045.4eeb420dca9023055216aedeee61b5e7@localhost> Message-ID: <054.def0b5596dcc4a5d0d10052afabcd3e9@localhost> #886: Profiling doesn't work with -threaded ----------------------------+----------------------------------------------- Reporter: Lemmih | Owner: Type: task | Status: new Priority: normal | Milestone: 6.10 branch Component: Runtime System | Version: 6.5 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Architecture: Multiple Os: Multiple | ----------------------------+----------------------------------------------- Comment (by Frederik): Hello, it seems that this bug isn't very clear from the documentation or the GHC web page, can we be honest and update http://haskell.org/ghc/ where it says "Profiling is supported, both by time/allocation and various kinds of heap profiling." to say "Profiling is supported, both by time/allocation and various kinds of heap profiling, provided you do not use threads."? Thank you. -- Ticket URL: GHC The Glasgow Haskell Compiler From frederik at a5.repetae.net Sat Feb 23 21:33:58 2008 From: frederik at a5.repetae.net (Frederik Eaton) Date: Sat Feb 23 21:32:00 2008 Subject: how to use ghci-debugger with packages In-Reply-To: <200802240236.08237.daniel.is.fischer@web.de> References: <20080224011859.GA6714@a5.repetae.net> <200802240236.08237.daniel.is.fischer@web.de> Message-ID: <20080224023358.GD13696@a5.repetae.net> On Sun, Feb 24, 2008 at 02:36:08AM +0100, Daniel Fischer wrote: > Am Sonntag, 24. Februar 2008 02:18 schrieb Frederik Eaton: > > Hello, > > > > I have a program which uses some code in a package, and I would like > > to be able to find out the source of an error which is occuring inside > > that package. Can I use the ghci-debugger to do this? If I try to set > > a breakpoint inside the package, it says: > > > > "cannot set breakpoint on Vector.Sparse.Wrappers.vmergeOp: module > > Vector.Sparse.Wrappers is not interpreted" > > > > But this page: > > > > http://www.haskell.org/ghc/dist/current/docs/users_guide/ghci-debugger.html > > > > has no use of the word "package", so I assume that reading that (long) > > document won't ansnwer my question... > > > > Thank you, > > > > Frederik > > The users-guide says > "There is one major restriction: breakpoints and single-stepping are only > available in interpreted modules; compiled code is invisible to the > debugger." > > The modules of an installed package are always compiled, I think. That's what I think as well, but I'm not sure (and it seems like the documentation should mention that: CC'ing glasgow-haskell-bugs). I can't see a reason why an installed package wouldn't be able to contain its own source code, for instance... > If you have the source available, you could try to put that in your working > directory (probably hide the installed package before starting ghci). Thanks, I may try that. I'm currently trying to get my GNU-make-based build to install profiling versions of package modules, in the hope that -xc might give more useful information than it did a year ago... Frederik -- http://ofb.net/~frederik/ From trac at galois.com Sun Feb 24 06:45:34 2008 From: trac at galois.com (GHC) Date: Sun Feb 24 06:43:48 2008 Subject: [GHC] #1523: Constant overhead of threadDelay In-Reply-To: <043.96258e6610a08ae1b8ec464a182dd716@localhost> References: <043.96258e6610a08ae1b8ec464a182dd716@localhost> Message-ID: <052.219cb11f24f83a7d06780e013ca62ffa@localhost> #1523: Constant overhead of threadDelay ----------------------------+----------------------------------------------- Reporter: chak | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: libraries/base | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------------+----------------------------------------------- Comment (by thorkilnaur): For comparison, on a x86 SuSE Linux, here are some measurements using two different GHC versions: {{{ tn@linux:~/tn/test/GHC/trac/1523/work> ghc --version The Glorious Glasgow Haskell Compilation System, version 6.4.1 tn@linux:~/tn/test/GHC/trac/1523/work> ghc --make threadDelayTest1.hs -o threadDelayTest1 Chasing modules from: threadDelayTest1.hs Compiling Main ( threadDelayTest1.hs, threadDelayTest1.o ) Linking ... tn@linux:~/tn/test/GHC/trac/1523/work> time ./threadDelayTest1 1000000 Performing 1 delays of 1000000 microsecs Done real 0m1.124s user 0m0.000s sys 0m0.016s tn@linux:~/tn/test/GHC/trac/1523/work> time ./threadDelayTest1 1000000 Performing 1 delays of 1000000 microsecs Done real 0m1.006s user 0m0.000s sys 0m0.004s tn@linux:~/tn/test/GHC/trac/1523/work> time ./threadDelayTest1 100000 Performing 10 delays of 100000 microsecs Done real 0m1.188s user 0m0.000s sys 0m0.008s tn@linux:~/tn/test/GHC/trac/1523/work> time ./threadDelayTest1 10000 Performing 100 delays of 10000 microsecs Done real 0m2.002s user 0m0.144s sys 0m1.832s tn@linux:~/tn/test/GHC/trac/1523/work> time ./threadDelayTest1 1000 Performing 1000 delays of 1000 microsecs Done real 0m19.987s user 0m1.952s sys 0m16.749s tn@linux:~/tn/test/GHC/trac/1523/work> /home/tn/tn/install/ghc-6.8.2/bin/ghc --version The Glorious Glasgow Haskell Compilation System, version 6.8.2 tn@linux:~/tn/test/GHC/trac/1523/work> /home/tn/tn/install/ghc-6.8.2/bin/ghc --make threadDelayTest1.hs -o threadDelayTest1 [1 of 1] Compiling Main ( threadDelayTest1.hs, threadDelayTest1.o ) Linking threadDelayTest1 ... tn@linux:~/tn/test/GHC/trac/1523/work> time ./threadDelayTest1 1000000 Performing 1 delays of 1000000 microsecs Done real 0m1.165s user 0m0.008s sys 0m0.000s tn@linux:~/tn/test/GHC/trac/1523/work> time ./threadDelayTest1 1000000 Performing 1 delays of 1000000 microsecs Done real 0m1.020s user 0m0.000s sys 0m0.000s tn@linux:~/tn/test/GHC/trac/1523/work> time ./threadDelayTest1 100000 Performing 10 delays of 100000 microsecs Done real 0m1.202s user 0m0.000s sys 0m0.004s tn@linux:~/tn/test/GHC/trac/1523/work> time ./threadDelayTest1 10000 Performing 100 delays of 10000 microsecs Done real 0m4.001s user 0m0.004s sys 0m0.000s tn@linux:~/tn/test/GHC/trac/1523/work> time ./threadDelayTest1 1000 Performing 1000 delays of 1000 microsecs Done real 0m40.003s user 0m0.000s sys 0m0.004s tn@linux:~/tn/test/GHC/trac/1523/work> }}} Best regards Thorkil -- Ticket URL: GHC The Glasgow Haskell Compiler From frederik at a5.repetae.net Sun Feb 24 08:38:00 2008 From: frederik at a5.repetae.net (Frederik Eaton) Date: Sun Feb 24 08:36:04 2008 Subject: ghc-pkg.bin in infinite loop Message-ID: <20080224133800.GB6714@a5.repetae.net> Hello, ghc-pkg.bin has been using up most of the CPU for over 3 minutes, is this a known bug? Frederik From trac at galois.com Sun Feb 24 09:03:51 2008 From: trac at galois.com (GHC) Date: Sun Feb 24 09:01:54 2008 Subject: [GHC] #2103: Some functions in network library do not work on NetBSD In-Reply-To: <044.1756b8af1f0088b08382108c842e3c22@localhost> References: <044.1756b8af1f0088b08382108c842e3c22@localhost> Message-ID: <053.e781507f0a85c473611873a0f2bf37d4@localhost> #2103: Some functions in network library do not work on NetBSD -------------------------------+-------------------------------------------- Reporter: iquiw | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.8.3 Component: libraries/network | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: network | Difficulty: Unknown Testcase: | Architecture: Unknown Os: NetBSD | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Patch applied, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 24 09:05:50 2008 From: trac at galois.com (GHC) Date: Sun Feb 24 09:04:03 2008 Subject: [GHC] #2100: [PATCH] generated FFI ccall stub prototypes are incomplete In-Reply-To: <042.903eb13e232c19cfd1c4fc81f12d1f06@localhost> References: <042.903eb13e232c19cfd1c4fc81f12d1f06@localhost> Message-ID: <051.911c42a954d2d1d5437e344c79ce9c58@localhost> #2100: [PATCH] generated FFI ccall stub prototypes are incomplete ----------------------------+----------------------------------------------- Reporter: pcc | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.8.3 Component: Compiler (FFI) | Version: 6.9 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ----------------------------+----------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Now applied to both the HEAD and the 6.8 branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 24 09:51:35 2008 From: trac at galois.com (GHC) Date: Sun Feb 24 09:50:39 2008 Subject: [GHC] #2071: hp2ps does not handle SCCs with spaces in the identifiers In-Reply-To: <043.db084f3257628fb450a2954b1e1b4fcc@localhost> References: <043.db084f3257628fb450a2954b1e1b4fcc@localhost> Message-ID: <052.d30ecbdda26336d5613603bd5a50f968@localhost> #2071: hp2ps does not handle SCCs with spaces in the identifiers -----------------------+---------------------------------------------------- Reporter: benl | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Profiling | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -----------------------+---------------------------------------------------- Comment (by igloo): Replying to [comment:2 duncan]: > Replying to [comment:1 igloo]: > > Rejecting SCCs containing spaces sounds like the simplest way to fix this. > > That seems unnecessarily restrictive to me. SCCs seem more like descriptions to me than identifiers. Perhaps, but as far as I know no-one's tripped over it before, and it probably never worked. -- Ticket URL: GHC The Glasgow Haskell Compiler From duncan.coutts at worc.ox.ac.uk Sun Feb 24 12:06:52 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Feb 24 12:07:04 2008 Subject: ghc-pkg.bin in infinite loop In-Reply-To: <20080224133800.GB6714@a5.repetae.net> References: <20080224133800.GB6714@a5.repetae.net> Message-ID: <1203872812.3076.227.camel@localhost> On Sun, 2008-02-24 at 13:38 +0000, Frederik Eaton wrote: > Hello, > > ghc-pkg.bin has been using up most of the CPU for over 3 minutes, is > this a known bug? Perhaps you have cyclic packages? I recall a bug being fixed to do with that recently, but the current versions would still have the problem. Duncan From trac at galois.com Sun Feb 24 12:51:56 2008 From: trac at galois.com (GHC) Date: Sun Feb 24 12:49:56 2008 Subject: [GHC] #2120: Arrays allow out-of-bounds indexes Message-ID: <046.df9dbe29ac2a6f0cde1841f7056aebbe@localhost> #2120: Arrays allow out-of-bounds indexes -------------------------+-------------------------------------------------- Reporter: amthrax | Owner: Type: bug | Status: new Priority: normal | Component: libraries (other) Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Multiple | Os: Multiple -------------------------+-------------------------------------------------- The array changes proposed and recently implemented for ticket #1610 (Make arrays safer) strengthened the requirements on `Ix` instances, but weakened the requirements on array users. Specifically, array referencing now permits indexes that are ''not'' `inRange`. For example, {{{ import Data.Array.IArray b :: Array (Int,Int) Int b = listArray ((0,0), (3,3)) (repeat 0) main = do print (b ! (0,5)) -- SHOULD fail, but doesn't print (index (bounds b) (0,5)) -- DOES fail }}} The first line in `main` ''should'' fail because the specified index is not `inRange`, but doesn't because the `(!)` operator (specifically `Data.Array.Base.safeIndex`) now uses `unsafeIndex` and simply checks that the resulting index is within the linearized bounds of the array. In this case, the unsafe index of (0,5) wraps aroung to the index of (1,1). A simple fix would be to use `index` instead of `unsafeIndex` in the implementation of `Data.Array.Base.safeIndex`. This would both require the user to use in-bounds references and would require `Ix` instances to return in-bounds indexes. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 24 12:59:15 2008 From: trac at galois.com (GHC) Date: Sun Feb 24 12:57:14 2008 Subject: [GHC] #1610: Make arrays safer In-Reply-To: <044.2772d89bdbdf392f82e328eabd2888b6@localhost> References: <044.2772d89bdbdf392f82e328eabd2888b6@localhost> Message-ID: <053.f747046aa313b5d1d2b5f0e7075e7861@localhost> #1610: Make arrays safer -------------------------------+-------------------------------------------- Reporter: igloo | Owner: igloo Type: proposal | Status: closed Priority: high | Milestone: 6.8.1 Component: libraries (other) | Version: 6.6.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Comment (by amthrax): The implementation of `safeIndex` in this change makes it possible to perform array references that are not `inRange`. I've detailed the bug and one resolution in ticket #2120. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 24 13:01:10 2008 From: trac at galois.com (GHC) Date: Sun Feb 24 12:59:14 2008 Subject: [GHC] #1955: Heap profiling on Windows doesn't work In-Reply-To: <051.41700a7931b75f5016d260a75d133aed@localhost> References: <051.41700a7931b75f5016d260a75d133aed@localhost> Message-ID: <060.e660e24217cdb5a2f4fcffaf5c1edae6@localhost> #1955: Heap profiling on Windows doesn't work ----------------------------+----------------------------------------------- Reporter: NeilMitchell | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Runtime System | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Windows | ----------------------------+----------------------------------------------- Changes (by igloo): * owner: => simonmar Comment: OK, part of the problem is that with the gcc 3.4.2 supplied with GHC the `argv[0]` value is changed to be the path to the executable if we are in a cygwin shell, but not if we are in a cmd shell; the 3.4.4 I have installed works as I'd expect in either case. With a cygwin shell: {{{ $ cat argv0.c #include int main(int argc, char **argv) { printf("%s\n", argv[0]); } $ gcc -dumpversion 3.4.4 $ gcc argv0.c -o 344 $ c:/ghc/ghc-6.8.2/gcc -dumpversion 3.4.2 $ c:/ghc/ghc-6.8.2/gcc argv0.c -o 342 $ ./344 ./344 $ ./342 C:\cygwin\home\ian\q\342.exe }}} In cmd: {{{ C:\cygwin\home\ian\q>344 344 C:\cygwin\home\ian\q>342 342 }}} Simon, I am assigning this bug to you as it'll need to be you who upgrades the version of gcc that comes with the nightly Windows build. After that, I think that the best thing is to drop this code from `utils/hp2ps/Main.c`: {{{ #if defined(_MSC_VER) || defined(__MINGW32__) || defined(_WIN32) DropSuffix(pathName, ".exe"); pathName = copystring2(pathName,".exe"); #endif }}} That way, if people use `foo.exe` to run the program then `hp2ps foo.exe` will work, and likewise, if they use `foo` then `hp2ps foo` will work. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 24 13:08:04 2008 From: trac at galois.com (GHC) Date: Sun Feb 24 13:06:20 2008 Subject: [GHC] #2088: GHC messages do not reflect argument name changes In-Reply-To: <052.87ed87efa8aaa066021158506aae5149@localhost> References: <052.87ed87efa8aaa066021158506aae5149@localhost> Message-ID: <061.c4d8bf4c9ce17a72742ec6872b644d39@localhost> #2088: GHC messages do not reflect argument name changes ---------------------------+------------------------------------------------ Reporter: sethkurtzberg | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Multiple Os: Multiple | ---------------------------+------------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Now also fixed in the 6.8 branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 24 13:08:39 2008 From: trac at galois.com (GHC) Date: Sun Feb 24 13:06:41 2008 Subject: [GHC] #1984: weird performance drop with -O2 on x86 In-Reply-To: <044.701336bc21541f57619b15fdf9cfbadd@localhost> References: <044.701336bc21541f57619b15fdf9cfbadd@localhost> Message-ID: <053.a8d607bf02eba848c98e28ce32242c6c@localhost> #1984: weird performance drop with -O2 on x86 ----------------------------+----------------------------------------------- Reporter: guest | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.8.3 Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------------+----------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 24 13:09:26 2008 From: trac at galois.com (GHC) Date: Sun Feb 24 13:07:28 2008 Subject: [GHC] #2023: Packages.lhs:mungePackagePaths doesn't handle haddock-html & haddock-interfaces In-Reply-To: <044.353c7e94c0ee9b420199f0094f141941@localhost> References: <044.353c7e94c0ee9b420199f0094f141941@localhost> Message-ID: <053.93c535b0b92116da8e4ff75a310196ab@localhost> #2023: Packages.lhs:mungePackagePaths doesn't handle haddock-html & haddock- interfaces ----------------------+----------------------------------------------------- Reporter: guest | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: packages | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed and merged: {{{ Sat Feb 9 06:36:48 PST 2008 Simon Marlow * FIX #2023: substitute for $topdir in haddockInterfaces and haddockHTMLs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 24 15:04:58 2008 From: trac at galois.com (GHC) Date: Sun Feb 24 15:03:00 2008 Subject: [GHC] #1899: compiler does not halt In-Reply-To: <044.2d1523d14ae1f01a86eeaaf884416abd@localhost> References: <044.2d1523d14ae1f01a86eeaaf884416abd@localhost> Message-ID: <053.6b91d7e251be5142994aa3b1c05b9a19@localhost> #1899: compiler does not halt ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Unknown | ----------------------+----------------------------------------------------- Comment (by igloo): This module (not well-typed): {{{ module ILPSAT where data Constraint a = Formula [[Proposition a]] data Proposition a = Prop a | Auxiliary [Proposition a] transRHS :: [a] -> Int -> Constraint a transRHS varSet b = if b < 0 then Formula [[Prop (Auxiliary undefined)]] else Formula $ [[Prop (Auxiliary varSet), Prop (Auxiliary varSet)] ] }}} With 6.8.2 and the HEAD: {{{ $ ghc -dcore-lint -c ILPSAT.hs -fforce-recomp -v [...] *** Renamer/typechecker: }}} at which point it appears to hang. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 24 15:46:54 2008 From: trac at galois.com (GHC) Date: Sun Feb 24 15:44:56 2008 Subject: [GHC] #2082: In ghci, :i leaves out parens in type In-Reply-To: <052.f371aa73fee3aae45f7806e8fd54c670@localhost> References: <052.f371aa73fee3aae45f7806e8fd54c670@localhost> Message-ID: <061.be192e3dcef0bc69e1298f6abb1f5f95@localhost> #2082: In ghci, :i leaves out parens in type ---------------------------+------------------------------------------------ Reporter: chad.scherrer | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: ghci030 | Architecture: x86 Os: Linux | ---------------------------+------------------------------------------------ Changes (by igloo): * testcase: => ghci030 Comment: Test added: ghci030. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 24 15:48:05 2008 From: trac at galois.com (GHC) Date: Sun Feb 24 15:46:06 2008 Subject: [GHC] #1977: Adding small check in Linux installer In-Reply-To: <044.ae029e1b95208651d10139d6f00f898c@localhost> References: <044.ae029e1b95208651d10139d6f00f898c@localhost> Message-ID: <053.f1db5f5e003ee2c9269c96ad35572049@localhost> #1977: Adding small check in Linux installer -----------------------------+---------------------------------------------- Reporter: Tener | Owner: Type: bug | Status: closed Priority: lowest | Milestone: 6.8.3 Component: None | Version: 6.8.1 Severity: trivial | Resolution: fixed Keywords: installer, path | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Linux | -----------------------------+---------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Done in HEAD and 6.8 branch: {{{ Sun Feb 24 05:43:34 PST 2008 Ian Lynagh * FIX #1977: Check to see if $(bindir) is in the path Before telling the user to add it, when installing a bindist, check to see if $(bindir) is already in the path. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 24 15:49:29 2008 From: trac at galois.com (GHC) Date: Sun Feb 24 15:47:41 2008 Subject: [GHC] #2073: ghci records empty input lines in readline history In-Reply-To: <045.754f0911fd9e82aafab4d99a7c2d2f12@localhost> References: <045.754f0911fd9e82aafab4d99a7c2d2f12@localhost> Message-ID: <054.a4ea0b885badb6b7e309b5224daff091@localhost> #2073: ghci records empty input lines in readline history -------------------------------+-------------------------------------------- Reporter: Eelis- | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.8.3 Component: GHCi | Version: 6.8.2 Severity: minor | Resolution: fixed Keywords: readline, history | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed in HEAD and 6.8 branch: {{{ Sun Feb 24 06:32:56 PST 2008 Ian Lynagh * FIX #2073: Don't add empty lines to GHCI's history }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 24 16:31:09 2008 From: trac at galois.com (GHC) Date: Sun Feb 24 16:29:08 2008 Subject: [GHC] #1281: runghc, runhaskell invoke wrong ghc when not first ghc in PATH In-Reply-To: <051.688c37be95655ef452fcfa7bd4cd6ebf@localhost> References: <051.688c37be95655ef452fcfa7bd4cd6ebf@localhost> Message-ID: <060.1e18de92c6f6c2d07b19e5147874f560@localhost> #1281: runghc, runhaskell invoke wrong ghc when not first ghc in PATH --------------------------+------------------------------------------------- Reporter: Isaac Dupree | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Linux | --------------------------+------------------------------------------------- Comment (by igloo): OK, it turns out that it is zsh that handles scripts with a `#!` pointing at a script. If I try to do it in a bash shell then it doesn't work. There's more information on http://www.in- ulm.de/~mascheck/various/shebang/, but the gist is that we can't make runhaskell a script (at least, not without requiring users use `#!/usr/bin/env runhaskell`). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 24 16:40:45 2008 From: trac at galois.com (GHC) Date: Sun Feb 24 16:38:46 2008 Subject: [GHC] #1281: runghc, runhaskell invoke wrong ghc when not first ghc in PATH In-Reply-To: <051.688c37be95655ef452fcfa7bd4cd6ebf@localhost> References: <051.688c37be95655ef452fcfa7bd4cd6ebf@localhost> Message-ID: <060.a84ac778415dcf469d330ab03e4b05f9@localhost> #1281: runghc, runhaskell invoke wrong ghc when not first ghc in PATH --------------------------+------------------------------------------------- Reporter: Isaac Dupree | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Linux | --------------------------+------------------------------------------------- Comment (by igloo): I think symlinks are the best way forward here. Is there a reason we don't use a symlink for ghci? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 25 03:05:50 2008 From: trac at galois.com (GHC) Date: Mon Feb 25 03:03:49 2008 Subject: [GHC] #1955: Heap profiling on Windows doesn't work In-Reply-To: <051.41700a7931b75f5016d260a75d133aed@localhost> References: <051.41700a7931b75f5016d260a75d133aed@localhost> Message-ID: <060.b69500d71974373b6ea73320639632f1@localhost> #1955: Heap profiling on Windows doesn't work ----------------------------+----------------------------------------------- Reporter: NeilMitchell | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Runtime System | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Windows | ----------------------------+----------------------------------------------- Comment (by NeilMitchell): In general, a Windows user would expect {{{foo.exe}}} then {{{h2ps foo}}} to work, and vice versa. Is there any reason for not always dropping the .exe when figuring out the heap profiling location, including within hp2ps? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 25 04:24:21 2008 From: trac at galois.com (GHC) Date: Mon Feb 25 04:22:18 2008 Subject: [GHC] #1281: runghc, runhaskell invoke wrong ghc when not first ghc in PATH In-Reply-To: <051.688c37be95655ef452fcfa7bd4cd6ebf@localhost> References: <051.688c37be95655ef452fcfa7bd4cd6ebf@localhost> Message-ID: <060.197f696cdd7497dee0bc83cd584217bb@localhost> #1281: runghc, runhaskell invoke wrong ghc when not first ghc in PATH --------------------------+------------------------------------------------- Reporter: Isaac Dupree | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Linux | --------------------------+------------------------------------------------- Comment (by simonmar): Replying to [comment:8 igloo]: > I think symlinks are the best way forward here. Is there a reason we don't use a symlink for ghci? No symlinks on Windows, but perhaps we could use symlinks on Un*x. The symlink would have to point to the wrapper script that invokes the GHC binary, so the cleverness might have to be in the script, not GHC itself. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 25 05:10:02 2008 From: trac at galois.com (GHC) Date: Mon Feb 25 05:08:00 2008 Subject: [GHC] #1281: runghc, runhaskell invoke wrong ghc when not first ghc in PATH In-Reply-To: <051.688c37be95655ef452fcfa7bd4cd6ebf@localhost> References: <051.688c37be95655ef452fcfa7bd4cd6ebf@localhost> Message-ID: <060.0bc22a807c1e820c48c6578bf34b1308@localhost> #1281: runghc, runhaskell invoke wrong ghc when not first ghc in PATH --------------------------+------------------------------------------------- Reporter: Isaac Dupree | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Linux | --------------------------+------------------------------------------------- Comment (by igloo): Replying to [comment:9 simonmar]: > Replying to [comment:8 igloo]: > > I think symlinks are the best way forward here. Is there a reason we don't use a symlink for ghci? > > No symlinks on Windows, but perhaps we could use symlinks on Un*x. The symlink would have to point to the wrapper script that invokes the GHC binary, so the cleverness might have to be in the script, not GHC itself. Oh, right, because we still need to pass the right -B flag. So symlinks won't work for runghc, as the #! line will still point to a script. So I think that that reduces our options to either leaving things as they are, or requiring that people use `#!/usr/bin/env runhaskell` if they want to make Haskell scripts. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 25 05:12:03 2008 From: trac at galois.com (GHC) Date: Mon Feb 25 05:10:01 2008 Subject: [GHC] #1955: Heap profiling on Windows doesn't work In-Reply-To: <051.41700a7931b75f5016d260a75d133aed@localhost> References: <051.41700a7931b75f5016d260a75d133aed@localhost> Message-ID: <060.87cef25e3c6677f9340e3e1586c7e63c@localhost> #1955: Heap profiling on Windows doesn't work ----------------------------+----------------------------------------------- Reporter: NeilMitchell | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Runtime System | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Windows | ----------------------------+----------------------------------------------- Comment (by igloo): That's probably better, good point. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 25 05:15:11 2008 From: trac at galois.com (GHC) Date: Mon Feb 25 05:13:09 2008 Subject: [GHC] #1216: indexing 2d arrays is slow and leaky. why? In-Reply-To: <044.7a2c34fb5e14ee065cc1b66e35e75915@localhost> References: <044.7a2c34fb5e14ee065cc1b66e35e75915@localhost> Message-ID: <053.50fee0357b036f7d2420f7833ed39add@localhost> #1216: indexing 2d arrays is slow and leaky. why? --------------------------------------+------------------------------------- Reporter: claus | Owner: simonpj Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------------------+------------------------------------- Changes (by simonmar): * type: bug => run-time performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 25 06:11:11 2008 From: trac at galois.com (GHC) Date: Mon Feb 25 06:09:12 2008 Subject: [GHC] #1523: Constant overhead of threadDelay In-Reply-To: <043.96258e6610a08ae1b8ec464a182dd716@localhost> References: <043.96258e6610a08ae1b8ec464a182dd716@localhost> Message-ID: <052.b34b4ba8401c43f1382887579b7dc112@localhost> #1523: Constant overhead of threadDelay ----------------------------+----------------------------------------------- Reporter: chak | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.8.3 Component: libraries/base | Version: 6.7 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------------+----------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Thanks for the testing Thorkil. I don't think we have any issues specifically relating to `threadDelay` left here, so I'm closing the bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 25 06:18:17 2008 From: trac at galois.com (GHC) Date: Mon Feb 25 06:16:16 2008 Subject: [GHC] #886: Profiling doesn't work with -threaded In-Reply-To: <045.4eeb420dca9023055216aedeee61b5e7@localhost> References: <045.4eeb420dca9023055216aedeee61b5e7@localhost> Message-ID: <054.c16b7ee97c6e3f68f23ffe2f11230181@localhost> #886: Profiling doesn't work with -threaded ----------------------------+----------------------------------------------- Reporter: Lemmih | Owner: Type: task | Status: new Priority: normal | Milestone: 6.10 branch Component: Runtime System | Version: 6.5 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Architecture: Multiple Os: Multiple | ----------------------------+----------------------------------------------- Comment (by simonmar): Replying to [comment:8 Frederik]: > to say "Profiling is supported, both by time/allocation and various kinds of heap profiling, provided you do not use threads."? Just wanted to make sure there's no misunderstanding here: you can use threads with profiling just fine, the bug is that you can't use the `-threaded` option with profiling. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 25 06:58:20 2008 From: trac at galois.com (GHC) Date: Mon Feb 25 06:56:17 2008 Subject: [GHC] #886: Profiling doesn't work with -threaded In-Reply-To: <045.4eeb420dca9023055216aedeee61b5e7@localhost> References: <045.4eeb420dca9023055216aedeee61b5e7@localhost> Message-ID: <054.e9d9a2ec7b853656d78386fffed35a8b@localhost> #886: Profiling doesn't work with -threaded ----------------------------+----------------------------------------------- Reporter: Lemmih | Owner: Type: task | Status: new Priority: normal | Milestone: 6.10 branch Component: Runtime System | Version: 6.5 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Architecture: Multiple Os: Multiple | ----------------------------+----------------------------------------------- Comment (by Frederik): Hello, I was just thinking about that too, is it not common for people to use -threaded? Myself, I ran into this problem when I was trying to debug something that I found I had to compile with -threaded to work properly, but maybe I should have been using forkProcess. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 25 09:10:01 2008 From: trac at galois.com (GHC) Date: Mon Feb 25 09:08:02 2008 Subject: [GHC] #2112: Bad error message for malformed GADTs In-Reply-To: <042.a8a3c695a5ecaa9d8d8b6be2b59a726e@localhost> References: <042.a8a3c695a5ecaa9d8d8b6be2b59a726e@localhost> Message-ID: <051.4b36b48b7f445a12414cad9a1745836f@localhost> #2112: Bad error message for malformed GADTs -------------------------------------+-------------------------------------- Reporter: tim | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.8.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: tcfail146 | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Changes (by simonpj): * testcase: => tcfail146 * difficulty: => Unknown * owner: => simonpj -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 25 11:42:40 2008 From: trac at galois.com (GHC) Date: Mon Feb 25 11:40:36 2008 Subject: [GHC] #2121: ghc-6.8.2: panic! -- idInfo b{tv a4zK} [tv] Message-ID: <047.e4adcbb2ad9abfb7aa020deb970f42f3@localhost> #2121: ghc-6.8.2: panic! -- idInfo b{tv a4zK} [tv] -------------------------+-------------------------------------------------- Reporter: vladimir | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: Linux -------------------------+-------------------------------------------------- ghc-6.8.2: panic! (the 'impossible' happened) (GHC version 6.8.2 for i386-unknown-linux): idInfo b{tv a4zK} [tv] When compiling the attached file from XMonadContrib darcs version. (http://xmonad.org) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 25 12:27:43 2008 From: trac at galois.com (GHC) Date: Mon Feb 25 12:25:48 2008 Subject: [GHC] #2112: Bad error message for malformed GADTs In-Reply-To: <042.a8a3c695a5ecaa9d8d8b6be2b59a726e@localhost> References: <042.a8a3c695a5ecaa9d8d8b6be2b59a726e@localhost> Message-ID: <051.ffa79ed1182dd38d8c88b88a08948597@localhost> #2112: Bad error message for malformed GADTs -------------------------------------+-------------------------------------- Reporter: tim | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.8.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: tcfail146 | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Changes (by simonpj): * owner: simonpj => igloo * type: bug => merge Comment: Fixed by {{{ Fri Feb 22 18:25:14 GMT 2008 simonpj@microsoft.com * Improve error messages from type-checking data constructors }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 25 12:29:49 2008 From: trac at galois.com (GHC) Date: Mon Feb 25 12:27:51 2008 Subject: [GHC] #2114: Bad error message for omitting -XExistentialQuantification flag In-Reply-To: <042.28403ebb48dbf904f743e7e47a5efd41@localhost> References: <042.28403ebb48dbf904f743e7e47a5efd41@localhost> Message-ID: <051.0779eab983c57ec8eac144a78c0a8807@localhost> #2114: Bad error message for omitting -XExistentialQuantification flag -------------------------------------+-------------------------------------- Reporter: tim | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.8.2 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: rnfail052, rnfail053 | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Changes (by simonpj): * testcase: => rnfail052, rnfail053 * difficulty: => Unknown * type: bug => merge * owner: => igloo Comment: Fixed by {{{ Fri Feb 22 18:26:46 GMT 2008 simonpj@microsoft.com * Fix Trac #2114: error reporting for 'forall' without appropriate flags }}} This is a mixture of parser and renamer improvements. Still a bit ad-hoc, but better than before. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 25 12:33:11 2008 From: trac at galois.com (GHC) Date: Mon Feb 25 12:31:09 2008 Subject: [GHC] #2082: In ghci, :i leaves out parens in type In-Reply-To: <052.f371aa73fee3aae45f7806e8fd54c670@localhost> References: <052.f371aa73fee3aae45f7806e8fd54c670@localhost> Message-ID: <061.c1c604d805347e5ddaa9cb8d37bdee98@localhost> #2082: In ghci, :i leaves out parens in type ---------------------------+------------------------------------------------ Reporter: chad.scherrer | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.8.3 Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: ghci030 | Architecture: x86 Os: Linux | ---------------------------+------------------------------------------------ Changes (by simonpj): * owner: simonpj => igloo * type: bug => merge Comment: Fixed by {{{ Tue Feb 19 17:34:10 GMT 2008 simonpj@microsoft.com * Fix Trac #2082 }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 25 20:14:56 2008 From: trac at galois.com (GHC) Date: Mon Feb 25 20:12:52 2008 Subject: [GHC] #2122: file locked even though hClose called Message-ID: <049.be63a8f92d13b1b85271244f7bf7fa0f@localhost> #2122: file locked even though hClose called ---------------------------+------------------------------------------------ Reporter: JeremyShaw | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: Linux ---------------------------+------------------------------------------------ If I open the same file twice with openFile, then close both handles, and then use writeFile to overwrite the file, I get a locked file error. I have attached a file which includes three test cases. One always fails, one always succeeds, and one sometimes fails when run multiple times, but only in GHCi. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 26 05:29:37 2008 From: trac at galois.com (GHC) Date: Tue Feb 26 05:27:31 2008 Subject: [GHC] #886: Profiling doesn't work with -threaded In-Reply-To: <045.4eeb420dca9023055216aedeee61b5e7@localhost> References: <045.4eeb420dca9023055216aedeee61b5e7@localhost> Message-ID: <054.db0e40932b817286aac2182d595084a6@localhost> #886: Profiling doesn't work with -threaded ----------------------------+----------------------------------------------- Reporter: Lemmih | Owner: Type: task | Status: new Priority: normal | Milestone: 6.10 branch Component: Runtime System | Version: 6.5 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Architecture: Multiple Os: Multiple | ----------------------------+----------------------------------------------- Comment (by simonmar): Often there's no reason ''not'' to use `-threaded` (unless you want to profile, of course!). But it's only necessary if you want to (a) use multiple processors or (b) make FFI calls that don't block all threads. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 26 05:34:13 2008 From: trac at galois.com (GHC) Date: Tue Feb 26 05:32:07 2008 Subject: [GHC] #2123: implement waitForProcess using signals Message-ID: <047.96e17276f11f467a9162fc8e32a52352@localhost> #2123: implement waitForProcess using signals ----------------------------------+----------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 6.10 branch Component: libraries/process | Version: 6.8.2 Severity: normal | Keywords: Difficulty: Moderate (1 day) | Testcase: Architecture: Unknown | Os: Unknown ----------------------------------+----------------------------------------- `waitForProcess` currently calls `waitpid` with a safe FFI call, which means that * you need to use `-threaded` to call this in a multithreaded program * one OS thread is needed per `waitProcess` instead we could implement this using the IO manager: have `waitForProcess` communicate with the IO manager, which wakes up the client when the appropriate `SIGCHLD` is received. Note that this means hooking `SIGCHLD` so we'd interact badly if the program itself wanted to use `SIGCHLD`. I think it was Duncan Coutts who mentioned this idea to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 26 06:24:00 2008 From: trac at galois.com (GHC) Date: Tue Feb 26 06:23:16 2008 Subject: [GHC] #2122: file locked even though hClose called In-Reply-To: <049.be63a8f92d13b1b85271244f7bf7fa0f@localhost> References: <049.be63a8f92d13b1b85271244f7bf7fa0f@localhost> Message-ID: <058.cf7d711d9be85062f25b13413f48e35f@localhost> #2122: file locked even though hClose called ----------------------------+----------------------------------------------- Reporter: JeremyShaw | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------------+----------------------------------------------- Changes (by simonmar): * owner: => simonmar * difficulty: => Unknown Comment: Nice report, thanks. I'm testing a fix now. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 26 08:48:00 2008 From: trac at galois.com (GHC) Date: Tue Feb 26 08:45:53 2008 Subject: [GHC] #2122: file locked even though hClose called In-Reply-To: <049.be63a8f92d13b1b85271244f7bf7fa0f@localhost> References: <049.be63a8f92d13b1b85271244f7bf7fa0f@localhost> Message-ID: <058.a6fdf82c072ac719d6146347bee976e1@localhost> #2122: file locked even though hClose called ----------------------------+----------------------------------------------- Reporter: JeremyShaw | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.8.3 Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------------+----------------------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge * component: libraries/base => Runtime System * milestone: => 6.8.3 Comment: Fixed. The only workaround is not to have the file open more than once. {{{ Tue Feb 26 10:46:50 GMT 2008 Simon Marlow * FIX #2122: file locking bug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 26 11:18:38 2008 From: trac at galois.com (GHC) Date: Tue Feb 26 11:16:35 2008 Subject: [GHC] #2124: My program compiles with -O1 but compiler panics with -O2 and up Message-ID: <046.21f867a8697b0fd12e937ed0b8fc8521@localhost> #2124: My program compiles with -O1 but compiler panics with -O2 and up -----------------------------+---------------------------------------------- Reporter: brassel | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: minor Keywords: optimization | Testcase: Architecture: x86 | Os: Linux -----------------------------+---------------------------------------------- I get an ghc-6.8.2: panic! (the 'impossible' happened) (GHC version 6.8.2 for i386-unknown-linux): nameModule poly_lookup'1_slSy{v} when compiling my module with -O2 and up. Before giving more details, i.e., going to the work of isolating the bug I'd like to know if there is an interest for this. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 26 11:27:40 2008 From: trac at galois.com (GHC) Date: Tue Feb 26 11:25:33 2008 Subject: [GHC] #2124: My program compiles with -O1 but compiler panics with -O2 and up In-Reply-To: <046.21f867a8697b0fd12e937ed0b8fc8521@localhost> References: <046.21f867a8697b0fd12e937ed0b8fc8521@localhost> Message-ID: <055.f121039fca7fba6c5a5139a5bc1a91c3@localhost> #2124: My program compiles with -O1 but compiler panics with -O2 and up --------------------------+------------------------------------------------- Reporter: brassel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: minor | Resolution: Keywords: optimization | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | --------------------------+------------------------------------------------- Changes (by simonpj): * difficulty: => Unknown Comment: That is bad. Yes we are interested. Can you give us the program? Or a boiled down version (much better if possible)? It's hard to track down without it. thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 26 11:57:36 2008 From: trac at galois.com (GHC) Date: Tue Feb 26 11:55:29 2008 Subject: [GHC] #2008: GHCi takes increasingly more memory In-Reply-To: <051.6d649c23331d31238e1b16c9a01068ae@localhost> References: <051.6d649c23331d31238e1b16c9a01068ae@localhost> Message-ID: <060.73454e37ff9c2087e85563a5a33a96e2@localhost> #2008: GHCi takes increasingly more memory --------------------------+------------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.9 Severity: normal | Resolution: worksforme Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Windows | --------------------------+------------------------------------------------- Changes (by NeilMitchell): * status: new => closed * resolution: => worksforme Comment: I am unable to replicate this with any other machine, and the one machine that this did happen on is now totally dead. No real chance of ever duplicating this, but will watch out for it in future. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 26 12:01:11 2008 From: trac at galois.com (GHC) Date: Tue Feb 26 11:59:08 2008 Subject: [GHC] #2125: PAP object entered! Message-ID: <047.1ef51b2b4e956858e95c7aa01df1d6ea@localhost> #2125: PAP object entered! -------------------------+-------------------------------------------------- Reporter: vladimir | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: Linux -------------------------+-------------------------------------------------- Error message when using a xmonad extension (Prompt.Shell) (xmonad-0.6 - darcs version) xmonad-i386-linux: internal error: PAP object entered! (GHC version 6.8.2 for i386_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug I'm not a dev and have no idea what info to provide to make this report useful... if you need something, you can ask me here : (i can easily reproduce it). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 26 12:13:36 2008 From: trac at galois.com (GHC) Date: Tue Feb 26 12:11:34 2008 Subject: [GHC] #2125: PAP object entered! In-Reply-To: <047.1ef51b2b4e956858e95c7aa01df1d6ea@localhost> References: <047.1ef51b2b4e956858e95c7aa01df1d6ea@localhost> Message-ID: <056.0cd105fa1cb370cd4e6ff96c0d6e2ff2@localhost> #2125: PAP object entered! ----------------------+----------------------------------------------------- Reporter: vladimir | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------+----------------------------------------------------- Changes (by simonpj): * difficulty: => Unknown Comment: That certainly sounds like a bug. Can you give enough info for us to reproduce it, please? Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 26 12:34:29 2008 From: trac at galois.com (GHC) Date: Tue Feb 26 12:32:25 2008 Subject: [GHC] #2125: PAP object entered! In-Reply-To: <047.1ef51b2b4e956858e95c7aa01df1d6ea@localhost> References: <047.1ef51b2b4e956858e95c7aa01df1d6ea@localhost> Message-ID: <056.4a16423e12d1924b172f1eb6d1c8cc2a@localhost> #2125: PAP object entered! ----------------------+----------------------------------------------------- Reporter: vladimir | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------+----------------------------------------------------- Comment (by vladimir): Problem is, i don't know what "enough info" would be :] Let's try : Using xmonad 0.6 darcs version, last updated yesterday (along with XMonadContrib files) The X11 library is also up to date. Never had this problem before yesterday's update. The steps to reproduce it : 1) Spawn Shell prompt 2) type anything (doesnt have to be a valid command) 3) Press 4) X11 crashes to console with following message : xmonad-i386-linux: internal error: PAP object entered! (GHC version 6.8.2 for i386_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug My full xmonad.hs config (http://pastebin.com/m6804d9e1) and xinitrc (http://pastebin.com/m42de0648) if needed. I on a gentoo box, 2.6.24-r2 kernel, xorg-server-1.4.0.90-r3, terminal=rxvt-unicode(8.9), shell=zsh(4.3.5), ghc-6.8.2 ... hope this helps... anything else ? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 26 12:41:21 2008 From: trac at galois.com (GHC) Date: Tue Feb 26 12:39:18 2008 Subject: [GHC] #2125: PAP object entered! In-Reply-To: <047.1ef51b2b4e956858e95c7aa01df1d6ea@localhost> References: <047.1ef51b2b4e956858e95c7aa01df1d6ea@localhost> Message-ID: <056.1299009eb98ca862a1b3c765e6837ad6@localhost> #2125: PAP object entered! ----------------------+----------------------------------------------------- Reporter: vladimir | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------+----------------------------------------------------- Comment (by simonpj): I forgot to mention: can you pls compile everything with `-dcore-lint`, and of course makes sure that you start with make-clean so there are no old `.o` files and `.hi` files lying around. Same for #2121 S -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 26 12:57:48 2008 From: trac at galois.com (GHC) Date: Tue Feb 26 12:55:41 2008 Subject: [GHC] #2124: My program compiles with -O1 but compiler panics with -O2 and up In-Reply-To: <046.21f867a8697b0fd12e937ed0b8fc8521@localhost> References: <046.21f867a8697b0fd12e937ed0b8fc8521@localhost> Message-ID: <055.cb1b2beb5c79501f6b8f92ce844144b8@localhost> #2124: My program compiles with -O1 but compiler panics with -O2 and up --------------------------+------------------------------------------------- Reporter: brassel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: minor | Resolution: Keywords: optimization | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | --------------------------+------------------------------------------------- Comment (by brassel): Yes of course. Boiling down proves to be much harder than expected. Thus in a first version, I have to give you the three modules involved. Sorry about that! But whenever I comment out one part of CompileBug.hs the bug vanishes. Maybe I can do better tomorrow. Here some hopefully useful observations: 1.) the bug goes away when you add -fno-monomorphism-restriction 2.) whenever I comment out things I get Ambiguous type variable `k' in the constraint: `Ord k' arising from a use of `FM.member' at CompileBug.hs:17:11-19 Possible cause: the monomorphism restriction applied to the following: myMember :: forall a. k -> FM.Map k a -> Bool (bound at CompileBug.hs:17:0) Probable fix: give these definition(s) an explicit type signature or use -fno-monomorphism-restriction because of the three lines myFromList = FM.fromList myLookup = FM.lookup myMember = FM.member at the beginning. 3.) the bug only comes with -O2, -O3, -O4, but not with simply -O 4.) The two additional modules compile just fine in whatever mode Hope this helps! If not, let me know and I will give boiling down a fresh try on the morrow. Guten Tag! Bernd -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 26 12:58:42 2008 From: trac at galois.com (GHC) Date: Tue Feb 26 12:56:38 2008 Subject: [GHC] #1899: compiler does not halt In-Reply-To: <044.2d1523d14ae1f01a86eeaaf884416abd@localhost> References: <044.2d1523d14ae1f01a86eeaaf884416abd@localhost> Message-ID: <053.52760d308c3c39793817258a77ad3b9c@localhost> #1899: compiler does not halt ----------------------+----------------------------------------------------- Reporter: guest | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: T1899 | Architecture: x86_64 (amd64) Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonpj): * testcase: => T1899 * owner: => igloo * type: bug => merge Comment: Thanks for boiling this down Ian. Fixed by {{{ Tue Feb 26 17:47:43 GMT 2008 simonpj@microsoft.com * Fix Trac #1899; missing equality check in typechecker's constraint simplifier }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 26 13:17:59 2008 From: trac at galois.com (GHC) Date: Tue Feb 26 13:16:02 2008 Subject: [GHC] #2125: PAP object entered! In-Reply-To: <047.1ef51b2b4e956858e95c7aa01df1d6ea@localhost> References: <047.1ef51b2b4e956858e95c7aa01df1d6ea@localhost> Message-ID: <056.3730c901ecc5249bec02fe2f5b1a3507@localhost> #2125: PAP object entered! ----------------------+----------------------------------------------------- Reporter: vladimir | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------+----------------------------------------------------- Comment (by vladimir): Done and both bugs vanished. Next time i'll clean before reporting. Sorry. Should i rebuild without the -dcore-lint ? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 26 18:59:47 2008 From: trac at galois.com (GHC) Date: Tue Feb 26 18:57:41 2008 Subject: [GHC] #2122: file locked even though hClose called In-Reply-To: <049.be63a8f92d13b1b85271244f7bf7fa0f@localhost> References: <049.be63a8f92d13b1b85271244f7bf7fa0f@localhost> Message-ID: <058.9ad342246cbe6604647048337fee10c5@localhost> #2122: file locked even though hClose called ----------------------------+----------------------------------------------- Reporter: JeremyShaw | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.8.3 Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------------+----------------------------------------------- Comment (by JeremyShaw): Thanks, this seems to have fixed the problem we were seeing in our real code. It may have also helped with some space usage as well. No good data on that though. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 26 20:03:53 2008 From: trac at galois.com (GHC) Date: Tue Feb 26 20:01:56 2008 Subject: [GHC] #2126: Misleading error message for newtype with no constructors Message-ID: <042.76c0e53865b0febc05402345d0a1b7df@localhost> #2126: Misleading error message for newtype with no constructors ------------------------+--------------------------------------------------- Reporter: tim | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 6.8.1 | Severity: trivial Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- Further adventures in error message pedantry! If I compile this module: {{{ module Foo where newtype X }}} I get: {{{ $ ghc -c Foo.hs Foo.hs:3:0: `X' has no constructors (-XEmptyDataDecls permits this) In the newtype declaration for `X' }}} Naively, I do what it suggests: {{{ $ ghc -c Foo.hs -XEmptyDataDecls Foo.hs:3:0: A newtype must have exactly one constructor, but `X' has none In the newtype declaration for `X' }}} It would be better to just print the second error message even when the user doesn't pass {{{-XEmptyDataDecls}}}, and not lead them down a maze of twisty little passages... -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 26 21:04:29 2008 From: trac at galois.com (GHC) Date: Tue Feb 26 21:02:32 2008 Subject: [GHC] #2127: Bad error message for FFI declaration with no -fffi flag Message-ID: <042.d91279db4013202517c91f1f3175fec8@localhost> #2127: Bad error message for FFI declaration with no -fffi flag ------------------------+--------------------------------------------------- Reporter: tim | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Parser) Version: 6.8.1 | Severity: minor Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- If I compile: {{{ module Ccall where import Foreign.C.Types foreign import ccall "stdio.h putchar" putchar :: CInt -> IO CInt }}} I get: {{{ $ ghc-6.8.1 -c -fext-core Ccall.hs -no-recomp Ccall.hs:5:8: parse error on input `import' }}} A better error message would be to suggest passing the -fffi flag. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 27 01:39:53 2008 From: trac at galois.com (GHC) Date: Wed Feb 27 01:37:46 2008 Subject: [GHC] #2125: PAP object entered! In-Reply-To: <047.1ef51b2b4e956858e95c7aa01df1d6ea@localhost> References: <047.1ef51b2b4e956858e95c7aa01df1d6ea@localhost> Message-ID: <056.6ed2adeb0e07be240d59d3d497d2161f@localhost> #2125: PAP object entered! ----------------------+----------------------------------------------------- Reporter: vladimir | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------+----------------------------------------------------- Changes (by vladimir): * status: new => closed * resolution: => fixed Comment: Rebuilt everything without -dcore-lint and still working properly. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 27 01:42:43 2008 From: trac at galois.com (GHC) Date: Wed Feb 27 01:40:36 2008 Subject: [GHC] #2121: ghc-6.8.2: panic! -- idInfo b{tv a4zK} [tv] In-Reply-To: <047.e4adcbb2ad9abfb7aa020deb970f42f3@localhost> References: <047.e4adcbb2ad9abfb7aa020deb970f42f3@localhost> Message-ID: <056.7ce1943a63d072498cd2a2a084c3a402@localhost> #2121: ghc-6.8.2: panic! -- idInfo b{tv a4zK} [tv] -------------------------+-------------------------------------------------- Reporter: vladimir | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Testcase: Architecture: x86 | Os: Linux -------------------------+-------------------------------------------------- Changes (by vladimir): * status: new => closed * resolution: => fixed Comment: Solved by cleaning before full rebuild, as suggested by simonpj for #2125. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 27 05:24:16 2008 From: trac at galois.com (GHC) Date: Wed Feb 27 05:22:14 2008 Subject: [GHC] #2128: Space leak with :trace Message-ID: <047.d2c047a7adb527bf1745d0129337ce92@localhost> #2128: Space leak with :trace -------------------------+-------------------------------------------------- Reporter: mnislaih | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: MacOS X -------------------------+-------------------------------------------------- There is some ugly space behaviour going on with :trace. I noticed while during a long running debugging session. My program runs for about 30 seconds (under ghci) and then throws a stack overflow exception. It does run in around 64M constant space. While launched under :trace, the space usage grows constantly up to 3.5G, and at this point my system dies, never reaching the exception. I have been able to replicate using a smaller example. {{{ import Data.List loop x = if x == 0 then 0 : loop 1 else 0 : loop 0 main = print (foldl' (+) 0 (loop 1)) }}} Under ghci 6.8.2, 1) :main runs in 30M constant space, 2) :trace main does not. Launching ghci with a heap space limit, e.g. +RTS -M300M, makes 2) eventually crash. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 27 05:51:57 2008 From: trac at galois.com (GHC) Date: Wed Feb 27 05:49:47 2008 Subject: [GHC] #2124: My program compiles with -O1 but compiler panics with -O2 and up In-Reply-To: <046.21f867a8697b0fd12e937ed0b8fc8521@localhost> References: <046.21f867a8697b0fd12e937ed0b8fc8521@localhost> Message-ID: <055.95a7f2ea9c67b983368b93cb9c419cf0@localhost> #2124: My program compiles with -O1 but compiler panics with -O2 and up --------------------------+------------------------------------------------- Reporter: brassel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: minor | Resolution: Keywords: optimization | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | --------------------------+------------------------------------------------- Comment (by brassel): Ha, I succeeded in isolating the bug quite a bit: {{{ module CompileBug where import qualified Data.Map as FM data J = J (String,String) myFromList = FM.fromList myLookup = FM.lookup myMember = FM.member elimConsts = myMember True makeTypeMap ps s = maybe undefined id (myLookup s fm) where fm = myFromList (concatMap typeMapTypeDecl ps) typeMapTypeDecl consDecls = zip (map (\ (J name) -> name) consDecls) undefined }}} Hope this helps! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 27 07:17:34 2008 From: trac at galois.com (GHC) Date: Wed Feb 27 07:15:26 2008 Subject: [GHC] #2125: PAP object entered! In-Reply-To: <047.1ef51b2b4e956858e95c7aa01df1d6ea@localhost> References: <047.1ef51b2b4e956858e95c7aa01df1d6ea@localhost> Message-ID: <056.4e672474905a276b7254d34f5d179827@localhost> #2125: PAP object entered! ----------------------+----------------------------------------------------- Reporter: vladimir | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------+----------------------------------------------------- Comment (by simonmar): Another instance of #1372, by the looks of it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 27 07:18:44 2008 From: trac at galois.com (GHC) Date: Wed Feb 27 07:16:42 2008 Subject: [GHC] #2127: Bad error message for FFI declaration with no -fffi flag In-Reply-To: <042.d91279db4013202517c91f1f3175fec8@localhost> References: <042.d91279db4013202517c91f1f3175fec8@localhost> Message-ID: <051.40d429f82aa98ae2cf32c1e8b4693dc8@localhost> #2127: Bad error message for FFI declaration with no -fffi flag -------------------------------+-------------------------------------------- Reporter: tim | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler (Parser) | Version: 6.8.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Changes (by simonmar): * difficulty: => Unknown * type: bug => feature request * milestone: => _|_ -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 27 08:16:42 2008 From: trac at galois.com (GHC) Date: Wed Feb 27 08:14:32 2008 Subject: [GHC] #2124: My program compiles with -O1 but compiler panics with -O2 and up In-Reply-To: <046.21f867a8697b0fd12e937ed0b8fc8521@localhost> References: <046.21f867a8697b0fd12e937ed0b8fc8521@localhost> Message-ID: <055.df5b7c19bf186a94d0849be6d81c83c7@localhost> #2124: My program compiles with -O1 but compiler panics with -O2 and up --------------------------+------------------------------------------------- Reporter: brassel | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: minor | Resolution: duplicate Keywords: optimization | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | --------------------------+------------------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => duplicate Comment: Thanks, that nailed it. This bug turns out to be a dup of #1988, which happily is already fixed, so I'll close it. (If one of us had thought of searching for 'nameModule' first we'd have spotted this sooner. Sorry.) Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 27 09:43:33 2008 From: trac at galois.com (GHC) Date: Wed Feb 27 09:41:23 2008 Subject: [GHC] #2129: runInteractiveCommand/Process docs don't mention if handles are text or binary Message-ID: <045.fab4515899caecbd52d0aae843491315@localhost> #2129: runInteractiveCommand/Process docs don't mention if handles are text or binary -----------------------+---------------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Component: libraries/process Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: Windows -----------------------+---------------------------------------------------- `runInteractiveCommand` and `runInteractiveProcess` return newly created `Handle`s. The haddock documentation for these actions does not specify if the `Handle`s are opened in text or binary mode. This caused at least one real-world bug where Cabal reads the output of `ghc-pkg describe *`, parsing it by splitting into lines. The standard haskell `lines` function splits on '\n' characters so we ended up with trailing '\r' characters. This was almost certainly because `ghc-pkg` was writing to stdout in text mode but Cabal was reading from the pipe in binary mode, presumably because currently `runInteractiveCommand` uses binary mode. We probably don't want to have two versions of the functions so perhaps the documentation should specify what it does now and mention `hSetBinaryMode` for people who want to use that. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 27 11:37:52 2008 From: trac at galois.com (GHC) Date: Wed Feb 27 11:35:51 2008 Subject: [GHC] #2126: Misleading error message for newtype with no constructors In-Reply-To: <042.76c0e53865b0febc05402345d0a1b7df@localhost> References: <042.76c0e53865b0febc05402345d0a1b7df@localhost> Message-ID: <051.d8bdd8bfa764a7ca2e8a1bded077d2c9@localhost> #2126: Misleading error message for newtype with no constructors -------------------------------------+-------------------------------------- Reporter: tim | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.8.1 Severity: trivial | Resolution: Keywords: | Difficulty: Unknown Testcase: T2126 | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Changes (by simonpj): * testcase: => T2126 * difficulty: => Unknown * type: bug => merge * owner: => igloo Comment: Good point. Fixed by {{{ Wed Feb 27 08:32:02 PST 2008 simonpj@microsoft.com * Fix Trac #2126: re-order tests (easy) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 27 12:29:38 2008 From: trac at galois.com (GHC) Date: Wed Feb 27 12:27:28 2008 Subject: [GHC] #2111: Incorrect arrow rec {} notation crashes in ghci In-Reply-To: <044.65925b3e4836aa227396b3392eadc917@localhost> References: <044.65925b3e4836aa227396b3392eadc917@localhost> Message-ID: <053.38fdbeb963a0072f3828d3d5bf21b245@localhost> #2111: Incorrect arrow rec {} notation crashes in ghci ----------------------+----------------------------------------------------- Reporter: luqui | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: T2111 | Architecture: x86 Os: Linux | ----------------------+----------------------------------------------------- Changes (by simonpj): * testcase: => T2111 * owner: simonpj => igloo * type: bug => merge Comment: Fixed by {{{ Tue Feb 26 17:56:35 GMT 2008 simonpj@microsoft.com * Fix Trac #2111: improve error handling for 'rec' in do-notation }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 27 12:58:38 2008 From: trac at galois.com (GHC) Date: Wed Feb 27 12:56:31 2008 Subject: [GHC] #886: Profiling doesn't work with -threaded In-Reply-To: <045.4eeb420dca9023055216aedeee61b5e7@localhost> References: <045.4eeb420dca9023055216aedeee61b5e7@localhost> Message-ID: <054.350b9c0d8f35bc85892cd95ee301a5f3@localhost> #886: Profiling doesn't work with -threaded ----------------------------+----------------------------------------------- Reporter: Lemmih | Owner: Type: task | Status: new Priority: normal | Milestone: 6.10 branch Component: Runtime System | Version: 6.5 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Architecture: Multiple Os: Multiple | ----------------------------+----------------------------------------------- Comment (by Frederik): OK, well that sounds like a significant chunk of functionality. I guess the benefit of working on non-commercial software is that you don't have to hide the shortcomings of your product. People who are interested to hear that GHC supports profiling are also likely to be interested to know to what extent it supports profiling. The fact that e.g. SMP is excluded is missing from http://haskell.org/ghc/ and http://haskell.org/ghc/docs/latest/html/users_guide/profiling.html, but that is one of the first questions that users who depend on SMP will want to know the answer to. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 27 18:44:48 2008 From: trac at galois.com (GHC) Date: Wed Feb 27 18:42:37 2008 Subject: [GHC] #2130: Mulitple comparisons on Word types produce redundant comparisons Message-ID: <043.bb69d7139f7b8c77fac9419da7252b2c@localhost> #2130: Mulitple comparisons on Word types produce redundant comparisons -----------------------------------------+---------------------------------- Reporter: dons | Owner: Type: run-time performance bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: performance, Word | Testcase: Architecture: Unknown | Os: Multiple -----------------------------------------+---------------------------------- The Ord and Eq instances that are derived for Word types seems to be inefficient (and appeared while writing a ByteString decoder for UTF8, which does a lot of Word8 matching). The following code: {{{ bad :: Word -> Bool bad c | c < 1 = True | c < 2 = True | otherwise = False }}} compiles to the rather horrible: {{{ case GHC.Prim.eqWord# ww_sXC __word 1 of wild2_aSC { GHC.Base.False -> case GHC.Prim.ltWord# ww_sXC __word 1 of wild_B1 { GHC.Base.False -> case GHC.Prim.eqWord# ww_sXC __word 2 of wild21_XUq { GHC.Base.False -> GHC.Prim.ltWord# ww_sXC __word 2; GHC.Base.True -> GHC.Base.False }; GHC.Base.True -> GHC.Base.True }; GHC.Base.True -> case GHC.Prim.eqWord# ww_sXC __word 2 of wild21_XUo { GHC.Base.False -> GHC.Prim.ltWord# ww_sXC __word 2; }}} In particular, notice the (<) on Word becomes a `case eqWord# of case ltWord# of ...` While the equivalent at an Int type, using the hand written Ord/Eq instances in GHC.Base, produces: {{{ M.good = \ (c_ag0 :: GHC.Base.Int) -> case c_ag0 of wild_aRF { GHC.Base.I# x_aRH -> case GHC.Prim.<# x_aRH 1 of wild1_B1 { GHC.Base.False -> GHC.Prim.<# x_aRH 2; GHC.Base.True -> GHC.Base.True } } }}} The poor code only seems to be generated if there's more than 1 comparison against the value. If I manually wrap Word, and write an instance Eq and Ord for it, based on the ones for Int (attached), we get identical code to the Int case: {{{ M.good = \ (c_agn :: M.MyWord) -> case c_agn `cast` ((M.:CoMyWord) :: M.MyWord ~ GHC.Word.Word) of wild_B1 { GHC.Word.W# x_agV -> case GHC.Prim.ltWord# x_agV __word 1 of wild1_X33 { GHC.Base.False -> GHC.Prim.ltWord# x_agV __word 2; GHC.Base.True -> GHC.Base.True } } }}} The Ord and Eq instances for Word seem to be deeply magic: {{{ data Word = W# Word# deriving (Eq, Ord) }}} Are the instances wired in? The solution to this might be to have similar instances of Eq and Ord for Word, as for Int, or to change the built-in deriving. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 27 19:19:39 2008 From: trac at galois.com (GHC) Date: Wed Feb 27 19:17:31 2008 Subject: [GHC] #2130: Mulitple comparisons on Word types produce redundant comparisons In-Reply-To: <043.bb69d7139f7b8c77fac9419da7252b2c@localhost> References: <043.bb69d7139f7b8c77fac9419da7252b2c@localhost> Message-ID: <052.49f51e1f88b189b6c8378b13bd40dd91@localhost> #2130: Mulitple comparisons on Word types produce redundant comparisons -----------------------------------------+---------------------------------- Reporter: dons | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: performance, Word | Testcase: Architecture: Unknown | Os: Multiple -----------------------------------------+---------------------------------- Comment (by dons): The extra comparisons bubble through to the final assembly, as you see here: {{{ good :: Int -> Bool good c | c < 22 = True | c < 42 = True | otherwise = False }}} The good Int yields: {{{ good_info: cmpq $22,7(%rbx) jl .LcgH movl $base_GHCziBase_Bool_closure_tbl,%eax cmpq $42,7(%rbx) setl %cl movzbl %cl,%ecx movq (%rax,%rcx,8),%rbx addq $8,%rbp jmp *(%rbp) .LcgH: movl $base_GHCziBase_True_closure+2,%ebx addq $8,%rbp jmp *(%rbp) }}} While our funky Ords for Word: {{{ bad :: Word -> Bool bad c | c < 22 = True | c < 42 = True | otherwise = False }}} yields: {{{ M_zdwbad_info: cmpq $22,%rsi je .Lcm7 cmpq $22,%rsi jb .Lcmb cmpq $42,%rsi je .Lcmd movl $base_GHCziBase_Bool_closure_tbl,%eax cmpq $42,%rsi setb %cl movzbl %cl,%ecx movq (%rax,%rcx,8),%rbx jmp *(%rbp) .Lcm7: cmpq $42,%rsi je .Lcm9 movl $base_GHCziBase_Bool_closure_tbl,%eax cmpq $42,%rsi setb %cl movzbl %cl,%ecx movq (%rax,%rcx,8),%rbx jmp *(%rbp) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 27 22:40:39 2008 From: trac at galois.com (GHC) Date: Wed Feb 27 22:38:29 2008 Subject: [GHC] #2130: Mulitple comparisons on Word types produce redundant comparisons In-Reply-To: <043.bb69d7139f7b8c77fac9419da7252b2c@localhost> References: <043.bb69d7139f7b8c77fac9419da7252b2c@localhost> Message-ID: <052.a903a1ac4a8ee18131b8a8c2aebe9ead@localhost> #2130: Mulitple comparisons on Word types produce redundant comparisons -----------------------------------------+---------------------------------- Reporter: dons | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: performance, Word | Testcase: Architecture: x86 | Os: Linux -----------------------------------------+---------------------------------- Changes (by morrow): * os: Multiple => Linux * architecture: Unknown => x86 Comment: Here is a duplication of the issue, and a writeup which will hopefully aid in comparing the code generated in various instances. ----------------------------------------------------------------------------- GHC was invoked as follows for the below: {{{ $ ghc -O2 -keep-s-files -fglasgow-exts -c XXX.hs }}} GHC version info: {{{ $ ghc -V The Glorious Glasgow Haskell Compilation System, version 6.9.20080218 }}} ----------------------------------------------------------------------------- The code genereated for this example is basically equivalent to that generated by the Int -> Int example, as is desired. {{{ import GHC.Word (Word(..)) -- for W# import GHC.Prim (ltWord#,int2Word#) choose :: Word -> Int choose (W# c) | c `ltWord#` (int2Word# 0x80#) = 1 | c `ltWord#` (int2Word# 0xc0#) = 2 | otherwise = 3 }}} maps to (obtained with ghc --show-iface): {{{ lvl :: GHC.Base.Int {- HasNoCafRefs Strictness: m Unfolding: (GHC.Base.I# 1) -} lvl1 :: GHC.Base.Int {- HasNoCafRefs Strictness: m Unfolding: (GHC.Base.I# 2) -} lvl2 :: GHC.Base.Int {- HasNoCafRefs Strictness: m Unfolding: (GHC.Base.I# 3) -} 2 choose :: GHC.Word.Word -> GHC.Base.Int {- Arity: 1 HasNoCafRefs Strictness: U(L)m Unfolding: (\ ds :: GHC.Word.Word -> case @ GHC.Base.Int ds of wild { GHC.Word.W# c -> case @ GHC.Base.Int GHC.Prim.ltWord# c __word 128 of wild1 { GHC.Base.False -> case @ GHC.Base.Int GHC.Prim.ltWord# c __word 192 of wild2 { GHC.Base.False -> M.lvl2 GHC.Base.True -> M.lvl1 } GHC.Base.True -> M.lvl } }) -} }}} ----------------------------------------------------------------------------- The code generated for this example is that to which the other two aspire. {{{ choose :: Int -> Int choose c | c < 0x80 = 1 | c < 0xc0 = 2 | otherwise = 3 }}} maps to (obtained with ghc --show-iface): {{{ lvl :: GHC.Base.Int {- HasNoCafRefs Strictness: m Unfolding: (GHC.Base.I# 1) -} lvl1 :: GHC.Base.Int {- HasNoCafRefs Strictness: m Unfolding: (GHC.Base.I# 2) -} lvl2 :: GHC.Base.Int {- HasNoCafRefs Strictness: m Unfolding: (GHC.Base.I# 3) -} choose :: GHC.Base.Int -> GHC.Base.Int {- Arity: 1 HasNoCafRefs Strictness: U(L)m Unfolding: (\ c :: GHC.Base.Int -> case @ GHC.Base.Int c of wild { GHC.Base.I# x -> case @ GHC.Base.Int GHC.Prim.<# x 128 of wild1 { GHC.Base.False -> case @ GHC.Base.Int GHC.Prim.<# x 192 of wild2 { GHC.Base.False -> Int.lvl2 GHC.Base.True -> Int.lvl1 } GHC.Base.True -> Int.lvl } }) -} }}} ----------------------------------------------------------------------------- This is the example of nonoptimal (wrt that of Int -> Int) code generated for the same function but with Word -> Int (and with no explicit unboxing). {{{ import Data.Word (Word) choose :: Word -> Int choose c | c < 0x80 = 1 | c < 0xc0 = 2 | otherwise = 3 }}} maps to (obtained with ghc --show-iface): {{{ $wchoose :: GHC.Prim.Word# -> GHC.Prim.Int# {- Arity: 1 HasNoCafRefs Strictness: L Unfolding: (\ ww :: GHC.Prim.Word# -> case @ GHC.Prim.Int# GHC.Prim.eqWord# ww __word 128 of wild2 { GHC.Base.False -> case @ GHC.Prim.Int# GHC.Prim.ltWord# ww __word 128 of wild { GHC.Base.False -> case @ GHC.Prim.Int# GHC.Prim.eqWord# ww __word 192 of wild21 { GHC.Base.False -> case @ GHC.Prim.Int# GHC.Prim.ltWord# ww __word 192 of wild1 { GHC.Base.False -> 3 GHC.Base.True -> 2 } GHC.Base.True -> 3 } GHC.Base.True -> 1 } GHC.Base.True -> case @ GHC.Prim.Int# GHC.Prim.eqWord# ww __word 192 of wild21 { GHC.Base.False -> case @ GHC.Prim.Int# GHC.Prim.ltWord# ww __word 192 of wild { GHC.Base.False -> 3 GHC.Base.True -> 2 } GHC.Base.True -> 3 } }) -} choose :: GHC.Word.Word -> GHC.Base.Int {- Arity: 1 HasNoCafRefs Strictness: U(L)m Worker: M.$wchoose 1 -} }}} ----------------------------------------------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 28 05:10:57 2008 From: trac at galois.com (GHC) Date: Thu Feb 28 05:08:45 2008 Subject: [GHC] #2131: concprog001(threaded2) occasional failures. Message-ID: <047.345a9b027d64df32bf7e2ae1b9475eb0@localhost> #2131: concprog001(threaded2) occasional failures. -------------------------------+-------------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Runtime System | Version: 6.8.2 Severity: normal | Keywords: Difficulty: Rocket Science | Testcase: concprog001 Architecture: Unknown | Os: Unknown -------------------------------+-------------------------------------------- This one has so far resisted my attempts to debug it. The most common error is "thread blocked indefinitely": I don't know whether it's a bug in the RTS or allowed behaviour for this program, but it only seems to occur on a multiprocessor with `+RTS -N2`, and only in one out of 10 runs or so. Also I've seen * hanging using 100% CPU without apparently making any progress * another type of crash I didn't make a note of at the time. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 28 07:10:28 2008 From: trac at galois.com (GHC) Date: Thu Feb 28 07:08:16 2008 Subject: [GHC] #886: Profiling doesn't work with SMP execution In-Reply-To: <045.4eeb420dca9023055216aedeee61b5e7@localhost> References: <045.4eeb420dca9023055216aedeee61b5e7@localhost> Message-ID: <054.0cdfe8cabcaf8a1d95a79e8d33e5c00f@localhost> #886: Profiling doesn't work with SMP execution ----------------------------+----------------------------------------------- Reporter: Lemmih | Owner: Type: task | Status: new Priority: normal | Milestone: _|_ Component: Runtime System | Version: 6.5 Severity: normal | Resolution: Keywords: | Difficulty: Difficult (1 week) Testcase: | Architecture: Multiple Os: Multiple | ----------------------------+----------------------------------------------- Changes (by simonmar): * difficulty: Moderate (1 day) => Difficult (1 week) * summary: Profiling doesn't work with -threaded => Profiling doesn't work with SMP execution * milestone: 6.10 branch => _|_ Comment: I've now enabled -prof -threaded, it turns out that there weren't any major problems preventing their use together, we were just being conservative. However, it is certainly a lot of work to make profiling work with SMP (+RTS -N2), and I don't think this is a high priority: you can just profile on a single CPU. Profiling parallel performance is another problem altogether (which is certainly on our radar). I've added a note to the profiling section of the user guide to mention that `+RTS -N2` is not supported with profiling. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 28 07:23:43 2008 From: trac at galois.com (GHC) Date: Thu Feb 28 07:21:30 2008 Subject: [GHC] #2132: Optimise nested comparisons Message-ID: <046.ba0b25228872b80f2daed8d0d0f8352f@localhost> #2132: Optimise nested comparisons -----------------------------------------+---------------------------------- Reporter: simonpj | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown -----------------------------------------+---------------------------------- GHC isn't capable of this optimisation: {{{ case (x ># y) of ==> case (x ># y) of True -> ...(x ==# y)... True -> ...False... False -> ... False -> ... }}} That is, knowing that (x>y) we know that the two are not equal. Also, consider this: {{{ case (x ># y) of ==> case (x >=# y) of True -> e True -> e False -> case (x ==# y) of False -> e' True -> e False -> e' }}} Again this needs special knowlege about comparison operators. However, it ''does'' arise. Consider this: {{{ data T = MkT Int deriving( Eq, Ord ) }}} The derived `(>)` operation looks like this: {{{ Foo.$dm> = \ (eta_a8q :: Foo.T) (eta1_a8r :: Foo.T) -> case eta_a8q of wild_B1 { Foo.MkT a1_a60 -> case eta1_a8r of wild1_XO { Foo.MkT b1_a62 -> case a1_a60 of wild2_a9I { GHC.Base.I# x#_a9K -> case b1_a62 of wild11_a9M { GHC.Base.I# y#_a9O -> case GHC.Prim.<# x#_a9K y#_a9O of wild3_a9W { GHC.Base.False -> case GHC.Prim.==# x#_a9K y#_a9O of wild12_a9Z { GHC.Base.False -> GHC.Base.True; GHC.Base.True -> GHC.Base.False }; GHC.Base.True -> GHC.Base.False }}} See also #2130 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 28 07:28:11 2008 From: trac at galois.com (GHC) Date: Thu Feb 28 07:25:59 2008 Subject: [GHC] #2130: Mulitple comparisons on Word types produce redundant comparisons In-Reply-To: <043.bb69d7139f7b8c77fac9419da7252b2c@localhost> References: <043.bb69d7139f7b8c77fac9419da7252b2c@localhost> Message-ID: <052.d07e64aa1cdebec615c85831d0677c8f@localhost> #2130: Mulitple comparisons on Word types produce redundant comparisons -------------------------------+-------------------------------------------- Reporter: dons | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: performance, Word | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | -------------------------------+-------------------------------------------- Changes (by simonpj): * owner: => igloo * difficulty: => Unknown * type: run-time performance bug => merge Comment: Excellent point, thanks. It's actually not at all easy to optimise the generation of `Ord` instances perfectly; see `Note [Comparision of primitive types]` in `TcGenDeriv.hs`. But I have improved matters a bit, by making a special case for data types that are wrappers for primitive types. {{{ Thu Feb 28 12:11:06 GMT 2008 simonpj@microsoft.com * Fix Trac #2130: improve derived Ord for primmitive types }}} That still leaves room for improvement: I've opened a new ticket for that #2132. But it does completely fix the `Word` type and its friends. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 28 11:04:59 2008 From: trac at galois.com (GHC) Date: Thu Feb 28 11:03:41 2008 Subject: [GHC] #783: performance problem compiling large file In-Reply-To: <044.a7a580fed8a85952633cd84570dae070@localhost> References: <044.a7a580fed8a85952633cd84570dae070@localhost> Message-ID: <053.b52f4de1b526fab353a2b9a4003576ae@localhost> #783: performance problem compiling large file ------------------------------------------+--------------------------------- Reporter: guest | Owner: Type: compile-time performance bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.4.2 Severity: normal | Resolution: Keywords: performance | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ------------------------------------------+--------------------------------- Comment (by igloo): With a slightly simpler variant of this: {{{ module Foo where foo :: Double -> Int foo x | x == 1 = 1 foo x | x == 2 = 2 ... foo x | x == 500 = 500 }}} compiling with {{{ ghc -c large.hs -fforce-recomp +RTS -p -h }}} one problem is that we get something like {{{ lit1 = ... lit2 = ... ... foo = case ... of False -> case ... of False -> ... True -> lit2 True -> lit1 }}} Each of the case expressions has an SRT for its alternatives. The outer one has all 500 lit's, the one inside 499, and so on, so we have quadratic space usage. The SRTs are `SRTEntries cafs`, where `cafs` is an `IdSet` (which is ultimately a `UniqFM`), so no sharing is possible. In this particular case using `-O` "fixes" it as `==` etc get specialised and the lits disappear, but (a) this won't be the case in general and (b) I don't think you should need to use `-O` to get reasonable compiler space usage. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 28 11:11:02 2008 From: trac at galois.com (GHC) Date: Thu Feb 28 11:08:56 2008 Subject: [GHC] #1589: Process creation and communication doesn't scale linearly In-Reply-To: <044.d2274ee12c731d087b3c981d4c934bbd@localhost> References: <044.d2274ee12c731d087b3c981d4c934bbd@localhost> Message-ID: <053.c26961430babd2f78795bef1690132bb@localhost> #1589: Process creation and communication doesn't scale linearly ----------------------------+----------------------------------------------- Reporter: guest | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Runtime System | Version: 6.7 Severity: minor | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Architecture: Multiple Os: Multiple | ----------------------------+----------------------------------------------- Comment (by simonmar): Just for your enjoyment, here is how my current development tree does on this benchmark: {{{ ./threads1589 1000000 0 +RTS -sstderr -k200 274,891,208 bytes allocated in the heap 788,755,388 bytes copied during GC 176,005,076 bytes maximum residency (8 sample(s)) 31,957,908 bytes maximum slop 387 MB total memory in use (3 MB lost due to fragmentation) Generation 0: 518 collections, 0 parallel, 1.83s, 1.84s elapsed Generation 1: 8 collections, 0 parallel, 1.36s, 1.76s elapsed INIT time 0.00s ( 0.00s elapsed) MUT time 0.74s ( 0.76s elapsed) GC time 3.19s ( 3.60s elapsed) EXIT time 0.25s ( 0.42s elapsed) Total time 4.18s ( 4.61s elapsed) %GC time 76.4% (78.1% elapsed) Alloc rate 278,209,693 bytes per MUT second Productivity 23.6% of total user, 21.4% of total elapsed }}} 4.6us per thread, and it scales just slightly worse than linearly until my laptop runs out of memory. The test is doing a bit more than just creating threads, it passes a single message along the chain of threads after creating them all, which is why it needs linear heap space and hence won't scale completely linearly. It'll be a while until I commit this as it's on top of a ton of other stuff I have to get committed, but I'm getting there. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 28 13:26:34 2008 From: trac at galois.com (GHC) Date: Thu Feb 28 13:24:23 2008 Subject: [GHC] #955: more object-code blow-up in ghc-6.6 vs. ghc-6.4.2 (both with optimization) In-Reply-To: <052.784670e095eb0d591995e903dae303b2@localhost> References: <052.784670e095eb0d591995e903dae303b2@localhost> Message-ID: <061.5c15d4ec5806706da58ee76a7964d4c3@localhost> #955: more object-code blow-up in ghc-6.6 vs. ghc-6.4.2 (both with optimization) --------------------------------------+------------------------------------- Reporter: maeder@tzi.de | Owner: Type: run-time performance bug | Status: new Priority: high | Milestone: 6.8.3 Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: object-code blow-up | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | --------------------------------------+------------------------------------- Comment (by igloo): Christian, Can you please tell me where I can get the other modules, e.g. SourceNames, to reproduce this? Thanks -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 29 04:16:23 2008 From: trac at galois.com (GHC) Date: Fri Feb 29 04:14:19 2008 Subject: [GHC] #955: more object-code blow-up in ghc-6.6 vs. ghc-6.4.2 (both with optimization) In-Reply-To: <052.784670e095eb0d591995e903dae303b2@localhost> References: <052.784670e095eb0d591995e903dae303b2@localhost> Message-ID: <061.aaeb66abb062733c8ae936869de8189d@localhost> #955: more object-code blow-up in ghc-6.6 vs. ghc-6.4.2 (both with optimization) --------------------------------------+------------------------------------- Reporter: maeder@tzi.de | Owner: Type: run-time performance bug | Status: new Priority: high | Milestone: 6.8.3 Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: object-code blow-up | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | --------------------------------------+------------------------------------- Comment (by maeder): `SourceNames` comes from programatica. It should be sufficient to check out: {{{ cvs -d :pserver:anoncvs@cvs.haskell.org:/cvs co -P programatica/tools/base cvs -d :pserver:anoncvs@cvs.haskell.org:/cvs co -P programatica/tools/property }}} I'll check if the attached atc.2.tgz behaves as described for ghc-6.8.2, too. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 29 04:49:52 2008 From: trac at galois.com (GHC) Date: Fri Feb 29 04:47:46 2008 Subject: [GHC] #955: more object-code blow-up in ghc-6.6 vs. ghc-6.4.2 (both with optimization) In-Reply-To: <052.784670e095eb0d591995e903dae303b2@localhost> References: <052.784670e095eb0d591995e903dae303b2@localhost> Message-ID: <061.f9b0e7d7b64c645c95efe2cc6aefb255@localhost> #955: more object-code blow-up in ghc-6.6 vs. ghc-6.4.2 (both with optimization) --------------------------------------+------------------------------------- Reporter: maeder@tzi.de | Owner: Type: run-time performance bug | Status: new Priority: high | Milestone: 6.8.3 Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: object-code blow-up | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | --------------------------------------+------------------------------------- Comment (by maeder): It compiles fine for me (110 files by calling "make") with ghc-6.8.2 and the object code sizes are much better than for ghc-6.6.1! So you may close this ticket. ghc-6.6.1 {{{ 340K ATC.hi 88K ATC.hs 1.8M ATC.o 12K ATC2.hi 16K ATC2.hs 3.5M ATC2.o 8.0M ATC3 8.0K ATC3.hi 4.0K ATC3.hs 4.0K ATC3.o }}} ghc-6.8.2 {{{ maeder@leibniz:/local/maeder/atc> ls -sh1 total 7.1M 324K ATC.hi 88K ATC.hs 968K ATC.o 12K ATC2.hi 16K ATC2.hs 896K ATC2.o 4.8M ATC3 8.0K ATC3.hi 4.0K ATC3.hs 4.0K ATC3.o 4.0K Common 4.0K Makefile 4.0K Makefile~ 12K atc.2.tgz 4.0K programatica }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 29 04:59:29 2008 From: trac at galois.com (GHC) Date: Fri Feb 29 04:57:22 2008 Subject: [GHC] #955: more object-code blow-up in ghc-6.6 vs. ghc-6.4.2 (both with optimization) In-Reply-To: <052.784670e095eb0d591995e903dae303b2@localhost> References: <052.784670e095eb0d591995e903dae303b2@localhost> Message-ID: <061.1cacbc3f2b9a7b55e6289b7fa2acb59b@localhost> #955: more object-code blow-up in ghc-6.6 vs. ghc-6.4.2 (both with optimization) --------------------------------------+------------------------------------- Reporter: maeder@tzi.de | Owner: Type: run-time performance bug | Status: new Priority: high | Milestone: 6.8.3 Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: object-code blow-up | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | --------------------------------------+------------------------------------- Comment (by maeder): Even after removing the first line in ATC2.hs, `{-# OPTIONS -O0 -fmax- simplifier-iterations2 #-}`, the code only increases lightly. {{{ maeder@leibniz:/local/maeder/atc> ls -sh1 total 7.8M 324K ATC.hi 88K ATC.hs 968K ATC.o 124K ATC2.hi 16K ATC2.hs 16K ATC2.hs~ 1.3M ATC2.o 5.1M ATC3 8.0K ATC3.hi 4.0K ATC3.hs 4.0K ATC3.o 4.0K Common 4.0K Makefile 4.0K Makefile~ 12K atc.2.tgz 4.0K programatica }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 29 09:24:50 2008 From: trac at galois.com (GHC) Date: Fri Feb 29 09:22:46 2008 Subject: [GHC] #955: more object-code blow-up in ghc-6.6 vs. ghc-6.4.2 (both with optimization) In-Reply-To: <052.784670e095eb0d591995e903dae303b2@localhost> References: <052.784670e095eb0d591995e903dae303b2@localhost> Message-ID: <061.0d1e7accb56aba7e909818f345af65df@localhost> #955: more object-code blow-up in ghc-6.6 vs. ghc-6.4.2 (both with optimization) --------------------------------------+------------------------------------- Reporter: maeder@tzi.de | Owner: Type: run-time performance bug | Status: closed Priority: high | Milestone: 6.8.3 Component: Compiler | Version: 6.6 Severity: normal | Resolution: fixed Keywords: object-code blow-up | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | --------------------------------------+------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: OK, I'm closing this then. Please reopen if you think it's not fixed after all. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler