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.