From trac at galois.com Sat Nov 1 15:48:52 2008 From: trac at galois.com (GHC) Date: Sat Nov 1 15:43:56 2008 Subject: [GHC] #2120: Arrays allow out-of-bounds indexes In-Reply-To: <046.df9dbe29ac2a6f0cde1841f7056aebbe@localhost> References: <046.df9dbe29ac2a6f0cde1841f7056aebbe@localhost> Message-ID: <055.b74860db2a7cc3c946d89a570a28400d@localhost> #2120: Arrays allow out-of-bounds indexes -------------------------------+-------------------------------------------- Reporter: amthrax | Owner: Type: bug | Status: new Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | -------------------------------+-------------------------------------------- Changes (by guest): * cc: ghc@henning-thielemann.de (added) Comment: This is not my Haskell! Checks must be done completely by default. It should be possible however to turn them off by a compiler switch. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 2 05:22:36 2008 From: trac at galois.com (GHC) Date: Sun Nov 2 05:18:06 2008 Subject: [GHC] #2724: foreign functions called from optimized Haskell code receive non-empty fpu stack In-Reply-To: <044.2d874f0fab562627c6bb887ff848f8fd@localhost> References: <044.2d874f0fab562627c6bb887ff848f8fd@localhost> Message-ID: <053.f5d849bdb9255019c7d56bbea10570bc@localhost> #2724: foreign functions called from optimized Haskell code receive non-empty fpu stack ------------------------------+--------------------------------------------- Reporter: aruiz | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler (NCG) | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by morrow): * cc: mjm2002@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 2 10:55:58 2008 From: trac at galois.com (GHC) Date: Sun Nov 2 10:50:57 2008 Subject: [GHC] #2735: ghc panic with Haskell 98 program (applyTypeToArgs?) Message-ID: <044.c907b2895ea8abdf5851e6c2e3e6eb80@localhost> #2735: ghc panic with Haskell 98 program (applyTypeToArgs?) ---------------------------------+------------------------------------------ Reporter: int-e | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.11 | Severity: normal Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ This code, {{{ module Bug where data S = S { s1 :: (), s2 :: () } f s = s { s1 = (), s2 = s1 s } }}} crashes ghc: {{{ ghc: panic! (the 'impossible' happened) (GHC version 6.11.20081031 for i386-unknown-linux): applyTypeToArgs ghc-prim:GHC.Unit.(){(w) v 71} [gid] wild{v sfY} [lid] ghc-prim:GHC.Unit.(){(w) tc 40} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} (Example trimmed down from a compile error in language-c. ghc 6.10 is not affected.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 3 01:39:12 2008 From: trac at galois.com (GHC) Date: Mon Nov 3 01:34:10 2008 Subject: [GHC] #2736: Add bool to Data.Bool Message-ID: <044.43d5c08c7d76644c4804eee606da70ae@localhost> #2736: Add bool to Data.Bool ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: task | Status: new Priority: normal | Component: libraries/base Version: | Severity: minor Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ The function either is in Data.Either and maybe is in Data.Maybe. The function if' is a referenced function in the point-free module, but it doesn't exist, and if is a keyword, not a function. Since Data.Bool is a library module, and it fits the form of the two modules mentioned earlier, it should have a function bool. Its exact form may need more discussion, but in keeping with the other two, I propose: bool :: a -> a -> Bool -> a bool false true False = false bool false true True = true (proposed by BMeph, 2 November 2008) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 3 01:39:47 2008 From: trac at galois.com (GHC) Date: Mon Nov 3 01:34:44 2008 Subject: [GHC] #2736: Add bool to Data.Bool In-Reply-To: <044.43d5c08c7d76644c4804eee606da70ae@localhost> References: <044.43d5c08c7d76644c4804eee606da70ae@localhost> Message-ID: <053.e48ba1e24823e17d18dbe3797fe4abd2@localhost> #2736: Add bool to Data.Bool ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: libraries/base | Version: Severity: minor | Resolution: Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ Changes (by guest): * type: task => proposal -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 3 03:25:24 2008 From: trac at galois.com (GHC) Date: Mon Nov 3 03:20:26 2008 Subject: [GHC] #2658: Extreme memory usage (probably type functions) In-Reply-To: <044.e9d0778983f3efa5257edab0ca1c5901@localhost> References: <044.e9d0778983f3efa5257edab0ca1c5901@localhost> Message-ID: <053.07de673930e87fa4fb88572299f6bb9d@localhost> #2658: Extreme memory usage (probably type functions) -------------------------------------+-------------------------------------- Reporter: guest | Owner: chak Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler (Type checker) | Version: 6.9 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | -------------------------------------+-------------------------------------- Changes (by simonpj): * owner: => chak -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 3 03:27:11 2008 From: trac at galois.com (GHC) Date: Mon Nov 3 03:22:08 2008 Subject: [GHC] #2683: Boxy-type ASSERT failure in 6.10: panic in xmonad-contrib In-Reply-To: <043.cf6c9356908d84d15cb72785d970ada9@localhost> References: <043.cf6c9356908d84d15cb72785d970ada9@localhost> Message-ID: <052.04b9f1f66d6ce1f12d7db25204a13b8c@localhost> #2683: Boxy-type ASSERT failure in 6.10: panic in xmonad-contrib ------------------------------+--------------------------------------------- Reporter: dons | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by simonpj): * owner: => simonpj * severity: critical => normal * milestone: 6.10.1 => 6.12 branch Comment: OK changing to 6.12; I think 6.10 is fine. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 3 03:29:09 2008 From: trac at galois.com (GHC) Date: Mon Nov 3 03:24:09 2008 Subject: [GHC] #2715: Equality constraint in superclass causes panic: applyTypeToArgs In-Reply-To: <047.797aaec011bad118fea0580e1c0ce283@localhost> References: <047.797aaec011bad118fea0580e1c0ce283@localhost> Message-ID: <056.e6cd7535dae6bad75070caf65b97cb13@localhost> #2715: Equality constraint in superclass causes panic: applyTypeToArgs -------------------------------------+-------------------------------------- Reporter: rodprice | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler (Type checker) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | -------------------------------------+-------------------------------------- Changes (by simonpj): * owner: => chak -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 3 04:26:52 2008 From: trac at galois.com (GHC) Date: Mon Nov 3 04:21:51 2008 Subject: [GHC] #2735: ghc panic with Haskell 98 program (applyTypeToArgs?) In-Reply-To: <044.c907b2895ea8abdf5851e6c2e3e6eb80@localhost> References: <044.c907b2895ea8abdf5851e6c2e3e6eb80@localhost> Message-ID: <053.26bd7672bc07d170bccb5351c5d9325f@localhost> #2735: ghc panic with Haskell 98 program (applyTypeToArgs?) ------------------------------+--------------------------------------------- Reporter: int-e | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by simonpj): * owner: => simonpj * difficulty: => Unknown Comment: Great report. Am fixing. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 3 06:12:50 2008 From: trac at galois.com (GHC) Date: Mon Nov 3 06:07:48 2008 Subject: [GHC] #2735: ghc panic with Haskell 98 program (applyTypeToArgs?) In-Reply-To: <044.c907b2895ea8abdf5851e6c2e3e6eb80@localhost> References: <044.c907b2895ea8abdf5851e6c2e3e6eb80@localhost> Message-ID: <053.0b7b6cba98a75c4c0d35b3c01cc94a89@localhost> #2735: ghc panic with Haskell 98 program (applyTypeToArgs?) ------------------------------+--------------------------------------------- Reporter: int-e | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: Fixed by {{{ Mon Nov 3 11:08:19 GMT 2008 simonpj@microsoft.com * Fix desugaring of record update (fixes Trac #2735) }}} Thanks for the report. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 3 07:17:07 2008 From: trac at galois.com (GHC) Date: Mon Nov 3 07:12:04 2008 Subject: [GHC] #2699: broken pipe errors are too noisy In-Reply-To: <044.4d8cfcf130a4f232512c2899cde1f85e@localhost> References: <044.4d8cfcf130a4f232512c2899cde1f85e@localhost> Message-ID: <053.91d9abce72b7658144162bda15bc948d@localhost> #2699: broken pipe errors are too noisy ------------------------------+--------------------------------------------- Reporter: int-e | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by simonmar): I wouldn't object to adding an errno field to `IOError`, it's an abstract type anyway so shouldn't break any code that uses it via the public API. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 3 15:14:25 2008 From: trac at galois.com (GHC) Date: Mon Nov 3 15:09:24 2008 Subject: [GHC] #2737: add :tracelocal to ghci debugger to trace only the expressions in a given function Message-ID: <046.6f550a6976a51e80c9bdb4b574c0fab8@localhost> #2737: add :tracelocal to ghci debugger to trace only the expressions in a given function ---------------------------------+------------------------------------------ Reporter: phercek | Owner: Type: feature request | Status: new Priority: normal | Component: GHCi Version: 6.8.3 | Severity: normal Keywords: debugger | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ As there is :steplocal, there should be also :tracelocal. It would keep history of evaluations within a given function. When an acces to a variable is needed it would be searched first in the selected expression and if not found the search would continue in the expressions from the trace history. If the value used would originate from the trace history it should be indicated so in the output: at the end or beginning of the output there would be the list of identifiers which values were taken from trace history. This would avoid the tedious task of searching the trace history manually and moreover it would limit the history to the interesting parts (so hopefully the current depth of 50 would be enough). :tracelocal should take an optional argument which defines the function to trace. Similar options as for a breakpoint specification (:break command) would be fine. It might be usefull to associate the tracelocal trace with breakpoint and having an option to set it on for given breakpoint (in such a case it would be possible to add tracelocal flag for a breakpoint). Note that the results from the trace history may not be from the expected scope but the same problem is with "printf debugging" which is an efficient way to debug Haskell programs now too. The list of identifiers which were taken from trace history (while evaluating an interactively entered expression) should be provided because of the posibility to get values from an unexpected scope. This should be a cheap way to make ghci debugger better than just plain "printf debugging", especially when used together with scriptable breakpoints (where one could script each breakpoint individually - not only all of them at once with :set stop). The best solution from user point of view would be just to provide access to all the variables which are in scope in a given expression (not just the free ones) but it is believed that it would introduce too much overhead. Here is the url of the thread head where this proposal started to evolve: http://www.haskell.org/pipermail/glasgow-haskell- users/2008-October/015840.html -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 3 16:10:21 2008 From: trac at galois.com (GHC) Date: Mon Nov 3 16:05:17 2008 Subject: [GHC] #2737: add :tracelocal to ghci debugger to trace only the expressions in a given function In-Reply-To: <046.6f550a6976a51e80c9bdb4b574c0fab8@localhost> References: <046.6f550a6976a51e80c9bdb4b574c0fab8@localhost> Message-ID: <055.5eb45cca3429fc3e5a25d8ef999f8ff6@localhost> #2737: add :tracelocal to ghci debugger to trace only the expressions in a given function ---------------------------------+------------------------------------------ Reporter: phercek | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.8.3 Severity: normal | Resolution: Keywords: debugger | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ Comment (by phercek): Actually, I see now, that it is possible to script individual breakpoints with ":set stop N " but it is not indicated so in the output of :help command. The format in the :help output is ":set stop " but it should be ":set stop [N] ". I still miss a minor feature: a switch to disable any default output when a breakpoint with a custom script is hit (so that only the custom script output (if any) is visible). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 3 19:35:14 2008 From: trac at galois.com (GHC) Date: Mon Nov 3 19:30:13 2008 Subject: [GHC] #2715: Equality constraint in superclass not supported In-Reply-To: <047.797aaec011bad118fea0580e1c0ce283@localhost> References: <047.797aaec011bad118fea0580e1c0ce283@localhost> Message-ID: <056.f933d29d0faea11fd711f2bc522fac8d@localhost> #2715: Equality constraint in superclass not supported -------------------------------------+-------------------------------------- Reporter: rodprice | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler (Type checker) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | -------------------------------------+-------------------------------------- Changes (by chak): * summary: Equality constraint in superclass causes panic: applyTypeToArgs => Equality constraint in superclass not supported Comment: There is no panic anymore. Programs with super class equalities are outright rejected with an error message explaining that superclass equalities are a currently unsupported feature. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 3 22:48:32 2008 From: trac at galois.com (GHC) Date: Mon Nov 3 22:43:28 2008 Subject: [GHC] #2738: Regression in type checking of sections in records Message-ID: <043.6e10d6300c4c2400615bca3697f92328@localhost> #2738: Regression in type checking of sections in records ---------------------------------+------------------------------------------ Reporter: dons | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 6.10.1 | Severity: normal Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ Looks like a GHC 6.10 regression. The following code, from xmonad-contrib, fails with an error under 6.10, but not under other compilers, {{{ [ 74 of 138] Compiling XMonad.Hooks.UrgencyHook ( XMonad/Hooks/UrgencyHook.hs, dist/build/XMonad/Hooks/UrgencyHook.o ) XMonad/Hooks/UrgencyHook.hs:424:48: The section `5 `seconds`' takes one argument, but its type `Int' has none In the `duration' field of a record In the expression: DzenUrgencyHook {duration = (5 `seconds`), args = []} In the definition of `dzenUrgencyHook': dzenUrgencyHook = DzenUrgencyHook {duration = (5 `seconds`), args = []} }}} The relevant code is: {{{ -- | Flashes when a window requests your attention and you can't see it. -- Defaults to a duration of five seconds, and no extra args to dzen. -- See 'DzenUrgencyHook'. dzenUrgencyHook :: DzenUrgencyHook dzenUrgencyHook = DzenUrgencyHook { duration = (5 `seconds`), args = [] } }}} Which looks harmless enough. In fact, rearranging the section let's it pass type checking: {{{ dzenUrgencyHook = DzenUrgencyHook { duration = seconds 5, args = [] } }}} The relevant code can be found here: http://code.haskell.org/XMonadContrib/XMonad/Hooks/UrgencyHook.hs, line 424. To reproduce, assuming ghc 6.10 is installed, and X11, {{{ $ cd XMonadContrib $ cabal install }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 4 04:58:17 2008 From: trac at galois.com (GHC) Date: Tue Nov 4 04:53:28 2008 Subject: [GHC] #1876: Complete shared library support In-Reply-To: <047.2ab772cd4150dcd51ba47e309570e649@localhost> References: <047.2ab772cd4150dcd51ba47e309570e649@localhost> Message-ID: <056.33247c029165faae53f14a272672591d@localhost> #1876: Complete shared library support ------------------------------+--------------------------------------------- Reporter: simonmar | Owner: clemens Type: task | Status: assigned Priority: high | Milestone: 6.10 branch Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Difficult (1 week) Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by simonmar): Some issues to resolve before we can deploy shared libraries. Some of these are probable just questions to be answered, but hint at documentation that we need to write. * Do GHC distributions contain both shared and static libraries? * Will Cabal build both shared and static libraries by default? * Can a module built with `-dynamic` link against static libraries, if the dynamic versions are not available? * If modules are compiled with `-fPIC` and/or `-dynamic`, can they then be linked statically? On which platforms? If not, what goes wrong if you try this? * On x86_64 we should have `-dynamic` turned on by default, for loading modules into GHCi, otherwise data references to shared libraries will only have 32-bit relocations and thus will break. * Using `-static` at compile-time on x86_64 should therefore come with a warning that the modules cannot be loaded into GHCi. Can we detect this and report an error in GHCi? * What is the performance overhead of turning on `-dynamic` by default on x86_64? * What is the performance overhead (and code-size overhead) of shared libraries in general? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 4 06:27:32 2008 From: trac at galois.com (GHC) Date: Tue Nov 4 06:22:49 2008 Subject: [GHC] #1876: Complete shared library support In-Reply-To: <047.2ab772cd4150dcd51ba47e309570e649@localhost> References: <047.2ab772cd4150dcd51ba47e309570e649@localhost> Message-ID: <056.988248c88e9274a065e89b10edfe8c6b@localhost> #1876: Complete shared library support ------------------------------+--------------------------------------------- Reporter: simonmar | Owner: clemens Type: task | Status: assigned Priority: high | Milestone: 6.10 branch Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Difficult (1 week) Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by spl): * cc: leather@cs.uu.nl (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 4 06:52:11 2008 From: trac at galois.com (GHC) Date: Tue Nov 4 06:47:05 2008 Subject: [GHC] #2739: GHC API crashes on template haskell splices Message-ID: <044.3bac7d34665c04ceca674c8a12436d56@localhost> #2739: GHC API crashes on template haskell splices ---------------------------------+------------------------------------------ Reporter: waern | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: major Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ The GHC API crashes when type checking these two modules: {{{TH.hs}}}: {{{ {-# LANGUAGE TemplateHaskell #-} module TH where import Language.Haskell.TH decl = [d| f x = x] }}} {{{TH2.hs}}}: {{{ {-# LANGUAGE TemplateHaskell #-} module TH2 where import TH $( decl ) }}} The crash happens in {{{HscMain.compileExpr}}}, when compiling and linking the spliced-in code. The crash is due to a {{{fromJust: Nothing}}}. I don't have the error message at hand. It would be nice if this could be fixed in 6.10.* since it makes Haddock crash when processing several packages on Hackage. I will add both {{{TH.hs}}} and {{{TH2.hs}}} to the test suite in the {{{code.haskell.org/haddock}}} repository later. (I thought I had done this, but I apparently forgot to add TH.hs). You can the use {{{test/runtests.hs}}} to invoke the crash. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 4 07:05:23 2008 From: trac at galois.com (GHC) Date: Tue Nov 4 07:00:16 2008 Subject: [GHC] #2738: Regression in type checking of sections in records In-Reply-To: <043.6e10d6300c4c2400615bca3697f92328@localhost> References: <043.6e10d6300c4c2400615bca3697f92328@localhost> Message-ID: <052.34d5c47492724b07a034b2025039830c@localhost> #2738: Regression in type checking of sections in records -------------------------------------+-------------------------------------- Reporter: dons | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.10.1 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | -------------------------------------+-------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: Thanks for the report. I haven't tried the full program, but this: {{{ data DzenUrgencyHook = DzenUrgencyHook { duration :: Int, args :: [String] } dzenUrgencyHook :: DzenUrgencyHook dzenUrgencyHook = DzenUrgencyHook { duration = (5 `seconds`), args = [] } seconds :: Int -> Int seconds = id }}} works in 6.8.2, and also works in 6.10 if you pass `-XPostfixOperators`. It was a bug in 6.8 that the non-Haskell98 extension to sections was accepted without a language extension being turned on, so I suspect that's what the problem is. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 4 08:38:53 2008 From: trac at galois.com (GHC) Date: Tue Nov 4 08:33:48 2008 Subject: [GHC] #2740: free variable not available in debugger, field selection function not available in debugger Message-ID: <046.05e1293bbffbc0807e6d01b8f2d22646@localhost> #2740: free variable not available in debugger, field selection function not available in debugger -------------------------+-------------------------------------------------- Reporter: phercek | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.8.2 | Severity: normal Keywords: debugger | Testcase: Architecture: x86 | Os: Linux -------------------------+-------------------------------------------------- The attached test shows the bugs. Unpack and check the ghci_log.html file to see how to reproduce them. Stderr is in red, selected expression is underlined. Looks like these error messages should not be there: Not in scope: `mSnd' Not in scope: `a' -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 4 09:44:10 2008 From: trac at galois.com (GHC) Date: Tue Nov 4 09:39:04 2008 Subject: [GHC] #2737: add :tracelocal to ghci debugger to trace only the expressions in a given function In-Reply-To: <046.6f550a6976a51e80c9bdb4b574c0fab8@localhost> References: <046.6f550a6976a51e80c9bdb4b574c0fab8@localhost> Message-ID: <055.98a7d4315a89043a2866593047b5ca85@localhost> #2737: add :tracelocal to ghci debugger to trace only the expressions in a given function ---------------------------------+------------------------------------------ Reporter: phercek | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.8.3 Severity: normal | Resolution: Keywords: debugger | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ Changes (by mnislaih): * cc: mnislaih@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 4 09:51:55 2008 From: trac at galois.com (GHC) Date: Tue Nov 4 09:46:52 2008 Subject: [GHC] #2722: < when compiling with -O option with ghc-6.10.0.20081019 In-Reply-To: <042.92b72b67c0e471e2bc1e2ec20b93b90f@localhost> References: <042.92b72b67c0e471e2bc1e2ec20b93b90f@localhost> Message-ID: <051.1968af44be58b7cdb135605e2f34129c@localhost> #2722: < when compiling with -O option with ghc-6.10.0.20081019 -------------------------------+-------------------------------------------- Reporter: uwe | Owner: Type: bug | Status: closed Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: arrows | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | -------------------------------+-------------------------------------------- Changes (by ross): * status: new => closed * resolution: => fixed Comment: It never occurred to me before that using a valid equation as a rule could change the semantics of a recursive definition, but it's obvious in retrospect. So with the Category split, this rule has to go, and I've pushed a patch to delete it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 4 16:54:14 2008 From: trac at galois.com (GHC) Date: Tue Nov 4 16:49:06 2008 Subject: [GHC] #2741: Delete key not working in GHCi Message-ID: <044.515a111ead67730965832db1290b176e@localhost> #2741: Delete key not working in GHCi -----------------------+---------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.10.1 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: Linux -----------------------+---------------------------------------------------- In GHCi 6.10.1, on Ubuntu with libedit 2.11, pressing the delete key produces a beep and inserts a tilde into the line rather than deleting a character. http://bugs.mysql.com/bug.php?id=294 is essentially the same problem, but in MySQL. It seems they fixed it by reverting to using libreadline. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 4 17:09:21 2008 From: trac at galois.com (GHC) Date: Tue Nov 4 17:04:14 2008 Subject: [GHC] #2742: The -> in ViewPatterns binds more weakly than infix data constructors. Message-ID: <044.60b13b19392ff3d7bf14c8ffe9299245@localhost> #2742: The -> in ViewPatterns binds more weakly than infix data constructors. ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ The following code, essentially taken from the ViewPatterns page on the wiki doesn't seem to parse correctly. {{{ mymap f [] = [] mymap f (x : mymap f -> xs) = f x : xs }}} However, this does: {{{ mymap f [] = [] mymap f (x : (mymap f -> xs)) = f x : xs }}} (though it triggers bug #2395 about overlapping patterns) It would seem nicer to make the view pattern arrow bind ''tighter'' than any infix data constructors. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 4 17:09:37 2008 From: trac at galois.com (GHC) Date: Tue Nov 4 17:04:32 2008 Subject: [GHC] #2742: The -> in ViewPatterns binds more weakly than infix data constructors. In-Reply-To: <044.60b13b19392ff3d7bf14c8ffe9299245@localhost> References: <044.60b13b19392ff3d7bf14c8ffe9299245@localhost> Message-ID: <053.7117c0bbc1201563675ed0286be6b303@localhost> #2742: The -> in ViewPatterns binds more weakly than infix data constructors. ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ Changes (by guest): * cc: cgibbard@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 4 18:06:59 2008 From: trac at galois.com (GHC) Date: Tue Nov 4 18:01:52 2008 Subject: [GHC] #2743: GHC 6.10.1 Win32 release is unusable Message-ID: <044.5c7925a0112349b6ff4c617bfd276240@localhost> #2743: GHC 6.10.1 Win32 release is unusable ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: blocker Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ 1. Running ghc in cmd.exe shell delivers (in my config): ghc.EXE: panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-unknown-mingw32): can't decompose ghc.exe path: "G:\\Progs\\ghc-6.10.1\\Bin\\ghc.exe" 2. runghc.exe/runhaskell.exe hangs. 3. $topdir\include\mingw\c++ contains subtrees "3.4.5" and "3.4.2". "3.4.2" seems completely irrelevant here. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 5 02:36:20 2008 From: trac at galois.com (GHC) Date: Wed Nov 5 02:31:13 2008 Subject: [GHC] #2744: Missing requirement check for hsc2hs Message-ID: <045.22de1b93d87ec567af1e55ce56c09fd8@localhost> #2744: Missing requirement check for hsc2hs -----------------------+---------------------------------------------------- Reporter: jputcu | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.10.1 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: Linux -----------------------+---------------------------------------------------- Using ghc-6.6.1 to build ghc-6.10.1 fails because it's missing the hsc2hs tools required by the hpc package. Installing the cabal hsc2hs-0.67.20061107 package fixed that problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 5 04:26:07 2008 From: trac at galois.com (GHC) Date: Wed Nov 5 04:21:00 2008 Subject: [GHC] #2745: ghc -shared broken Message-ID: <047.4659d608cdcae10c404611f42e7f8e53@localhost> #2745: ghc -shared broken ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown/Multiple | Os: Windows ---------------------------------+------------------------------------------ Lennart reports that `ghc -shared` is broken: {{{ $ cat Foo.hs {-# LANGUAGE ForeignFunctionInterface #-} module Foo where f :: Int -> Int f x = x+1 foreign export ccall f :: Int -> Int $ ghc -shared Foo.hs Foo.o:fake:(.text+0x21): undefined reference to `stg_INTLIKE_closure' Foo.o:fake:(.text+0x28): undefined reference to `stg_ap_pp_info' Foo_stub.o:Foo_stub.c:(.text+0x9): undefined reference to `rts_lock' Foo_stub.o:Foo_stub.c:(.text+0x1a): undefined reference to `rts_mkInt' Foo_stub.o:Foo_stub.c:(.text+0x2e): undefined reference to `rts_apply' Foo_stub.o:Foo_stub.c:(.text+0x42): undefined reference to `rts_apply' Foo_stub.o:Foo_stub.c:(.text+0x55): undefined reference to `rts_evalIO' Foo_stub.o:Foo_stub.c:(.text+0x67): undefined reference to `rts_checkSchedStatus' Foo_stub.o:Foo_stub.c:(.text+0x72): undefined reference to `rts_getInt' Foo_stub.o:Foo_stub.c:(.text+0x7c): undefined reference to `rts_unlock' Foo_stub.o:Foo_stub.c:(.text+0x97): undefined reference to `getStablePtr' ..... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 5 04:26:45 2008 From: trac at galois.com (GHC) Date: Wed Nov 5 04:21:45 2008 Subject: [GHC] #2745: ghc -shared broken In-Reply-To: <047.4659d608cdcae10c404611f42e7f8e53@localhost> References: <047.4659d608cdcae10c404611f42e7f8e53@localhost> Message-ID: <056.557137184ef7be977bed24812b76f1b0@localhost> #2745: ghc -shared broken ----------------------+----------------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Windows | ----------------------+----------------------------------------------------- Changes (by simonmar): * cc: lennart@augustsson.net (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 5 04:39:19 2008 From: trac at galois.com (GHC) Date: Wed Nov 5 04:34:10 2008 Subject: [GHC] #2744: Missing requirement check for hsc2hs In-Reply-To: <045.22de1b93d87ec567af1e55ce56c09fd8@localhost> References: <045.22de1b93d87ec567af1e55ce56c09fd8@localhost> Message-ID: <054.687bd7133217c0a25d7dd2a0c6d35065@localhost> #2744: Missing requirement check for hsc2hs --------------------------+------------------------------------------------- Reporter: jputcu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | --------------------------+------------------------------------------------- Changes (by simonmar): * difficulty: => Unknown Comment: Where did you get your GHC 6.6.1 from? As far as I can tell, 6.6.1 was shipped with hsc2hs. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 5 04:58:19 2008 From: trac at galois.com (GHC) Date: Wed Nov 5 04:53:10 2008 Subject: [GHC] #2746: Documentation for Haskell 98 modules is empty Message-ID: <047.55938b64a6a9b8fb4713b6865f858c9d@localhost> #2746: Documentation for Haskell 98 modules is empty ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Documentation | Version: 6.10.1 Severity: major | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ How did this happen? [http://www.haskell.org/ghc/docs/6.10.1/html/libraries/haskell98/Char.html] in 6.8.3 at least we could see the exports, with hyperlinks to the actual docs: [http://www.haskell.org/ghc/docs/6.8.3/html/libraries/haskell98/Char.html] Also, #2337 seems to have regressed again, I imagine the cause is probably the same. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 5 06:51:33 2008 From: trac at galois.com (GHC) Date: Wed Nov 5 06:46:25 2008 Subject: [GHC] #2744: Missing requirement check for hsc2hs In-Reply-To: <045.22de1b93d87ec567af1e55ce56c09fd8@localhost> References: <045.22de1b93d87ec567af1e55ce56c09fd8@localhost> Message-ID: <054.edb6c47102f6fb324922cf529e99cddb@localhost> #2744: Missing requirement check for hsc2hs --------------------------+------------------------------------------------- Reporter: jputcu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | --------------------------+------------------------------------------------- Comment (by jputcu): I used a standard ghc-6.6.1-src.tar.bz2 found at the official ghc download site. Did a configure, make and install. You're correct, the tool is present in the tar, but apparently not installed with the standard "make install". -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 5 07:28:46 2008 From: trac at galois.com (GHC) Date: Wed Nov 5 07:23:35 2008 Subject: [GHC] #2743: GHC 6.10.1 Win32 release is unusable (on XP SP3) In-Reply-To: <044.5c7925a0112349b6ff4c617bfd276240@localhost> References: <044.5c7925a0112349b6ff4c617bfd276240@localhost> Message-ID: <053.62d11ed2b2ceb90e2e93e5bf9af7530c@localhost> #2743: GHC 6.10.1 Win32 release is unusable (on XP SP3) -------------------------+-------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: blocker | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Windows -------------------------+-------------------------------------------------- Changes (by guest): * os: Unknown/Multiple => Windows * architecture: Unknown/Multiple => x86 * summary: GHC 6.10.1 Win32 release is unusable => GHC 6.10.1 Win32 release is unusable (on XP SP3) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 5 08:33:44 2008 From: trac at galois.com (GHC) Date: Wed Nov 5 08:28:34 2008 Subject: [GHC] #2743: GHC 6.10.1 Win32 release is unusable (on XP SP3) In-Reply-To: <044.5c7925a0112349b6ff4c617bfd276240@localhost> References: <044.5c7925a0112349b6ff4c617bfd276240@localhost> Message-ID: <053.11723c6198bbcfe1f8643e7caf580b68@localhost> #2743: GHC 6.10.1 Win32 release is unusable (on XP SP3) -------------------------+-------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: blocker | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Windows -------------------------+-------------------------------------------------- Comment (by NeilMitchell): I fixed a similar issue in 6.9, and at that point wondered if other changes needed making - obviously the answer is yes. I'll track this one down and get a patch. I suspect this relates to either your shell, or your %PATH% - do you have "G:\Progs\ghc-6.10.1\Bin" on your path, and does changing it to "\bin" fix the issue? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 5 08:49:34 2008 From: trac at galois.com (GHC) Date: Wed Nov 5 08:44:24 2008 Subject: [GHC] #2743: GHC 6.10.1 Win32 release is unusable (on XP SP3) In-Reply-To: <044.5c7925a0112349b6ff4c617bfd276240@localhost> References: <044.5c7925a0112349b6ff4c617bfd276240@localhost> Message-ID: <053.aa7f35a8b422088813d4bd77d989e469@localhost> #2743: GHC 6.10.1 Win32 release is unusable (on XP SP3) -------------------------+-------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: blocker | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Windows -------------------------+-------------------------------------------------- Comment (by NeilMitchell): I've attached a patch, which I think should fix the issue. This probably needs to be merged in to 6.10 as well. I haven't tested the patch (other than it compiles), but its fairly simple, so hopefully will work. When was getBaseDir altered? If this code is new for 6.10, then it is almost certainly worth releasing a new version for Windows. Depending on peoples setups, it could be quite common. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 5 10:08:26 2008 From: trac at galois.com (GHC) Date: Wed Nov 5 10:03:17 2008 Subject: [GHC] #2743: GHC 6.10.1 Win32 release is unusable (on XP SP3) In-Reply-To: <044.5c7925a0112349b6ff4c617bfd276240@localhost> References: <044.5c7925a0112349b6ff4c617bfd276240@localhost> Message-ID: <053.1dd82ba212962b98365ddfdee6ab7bda@localhost> #2743: GHC 6.10.1 Win32 release is unusable (on XP SP3) -------------------------+-------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: blocker | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Windows -------------------------+-------------------------------------------------- Comment (by guest): Yes, changing "G:\Progs\ghc-6.10.1\Bin" to "G:\Progs\ghc-6.10.1\bin" in my %PATH% have fixed the ghc.exe issue, but runghc/runhaskell still hangs. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 5 10:22:32 2008 From: trac at galois.com (GHC) Date: Wed Nov 5 10:17:23 2008 Subject: [GHC] #2747: Excessive Memory Usage Message-ID: <044.00f0ddc6265bd8f5349ed085d7f86a62@localhost> #2747: Excessive Memory Usage -----------------------------------------+---------------------------------- Reporter: guest | Owner: Type: run-time performance bug | Status: new Priority: normal | Component: Runtime System Version: 6.10.1 | Severity: blocker Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Windows -----------------------------------------+---------------------------------- "foldl1' (*) [1..1000000]" for example allocates up to 1.9 GB of Memory in about 10 seconds and stops with "out of memory". I guess I don't have to mention that with 6.8.3 it runs with only as much as 20MB. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 5 10:42:51 2008 From: trac at galois.com (GHC) Date: Wed Nov 5 10:37:40 2008 Subject: [GHC] #2743: GHC 6.10.1 Win32 release is unusable (on XP SP3) In-Reply-To: <044.5c7925a0112349b6ff4c617bfd276240@localhost> References: <044.5c7925a0112349b6ff4c617bfd276240@localhost> Message-ID: <053.6b0107b831335c921c465c27ef96592d@localhost> #2743: GHC 6.10.1 Win32 release is unusable (on XP SP3) -------------------------+-------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: blocker | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Windows -------------------------+-------------------------------------------------- Comment (by NeilMitchell): The PATH thing has a patch, is a known issue, so that seems to be eliminated. The issue with runghc is that "runghc" with no arguments takes the file from stdin. i.e. type "runghc" then type "main = print 1" enter, then hit Ctrl+Z and enter. That will print the number 1 to the screen. This isn't how most Windows programs behave, and trying "runghc --help" has exactly the same behaviour (i.e. an apparent hang) so its not very helpful. There is a bug on my 6.9 thing that hitting Ctrl+C does not abort runghc while typing in a script, and that is a bug, if it is the same with 6.10. So I guess the runghc should respond more helpfully to --help, and should abort on Ctrl+C. Should it also print some help text for windows users with stdin bound to the prompt? Seems a bit of a horrid special case, but might help. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 5 11:05:20 2008 From: trac at galois.com (GHC) Date: Wed Nov 5 11:00:10 2008 Subject: [GHC] #2741: Delete key not working in GHCi In-Reply-To: <044.515a111ead67730965832db1290b176e@localhost> References: <044.515a111ead67730965832db1290b176e@localhost> Message-ID: <053.013cc12ea7ae661e501f708860380d8d@localhost> #2741: Delete key not working in GHCi -----------------------+---------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Linux -----------------------+---------------------------------------------------- Changes (by guest): * cc: sanzhiyan@gmail.com (added) Comment: it's the same on archlinux with libedit 20080712_2.11, also non-ascii characters like "?" don't work. The same happens in the test program from http://hackage.haskell.org/trac/ghc/ticket/2606#comment:4 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 5 11:25:47 2008 From: trac at galois.com (GHC) Date: Wed Nov 5 11:20:37 2008 Subject: [GHC] #2743: GHC 6.10.1 Win32 release is unusable (on XP SP3) In-Reply-To: <044.5c7925a0112349b6ff4c617bfd276240@localhost> References: <044.5c7925a0112349b6ff4c617bfd276240@localhost> Message-ID: <053.23ab37d91bac81d1d81d4735d7d0e4c7@localhost> #2743: GHC 6.10.1 Win32 release is unusable (on XP SP3) -------------------------+-------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: blocker | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Windows -------------------------+-------------------------------------------------- Comment (by guest): Well, I conjectured something like this about runghc, but didn't bother to test it out since it wasn't an issue for 6.8.3: runghc.exe: syntax: runghc [-f GHC-PATH | --] [GHC-ARGS] [--] FILE ARG... -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 5 14:57:11 2008 From: trac at galois.com (GHC) Date: Wed Nov 5 14:52:08 2008 Subject: [GHC] #2349: SIZET_FMT in includes/mkDerivedConstants.c needs to be "d" under older Solaris version In-Reply-To: <045.bc3bbec7f28e57f84d533f6eb759f26c@localhost> References: <045.bc3bbec7f28e57f84d533f6eb759f26c@localhost> Message-ID: <054.0eb80c9af5a92cc21200be14b38c55ae@localhost> #2349: SIZET_FMT in includes/mkDerivedConstants.c needs to be "d" under older Solaris version ----------------------+----------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: sparc Os: Solaris | ----------------------+----------------------------------------------------- Changes (by maeder): * version: 6.8.2 => 6.10.1 Comment: I've no idea how to test this. (Maybe just for Solaris 8?) I get {{{ ./../includes/GHCConstants.h:2:25: Not in scope: `zd' ./../includes/GHCConstants.h:4:25: Not in scope: `zd' ... ./../includes/GHCConstants.h:469:25: Not in scope: `zd' ./../includes/GHCConstants.h:472:22: Not in scope: `zd' }}} when building `dist-stage1/build/Constants.o` -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 5 15:07:05 2008 From: trac at galois.com (GHC) Date: Wed Nov 5 15:01:54 2008 Subject: [GHC] #2747: Excessive Memory Usage: space leak with foldl' on Integer In-Reply-To: <044.00f0ddc6265bd8f5349ed085d7f86a62@localhost> References: <044.00f0ddc6265bd8f5349ed085d7f86a62@localhost> Message-ID: <053.2ef86eef056573c978943b8e26852824@localhost> #2747: Excessive Memory Usage: space leak with foldl' on Integer -----------------------------------------+---------------------------------- Reporter: guest | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: blocker | Resolution: Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple -----------------------------------------+---------------------------------- Comment (by nominolo): A heap profile shows ARR_WORDS as the culprit. The compiling the program with {{{-O}}} with either version gives an equivalent inner loop: {{{ -- 6.8.2 Rec { Main.lgo :: GHC.Num.Integer -> [GHC.Num.Integer] -> GHC.Num.Integer [GlobalId] [Arity 2 NoCafRefs Str: DmdType SS] Main.lgo = \ (z1_aw1 :: GHC.Num.Integer) (ds_aw2 :: [GHC.Num.Integer]) -> case ds_aw2 of wild_aw3 { [] -> z1_aw1; : x_aw7 xs1_aw8 -> case GHC.Num.timesInteger z1_aw1 x_aw7 of tpl_awa { __DEFAULT -> Main.lgo tpl_awa xs1_aw8 } } end Rec } }}} {{{ -- HEAD (6.11.20081103) Rec { Main.lgo :: GHC.Integer.Internals.Integer -> [GHC.Integer.Internals.Integer] -> GHC.Integer.Internals.Integer [GlobalId] [Arity 2 NoCafRefs Str: DmdType SS] Main.lgo = \ (z_ay4 :: GHC.Integer.Internals.Integer) (ds_ay5 :: [GHC.Integer.Internals.Integer]) -> case ds_ay5 of wild_ay6 { [] -> z_ay4; : x_aya xs_ayb -> case GHC.Integer.timesInteger z_ay4 x_aya of z'_ayd { __DEFAULT -> Main.lgo z'_ayd xs_ayb } } end Rec } }}} My guess therefore is that {{{GHC.Integer.timesInteger}}} is the culprit. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 5 15:37:19 2008 From: trac at galois.com (GHC) Date: Wed Nov 5 15:32:10 2008 Subject: [GHC] #2748: Fundep-laden code compiled and ran fine in 6.8, fails in 6.10 Message-ID: <048.d339fd8ea08f26d215e7fbe110469ee0@localhost> #2748: Fundep-laden code compiled and ran fine in 6.8, fails in 6.10 ---------------------------------+------------------------------------------ Reporter: sedillard | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ I was kindly alerted by Ian Lynagh that some code of mine on hackage was causing 6.10-rc1 to fail to terminate. This code compiles and runs find on 6.8. Instead of diverging, 6.10.1 raises a type error. I've made a test case, and I'm creating this ticket to figure out what's going in. Is it, A) The code is incorrect and 6.8 was erroneously accepting it, and only by luck producing a valid program B) The code is correct and 6.10.1's typechecker is being overly conservative. At the core is overlapping instances. I've spent considerable effort removing them from the library, because I can't just look at the code and say for certain "this will never overlap with that" because its too complicated. Overlap errors become the users problem, I myself having been bitten by them many times as a user of my own library. The solution is to do without overlapping instances. The types of my instances then go from something nice like {{{ instance (A t) => C t instance (B t) => C t --overlap }}} to something nasty like {{{ instance (A (T (T x))) => C (T (T x)) instance (B (T (T (T x)))) => C (T (T (T x))) --no overlap }}} It's uglier for me to read and write but ultimately better for the user because I've eliminated a category of errors. If the compiler will let me, I try to abbreviate 'T (T (T x)))' to 't' in the instance head, but I'm not always able to because 't' is more general than 'T (T (T x)))'. I'm not entirely sure how that factors into things. To see what I'm talking about, compile the attached file and look for the error that says {{{Couldn't match expected type `vmt' against inferred type `vv :. (b' :. v)' `vmt' is a rigid type variable...}}}. It has something to do with functional dependencies. The fundep involved demands that 'vmt' be of the type 'x :. y :. z :. etc' but in this particular case it's so verbose I just call it 'vmt'. 6.8 lets me do that. 6.10 doesn't. Who's right? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 5 15:39:50 2008 From: trac at galois.com (GHC) Date: Wed Nov 5 15:34:40 2008 Subject: [GHC] #2748: Fundep-laden code compiled and ran fine in 6.8, fails in 6.10 In-Reply-To: <048.d339fd8ea08f26d215e7fbe110469ee0@localhost> References: <048.d339fd8ea08f26d215e7fbe110469ee0@localhost> Message-ID: <057.403a167febb2bf2f65740a5ad6c39ea1@localhost> #2748: Fundep-laden code compiled and ran fine in 6.8, fails in 6.10 ---------------------------------+------------------------------------------ Reporter: sedillard | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ Changes (by sedillard): * version: 6.8.3 => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 5 16:38:52 2008 From: trac at galois.com (GHC) Date: Wed Nov 5 16:33:43 2008 Subject: [GHC] #2747: Excessive Memory Usage: space leak with foldl' on Integer In-Reply-To: <044.00f0ddc6265bd8f5349ed085d7f86a62@localhost> References: <044.00f0ddc6265bd8f5349ed085d7f86a62@localhost> Message-ID: <053.55f6f3368c5731710873c96d16ea80f1@localhost> #2747: Excessive Memory Usage: space leak with foldl' on Integer -----------------------------------------+---------------------------------- Reporter: guest | Owner: nominolo Type: run-time performance bug | Status: assigned Priority: normal | Milestone: Component: Runtime System | Version: 6.10.1 Severity: blocker | Resolution: Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple -----------------------------------------+---------------------------------- Changes (by nominolo): * status: new => assigned * owner: => nominolo Comment: Here's a small abstract of the output when run debugged RTS and {{{+RTS -Dg}}} (GC debugging): {{{ allocated 1 megablock(s) at 0xae00000 allocated 1 megablock(s) at 0xaf00000 allocated 1 megablock(s) at 0xb000000 allocated 1 megablock(s) at 0xb100000 allocated 1 megablock(s) at 0xb200000 allocated 1 megablock(s) at 0xb300000 GC (gen 0): 151940 KB to collect, 152 MB in use, using 1 thread(s) Memory inventory: gen 0 blocks : 37859 blocks (147 MB) gen 1 blocks : 4 blocks (0 MB) nursery : 128 blocks (0 MB) retainer : 0 blocks (0 MB) arena blocks : 0 blocks (0 MB) exec : 0 blocks (0 MB) free : 617 blocks (2 MB) total : 38608 blocks (150 MB) alloc new todo block 0x6d08000 for step 1 GC thread 0 working scavenging block 0x6d08000 (gen 0, step 1) @ 0x6d08000 scavenged 40 bytes GC thread 0 idle (0 still running) GC thread 0 finished. GC thread 0 working }}} As you can see, it's adding megablocks (1MB) to the first generation. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 5 17:43:23 2008 From: trac at galois.com (GHC) Date: Wed Nov 5 17:38:14 2008 Subject: [GHC] #2747: Excessive Memory Usage: space leak with foldl' on Integer In-Reply-To: <044.00f0ddc6265bd8f5349ed085d7f86a62@localhost> References: <044.00f0ddc6265bd8f5349ed085d7f86a62@localhost> Message-ID: <053.e909d8d5a9d2b73a3120537360e6b45b@localhost> #2747: Excessive Memory Usage: space leak with foldl' on Integer -----------------------------------------+---------------------------------- Reporter: guest | Owner: simonmar Type: run-time performance bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.10.1 Severity: blocker | Resolution: Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple -----------------------------------------+---------------------------------- Changes (by nominolo): * status: assigned => new * owner: nominolo => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From noreply at sourceforge.net Thu Nov 6 03:38:57 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 6 03:33:45 2008 Subject: [ ghc-Bugs-1228084 ] OpenAL needs -pthread Message-ID: Bugs item #1228084, was opened at 2005-06-27 10:04 Message generated for change (Comment added) made by spanne You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108032&aid=1228084&group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: libraries (other) Group: None >Status: Closed Resolution: None Priority: 3 Private: No Submitted By: Volker Stolz (volkersf) Assigned to: Sven Panne (spanne) Summary: OpenAL needs -pthread Initial Comment: On FreeBSD (and maybe NetBSD as well), OpenAL needs -pthread in CFLAGS/LDFLAGS: configure:2352: gcc -o conftest -I/usr/local/include -L/usr/local/lib conftest.c -lopenal >&5 /usr/local/lib/libopenal.so: undefined reference to `pthread_create' /usr/local/lib/libopenal.so: undefined reference to `pthread_attr_init' /usr/local/lib/libopenal.so: undefined reference to `pthread_exit' This should best be solved during configure instead of setting this globally. Also, this probably needs to be propagated into OpenAL. cabal for linking a resulting application (although already the RTS should pull in -pthread). ---------------------------------------------------------------------- >Comment By: Sven Panne (spanne) Date: 2008-11-06 09:38 Message: This bug tracker isn't used anymore, and I'm quite sure that I've fixed this bug a long time ago. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108032&aid=1228084&group_id=8032 From trac at galois.com Thu Nov 6 06:11:35 2008 From: trac at galois.com (GHC) Date: Thu Nov 6 06:06:23 2008 Subject: [GHC] #2747: Excessive Memory Usage: space leak with foldl' on Integer In-Reply-To: <044.00f0ddc6265bd8f5349ed085d7f86a62@localhost> References: <044.00f0ddc6265bd8f5349ed085d7f86a62@localhost> Message-ID: <053.d9f1afad0fab51ebb43c3db2cb8e2438@localhost> #2747: Excessive Memory Usage: space leak with foldl' on Integer --------------------------------------+------------------------------------- Reporter: guest | Owner: simonmar Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Runtime System | Version: 6.10.1 Severity: blocker | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | --------------------------------------+------------------------------------- Changes (by simonmar): * difficulty: => Unknown * milestone: => 6.10.2 Comment: Testing the fix right now. We discovered the cause: basically the RTS isn't triggering a GC often enough, because some accounting got accidentally removed during some other refactoring. Large objects aren't being counted when deciding whether to GC, so a program that allocates all or mostly large objects can use a large amount of memory between GCs. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 6 08:33:07 2008 From: trac at galois.com (GHC) Date: Thu Nov 6 08:27:55 2008 Subject: [GHC] #2747: Excessive Memory Usage: space leak with foldl' on Integer In-Reply-To: <044.00f0ddc6265bd8f5349ed085d7f86a62@localhost> References: <044.00f0ddc6265bd8f5349ed085d7f86a62@localhost> Message-ID: <053.632d50ca4016c6a57d1e7fa691434d81@localhost> #2747: Excessive Memory Usage: space leak with foldl' on Integer ------------------------------+--------------------------------------------- Reporter: guest | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.2 Component: Runtime System | Version: 6.10.1 Severity: blocker | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: run-time performance bug => merge Comment: Fixed: {{{ Thu Nov 6 03:37:14 PST 2008 Simon Marlow * allocateInGen(): increase alloc_blocks (#2747) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 6 09:49:23 2008 From: trac at galois.com (GHC) Date: Thu Nov 6 09:44:18 2008 Subject: [GHC] #2749: No mention of -shared regression in relase docs Message-ID: <044.2ba8f465a23dbcd2ddd81175dc89df9f@localhost> #2749: No mention of -shared regression in relase docs ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Documentation Version: 6.10.1 | Severity: normal Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ The -shared flag used to do something useful on Windows, now it just fails and says it's not implemented. This is bad, but even worse, the release documentation does not mention this, nor what one should do to manually recover the functionality that was removed from ghc. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 6 11:26:23 2008 From: trac at galois.com (GHC) Date: Thu Nov 6 11:21:11 2008 Subject: [GHC] #2744: Missing requirement check for hsc2hs In-Reply-To: <045.22de1b93d87ec567af1e55ce56c09fd8@localhost> References: <045.22de1b93d87ec567af1e55ce56c09fd8@localhost> Message-ID: <054.89c5b2d4b89402d3f6e718006ba83916@localhost> #2744: Missing requirement check for hsc2hs --------------------------+------------------------------------------------- Reporter: jputcu | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Build System | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | --------------------------+------------------------------------------------- Changes (by simonmar): * milestone: => 6.10.2 Comment: Well, I'm fairly sure hsc2hs was installed with 6.6.1. It's in the binary distributions, I just checked. Still, it wouldn't hurt to have configure check for hsc2hs anyway. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 6 11:29:07 2008 From: trac at galois.com (GHC) Date: Thu Nov 6 11:24:02 2008 Subject: [GHC] #2749: No mention of -shared regression in relase docs In-Reply-To: <044.2ba8f465a23dbcd2ddd81175dc89df9f@localhost> References: <044.2ba8f465a23dbcd2ddd81175dc89df9f@localhost> Message-ID: <053.0f3e086610ed6d97867f758035c97c3c@localhost> #2749: No mention of -shared regression in relase docs ------------------------------+--------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 6.10.1 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: see #2745 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 6 11:30:50 2008 From: trac at galois.com (GHC) Date: Thu Nov 6 11:25:42 2008 Subject: [GHC] #2750: Bug in Data.Generics Message-ID: <044.cd214fdda0ee80175fd522907e79182f@localhost> #2750: Bug in Data.Generics ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ Observe the following: {{{ Prelude> :m +Data.Generics Prelude Data.Generics> dataTypeName (dataTypeOf (1,2)) "Prelude.(,)" Prelude Data.Generics> dataTypeName (dataTypeOf (1,2,3)) "Prelude.(,)" Prelude Data.Generics> dataTypeName (dataTypeOf (1,2,3,4)) "Prelude.(,,,)" }}} Probably a pasto in Data.Generics. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 6 11:40:30 2008 From: trac at galois.com (GHC) Date: Thu Nov 6 11:35:28 2008 Subject: [GHC] #2745: ghc -shared broken In-Reply-To: <047.4659d608cdcae10c404611f42e7f8e53@localhost> References: <047.4659d608cdcae10c404611f42e7f8e53@localhost> Message-ID: <056.b96f0a94c245dad742d65616cf9922c4@localhost> #2745: ghc -shared broken ----------------------+----------------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Windows | ----------------------+----------------------------------------------------- Changes (by simonmar): * cc: clemens@endorphin.org (added) Comment: The culprit appears to be this patch: {{{ Mon Oct 13 21:14:26 BST 2008 Clemens Fruhwirth * Do not filter the rts from linked libraries in linkDynLib as Windows does not allo w unresolved symbols { hunk ./compiler/main/DriverPipeline.hs 1497 - let pkgs_no_rts = filter ((/= rtsPackageId) . packageConfigId) pkgs hunk ./compiler/main/DriverPipeline.hs 1498 + -- On Windows we need to link the RTS import lib as Windows does + -- not allow undefined symbols. +#if defined(mingw32_HOST_OS) + let pkgs_no_rts = filter ((/= rtsPackageId) . packageConfigId) pkgs +#else + let pkgs_no_rts = pkgs +#endif } }}} but the patch doesn't seem to match the description - should it be `!defined(mingw32_HOST_OS)`? We need a test for this too. -- Ticket URL: GHC The Glasgow Haskell Compiler From conal at conal.net Thu Nov 6 16:05:01 2008 From: conal at conal.net (Conal Elliott) Date: Thu Nov 6 15:59:48 2008 Subject: build failure for 6.10.1, missing ghcautoconf.h Message-ID: I just tried to build 6.10.1 from the source tarball ( http://haskell.org/ghc/dist/6.10.1/ghc-6.10.1-src.tar.bz2) (plus extralibs) on Ubuntu 8.10, building with ghc-6.11. I got the following error: Configuring ghc-bin-6.10.1... /home/conal/downloads/ghc-6.10.1/libraries/cabal-bin /usr/local/bin/ghc /home/conal/downloads/ghc-6.10.1/libraries/bootstrapping.conf build --distpref dist-stage1 --ghc-option=-H32m --ghc-option=-O --ghc-option=-H32m --ghc-option=-O Preprocessing executables for ghc-bin-6.10.1... Building ghc-bin-6.10.1... In file included from Main.hs:14:0: /usr/local/lib/ghc-6.11.20081103/ghc-6.11.20081103/include/HsVersions.h:23:0: error: ../includes/ghcautoconf.h: No such file or directory make[2]: *** [build.stage.1] Error 1 make[1]: *** [build.stage.1] Error 2 make: *** [stage1] Error 1 conal@compy-doble:~/downloads/ghc-6.10.1$ Is this problem known? Does it come from building 6.10.1 with 6.11? Thanks, - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-bugs/attachments/20081106/34b126ee/attachment.htm From trac at galois.com Fri Nov 7 00:33:29 2008 From: trac at galois.com (GHC) Date: Fri Nov 7 00:28:14 2008 Subject: [GHC] #2751: GHC 6.10.1 fails to build with --enable-shared configured on Ubuntu 8.04. Message-ID: <044.e59a32690b73a04f93e0448da03405c8@localhost> #2751: GHC 6.10.1 fails to build with --enable-shared configured on Ubuntu 8.04. ------------------------------------+--------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: build enable-shared | Testcase: Architecture: x86 | Os: Linux ------------------------------------+--------------------------------------- To replicate: * unpack the source tar file * unpack the extralibs tar file * unpack the test suite tar file In the source root: $ ./configure --enable-shared $ make The package base-4.0.0.0 will crap out with a complaint about libffi. Do the following instead after unpacking and it builds all the way through, even if you bootstrap3, etc.: $ ./configure $ make To my untutored eyes it appears as if ghc is looking for libffi.so.5 and isn't finding it. This is not a surprise given: $ ll /usr/lib/libffi* lrwxrwxrwx 1 root root 15 2008-10-23 09:13 /usr/lib/libffi.so.4 -> libffi.so.4.0.1 -rw-r--r-- 1 root root 22K 2008-10-11 03:38 /usr/lib/libffi.so.4.0.1 I've attached the config log (for details of file versions, etc.) and the output of the make process (for complete error information) to this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 7 00:59:51 2008 From: trac at galois.com (GHC) Date: Fri Nov 7 00:54:35 2008 Subject: [GHC] #2751: GHC 6.10.1 fails to build with --enable-shared configured on Ubuntu 8.04. In-Reply-To: <044.e59a32690b73a04f93e0448da03405c8@localhost> References: <044.e59a32690b73a04f93e0448da03405c8@localhost> Message-ID: <053.983bd41d871d399bc829fae00ba186ee@localhost> #2751: GHC 6.10.1 fails to build with --enable-shared configured on Ubuntu 8.04. ------------------------------------+--------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: build enable-shared | Testcase: Architecture: x86 | Os: Linux ------------------------------------+--------------------------------------- Comment (by ttmrichter): Decided to register and claim the ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 7 03:52:12 2008 From: trac at galois.com (GHC) Date: Fri Nov 7 03:46:56 2008 Subject: [GHC] #2752: Parse error in STM.c Message-ID: <045.c718ce03da14ed9d9cb9e18ef468e107@localhost> #2752: Parse error in STM.c -----------------------+---------------------------------------------------- Reporter: jputcu | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.10.1 | Severity: blocker Keywords: | Testcase: Architecture: x86 | Os: Linux -----------------------+---------------------------------------------------- Building failed. * Red Hat 7.3 * ghc-6.6.1 * gcc-2.96 * GNU make-3.80 * perl-5.6.1 rst/STM.c line 392 "StgTVarWatchQueue *trail" {{{ ... /home/jorisp/ghc5042_rh72/ghc-6.10.1/ghc/stage1-inplace/ghc -optc-O -optc- Wall -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc- Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-I../includes -optc-I. -optc-Iparallel -optc-Ism -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -optc-I../gmp/gmpbuild -optc-I../libffi/build/include -optc-fno-strict-aliasing -H32m -O -optc-O2 -I../includes -I. -Iparallel -Ism -DCOMPILING_RTS -package-name rts -static -I../gmp/gmpbuild -I../libffi/build/include -I. -dcmm-lint -c STM.c -o STM.o In file included from ../includes/Rts.h:179, from STM.c:86:0: ../includes/SMPClosureOps.h: In function `unlockClosure': ../includes/SMPClosureOps.h:54:0: warning: unused parameter `p' ../includes/SMPClosureOps.h:54:0: warning: unused parameter `info' In file included from ../includes/Rts.h:180, from STM.c:86:0: ../includes/SpinLock.h: In function `initSpinLock': ../includes/SpinLock.h:99:0: warning: unused parameter `p' In file included from Schedule.h:14, from STM.c:90:0: Capability.h: In function `releaseCapability': Capability.h:150:0: warning: unused parameter `cap' Capability.h: In function `releaseCapability_': Capability.h:151:0: warning: unused parameter `cap' STM.c: In function `lock_stm': STM.c:183:0: warning: unused parameter `trec' STM.c: In function `unlock_stm': STM.c:187:0: warning: unused parameter `trec' STM.c: In function `lock_tvar': STM.c:191:0: warning: unused parameter `trec' STM.c: In function `unlock_tvar': STM.c:199:0: warning: unused parameter `trec' STM.c: In function `cond_lock_tvar': STM.c:209:0: warning: unused parameter `trec' STM.c: In function `lock_inv': STM.c:219:0: warning: unused parameter `inv' STM.c: In function `unlock_inv': STM.c:224:0: warning: unused parameter `inv' STM.c: In function `unpark_waiters_on': STM.c:392:0: parse error before `*' STM.c:394:0: `trail' undeclared (first use in this function) STM.c:394:0: (Each undeclared identifier is reported only once STM.c:394:0: for each function it appears in.) STM.c:394:0: warning: value computed is not used STM.c:390:0: warning: `q' might be used uninitialized in this function STM.c: In function `revert_ownership': STM.c:763:0: warning: unused parameter `trec' STM.c:764:0: warning: unused parameter `revert_all' STM.c: In function `check_read_only': STM.c:858:0: warning: unused parameter `trec' STM.c: In function `getToken': STM.c:930:0: warning: unused parameter `cap' STM.c: In function `stmWaitUnlock': STM.c:1529:0: warning: unused parameter `cap' STM.c: In function `read_current_value': STM.c:1571:0: warning: unused parameter `trec' make[1]: *** [STM.o] Error 1 make[1]: Leaving directory `/home/jorisp/ghc5042_rh72/ghc-6.10.1/rts' make: *** [stage1] Error 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 7 08:19:49 2008 From: trac at galois.com (GHC) Date: Fri Nov 7 08:14:44 2008 Subject: [GHC] #2745: ghc -shared broken In-Reply-To: <047.4659d608cdcae10c404611f42e7f8e53@localhost> References: <047.4659d608cdcae10c404611f42e7f8e53@localhost> Message-ID: <056.9c5680bb8762bba5eee2a05684739145@localhost> #2745: ghc -shared broken ----------------------+----------------------------------------------------- Reporter: simonmar | Owner: igloo Type: merge | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Windows | ----------------------+----------------------------------------------------- Changes (by simonmar): * owner: => igloo * type: bug => merge Comment: Fixed, and I have a test almost ready to commit too. {{{ Fri Nov 7 09:29:25 GMT 2008 Simon Marlow * Bugfix for patch "Do not filter the rts from linked libraries..." (#2745) The sense of the #ifdef was wrong }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 7 13:50:31 2008 From: trac at galois.com (GHC) Date: Fri Nov 7 13:45:22 2008 Subject: [GHC] #2644: type of IntMap.intersection[WithKey] is incorrect In-Reply-To: <048.cdf8c7c801b2eb701f7311923129020e@localhost> References: <048.cdf8c7c801b2eb701f7311923129020e@localhost> Message-ID: <057.f2daa4b8cbfcc610e7d7c078570939ed@localhost> #2644: type of IntMap.intersection[WithKey] is incorrect -------------------------------+-------------------------------------------- Reporter: sedillard | Owner: Type: bug | Status: new Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.8.3 Severity: normal | Resolution: Keywords: containers | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | -------------------------------+-------------------------------------------- Changes (by Deewiant): * cc: Deewiant (added) Comment: This would really be useful to get in. Nobody seemed to have any objections when it was posted to the list, so I suppose it can be applied by now? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 7 18:43:36 2008 From: trac at galois.com (GHC) Date: Fri Nov 7 18:38:19 2008 Subject: [GHC] #2753: GHC 6.10.1 cannot compile Crypto-4.1.0 Message-ID: <052.22581ce23675b5d58c2247a1ee1a7ede@localhost> #2753: GHC 6.10.1 cannot compile Crypto-4.1.0 ---------------------------------+------------------------------------------ Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: critical Keywords: | Testcase: Architecture: Unknown/Multiple | Os: MacOS X ---------------------------------+------------------------------------------ While trying to install Crypto, I get this error message with GHC 6.10.1 on Mac OS X 10.5: {{{ $ cabal install Crypto ... Linking dist/build/SymmetricTest/SymmetricTest ... [1 of 4] Compiling Codec.Utils ( Codec/Utils.hs, dist/build/SHA1Test /SHA1Test-tmp/Codec/Utils.o ) [2 of 4] Compiling Data.Digest.SHA1 ( Data/Digest/SHA1.hs, dist/build/SHA1Test/SHA1Test-tmp/Data/Digest/SHA1.o ) [3 of 4] Compiling Codec.Text.Raw ( Codec/Text/Raw.hs, dist/build/SHA1Test/SHA1Test-tmp/Codec/Text/Raw.o ) [4 of 4] Compiling Main ( SHA1Test.hs, dist/build/SHA1Test /SHA1Test-tmp/Main.o ) ghc: panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-apple-darwin): RegAllocLinear.getStackSlotFor: out of stack slots, try -fregs- graph ... $ }}} Even with -fregs-graph specified (in the .cabal file) this happens. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 7 18:49:19 2008 From: trac at galois.com (GHC) Date: Fri Nov 7 18:44:01 2008 Subject: [GHC] #2753: GHC 6.10.1 cannot compile Crypto-4.1.0 In-Reply-To: <052.22581ce23675b5d58c2247a1ee1a7ede@localhost> References: <052.22581ce23675b5d58c2247a1ee1a7ede@localhost> Message-ID: <061.9c3f178dd9a9392a8cf6e38137142886@localhost> #2753: GHC 6.10.1 cannot compile Crypto-4.1.0 ---------------------------------+------------------------------------------ Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: critical | Resolution: Keywords: | Testcase: Architecture: Unknown/Multiple | Os: MacOS X ---------------------------------+------------------------------------------ Comment (by thoughtpolice): Actually, with -fregs-graph it does build (got cabal file wrong.) But without it this chokes on the SHA1Test.hs file. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 7 23:30:28 2008 From: trac at galois.com (GHC) Date: Fri Nov 7 23:25:11 2008 Subject: [GHC] #2754: Strictness analyzer fails on an implementation of foldl Message-ID: <045.b34db0d1501300b44384b2b8b33f4b1f@localhost> #2754: Strictness analyzer fails on an implementation of foldl -----------------------------------------+---------------------------------- Reporter: nimnul | Owner: Type: run-time performance bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: Windows -----------------------------------------+---------------------------------- foldB has O(1) complexity, but foldA O(N). Looks like a strictness analyzer failure. module Main where foldA :: (a -> e -> a) -> a -> [e] -> a foldA _ r [] = r foldA op r (x:xs) = foldA op (op r x) xs foldB :: (a -> e -> a) -> a -> [e] -> a foldB _ r [] = r foldB op r (x:xs) = r' `seq` foldB op r' xs where r' = op r x l :: [Int] l = [1..100*1000*1000] main = print $ foldl (+) 0 l -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 8 11:28:28 2008 From: trac at galois.com (GHC) Date: Sat Nov 8 11:24:20 2008 Subject: [GHC] #1876: Complete shared library support In-Reply-To: <047.2ab772cd4150dcd51ba47e309570e649@localhost> References: <047.2ab772cd4150dcd51ba47e309570e649@localhost> Message-ID: <056.d4c9e4d6ae69ecdfbf0c7a2942a64452@localhost> #1876: Complete shared library support ------------------------------+--------------------------------------------- Reporter: simonmar | Owner: clemens Type: task | Status: assigned Priority: high | Milestone: 6.10 branch Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Difficult (1 week) Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by ingmar): * cc: ingmar@exherbo.org (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 8 13:59:04 2008 From: trac at galois.com (GHC) Date: Sat Nov 8 13:53:46 2008 Subject: [GHC] #2755: Broken link in GHC API documentation Message-ID: <044.a40779a08e2a4155adb6f037645bf002@localhost> #2755: Broken link in GHC API documentation ---------------------------------+------------------------------------------ Reporter: waern | Owner: Type: bug | Status: new Priority: normal | Component: Documentation Version: 6.10.1 | Severity: normal Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ In the docs for the Exception module, the link to the Exception class goes to this page, which is not available: {{{ http://www.haskell.org/home/ian/6.10.1/ghc-6.10.1/libraries/base/dist/doc/html/base /Control-Exception-Base.html#t%3AException }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 9 12:55:45 2008 From: trac at galois.com (GHC) Date: Sun Nov 9 12:50:27 2008 Subject: [GHC] #2753: GHC 6.10.1 cannot compile Crypto-4.1.0 In-Reply-To: <052.22581ce23675b5d58c2247a1ee1a7ede@localhost> References: <052.22581ce23675b5d58c2247a1ee1a7ede@localhost> Message-ID: <061.b6acab1ba4eeb361ce66666365f51838@localhost> #2753: GHC 6.10.1 cannot compile Crypto-4.1.0 ---------------------------------+------------------------------------------ Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: critical | Resolution: Keywords: | Testcase: Architecture: Unknown/Multiple | Os: MacOS X ---------------------------------+------------------------------------------ Comment (by JohnMacFarlane): I'm getting the same problem on a Ubuntu linux x86 system. See also #2623. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 9 13:21:49 2008 From: trac at galois.com (GHC) Date: Sun Nov 9 13:16:26 2008 Subject: [GHC] #2755: Broken link in GHC API documentation In-Reply-To: <044.a40779a08e2a4155adb6f037645bf002@localhost> References: <044.a40779a08e2a4155adb6f037645bf002@localhost> Message-ID: <053.c3a19537d62099d9664f54615f47a5a1@localhost> #2755: Broken link in GHC API documentation ---------------------------------+------------------------------------------ Reporter: waern | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ Comment (by nominolo): Note the {{{home/ian}}} part in the URL, that doesn't seem right. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 9 14:16:27 2008 From: trac at galois.com (GHC) Date: Sun Nov 9 14:11:05 2008 Subject: [GHC] #2753: GHC 6.10.1 cannot compile Crypto-4.1.0 In-Reply-To: <052.22581ce23675b5d58c2247a1ee1a7ede@localhost> References: <052.22581ce23675b5d58c2247a1ee1a7ede@localhost> Message-ID: <061.76fafe0212cc02c9384c15074dcadf89@localhost> #2753: GHC 6.10.1 cannot compile Crypto-4.1.0 ---------------------------------+------------------------------------------ Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: critical | Resolution: Keywords: | Testcase: Architecture: Unknown/Multiple | Os: MacOS X ---------------------------------+------------------------------------------ Comment (by nominolo): SHA1 is a particular stress-test of the register allocator. It's a known problem, but apparently #2623 claims it's been fixed. So perhaps #2623 should be re-opened and this one be marked as a duplicate. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 9 21:56:46 2008 From: trac at galois.com (GHC) Date: Sun Nov 9 21:51:23 2008 Subject: [GHC] #2756: state hack causes unneeded value to be evaluated Message-ID: <044.fd970d5f81038e1e8c0cb54c1d8b0d1b@localhost> #2756: state hack causes unneeded value to be evaluated ---------------------------------+------------------------------------------ Reporter: int-e | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ The following code prints "{{{Main: Why?}}}" when compiled with {{{ghc -O1}}}. With {{{-fno-state-hack}}} it works fine. {{{ data X = X () {-# NOINLINE newX #-} newX :: () -> IO X newX n = do let {-# NOINLINE value #-} value = n return (X value) main = do x <- newX (error "Why?") case x of X _ -> return () }}} Both pragmas are needed to exhibit the bug. (In my actual code, {{{value}}} is an {{{unsafePerformIO}}} -- this was the motivation for adding the pragmas.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 10 05:06:08 2008 From: trac at galois.com (GHC) Date: Mon Nov 10 05:00:42 2008 Subject: [GHC] #2757: runghc doesn't respond to --help Message-ID: <047.8ea527abd27e35ccd572a6a7f32be73f@localhost> #2757: runghc doesn't respond to --help ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.8.3 Severity: normal | Keywords: Difficulty: Easy (1 hr) | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ Should be an easy one. (moved from #2743) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 10 05:07:17 2008 From: trac at galois.com (GHC) Date: Mon Nov 10 05:01:52 2008 Subject: [GHC] #2758: runghc in stdin mode ignores Ctrl-C on Windows, cannot be killed Message-ID: <047.917d1da3b05e4d79bd411a581a2d9795@localhost> #2758: runghc in stdin mode ignores Ctrl-C on Windows, cannot be killed ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.8.3 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ Moved from #2743. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 10 05:08:22 2008 From: trac at galois.com (GHC) Date: Mon Nov 10 05:02:57 2008 Subject: [GHC] #2743: GHC 6.10.1 Win32 release is unusable (on XP SP3) In-Reply-To: <044.5c7925a0112349b6ff4c617bfd276240@localhost> References: <044.5c7925a0112349b6ff4c617bfd276240@localhost> Message-ID: <053.996edeef352055332e39fdfdbd4fa740@localhost> #2743: GHC 6.10.1 Win32 release is unusable (on XP SP3) ----------------------+----------------------------------------------------- Reporter: guest | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: blocker | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------+----------------------------------------------------- Changes (by simonmar): * owner: => simonmar * difficulty: => Unknown * milestone: => 6.10.2 Comment: I'll validate and commit, thanks. The runghc bugs have been separately ticketed as #2757 and #2758. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 10 05:12:28 2008 From: trac at galois.com (GHC) Date: Mon Nov 10 05:07:04 2008 Subject: [GHC] #2751: GHC 6.10.1 fails to build with --enable-shared configured on Ubuntu 8.04. In-Reply-To: <044.e59a32690b73a04f93e0448da03405c8@localhost> References: <044.e59a32690b73a04f93e0448da03405c8@localhost> Message-ID: <053.a79f3c7af7395e12c89d11242fab80e3@localhost> #2751: GHC 6.10.1 fails to build with --enable-shared configured on Ubuntu 8.04. ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.10.1 Severity: normal | Resolution: Keywords: build enable-shared | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ---------------------------------+------------------------------------------ Changes (by simonmar): * cc: clemens (added) * difficulty: => Unknown Comment: Note `--enable-shared` is not fully supported yet - see #1876. There are probably patches in HEAD that fix this bug. I think we should probably close it, but I'll leave the decision to Clemens who is working on the shared lib support at the moment. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 10 05:18:55 2008 From: trac at galois.com (GHC) Date: Mon Nov 10 05:13:30 2008 Subject: [GHC] #2751: GHC 6.10.1 fails to build with --enable-shared configured on Ubuntu 8.04. In-Reply-To: <044.e59a32690b73a04f93e0448da03405c8@localhost> References: <044.e59a32690b73a04f93e0448da03405c8@localhost> Message-ID: <053.6c242670a2f24d32375d15d69ad153d1@localhost> #2751: GHC 6.10.1 fails to build with --enable-shared configured on Ubuntu 8.04. ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.10.1 Severity: normal | Resolution: Keywords: build enable-shared | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ---------------------------------+------------------------------------------ Comment (by ttmrichter): It may be best, then, to remove the option from the build scripts until it is supported, or at least to document somewhere prominent (like in ./configure --help) that this is not yet fully supported, etc. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 10 05:33:29 2008 From: trac at galois.com (GHC) Date: Mon Nov 10 05:28:05 2008 Subject: [GHC] #2752: Parse error in STM.c In-Reply-To: <045.c718ce03da14ed9d9cb9e18ef468e107@localhost> References: <045.c718ce03da14ed9d9cb9e18ef468e107@localhost> Message-ID: <054.1fb35e6ad1808b2e7896e6736425d7d8@localhost> #2752: Parse error in STM.c --------------------------+------------------------------------------------- Reporter: jputcu | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Build System | Version: 6.10.1 Severity: blocker | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | --------------------------+------------------------------------------------- Changes (by simonmar): * owner: => simonmar * difficulty: => Unknown * milestone: => 6.10.2 Comment: Thanks for the report. I see what the bug is, so I can fix that, but unfortunately I don't have a way to test with gcc 2.95 here. If you can test the patch, that would be most helpful - I wouldn't be surprised if there are other problems to be found. {{{ diff -rN -u old-ghc-testing/rts/STM.c new-ghc-testing/rts/STM.c --- old-ghc-testing/rts/STM.c 2008-11-10 10:33:06.000000000 +0000 +++ new-ghc-testing/rts/STM.c 2008-11-10 10:33:07.000000000 +0000 @@ -388,8 +388,8 @@ static void unpark_waiters_on(Capability *cap, StgTVar *s) { StgTVarWatchQueue *q; - TRACE("unpark_waiters_on tvar=%p", s); StgTVarWatchQueue *trail; + TRACE("unpark_waiters_on tvar=%p", s); // unblock TSOs in reverse order, to be a bit fairer (#2319) for (q = s -> first_watch_queue_entry, trail = q; q != END_STM_WATCH_QUEUE; }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 10 05:34:50 2008 From: trac at galois.com (GHC) Date: Mon Nov 10 05:29:25 2008 Subject: [GHC] #2754: Strictness analyzer fails on an implementation of foldl In-Reply-To: <045.b34db0d1501300b44384b2b8b33f4b1f@localhost> References: <045.b34db0d1501300b44384b2b8b33f4b1f@localhost> Message-ID: <054.e00bf1f223b8efc717ca76fb626618d0@localhost> #2754: Strictness analyzer fails on an implementation of foldl --------------------------------------+------------------------------------- Reporter: nimnul | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | --------------------------------------+------------------------------------- Changes (by simonmar): * difficulty: => Unknown Old description: > foldB has O(1) complexity, but foldA O(N). Looks like a strictness > analyzer failure. > > module Main where > > foldA :: (a -> e -> a) -> a -> [e] -> a > foldA _ r [] = r > foldA op r (x:xs) = foldA op (op r x) xs > > foldB :: (a -> e -> a) -> a -> [e] -> a > foldB _ r [] = r > foldB op r (x:xs) = r' `seq` foldB op r' xs where r' = op r x > > l :: [Int] > l = [1..100*1000*1000] > > main = print $ foldl (+) 0 l New description: foldB has O(1) complexity, but foldA O(N). Looks like a strictness analyzer failure. {{{ module Main where foldA :: (a -> e -> a) -> a -> [e] -> a foldA _ r [] = r foldA op r (x:xs) = foldA op (op r x) xs foldB :: (a -> e -> a) -> a -> [e] -> a foldB _ r [] = r foldB op r (x:xs) = r' `seq` foldB op r' xs where r' = op r x l :: [Int] l = [1..100*1000*1000] main = print $ foldl (+) 0 l }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 10 05:36:46 2008 From: trac at galois.com (GHC) Date: Mon Nov 10 05:31:24 2008 Subject: [GHC] #2754: Strictness analyzer fails on an implementation of foldl In-Reply-To: <045.b34db0d1501300b44384b2b8b33f4b1f@localhost> References: <045.b34db0d1501300b44384b2b8b33f4b1f@localhost> Message-ID: <054.c48c61a6944cbe22b91d7d8f6f5fa695@localhost> #2754: Strictness analyzer fails on an implementation of foldl --------------------------------------+------------------------------------- Reporter: nimnul | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | --------------------------------------+------------------------------------- Comment (by simonmar): Could you be more clear about what behaviour you claim is wrong here? The example code doesn't use `foldA` or `foldB`. `foldA` is just `foldl`, which has well-known performance issues, and `foldB` is the same as `foldl'`, available from the `Data.List` module. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 10 05:42:56 2008 From: trac at galois.com (GHC) Date: Mon Nov 10 05:37:33 2008 Subject: [GHC] #2753: GHC 6.10.1 cannot compile Crypto-4.1.0 In-Reply-To: <052.22581ce23675b5d58c2247a1ee1a7ede@localhost> References: <052.22581ce23675b5d58c2247a1ee1a7ede@localhost> Message-ID: <061.4d44c36f21b251dcca3e77674dab5c41@localhost> #2753: GHC 6.10.1 cannot compile Crypto-4.1.0 ------------------------------+--------------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: critical | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by simonmar): * difficulty: => Unknown * os: MacOS X => Unknown/Multiple * milestone: => 6.10.2 Comment: I don't think it was ever fixed, it may have just stopped happening for a while for unrelated reasons. The problem is that the spill code in the linear register allocator is pretty stupid and doesn't try to re-use spill slots. Also, we only have a fixed number of spill slots, because we have a fixed-size frame on the C stack in which to spill into, which is currently 2048 words. We could certainly bump the size of this without any serious adverse effects (`includes/Constants.h`, `RESERVED_C_STACK_BYTES`). I suggest that as a workaround for 6.10.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 10 05:50:58 2008 From: trac at galois.com (GHC) Date: Mon Nov 10 05:45:33 2008 Subject: [GHC] #2756: state hack causes unneeded value to be evaluated In-Reply-To: <044.fd970d5f81038e1e8c0cb54c1d8b0d1b@localhost> References: <044.fd970d5f81038e1e8c0cb54c1d8b0d1b@localhost> Message-ID: <053.fcb83588d085f0d25555a5b10cd72092@localhost> #2756: state hack causes unneeded value to be evaluated ------------------------------+--------------------------------------------- Reporter: int-e | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by simonmar): * difficulty: => Unknown * milestone: => 6.10.2 Comment: Good bug. I don't think this is caused by `-fno-state-hack`. The code coming out of the simplifier is fine; this is `newX`: {{{ a_rus = \ (n_afy :: ()) (eta_ssU :: GHC.Prim.State# GHC.Prim.RealWorld) -> (# eta_ssU, Main.X (let { value_sub [NEVER Just S] :: () [Str: DmdType] value_sub = n_afy } in value_sub) #) }}} The prep phase lifts out that `let`, but doesn't reset its strictness annotation, which changes the meaning of the program: {{{ a_rus = \ (n_suA :: ()) (eta_suy :: GHC.Prim.State# GHC.Prim.RealWorld) -> let { sat_suE :: Main.X [] sat_suE = case n_suA of value_suC [NEVER Just S] { __DEFAULT -> Main.X value_suC } } in (# eta_suy, sat_suE #) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 10 08:07:38 2008 From: trac at galois.com (GHC) Date: Mon Nov 10 08:02:14 2008 Subject: [GHC] #2754: Strictness analyzer fails on an implementation of foldl In-Reply-To: <045.b34db0d1501300b44384b2b8b33f4b1f@localhost> References: <045.b34db0d1501300b44384b2b8b33f4b1f@localhost> Message-ID: <054.f048d41888bc05644da57ba67abafc95@localhost> #2754: Strictness analyzer fails on an implementation of foldl --------------------------------------+------------------------------------- Reporter: nimnul | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | --------------------------------------+------------------------------------- Comment (by nimnul): You just replace foldl with foldA and foldB. The test code fragments are {{{ main = print $ foldA (+) 0 l }}} and {{{ main = print $ foldB (+) 0 l }}} First of all, {{{foldl}}} works - it takes my pc about a second to calculate the correct answer - {{{987459712}}}, without excessive heap or stack usage. While {{{foldA}}} is semantically equivalent to {{{foldl}}}, it has different spatial complexity than current implementation of {{{foldl}}} in {{{Prelude}}} - I get heap overflow with such a big list {{{l}}}. The bug is that ghc generates inefficient code for a naive implementation of {{{foldl}}}. This behavior is strange, because in similar cases the optimizer works perfectly. Even if you just "inline {{{op}}}", I mean substitute {{{op}}} for its value {{{(+)}}}, memory is not eaten up any more: {{{ foldC r [] = r foldC r (x:xs) = foldC ((+) r x) xs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 10 09:13:35 2008 From: trac at galois.com (GHC) Date: Mon Nov 10 09:08:19 2008 Subject: [GHC] #2759: Data.Generics.ConstrRep isn't general enough Message-ID: <044.ed7d09d66854fb1616fb1d1343b2d811@localhost> #2759: Data.Generics.ConstrRep isn't general enough ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: minor Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ The type ConstrRep in Data.Generics is used to represent constructors for types. The FloatConstr constructor is the one used for all kinds of floating point primitives. But FloatConstr has an argument of type Double. This limits the primitive floating point types to those that are accurately representable as a Double. In other places in Haskell where an accurate and generic floating point value is needed the type Rational is used. It should be used here too. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 10 09:22:49 2008 From: trac at galois.com (GHC) Date: Mon Nov 10 09:17:29 2008 Subject: [GHC] #2760: Data.Generics.Basics.mkNoreptype spelled wrong Message-ID: <044.b3884d30a8391ab9f46e5542669e8ee1@localhost> #2760: Data.Generics.Basics.mkNoreptype spelled wrong ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: minor Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ To be consistent with the constructor name NoRep this function should be mkNoRepType. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 10 09:52:15 2008 From: trac at galois.com (GHC) Date: Mon Nov 10 09:46:49 2008 Subject: [GHC] #2761: type checker bug Message-ID: <044.2091feeeccc6148f5f881c90c5760fb9@localhost> #2761: type checker bug ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ This causes a type error: foo :: forall b. (b -> String, Int) foo = (const "hi", 0) bar :: (forall b. b -> String, Int) bar = foo This should compile fine since the types are equivalent. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 10 11:24:07 2008 From: trac at galois.com (GHC) Date: Mon Nov 10 11:18:41 2008 Subject: [GHC] #2761: type checker bug In-Reply-To: <044.2091feeeccc6148f5f881c90c5760fb9@localhost> References: <044.2091feeeccc6148f5f881c90c5760fb9@localhost> Message-ID: <053.2a32e25672467312cd51228c66f4874b@localhost> #2761: type checker bug ----------------------------------------+----------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ----------------------------------------+----------------------------------- Comment (by guest): Sorry about bad formatting before... This produces a type error: {{{ foo :: forall b. (b -> String, Int) foo = (const "hi", 0) bar :: (forall b. b -> String, Int) bar = foo }}} But the types are equivalent. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 10 11:55:57 2008 From: trac at galois.com (GHC) Date: Mon Nov 10 11:50:30 2008 Subject: [GHC] #2762: Excessive heap usage Message-ID: <044.bf1fb1b8e171504548cbe3cb91273ef8@localhost> #2762: Excessive heap usage ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.11 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ With `Main.hs`: {{{ module Main (main) where import InputOutput main :: IO () main = do let content1 = concat (replicate 1000000 "1x") ++ "0" let i1 = fst $ input content1 view i1 let content2 = concat (replicate 1000001 "1y") ++ "0" let i2 = fst $ input content2 view i2 view :: [Char] -> IO () view [] = return () view (i : is) = i `seq` view is }}} and `InputOutput.hs`: {{{ module InputOutput (input) where class InputOutput a where input :: String -> (a, String) instance InputOutput Char where input (x : bs) = (x, bs) instance InputOutput a => InputOutput [a] where input ('0':bs) = ([], bs) input ('1':bs) = case input bs of (x, bs') -> case input bs' of ~(xs, bs'') -> (x : xs, bs'') }}} according to {{{ ghc -O -prof -auto-all --make Main.hs -fforce-recomp ./Main +RTS -h }}} heap usage goes up to about 20M with the HEAD, but only about 200 bytes with 6.8.2. This is with 6.11.20081108, but I started investigating with the HEAD when I saw similar problems with more-or-less 6.10.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 10 12:14:45 2008 From: trac at galois.com (GHC) Date: Mon Nov 10 12:09:19 2008 Subject: [GHC] #2189: hSetBuffer stdin NoBuffering doesn't seem to work in ghc 6.8.2 on Windows XP In-Reply-To: <047.b31f95b84e60784da45a33105d44ed84@localhost> References: <047.b31f95b84e60784da45a33105d44ed84@localhost> Message-ID: <056.6da63cfee374162f06c4f22670522160@localhost> #2189: hSetBuffer stdin NoBuffering doesn't seem to work in ghc 6.8.2 on Windows XP --------------------------------------------+------------------------------- Reporter: FalconNL | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: Keywords: hsetbuffering buffering buffer | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | --------------------------------------------+------------------------------- Comment (by camio): Alistar Bayley noted this workaround in haskell-cafe {{{ {-# LANGUAGE ForeignFunctionInterface #-} import Data.Char import Control.Monad (liftM) import Foreign.C.Types getHiddenChar = liftM (chr.fromEnum) c_getch foreign import ccall unsafe "conio.h getch" c_getch :: IO CInt }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 10 12:26:28 2008 From: trac at galois.com (GHC) Date: Mon Nov 10 12:21:04 2008 Subject: [GHC] #2754: Strictness analyzer fails on an implementation of foldl In-Reply-To: <045.b34db0d1501300b44384b2b8b33f4b1f@localhost> References: <045.b34db0d1501300b44384b2b8b33f4b1f@localhost> Message-ID: <054.d2761a00c459aa97a19680169aeee540@localhost> #2754: Strictness analyzer fails on an implementation of foldl --------------------------------------+------------------------------------- Reporter: nimnul | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | --------------------------------------+------------------------------------- Comment (by dons): nimul, this might explain the behaviour you see: {{{ -- We write foldl as a non-recursive thing, so that it -- can be inlined, and then (often) strictness-analysed, -- and hence the classic space leak on foldl (+) 0 xs foldl :: (a -> b -> a) -> a -> [b] -> a foldl f z0 xs0 = lgo z0 xs0 where lgo z [] = z lgo z (x:xs) = lgo (f z x) xs }}} If I remember correctly from the discussion with nimul in #haskell, his view was that the strictness analyser wasn't sufficiently powerful: it doesn't do magic. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 10 12:49:21 2008 From: trac at galois.com (GHC) Date: Mon Nov 10 12:44:02 2008 Subject: [GHC] #2754: Strictness analyzer fails on an implementation of foldl In-Reply-To: <045.b34db0d1501300b44384b2b8b33f4b1f@localhost> References: <045.b34db0d1501300b44384b2b8b33f4b1f@localhost> Message-ID: <054.e7064c9b5bffa5c9f4bd33b0701034b6@localhost> #2754: Strictness analyzer fails on an implementation of foldl --------------------------------------+------------------------------------- Reporter: nimnul | Owner: Type: run-time performance bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | --------------------------------------+------------------------------------- Changes (by igloo): * status: new => closed * resolution: => invalid Comment: Right, `foldA` is only strict in `r` if `op` is strict in its first argument. Depending on how you write `foldA`, and what other optimisations (such as inlining) happen, GHC might be able to tell that `op` is indeed strict in its first argument, but otherwise it must assume that it is not. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 10 13:20:28 2008 From: trac at galois.com (GHC) Date: Mon Nov 10 13:15:08 2008 Subject: [GHC] #2761: type checker bug In-Reply-To: <044.2091feeeccc6148f5f881c90c5760fb9@localhost> References: <044.2091feeeccc6148f5f881c90c5760fb9@localhost> Message-ID: <053.3752f3d15dce9eedb062e29968b8690d@localhost> #2761: type checker bug -------------------------------------+-------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | -------------------------------------+-------------------------------------- Changes (by igloo): * difficulty: => Unknown Old description: > This causes a type error: > > foo :: forall b. (b -> String, Int) > foo = (const "hi", 0) > > bar :: (forall b. b -> String, Int) > bar = foo > > This should compile fine since the types are equivalent. New description: This causes a type error: {{{ foo :: forall b. (b -> String, Int) foo = (const "hi", 0) bar :: (forall b. b -> String, Int) bar = foo }}} This should compile fine since the types are equivalent. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 10 13:26:39 2008 From: trac at galois.com (GHC) Date: Mon Nov 10 13:21:14 2008 Subject: [GHC] #2761: type checker bug In-Reply-To: <044.2091feeeccc6148f5f881c90c5760fb9@localhost> References: <044.2091feeeccc6148f5f881c90c5760fb9@localhost> Message-ID: <053.36408e315373859e498ee0e4b59600d5@localhost> #2761: type checker bug -------------------------------------+-------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.8.3 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | -------------------------------------+-------------------------------------- Changes (by igloo): * status: new => closed * resolution: => invalid Comment: Thanks for the report! However, the types are not equivalent, e.g. this fails to typecheck: {{{ foo :: forall b. (b -> String, Int) foo = undefined x :: (String, String) x = case foo of (f, _) -> (f 'a', f True) }}} with: {{{ Couldn't match expected type `Char' against inferred type `Bool' In the first argument of `f', namely `True' In the expression: f True In the expression: (f 'a', f True) }}} but this does typecheck: {{{ bar :: (forall b. b -> String, Int) bar = undefined x :: (String, String) x = case bar of (f, _) -> (f 'a', f True) }}} (with `-XImpredicativeTypes -XRank2Types`) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 10 13:34:55 2008 From: trac at galois.com (GHC) Date: Mon Nov 10 13:29:34 2008 Subject: [GHC] #2189: hSetBuffering stdin NoBuffering doesn't work on Windows In-Reply-To: <047.b31f95b84e60784da45a33105d44ed84@localhost> References: <047.b31f95b84e60784da45a33105d44ed84@localhost> Message-ID: <056.aa5376eed6d682ea4483ed3f9ef0086d@localhost> #2189: hSetBuffering stdin NoBuffering doesn't work on Windows --------------------------------------------+------------------------------- Reporter: FalconNL | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: Keywords: hsetbuffering buffering buffer | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | --------------------------------------------+------------------------------- Changes (by Deewiant): * cc: Deewiant (added) * summary: hSetBuffer stdin NoBuffering doesn't seem to work in ghc 6.8.2 on Windows XP => hSetBuffering stdin NoBuffering doesn't work on Windows Comment: Unfortunately conio doesn't mix with ordinary IO, as I demonstrated in a response to that thread on glasgow-haskell-users. As for the original problem, I think this'd take some work to solve: GHC would have to convert to the Win32 API for all of its IO on Windows. (That'd also help with #806.) What currently happens is the following call chain, starting from `hGetChar` (a bit of documentation for any would-be fixers): {{{ System.IO.hGetChar stdin -- meanings of numbers: stdin FD, not a socket, offset 0, length 1 GHC.Handle.readRawBuffer "hGetChar" 0 0 0 1 GHC.Handle.asyncReadRawBuffer 0 0 0 1 GHC.Conc.asyncReadBA 0 0 1 0 -- offset got applied GHC.Conc.asyncRead 0 0 1 -- asyncReadzh_fast in rts/PrimOps.cmm asyncRead# 0 0 1 -- in rts/win32/AsyncIO.c -- the new 0 signifies that this is a read and not a write addIORequest(0, 0, 0, 1, ) }}} From there it ends up into the asynchronous IO work queue, whence it eventually gets picked up by `IOWorkerProc` (in rts/win32/IOManager.c). It notices that the `workKind` is `WORKER_READ` but not `WORKER_FOR_SOCKET`, so it does a plain `read()` call. In the current situation that's basically fine, since the `hSetBuffering` never did anything and we're still in line buffered mode. In unbuffered mode, that'd be a problem, as the comment from System.Posix.Internals (which judah posted above) asserts: enter needs to be pressed twice. The fact that it gives '\r' instead of '\n' isn't such a big problem since it can be easily modified. I'm attaching a C program which shows how the problem is avoided by using the Win32 API directly (in this case, `ReadFile` is fine) instead of the POSIX `read`: the latter requires two presses of enter, the former only one. Since there seems to be no way of getting a Win32 `HANDLE` object from a C `FILE*` let alone a POSIX file descriptor, I believe that the only reasonable way of getting this and #806 to work reliably is to convert the whole IO subsystem to use the Windows API directly?starting from changing `GHC.IOBase.Handle__.haFD` from an `FD` to a `HANDLE` on Windows. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 10 14:03:35 2008 From: trac at galois.com (GHC) Date: Mon Nov 10 13:58:10 2008 Subject: [GHC] #2761: type checker bug In-Reply-To: <044.2091feeeccc6148f5f881c90c5760fb9@localhost> References: <044.2091feeeccc6148f5f881c90c5760fb9@localhost> Message-ID: <053.8126e2fb2a92b6b2a60c38b3967c2f90@localhost> #2761: type checker bug -------------------------------------+-------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.8.3 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | -------------------------------------+-------------------------------------- Changes (by sclv): * cc: sclv (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 10 14:58:11 2008 From: trac at galois.com (GHC) Date: Mon Nov 10 14:52:45 2008 Subject: [GHC] #2763: while installing cabal from darcs, 1.6.0.1 and 1.4.0.2 Message-ID: <044.967654beccd358d1d0ac92f7259473da@localhost> #2763: while installing cabal from darcs, 1.6.0.1 and 1.4.0.2 ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: cabal ghc ubuntu | Testcase: Architecture: x86_64 (amd64) | Os: Linux ---------------------------------+------------------------------------------ I can't build cabal 1.4.0.2, cabal from darcs and cabal 1.6.0.1 Running ubuntu 8.04, running ghc that comes with it root@burn:~/projects/haskell/Cabal-1.4.0.2# ghc -v Glasgow Haskell Compiler, Version 6.8.2, for Haskell 98, stage 2 booted by GHC version 6.8.2 Using package config file: /usr/lib/ghc-6.8.2/package.conf Using package config file: /home/abez/.ghc/x86_64-linux-6.8.2/package.conf hiding package mtl-1.1.0.0 to avoid conflict with later version mtl-1.1.0.1 wired-in package base mapped to base-3.0.1.0 wired-in package rts mapped to rts-1.0 wired-in package haskell98 mapped to haskell98-1.0.1.0 wired-in package template-haskell mapped to template-haskell-2.2.0.0 wired-in package ndp not found. Hsc static flags: -static *** Deleting temp files: Deleting: *** Deleting temp dirs: Deleting: ghc-6.8.2: no input files Usage: For basic information, try the `--help' option. root@burn:~/projects/haskell/Cabal-1.4.0.2# ghc -v Glasgow Haskell Compiler, Version 6.8.2, for Haskell 98, stage 2 booted by GHC version 6.8.2 Using package config file: /usr/lib/ghc-6.8.2/package.conf Using package config file: /home/abez/.ghc/x86_64-linux-6.8.2/package.conf hiding package mtl-1.1.0.0 to avoid conflict with later version mtl-1.1.0.1 wired-in package base mapped to base-3.0.1.0 wired-in package rts mapped to rts-1.0 wired-in package haskell98 mapped to haskell98-1.0.1.0 wired-in package template-haskell mapped to template-haskell-2.2.0.0 wired-in package ndp not found. Hsc static flags: -static *** Deleting temp files: Deleting: *** Deleting temp dirs: Deleting: ghc-6.8.2: no input files Usage: For basic information, try the `--help' option. root@burn:~/projects/haskell/Cabal-1.4.0.2# uname -a Linux burn 2.6.24-19-generic #1 SMP Wed Aug 20 17:53:40 UTC 2008 x86_64 GNU/Linux root@burn:~/projects/haskell/Cabal-1.4.0.2# ./Setup build Preprocessing library Cabal-1.4.0.2... Building Cabal-1.4.0.2... [13 of 45] Compiling Distribution.Simple.Utils ( Distribution/Simple/Utils.hs, dist/build/Distribution/Simple/Utils.o ) ghc-6.8.2: panic! (the 'impossible' happened) (GHC version 6.8.2 for x86_64-unknown-linux): applyTypeToArgs unix-2.3.0.0:System.Posix.Signals.a38{v rBu} [gid] (unix-2.3.0.0:System.Posix.Signals.a5{v rBt} [gid] `cast` (base:GHC.Prim.sym{(w) tc 34v} (base:Foreign.C.Types.:CoCInt{tc ryy}) :: base:GHC.Int.Int32{tc 3V} ~ base:Foreign.C.Types.CInt{tc rz9})) unix-2.3.0.0:System.Posix.Signals.Ignore{v rBs} [gid] (base:Data.Maybe.Nothing{v r6a} [gid] @ unix-2.3.0.0:System.Posix.Signals.SignalSet{tc rBr}) eta{v a2Rl} [lid] (# base:GHC.Prim.State#{(w) tc 32q} base:GHC.Prim.RealWorld{(w) tc 31E}, unix-2.3.0.0:System.Posix.Signals.SignalSet{tc rBr} #) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Another one: @burn:~/projects/haskell/cabal$ ./Setup build Preprocessing library Cabal-1.6.0.1... Building Cabal-1.6.0.1... [ 1 of 50] Compiling Distribution.Simple.GHC.Makefile ( Distribution/Simple/GHC/Makefile.hs, dist/build/Distribution/Simple/GHC/Makefile.o ) [ 2 of 50] Compiling Distribution.Compat.Permissions ( Distribution/Compat/Permissions.hs, dist/build/Distribution/Compat/Permissions.o ) [ 3 of 50] Compiling Distribution.Compat.Exception ( Distribution/Compat/Exception.hs, dist/build/Distribution/Compat/Exception.o ) [ 4 of 50] Compiling Distribution.Compat.TempFile ( Distribution/Compat/TempFile.hs, dist/build/Distribution/Compat/TempFile.o ) [ 5 of 50] Compiling Distribution.GetOpt ( Distribution/GetOpt.hs, dist/build/Distribution/GetOpt.o ) [ 6 of 50] Compiling Distribution.Compat.ReadP ( Distribution/Compat/ReadP.hs, dist/build/Distribution/Compat/ReadP.o ) [ 7 of 50] Compiling Distribution.Text ( Distribution/Text.hs, dist/build/Distribution/Text.o ) [ 8 of 50] Compiling Distribution.Version ( Distribution/Version.hs, dist/build/Distribution/Version.o ) [ 9 of 50] Compiling Language.Haskell.Extension ( Language/Haskell/Extension.hs, dist/build/Language/Haskell/Extension.o ) [10 of 50] Compiling Distribution.System ( Distribution/System.hs, dist/build/Distribution/System.o ) [11 of 50] Compiling Distribution.Simple.PreProcess.Unlit ( Distribution/Simple/PreProcess/Unlit.hs, dist/build/Distribution/Simple/PreProcess/Unlit.o ) [12 of 50] Compiling Distribution.ReadE ( Distribution/ReadE.hs, dist/build/Distribution/ReadE.o ) [13 of 50] Compiling Distribution.Verbosity ( Distribution/Verbosity.hs, dist/build/Distribution/Verbosity.o ) [14 of 50] Compiling Distribution.Package ( Distribution/Package.hs, dist/build/Distribution/Package.o ) [15 of 50] Compiling Distribution.ModuleName ( Distribution/ModuleName.hs, dist/build/Distribution/ModuleName.o ) [16 of 50] Compiling Distribution.Simple.Utils ( Distribution/Simple/Utils.hs, dist/build/Distribution/Simple/Utils.o ) ghc-6.8.2: panic! (the 'impossible' happened) (GHC version 6.8.2 for x86_64-unknown-linux): applyTypeToArgs unix-2.3.0.0:System.Posix.Signals.a38{v roIc} [gid] (unix-2.3.0.0:System.Posix.Signals.a5{v roIb} [gid] `cast` (base:GHC.Prim.sym{(w) tc 34v} (base:Foreign.C.Types.:CoCInt{tc r1dN}) :: base:GHC.Int.Int32{tc 3V} ~ base:Foreign.C.Types.CInt{tc r17X})) unix-2.3.0.0:System.Posix.Signals.Ignore{v roIa} [gid] (base:Data.Maybe.Nothing{v r6E} [gid] @ unix-2.3.0.0:System.Posix.Signals.SignalSet{tc roI9}) eta{v apPk} [lid] (# base:GHC.Prim.State#{(w) tc 32q} base:GHC.Prim.RealWorld{(w) tc 31E}, unix-2.3.0.0:System.Posix.Signals.SignalSet{tc roI9} #) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 10 16:44:47 2008 From: trac at galois.com (GHC) Date: Mon Nov 10 16:39:29 2008 Subject: [GHC] #1872: Extensible Records In-Reply-To: <044.1644b4d2ed2831e3dac4855a76eabeb0@localhost> References: <044.1644b4d2ed2831e3dac4855a76eabeb0@localhost> Message-ID: <053.0f46373e4673d18321d15ef133991a87@localhost> #1872: Extensible Records -----------------------------------+---------------------------------------- Reporter: gidyn | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: Extensible Records | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple -----------------------------------+---------------------------------------- Changes (by guest): * version: => 6.11 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 10 18:44:02 2008 From: trac at galois.com (GHC) Date: Mon Nov 10 18:38:35 2008 Subject: [GHC] #2764: gen_contents_index generates links with package.haddock in the path Message-ID: <050.3f1d57166b0bf0e303ef4a1822302d5d@localhost> #2764: gen_contents_index generates links with package.haddock in the path ---------------------------------+------------------------------------------ Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Component: Documentation Version: 6.10.1 | Severity: normal Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ If one runs gen_contents_index in libraries/ it generates broken links to the documentation for packages. I will attach a simple patch to fix this. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 10 19:33:37 2008 From: trac at galois.com (GHC) Date: Mon Nov 10 19:28:11 2008 Subject: [GHC] #2754: Strictness analyzer fails on an implementation of foldl In-Reply-To: <045.b34db0d1501300b44384b2b8b33f4b1f@localhost> References: <045.b34db0d1501300b44384b2b8b33f4b1f@localhost> Message-ID: <054.0af3cd638d6f8d881fab8ec6999552e4@localhost> #2754: Strictness analyzer fails on an implementation of foldl --------------------------------------+------------------------------------- Reporter: nimnul | Owner: Type: run-time performance bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | --------------------------------------+------------------------------------- Comment (by nimnul): Replying to [comment:4 dons]: > nimul, this might explain the behaviour you see: > > {{{ > -- We write foldl as a non-recursive thing, so that it > -- can be inlined, (skipped) }}} foldC is recursive, but is optimized correctly. So recursion in foldA is not an argument. > If I remember correctly from the discussion with nimul in #haskell, his view was that the strictness analyser wasn't sufficiently powerful: it doesn't do magic. No optimizer does magic. But optimizers do evolve, and new versions of say gcc perform more and more optimizations. GCC team at least accepts cases when GCC optimizer fails to produce optimal code as enhancement requests. You can find a lot of such requests in the GCC bug tracker, for example, http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28364. Is there any reason why GHC team don't follow them and don't accept such requests? Is there any reason why my case is not a failing simple test case for GHC optimizer, and thus cannot be accepted as an enhancement request? The current behaviour (not inlining op) and the desired behaviour (to inline op if it's known to be strict and then proceed with already implemented optimizations) are clear. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 10 20:00:38 2008 From: trac at galois.com (GHC) Date: Mon Nov 10 19:55:13 2008 Subject: [GHC] #2754: Strictness analyzer fails on an implementation of foldl In-Reply-To: <045.b34db0d1501300b44384b2b8b33f4b1f@localhost> References: <045.b34db0d1501300b44384b2b8b33f4b1f@localhost> Message-ID: <054.d6adf031b2eea9bfbd19c59c06cfb614@localhost> #2754: Strictness analyzer fails on an implementation of foldl -----------------------------+---------------------------------------------- Reporter: nimnul | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | -----------------------------+---------------------------------------------- Changes (by dons): * type: run-time performance bug => feature request Comment: Ah, much clearer. So what we have is not a bug, but rather a feature request: you would like the strictness analyser extended in some way such that foldl is always equivalent to foldl'. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 10 20:42:48 2008 From: trac at galois.com (GHC) Date: Mon Nov 10 20:37:22 2008 Subject: [GHC] #2754: Strictness analyzer fails on an implementation of foldl In-Reply-To: <045.b34db0d1501300b44384b2b8b33f4b1f@localhost> References: <045.b34db0d1501300b44384b2b8b33f4b1f@localhost> Message-ID: <054.78370e0518b80a22130e0f2da9b51332@localhost> #2754: Strictness analyzer fails on an implementation of foldl -----------------------------+---------------------------------------------- Reporter: nimnul | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | -----------------------------+---------------------------------------------- Comment (by igloo): Replying to [comment:6 nimnul]: > Replying to [comment:4 dons]: > > nimul, this might explain the behaviour you see: > > > > {{{ > > -- We write foldl as a non-recursive thing, so that it > > -- can be inlined, (skipped) > }}} > > foldC is recursive, but is optimized correctly. So recursion in foldA is not an argument. Right, the strictness analyser understand recursion, that's not the problem. Let me try and explain the differences. With `foldl`: {{{ foldl :: (a -> b -> a) -> a -> [b] -> a foldl f z0 xs0 = lgo z0 xs0 where lgo z [] = z lgo z (x:xs) = lgo (f z x) xs }}} if you have a use {{{ main = print $ foldl (+) 0 l }}} then GHC inlines the definition of `foldl` where it is used. The `(+)` is then inlined for `f` in this copy of `foldl`, the strictness analyser can tell that it is strict, and you get the behaviour that you want. If you use `foldA` instead: {{{ foldA :: (a -> e -> a) -> a -> [e] -> a foldA _ r [] = r foldA op r (x:xs) = foldA op (op r x) xs }}} then the definition won't be inlined, because GHC deliberately doesn't inline recursive definitions. Instead, you get a call to the generic `foldA` code, which can't assume that `op` is strict in its first argument, so you get the large thunk built. If you use `foldC`: {{{ foldC r [] = r foldC r (x:xs) = foldC ((+) r x) xs }}} then the strictness analyser can again see that the function you are using (`(+)`) is strict and so you get the behaviour that you want. (actually, this is only because you end up with a version specialised for `Int`; if you define foldC in a different module then I suspect you'll get a large thunk built again). > Is there any reason why my case is not a failing simple test case for GHC optimizer, and thus cannot be accepted as an enhancement request? The current behaviour (not inlining op) and the desired behaviour (to inline op if it's known to be strict and then proceed with already implemented optimizations) are clear. You could certainly make changes to the optimiser that make this case better, but there would be other cases that those changes would make worse. This (`foldl (+)`) is a well-known example, and I don't think that having this ticket open would be useful. I'm sure that if Simon disagrees then he well re-open it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 10 23:37:07 2008 From: trac at galois.com (GHC) Date: Mon Nov 10 23:31:42 2008 Subject: [GHC] #2754: Strictness analyzer fails on an implementation of foldl In-Reply-To: <045.b34db0d1501300b44384b2b8b33f4b1f@localhost> References: <045.b34db0d1501300b44384b2b8b33f4b1f@localhost> Message-ID: <054.bec41e2524744be339f0ffa594394694@localhost> #2754: Strictness analyzer fails on an implementation of foldl -----------------------------+---------------------------------------------- Reporter: nimnul | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | -----------------------------+---------------------------------------------- Comment (by nimnul): Replying to [comment:7 dons]: > Ah, much clearer. > > So what we have is not a bug, but rather a feature request: you would like the strictness analyser extended in some way such that foldl is always equivalent to foldl'. No no. foldl and foldl' are different functions. While foldl performs extra graph node allocations, compared to foldl', when op is strict, foldl' performs extra reductions if op is not strict. For tight loops like this foldl' is better than foldl. But if op is not strict and a lot of computations can be saved by not evaluating certain intermediate r, foldl can be better. Am I wrong? I don't want foldl to be always equivalent to foldl'. I only want them to be equivalent if op is strict in r. The problem is complex - while foldA and foldB differ only by a strictness annotation, the reason why compiler fails to insert the annotation may be not related to the strictness analyzer at all. It can be specializer failure (does ghc has one?), inliner failure, missing rewrite rules in the optimizer, anything. And it is not necessary to fix the problem by fixing optimizer - a workaround could be provided so one can use pragmas to achieve the result. Now INLINE pragma doesn't work because foldA is recursive, and that's ok, but the SPECIALIZE pragma is somewhat limited and can be improved - for example, I cannot tell the compiler to specialize foldA by inlining its first argument. Such specialization is not my invention - it has been used for years in C++ to avoid indirect calls when a function object is passed to a template function. And modern c++ compilers such as Microsoft's and GCC can even instantiate functions accepting function pointers. While automated instantiation and inlining is cumbersome to implement, and both inlining/specializing everything and inlining/specializing nothing can lead to poor performance, a developer should be able to hint - such tuning may be beneficial for libraries. And better "self-optimizing" libraries like Stream Fusion make life better for library users like me, as high-performance libraries reduce the need for performance profiling and optimizations in client code. So there can be very different ways to improve compilation of code fragments like foldA. And it's not just a narrow problem of programmers trying to reimplement foldl - I believe there are other scenarios when recursive definitions fail to optimize because they cannot be inlined. I cannot suggest exactly what the problem is, and how is better to fix it - I have a faint idea what happens inside of GHC optimizer. I'm merely reporting code which is problematic for current optimizer. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 11 03:50:44 2008 From: trac at galois.com (GHC) Date: Tue Nov 11 03:45:18 2008 Subject: [GHC] #2189: hSetBuffering stdin NoBuffering doesn't work on Windows In-Reply-To: <047.b31f95b84e60784da45a33105d44ed84@localhost> References: <047.b31f95b84e60784da45a33105d44ed84@localhost> Message-ID: <056.c7477cd1584317726758c11b226c6a93@localhost> #2189: hSetBuffering stdin NoBuffering doesn't work on Windows --------------------------------------------+------------------------------- Reporter: FalconNL | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: Keywords: hsetbuffering buffering buffer | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | --------------------------------------------+------------------------------- Comment (by simonmar): First, I completely agree that we should be using the Win32 API directly instead of the POSIX compatibility layer. It's that way for historical reasons - I think it was easier to port the IO library to Windows in the first place by using the POSIX layer. As you say, #806 would be helped by that, but also the Windows side of #635, and #989. The call sequence you posted only applies to the non-threaded RTS. With the threaded RTS, everything is in the IO library. We still end up calling `read()`, but directly from Haskell. Incedentally, there ''is'' a way to get a `HANDLE` from a file descriptor: `_get_osfhandle(fd)`. You might want to look at `libraries\base\cbits\inputReady.c` for some serious console hackery. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 11 04:01:42 2008 From: trac at galois.com (GHC) Date: Tue Nov 11 03:56:14 2008 Subject: [GHC] #2754: Strictness analyzer fails on an implementation of foldl In-Reply-To: <045.b34db0d1501300b44384b2b8b33f4b1f@localhost> References: <045.b34db0d1501300b44384b2b8b33f4b1f@localhost> Message-ID: <054.c678ffedae04139c8aa6e6da104fc229@localhost> #2754: Strictness analyzer fails on an implementation of foldl -----------------------------+---------------------------------------------- Reporter: nimnul | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | -----------------------------+---------------------------------------------- Comment (by simonmar): It does seem reasonable to want to be able to create specialised versions of recursive functions, and we even have some of the machinery for doing so (SpecConstr). We should wait until Simon PJ can comment though (he's away this week). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 11 04:03:25 2008 From: trac at galois.com (GHC) Date: Tue Nov 11 03:57:56 2008 Subject: [GHC] #2764: gen_contents_index generates links with package.haddock in the path In-Reply-To: <050.3f1d57166b0bf0e303ef4a1822302d5d@localhost> References: <050.3f1d57166b0bf0e303ef4a1822302d5d@localhost> Message-ID: <059.c9a8161c11277aa1ea017b0e17ad6e7e@localhost> #2764: gen_contents_index generates links with package.haddock in the path ---------------------------------+------------------------------------------ Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ Comment (by juhpetersen): I darcs-sent the patch also to ghc-cvs. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 11 04:04:28 2008 From: trac at galois.com (GHC) Date: Tue Nov 11 03:59:00 2008 Subject: [GHC] #2758: runghc in stdin mode ignores Ctrl-C on Windows, cannot be killed In-Reply-To: <047.917d1da3b05e4d79bd411a581a2d9795@localhost> References: <047.917d1da3b05e4d79bd411a581a2d9795@localhost> Message-ID: <056.2294c6bd044c158bb508ae31e2d769b6@localhost> #2758: runghc in stdin mode ignores Ctrl-C on Windows, cannot be killed ----------------------+----------------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------+----------------------------------------------------- Changes (by simonmar): * os: Unknown/Multiple => Windows * architecture: Unknown/Multiple => x86 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 11 04:07:41 2008 From: trac at galois.com (GHC) Date: Tue Nov 11 04:02:16 2008 Subject: [GHC] #2189: hSetBuffering stdin NoBuffering doesn't work on Windows In-Reply-To: <047.b31f95b84e60784da45a33105d44ed84@localhost> References: <047.b31f95b84e60784da45a33105d44ed84@localhost> Message-ID: <056.c35f2d72fdaa5be645f4e81ac59000f7@localhost> #2189: hSetBuffering stdin NoBuffering doesn't work on Windows --------------------------------------------+------------------------------- Reporter: FalconNL | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: Keywords: hsetbuffering buffering buffer | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | --------------------------------------------+------------------------------- Comment (by Deewiant): Heh, I just noticed that `_get_osfhandle` is used about 30 lines down from the code I was looking at last time. Thanks for the heads up. Using it this might be fixable with a lot less work by just changing the `read` call in `IOWorkerProc` to a `ReadFile`. The threaded RTS seems to end up in `__hscore_PrelHandle_read` in `libraries/base/include/HsBase.h` which is again just a `read` call and might be convertable to `ReadFile` without too much trouble. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 11 04:53:41 2008 From: trac at galois.com (GHC) Date: Tue Nov 11 04:48:17 2008 Subject: [GHC] #2765: unsetenv not found under Solaris 8 when building ghc-6.10.1 Message-ID: <045.123eb53c80ae5471f437c79b85fa80f5@localhost> #2765: unsetenv not found under Solaris 8 when building ghc-6.10.1 -----------------------+---------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Architecture: sparc | Os: Solaris -----------------------+---------------------------------------------------- Which library provides unsetenv? {{{ Building ghc-bin-6.10.1... [1 of 1] Compiling Main ( Main.hs, dist-stage2/build/ghc/ghc- tmp/Main.o ) Linking dist-stage2/build/ghc/ghc ... /home/maeder/haskell/solaris/ghc-6.10.1/libraries/unix/dist/build/libHSunix-2.3.1.0.a(HsUnix.o): In function `__hsunix_unsetenv': HsUnix.c:(.text+0x138): undefined reference to `unsetenv' collect2: ld returned 1 exit status gmake[3]: *** [build.stage.2] Error 1 gmake[3]: Leaving directory `/home/maeder/haskell/solaris/ghc-6.10.1/ghc' gmake[2]: *** [build.stage.2] Error 2 gmake[2]: Leaving directory `/home/maeder/haskell/solaris/ghc-6.10.1/compiler' gmake[1]: *** [stage2] Error 2 gmake[1]: Leaving directory `/home/maeder/haskell/solaris/ghc-6.10.1' gmake: *** [bootstrap2] Error 2 }}} {{{ SunOS 5.8 Generic_117350-57 sun4u sparc SUNW,Ultra-4 -bash-3.00$ gcc -v Using built-in specs. Target: sparc-sun-solaris2.8 Configured with: ../gcc-4.0.3/configure --prefix=/usr/local/lang -program- suffix=_4.0.3 --with-gnu-as --with-as=/usr/local/bin/gnu-as --with-gnu-ld --with-ld=/usr/local/bin/gnu-ld --enable-version-specific-runtime-libs --enable-languages=c,c++ Thread model: posix gcc version 4.0.3 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 11 05:09:38 2008 From: trac at galois.com (GHC) Date: Tue Nov 11 05:04:12 2008 Subject: [GHC] #2692: ghc-6.10.0.20081007 seg faults on Sparc In-Reply-To: <045.b06b0ab2c1c887d4319783181d70d6f9@localhost> References: <045.b06b0ab2c1c887d4319783181d70d6f9@localhost> Message-ID: <054.21b0def90232a5d732fa3435335e34d1@localhost> #2692: ghc-6.10.0.20081007 seg faults on Sparc ----------------------+----------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: sparc Os: Solaris | ----------------------+----------------------------------------------------- Comment (by maeder): the machine used is: {{{ SunOS 5.10 Generic_137111-07 sun4u sparc SUNW,Sun-Fire-280R -bash-3.00$ gcc -v Using built-in specs. Target: sparc-sun-solaris2.10 Configured with: ../gcc-4.2.2/configure --prefix=/usr/local/lang -program- suffix=_4.2.2 --with-gnu-as --with-as=/usr/local/bin/gnu-as --with-gnu-ld --with-ld=/usr/local/bin/gnu-ld --enable-version-specific-runtime-libs --enable-languages=c,c++ Thread model: posix gcc version 4.2.2 }}} I've also tried a different machine, where the stage2 compiler just sleeps and seg-faults without failure position when relinked with `GhcDebugged=YES`. {{{ SunOS 5.10 Generic_137111-03 sun4u sparc SUNW,Sun-Fire-V240 -bash-3.00$ gcc -v Reading specs from /export/local/lang/bin/../lib/gcc/sparc-sun- solaris2.10/3.4.4/specs Configured with: ../gcc-3.4.4/configure --prefix=/usr/local/lang -program- suffix=_3.4.4_s10 --with-gnu-as --with-as=/usr/local/bin/gnu-as --with- gnu-ld --with-ld=/usr/local/bin/gnu-ld --enable-version-specific-runtime- libs --enable-languages=c,c++,f77 Thread model: posix gcc version 3.4.4 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 11 05:39:56 2008 From: trac at galois.com (GHC) Date: Tue Nov 11 05:34:28 2008 Subject: [GHC] #2766: Infix type operators are presented with incorrect syntax in ghci Message-ID: <048.ede65a0a07b7bb10f4f547601c287a56@localhost> #2766: Infix type operators are presented with incorrect syntax in ghci ---------------------------------+------------------------------------------ Reporter: EyalLotem | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ Prelude Control.Arrow> :t first :: Arrow (~>) => b~>c -> (b, d)~>(c, d) first :: Arrow (~>) => b~>c -> (b, d)~>(c, d) :: (Arrow ~>) => ~> b c -> ~> (b, d) (c, d) This is incorrect syntax, and causes other bugs too e.g: http://trac.haskell.org/haddock/ticket/64 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 11 05:41:56 2008 From: trac at galois.com (GHC) Date: Tue Nov 11 05:36:27 2008 Subject: [GHC] #2766: Infix type operators are presented with incorrect syntax in ghci In-Reply-To: <048.ede65a0a07b7bb10f4f547601c287a56@localhost> References: <048.ede65a0a07b7bb10f4f547601c287a56@localhost> Message-ID: <057.9e8cdb0a0a1ed4b5b696ab4d2a8d8a2d@localhost> #2766: Infix type operators are presented with incorrect syntax in ghci ---------------------------------+------------------------------------------ Reporter: EyalLotem | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: major | Resolution: Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ Comment (by EyalLotem): Better formatting: {{{ Prelude Control.Arrow> :t first :: Arrow (~>) => b~>c -> (b, d)~>(c, d) first :: Arrow (~>) => b~>c -> (b, d)~>(c, d) :: (Arrow ~>) => ~> b c -> ~> (b, d) (c, d) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 11 05:59:05 2008 From: trac at galois.com (GHC) Date: Tue Nov 11 05:53:38 2008 Subject: [GHC] #2762: Excessive heap usage In-Reply-To: <044.bf1fb1b8e171504548cbe3cb91273ef8@localhost> References: <044.bf1fb1b8e171504548cbe3cb91273ef8@localhost> Message-ID: <053.0b0bc7d464791bbe310f843a68c3a004@localhost> #2762: Excessive heap usage ------------------------------+--------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by simonmar): Ok, here's what's happening. The `input` method for `InputOutput [a]` gets compiled to this (STG syntax, so we can see the closures): {{{ InputOutput.input1 = \r srt:(0,*bitmap*) [$dInputOutput_smx] let { input2_smz = \u srt:(0,*bitmap*) [] InputOutput.input1 $dInputOutput_smx; } in let { sat_snm = \r srt:(1,*bitmap*) [ds_smB] ... } in sat_snm; }}} so, `sat_snm` is the function that does the work, and it has `input2_smz` as a free variable. When this function is called, it allocates closures for `sat_snm` and `input2_smz`, and proceeds to enter `sat_snm`. Eventually this call evaluates `input2_smz`, which is another call to `input1`, which creates more closures, and so on. Normally all these closures would be GC'd immediately, but they don't in this example, because the `Main` module has this CAF: {{{ Main.input :: GHC.Base.String -> ([GHC.Types.Char], GHC.Base.String) Main.input = InputOutput.input1 @ GHC.Types.Char (InputOutput.a `cast` ...) }}} This CAF evaluates to an unbounded chain of `sat_snm` closures: remember `sat_snm` has `input2` as a free var, which itself evaluates to another `sat_snm` closure, and so on). The CAF is retained because it is used by the second call to input. The solution seems simple: inline `input2`, then the two closures in `input1` disappear. We ought to be able to tell that `input2` is a value - perhaps the recursion gets in the way? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 11 07:42:38 2008 From: trac at galois.com (GHC) Date: Tue Nov 11 07:37:10 2008 Subject: [GHC] #2743: GHC 6.10.1 Win32 release is unusable (on XP SP3) In-Reply-To: <044.5c7925a0112349b6ff4c617bfd276240@localhost> References: <044.5c7925a0112349b6ff4c617bfd276240@localhost> Message-ID: <053.025fdc1f511ba5ddb81a88b99749f17c@localhost> #2743: GHC 6.10.1 Win32 release is unusable (on XP SP3) ----------------------+----------------------------------------------------- Reporter: guest | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: blocker | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------+----------------------------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: Validated and pushed: {{{ Wed Nov 5 05:43:15 PST 2008 Neil Mitchell * Perform case-insensitive matching of path components in getBaseDir on Windows (Fixes bug 2743) }}} we should check that it actually fixes the bug, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 11 09:01:09 2008 From: trac at galois.com (GHC) Date: Tue Nov 11 08:55:40 2008 Subject: [GHC] #2767: Type family bug ? Message-ID: <043.5d7b08e8b12f70310b2c5608326cbdc1@localhost> #2767: Type family bug ? ---------------------------------+------------------------------------------ Reporter: test | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 6.10.1 | Severity: normal Keywords: | Testcase: Architecture: Unknown/Multiple | Os: MacOS X ---------------------------------+------------------------------------------ I get this error when compiling a program with associated type families: {{{ $ ghc --make Queens_v2.hs [1 of 5] Compiling Domain ( Domain.hs, Domain.o ) [2 of 5] Compiling Solver ( Solver.hs, Solver.o ) [3 of 5] Compiling FD ( FD.hs, FD.o ) [4 of 5] Compiling SearchTree ( SearchTree.hs, SearchTree.o ) [5 of 5] Compiling Main ( Queens_v2.hs, Queens_v2.o ) ghc: panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-apple-darwin): idInfo co{v a629} [tv] }}} Tom Schrijvers -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 11 09:22:32 2008 From: trac at galois.com (GHC) Date: Tue Nov 11 09:17:02 2008 Subject: [GHC] #2767: Type family bug ? In-Reply-To: <043.5d7b08e8b12f70310b2c5608326cbdc1@localhost> References: <043.5d7b08e8b12f70310b2c5608326cbdc1@localhost> Message-ID: <052.bef9bc4a86dde28f7930ad4688b8cb25@localhost> #2767: Type family bug ? ----------------------------------------+----------------------------------- Reporter: test | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown/Multiple | Os: MacOS X ----------------------------------------+----------------------------------- Comment (by test): I've narrowed down the problem to the code below. The problem is one of type inference. If either type signature is added, then it compiles fine. {{{ {-# LANGUAGE TypeFamilies #-} {-# OPTIONS_GHC -fglasgow-exts #-} module Main where main = return () -- eval' :: Solver solver => Tree solver a -> [(Label solver,Tree solver a)] -> solver [a] eval' (NewVar f) wl = do v <- newvarSM eval' (f v) wl eval' Fail wl = continue wl -- continue :: Solver solver => [(Label solver,Tree solver a)] -> solver [a] continue ((past,t):wl) = do gotoSM past eval' t wl data Tree s a = Fail | NewVar (Term s -> Tree s a) class Monad solver => Solver solver where type Term solver :: * type Label solver :: * newvarSM :: solver (Term solver) gotoSM :: Label solver -> solver () }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 11 09:27:04 2008 From: trac at galois.com (GHC) Date: Tue Nov 11 09:22:15 2008 Subject: [GHC] #2724: foreign functions called from optimized Haskell code receive non-empty fpu stack In-Reply-To: <044.2d874f0fab562627c6bb887ff848f8fd@localhost> References: <044.2d874f0fab562627c6bb887ff848f8fd@localhost> Message-ID: <053.32a6c71a2dd08ad740d225151e9f4b93@localhost> #2724: foreign functions called from optimized Haskell code receive non-empty fpu stack ------------------------------+--------------------------------------------- Reporter: aruiz | Owner: igoo Type: merge | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler (NCG) | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by simonmar): * owner: => igoo * type: bug => merge Comment: I believe this patch fixes it. At least, with this patch, the `hoco` example above doesn't complain about NaN (it complains about failing QuickCheck tests instead, but that's what the other versions of the test do). {{{ Tue Nov 11 12:56:19 GMT 2008 Simon Marlow * Fix to i386_insert_ffrees (#2724, #1944) The i386 native code generator has to arrange that the FPU stack is clear on exit from any function that uses the FPU. Unfortunately it was getting this wrong (and has been ever since this code was written, I think): it was looking for basic blocks that used the FPU and adding the code to clear the FPU stack on any non-local exit from the block. In fact it should be doing this on a whole-function basis, rather than individual basic blocks. }}} Many thanks to those of you who took the time to carefully isolate this bug and report it in a way that enabled us to diagnose the problem. It's been a subtle and long-standing bug, and it's very nice to finally have it fixed! Now what I really need is a small test case that we can add to the testsuite. I've tried cutting down hmatrix with no success so far, can anyone help? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 11 09:28:55 2008 From: trac at galois.com (GHC) Date: Tue Nov 11 09:23:28 2008 Subject: [GHC] #1944: round function causes cblas NaNs In-Reply-To: <052.7827d863c451a2b4d8c8af2c2416f81c@localhost> References: <052.7827d863c451a2b4d8c8af2c2416f81c@localhost> Message-ID: <061.0ba83f58eba5b16320721974df729df1@localhost> #1944: round function causes cblas NaNs ---------------------------+------------------------------------------------ Reporter: SevenThunders | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.1 Severity: critical | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ---------------------------+------------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Optimistically assuming this is the same bug as #2724 (now fixed). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 11 10:00:27 2008 From: trac at galois.com (GHC) Date: Tue Nov 11 09:55:01 2008 Subject: [GHC] #2752: Parse error in STM.c In-Reply-To: <045.c718ce03da14ed9d9cb9e18ef468e107@localhost> References: <045.c718ce03da14ed9d9cb9e18ef468e107@localhost> Message-ID: <054.2180abc08bf59301dee3ff0b27250693@localhost> #2752: Parse error in STM.c --------------------------+------------------------------------------------- Reporter: jputcu | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.2 Component: Build System | Version: 6.10.1 Severity: blocker | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | --------------------------+------------------------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: I committed that patch, BTW. {{{ Tue Nov 11 05:53:44 PST 2008 Simon Marlow * Fix parse error with older gccs (#2752) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 11 10:16:17 2008 From: trac at galois.com (GHC) Date: Tue Nov 11 10:10:50 2008 Subject: [GHC] #2081: GHC reports internal error: stg_ap_v_ret In-Reply-To: <050.436412791af8536dabd2387bab7c6cbf@localhost> References: <050.436412791af8536dabd2387bab7c6cbf@localhost> Message-ID: <059.0aa2dde0ae197333cf9648881c1c6304@localhost> #2081: GHC reports internal error: stg_ap_v_ret -------------------------+-------------------------------------------------- Reporter: thorkilnaur | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: MacOS X | -------------------------+-------------------------------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 11 10:16:34 2008 From: trac at galois.com (GHC) Date: Tue Nov 11 10:11:12 2008 Subject: [GHC] #2584: Pretty printing of types with HsDocTy goes wrong In-Reply-To: <051.bf512b6956b3ff06fbdabc8d35b6e47d@localhost> References: <051.bf512b6956b3ff06fbdabc8d35b6e47d@localhost> Message-ID: <060.ef682f14f6be9f6c2b79500c4b78b964@localhost> #2584: Pretty printing of types with HsDocTy goes wrong ------------------------------+--------------------------------------------- Reporter: NeilMitchell | Owner: waern Type: bug | Status: assigned Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.9 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 11 10:16:48 2008 From: trac at galois.com (GHC) Date: Tue Nov 11 10:11:18 2008 Subject: [GHC] #2655: Control.Exception's Haddock document drop instruction about Extensible Exceptions In-Reply-To: <047.1bde2d0a50f92799bbadb2d6cc5101e0@localhost> References: <047.1bde2d0a50f92799bbadb2d6cc5101e0@localhost> Message-ID: <056.cb369c342090d5686917daef000e19b4@localhost> #2655: Control.Exception's Haddock document drop instruction about Extensible Exceptions ------------------------------+--------------------------------------------- Reporter: shelarcy | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Documentation | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 11 10:17:07 2008 From: trac at galois.com (GHC) Date: Tue Nov 11 10:11:42 2008 Subject: [GHC] #2658: Extreme memory usage (probably type functions) In-Reply-To: <044.e9d0778983f3efa5257edab0ca1c5901@localhost> References: <044.e9d0778983f3efa5257edab0ca1c5901@localhost> Message-ID: <053.a48d95111a7c1066260ea5935b2ce776@localhost> #2658: Extreme memory usage (probably type functions) -------------------------------------+-------------------------------------- Reporter: guest | Owner: chak Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler (Type checker) | Version: 6.9 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | -------------------------------------+-------------------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 11 10:17:19 2008 From: trac at galois.com (GHC) Date: Tue Nov 11 10:11:55 2008 Subject: [GHC] #2697: bad testsuite results with ghc-6.10.0.20081007 In-Reply-To: <045.c368cc178489a6d371c14b6319d3b743@localhost> References: <045.c368cc178489a6d371c14b6319d3b743@localhost> Message-ID: <054.3aee5b88087cd52d2833ab651eb9323a@localhost> #2697: bad testsuite results with ghc-6.10.0.20081007 ------------------------------+--------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 11 10:17:36 2008 From: trac at galois.com (GHC) Date: Tue Nov 11 10:12:07 2008 Subject: [GHC] #2709: System.Directory.doesDirectoryExist "\\" is False on Windows In-Reply-To: <047.62ffe3d738f377c87f772b23e67bd03b@localhost> References: <047.62ffe3d738f377c87f772b23e67bd03b@localhost> Message-ID: <056.8f5e35288680b228c26e628b7f7233b1@localhost> #2709: System.Directory.doesDirectoryExist "\\" is False on Windows ---------------------------------+------------------------------------------ Reporter: Deewiant | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: libraries/directory | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Windows | ---------------------------------+------------------------------------------ Changes (by igloo): * milestone: 6.10.1 => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 11 10:18:22 2008 From: trac at galois.com (GHC) Date: Tue Nov 11 10:12:58 2008 Subject: [GHC] #1364: Finalizers not guaranteed to run before the program exits In-Reply-To: <059.db0f5b638555483a7832474f38ff8320@localhost> References: <059.db0f5b638555483a7832474f38ff8320@localhost> Message-ID: <068.3ab0c37e5137a439eb4a65a1c3d6a240@localhost> #1364: Finalizers not guaranteed to run before the program exits ----------------------------------+----------------------------------------- Reporter: tomac@pacific.net.au | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: 6.10.2 Component: Runtime System | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 11 10:18:46 2008 From: trac at galois.com (GHC) Date: Tue Nov 11 10:13:20 2008 Subject: [GHC] #1845: unconditional relative branch out of range (GHC version 6.8.1/6.8.2 for powerpc_apple_darwin) In-Reply-To: <044.65389402080b2ab045a1b2fde12245f8@localhost> References: <044.65389402080b2ab045a1b2fde12245f8@localhost> Message-ID: <053.384e14665b897cce12893f022292ebac@localhost> #1845: unconditional relative branch out of range (GHC version 6.8.1/6.8.2 for powerpc_apple_darwin) ----------------------+----------------------------------------------------- Reporter: guest | Owner: thorkilnaur Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.8.2 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 11 10:24:20 2008 From: trac at galois.com (GHC) Date: Tue Nov 11 10:19:01 2008 Subject: [GHC] #2031: relocation overflow In-Reply-To: <045.02b5c8981d759aa3391df46bf05998bf@localhost> References: <045.02b5c8981d759aa3391df46bf05998bf@localhost> Message-ID: <054.d2d585625e873509834b2a39749fccd1@localhost> #2031: relocation overflow ----------------------+----------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 11 10:24:37 2008 From: trac at galois.com (GHC) Date: Tue Nov 11 10:19:12 2008 Subject: [GHC] #2063: Breackage on OpenBSD due to mmap remap In-Reply-To: <043.15abf9ca319b437728a2421245ad0407@localhost> References: <043.15abf9ca319b437728a2421245ad0407@localhost> Message-ID: <052.5f35ff42277f2333bed2063e724d9c02@localhost> #2063: Breackage on OpenBSD due to mmap remap ----------------------------+----------------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: OpenBSD | Difficulty: Moderate (1 day) Testcase: | Architecture: x86_64 (amd64) Os: OpenBSD | ----------------------------+----------------------------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 11 10:24:54 2008 From: trac at galois.com (GHC) Date: Tue Nov 11 10:19:36 2008 Subject: [GHC] #2285: Solaris 9 build fails at stage2 with undefined symbol errors (for libm symbols) In-Reply-To: <048.9d281a64a969b94451f675cf7f831df1@localhost> References: <048.9d281a64a969b94451f675cf7f831df1@localhost> Message-ID: <057.094db320394fc6abf2d6af4821571694@localhost> #2285: Solaris 9 build fails at stage2 with undefined symbol errors (for libm symbols) -----------------------+---------------------------------------------------- Reporter: TimBishop | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: sparc Os: Solaris | -----------------------+---------------------------------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 11 10:25:21 2008 From: trac at galois.com (GHC) Date: Tue Nov 11 10:19:52 2008 Subject: [GHC] #2301: Proper handling of SIGINT/SIGQUIT In-Reply-To: <045.f06a53427920f75d02000e2372e27573@localhost> References: <045.f06a53427920f75d02000e2372e27573@localhost> Message-ID: <054.baf5b0c775490ce925a3260ec9be05b1@localhost> #2301: Proper handling of SIGINT/SIGQUIT -------------------------------+-------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: libraries/process | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | -------------------------------+-------------------------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 11 10:25:37 2008 From: trac at galois.com (GHC) Date: Tue Nov 11 10:20:10 2008 Subject: [GHC] #2342: timer problem under Sparc Solaris for Release Candidate ghc-6.8.2.20080603 In-Reply-To: <045.7c5ad0836c0444e2655d0f93786db19e@localhost> References: <045.7c5ad0836c0444e2655d0f93786db19e@localhost> Message-ID: <054.2edd81180b60fcb683ed53d3055683af@localhost> #2342: timer problem under Sparc Solaris for Release Candidate ghc-6.8.2.20080603 --------------------------+------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Build System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: sparc Os: Solaris | --------------------------+------------------------------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 11 10:27:46 2008 From: trac at galois.com (GHC) Date: Tue Nov 11 10:22:20 2008 Subject: [GHC] #2349: SIZET_FMT in includes/mkDerivedConstants.c needs to be "d" under older Solaris version In-Reply-To: <045.bc3bbec7f28e57f84d533f6eb759f26c@localhost> References: <045.bc3bbec7f28e57f84d533f6eb759f26c@localhost> Message-ID: <054.ec64e279c103bceec3801d93f6468907@localhost> #2349: SIZET_FMT in includes/mkDerivedConstants.c needs to be "d" under older Solaris version ----------------------+----------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: sparc Os: Solaris | ----------------------+----------------------------------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 11 10:28:01 2008 From: trac at galois.com (GHC) Date: Tue Nov 11 10:22:33 2008 Subject: [GHC] #2380: Adjustor.o crash compiling ghc 6.8.3 on iBook G4 10.4.11 In-Reply-To: <045.f144b092f23e8db9c081050578f2b103@localhost> References: <045.f144b092f23e8db9c081050578f2b103@localhost> Message-ID: <054.c10fb15831523c2ecb09fc8284f08ce4@localhost> #2380: Adjustor.o crash compiling ghc 6.8.3 on iBook G4 10.4.11 --------------------------+------------------------------------------------- Reporter: povman | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Build System | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | --------------------------+------------------------------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 11 10:30:12 2008 From: trac at galois.com (GHC) Date: Tue Nov 11 10:24:43 2008 Subject: [GHC] #2402: ghc fails sans error message. In-Reply-To: <046.ec9278b09c51ceec22610f63a11d7929@localhost> References: <046.ec9278b09c51ceec22610f63a11d7929@localhost> Message-ID: <055.733c809067fbf7e51542d64affaf20b5@localhost> #2402: ghc fails sans error message. ----------------------+----------------------------------------------------- Reporter: lpsmith | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 11 10:30:31 2008 From: trac at galois.com (GHC) Date: Tue Nov 11 10:25:04 2008 Subject: [GHC] #2435: Qualified name required when defining type family instance in instance declaration In-Reply-To: <041.497191dfe597e8898c23dfb8fea641e6@localhost> References: <041.497191dfe597e8898c23dfb8fea641e6@localhost> Message-ID: <050.dd92f409864c075a13946008adbe79b7@localhost> #2435: Qualified name required when defining type family instance in instance declaration ------------------------------+--------------------------------------------- Reporter: rl | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 11 10:56:24 2008 From: trac at galois.com (GHC) Date: Tue Nov 11 10:50:56 2008 Subject: [GHC] #1779: unknown symbol `hs_hpc_module' In-Reply-To: <044.e238a8559ffe0a21198f4a819a87e869@localhost> References: <044.e238a8559ffe0a21198f4a819a87e869@localhost> Message-ID: <053.98cc85e56c4181f44d48fa01b68f4707@localhost> #1779: unknown symbol `hs_hpc_module' ------------------------------+--------------------------------------------- Reporter: guest | Owner: AndyGill Type: bug | Status: reopened Priority: low | Milestone: 6.10.2 Component: GHCi | Version: 6.9 Severity: minor | Resolution: Keywords: hpc | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 11 10:56:49 2008 From: trac at galois.com (GHC) Date: Tue Nov 11 10:51:19 2008 Subject: [GHC] #2730: Quasiquote or TH linking may need HPC flag In-Reply-To: <046.eb529fb4a48a2719d84deefae728a2de@localhost> References: <046.eb529fb4a48a2719d84deefae728a2de@localhost> Message-ID: <055.8814eb9e9072a1ce739d112637d1998e@localhost> #2730: Quasiquote or TH linking may need HPC flag ------------------------------+--------------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 11 11:03:43 2008 From: trac at galois.com (GHC) Date: Tue Nov 11 10:58:18 2008 Subject: [GHC] #2692: ghc-6.10.0.20081007 seg faults on Sparc In-Reply-To: <045.b06b0ab2c1c887d4319783181d70d6f9@localhost> References: <045.b06b0ab2c1c887d4319783181d70d6f9@localhost> Message-ID: <054.b213aa980655d9f1cc9c7460c56c92ff@localhost> #2692: ghc-6.10.0.20081007 seg faults on Sparc ----------------------+----------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: sparc Os: Solaris | ----------------------+----------------------------------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 11 11:11:23 2008 From: trac at galois.com (GHC) Date: Tue Nov 11 11:05:54 2008 Subject: [GHC] #2689: make maintainer-clean leaves generated files and directories In-Reply-To: <044.d82e9d076aeb3a76dac009bdaa86249d@localhost> References: <044.d82e9d076aeb3a76dac009bdaa86249d@localhost> Message-ID: <053.14c7723884d9d35b7db99f6c05b697b9@localhost> #2689: make maintainer-clean leaves generated files and directories ------------------------------+--------------------------------------------- Reporter: claus | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Build System | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 11 11:13:23 2008 From: trac at galois.com (GHC) Date: Tue Nov 11 11:07:56 2008 Subject: [GHC] #2677: Detection of TF instance conflict depends on instance order In-Reply-To: <046.85ed4c204d40e74117cf277dea4c07f0@localhost> References: <046.85ed4c204d40e74117cf277dea4c07f0@localhost> Message-ID: <055.a69a5ecb69bcbc29319a1f5fb146b20e@localhost> #2677: Detection of TF instance conflict depends on instance order -------------------------------------+-------------------------------------- Reporter: reinerp | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: TF instance conflict | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | -------------------------------------+-------------------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 11 11:37:14 2008 From: trac at galois.com (GHC) Date: Tue Nov 11 11:31:48 2008 Subject: [GHC] #2673: FreeBSD built-in libedit is not compatible with GHC In-Reply-To: <048.a7a8b8cd246f16f4f13f2f8936382c3e@localhost> References: <048.a7a8b8cd246f16f4f13f2f8936382c3e@localhost> Message-ID: <057.b7f7b6c67f0fcfdaf6a217685d4d4f8d@localhost> #2673: FreeBSD built-in libedit is not compatible with GHC -----------------------+---------------------------------------------------- Reporter: gmainland | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: FreeBSD | -----------------------+---------------------------------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 11 11:38:26 2008 From: trac at galois.com (GHC) Date: Tue Nov 11 11:33:02 2008 Subject: [GHC] #2664: type family + data family + typeclass + type error causes GHC to diverge In-Reply-To: <044.872c3ac7a7ba1538fc338d52d1b94837@localhost> References: <044.872c3ac7a7ba1538fc338d52d1b94837@localhost> Message-ID: <053.639308c2d0f1f5d0e789805edb4369ee@localhost> #2664: type family + data family + typeclass + type error causes GHC to diverge ------------------------------+--------------------------------------------- Reporter: ryani | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 11 12:12:42 2008 From: trac at galois.com (GHC) Date: Tue Nov 11 12:07:14 2008 Subject: [GHC] #2650: System.Process: processes may unwantedly inherit Handles on Windows when multithreading In-Reply-To: <047.1449ef20e3242d7624bded23f58b28e1@localhost> References: <047.1449ef20e3242d7624bded23f58b28e1@localhost> Message-ID: <056.4e5064f50b181add95037b8f33d84cd6@localhost> #2650: System.Process: processes may unwantedly inherit Handles on Windows when multithreading -------------------------------+-------------------------------------------- Reporter: Deewiant | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: libraries/process | Version: 6.9 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | -------------------------------+-------------------------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 11 12:13:19 2008 From: trac at galois.com (GHC) Date: Tue Nov 11 12:07:51 2008 Subject: [GHC] #2638: runInteractiveCommand on Win32 leaks, produces inconsistent behavior In-Reply-To: <043.7879ff2ec970e5670b4c9255c0e07b58@localhost> References: <043.7879ff2ec970e5670b4c9255c0e07b58@localhost> Message-ID: <052.1ff7de4ed10d78fd75b91b6b257cd3d3@localhost> #2638: runInteractiveCommand on Win32 leaks, produces inconsistent behavior -------------------------------+-------------------------------------------- Reporter: sclv | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: libraries/process | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: vax Os: Windows | -------------------------------+-------------------------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 11 12:18:51 2008 From: trac at galois.com (GHC) Date: Tue Nov 11 12:13:22 2008 Subject: [GHC] #2514: Add/Expose Binary API that allows dumping of any GHC Binary instance In-Reply-To: <047.57cf723e547f8e60541f4f12c39c26fa@localhost> References: <047.57cf723e547f8e60541f4f12c39c26fa@localhost> Message-ID: <056.151e419765980dcc0bab9089a2305802@localhost> #2514: Add/Expose Binary API that allows dumping of any GHC Binary instance ------------------------------+--------------------------------------------- Reporter: nominolo | Owner: nominolo Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: GHC API | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 11 12:19:29 2008 From: trac at galois.com (GHC) Date: Tue Nov 11 12:13:59 2008 Subject: [GHC] #2511: unix package doesnt load in ghci on freebsd/amd64 In-Reply-To: <046.b342e2cde385158917f69c7725044f60@localhost> References: <046.b342e2cde385158917f69c7725044f60@localhost> Message-ID: <055.25c26265a157f5b137efb87c1424d145@localhost> #2511: unix package doesnt load in ghci on freebsd/amd64 ----------------------------+----------------------------------------------- Reporter: newsham | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: libraries/unix | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: FreeBSD | ----------------------------+----------------------------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 11 12:19:47 2008 From: trac at galois.com (GHC) Date: Tue Nov 11 12:14:18 2008 Subject: [GHC] #2475: debugger gives "Can't unify" when stopped at an exception In-Reply-To: <044.67056a89ea8901dff63b307a4127f5ba@localhost> References: <044.67056a89ea8901dff63b307a4127f5ba@localhost> Message-ID: <053.53d49252bd9059c0325e8b9b9e092929@localhost> #2475: debugger gives "Can't unify" when stopped at an exception ------------------------------------------+--------------------------------- Reporter: igloo | Owner: mnislaih Type: bug | Status: assigned Priority: normal | Milestone: 6.10.2 Component: GHCi | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: break011, break017, break024 | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------------------+--------------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 11 12:22:38 2008 From: trac at galois.com (GHC) Date: Tue Nov 11 12:17:09 2008 Subject: [GHC] #2611: print022 fails In-Reply-To: <044.04df65fcd08934af446e85568f6b956a@localhost> References: <044.04df65fcd08934af446e85568f6b956a@localhost> Message-ID: <053.6c63840964a633a03ce50a4bbfbe9bd4@localhost> #2611: print022 fails ------------------------------+--------------------------------------------- Reporter: igloo | Owner: mnislaih Type: bug | Status: assigned Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: print022 | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by mnislaih): * status: new => assigned * owner: => mnislaih * cc: mnislaih@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 11 12:24:08 2008 From: trac at galois.com (GHC) Date: Tue Nov 11 12:18:42 2008 Subject: [GHC] #2436: Bad warning when exporting data families In-Reply-To: <041.c0e126f9cae0d4eca6685716c24c2990@localhost> References: <041.c0e126f9cae0d4eca6685716c24c2990@localhost> Message-ID: <050.c4eff0a889bbe5f5aa98df799dba8735@localhost> #2436: Bad warning when exporting data families ------------------------------+--------------------------------------------- Reporter: rl | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 11 12:25:56 2008 From: trac at galois.com (GHC) Date: Tue Nov 11 12:20:31 2008 Subject: [GHC] #2475: debugger gives "Can't unify" when stopped at an exception In-Reply-To: <044.67056a89ea8901dff63b307a4127f5ba@localhost> References: <044.67056a89ea8901dff63b307a4127f5ba@localhost> Message-ID: <053.d8a009963f228bfe13bba80635119b58@localhost> #2475: debugger gives "Can't unify" when stopped at an exception ------------------------------------------+--------------------------------- Reporter: igloo | Owner: mnislaih Type: bug | Status: closed Priority: normal | Milestone: 6.10.2 Component: GHCi | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: break011, break017, break024 | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------------------+--------------------------------- Changes (by mnislaih): * status: assigned => closed * resolution: => fixed Comment: I forgot to close this ticket. Fixed by the patch {{{ Thu Sep 18 05:21:33 PDT 2008 pepe * Fix a couple of issues with :print }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 11 12:33:55 2008 From: trac at galois.com (GHC) Date: Tue Nov 11 12:28:27 2008 Subject: [GHC] #1995: Unsoundness in the RTTI scheme when newtypes are involved In-Reply-To: <047.3d0710ff9b9b1528afeb4de92d082c32@localhost> References: <047.3d0710ff9b9b1528afeb4de92d082c32@localhost> Message-ID: <056.2dadf1a2c3da78fe8f71c442075a1b4e@localhost> #1995: Unsoundness in the RTTI scheme when newtypes are involved ------------------------------------------+--------------------------------- Reporter: mnislaih | Owner: mnislaih Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.8.2 Severity: major | Resolution: fixed Keywords: | Difficulty: Project (> 1 week) Testcase: print029, print030, print031 | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------------------+--------------------------------- Changes (by mnislaih): * status: new => closed * resolution: => fixed Comment: Fixed up to some point by the patch below. {{{ Thu Sep 18 05:21:33 PDT 2008 pepe * Fix a couple of issues with :print }}} It is still possible to make :print compute unsound types, e.g. with recursive newtypes like: {{{ newtype In f = In (f (In f)) }}} I don't think this can be fixed completely without resorting to a separate compilation mode for :print, where newtypes are replaced by strict one- constructor datatypes. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 11 12:54:48 2008 From: trac at galois.com (GHC) Date: Tue Nov 11 12:49:25 2008 Subject: [GHC] #2342: timer problem under Sparc Solaris for Release Candidate ghc-6.8.2.20080603 In-Reply-To: <045.7c5ad0836c0444e2655d0f93786db19e@localhost> References: <045.7c5ad0836c0444e2655d0f93786db19e@localhost> Message-ID: <054.02a3ac0d47168b28428b336c8d0d6cf4@localhost> #2342: timer problem under Sparc Solaris for Release Candidate ghc-6.8.2.20080603 --------------------------+------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Build System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: sparc Os: Solaris | --------------------------+------------------------------------------------- Comment (by maeder): I think the above hack fixed it, so this ticket can be closed. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 11 13:28:45 2008 From: trac at galois.com (GHC) Date: Tue Nov 11 13:23:17 2008 Subject: [GHC] #2768: rts/win32/IOManager.h declarations conflict with windows.h Message-ID: <047.ee2a51d822f2ec1d2f12177eff0b4289@localhost> #2768: rts/win32/IOManager.h declarations conflict with windows.h -------------------------+-------------------------------------------------- Reporter: Deewiant | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 6.11 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: Windows -------------------------+-------------------------------------------------- `rts/win32/IOManager.h` has the following: {{{ /* On the yucky side..suppress -Wmissing-declarations warnings when * including */ extern void* GetCurrentFiber ( void ); extern void* GetFiberData ( void ); #include }}} Which causes problems on my system: {{{ In file included from d:\progging\mingw\bin\../lib/gcc/i686-pc- mingw32/4.2.1-dw2/../../../../include/windef.h:253, from d:\progging\mingw\bin\../lib/gcc/i686-pc- mingw32/4.2.1-dw2/../../../../include/windows.h:48, from IOManager.h:14, from IOManager.c:11: d:\progging\mingw\bin\../lib/gcc/i686-pc- mingw32/4.2.1-dw2/../../../../include/winnt.h:3832: error: static declaration of 'GetCurrentFiber' follows non-static declaration IOManager.h:12: error: previous declaration of 'GetCurrentFiber' was here d:\progging\mingw\bin\../lib/gcc/i686-pc- mingw32/4.2.1-dw2/../../../../include/winnt.h:3842: error: static declaration of 'GetFiberData' follows non-static declaration IOManager.h:13: error: previous declaration of 'GetFiberData' was here }}} Commenting out the two declarations makes things work again. A possible reason why this hasn't been a problem for others is that I'm using a 'technology preview' of MinGW from 2007 which comes with GCC 4.2.1, instead of the stable 3.4.5 from 2006. My `winnt.h` contains the following (snipped down to size where irrelevant): {{{ #if (__GNUC__ >= 3) /* Support -masm=intel. */ static __inline__ PVOID GetCurrentFiber(void) { ... } ... #else /* __GNUC__ >= 3 */ static __inline__ PVOID GetCurrentFiber(void) { ... } }}} So it seems that with a recent enough version of these headers the fiber functions get defined in any case, regardless of compiler version; were people to grab the latest version of [http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=11550 w32api] they'd run into these problems as well. Judging from the file timestamps I've got 3.11, the second-newest. 3.12's `winnt.h` appears identical in this respect, so updating wouldn't help. Since the two lines are claimed to be only for warning avoidance, I suggest just removing them. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 11 14:29:25 2008 From: trac at galois.com (GHC) Date: Tue Nov 11 14:24:26 2008 Subject: [GHC] #2724: foreign functions called from optimized Haskell code receive non-empty fpu stack In-Reply-To: <044.2d874f0fab562627c6bb887ff848f8fd@localhost> References: <044.2d874f0fab562627c6bb887ff848f8fd@localhost> Message-ID: <053.786b5cfe8dde59688895ae3742717f86@localhost> #2724: foreign functions called from optimized Haskell code receive non-empty fpu stack ------------------------------+--------------------------------------------- Reporter: aruiz | Owner: igoo Type: merge | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler (NCG) | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by aruiz): Fantastic! I will try to prepare a simple test case which doesn't need any foreign library. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 11 16:00:08 2008 From: trac at galois.com (GHC) Date: Tue Nov 11 15:54:41 2008 Subject: [GHC] #2646: Expand folding options for Sets and Maps In-Reply-To: <048.6604d7f856ddb37749ce7cc8864ce33b@localhost> References: <048.6604d7f856ddb37749ce7cc8864ce33b@localhost> Message-ID: <057.c42951e3fb87c9ee4d07bd9b26957845@localhost> #2646: Expand folding options for Sets and Maps -------------------------------+-------------------------------------------- Reporter: sedillard | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.8.3 Severity: normal | Resolution: Keywords: containers | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | -------------------------------+-------------------------------------------- Comment (by Deewiant): It'd also be nice to export the in-order fold, `foldi`, which exists but is commented out for some reason. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 11 16:01:43 2008 From: trac at galois.com (GHC) Date: Tue Nov 11 15:56:13 2008 Subject: [GHC] #2769: Export mapAccumR from Data.Map, Data.IntMap Message-ID: <047.6884ccd8725fc9653ca909dcd5164d50@localhost> #2769: Export mapAccumR from Data.Map, Data.IntMap ---------------------------------+------------------------------------------ Reporter: Deewiant | Owner: Type: proposal | Status: new Priority: normal | Component: libraries (other) Version: 6.11 | Severity: normal Keywords: containers | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ For some reason, the `mapAccumR` function isn't exported from `Data.Map` or `Data.IntMap`: it's just commented out. Attached is a patch which corrects that. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 11 16:16:07 2008 From: trac at galois.com (GHC) Date: Tue Nov 11 16:10:37 2008 Subject: [GHC] #2769: Export mapAccumR from Data.Map, Data.IntMap In-Reply-To: <047.6884ccd8725fc9653ca909dcd5164d50@localhost> References: <047.6884ccd8725fc9653ca909dcd5164d50@localhost> Message-ID: <056.31cf87993d163150dfd2f5c190358df8@localhost> #2769: Export mapAccumR from Data.Map, Data.IntMap ----------------------------------+----------------------------------------- Reporter: Deewiant | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 6.11 Severity: normal | Resolution: Keywords: containers | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ----------------------------------+----------------------------------------- Comment (by Deewiant): URL to discussion archives: http://www.haskell.org/pipermail/libraries/2008-November/010935.html -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 11 16:38:42 2008 From: trac at galois.com (GHC) Date: Tue Nov 11 16:33:14 2008 Subject: [GHC] #2747: Excessive Memory Usage: space leak with foldl' on Integer In-Reply-To: <044.00f0ddc6265bd8f5349ed085d7f86a62@localhost> References: <044.00f0ddc6265bd8f5349ed085d7f86a62@localhost> Message-ID: <053.b7fe4d5ba17feda210603c68a6fea05d@localhost> #2747: Excessive Memory Usage: space leak with foldl' on Integer ------------------------------+--------------------------------------------- Reporter: guest | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10.2 Component: Runtime System | Version: 6.10.1 Severity: blocker | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 11 16:40:56 2008 From: trac at galois.com (GHC) Date: Tue Nov 11 16:35:41 2008 Subject: [GHC] #2745: ghc -shared broken In-Reply-To: <047.4659d608cdcae10c404611f42e7f8e53@localhost> References: <047.4659d608cdcae10c404611f42e7f8e53@localhost> Message-ID: <056.7ef8df281bc265f0297fd48f28cd7840@localhost> #2745: ghc -shared broken ----------------------+----------------------------------------------------- Reporter: simonmar | Owner: igloo Type: merge | Status: closed Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Windows | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 11 18:20:00 2008 From: trac at galois.com (GHC) Date: Tue Nov 11 18:15:00 2008 Subject: [GHC] #2724: foreign functions called from optimized Haskell code receive non-empty fpu stack In-Reply-To: <044.2d874f0fab562627c6bb887ff848f8fd@localhost> References: <044.2d874f0fab562627c6bb887ff848f8fd@localhost> Message-ID: <053.77d959c9ee06c30058e03d0568c5d932@localhost> #2724: foreign functions called from optimized Haskell code receive non-empty fpu stack ------------------------------+--------------------------------------------- Reporter: aruiz | Owner: Type: task | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler (NCG) | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * priority: high => normal * owner: igoo => * type: merge => task Comment: Merged. Leaving the ticket open for the testcase. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 11 18:21:01 2008 From: trac at galois.com (GHC) Date: Tue Nov 11 18:15:31 2008 Subject: [GHC] #2743: GHC 6.10.1 Win32 release is unusable (on XP SP3) In-Reply-To: <044.5c7925a0112349b6ff4c617bfd276240@localhost> References: <044.5c7925a0112349b6ff4c617bfd276240@localhost> Message-ID: <053.3d51b5f28b2f7c22013962289ccba5ed@localhost> #2743: GHC 6.10.1 Win32 release is unusable (on XP SP3) ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: task | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: blocker | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------+----------------------------------------------------- Changes (by igloo): * owner: igloo => * type: merge => task Comment: Merged. Ticket left open for fix verification. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 11 18:21:32 2008 From: trac at galois.com (GHC) Date: Tue Nov 11 18:16:03 2008 Subject: [GHC] #2752: Parse error in STM.c In-Reply-To: <045.c718ce03da14ed9d9cb9e18ef468e107@localhost> References: <045.c718ce03da14ed9d9cb9e18ef468e107@localhost> Message-ID: <054.d25b690406727d1519c14382f082682b@localhost> #2752: Parse error in STM.c --------------------------+------------------------------------------------- Reporter: jputcu | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10.2 Component: Build System | Version: 6.10.1 Severity: blocker | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | --------------------------+------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 11 22:50:48 2008 From: trac at galois.com (GHC) Date: Tue Nov 11 22:45:19 2008 Subject: [GHC] #1944: round function causes cblas NaNs In-Reply-To: <052.7827d863c451a2b4d8c8af2c2416f81c@localhost> References: <052.7827d863c451a2b4d8c8af2c2416f81c@localhost> Message-ID: <061.8ff2fb044f4f2c528c724f24bd4f7d8c@localhost> #1944: round function causes cblas NaNs ---------------------------+------------------------------------------------ Reporter: SevenThunders | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.1 Severity: critical | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ---------------------------+------------------------------------------------ Comment (by SevenThunders): I tried to test it on the simple case that I provided but it no longer compiles. It seems the linker can't link to the atlas.lib file created by the dlltool.exe anymore. Here is the message: Linking Test2.exe ... ctest2.o:ctest2.c:(.text+0xb5): undefined reference to `cblas_dgemm' collect2: ld returned 1 exit status Alas I don't have time right now to figure out what has changed with the linker. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 12 05:22:31 2008 From: trac at galois.com (GHC) Date: Wed Nov 12 05:17:00 2008 Subject: [GHC] #2752: Parse error in STM.c In-Reply-To: <045.c718ce03da14ed9d9cb9e18ef468e107@localhost> References: <045.c718ce03da14ed9d9cb9e18ef468e107@localhost> Message-ID: <054.313fd8e30da4cd93cf0cc456d1694115@localhost> #2752: Parse error in STM.c --------------------------+------------------------------------------------- Reporter: jputcu | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10.2 Component: Build System | Version: 6.10.1 Severity: blocker | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | --------------------------+------------------------------------------------- Comment (by jputcu): I can confirm this patch is working. An STM.o is created. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 12 06:00:02 2008 From: trac at galois.com (GHC) Date: Wed Nov 12 05:54:30 2008 Subject: [GHC] #2743: GHC 6.10.1 Win32 release is unusable (on XP SP3) In-Reply-To: <044.5c7925a0112349b6ff4c617bfd276240@localhost> References: <044.5c7925a0112349b6ff4c617bfd276240@localhost> Message-ID: <053.3e51a17f70c5b446ff6018837e8be90b@localhost> #2743: GHC 6.10.1 Win32 release is unusable (on XP SP3) ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: task | Status: closed Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: blocker | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------+----------------------------------------------------- Changes (by NeilMitchell): * status: new => closed * resolution: => fixed Comment: I've built with the fix, and tested, and it works: {{{ C:\ghc>ghc-6.8.3\BIN\ghc.exe ghc.exe: no input files Usage: For basic information, try the `--help' option. C:\ghc>ghc-6.9.20080905\BIN\ghc.exe ghc.exe: panic! (the 'impossible' happened) (GHC version 6.9.20080905 for i386-unknown-mingw32): can't decompose ghc.exe path: "C:\\ghc\\ghc-6.9.20080905\\BIN\\ghc.exe" Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug C:\ghc>ghc-6.11.20081111\BIN\ghc.exe ghc.exe: no input files Usage: For basic information, try the `--help' option. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 12 06:54:10 2008 From: trac at galois.com (GHC) Date: Wed Nov 12 06:48:41 2008 Subject: [GHC] #2142: :b doesn't invoke :browse, or even generate an ambiguous command error In-Reply-To: <043.092835305ce494a68c91d5b535c09f14@localhost> References: <043.092835305ce494a68c91d5b535c09f14@localhost> Message-ID: <052.d9c40a1ef9cc1b27817cdb798ba13ad7@localhost> #2142: :b doesn't invoke :browse, or even generate an ambiguous command error ------------------------------+--------------------------------------------- Reporter: SamB | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => wontfix Comment: Perhaps in retrospect we shouldn't have spammed `:b`, but I think it would cause more trouble than it's worth to reverse that decision now. There are workarounds using `:def` (e.g. I use `:ls` for `:browse`). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 12 07:22:36 2008 From: trac at galois.com (GHC) Date: Wed Nov 12 07:17:07 2008 Subject: [GHC] #2380: Adjustor.o crash compiling ghc 6.8.3 on iBook G4 10.4.11 In-Reply-To: <045.f144b092f23e8db9c081050578f2b103@localhost> References: <045.f144b092f23e8db9c081050578f2b103@localhost> Message-ID: <054.69c41450959ebab2ead7c179ba4b7d6a@localhost> #2380: Adjustor.o crash compiling ghc 6.8.3 on iBook G4 10.4.11 --------------------------+------------------------------------------------- Reporter: povman | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Build System | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | --------------------------+------------------------------------------------- Comment (by ChrisKuklewicz): I reported a very similar looking bug to macports this week at http://trac.macports.org/ticket/17184 which I have updated to point to this ghc bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 12 07:44:07 2008 From: trac at galois.com (GHC) Date: Wed Nov 12 07:38:35 2008 Subject: [GHC] #2770: Missing check that C compiler is C99 compatible Message-ID: <045.e59ec55e01d8ef8d16caa02433e3c648@localhost> #2770: Missing check that C compiler is C99 compatible ---------------------------------+------------------------------------------ Reporter: jputcu | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.10.1 | Severity: blocker Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ The autoconfigure script checks for gcc >= 2. When using such a compiler on Red Hat 7.3, gcc-2.96, I get a number of C89 errors. Stated on http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/Conventions, C99 standard is used so my compiler is too old? Should the gcc requirement be updated or just check for C99 compliance. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 12 10:36:16 2008 From: trac at galois.com (GHC) Date: Wed Nov 12 10:30:43 2008 Subject: [GHC] #2771: GHC fail to Compile Crypto Message-ID: <044.89d1bcada3e6d5d964323cdcff7a7706@localhost> #2771: GHC fail to Compile Crypto -----------------------+---------------------------------------------------- Reporter: aivuk | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: Linux -----------------------+---------------------------------------------------- When I tried to compile Crypto lib in a MSI Wind notebook with Arch Linux, an error happens in Main compilation: {{{ Configuring Crypto-4.1.0... Warning: No 'build-type' specified. If you do not need a custom Setup.hs or ./configure script then use 'build-type: Simple'. Preprocessing library Crypto-4.1.0... Preprocessing executables for Crypto-4.1.0... Building Crypto-4.1.0... /usr/bin/ar: creating dist/build/libHSCrypto-4.1.0.a [4 of 4] Compiling Main ( SHA1Test.hs, dist/build/SHA1Test /SHA1Test-tmp/Main.o ) ghc: panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-unknown-linux): RegAllocLinear.getStackSlotFor: out of stack slots, try -fregs- graph }}} I compiled the same lib in a Arch box, but in x86_64 arch without problems. I'm compiling using the Arch package haskell-crypto in both cases. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 12 12:29:02 2008 From: trac at galois.com (GHC) Date: Wed Nov 12 12:23:31 2008 Subject: [GHC] #2772: vista detects ghc crash on testsuite ghci derefnull Message-ID: <053.44f1e76a6a78ead775340ed4b7d630b0@localhost> #2772: vista detects ghc crash on testsuite ghci derefnull -------------------------------+-------------------------------------------- Reporter: TristanAllwood | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: | Severity: normal Keywords: | Testcase: derefnull(ghci) Architecture: x86 | Os: Windows -------------------------------+-------------------------------------------- On Vista SP1, windows detects a ghc crash and pops up an interactive prompt. Makes it tricky to leave the full testsuite running overnight. When running the test suite from ghc head this morning (for reference, last patch applied was:) {{{ Tue Nov 11 13:53:44 GMT Standard Time 2008 Simon Marlow * Fix parse error with older gccs (#2752) }}} [http://www.zonetora.co.uk/NonBlog/derefnull.jpg Screenshot] -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 12 12:56:05 2008 From: trac at galois.com (GHC) Date: Wed Nov 12 12:50:42 2008 Subject: [GHC] #2773: Documentation mentions deprecated flags Message-ID: <044.8fbd9fa5930a794c5be22803687b7d92@localhost> #2773: Documentation mentions deprecated flags ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Documentation Version: 6.10.1 | Severity: minor Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ The 6.10.1 release notes mentions a number of -optdef flags that are now deprecated. Despite this the rest of the documentation (e.g., on separate compilation) mentions the deprecated flags instead of the new ones. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 12 13:51:35 2008 From: trac at galois.com (GHC) Date: Wed Nov 12 13:46:03 2008 Subject: [GHC] #2774: sIsReadable and sIsWritable return true after socket is closed. Message-ID: <047.480c8e606a3bfd77cd4272bd9432134f@localhost> #2774: sIsReadable and sIsWritable return true after socket is closed. ---------------------------------+------------------------------------------ Reporter: felixmar | Owner: Type: bug | Status: new Priority: normal | Component: libraries/network Version: 6.10.1 | Severity: normal Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ {{{ > import Network.Socket > s <- socket AF_INET Stream 6 Loading package parsec-2.1.0.1 ... linking ... done. Loading package network-2.2.0.1 ... linking ... done. > bindSocket s (SockAddrInet 0 0) > listen s 1 > sClose s > sIsReadable s True > sIsWritable s True }}} sIsReadable and sIsWritable return true when the !SocketStatus is Connected or Listening. sClose does not change the status. Perhaps a new status Closed should be added to !SocketStatus. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 12 18:08:22 2008 From: trac at galois.com (GHC) Date: Wed Nov 12 18:02:50 2008 Subject: [GHC] #2775: Type Family panic Message-ID: <044.cf027f74305f326c967336b8f3c587bd@localhost> #2775: Type Family panic -----------------------+---------------------------------------------------- Reporter: camio | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: blocker Keywords: | Testcase: Architecture: x86 | Os: Windows -----------------------+---------------------------------------------------- The following code produces the ghc panic below. {{{ {-# LANGUAGE RankNTypes, TypeFamilies #-} import Data.VectorSpace data I = I { integral :: (VectorSpace v, Scalar v ~ Double) => v } -- This works -- integral :: (VectorSpace v, Scalar v ~ Double) => v -- integral = undefined -- type BallAnim = Input -> Behavior Ball followMouse i = integral undefined undefined }}} {{{ ff>ghci GhcBug.hs GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Main ( GhcBug.hs, interpreted ) : panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-unknown-mingw32): applyTypeToArgs ipv{v B4} [lid] @ (a{tv arL} [sk] -> t_arM{tv} [sk]) $dVectorSpace{v arP} [lid] (base:GHC.Err.undefined{v rdH} [gid] @ a{tv arL} [sk]) (vector-space-0.5:Data.VectorSpace.Scalar{tc rgl} (a{tv arL} [sk] -> t_arM{tv} [sk]) ~ ghc-prim:GHC.Types.Double{(w) tc 3u}) => a{tv arL} [sk] -> t_arM{tv} [sk] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 12 18:09:50 2008 From: trac at galois.com (GHC) Date: Wed Nov 12 18:04:16 2008 Subject: [GHC] #2775: Type Family panic In-Reply-To: <044.cf027f74305f326c967336b8f3c587bd@localhost> References: <044.cf027f74305f326c967336b8f3c587bd@localhost> Message-ID: <053.778053de25e7360ee1496300253d59d1@localhost> #2775: Type Family panic -------------------------+-------------------------------------------------- Reporter: camio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: blocker | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Windows -------------------------+-------------------------------------------------- Comment (by camio): It seems to have something to do with the dependent family function type being in a data or newtype declaration. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 12 23:34:00 2008 From: trac at galois.com (GHC) Date: Wed Nov 12 23:28:33 2008 Subject: [GHC] #2776: Document -pgmL (Use cmd as the literate pre-processor) Message-ID: <047.3b71ad52e13d9dd964c5cec1ca82c2e0@localhost> #2776: Document -pgmL (Use cmd as the literate pre-processor) ---------------------------------+------------------------------------------ Reporter: Syzygies | Owner: Type: bug | Status: new Priority: normal | Component: Documentation Version: 6.10.1 | Severity: minor Keywords: pgmL literate | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ The GHC option -pgmL (Use cmd as the literate pre-processor) is undocumented, and behaves differently than -pgmF (Use cmd as the pre- processor). While one can count on the first three arguments to a -pgmF command giving file names, with optional arguments coming later, the ''last'' three arguments to a -pgmL command give the file names. An undocumented "-h" argument always comes ''before'' these file arguments, throwing off any command designed according to the documentation for -pgmF. Moreover, an optional argument provided using -opL comes ''before'' any of these arguments. The undocumented "-h" reminds me of the passage in Real World Haskell, how only one reasonable program could have type "(a, b) -> a", because there isn't enough information to do anything clever. Here, GHC wants the -pgmL command to emit standard Haskell, but for all it knows, the literate program is in Swahili. GHC isn't really in a good position to be offering advice via options on this conversion, because it has no idea what conversion is taking place. So the "-h" is inexplicable. Also, the example command in GHC manual section 5.10.4. doesn't use argument $1, and probably wants to use $1 rather than $2 for the echo, if in fact it is possible to create circumstance where $1 and $2 differ. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 13 04:10:02 2008 From: trac at galois.com (GHC) Date: Thu Nov 13 04:04:31 2008 Subject: [GHC] #2771: GHC fail to Compile Crypto In-Reply-To: <044.89d1bcada3e6d5d964323cdcff7a7706@localhost> References: <044.89d1bcada3e6d5d964323cdcff7a7706@localhost> Message-ID: <053.5ea593a4e5303e16a749eaf2ab39a11d@localhost> #2771: GHC fail to Compile Crypto -------------------------+-------------------------------------------------- Reporter: aivuk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Linux -------------------------+-------------------------------------------------- Comment (by jimstutt): Ditto with darcs, hackage and aur versions on archlinux 2-6-27-ARCH ghc 6.10.1 unknown-linux on x86. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 13 04:33:37 2008 From: trac at galois.com (GHC) Date: Thu Nov 13 04:28:05 2008 Subject: [GHC] #2758: runghc in stdin mode ignores Ctrl-C on Windows, cannot be killed In-Reply-To: <047.917d1da3b05e4d79bd411a581a2d9795@localhost> References: <047.917d1da3b05e4d79bd411a581a2d9795@localhost> Message-ID: <056.5a98262774250e9c61f62a23462e158d@localhost> #2758: runghc in stdin mode ignores Ctrl-C on Windows, cannot be killed ----------------------+----------------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------+----------------------------------------------------- Changes (by NeilMitchell): * cc: ndmitchell@gmail.com (added) * version: 6.8.3 => 6.10.1 Comment: I think this is actually a more general bug with GHC, rather than just runghc. Try for example: {{{ main = print =<< getContents }}} On Windows XP this program cannot be aborted with Ctrl+C. I guess runghc uses code similar to read in the file, which is where the problem is. This bug has already been reported on mailing lists under a few different guises, so is probably quite critical/ -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 13 04:36:49 2008 From: trac at galois.com (GHC) Date: Thu Nov 13 04:31:14 2008 Subject: [GHC] #2772: vista detects ghc crash on testsuite ghci derefnull In-Reply-To: <053.44f1e76a6a78ead775340ed4b7d630b0@localhost> References: <053.44f1e76a6a78ead775340ed4b7d630b0@localhost> Message-ID: <062.076aa3cc63ad3e5bced18437d066c53c@localhost> #2772: vista detects ghc crash on testsuite ghci derefnull -------------------------------+-------------------------------------------- Reporter: TristanAllwood | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: Severity: normal | Resolution: Keywords: | Testcase: derefnull(ghci) Architecture: x86 | Os: Windows -------------------------------+-------------------------------------------- Comment (by NeilMitchell): I ''think'' that you can turn this off by using a manifest in some way. There is a global system setting for it, but I can't remember exactly where (I turned it off on my Vista machine). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 13 05:38:14 2008 From: trac at galois.com (GHC) Date: Thu Nov 13 05:32:46 2008 Subject: [GHC] #2758: runghc in stdin mode ignores Ctrl-C on Windows, cannot be killed In-Reply-To: <047.917d1da3b05e4d79bd411a581a2d9795@localhost> References: <047.917d1da3b05e4d79bd411a581a2d9795@localhost> Message-ID: <056.f0f2b1f8cf0b753f135e18a6aa4d80fe@localhost> #2758: runghc in stdin mode ignores Ctrl-C on Windows, cannot be killed ----------------------+----------------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------+----------------------------------------------------- Changes (by Deewiant): * cc: Deewiant (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 13 06:42:04 2008 From: trac at galois.com (GHC) Date: Thu Nov 13 06:36:30 2008 Subject: [GHC] #2758: runghc in stdin mode ignores Ctrl-C on Windows, cannot be killed In-Reply-To: <047.917d1da3b05e4d79bd411a581a2d9795@localhost> References: <047.917d1da3b05e4d79bd411a581a2d9795@localhost> Message-ID: <056.d386b39c681beaaa5612a0d1bb5ccfc8@localhost> #2758: runghc in stdin mode ignores Ctrl-C on Windows, cannot be killed ----------------------------+----------------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------------+----------------------------------------------- Changes (by simonmar): * owner: => simonmar * component: Compiler => Runtime System Comment: In 6.8.3 you had to press ^C twice to exit the program, which was also wrong. The new bug is actually a result of the way that we now deliver ^C as an exception. Also, it works with `-threaded` (we had a dialogue with the darcs folks about making that work a while back). I think I have a fix for the non-threaded case, will commit when I've validated. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 13 06:45:49 2008 From: trac at galois.com (GHC) Date: Thu Nov 13 06:40:15 2008 Subject: [GHC] #2768: rts/win32/IOManager.h declarations conflict with windows.h In-Reply-To: <047.ee2a51d822f2ec1d2f12177eff0b4289@localhost> References: <047.ee2a51d822f2ec1d2f12177eff0b4289@localhost> Message-ID: <056.a3e5558cd5caecb7cc14b50b2affb5d8@localhost> #2768: rts/win32/IOManager.h declarations conflict with windows.h ----------------------------+----------------------------------------------- Reporter: Deewiant | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Runtime System | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------------+----------------------------------------------- Changes (by simonmar): * owner: => simonmar * difficulty: => Unknown * milestone: => 6.10.2 Comment: Thanks; will validate and push. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 13 08:12:14 2008 From: trac at galois.com (GHC) Date: Thu Nov 13 08:06:38 2008 Subject: [GHC] #2772: vista detects ghc crash on testsuite ghci derefnull In-Reply-To: <053.44f1e76a6a78ead775340ed4b7d630b0@localhost> References: <053.44f1e76a6a78ead775340ed4b7d630b0@localhost> Message-ID: <062.0855246ab8bba24c93adfc4f6e74cec9@localhost> #2772: vista detects ghc crash on testsuite ghci derefnull -----------------------------+---------------------------------------------- Reporter: TristanAllwood | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: derefnull(ghci) | Architecture: x86 Os: Windows | -----------------------------+---------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: GHC is meant to handle it, with the `rts/win32/seh_excn.h` stuff. From the screenshot I assume it's only the `ghci` way that's failing, so this is a duplicate of #1820. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 13 11:19:07 2008 From: trac at galois.com (GHC) Date: Thu Nov 13 11:13:38 2008 Subject: [GHC] #2777: process created by system "yes" exits with error code 1 Message-ID: <046.b3eaccd2d2b4d795ec4f18ac0fee6137@localhost> #2777: process created by system "yes" exits with error code 1 ------------------------+--------------------------------------------------- Reporter: greenrd | Owner: Type: bug | Status: new Priority: normal | Component: libraries/process Version: 6.10.1 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: Linux ------------------------+--------------------------------------------------- {{{ GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Prelude> :m +System.Process Prelude System.Process> system "yes" }}} results in a long stream of "y"s and then, almost instantly: {{{ ExitFailure 1 }}} This should not happen. The Linux command "yes" is supposed to run forever, and exit code 1 indicates a write error. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 13 11:39:21 2008 From: trac at galois.com (GHC) Date: Thu Nov 13 11:33:48 2008 Subject: [GHC] #2778: Standard output from subprocess has chunks missing Message-ID: <046.96e70e10b86b2b31e8de7a8385d0eda8@localhost> #2778: Standard output from subprocess has chunks missing ------------------------+--------------------------------------------------- Reporter: greenrd | Owner: Type: bug | Status: new Priority: normal | Component: libraries/process Version: 6.10.1 | Severity: major Keywords: | Testcase: Architecture: x86 | Os: Linux ------------------------+--------------------------------------------------- Running {{{ system "hexdump /dev/urandom" }}} in ghci results in output in which chunks of text are missing. For example: {{{ 0002770 b1d8 7abf 562d aff8 3b26 a27b 6e0b ec5e 0002780 9046 7d66 bbb3 42a0 1e32 8fe6 ae7b 1247 0002790 00c2 1d8c befa 7b2f c9a1 3639 0692 c4b4 00027a0 dcfd 7699 2382 1c93 3a06 bfef 4de5 1cb2 00027b0 f432 1992 d077 92a4 4f27 4188 0525 87cf 00027c0 856d 5610 b5c5 1642 9f5b d1e5 a388 1428 00027d0 9ba4 17e3 9852 b716 a438 5e67 c4f3 9a43 00027e0 c718 f425 20db 89ca bdd3 960a 62ae 0ba4 00027f0 535d f015 2f50 3406 305f e6ea b7c1 ce90 0002800 b1e5 7c61 ab0c b60d 0002d10 1652 0720 7e2c f08b 21c6 6c43 a6b5 6f28 0002d20 91c2 a9d6 829c 24bd aead ef71 e063 3ada 0002d30 414f 2c5f 0bc1 364f f852 116c 571d ff50 0002d40 0eb0 8a18 61a6 ab32 d90f c710 7fe6 d9fa 0002d50 fe5f 7585 78a5 f8f2 1641 e915 7996 db7b 0002d60 ab5e d0d6 556c 2e4a 07bd ef60 bf4f 8bf4 0002d70 960b dc59 73df 5227 c284 e7c2 1346 2763 0002d80 a142 fc51 3730 98f5 7939 d851 88c4 86c1 }}} Note the extra long line - and then look at the hexadecimal input offsets at the start of each line. What seems to have happened is that the end of the 0002800 line has been cut off, and then all the lines from there onwards until 0002d00 (including its '\n') are missing. This bug repeats every so often in the output, and on my machine is easy enough to spot by eye. This problem does not occur if I run the command "hexdump /dev/urandom" directly from the shell. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 13 12:29:15 2008 From: trac at galois.com (GHC) Date: Thu Nov 13 12:23:42 2008 Subject: [GHC] #2778: Standard output from subprocess has chunks missing In-Reply-To: <046.96e70e10b86b2b31e8de7a8385d0eda8@localhost> References: <046.96e70e10b86b2b31e8de7a8385d0eda8@localhost> Message-ID: <055.17079151c3ab3615aec777fea8851b94@localhost> #2778: Standard output from subprocess has chunks missing ----------------------------------+----------------------------------------- Reporter: greenrd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/process | Version: 6.10.1 Severity: major | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Linux ----------------------------------+----------------------------------------- Comment (by greenrd): This bug does not occur when ghc -e is used instead of ghci. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 13 12:29:46 2008 From: trac at galois.com (GHC) Date: Thu Nov 13 12:24:11 2008 Subject: [GHC] #2777: process created by system "yes" exits with error code 1 In-Reply-To: <046.b3eaccd2d2b4d795ec4f18ac0fee6137@localhost> References: <046.b3eaccd2d2b4d795ec4f18ac0fee6137@localhost> Message-ID: <055.ba74590238fa4b9d644f1c7394227baf@localhost> #2777: process created by system "yes" exits with error code 1 ----------------------------------+----------------------------------------- Reporter: greenrd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/process | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Linux ----------------------------------+----------------------------------------- Comment (by greenrd): This bug does not occur when ghc -e is used instead of ghci. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 13 12:33:55 2008 From: trac at galois.com (GHC) Date: Thu Nov 13 12:28:22 2008 Subject: [GHC] #2771: GHC fail to Compile Crypto In-Reply-To: <044.89d1bcada3e6d5d964323cdcff7a7706@localhost> References: <044.89d1bcada3e6d5d964323cdcff7a7706@localhost> Message-ID: <053.cd6e58e46092db26d6cda0be331829d9@localhost> #2771: GHC fail to Compile Crypto -------------------------+-------------------------------------------------- Reporter: aivuk | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: duplicate Keywords: | Testcase: Architecture: x86 | Os: Linux -------------------------+-------------------------------------------------- Changes (by Deewiant): * status: new => closed * resolution: => duplicate Comment: Duplicate of #2753. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 13 13:12:49 2008 From: trac at galois.com (GHC) Date: Thu Nov 13 13:07:16 2008 Subject: [GHC] #2395: "Pattern match(es) are overlapped" warning with a single view pattern (ghc 6.9.20080606) In-Reply-To: <047.ecbd48e54b1bf1fee3a4558a1775b513@localhost> References: <047.ecbd48e54b1bf1fee3a4558a1775b513@localhost> Message-ID: <056.22931d74c430b258dd7c6d7959374a39@localhost> #2395: "Pattern match(es) are overlapped" warning with a single view pattern (ghc 6.9.20080606) ------------------------------+--------------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by NeilMitchell): * cc: ndmitchell@gmail.com (added) * os: Linux => Unknown/Multiple * architecture: x86 => Unknown/Multiple Comment: If you use View Patterns, this is absolutely infuriating! In one project I use view patterns in 8 places, so the compilation output becomes so verbose I miss genuine errors. It's fine for view patterns to not participate in overlap/exhaustive checking, but it should do so by _not_ issuing loads of bogus warnings which cannot be worked around :-) This bug seriously impacts on the usability of view patterns, which is a real shame because I'm finding them to be a very useful practical feature. I'd argue for this bug being "major" rather than "minor". -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 13 16:02:15 2008 From: trac at galois.com (GHC) Date: Thu Nov 13 15:56:40 2008 Subject: [GHC] #2758: runghc in stdin mode ignores Ctrl-C on Windows, cannot be killed In-Reply-To: <047.917d1da3b05e4d79bd411a581a2d9795@localhost> References: <047.917d1da3b05e4d79bd411a581a2d9795@localhost> Message-ID: <056.4f2cce1b8f01d96bfeb35ac621bcf006@localhost> #2758: runghc in stdin mode ignores Ctrl-C on Windows, cannot be killed ----------------------------+----------------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------------+----------------------------------------------- Comment (by nominolo): FWIW, I have a similar problem with a program that only reads from a socket using the network-bytestring package. I'll test it as soon as the fix hits HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 14 02:10:39 2008 From: trac at galois.com (GHC) Date: Fri Nov 14 02:05:10 2008 Subject: [GHC] #2767: Type family bug ? In-Reply-To: <043.5d7b08e8b12f70310b2c5608326cbdc1@localhost> References: <043.5d7b08e8b12f70310b2c5608326cbdc1@localhost> Message-ID: <052.71f71cef765727580a64abd97225d8df@localhost> #2767: Type family bug ? ----------------------------------------+----------------------------------- Reporter: test | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown/Multiple | Os: MacOS X ----------------------------------------+----------------------------------- Changes (by test): * cc: tom.schrijvers@cs.kuleuven.be (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 14 06:27:38 2008 From: trac at galois.com (GHC) Date: Fri Nov 14 06:22:01 2008 Subject: [GHC] #2758: runghc in stdin mode ignores Ctrl-C on Windows, cannot be killed In-Reply-To: <047.917d1da3b05e4d79bd411a581a2d9795@localhost> References: <047.917d1da3b05e4d79bd411a581a2d9795@localhost> Message-ID: <056.02479d43481ecf70c263dff8c8b56479@localhost> #2758: runghc in stdin mode ignores Ctrl-C on Windows, cannot be killed ----------------------------+----------------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------------+----------------------------------------------- Comment (by nominolo): Ok, patch {{{ Thu Nov 13 03:43:42 PST 2008 Simon Marlow * notice ^C exceptions when waiting for I/O }}} fixes my problem mentioned above. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 14 07:41:49 2008 From: trac at galois.com (GHC) Date: Fri Nov 14 07:36:13 2008 Subject: [GHC] #2758: runghc in stdin mode ignores Ctrl-C on Windows, cannot be killed In-Reply-To: <047.917d1da3b05e4d79bd411a581a2d9795@localhost> References: <047.917d1da3b05e4d79bd411a581a2d9795@localhost> Message-ID: <056.7d9bd9901db30a7e2aa0281503ffd70f@localhost> #2758: runghc in stdin mode ignores Ctrl-C on Windows, cannot be killed ----------------------------+----------------------------------------------- Reporter: simonmar | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.2 Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------------+----------------------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 14 07:54:04 2008 From: trac at galois.com (GHC) Date: Fri Nov 14 07:48:28 2008 Subject: [GHC] #2778: Standard output from subprocess has chunks missing In-Reply-To: <046.96e70e10b86b2b31e8de7a8385d0eda8@localhost> References: <046.96e70e10b86b2b31e8de7a8385d0eda8@localhost> Message-ID: <055.4efa5a263b9f219b7b85cc66b3c1627f@localhost> #2778: Standard output from subprocess has chunks missing -------------------------------+-------------------------------------------- Reporter: greenrd | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: libraries/process | Version: 6.10.1 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | -------------------------------+-------------------------------------------- Changes (by simonmar): * priority: normal => high * difficulty: => Unknown * milestone: => 6.10.2 Comment: Wow. Am investigating, thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 14 08:11:48 2008 From: trac at galois.com (GHC) Date: Fri Nov 14 08:06:10 2008 Subject: [GHC] #2758: runghc in stdin mode ignores Ctrl-C on Windows, cannot be killed In-Reply-To: <047.917d1da3b05e4d79bd411a581a2d9795@localhost> References: <047.917d1da3b05e4d79bd411a581a2d9795@localhost> Message-ID: <056.995bcee77b1a87b752708750b7420241@localhost> #2758: runghc in stdin mode ignores Ctrl-C on Windows, cannot be killed ----------------------------+----------------------------------------------- Reporter: simonmar | Owner: simonmar Type: merge | Status: new Priority: normal | Milestone: 6.10.2 Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------------+----------------------------------------------- Changes (by simonmar): * owner: igloo => simonmar Comment: oops, one more fix is required for runghc. Am validating now. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 14 08:46:14 2008 From: trac at galois.com (GHC) Date: Fri Nov 14 08:40:37 2008 Subject: [GHC] #2778: Standard output from subprocess has chunks missing In-Reply-To: <046.96e70e10b86b2b31e8de7a8385d0eda8@localhost> References: <046.96e70e10b86b2b31e8de7a8385d0eda8@localhost> Message-ID: <055.3711a656643ef0f352491bcd9f811814@localhost> #2778: Standard output from subprocess has chunks missing -------------------------------+-------------------------------------------- Reporter: greenrd | Owner: igloo Type: merge | Status: new Priority: high | Milestone: 6.10.2 Component: libraries/process | Version: 6.10.1 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | -------------------------------+-------------------------------------------- Changes (by simonmar): * owner: => igloo * type: bug => merge Comment: Fixed: {{{ Fri Nov 14 13:05:46 GMT 2008 Simon Marlow * Don't put stdin into non-blocking mode (#2778, #2777) This used to be necessary when our I/O library needed all FDs in O_NONBLOCK mode, and readline used to put stdin back into blocking mode. Nowadays the I/O library can cope with FDs in blocking mode, and #2778/#2777 show why this is important. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 14 08:46:52 2008 From: trac at galois.com (GHC) Date: Fri Nov 14 08:41:20 2008 Subject: [GHC] #2777: process created by system "yes" exits with error code 1 In-Reply-To: <046.b3eaccd2d2b4d795ec4f18ac0fee6137@localhost> References: <046.b3eaccd2d2b4d795ec4f18ac0fee6137@localhost> Message-ID: <055.1233b5d040223ebd7761ccb9c56d872a@localhost> #2777: process created by system "yes" exits with error code 1 -------------------------------+-------------------------------------------- Reporter: greenrd | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/process | Version: 6.10.1 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | -------------------------------+-------------------------------------------- Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: Turns out to be the same bug as #2778. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 14 09:20:37 2008 From: trac at galois.com (GHC) Date: Fri Nov 14 09:14:58 2008 Subject: [GHC] #2751: GHC 6.10.1 fails to build with --enable-shared configured on Ubuntu 8.04. In-Reply-To: <044.e59a32690b73a04f93e0448da03405c8@localhost> References: <044.e59a32690b73a04f93e0448da03405c8@localhost> Message-ID: <053.d9c96cd37c56db7d61f2a65a340271ac@localhost> #2751: GHC 6.10.1 fails to build with --enable-shared configured on Ubuntu 8.04. ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: build enable-shared | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: `./configure --help` now discourages the use of `--enable-shared` for the time being. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 14 10:52:00 2008 From: trac at galois.com (GHC) Date: Fri Nov 14 10:46:21 2008 Subject: [GHC] #2779: ghc: internal error: mmap() returned memory outside 2Gb Message-ID: <046.19af2873ee6cc18b47281314e3aa1721@localhost> #2779: ghc: internal error: mmap() returned memory outside 2Gb -------------------------------+-------------------------------------------- Reporter: rkapoor | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Linux -------------------------------+-------------------------------------------- On installing ghc binary dist on Ubuntu Hardy 8.4.1 running GHCi gives: GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help ghc: internal error: mmap() returned memory outside 2Gb (GHC version 6.10.1 for x86_64_unknown_linux) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 14 11:38:11 2008 From: trac at galois.com (GHC) Date: Fri Nov 14 11:32:34 2008 Subject: [GHC] #2780: C stack overflow on Windows Message-ID: <051.534ce471972252b8580311fd2911209c@localhost> #2780: C stack overflow on Windows ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Windows ---------------------------------+------------------------------------------ {{{ $ ghc --make Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main.exe ... $ Main C stack overflow in generated code $ type Main.hs module Main where main = error $ show f where f = r where r = r `seq` () }}} It should go {{{}}}, and in some circumstances it does, but in this particular configuration it crashes C. Windows XP, using GHC 6.9.20080916. If run from GHCi then GHCi silently aborts. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 14 13:21:55 2008 From: trac at galois.com (GHC) Date: Fri Nov 14 13:16:16 2008 Subject: [GHC] #2781: Install permissions broken Message-ID: <044.61bd22c82633a255fd3e3d2cc7138fa8@localhost> #2781: Install permissions broken ------------------------------------+--------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: install permissions | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ------------------------------------+--------------------------------------- -rwx------ 1 root root 103 2008-11-14 20:19 /usr/local/bin/ghc-6.10.1* And similarly for all files that I checked, no matter what I set for umask, which should be overridden by software instlals in any case. That has been a problem with other Haskell software install lately as well, but not othe non-Haskell software. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 14 13:47:35 2008 From: trac at galois.com (GHC) Date: Fri Nov 14 13:42:06 2008 Subject: [GHC] #2399: Template Haskell: support for view patterns In-Reply-To: <043.ea0fa95d3ba4304244b4038504ec46d3@localhost> References: <043.ea0fa95d3ba4304244b4038504ec46d3@localhost> Message-ID: <052.85da9cfea1412701fa2f3432cbcbd90a@localhost> #2399: Template Haskell: support for view patterns ------------------------------+--------------------------------------------- Reporter: fons | Owner: Type: feature request | Status: new Priority: low | Milestone: _|_ Component: Template Haskell | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by duncan2nd): * cc: duncan2nd@gmx.de (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 14 14:10:20 2008 From: trac at galois.com (GHC) Date: Fri Nov 14 14:04:43 2008 Subject: [GHC] #2758: runghc in stdin mode ignores Ctrl-C on Windows, cannot be killed In-Reply-To: <047.917d1da3b05e4d79bd411a581a2d9795@localhost> References: <047.917d1da3b05e4d79bd411a581a2d9795@localhost> Message-ID: <056.d034de61e82a2665f330cc8178230cd6@localhost> #2758: runghc in stdin mode ignores Ctrl-C on Windows, cannot be killed ----------------------------+----------------------------------------------- Reporter: simonmar | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.2 Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------------+----------------------------------------------- Changes (by simonmar): * owner: simonmar => igloo Comment: These two patches need to be merged: {{{ Thu Nov 13 03:43:42 PST 2008 Simon Marlow * notice ^C exceptions when waiting for I/O Fri Nov 14 05:09:58 PST 2008 Simon Marlow * close the temporary Handle before removing the file }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 14 14:41:22 2008 From: trac at galois.com (GHC) Date: Fri Nov 14 14:35:44 2008 Subject: [GHC] #2512: MAP_32BIT flag might not be respected under xen? In-Reply-To: <044.02579c65234b2e00edf9fbae992e571c@localhost> References: <044.02579c65234b2e00edf9fbae992e571c@localhost> Message-ID: <053.89374288c14a0fdfc6c56fb7c02c2062@localhost> #2512: MAP_32BIT flag might not be respected under xen? ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: None | Version: 6.8.3 Severity: critical | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------+----------------------------------------------------- Changes (by rkapoor): * cc: rk@trie.org (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 14 14:43:58 2008 From: trac at galois.com (GHC) Date: Fri Nov 14 14:38:20 2008 Subject: [GHC] #2779: ghc: internal error: mmap() returned memory outside 2Gb In-Reply-To: <046.19af2873ee6cc18b47281314e3aa1721@localhost> References: <046.19af2873ee6cc18b47281314e3aa1721@localhost> Message-ID: <055.af9e7b7a6b68e50abf69fc22e82ce528@localhost> #2779: ghc: internal error: mmap() returned memory outside 2Gb -------------------------------+-------------------------------------------- Reporter: rkapoor | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: duplicate Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Linux -------------------------------+-------------------------------------------- Changes (by rkapoor): * status: new => closed * resolution: => duplicate Comment: Closing since the another ticket already exists #2512 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 14 15:57:11 2008 From: trac at galois.com (GHC) Date: Fri Nov 14 15:51:31 2008 Subject: [GHC] #2780: C stack overflow on Windows In-Reply-To: <051.534ce471972252b8580311fd2911209c@localhost> References: <051.534ce471972252b8580311fd2911209c@localhost> Message-ID: <060.35fb24871f57522bdd98d44d2df275da@localhost> #2780: C stack overflow on Windows ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Windows ---------------------------------+------------------------------------------ Comment (by Deewiant): Confirmed for 6.10.0.20081007, also on Windows XP. Here GHCi doesn't crash silently though, it gives the same error: {{{ > :main *** Exception: C stack overflow in generated code }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 14 23:46:20 2008 From: trac at galois.com (GHC) Date: Fri Nov 14 23:40:44 2008 Subject: [GHC] #2753: GHC 6.10.1 cannot compile Crypto-4.1.0 In-Reply-To: <052.22581ce23675b5d58c2247a1ee1a7ede@localhost> References: <052.22581ce23675b5d58c2247a1ee1a7ede@localhost> Message-ID: <061.9ea2fe567c4f3171936aa697368f8cbe@localhost> #2753: GHC 6.10.1 cannot compile Crypto-4.1.0 ------------------------------+--------------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: critical | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by gregwebs): On debian Linux X86 ghc 6.10.1 I encountered this problem. I was able to compile by modifying the cabal file to use -fregs-graph. {{{ Executable SHA1Test Main-Is: SHA1Test.hs Ghc-options: -fregs-graph Other-modules: Codec.Text.Raw Data.Digest.SHA1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 15 06:15:07 2008 From: trac at galois.com (GHC) Date: Sat Nov 15 06:09:25 2008 Subject: [GHC] #2782: Data instance for ratio changed, now incompatible Message-ID: <051.189aa7b9d1c49af18083253419266527@localhost> #2782: Data instance for ratio changed, now incompatible ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ Using the following code: {{{ import Data.Generics -- import Data.Data on 6.10 import Data.Ratio -- data (Integral a) => Ratio a = !a :% !a deriving (Eq) u = undefined :: Ratio Integer ctr t = head $ dataTypeConstrs $ dataTypeOf t ctr2 t = length $ gmapQ (const undefined) $ asTypeOf (fromConstr $ ctr t) t test = ctr2 u }}} Under GHC 6.8.2 I get the answer 0, under GHC 6.10.1 I get the answer "undefined". Both are wrong, but at least the GHC 6.8.2 one works enough for me to use it. So there are a couple of issues here: 1) {{{fromConstr = fromConstrB undefined}}} in Data.Data is a really bad idea - instead of undefined {{{error "Data.Data.fromConstr"}}} would be a million times better. It took 3 hours to even figure out what library was causing the undefined in a 80 module program! base was not my first guess :-) 2) Ratio used to have a workable fromConstr, now it doesn't. Before it gave the wrong answer. It's all to do with the strictness annotations on :%. The new version means I can't use Uniplate with Haskell Source Exts, which is a really big shame. I have no idea what the fix is. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 15 06:43:45 2008 From: trac at galois.com (GHC) Date: Sat Nov 15 06:38:04 2008 Subject: [GHC] #2782: Data instance for ratio changed, now incompatible In-Reply-To: <051.189aa7b9d1c49af18083253419266527@localhost> References: <051.189aa7b9d1c49af18083253419266527@localhost> Message-ID: <060.e7813ed4fe21942f7ebcee0f2a0504ae@localhost> #2782: Data instance for ratio changed, now incompatible ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ Changes (by NeilMitchell): * cc: ndmitchell@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 15 10:07:03 2008 From: trac at galois.com (GHC) Date: Sat Nov 15 10:01:23 2008 Subject: [GHC] #2783: RTS -K/-M options not honored Message-ID: <049.63d82e75e6191178fe162ae9a73c2fd3@localhost> #2783: RTS -K/-M options not honored ---------------------------------+------------------------------------------ Reporter: j.waldmann | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: major Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Linux ---------------------------------+------------------------------------------ I have this program main = print $ do x <- [ 0 .. 5 ] ; let { y = 5 - y } ; return y I compile with ghc-6.10.1 --make and I execute with +RTS -M10m -K10m but still the executable quickly eats up all my memory. (I know the program is silly but still it should crash gracefully.) When I do the same thing with ghc-6.8.3, I get "Heap exhausted", as it should be. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 15 10:07:39 2008 From: trac at galois.com (GHC) Date: Sat Nov 15 10:01:56 2008 Subject: [GHC] #2783: RTS -K/-M options not honored In-Reply-To: <049.63d82e75e6191178fe162ae9a73c2fd3@localhost> References: <049.63d82e75e6191178fe162ae9a73c2fd3@localhost> Message-ID: <058.fe376b1565969add8064089cdc879002@localhost> #2783: RTS -K/-M options not honored ---------------------------+------------------------------------------------ Reporter: j.waldmann | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: major | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Linux ---------------------------+------------------------------------------------ Changes (by j.waldmann): * architecture: Unknown/Multiple => x86 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 15 13:05:53 2008 From: trac at galois.com (GHC) Date: Sat Nov 15 13:00:12 2008 Subject: [GHC] #2782: Data instance for ratio changed, now incompatible In-Reply-To: <051.189aa7b9d1c49af18083253419266527@localhost> References: <051.189aa7b9d1c49af18083253419266527@localhost> Message-ID: <060.5c4afd5b3604bc0a01c45022fd9044e9@localhost> #2782: Data instance for ratio changed, now incompatible ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ Comment (by claus): I'm not sure I follow: neither strictness nor `fromConstr` have changed (I think?). The only change I'm aware of is that the `Data` instance for `Ratio` used to be inconsistent (treating the type as abstract for `gfoldl` and as concrete for `gunfold`), while it now treats the type as concrete for both directions. Your example tries to map a query over the subterms of an undefined `Ratio`, relying on the old half-abstract behaviour for not actually looking for subterms. Whereas with the new instance `gmapQ` will look for subterms and fail. The old behaviour can be restored by making the abstract handling of `Ratio` explicit: {{{ ctr2 t = length $ (gmapQ (const undefined) `extQ` ratio) $ asTypeOf (fromConstr $ ctr t) t test = ctr2 u ratio :: Ratio Integer -> [a] ratio _ = [] }}} Now we get `0` from both versions of ghc. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 15 17:51:01 2008 From: trac at galois.com (GHC) Date: Sat Nov 15 17:45:20 2008 Subject: [GHC] #2784: Cannot call connect with a socket that is already bound. Message-ID: <047.de4c3c5f634fbec7d0b7644c39e5f764@localhost> #2784: Cannot call connect with a socket that is already bound. ---------------------------------+------------------------------------------ Reporter: felixmar | Owner: Type: bug | Status: new Priority: normal | Component: libraries/network Version: 6.10.1 | Severity: normal Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ {{{ > import Network.Socket > sock <- socket AF_INET Datagram 0 Loading package parsec-2.1.0.1 ... linking ... done. Loading package network-2.2.0.1 ... linking ... done. > bindSocket sock (SockAddrInet aNY_PORT iNADDR_ANY) > connect sock undefined *** Exception: user error (connect: can't peform connect on socket in status Bound) }}} Network.Socket.connect checks the !SocketStatus of the socket: {{{ if currentStatus /= NotConnected }}} From [http://www.opengroup.org/onlinepubs/000095399/functions/connect.html The Open Group Base Specifications Issue 6]: "If the socket has not already been bound to a local address, connect() shall bind it to an address which, unless the socket's address family is AF_UNIX, is an unused local address." -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 16 10:26:06 2008 From: trac at galois.com (GHC) Date: Sun Nov 16 10:20:25 2008 Subject: [GHC] #2778: Standard output from subprocess has chunks missing In-Reply-To: <046.96e70e10b86b2b31e8de7a8385d0eda8@localhost> References: <046.96e70e10b86b2b31e8de7a8385d0eda8@localhost> Message-ID: <055.330ad73151119f19fef02c2229b4ca85@localhost> #2778: Standard output from subprocess has chunks missing -------------------------------+-------------------------------------------- Reporter: greenrd | Owner: igloo Type: merge | Status: closed Priority: high | Milestone: 6.10.2 Component: libraries/process | Version: 6.10.1 Severity: major | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 16 10:26:48 2008 From: trac at galois.com (GHC) Date: Sun Nov 16 10:21:03 2008 Subject: [GHC] #2758: runghc in stdin mode ignores Ctrl-C on Windows, cannot be killed In-Reply-To: <047.917d1da3b05e4d79bd411a581a2d9795@localhost> References: <047.917d1da3b05e4d79bd411a581a2d9795@localhost> Message-ID: <056.e54812d112aad447366e34b4a79bb989@localhost> #2758: runghc in stdin mode ignores Ctrl-C on Windows, cannot be killed ----------------------------+----------------------------------------------- Reporter: simonmar | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10.2 Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | 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 Nov 16 10:53:33 2008 From: trac at galois.com (GHC) Date: Sun Nov 16 10:47:51 2008 Subject: [GHC] #2753: GHC 6.10.1 cannot compile Crypto-4.1.0 In-Reply-To: <052.22581ce23675b5d58c2247a1ee1a7ede@localhost> References: <052.22581ce23675b5d58c2247a1ee1a7ede@localhost> Message-ID: <061.9a69663638ba05b82220b59fb99fcc08@localhost> #2753: GHC 6.10.1 cannot compile Crypto-4.1.0 ------------------------------+--------------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: critical | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by igloo): Oh, for some reason I thought that `-fregs-graph` was the default in 6.10, which was why it worked in the past. Is there a reason not to make it the default? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 16 11:27:17 2008 From: trac at galois.com (GHC) Date: Sun Nov 16 11:21:33 2008 Subject: [GHC] #2782: Data instance for ratio changed, now incompatible In-Reply-To: <051.189aa7b9d1c49af18083253419266527@localhost> References: <051.189aa7b9d1c49af18083253419266527@localhost> Message-ID: <060.1a9aea7f861ab3ae83450106c02e9c3f@localhost> #2782: Data instance for ratio changed, now incompatible ------------------------------+--------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * component: Compiler => libraries/base * difficulty: => Unknown * status: new => closed * resolution: => fixed Comment: I've changed the `undefined` as you suggest. If you want the actual behaviour changed, then can you please file a proposal? http://www.haskell.org/haskellwiki/Library_submissions -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 16 11:50:05 2008 From: trac at galois.com (GHC) Date: Sun Nov 16 11:44:18 2008 Subject: [GHC] #2764: gen_contents_index generates links with package.haddock in the path In-Reply-To: <050.3f1d57166b0bf0e303ef4a1822302d5d@localhost> References: <050.3f1d57166b0bf0e303ef4a1822302d5d@localhost> Message-ID: <059.195fbf31c5e8fe07fd0b6b4fe3e30890@localhost> #2764: gen_contents_index generates links with package.haddock in the path ------------------------------+--------------------------------------------- Reporter: juhpetersen | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Documentation | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * owner: => igloo * difficulty: => Unknown * milestone: => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 16 11:51:01 2008 From: trac at galois.com (GHC) Date: Sun Nov 16 11:45:16 2008 Subject: [GHC] #2475: debugger gives "Can't unify" when stopped at an exception In-Reply-To: <044.67056a89ea8901dff63b307a4127f5ba@localhost> References: <044.67056a89ea8901dff63b307a4127f5ba@localhost> Message-ID: <053.aaecb1b0119473e4dbd5c45ecfba9d1a@localhost> #2475: debugger gives "Can't unify" when stopped at an exception ------------------------------------------+--------------------------------- Reporter: igloo | Owner: mnislaih Type: bug | Status: closed Priority: normal | Milestone: 6.10.2 Component: GHCi | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: break011, break017, break024 | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------------------+--------------------------------- Comment (by igloo): This was merged into the 6.10 branch too. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 16 11:52:07 2008 From: trac at galois.com (GHC) Date: Sun Nov 16 11:46:22 2008 Subject: [GHC] #1995: Unsoundness in the RTTI scheme when newtypes are involved In-Reply-To: <047.3d0710ff9b9b1528afeb4de92d082c32@localhost> References: <047.3d0710ff9b9b1528afeb4de92d082c32@localhost> Message-ID: <056.f803da93740e55a69949bd5fb05beddf@localhost> #1995: Unsoundness in the RTTI scheme when newtypes are involved ------------------------------------------+--------------------------------- Reporter: mnislaih | Owner: mnislaih Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.8.2 Severity: major | Resolution: fixed Keywords: | Difficulty: Project (> 1 week) Testcase: print029, print030, print031 | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------------------+--------------------------------- Comment (by igloo): This was merged into the 6.10 branch too. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 16 13:00:41 2008 From: trac at galois.com (GHC) Date: Sun Nov 16 12:55:03 2008 Subject: [GHC] #2342: timer problem under Sparc Solaris for Release Candidate ghc-6.8.2.20080603 In-Reply-To: <045.7c5ad0836c0444e2655d0f93786db19e@localhost> References: <045.7c5ad0836c0444e2655d0f93786db19e@localhost> Message-ID: <054.535ac32904711d745a56e7a5ab6d570c@localhost> #2342: timer problem under Sparc Solaris for Release Candidate ghc-6.8.2.20080603 --------------------------+------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.2 Component: Build System | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: sparc Os: Solaris | --------------------------+------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: OK, closing it. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 16 18:06:52 2008 From: trac at galois.com (GHC) Date: Sun Nov 16 18:01:08 2008 Subject: [GHC] #2785: Memory leakage with socket benchmark program Message-ID: <047.470588859e52453dab1b67a6015374ad@localhost> #2785: Memory leakage with socket benchmark program -------------------------+-------------------------------------------------- Reporter: felixmar | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 6.10.1 | Severity: major Keywords: | Testcase: Architecture: x86 | Os: Windows -------------------------+-------------------------------------------------- Attached benchmark program is similar to the thread-ring benchmark of the language shootout, but in this benchmark threads use UDP messages to communicate. Memory use of the program is stable with GHC-6.8.3/Windows and GHC-6.8.2/Linux but the working set increases about 4K per second when it is compiled with GHC-6.10.1. The number of used threads does not seem to matter. N.B. Benchmark must be compiled with -threaded on Windows otherwise it will block. Run with "threadring t n" where t is the number of threads and n the number of messages that are passed around. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 16 20:22:56 2008 From: trac at galois.com (GHC) Date: Sun Nov 16 20:17:21 2008 Subject: [GHC] #2767: Type family bug ? In-Reply-To: <043.5d7b08e8b12f70310b2c5608326cbdc1@localhost> References: <043.5d7b08e8b12f70310b2c5608326cbdc1@localhost> Message-ID: <052.3621c9081c6bd2a6177e50daafeb9c34@localhost> #2767: Type family bug ? ----------------------------------------+----------------------------------- Reporter: test | Owner: chak Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ----------------------------------------+----------------------------------- Changes (by chak): * owner: => chak * os: MacOS X => Unknown/Multiple -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 16 20:26:55 2008 From: trac at galois.com (GHC) Date: Sun Nov 16 20:21:13 2008 Subject: [GHC] #2775: Type Family panic In-Reply-To: <044.cf027f74305f326c967336b8f3c587bd@localhost> References: <044.cf027f74305f326c967336b8f3c587bd@localhost> Message-ID: <053.48154666645348dbeb333290129a09bf@localhost> #2775: Type Family panic ---------------------------------+------------------------------------------ Reporter: camio | Owner: chak Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: blocker | Resolution: Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ Changes (by chak): * owner: => chak * os: Windows => Unknown/Multiple * architecture: x86 => Unknown/Multiple -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 17 09:46:50 2008 From: trac at galois.com (GHC) Date: Mon Nov 17 09:41:04 2008 Subject: [GHC] #2780: C stack overflow on Windows In-Reply-To: <051.534ce471972252b8580311fd2911209c@localhost> References: <051.534ce471972252b8580311fd2911209c@localhost> Message-ID: <060.429110588cfd10a5f0ab8562297fc707@localhost> #2780: C stack overflow on Windows --------------------------+------------------------------------------------- Reporter: NeilMitchell | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Windows | --------------------------+------------------------------------------------- Changes (by simonmar): * owner: => simonmar * difficulty: => Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 17 09:47:04 2008 From: trac at galois.com (GHC) Date: Mon Nov 17 09:41:18 2008 Subject: [GHC] #2783: RTS -K/-M options not honored In-Reply-To: <049.63d82e75e6191178fe162ae9a73c2fd3@localhost> References: <049.63d82e75e6191178fe162ae9a73c2fd3@localhost> Message-ID: <058.be74f87c16b6b1d9ece286c051ff619f@localhost> #2783: RTS -K/-M options not honored ------------------------+--------------------------------------------------- Reporter: j.waldmann | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ------------------------+--------------------------------------------------- Changes (by simonmar): * owner: => simonmar * difficulty: => Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 17 09:52:55 2008 From: trac at galois.com (GHC) Date: Mon Nov 17 09:47:13 2008 Subject: [GHC] #2753: GHC 6.10.1 cannot compile Crypto-4.1.0 In-Reply-To: <052.22581ce23675b5d58c2247a1ee1a7ede@localhost> References: <052.22581ce23675b5d58c2247a1ee1a7ede@localhost> Message-ID: <061.5ac64ff24c8dffcc507d4cd832bc8acb@localhost> #2753: GHC 6.10.1 cannot compile Crypto-4.1.0 ------------------------------+--------------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: critical | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by simonmar): Replying to [comment:6 igloo]: > Oh, for some reason I thought that `-fregs-graph` was the default in 6.10, which was why it worked in the past. Is there a reason not to make it the default? Partly paranoia: the linear-scan allocator has had a good shakedown, it only has two known bugs (this one and another one that doesn't actually show up in practice), whereas `-fregs-graph` has hardly been tested in the field. Partly performance: I believe `-fregs-graph` is slower, but we haven't measured it systematically yet. We'll probably want `-fregs- graph` to become the default in 6.12, however. I'm still considering whether we want to keep the old allocator around too, perhaps for non- optimised compilations. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 17 09:58:29 2008 From: trac at galois.com (GHC) Date: Mon Nov 17 09:52:41 2008 Subject: [GHC] #2512: MAP_32BIT flag might not be respected under xen? In-Reply-To: <044.02579c65234b2e00edf9fbae992e571c@localhost> References: <044.02579c65234b2e00edf9fbae992e571c@localhost> Message-ID: <053.1956ba0e84ccb3d36f72e6923ac3b196@localhost> #2512: MAP_32BIT flag might not be respected under xen? ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.2 Component: None | Version: 6.8.3 Severity: critical | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------+----------------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => duplicate Comment: A patch has been committed, we need help to test it. Head on over to #2063 (I'm merging these two bugs as they're very closely related). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 17 10:00:33 2008 From: trac at galois.com (GHC) Date: Mon Nov 17 09:54:46 2008 Subject: [GHC] #2063: Breackage on OpenBSD due to mmap remap In-Reply-To: <043.15abf9ca319b437728a2421245ad0407@localhost> References: <043.15abf9ca319b437728a2421245ad0407@localhost> Message-ID: <052.441c3ced1d5072272ab387c6c9be24d2@localhost> #2063: Breackage on OpenBSD due to mmap remap ----------------------------+----------------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: OpenBSD | Difficulty: Moderate (1 day) Testcase: | Architecture: x86_64 (amd64) Os: OpenBSD | ----------------------------+----------------------------------------------- Comment (by simonmar): I've pushed the following speculative fix for this and #2512: {{{ Mon Nov 17 04:05:56 PST 2008 Simon Marlow * Attempt to fix #2512 and #2063; add +RTS -xm
-RTS option On x86_64, the RTS needs to allocate memory in the low 2Gb of the address space. On Linux we can do this with MAP_32BIT, but sometimes this doesn't work (#2512) and other OSs don't support it at all (#2063). So to work around this: - Try MAP_32BIT first, if available. - Otherwise, try allocating memory from a fixed address (by default 1Gb) - We now provide an option to configure the address to allocate from. This allows a workaround on machines where the default breaks, and also provides a way for people to test workarounds that we can incorporate in future releases. }}} We need help to test this, from folks running *BSD on x86_64, and also Xen on x86_64. Igloo: please merge, then keep the bug open for testing. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 17 10:02:30 2008 From: trac at galois.com (GHC) Date: Mon Nov 17 09:56:43 2008 Subject: [GHC] #2063: x86_64: RTS linker depends on working MAP_32BIT In-Reply-To: <043.15abf9ca319b437728a2421245ad0407@localhost> References: <043.15abf9ca319b437728a2421245ad0407@localhost> Message-ID: <052.ffc8fb6a13e95244d14b3036ae855c88@localhost> #2063: x86_64: RTS linker depends on working MAP_32BIT ------------------------------+--------------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: OpenBSD | Difficulty: Moderate (1 day) Testcase: | Architecture: x86_64 (amd64) Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by simonmar): * os: OpenBSD => Unknown/Multiple * summary: Breackage on OpenBSD due to mmap remap => x86_64: RTS linker depends on working MAP_32BIT -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 17 11:46:44 2008 From: trac at galois.com (GHC) Date: Mon Nov 17 11:40:57 2008 Subject: [GHC] #2786: Blackhole loops are not detected and reported in GHCi Message-ID: <047.3bdf34422fea8ddbcf6903bcf24a5b4b@localhost> #2786: Blackhole loops are not detected and reported in GHCi ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: GHCi | Version: 6.8.3 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ While looking into #2783 I noticed this. It has never worked, and I was vaguely aware of it, but it seems we don't have a ticket. {{{ let x = x in x }}} in GHCi should report `<>`. One issue is that the `interruptTargetThread` global var points to the `ThreadId` running the expression, which will keep it alive and prevent it from being detected as deadlocked. But that's not all: I think the expression itself is being retained by the main thread (perhaps because it is bound to `it`), which will cause the child thread to also stay alive. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 17 11:52:44 2008 From: trac at galois.com (GHC) Date: Mon Nov 17 11:46:56 2008 Subject: [GHC] #2783: RTS -K/-M options not honored In-Reply-To: <049.63d82e75e6191178fe162ae9a73c2fd3@localhost> References: <049.63d82e75e6191178fe162ae9a73c2fd3@localhost> Message-ID: <058.415250a1a8d020838873d1de01632d3f@localhost> #2783: RTS -K/-M options not honored ----------------------------+----------------------------------------------- Reporter: j.waldmann | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.2 Component: Runtime System | Version: 6.10.1 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------------+----------------------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge * component: Compiler => Runtime System * milestone: => 6.10.2 Comment: Fixed: {{{ Mon Nov 17 06:45:15 PST 2008 Simon Marlow * Fix #2783: detect black-hole loops properly At some point we regressed on detecting simple black-hole loops. This happened due to the introduction of duplicate-work detection for parallelism: a black-hole loop looks very much like duplicate work, except it's duplicate work being performed by the very same thread. So we have to detect and handle this case. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 17 14:45:56 2008 From: trac at galois.com (GHC) Date: Mon Nov 17 14:40:07 2008 Subject: [GHC] #2787: Panic (core lint failure) with type synonym in GHC 6.10.1 Message-ID: <049.16b406b9b4b75d10bbd6f184f46c2987@localhost> #2787: Panic (core lint failure) with type synonym in GHC 6.10.1 ---------------------------+------------------------------------------------ Reporter: BenMoseley | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 6.10.1 | Severity: major Keywords: | Testcase: Architecture: x86 | Os: Windows ---------------------------+------------------------------------------------ This causes a panic: {{{ {-# LANGUAGE TypeFamilies, GADTs #-} module GHCBug ( PVR(..), Core(..), analyseCore ) where data Core a where Ctr :: Core Double data PVR a = PVR a deriving (Eq, Show) class Sub a where type AssocSyn a :: * -> * instance Sub Double where type AssocSyn Double = PVR analyseCore :: Core a -> ((AssocSyn a) a) analyseCore Ctr = pvr where -- GHC panics if we use the below as the type sig for 'pvr' pvr :: PVR ~ AssocSyn a => (AssocSyn a) a -- pvr :: (AssocSyn a) a pvr = undefined main :: IO () main = print "ok" }}} The basic compiler panic is: {{{ c:/ws/main/depot/QA/EDG/EDG_priv/FPF_Dev.br/src $ ghc -main-is GHCBug ~/GHCBug.hs ghc.exe: panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-unknown-mingw32): initC: srt_lbl Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The core lint failure part is: {{{ *** Checking old interface for main:GHCBug: *** Parser: *** Renamer/typechecker: *** Desugar: Result size = 199 *** Core Lint Errors: in result of Desugar *** {-# LINE 21 "F:\ME\GHCBug.hs #-}: [RHS of pvr_awa :: GHCBug.AssocSyn GHC.Types.Double GHC.Types.Double] pvr_afN is out of scope *** Offending Program *** }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 17 20:43:02 2008 From: trac at galois.com (GHC) Date: Mon Nov 17 20:37:17 2008 Subject: [GHC] #2787: Panic (core lint failure) with type synonym in GHC 6.10.1 In-Reply-To: <049.16b406b9b4b75d10bbd6f184f46c2987@localhost> References: <049.16b406b9b4b75d10bbd6f184f46c2987@localhost> Message-ID: <058.1f7684df471e56f55833f5bf9a17919b@localhost> #2787: Panic (core lint failure) with type synonym in GHC 6.10.1 ----------------------------------------+----------------------------------- Reporter: BenMoseley | Owner: chak Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.10.1 Severity: major | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Unknown/Multiple ----------------------------------------+----------------------------------- Changes (by chak): * owner: => chak * os: Windows => Unknown/Multiple Comment: Thanks for the bug report. In your code example, you could write {{{ ... where pvr :: PVR a pvr = undefined }}} That signature would be equivalent to the one that causes the panic. I am just suggesting this as a possible work around until GHC has been fixed, but maybe it is only applicable to the stripped down example of your bug report. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 18 02:18:00 2008 From: trac at galois.com (GHC) Date: Tue Nov 18 02:12:09 2008 Subject: [GHC] #2788: GHC panic Message-ID: <047.5ac0bbd39d0957669e5f57a594afec3c@localhost> #2788: GHC panic -------------------------+-------------------------------------------------- Reporter: rodprice | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: MacOS X -------------------------+-------------------------------------------------- Attempting to compile SHA1Test.hs in the Crypto-4.1.0 package on Hackage generates the following ghc: panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-apple-darwin): RegAllocLinear.getStackSlotFor: out of stack slots, try -fregs- graph Compiling by hand with ghc --make -fglasgow-exts -fregs-graph SHA1Test.hs resolves the problem. I'm using an Intel MacBook Pro running Leopard (10.5.5). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 18 02:26:16 2008 From: trac at galois.com (GHC) Date: Tue Nov 18 02:20:29 2008 Subject: [GHC] #2787: Panic (core lint failure) with type synonym in GHC 6.10.1 In-Reply-To: <049.16b406b9b4b75d10bbd6f184f46c2987@localhost> References: <049.16b406b9b4b75d10bbd6f184f46c2987@localhost> Message-ID: <058.365268b4d516c92a79f536de69f54f7c@localhost> #2787: Panic (core lint failure) with type synonym in GHC 6.10.1 ----------------------------------------+----------------------------------- Reporter: BenMoseley | Owner: chak Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.10.1 Severity: major | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Unknown/Multiple ----------------------------------------+----------------------------------- Comment (by BenMoseley): Thanks for the response. I've managed to work around it without too much trouble, so it's not directly urgent for us at the moment. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 18 03:38:01 2008 From: trac at galois.com (GHC) Date: Tue Nov 18 03:32:10 2008 Subject: [GHC] #2788: GHC panic In-Reply-To: <047.5ac0bbd39d0957669e5f57a594afec3c@localhost> References: <047.5ac0bbd39d0957669e5f57a594afec3c@localhost> Message-ID: <056.e607c8a0f9a7bf5810b706ad23d4e669@localhost> #2788: GHC panic -------------------------+-------------------------------------------------- Reporter: rodprice | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: duplicate Keywords: | Testcase: Architecture: x86 | Os: MacOS X -------------------------+-------------------------------------------------- Changes (by Deewiant): * status: new => closed * resolution: => duplicate Comment: Duplicate of #2753. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 18 04:04:23 2008 From: trac at galois.com (GHC) Date: Tue Nov 18 03:58:33 2008 Subject: [GHC] #2770: Missing check that C compiler is C99 compatible In-Reply-To: <045.e59ec55e01d8ef8d16caa02433e3c648@localhost> References: <045.e59ec55e01d8ef8d16caa02433e3c648@localhost> Message-ID: <054.20e6e929c63c0eadd6ea5ae828b206af@localhost> #2770: Missing check that C compiler is C99 compatible -----------------------------+---------------------------------------------- Reporter: jputcu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.10.1 Severity: blocker | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Linux -----------------------------+---------------------------------------------- Changes (by jputcu): * os: Unknown/Multiple => Linux * architecture: Unknown/Multiple => x86 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 18 07:42:44 2008 From: trac at galois.com (GHC) Date: Tue Nov 18 07:36:55 2008 Subject: [GHC] #2780: C stack overflow on Windows In-Reply-To: <051.534ce471972252b8580311fd2911209c@localhost> References: <051.534ce471972252b8580311fd2911209c@localhost> Message-ID: <060.319c69c70ca02dc54b9af63cf24b5597@localhost> #2780: C stack overflow on Windows --------------------------+------------------------------------------------- Reporter: NeilMitchell | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Windows | --------------------------+------------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => duplicate Comment: same bug as #2783 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 18 09:00:08 2008 From: trac at galois.com (GHC) Date: Tue Nov 18 08:54:20 2008 Subject: [GHC] #2120: Arrays allow out-of-bounds indexes In-Reply-To: <046.df9dbe29ac2a6f0cde1841f7056aebbe@localhost> References: <046.df9dbe29ac2a6f0cde1841f7056aebbe@localhost> Message-ID: <055.0d173a6f5c003d289ce06c50239adc71@localhost> #2120: Arrays allow out-of-bounds indexes -------------------------------+-------------------------------------------- Reporter: amthrax | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: libraries (other) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | -------------------------------+-------------------------------------------- Changes (by simonmar): * milestone: Not GHC => 6.12 branch Comment: It's not always necessary to do both checks, for example it suffices to do the second check for ordinary one-dimensional integral indices. So perhaps the cost of doing this properly won't be so bad. Moving this to the 6.12 milestone - it was the GHC project that broke it, so we should fix it again :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 18 09:08:19 2008 From: trac at galois.com (GHC) Date: Tue Nov 18 09:02:29 2008 Subject: [GHC] #2063: x86_64: RTS linker depends on working MAP_32BIT In-Reply-To: <043.15abf9ca319b437728a2421245ad0407@localhost> References: <043.15abf9ca319b437728a2421245ad0407@localhost> Message-ID: <052.6d78380a9d0203614a22bc905240178f@localhost> #2063: x86_64: RTS linker depends on working MAP_32BIT ------------------------------+--------------------------------------------- Reporter: dons | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.2 Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: OpenBSD | Difficulty: Moderate (1 day) Testcase: | Architecture: x86_64 (amd64) Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by simonmar): * owner: => igloo * type: bug => merge Comment: note this patch also needs to be merge: {{{ Mon Nov 17 06:28:31 PST 2008 Simon Marlow * fix compile breakage on Windows }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 18 15:56:56 2008 From: trac at galois.com (GHC) Date: Tue Nov 18 15:51:05 2008 Subject: [GHC] #2063: x86_64: RTS linker depends on working MAP_32BIT In-Reply-To: <043.15abf9ca319b437728a2421245ad0407@localhost> References: <043.15abf9ca319b437728a2421245ad0407@localhost> Message-ID: <052.e0f2bcbd172f94ee8b38fcb5555cb6a9@localhost> #2063: x86_64: RTS linker depends on working MAP_32BIT ------------------------------+--------------------------------------------- Reporter: dons | Owner: igloo Type: task | Status: new Priority: normal | Milestone: 6.10.2 Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: OpenBSD | Difficulty: Moderate (1 day) Testcase: | Architecture: x86_64 (amd64) Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * type: merge => task Comment: Both merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 18 15:57:48 2008 From: trac at galois.com (GHC) Date: Tue Nov 18 15:51:59 2008 Subject: [GHC] #2063: x86_64: RTS linker depends on working MAP_32BIT In-Reply-To: <043.15abf9ca319b437728a2421245ad0407@localhost> References: <043.15abf9ca319b437728a2421245ad0407@localhost> Message-ID: <052.a18a904e1394f2708b4ef46b88910cbc@localhost> #2063: x86_64: RTS linker depends on working MAP_32BIT ------------------------------+--------------------------------------------- Reporter: dons | Owner: Type: task | Status: new Priority: normal | Milestone: 6.10.2 Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: OpenBSD | Difficulty: Moderate (1 day) Testcase: | Architecture: x86_64 (amd64) Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * owner: igloo => -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 18 15:59:03 2008 From: trac at galois.com (GHC) Date: Tue Nov 18 15:53:12 2008 Subject: [GHC] #2783: RTS -K/-M options not honored In-Reply-To: <049.63d82e75e6191178fe162ae9a73c2fd3@localhost> References: <049.63d82e75e6191178fe162ae9a73c2fd3@localhost> Message-ID: <058.2b0543b1c0c5ea11788c2139d8b6926d@localhost> #2783: RTS -K/-M options not honored ----------------------------+----------------------------------------------- Reporter: j.waldmann | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10.2 Component: Runtime System | Version: 6.10.1 Severity: major | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------------+----------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 19 08:14:21 2008 From: trac at galois.com (GHC) Date: Wed Nov 19 08:08:28 2008 Subject: [GHC] #2789: GMP update required Message-ID: <047.d40b0b4f133d6bc7573ed702970e3886@localhost> #2789: GMP update required ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 6.10.2 Component: Build System | Version: 6.8.3 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ The GMP in GHC's tree is slightly out of date; GMP suffered from the same issue with gcc's extern inline behaviour as us (#2469), and fixed it in 4.2.2 it seems. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 19 09:09:58 2008 From: trac at galois.com (GHC) Date: Wed Nov 19 09:04:04 2008 Subject: [GHC] #2790: Use -fregs-graph by default Message-ID: <044.e23cb1a138a9b4ed2c315b0444e4b3fc@localhost> #2790: Use -fregs-graph by default ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: task | Status: new Priority: high | Milestone: 6.12 branch Component: Compiler | Version: 6.8.3 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ Check performance of `-fregs-graph` vs the default (linear0scan allocator). Assuming that all is well, make `-fregs-graph` the new default, and add a `-fregs-linear` flag for the current behaviour. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 19 09:17:41 2008 From: trac at galois.com (GHC) Date: Wed Nov 19 09:11:47 2008 Subject: [GHC] #2791: Allow two versions of GHC to be installed simultaneously with the OS X installer Message-ID: <044.1f391cee5315bd35beec9a86f78138d3@localhost> #2791: Allow two versions of GHC to be installed simultaneously with the OS X installer ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Build System | Version: 6.8.3 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ Currently, for some people at least, installing a 6.10 series OS X installer will remove the 6.8 series GHC. We'd like it to leave the old one there (although the symlinks for commands like `ghc` will no longer point to it). More details are in this thread: http://www.haskell.org/pipermail/glasgow-haskell- users/2008-November/015904.html -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 19 09:50:21 2008 From: trac at galois.com (GHC) Date: Wed Nov 19 09:44:28 2008 Subject: [GHC] #2768: rts/win32/IOManager.h declarations conflict with windows.h In-Reply-To: <047.ee2a51d822f2ec1d2f12177eff0b4289@localhost> References: <047.ee2a51d822f2ec1d2f12177eff0b4289@localhost> Message-ID: <056.2de4fc1fd2fcd38698b2fae58696e14c@localhost> #2768: rts/win32/IOManager.h declarations conflict with windows.h ----------------------------+----------------------------------------------- Reporter: Deewiant | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.2 Component: Runtime System | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------------+----------------------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: Fixed, to merge: {{{ Thu Nov 13 03:46:26 PST 2008 Simon Marlow * #2768: fix compatibility problem with newer version of mingw }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 19 11:05:18 2008 From: trac at galois.com (GHC) Date: Wed Nov 19 10:59:25 2008 Subject: [GHC] #2792: getEnvironment segfaults under ghci 6.6 x86_64 Message-ID: <046.46cd9ea14515f0ea2bee58a0fb921fb0@localhost> #2792: getEnvironment segfaults under ghci 6.6 x86_64 -------------------------------+-------------------------------------------- Reporter: droundy | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.6 | Severity: normal Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Linux -------------------------------+-------------------------------------------- I know this is a very old version of ghc, but thought it'd be worth reporting, since it's possible that some obscure set of circumstances may trigger it, and it seems possible that it's present in later versions of getEnvironment. The following file segfaults on two machines when I execute it with runghc: import System.Environment ( getEnvironment ) main = do getEnvironment >>= (putStrLn . unlines . map show) putStrLn "I'm still alive" I'm not sure what triggers this, but it happens on two debian etch x86_64 machines, but not on my debian etch 32-bit machine. The script runs fine if I compile it with ghc --make on any of these machines. A quick shows that ghci also segfaults if I call getEnvironment. I'd be very surprised if this isn't already fixed, but since I came across it, it seemed best to mention it. I find it somewhat puzzling that it only shows up in ghci. David -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 19 12:41:29 2008 From: trac at galois.com (GHC) Date: Wed Nov 19 12:35:36 2008 Subject: [GHC] #2754: Strictness analyzer fails on an implementation of foldl In-Reply-To: <045.b34db0d1501300b44384b2b8b33f4b1f@localhost> References: <045.b34db0d1501300b44384b2b8b33f4b1f@localhost> Message-ID: <054.bbafb1f8e0e6bf5ff8e420cc591eea46@localhost> #2754: Strictness analyzer fails on an implementation of foldl -----------------------------+---------------------------------------------- Reporter: nimnul | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | -----------------------------+---------------------------------------------- Comment (by simonpj): I think you're suggesting the following: if the compiler sees `foldl` applied to a strict function, use a {{{foldl'}}} instead. That's a reasonable suggestion but tricky for the compiler to automate. It would have to (a) spot the opportunity, (b) generate a specialised version (that's {{{foldl'}}}), and (c) spot applications of `foldl` to a strict function, and use the specialised version. That's a big ask. GHC is not clever enough to do any of these three! Even (c) is tricky: GHC's current rule matcher doesn't take strictness into account. Would it matter if the function was only strict in its first argument? Or its second? You sensibly suggest that (a), at least, might be programmer driven. But even then you need a language in which the programm can express the intent (how to say "generate a specialised version for a bi-strict function argument"?). And there's still (b) and (c) to worry about. So while yes, we're very open to suggestions for improvements, I don't see how to take action on this one. However two methods are already supported: * Write the function non-recursively, as Don suggests. Then it can be inlined at every use site, which generates a very specialised copy! * Use Template Haskell; this is the direct analogue of what you do with template functions in C++ Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 19 12:43:18 2008 From: trac at galois.com (GHC) Date: Wed Nov 19 12:37:36 2008 Subject: [GHC] #2793: CLDouble is nothing like a long double Message-ID: <047.5dadea2fc38a170289501238d399f214@localhost> #2793: CLDouble is nothing like a long double ---------------------------------+------------------------------------------ Reporter: jedbrown | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.11 | Severity: normal Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ This affects all versions of GHC. Why does the type exist when it is just a synonym for CDouble? Either it should actually become a `long double' as the documentation says or it should just not exist. From Foreign/C/Types.hs: {{{ -- HACK: Currently no long double in the FFI, so we simply re-use double -- | Haskell type representing the C @long double@ type. FLOATING_TYPE(CLDouble,tyConCLDouble,"CLDouble",HTYPE_DOUBLE) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 19 17:11:23 2008 From: trac at galois.com (GHC) Date: Wed Nov 19 17:05:35 2008 Subject: [GHC] #2792: getEnvironment segfaults under ghci 6.6 x86_64 In-Reply-To: <046.46cd9ea14515f0ea2bee58a0fb921fb0@localhost> References: <046.46cd9ea14515f0ea2bee58a0fb921fb0@localhost> Message-ID: <055.cb07e2db22d9ac639e35b1b94267c61e@localhost> #2792: getEnvironment segfaults under ghci 6.6 x86_64 -------------------------------+-------------------------------------------- Reporter: droundy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.6 Severity: normal | Resolution: Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Linux -------------------------------+-------------------------------------------- Comment (by duncan): Previously reported as ticket #781 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 19 17:16:35 2008 From: trac at galois.com (GHC) Date: Wed Nov 19 17:10:41 2008 Subject: [GHC] #2754: Strictness analyzer fails on an implementation of foldl In-Reply-To: <045.b34db0d1501300b44384b2b8b33f4b1f@localhost> References: <045.b34db0d1501300b44384b2b8b33f4b1f@localhost> Message-ID: <054.b26a57961cc5f01ba4b94c48d677e21a@localhost> #2754: Strictness analyzer fails on an implementation of foldl -----------------------------+---------------------------------------------- Reporter: nimnul | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | -----------------------------+---------------------------------------------- Comment (by duncan): I've often wanted to write rules that match on strictness properties. This is one good example where it'd be useful. If (c) is possible then (a) and (b) can be done by the lib author (as with other rules). -- Ticket URL: GHC The Glasgow Haskell Compiler From mechvel at botik.ru Thu Nov 20 04:05:51 2008 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Thu Nov 20 03:59:57 2008 Subject: -XDisambiguateRecordFields Message-ID: <20081120090551.GA3328@scico.botik.ru> The ghc-6.10.1 doc writes about -fdisambiguate-record-fields, the compiler does not recognize it, also it does not recognize -XDisambiguate-record-fields, and it does recognize -XDisambiguateRecordFields. Also is not it better to uniformly use an upper case letter instead of dash everywhere in flags? Regards, ----------------- Serge Mechveliani mechvel@botik.ru From trac at galois.com Thu Nov 20 05:16:15 2008 From: trac at galois.com (GHC) Date: Thu Nov 20 05:10:22 2008 Subject: [GHC] #2794: Bootstrapping ghc-6.4.3 hangs in call to "ghc-pkg-inplace" Message-ID: <045.51a34987f6c098b166e3866c58821344@localhost> #2794: Bootstrapping ghc-6.4.3 hangs in call to "ghc-pkg-inplace" -----------------------+---------------------------------------------------- Reporter: cspiel | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.4.3 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: Linux -----------------------+---------------------------------------------------- I want to bootstrap ghc-6.4.3 with ghc-6.2.2 on an i686 Linux system based on libc-2.2.4. The bootstrap '''make''' runs ok until the following command: {{{ ../utils/ghc-pkg/ghc-pkg-inplace --force --update-package GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 20 07:08:58 2008 From: trac at galois.com (GHC) Date: Thu Nov 20 07:03:11 2008 Subject: [GHC] #2794: Bootstrapping ghc-6.4.3 hangs in call to "ghc-pkg-inplace" In-Reply-To: <045.51a34987f6c098b166e3866c58821344@localhost> References: <045.51a34987f6c098b166e3866c58821344@localhost> Message-ID: <054.fdff5d219c44386e3ca1d2ad79dc42d1@localhost> #2794: Bootstrapping ghc-6.4.3 hangs in call to "ghc-pkg-inplace" -----------------------------+---------------------------------------------- Reporter: cspiel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.4.3 Severity: normal | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Linux -----------------------------+---------------------------------------------- Comment (by maeder): Is there no binary distribution of an even newer ghc version that works with libc-2.2.4? (I didn't find one under http://haskell.org/ghc/dist/) Is your ghc-6.2.2 from http://haskell.org/ghc/dist/6.2.2/ghc-6.2.2-i386 -linux-glibc2.2.tar.bz2? I don't see a release of ghc-6.4.3. So try ghc-6.4.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From simonpj at microsoft.com Thu Nov 20 07:28:57 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Nov 20 07:23:03 2008 Subject: -XDisambiguateRecordFields In-Reply-To: <20081120090551.GA3328@scico.botik.ru> References: <20081120090551.GA3328@scico.botik.ru> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C331924195CE@EA-EXMSG-C334.europe.corp.microsoft.com> It's a documentation bug -- sorry. I'll fix that. The flag is -XDisambiguateRecordFields Simon | -----Original Message----- | From: glasgow-haskell-bugs-bounces@haskell.org [mailto:glasgow-haskell-bugs- | bounces@haskell.org] On Behalf Of Serge D. Mechveliani | Sent: 20 November 2008 09:06 | To: glasgow-haskell-bugs@haskell.org | Subject: -XDisambiguateRecordFields | | The ghc-6.10.1 doc writes about -fdisambiguate-record-fields, | the compiler does not recognize it, | also it does not recognize -XDisambiguate-record-fields, | and it does recognize -XDisambiguateRecordFields. | | Also is not it better to uniformly use an upper case letter instead of | dash everywhere in flags? | | Regards, | | ----------------- | Serge Mechveliani | mechvel@botik.ru | | _______________________________________________ | Glasgow-haskell-bugs mailing list | Glasgow-haskell-bugs@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Thu Nov 20 09:35:02 2008 From: trac at galois.com (GHC) Date: Thu Nov 20 09:29:15 2008 Subject: [GHC] #2794: Bootstrapping ghc-6.4.3 hangs in call to "ghc-pkg-inplace" In-Reply-To: <045.51a34987f6c098b166e3866c58821344@localhost> References: <045.51a34987f6c098b166e3866c58821344@localhost> Message-ID: <054.90bc00c1c7dff6b08e23c379e044409e@localhost> #2794: Bootstrapping ghc-6.4.3 hangs in call to "ghc-pkg-inplace" -----------------------------+---------------------------------------------- Reporter: cspiel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.4.3 Severity: normal | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Linux -----------------------------+---------------------------------------------- Comment (by cspiel): Replying to [comment:1 maeder]: > Is there no binary distribution of an even newer ghc version > that works with libc-2.2.4? (I didn't find one under > http://haskell.org/ghc/dist/) Sadly, I'm not aware of any newer distro. Libc-2.2 is ancient. > Is your ghc-6.2.2 from > http://haskell.org/ghc/dist/6.2.2/ghc-6.2.2-i386-linux-glibc2.2.tar.bz2? Yes. > I don't see a release of ghc-6.4.3. So try ghc-6.4.2 Using ghc-6.4.2 on my system gives {{{ ghc-6.4.2: /lib/libc.so.6: version `GLIBC_2.3' not found (required by ghc-6.4.2) ghc-6.4.2: /lib/libpthread.so.0: version `GLIBC_2.3.2' not found (required by ghc-6.4.2) }}} as expected. :( -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 20 09:48:07 2008 From: trac at galois.com (GHC) Date: Thu Nov 20 09:42:09 2008 Subject: [GHC] #2792: getEnvironment segfaults under ghci 6.6 x86_64 In-Reply-To: <046.46cd9ea14515f0ea2bee58a0fb921fb0@localhost> References: <046.46cd9ea14515f0ea2bee58a0fb921fb0@localhost> Message-ID: <055.c7de9e93f103268150a2f2b494302fc9@localhost> #2792: getEnvironment segfaults under ghci 6.6 x86_64 ---------------------+------------------------------------------------------ Reporter: droundy | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.6 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 David, and thanks to Duncan for finding the original ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 20 09:53:07 2008 From: trac at galois.com (GHC) Date: Thu Nov 20 09:47:16 2008 Subject: [GHC] #2794: Bootstrapping ghc-6.4.3 hangs in call to "ghc-pkg-inplace" In-Reply-To: <045.51a34987f6c098b166e3866c58821344@localhost> References: <045.51a34987f6c098b166e3866c58821344@localhost> Message-ID: <054.d032d28c5f186d8817a35755cdbf030b@localhost> #2794: Bootstrapping ghc-6.4.3 hangs in call to "ghc-pkg-inplace" -----------------------------+---------------------------------------------- Reporter: cspiel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.4.3 Severity: normal | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Linux -----------------------------+---------------------------------------------- Comment (by maeder): Try building ghc-6.4.2 or ghc-6.6.1 from sources using ghc-6.2.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 20 09:55:53 2008 From: trac at galois.com (GHC) Date: Thu Nov 20 09:50:03 2008 Subject: [GHC] #2794: Bootstrapping ghc-6.4.3 hangs in call to "ghc-pkg-inplace" In-Reply-To: <045.51a34987f6c098b166e3866c58821344@localhost> References: <045.51a34987f6c098b166e3866c58821344@localhost> Message-ID: <054.99e4d54d85ae3040e7a34c9cb21b4977@localhost> #2794: Bootstrapping ghc-6.4.3 hangs in call to "ghc-pkg-inplace" --------------------------+------------------------------------------------- Reporter: cspiel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.4.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | --------------------------+------------------------------------------------- Changes (by simonmar): * difficulty: => Unknown Comment: I'm not sure we're going to be able to help much other than to give you some tips for debugging it. I'd start by disassembling __stginit_DistributionziCompatziReadP_ and stepping forward in gdb to see why it's looping. Try compiling ghc-pkg or Distribution.Compat.ReadP with -fasm and see if that helps. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 20 12:49:59 2008 From: trac at galois.com (GHC) Date: Thu Nov 20 12:44:18 2008 Subject: [GHC] #2794: Bootstrapping ghc-6.4.3 hangs in call to "ghc-pkg-inplace" In-Reply-To: <045.51a34987f6c098b166e3866c58821344@localhost> References: <045.51a34987f6c098b166e3866c58821344@localhost> Message-ID: <054.2d038b2c31710ddc63b226a2e5fd6e72@localhost> #2794: Bootstrapping ghc-6.4.3 hangs in call to "ghc-pkg-inplace" --------------------------+------------------------------------------------- Reporter: cspiel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.4.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | --------------------------+------------------------------------------------- Comment (by cspiel): Replying to [comment:4 simonmar]: > Try compiling ghc-pkg or Distribution.Compat.ReadP with -fasm > and see if that helps. Compiling just ''ghc-pkg'' or just ''readp.hs'', or both with option {{{-fasm}}} does not remove the problem. '''ghc-pkg''' still hangs. Then I pulled out the big mallet and said {{{ make clean make EXTRA_HC_OPTS=-fasm }}} in the root directory. This makes the problem go away and the bootstraping run grinds on for a long long time (as it should be). However, after a while I run into {{{ ../compiler/ghc-inplace -H16m -O -optc-O2 -static -I/site/include -I. -#include HCIncludes.h -fvia-C -dcmm-lint -#include posix/Itimer.h -fasm -c PrimOps.cmm -o PrimOps.o ghc-6.6.1: panic! (the 'impossible' happened) (GHC version 6.6.1 for i386-unknown-linux): iselExpr64(i386) -_c23::I64 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Following meader's advice I used ghc-6.6.1 for this run. ghc-6.4.3 faults at a different file: {{{ ../../ghc/compiler/ghc-inplace -H16m -O -O2 -static -I. -#include Prelude.h -#include Rts.h -#include RtsFlags.h -#include RtsUtils.h -#include StgRun.h -#include Schedule.h -#include Printer.h -#include Sanity.h -#include STM.h -#include Storage.h -#include SchedAPI.h -#include Timer.h -#include Itimer.h -#include ProfHeap.h -#include LdvProfile.h -#include Profiling.h -#include Apply.h -fvia-C -dcmm-lint -fasm -c Apply.cmm -o Apply.o ghc-6.4.3: panic! (the `impossible' happened, GHC version 6.4.3): nativeGen/RegisterAlloc.hs:286: Non-exhaustive patterns in function livenessSCCs Please report this as a compiler bug. See: http://www.haskell.org/ghc/reportabug }}} So, it looks like a clever use of "{{{-fasm}}}" could do the job: Get '''ghc-phk''' built with "{{{-fasm}}}" then interrupt and continue without the option. It won't be pretty, but I want a working Haskell compiler and not a beauty prize. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 20 16:37:15 2008 From: trac at galois.com (GHC) Date: Thu Nov 20 16:31:16 2008 Subject: [GHC] #2795: The Network.Socket library does not take into account that the bits in the network are sent as big enddian. Message-ID: <044.6c385a1093d32284095f65013344ce56@localhost> #2795: The Network.Socket library does not take into account that the bits in the network are sent as big enddian. -----------------------------------------------------------------------+---- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: libraries/network Version: | Severity: major Keywords: socket port number big-enddian little-enddian conflict | Testcase: Architecture: x86 | Os: Linux -----------------------------------------------------------------------+---- We got the program (1) below that is supposed to open a server in the port 51777. However, when we run the program, we observed that the port created was the number 16842. We believe that this difference comes from the fact that we run the program in a little enddian machine (Intel processor) and the socket library consider big enddian numbers instead. If we take 51777 and converted as indicated by function conv (see (2)), the socket open is indeed 51777. Kind regards, Alejandro Russo & Josef Svenningsson (1) import Network.Socket import System main = do s <- socket AF_INET Stream 0 arg <- getArgs let shost = head arg port = PortNum 51777 host <- inet_addr shost putStrLn "Making the server..." bindSocket s (SockAddrInet port host) b <- sIsBound s putStrLn "Socket bounded!" listen s 5 putStrLn "Listening OK" putStrLn "Waiting for clients..." (s', c) <- accept s putStrLn "Client found!" str <- recv s' 255 putStr "Message received:" putStr str (2) conv :: Word16 -> Word16 conv w16 = shiftL (fromIntegral a) 8 .|. fromIntegral b where a = fromIntegral w16 :: Word8 b = fromIntegral (shiftR w16 8) :: Word8 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 20 17:48:37 2008 From: trac at galois.com (GHC) Date: Thu Nov 20 17:42:41 2008 Subject: [GHC] #2795: The Network.Socket library does not take into account that the bits in the network are sent as big enddian. In-Reply-To: <044.6c385a1093d32284095f65013344ce56@localhost> References: <044.6c385a1093d32284095f65013344ce56@localhost> Message-ID: <053.f9292cbe43ed1715a05390774640d214@localhost> #2795: The Network.Socket library does not take into account that the bits in the network are sent as big enddian. -----------------------------------------------------------------------+---- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/network | Version: Severity: major | Resolution: Keywords: socket port number big-enddian little-enddian conflict | Testcase: Architecture: x86 | Os: Linux -----------------------------------------------------------------------+---- Comment (by felixmar): Hi Alejandro and Josef, This is not a bug, but the documentation for Network.Socket is lacking. !PortNumber is defined as {{{ newtype PortNumber = PortNum Word16 }}} The Word16 argument of !PortNum represents the internal port number of !PortNumber and is in network byte order. Because !PortNumber is an instance of Num you can define a !PortNumber value like this: {{{ let port = 51777 :: PortNumber }}} The value 51777 will then be automatically converted to it's internal representation depending on the little-endianness or big-endianness of the processor. Regards, Felix -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 20 22:20:35 2008 From: trac at galois.com (GHC) Date: Thu Nov 20 22:14:39 2008 Subject: [GHC] #2796: GHC panic related to associated types Message-ID: <045.982472b85d4648c742f947e5a9914557@localhost> #2796: GHC panic related to associated types -----------------------------------------------------------------------------------------+ Reporter: FSalad | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: associated types, associated type synonyms, type families, family, panic | Testcase: Architecture: Unknown/Multiple | Os: Linux -----------------------------------------------------------------------------------------+ Hello :) the attached program mysteriously fails with: >>> ghc --make Bug [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ghc: panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-unknown-linux): typePrimRep main:Bug.FDom{tc rfJ} f1{tv afZ} [tv] ~ main:Bug.FDom{tc rfJ} f2{tv ag0} [tv] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 21 03:37:58 2008 From: trac at galois.com (GHC) Date: Fri Nov 21 03:32:10 2008 Subject: [GHC] #2794: Bootstrapping ghc-6.4.3 hangs in call to "ghc-pkg-inplace" In-Reply-To: <045.51a34987f6c098b166e3866c58821344@localhost> References: <045.51a34987f6c098b166e3866c58821344@localhost> Message-ID: <054.7ad4c3b9123d1197adea4e863b9747d2@localhost> #2794: Bootstrapping ghc-6.4.3 hangs in call to "ghc-pkg-inplace" --------------------------+------------------------------------------------- Reporter: cspiel | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 6.4.3 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | --------------------------+------------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => wontfix Comment: Looks like you're running into old code gen bugs, perhaps coupled with some incompatibility with your gcc version. I think you're taking the right approach. Please continue the discussion on glasgow-haskell- users@haskell.org, and open a new ticket if you run into a bug which is likely to be still present or which we have a chance of reproducing. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 21 03:42:56 2008 From: trac at galois.com (GHC) Date: Fri Nov 21 03:36:58 2008 Subject: [GHC] #2063: x86_64: RTS linker depends on working MAP_32BIT In-Reply-To: <043.15abf9ca319b437728a2421245ad0407@localhost> References: <043.15abf9ca319b437728a2421245ad0407@localhost> Message-ID: <052.0bd1ceadc24a59a0b2bf67a23a8f02aa@localhost> #2063: x86_64: RTS linker depends on working MAP_32BIT ------------------------------+--------------------------------------------- Reporter: dons | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.2 Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: OpenBSD | Difficulty: Moderate (1 day) Testcase: | Architecture: x86_64 (amd64) Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by simonmar): * owner: => igloo * type: task => merge Comment: One more patch to merge: {{{ Thu Nov 20 15:40:14 GMT 2008 Simon Marlow * round the size up to a page in mmapForLinker() instead of in the caller }}} A Xen user reported on glasgow-haskell-users that this fixed the problem for them. If we get posititve feedback from a *BSD user then we can close this bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 21 04:27:54 2008 From: trac at galois.com (GHC) Date: Fri Nov 21 04:21:56 2008 Subject: [GHC] #2502: segfault with GHC.Handle.fdToHandle' In-Reply-To: <046.3af147e9b383729d4b3cbb7db169730e@localhost> References: <046.3af147e9b383729d4b3cbb7db169730e@localhost> Message-ID: <055.c15980632000e97d9f9744fc5afa3827@localhost> #2502: segfault with GHC.Handle.fdToHandle' ---------------------+------------------------------------------------------ Reporter: EricKow | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: None | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: FreeBSD | ---------------------+------------------------------------------------------ Comment (by thorkilnaur): With {{{ $ uname -a FreeBSD tn12.thorkilnaur.dk 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Fri Jan 12 10:40:27 UTC 2007 root@dessler.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.10.1 $ }}} I can do {{{ $ cat t1.hs import GHC.Handle ( fdToHandle' ) import IO ( IOMode(..) ) main = fdToHandle' 1 Nothing False "stdout" WriteMode True $ ghc -fforce-recomp --make t1.hs -threaded [1 of 1] Compiling Main ( t1.hs, t1.o ) Linking t1 ... $ ./t1 $ ghc -fforce-recomp --make t1.hs -threaded -optl-pthread [1 of 1] Compiling Main ( t1.hs, t1.o ) Linking t1 ... $ ./t1 Segmentation fault: 11 (core dumped) $ }}} Studying the {{{gcc}}} and {{{ld}}} command lines produced by {{{ghc}}} using {{{-v}}}, I find that {{{-optl-pthread}}} (as one would expect) adds {{{-pthread}}} to the {{{gcc}}} command for performing the link. This, in turn, causes {{{-lpthread}}} to be added to the {{{ld}}} command. Now, the {{{ld}}} command already has {{{-lthr}}} which prompted a search which uncovered http://planet.gentoo.org/developers/lavajoe/2007/09/17/spinning_my_tires_in_bug_mud. According to Joe Peterson in this reference, libthr is the newer FreeBSD threading library, replacing the older libpthread. And, again according to the quoted reference, at least in older FreeBSDs (like the 6.2 I am using here), mixing the two could lead to segmentation faults, in spite of libpthread being "mapped to libthr by libmap.conf". Summing all this up, I would say that this is a FreeBSD problem, not a GHC problem. And, of course, the work-around is not to use the {{{-optl- pthread}}} flag, which doesn't appear to be necessary in any case. So I suggest that we close this ticket. Best regards Thorkil -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 21 05:40:27 2008 From: trac at galois.com (GHC) Date: Fri Nov 21 05:34:33 2008 Subject: [GHC] #2796: GHC panic related to associated types In-Reply-To: <045.982472b85d4648c742f947e5a9914557@localhost> References: <045.982472b85d4648c742f947e5a9914557@localhost> Message-ID: <054.dd5dc896fa2b59d18588ffa58739bf11@localhost> #2796: GHC panic related to associated types --------------------------------------------------------------------------------------+ Reporter: FSalad | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: associated types, associated type synonyms, type families, family, panic | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Linux | --------------------------------------------------------------------------------------+ Changes (by simonpj): * owner: => chak * difficulty: => Unknown * milestone: => 6.10.2 Old description: > Hello :) > > the attached program mysteriously fails with: > > >>> ghc --make Bug > > [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) > ghc: panic! (the 'impossible' happened) > (GHC version 6.10.1 for i386-unknown-linux): > typePrimRep > main:Bug.FDom{tc rfJ} f1{tv afZ} [tv] > ~ > main:Bug.FDom{tc rfJ} f2{tv ag0} [tv] > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug New description: The attached program mysteriously fails with: {{{ >>> ghc --make Bug [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ghc: panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-unknown-linux): typePrimRep main:Bug.FDom{tc rfJ} f1{tv afZ} [tv] ~ main:Bug.FDom{tc rfJ} f2{tv ag0} [tv] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Comment: Thanks for the report. Assigning to Manuel. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 21 06:34:05 2008 From: trac at galois.com (GHC) Date: Fri Nov 21 06:28:06 2008 Subject: [GHC] #2063: x86_64: RTS linker depends on working MAP_32BIT In-Reply-To: <043.15abf9ca319b437728a2421245ad0407@localhost> References: <043.15abf9ca319b437728a2421245ad0407@localhost> Message-ID: <052.793a4d8f32d689c71f30bf71fd1a8f3f@localhost> #2063: x86_64: RTS linker depends on working MAP_32BIT ------------------------------+--------------------------------------------- Reporter: dons | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.2 Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: OpenBSD | Difficulty: Moderate (1 day) Testcase: | Architecture: x86_64 (amd64) Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by simonmar): And another patch to merge: {{{ Fri Nov 21 00:54:18 PST 2008 Simon Marlow * fix the build when !USE_MMAP }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 21 11:21:45 2008 From: trac at galois.com (GHC) Date: Fri Nov 21 11:15:45 2008 Subject: [GHC] #2797: ghci stack overflows when ghc does not Message-ID: <053.b5bed6c883dfb7d157e5092dcf2242ee@localhost> #2797: ghci stack overflows when ghc does not ---------------------------------+------------------------------------------ Reporter: TristanAllwood | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.11 | Severity: normal Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ Happens with today's HEAD and 6.10.1 I appreciate I am playing a little fast and loose by using unsafePerformIO. {{{ module Main where import System.IO.Unsafe main :: IO () main = do bar [] 5000000 `seq` return () bar :: [()] -> Int -> Int bar stk 0 = error $ show stk bar stk n = stk `seq` bar (push stk) (n-1) push :: [()] -> [()] push stk = unsafePerformIO . return $ take 2 (():stk) }}} {{{ $ ~/ghc/ghc/ghc/stage2-inplace/ghc -O0 --make -o GT2 ghciTest2.hs [1 of 1] Compiling Main ( ghciTest2.hs, ghciTest2.o ) Linking GT2.exe ... t-trallw@MSRC-1326435 ~/ghc/ghc-Stack-Tests $ ./GT2.exe +RTS -k0.01k -K0.01k GT2.exe: [(),()] t-trallw@MSRC-1326435 ~/ghc/ghc-Stack-Tests $ rm *.o *.exe *.hi ; ~/ghc/ghc/ghc/stage2-inplace/ghc -e 'main' ghciTest2.hs +RTS -K40M Stack space overflow: current size 40000000 bytes. Use `+RTS -Ksize' to increase it. }}} Using {{{-K400M}}} ghci does get there. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 21 11:36:10 2008 From: trac at galois.com (GHC) Date: Fri Nov 21 11:30:09 2008 Subject: [GHC] #2797: ghci stack overflows when ghc does not In-Reply-To: <053.b5bed6c883dfb7d157e5092dcf2242ee@localhost> References: <053.b5bed6c883dfb7d157e5092dcf2242ee@localhost> Message-ID: <062.f5a44fcf67065c4fa37bbfae931def67@localhost> #2797: ghci stack overflows when ghc does not ---------------------------------+------------------------------------------ Reporter: TristanAllwood | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.11 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ Comment (by TristanAllwood): Also may be of interest: Compiling with hpc doesn't change the executable behaviour. {{{ $ ~/ghc/ghc/ghc/stage2-inplace/ghc -fhpc -O0 --make -o GT2 ghciTest2.hs [1 of 1] Compiling Main ( ghciTest2.hs, ghciTest2.o ) Linking GT2.exe ... t-trallw@MSRC-1326435 ~/ghc/ghc-Stack-Tests $ ./GT2.exe +RTS -k0.01k -K0.01k GT2.exe: [(),()] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 21 11:41:40 2008 From: trac at galois.com (GHC) Date: Fri Nov 21 11:35:38 2008 Subject: [GHC] #2797: ghci stack overflows when ghc does not In-Reply-To: <053.b5bed6c883dfb7d157e5092dcf2242ee@localhost> References: <053.b5bed6c883dfb7d157e5092dcf2242ee@localhost> Message-ID: <062.5d4b2ecf5b614f4d984eaeba721d7118@localhost> #2797: ghci stack overflows when ghc does not ---------------------------------+------------------------------------------ Reporter: TristanAllwood | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.11 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ Comment (by TristanAllwood): The plot thickens. Interpreting with -fhpc is fine... {{{ $ rm *.o *.exe *.hi ; ~/ghc/ghc/ghc/stage2-inplace/ghc -fhpc -e 'main' ghciTest2.hs rm: cannot remove `*.o': No such file or directory rm: cannot remove `*.exe': No such file or directory rm: cannot remove `*.hi': No such file or directory : [(),()] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 21 12:02:05 2008 From: trac at galois.com (GHC) Date: Fri Nov 21 11:56:17 2008 Subject: [GHC] #2750: Bug in Data.Generics In-Reply-To: <044.cd214fdda0ee80175fd522907e79182f@localhost> References: <044.cd214fdda0ee80175fd522907e79182f@localhost> Message-ID: <053.66e2a563756ec12a5cce43bc1b92268e@localhost> #2750: Bug in Data.Generics ------------------------------+--------------------------------------------- Reporter: guest | Owner: jose magalhaes Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by simonpj): * owner: => jose magalhaes * difficulty: => Unknown * cc: jpm@cs.uu.nl (added) Comment: Jose Magalh?es is taking this. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 21 12:02:53 2008 From: trac at galois.com (GHC) Date: Fri Nov 21 11:57:01 2008 Subject: [GHC] #2759: Data.Generics.ConstrRep isn't general enough In-Reply-To: <044.ed7d09d66854fb1616fb1d1343b2d811@localhost> References: <044.ed7d09d66854fb1616fb1d1343b2d811@localhost> Message-ID: <053.5a44dcf3d2fa330ae04c656535e7c86a@localhost> #2759: Data.Generics.ConstrRep isn't general enough ------------------------------+--------------------------------------------- Reporter: guest | Owner: jose magalhaes Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by simonpj): * owner: => jose magalhaes * difficulty: => Unknown * cc: jpm@cs.uu.nl (added) Comment: Assigning to Jose. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 21 12:03:27 2008 From: trac at galois.com (GHC) Date: Fri Nov 21 11:57:35 2008 Subject: [GHC] #2760: Data.Generics.Basics.mkNoreptype spelled wrong In-Reply-To: <044.b3884d30a8391ab9f46e5542669e8ee1@localhost> References: <044.b3884d30a8391ab9f46e5542669e8ee1@localhost> Message-ID: <053.64fb8414e212de53673a2d05da7d4208@localhost> #2760: Data.Generics.Basics.mkNoreptype spelled wrong ------------------------------+--------------------------------------------- Reporter: guest | Owner: jose magalhaes Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by simonpj): * owner: => jose magalhaes * difficulty: => Unknown * cc: jpm@cs.uu.nl (added) Comment: Assigning to Jose. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 22 06:12:35 2008 From: trac at galois.com (GHC) Date: Sat Nov 22 06:06:34 2008 Subject: [GHC] #2740: free variable not available in debugger In-Reply-To: <046.05e1293bbffbc0807e6d01b8f2d22646@localhost> References: <046.05e1293bbffbc0807e6d01b8f2d22646@localhost> Message-ID: <055.e551f4435c10454cd4af8cc692b82cc7@localhost> #2740: free variable not available in debugger -------------------------+-------------------------------------------------- Reporter: phercek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: debugger | Testcase: Architecture: x86 | Os: Linux -------------------------+-------------------------------------------------- Changes (by mnislaih): * version: 6.8.2 => 6.10.1 * summary: free variable not available in debugger, field selection function not available in debugger => free variable not available in debugger Comment: Hi, thanks a lot for the report. The second error message is surely a bug: a free variable is not made available. On the other hand the first one looks like a legit error: the selector is not in the export list of the module, therefore it is not available. Or should it be? I tested with 6.10 and the behavior is the same. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 22 06:12:43 2008 From: trac at galois.com (GHC) Date: Sat Nov 22 06:06:44 2008 Subject: [GHC] #2740: free variable not available in debugger In-Reply-To: <046.05e1293bbffbc0807e6d01b8f2d22646@localhost> References: <046.05e1293bbffbc0807e6d01b8f2d22646@localhost> Message-ID: <055.a78f2cfc15be311be90500d1418e7483@localhost> #2740: free variable not available in debugger -------------------------+-------------------------------------------------- Reporter: phercek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: debugger | Testcase: Architecture: x86 | Os: Linux -------------------------+-------------------------------------------------- Changes (by mnislaih): * cc: mnislaih@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From mechvel at botik.ru Sat Nov 22 06:29:39 2008 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Sat Nov 22 06:23:46 2008 Subject: mapRecordField Message-ID: <20081122112939.GA25866@scico.botik.ru> People, ghc-6.10.1 says it provides a `sugar' syntax for records: wild-card patterns, punning, and field disambiguation. For example, I write fam {opAttrs = cp $ opAttrs fam} to map the function cp to the field opAttrs in the record fam. The best expression for this could be mapField opAttrs cp fam, with an intended library function mapField -- which does not agree with Haskell types. But as GHC takes care to provide a language extension for records, maybe it could introduce mapField as the language construct and as a reserved word? Also I do not know, maybe, something like fam {opAttrs = cp opAttrs} is possible now? Thank you in advance for your explanation, ----------------- Serge Mechveliani mechvel@botik.ru From trac at galois.com Sat Nov 22 09:21:17 2008 From: trac at galois.com (GHC) Date: Sat Nov 22 09:15:13 2008 Subject: [GHC] #2798: Enable "rec" keyword when RecursiveDo is enabled? Message-ID: <047.c01de827ffb9a59aafb72de68ac54369@localhost> #2798: Enable "rec" keyword when RecursiveDo is enabled? ---------------------------------+------------------------------------------ Reporter: nominolo | Owner: Type: task | Status: new Priority: normal | Component: Compiler Version: 6.11 | Severity: minor Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ GHC supports recursive statement groups marked by the keyword {{{rec}}}, however this is only activated via a hack. Consider this (silly) example program: {{{ {-# LANGUAGE RecursiveDo, Arrows #-} main :: IO () main = mdo x <- return (length [1..42::Int]) rec b <- return x let a = const c c <- print "x" return (a b) }}} The {{{Arrow}}} language needs to be enabled, otherwise the {{{rec}}} keyword wouldn't be recognised. Currently this behaviour is undocumented, and {{{rec}}} groups only appear in the internal AST. This ticket has been created to have a documented decsion whether this feature is supported or not. Given that GHC automatically identifies strongly-connected components and re-groups things (although it cannot re- order statements due to probable dependencies) having an explicet {{{rec}}} keyword probably isn't that useful. In particular {{{ mdo foo ...is equivalent to... mdo rec foo bar bar baz baz }}} Thoughts? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 22 10:01:57 2008 From: trac at galois.com (GHC) Date: Sat Nov 22 09:55:55 2008 Subject: [GHC] #2740: free variable not available in debugger In-Reply-To: <046.05e1293bbffbc0807e6d01b8f2d22646@localhost> References: <046.05e1293bbffbc0807e6d01b8f2d22646@localhost> Message-ID: <055.129576f4b3de46bb81cda9767c340a02@localhost> #2740: free variable not available in debugger -------------------------+-------------------------------------------------- Reporter: phercek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: debugger | Testcase: Architecture: x86 | Os: Linux -------------------------+-------------------------------------------------- Comment (by phercek): Hi, Simon Marlow indicated that the unavailable selector function could be a bug too here: http://www.haskell.org/pipermail/glasgow-haskell- users/2008-November/015879.html My opinion is that it is a bug, i.e. functions which are not exported from a module should be available when debugging inside the module where they are defined (but they should not be available when debugging some other modules). In other words (from a debugger user perspective), all identifiers which are in scope at a break point location should be available in debugger for use. Of course I see now that there are technicall reasons why non-free variable identifiers (which are in scope) are not available. In such a case some workarounds may be done to improve the pain (http://hackage.haskell.org/trac/ghc/ticket/2737). But do the same technical reasons apply also to function names too? I hope not. Maybe the "field selection function not available in debugger" part of this bug report is a new feature request instead of a bug? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 22 10:13:16 2008 From: trac at galois.com (GHC) Date: Sat Nov 22 10:07:11 2008 Subject: [GHC] #2798: Enable "rec" keyword when RecursiveDo is enabled? In-Reply-To: <047.c01de827ffb9a59aafb72de68ac54369@localhost> References: <047.c01de827ffb9a59aafb72de68ac54369@localhost> Message-ID: <056.c9ab7df18d65989239eccb781324f5fc@localhost> #2798: Enable "rec" keyword when RecursiveDo is enabled? ---------------------------------+------------------------------------------ Reporter: nominolo | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: minor | Resolution: Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ Comment (by ross): The idea of "rec" was to use it with plain "do", to indicate feedback explicitly as an alternative to using "mdo". Many users of arrow notation prefer to do that. As you say, it's not much use together with "mdo". -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 22 10:49:19 2008 From: trac at galois.com (GHC) Date: Sat Nov 22 10:43:15 2008 Subject: [GHC] #2740: free variable not available in debugger In-Reply-To: <046.05e1293bbffbc0807e6d01b8f2d22646@localhost> References: <046.05e1293bbffbc0807e6d01b8f2d22646@localhost> Message-ID: <055.96fda635878e2f516096e1e2d99e6786@localhost> #2740: free variable not available in debugger -------------------------+-------------------------------------------------- Reporter: phercek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: debugger | Testcase: Architecture: x86 | Os: Linux -------------------------+-------------------------------------------------- Comment (by mnislaih): It would be a feature request, but ghci already provides this feature. {{{ *Main> :m + *BL.Test }}} will bring the full top level of BL.Test into scope, regardless of what the export list says. I'm not sure if 6.8.x had this feature already. But probably what you want is this done automatically when stopped in a breakpoint, right ? In that case, please open a feature request ticket and make sure to put me in the CC. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 22 12:46:48 2008 From: trac at galois.com (GHC) Date: Sat Nov 22 12:40:45 2008 Subject: [GHC] #2799: Panic (core lint failure) with GADTs, GHC 6.10.1 Message-ID: <047.02178742ef8c8010079728a64ae52ee1@localhost> #2799: Panic (core lint failure) with GADTs, GHC 6.10.1 -------------------------+-------------------------------------------------- Reporter: alexey_r | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: major Keywords: | Testcase: Architecture: x86 | Os: Windows -------------------------+-------------------------------------------------- The compiler panic when trying to compile [http://www.seas.upenn.edu/~sweirich/RepLib/ RepLib 0.2]. A stripped-down example: {{{ {-# OPTIONS -fglasgow-exts -XUndecidableInstances #-} module RepAux ( toSpineRl ) where data R a = R data Nil = Nil data a :*: l = a :*: l data MTup r l where MNil :: MTup ctx Nil (:+:) :: r a -> MTup r l -> MTup r (a :*: l) data Typed a = a ::: R a data Spine a where (:<>) :: Spine (a -> b) -> Typed a -> Spine b toSpineRl :: MTup R l -> l -> (l -> a) -> Spine a toSpineRl MNil Nil into = undefined toSpineRl (ra :+: rs) (a :*: l) into = (toSpineRl rs l into') :<> (a ::: ra) where into' tl1 x1 = into (x1 :*: tl1) }}} Compiler panic: {{{ F:\Programming\Libraries\Haskell\replib-bug>ghc --make RepAux [1 of 1] Compiling RepAux ( RepAux.hs, RepAux.o ) ghc: panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-unknown-mingw32): initC: srt_lbl Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} With -v: {{{ F:\Programming\Libraries\Haskell\replib-bug>ghc --make RepAux -v Glasgow Haskell Compiler, Version 6.10.1, for Haskell 98, stage 2 booted by GHC version 6.8.3 Using package config file: F:\proglangs\ghc\ghc-6.10.1\package.conf hiding package base-3.0.3.0 to avoid conflict with later version base-4.0.0.0 hiding package regex-base-0.72.0.2 to avoid conflict with later version regex-ba se-0.93.1 hiding package parsec-2.1.0.1 to avoid conflict with later version parsec-3.0.0 hiding package QuickCheck-1.2.0.0 to avoid conflict with later version QuickChec k-2.1 hiding package QuickCheck-2.1 to avoid conflict with later version QuickCheck-2. 1.0.1 hiding package rmonad-0.2 to avoid conflict with later version rmonad-0.3 hiding package TypeCompose-0.5.1 to avoid conflict with later version TypeCompos e-0.6.0 hiding package reactive-0.9.0 to avoid conflict with later version reactive-0.9. 1 wired-in package ghc-prim mapped to ghc-prim-0.1.0.0 wired-in package integer mapped to integer-0.1.0.0 wired-in package base mapped to base-4.0.0.0 wired-in package rts mapped to rts-1.0 wired-in package haskell98 mapped to haskell98-1.0.1.0 wired-in package syb mapped to syb-0.1.0.0 wired-in package template-haskell mapped to template-haskell-2.3.0.0 wired-in package dph-seq mapped to dph-seq-0.3 wired-in package dph-par mapped to dph-par-0.3 Hsc static flags: -static *** Chasing dependencies: Chasing modules from: *RepAux.hs Stable obj: [] Stable BCO: [] Ready for upsweep [NONREC ModSummary { ms_hs_date = Sat Nov 22 20:43:55 Russian Standard Time 2008 ms_mod = main:RepAux, ms_imps = [] ms_srcimps = [] }] compile: input file RepAux.hs Created temporary directory: C:\Users\Alexey\AppData\Local\Temp\/ghc12212_0 *** Checking old interface for main:RepAux: [1 of 1] Compiling RepAux ( RepAux.hs, RepAux.o ) *** Parser: *** Renamer/typechecker: *** Desugar: Result size = 74 *** Simplify: Result size = 65 Result size = 65 *** Tidy Core: Result size = 65 *** CorePrep: Result size = 119 *** Stg2Stg: *** CodeGen: *** CodeOutput: *** Deleting temp files: Deleting: C:\Users\Alexey\AppData\Local\Temp\/ghc12212_0/ghc12212_0.s Warning: exception raised when deleting C:\Users\Alexey\AppData\Local\Temp\/ghc1 2212_0/ghc12212_0.s: DeleteFile: permission denied (The process cannot access the file because it is being used by another process.) *** Deleting temp dirs: Deleting: C:\Users\Alexey\AppData\Local\Temp\/ghc12212_0 Warning: exception raised when deleting C:\Users\Alexey\AppData\Local\Temp\/ghc1 2212_0: RemoveDirectory: unsatisified constraints (The directory is not empty.) ghc: panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-unknown-mingw32): initC: srt_lbl Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} With -dcore-lint: {{{ F:\Programming\Libraries\Haskell\replib-bug>ghc --make RepAux -dcore-lint [1 of 1] Compiling RepAux ( RepAux.hs, RepAux.o ) *** Core Lint Errors: in result of Desugar *** {-# LINE 24 "RepAux.hs #-}: [RHS of into'_ahT :: l_ahu -> a_aht -> a_ahe] into'_agp is out of scope *** Offending Program *** Rec { RepAux.toSpineRl :: forall l_ag8 a_ag9. RepAux.MTup RepAux.R l_ag8 -> l_ag8 -> (l_ag8 -> a_ag9) -> RepAux.Spine a_ag9 [Exported] [] RepAux.toSpineRl = \ (@ l_ahd) (@ a_ahe) -> let { toSpineRl_ahf :: RepAux.MTup RepAux.R l_ahd -> l_ahd -> (l_ahd -> a_ahe) -> RepAux.Spine a_ahe [] toSpineRl_ahf = RepAux.toSpineRl @ l_ahd @ a_ahe } in \ (ds_dia :: RepAux.MTup RepAux.R l_ahd) (ds_dib :: l_ahd) (into_agc :: l_ahd -> a_ahe) -> case ds_dia of wild_B1 { RepAux.MNil @ $co$_ahn -> letrec { } in let { ds_did :: RepAux.Nil [] ds_did = ds_dib `cast` (sym (trans (trans RepAux.Nil (sym (trans $co$_ahn (sym RepAux.Ni l)))) l_ahd) :: l_ahd ~ RepAux.Nil) } in case ds_did of wild_B1 { RepAux.Nil -> letrec { } in GHC.Err.undefined @ (RepAux.Spine a_ahe) }; RepAux.:+: @ a_aht @ l_ahu @ $co$_ahU ra_agf rs_agh -> letrec { into'_ahT :: l_ahu -> a_aht -> a_ahe [] into'_ahT = into'_agp @ a_aht @ l_ahu @ (trans (trans (a_aht RepAux.:*: l_ahu) (sym (trans $co$_ahU (sym (a_aht RepAux.:*: l_ahu))))) l_ahd); } in let { ds_dic :: a_aht RepAux.:*: l_ahu [] ds_dic = ds_dib `cast` (sym (trans (trans (a_aht RepAux.:*: l_ahu) (sym (trans $co$_ahU (sym (a_aht RepAux.:*: l_ahu) )))) l_ahd) :: l_ahd ~ a_aht RepAux.:*: l_ahu) } in case ds_dic of wild_B1 { RepAux.:*: a_agj l_agl -> letrec { } in let { into_agn :: l_ahd -> a_ahe [] into_agn = into_agc } in letrec { into'_agp :: forall a_ahH l_ahI. (a_ahH RepAux.:*: l_ahI ~ l_ahd) => l_ahI -> a_ahH -> a_ahe [] into'_agp = \ (@ a_ahH) (@ l_ahI) (@ co_ahK) -> letrec { into'_ahM :: l_ahI -> a_ahH -> a_ahe [] into'_ahM = \ (tl1_ags :: l_ahI) (x1_agu :: a_ahH) -> into_agn ((\ (sub_ai7 :: a_ahH) (sub_ai8 :: l_ahI) -> (RepAux.:*: @ a_ahH @ l_ahI sub_ai7 sub_ai8) `cast` (trans (trans (a_ahH RepAux.:*: l_ahI) (sym (sym co_ahK))) l_ahd :: a_ahH RepAux.:*: l_ahI ~ l_ahd)) x1_agu tl1_ags); } in into'_ahM; } in RepAux.:<> @ a_ahe @ a_aht (RepAux.toSpineRl @ l_ahu @ (a_aht -> a_ahe) rs_agh l_agl into'_ahT) (RepAux.::: @ a_aht a_agj ra_agf) } } end Rec } *** End of Offense *** : Compilation had errors }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 22 16:22:15 2008 From: trac at galois.com (GHC) Date: Sat Nov 22 16:16:10 2008 Subject: [GHC] #2800: deprecated OPTIONS flag warnings generated during dep chasing? Message-ID: <045.0e85c856f9a219b317597d25eed9584a@localhost> #2800: deprecated OPTIONS flag warnings generated during dep chasing? ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ It would appear that warnings about deprecated flags used in `OPTIONS` pragmas get spat out during the early pre-processing and module chasing phase when they would not be generated after pre-processing. `ghc --make` has to scan each module to look for options and language extensions to know if it has to run cpp. At this stage it cannot of course run cpp so it does not necessarily get the full set of options and extensions since some may be conditional. So it should not at this stage generate any warnings since they may be suppressed by later cpp- conditional flags. Another possible theory is that it generates the warnings before having read all the `OPTIONS` flags so the later warning suppression is ineffective. Unfortunately we have to put them in the order we do for compatibility with older versions of ghc. Here's an example out of Cabal: {{{ {-# OPTIONS -cpp -fffi #-} -- OPTIONS required for ghc-6.4.x, and must appear first {-# LANGUAGE CPP, ForeignFunctionInterface #-} {-# OPTIONS_GHC -cpp -fffi #-} {-# OPTIONS_NHC98 -cpp #-} {-# OPTIONS_JHC -fcpp -fffi #-} #if __GLASGOW_HASKELL__ >= 610 {-# OPTIONS_GHC -fno-warn-deprecated-flags #-} -- the ghc flag -fffi is deprecated in ghc-6.10. We're -- supposed to use the LANGUAGE pragmas instead. However -- we have to maintain compatibility with older ghc versions -- so we (try to) suppress this warning. #endif }}} What we're trying to do here is make it work with ghc-6.4 + and not generate any warnings with the latest ghc. This seems quite tricky to do. To support ghc-6.4 we have to put the `OPTIONS` pragma first, since it apparently only looks at the first couple lines. We then use the compiler- specific `OPTIONS` pragmas. In particular these are needed for ghc-6.6. For ghc-6.8 and later we can use the `LANGUAGE` pragmas. In ghc-6.10 the `-fffi` option is deprecated. However we cannot conditionally compile the `OPTIONS -cpp -fffi` since ghc needs to see the `-cpp` to know that it has to cpp the module. Making the `OPTIONS -cpp` unconditional and the `OPTIONS -cpp -fffi` conditional does not work with ghc-6.4. So instead we try suppressing the warning. We cannot do that unconditionally since the flag is only present in newer ghc versions. However if we do suppress conditionally then ghc still warns anyway, presumably because it is warning on the first pass rather than in the pass after running cpp. All in all it's a bit tricky to do right. Indeed I cannot currently see a way to make it work at all without generating warnings. The sledgehammer would be to put a flag in the .cabal file and have it apply to all modules, however that does not prevent the warning happening during Cabal bootstrapping which uses plain `ghc --make`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 22 23:12:41 2008 From: trac at galois.com (GHC) Date: Sat Nov 22 23:06:36 2008 Subject: [GHC] #2801: Hang in getLine on Windows when Ctrl-C Message-ID: <053.cf8db06d79e114b571377a346a2aae7a@localhost> #2801: Hang in getLine on Windows when Ctrl-C -------------------------------+-------------------------------------------- Reporter: erikcharlebois | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Windows -------------------------------+-------------------------------------------- The following program main = getLine hangs when I ctrl-C in the Windows command prompt. The only way to recover after that is to kill the process in Task Manager. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 23 02:25:15 2008 From: trac at galois.com (GHC) Date: Sun Nov 23 02:19:10 2008 Subject: [GHC] #2802: Download bundle for Linux libedit2 has reference to libedit0 in editline lib Message-ID: <053.d54bc1052404d450eba42b9c4b28a824@localhost> #2802: Download bundle for Linux libedit2 has reference to libedit0 in editline lib -------------------------------+-------------------------------------------- Reporter: Ashley Yakeley | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.10.1 | Severity: normal Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Linux -------------------------------+-------------------------------------------- To reproduce: 1. Download GHC 6.10.1 binary bundle for Linux x86_64 with libedit2. Link is http://www.haskell.org/ghc/dist/6.10.1/ghc-6.10.1-x86_64-unknown- linux-libedit2.tar.bz2 2. Install 3. do "ghc-pkg describe editline" Results: "extra-libraries: edit ncurses" Expected "extra-libraries: edit2 ncurses" 4. do "cabal install haddock" Results: "/usr/bin/ld: cannot find -ledit" Expected: success -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 23 02:28:09 2008 From: trac at galois.com (GHC) Date: Sun Nov 23 02:22:03 2008 Subject: [GHC] #2802: Download bundle for Linux libedit2 has reference to libedit0 in editline lib In-Reply-To: <053.d54bc1052404d450eba42b9c4b28a824@localhost> References: <053.d54bc1052404d450eba42b9c4b28a824@localhost> Message-ID: <062.963a87835c54f6afc2d38953112195be@localhost> #2802: Download bundle for Linux libedit2 has reference to libedit0 in editline lib -------------------------------+-------------------------------------------- Reporter: Ashley Yakeley | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Linux -------------------------------+-------------------------------------------- Comment (by Ashley Yakeley): To reproduce: 1. Download GHC 6.10.1 binary bundle for Linux x86_64 with libedit2.[[BR]] Link is http://www.haskell.org/ghc/dist/6.10.1/ghc-6.10.1-x86_64-unknown- linux-libedit2.tar.bz2[[BR]] 2. Install[[BR]] 3. do "ghc-pkg describe editline"[[BR]] Results: "extra-libraries: edit ncurses"[[BR]] Expected "extra-libraries: edit2 ncurses"[[BR]] 4. do "cabal install haddock"[[BR]] Results: "/usr/bin/ld: cannot find -ledit"[[BR]] Expected: success -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 23 04:25:56 2008 From: trac at galois.com (GHC) Date: Sun Nov 23 04:19:50 2008 Subject: [GHC] #2802: Download bundle for Linux libedit2 has reference to libedit0 in editline lib In-Reply-To: <053.d54bc1052404d450eba42b9c4b28a824@localhost> References: <053.d54bc1052404d450eba42b9c4b28a824@localhost> Message-ID: <062.70d7896d68ff74bc3d255540e7286f35@localhost> #2802: Download bundle for Linux libedit2 has reference to libedit0 in editline lib -------------------------------+-------------------------------------------- Reporter: Ashley Yakeley | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Linux -------------------------------+-------------------------------------------- Comment (by duncan): That is not the cause of not being able to find `-ledit`. The shared lib name is the same for `libedit.so.0` and `libedit.so.2`. Check that you have one of these two files installed in `/usr/lib` or some other dir that's on the linker path. It's slightly odd though as if ld cannot find it, it makes one wonder how come ghc runs, given that it also links to libedit. Perhaps check the output of ldd on the ghc binary (not the shell script) to see exactly where it is finding the `libedit.so.*`. eg: {{{ ldd /usr/local/lib/ghc-6.10.1/ghc-6.10.1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 23 04:53:49 2008 From: trac at galois.com (GHC) Date: Sun Nov 23 04:47:43 2008 Subject: [GHC] #2802: Download bundle for Linux libedit2 has reference to libedit0 in editline lib In-Reply-To: <053.d54bc1052404d450eba42b9c4b28a824@localhost> References: <053.d54bc1052404d450eba42b9c4b28a824@localhost> Message-ID: <062.72d57dc3838bb602558335ec3470c4f8@localhost> #2802: Download bundle for Linux libedit2 has reference to libedit0 in editline lib -------------------------------+-------------------------------------------- Reporter: Ashley Yakeley | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Linux -------------------------------+-------------------------------------------- Comment (by Ashley Yakeley): Duh, you're right. It looks like the problem is that I don't have the /usr/lib/libedit.so symlink. I only have libedit.so.2 and libedit.so.2.11. I fixed this with "sudo aptitude install libedit-dev" (on Ubuntu 8.10). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 23 06:20:33 2008 From: trac at galois.com (GHC) Date: Sun Nov 23 06:14:27 2008 Subject: [GHC] #2802: Download bundle for Linux libedit2 has reference to libedit0 in editline lib In-Reply-To: <053.d54bc1052404d450eba42b9c4b28a824@localhost> References: <053.d54bc1052404d450eba42b9c4b28a824@localhost> Message-ID: <062.dea773a36d58367cee63cff30e261c53@localhost> #2802: Download bundle for Linux libedit2 has reference to libedit0 in editline lib -------------------------------+-------------------------------------------- Reporter: Ashley Yakeley | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Linux -------------------------------+-------------------------------------------- Comment (by duncan): Perhaps configure should check for this. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 23 08:59:47 2008 From: trac at galois.com (GHC) Date: Sun Nov 23 08:53:45 2008 Subject: [GHC] #1074: -fwarn-unused-imports complains about wrong import In-Reply-To: <044.4c9395b3e6188ac7c118df9e58cf802d@localhost> References: <044.4c9395b3e6188ac7c118df9e58cf802d@localhost> Message-ID: <053.e7ffb6f580a7aee4a2e63e8287588c7a@localhost> #1074: -fwarn-unused-imports complains about wrong import ------------------------------+--------------------------------------------- Reporter: guest | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.6 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * owner: => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 23 13:57:18 2008 From: trac at galois.com (GHC) Date: Sun Nov 23 13:51:11 2008 Subject: [GHC] #2803: bring full top level of a module in scope when a breakpoint is hit in the module Message-ID: <046.652e8c43925e61f6025ee776347b88e6@localhost> #2803: bring full top level of a module in scope when a breakpoint is hit in the module ---------------------------------+------------------------------------------ Reporter: phercek | Owner: Type: feature request | Status: new Priority: normal | Component: GHCi Version: 6.8.3 | Severity: normal Keywords: debugger | Testcase: Architecture: Unknown/Multiple | Os: Linux ---------------------------------+------------------------------------------ It should do something like {{{:module + *ModuleWhereBreakpointWasHit}}} and remove the added top level symbols of {{{ModuleWhereBreakpointWasHit}}} when we leave it. The goal is so that the functions which are in scope when we hit a breakpoint are readily available for investigations of the values stored in the free variables of the selected expression. This feature request is a consequence of the dicsussion in this ticket http://hackage.haskell.org/trac/ghc/ticket/2740#comment:4 ... and a realated thing: When I do something like {{{:module + ModName}}} and later I do {{{:module + *ModName}}} then the non-exported symbols from {{{ModName}}} are not added into the scope. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 23 14:17:37 2008 From: trac at galois.com (GHC) Date: Sun Nov 23 14:11:32 2008 Subject: [GHC] #2804: Failing GHCi: "ghc-6.8.2: internal error" Message-ID: <056.ec78b7e0bee86aec61dd34ed6f6eeb35@localhost> #2804: Failing GHCi: "ghc-6.8.2: internal error" ----------------------------------+----------------------------------------- Reporter: sfvisser@cs.uu.nl | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.8.2 | Severity: blocker Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Linux ----------------------------------+----------------------------------------- After installing ghc-6.8.2 on Gentoo linux using emerge: ---------------------------------------------------------------- $ ghci GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help ghc-6.8.2: internal error: R_X86_64_32S relocation out of range: (noname) = 0x7f421a1e5490 (GHC version 6.8.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug ---------------------------------------------------------------- $ uname -a Linux 2.6.24-19-xen #1 SMP Sat Jul 12 00:15:59 UTC 2008 x86_64 Dual-Core AMD Opteron(tm) Processor 2212 AuthenticAMD GNU/Linux (the same thing happens when I try to install ghc-6.10.1 from source) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 23 14:21:38 2008 From: trac at galois.com (GHC) Date: Sun Nov 23 14:15:31 2008 Subject: [GHC] #2799: Panic (core lint failure) with GADTs, GHC 6.10.1 In-Reply-To: <047.02178742ef8c8010079728a64ae52ee1@localhost> References: <047.02178742ef8c8010079728a64ae52ee1@localhost> Message-ID: <056.3c1a3afc8942cfbcda2f2f7fbf879d88@localhost> #2799: Panic (core lint failure) with GADTs, GHC 6.10.1 -------------------------+-------------------------------------------------- Reporter: alexey_r | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: major | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Windows -------------------------+-------------------------------------------------- Comment (by BenMoseley): Wonder if this is the same: http://hackage.haskell.org/trac/ghc/ticket/2787 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 23 14:22:35 2008 From: trac at galois.com (GHC) Date: Sun Nov 23 14:16:35 2008 Subject: [GHC] #2787: Panic (core lint failure) with type synonym in GHC 6.10.1 In-Reply-To: <049.16b406b9b4b75d10bbd6f184f46c2987@localhost> References: <049.16b406b9b4b75d10bbd6f184f46c2987@localhost> Message-ID: <058.ff5792b063856f4a92a6e6480d8bd313@localhost> #2787: Panic (core lint failure) with type synonym in GHC 6.10.1 ----------------------------------------+----------------------------------- Reporter: BenMoseley | Owner: chak Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.10.1 Severity: major | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Unknown/Multiple ----------------------------------------+----------------------------------- Changes (by BenMoseley): * cc: ben@moseley.name (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 23 14:39:00 2008 From: trac at galois.com (GHC) Date: Sun Nov 23 14:32:52 2008 Subject: [GHC] #2799: Panic (core lint failure) with GADTs, GHC 6.10.1 In-Reply-To: <047.02178742ef8c8010079728a64ae52ee1@localhost> References: <047.02178742ef8c8010079728a64ae52ee1@localhost> Message-ID: <056.1c50efb91a8e76e0e6f4137c25aa73a8@localhost> #2799: Panic (core lint failure) with GADTs, GHC 6.10.1 -------------------------+-------------------------------------------------- Reporter: alexey_r | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: major | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Windows -------------------------+-------------------------------------------------- Comment (by alexey_r): It looks quite likely, but I am not sure (no type synonyms involved, for one). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 23 21:18:34 2008 From: trac at galois.com (GHC) Date: Sun Nov 23 21:12:30 2008 Subject: [GHC] #2799: Panic (core lint failure) with GADTs, GHC 6.10.1 In-Reply-To: <047.02178742ef8c8010079728a64ae52ee1@localhost> References: <047.02178742ef8c8010079728a64ae52ee1@localhost> Message-ID: <056.cb21af7ae930c54116002bcebff7a11e@localhost> #2799: Panic (core lint failure) with GADTs, GHC 6.10.1 -------------------------+-------------------------------------------------- Reporter: alexey_r | Owner: chak Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: major | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Windows -------------------------+-------------------------------------------------- Changes (by chak): * owner: => chak Comment: Seems rather likely that it is a duplicate of #2787 (GADTs and type families use the inference engine). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 24 03:31:06 2008 From: trac at galois.com (GHC) Date: Mon Nov 24 03:24:58 2008 Subject: [GHC] #2798: Enable "rec" keyword when RecursiveDo is enabled? In-Reply-To: <047.c01de827ffb9a59aafb72de68ac54369@localhost> References: <047.c01de827ffb9a59aafb72de68ac54369@localhost> Message-ID: <056.a76ec4b50896b957416eb34ab95a0758@localhost> #2798: Enable "rec" keyword when RecursiveDo is enabled? ------------------------------+--------------------------------------------- Reporter: nominolo | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by simonpj): * difficulty: => Unknown Comment: I think the reason for 'mdo' was by analogy with 'let' and 'where': just say "use recursion" and let the compiler sort out the details. I have forgotten whether the same choice could be made for arrows, or whether 'rec' is essential there. I don't feel strongly about this. I suppose we could do any of these: * Remove 'rec' altogether (including from arrows i.e. 'proc') * Remove 'mdo' and use 'do rec' instead * Allow 'rec' in 'do' as well as in 'proc' * Status quo ('rec' in 'proc' but not in 'do') Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 24 04:57:07 2008 From: trac at galois.com (GHC) Date: Mon Nov 24 04:50:58 2008 Subject: [GHC] #2805: Test ffi009(ghci) fails on PPC Mac OS X Message-ID: <050.49e5533b97232a9f431fe6cab3b29ebd@localhost> #2805: Test ffi009(ghci) fails on PPC Mac OS X ----------------------------+----------------------------------------------- Reporter: thorkilnaur | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.11 | Severity: normal Keywords: | Testcase: ffi009(ghci) Architecture: powerpc | Os: MacOS X ----------------------------+----------------------------------------------- The test ffi009(ghci) has failed for a while on PPC Msc OS X (http://darcs.haskell.org/buildbot/all/builders/tnaur%20PPC%20OSX%20head%202/builds/156/steps/runtestsuite/logs/unexpected): {{{ =====> ffi009(ghci) cd ./ffi/should_run && '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/buildbot/ghc/tnaur-ppc-osx-2 /tnaur-ppc-osx-head-2/build/ghc/stage2-inplace/ghc' -fforce-recomp -dcore- lint -dcmm-lint -Dpowerpc_apple_darwin -dno-debug-output ffi009.hs --interactive -v0 -ignore-dot-ghci -fglasgow-exts ffi009.interp.stdout 2>ffi009.interp.stderr /bin/sh: line 1: 98633 Illegal instruction '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/buildbot/ghc/tnaur-ppc-osx-2 /tnaur-ppc-osx-head-2/build/ghc/stage2-inplace/ghc' -fforce-recomp -dcore- lint -dcmm-lint -Dpowerpc_apple_darwin -dno-debug-output ffi009.hs --interactive -v0 -ignore-dot-ghci -fglasgow-exts < ffi009.genscript > ffi009.interp.stdout 2> ffi009.interp.stderr Wrong exit code (expected 0 , actual 132 ) Stdout: Testing 5 Int arguments... True True True True True True True True True True Testing 11 Double arguments... Stderr: *** unexpected failure for ffi009(ghci) }}} An extract from the so-called crash report indicates a jump into the wild: {{{ Exception Type: EXC_BAD_INSTRUCTION (SIGILL) Exception Codes: 0x0000000000000002, 0x00000000027ffd04 Crashed Thread: 2 ... Thread 2 Crashed: 0 ??? 0x027ffd04 0 + 41942276 1 ghc 0x012da320 setThreadLocalVar + 16 2 ghc 0x012fa87c ffi_call_DARWIN + 204 (darwin.S:131) 3 ghc 0x012fa3a0 ffi_call + 208 (ffi_darwin.c:457) 4 ghc 0x012cacb8 interpretBCO + 4984 5 ghc 0x012d46d0 schedule + 1024 6 ghc 0x012d4d84 workerStart + 84 7 libSystem.B.dylib 0x9292f658 _pthread_start + 316 }}} When the test is run with a ghc built with {{{GhcDebugged=YES}}} (see http://hackage.haskell.org/trac/ghc/wiki/Building/Hacking and {{{mk/config.mk}}}), an assertion failure is reported instead: {{{ =====> ffi009(ghci) cd . && '/Users/thorkilnaur/tn/GHCDarcsRepository/ghc-HEAD-complete-for- pulling-and-copying-20070713_1212/ghc/ghc/stage2-inplace/ghc' -fforce- recomp -dcore-lint -dcmm-lint -Dpowerpc_apple_darwin -dno-debug-output ffi009.hs --interactive -v0 -ignore-dot-ghci -fglasgow-exts ffi009.interp.stdout 2>ffi009.interp.stderr /bin/sh: line 1: 43988 Abort trap '/Users/thorkilnaur/tn/GHCDarcsRepository/ghc-HEAD-complete-for-pulling- and-copying-20070713_1212/ghc/ghc/stage2-inplace/ghc' -fforce-recomp -dcore-lint -dcmm-lint -Dpowerpc_apple_darwin -dno-debug-output ffi009.hs --interactive -v0 -ignore-dot-ghci -fglasgow-exts < ffi009.genscript > ffi009.interp.stdout 2> ffi009.interp.stderr Wrong exit code (expected 0 , actual 134 ) Stdout: Stderr: ffi009: internal error: ASSERTION FAILED: file Linker.c, line 4380 (GHC version 6.11.20081121 for powerpc_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for ffi009(ghci) }}} The assertion failure is reported from this context in {{{Linker.c}}}: {{{ if(reloc->r_pcrel) { #ifdef powerpc_HOST_ARCH // In the .o file, this should be a relative jump to NULL // and we'll change it to a relative jump to the symbol ASSERT(word + reloc->r_address == 0); jumpIsland = (unsigned long) &makeSymbolExtra(oc, reloc->r_symbolnum, (unsigned long) symbolAddress) -> jumpIsland; if(jumpIsland != 0) { offsetToJumpIsland = word + jumpIsland - (((long)image) + sect->offset - sect->addr); } #endif word += (unsigned long) symbolAddress - (((long)image) + sect->offset - sect->addr); } }}} The relocations leading to the assertion failure are required by branch instructions generated by {{{gcc}}} for {{{ffi009_stub.c}}} that contains expressions of the form {{{symbol+constant}}} (where {{{symbol}}} is an external symbol) whose distance to the instruction needs to be packed into a 24-bit field. An example is {{{ bl saveFP+56 ; save f28-f31 }}} and there are actually 4 cases like this in the code generated by {{{gcc}}} for {{{ffi009_stub.c}}}. This problem does not appear particularly easy to solve: The mechanism used when such a branch needs to address code that cannot be addressed using a 24-bit relative address is to create so-called jump islands, which are small, close-by pieces of code that (hopefully, but see #1845) *can* be reached using 24-bit relative addressing. The branch is changed to address the jump island which, in turn, constructs the actual 32-bit address and branches to it. Currently, however, this mechanism, for the PPC Mac OS X architecture, is limited to a single jump island per external symbol and is not capable of handling the addressing of external symbols with constants added to them. Handling the adding of a constant is doable, I believe, but the problem is that the same external symbol may appear multiple times with different constants added. For example, in addition to the above case, the code for {{{ffi009_stub.c}}} also includes {{{ bl saveFP+28 ; save f21-f31 }}} which would require creating two jump islands for the single symbol {{{saveFP}}}. Possible solutions: 1. Make a special case out of the specific symbols concerned here. This would involve creating a limited list of different jump islands for these symbols, to be used when different constants were added. 1. Generalize, somehow, the present jump island mechanism to allow more flexibility. It is undoubtably possible to do this, but it does not seem to be particularly easy to do. 1. The {{{-mlongjump}}} option actually causes {{{gcc}}} to replace the critical relative brach instructions by inline code, at the expense of generating longer and potentially slower code for all calls and possibly other branches as well. And if we try this, we get: {{{ ffi009: internal error: unknown relocation 13 (GHC version 6.11.20081121 for powerpc_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} (relocation type 13 is PPC_RELOC_JBSR) so Linker.c needs to be extended to handle this type also. Any advice on how to proceed in this matter, additional ideas and views, would be most welcome. Best regards Thorkil -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 24 05:44:38 2008 From: trac at galois.com (GHC) Date: Mon Nov 24 05:38:28 2008 Subject: [GHC] #2806: Require bang-patterns for unlifted bindings Message-ID: <046.9d55d0c05fffd15719c6c19b63c006aa@localhost> #2806: Require bang-patterns for unlifted bindings ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.3 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ GHC allows let/where bindings for unlifted values, but they are necessarily ''strict''. That does lead to confusing behaviour. For example, 'f' and 'g' behave differently here: {{{ {-# LANGUAGE MagicHash #-} import GHC.Base import GHC.Exts main :: IO () main = do print (I# (f 5# 0#)) print (I# (g 4# 0#)) f :: Int# -> Int# -> Int# f x y | False = x `divInt#` y f x y = x g :: Int# -> Int# -> Int# g x y | False = z where z = x `divInt#` y g x y = x }}} Suggestion: require that an unlifted let/where binding has a bang on it. That would make lifted and unlifted bindings behave uniformly. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 24 06:03:32 2008 From: trac at galois.com (GHC) Date: Mon Nov 24 05:57:26 2008 Subject: [GHC] #2801: Hang in getLine on Windows when Ctrl-C In-Reply-To: <053.cf8db06d79e114b571377a346a2aae7a@localhost> References: <053.cf8db06d79e114b571377a346a2aae7a@localhost> Message-ID: <062.d9f52e3a6488934b61e11327801d2043@localhost> #2801: Hang in getLine on Windows when Ctrl-C ----------------------------+----------------------------------------------- Reporter: erikcharlebois | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Windows | ----------------------------+----------------------------------------------- Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: Thanks. This one was already reported and fixed: #2758 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 24 06:05:57 2008 From: trac at galois.com (GHC) Date: Mon Nov 24 05:59:53 2008 Subject: [GHC] #2804: Failing GHCi: "ghc-6.8.2: internal error" In-Reply-To: <056.ec78b7e0bee86aec61dd34ed6f6eeb35@localhost> References: <056.ec78b7e0bee86aec61dd34ed6f6eeb35@localhost> Message-ID: <065.6521c05c99d660f0cddef4b463cc1b51@localhost> #2804: Failing GHCi: "ghc-6.8.2: internal error" -------------------------------+-------------------------------------------- Reporter: sfvisser@cs.uu.nl | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.8.2 Severity: blocker | 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. See #2512. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 24 06:24:08 2008 From: trac at galois.com (GHC) Date: Mon Nov 24 06:17:59 2008 Subject: [GHC] #2798: Enable "rec" keyword when RecursiveDo is enabled? In-Reply-To: <047.c01de827ffb9a59aafb72de68ac54369@localhost> References: <047.c01de827ffb9a59aafb72de68ac54369@localhost> Message-ID: <056.c40e69164ee8428c2d71bfd4e2d6ec2d@localhost> #2798: Enable "rec" keyword when RecursiveDo is enabled? ------------------------------+--------------------------------------------- Reporter: nominolo | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by claus): Replying to [comment:2 simonpj]: > I think the reason for 'mdo' was by analogy with 'let' and 'where': just say "use recursion" and let the compiler sort out the details. I have often wanted a non-recursive 'let' as well as the current 'let rec'. It would get rid of many unreadable '-ed names and silly bugs. 'do', with non-recursive bindings by default, and recursive bindings possible, is slightly more pleasant in this regard (though the syntactic differences between pure and monadic bindings are too awkward). Unfortunately, that nice and simple distinction is out of reach for 'let' (too much code out there), but "let the compiler sort out the details" is good only if programmers still have control, and renaming is not the nicest way of exercising such control. > * Remove 'mdo' and use 'do rec' instead Without bias to the actual choice, the name 'mdo' is unfortunate - I doubt it makes sense to Haskell newcomers, nor does it evoke useful semantic associations. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 24 06:40:59 2008 From: trac at galois.com (GHC) Date: Mon Nov 24 06:34:48 2008 Subject: [GHC] #2805: Test ffi009(ghci) fails on PPC Mac OS X In-Reply-To: <050.49e5533b97232a9f431fe6cab3b29ebd@localhost> References: <050.49e5533b97232a9f431fe6cab3b29ebd@localhost> Message-ID: <059.dfeca045a665ccb23c968bb3b1dd6a12@localhost> #2805: Test ffi009(ghci) fails on PPC Mac OS X --------------------------+------------------------------------------------- Reporter: thorkilnaur | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: ffi009(ghci) | Architecture: powerpc Os: MacOS X | --------------------------+------------------------------------------------- Changes (by simonmar): * difficulty: => Unknown Comment: Good analysis Thorkil! I expect the quickest way to workaround this problem is to implement the missing relocation type in the Linker and use `-mlongjump` option to gcc. But presumably this could apply to any compiled C code that we need to load up into GHCi, not just stub files? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 24 10:35:04 2008 From: trac at galois.com (GHC) Date: Mon Nov 24 10:29:08 2008 Subject: [GHC] #2807: the 'impossible' happened Message-ID: <044.c37aa6a069c13ff1a4ac7b7c3064e42a@localhost> #2807: the 'impossible' happened ---------------------------------+------------------------------------------ Reporter: celes | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.6 | Severity: normal Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ ghc panicced when compiling some code, which is valid code ghc --make lamb.hs -O2 -optc-O3 -fglasgow-exts -o lamb [1 of 1] Compiling Main ( lamb.hs, lamb.o ) ghc-6.6: panic! (the 'impossible' happened) (GHC version 6.6 for i386-apple-darwin): initC: srt Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make: *** [lamb] Error 1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 24 10:48:55 2008 From: trac at galois.com (GHC) Date: Mon Nov 24 10:42:47 2008 Subject: [GHC] #2807: the 'impossible' happened In-Reply-To: <044.c37aa6a069c13ff1a4ac7b7c3064e42a@localhost> References: <044.c37aa6a069c13ff1a4ac7b7c3064e42a@localhost> Message-ID: <053.37ef08fff465eb2d293bbf6ba6df76a9@localhost> #2807: the 'impossible' happened ---------------------------------+------------------------------------------ Reporter: celes | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ Comment (by celes): Note the error does not occur if the -O2 option is not used -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 24 13:25:33 2008 From: trac at galois.com (GHC) Date: Mon Nov 24 13:19:22 2008 Subject: [GHC] #2808: createDirectoryIfMissing should be atomic Message-ID: <046.21f1a9c564db33e6ee9ef7b6ede88c51@localhost> #2808: createDirectoryIfMissing should be atomic ---------------------------------+------------------------------------------ Reporter: EricKow | Owner: Type: bug | Status: new Priority: normal | Component: libraries/directory Version: 6.10.1 | Severity: normal Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ If I run createDirectoryIfMissing many times in parallel, it sometimes fails because (presumably) somewhere between the check if the directory exists, and between the actual creation, something else creates the directory. Right now my workaround is to catch exceptions with isAlreadyExistsErrors -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 24 18:30:20 2008 From: trac at galois.com (GHC) Date: Mon Nov 24 18:24:14 2008 Subject: [GHC] #2753: GHC 6.10.1 cannot compile Crypto-4.1.0 In-Reply-To: <052.22581ce23675b5d58c2247a1ee1a7ede@localhost> References: <052.22581ce23675b5d58c2247a1ee1a7ede@localhost> Message-ID: <061.af03f25385e0f45e899772ea1491f8f0@localhost> #2753: GHC 6.10.1 cannot compile Crypto-4.1.0 ------------------------------+--------------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: critical | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by StefanKersten): * cc: sk@k-hornz.de (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 24 21:54:24 2008 From: trac at galois.com (GHC) Date: Mon Nov 24 21:48:12 2008 Subject: [GHC] #2809: Patching libffi fails in Solaris Message-ID: <041.34e879df044c407444e4cdf62cae4e54@localhost> #2809: Patching libffi fails in Solaris ---------------------------------+------------------------------------------ Reporter: rl | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.11 | Severity: normal Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Solaris ---------------------------------+------------------------------------------ This is what happens: {{{ gmake[1]: Entering directory `/home/rl/ghc/ghc/libffi' rm -f -rf libffi-3.0.6 build /usr/sfw/bin/gtar -zxf libffi-3.0.6.tar.gz mv libffi-3.0.6 build chmod +x ln patch -p0 < libffi-dllize-3.0.6.patch Looks like a unified context diff. Hunk #5 failed at line 344. Hunk #6 failed at line 165. Hunk #7 failed at line 33. 3 out of 7 hunks failed: saving rejects to build/include/ffi.h.in.rej The next patch looks like a unified context diff. Hunk #2 failed at line 66. Hunk #3 failed at line 26. 2 out of 3 hunks failed: saving rejects to build/include/ffi_common.h.rej done gmake[1]: *** [stamp.ffi.configure] Error 1 }}} Using GNU `patch` instead of the Solaris version works. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 25 04:32:03 2008 From: trac at galois.com (GHC) Date: Tue Nov 25 04:25:51 2008 Subject: [GHC] #2808: createDirectoryIfMissing should be atomic In-Reply-To: <046.21f1a9c564db33e6ee9ef7b6ede88c51@localhost> References: <046.21f1a9c564db33e6ee9ef7b6ede88c51@localhost> Message-ID: <055.0f31202676d39004a8efd4bb6511d057@localhost> #2808: createDirectoryIfMissing should be atomic ------------------------------------+--------------------------------------- Reporter: EricKow | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/directory | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ------------------------------------+--------------------------------------- Comment (by duncan): Unfortunately it's not clear that this is possible. The POSIX `mkdir()` function can returns `EEXIST` however that does not distinguish the case that there is a existing directory, or that there is an existing file (or indeed symlink). It could be atomic but the error code / exception could not necessarily be accurate. It could check afterwards if the path that already existed was a file or directory, but of course that will not be atomic. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 25 05:13:06 2008 From: trac at galois.com (GHC) Date: Tue Nov 25 05:06:55 2008 Subject: [GHC] #2807: the 'impossible' happened In-Reply-To: <044.c37aa6a069c13ff1a4ac7b7c3064e42a@localhost> References: <044.c37aa6a069c13ff1a4ac7b7c3064e42a@localhost> Message-ID: <053.3dad10720ebec0e55d81626d03f86843@localhost> #2807: the 'impossible' happened ------------------------------+--------------------------------------------- Reporter: celes | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.6 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by simonpj): * status: new => closed * difficulty: => Unknown * resolution: => wontfix Comment: Thanks for the report. Definitely a bug in 6.6. However, it's fine in GHC 6.8 (last year's release) and 6.10 (last month's release). I'm afraid we won't be making any new releases of 6.6, so I can only suggest you upgrade. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 25 05:34:16 2008 From: trac at galois.com (GHC) Date: Tue Nov 25 05:28:04 2008 Subject: [GHC] #2740: free variable not available in debugger In-Reply-To: <046.05e1293bbffbc0807e6d01b8f2d22646@localhost> References: <046.05e1293bbffbc0807e6d01b8f2d22646@localhost> Message-ID: <055.0c8355109a57a92fbfb2f85bc0f6e211@localhost> #2740: free variable not available in debugger ----------------------+----------------------------------------------------- Reporter: phercek | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: debugger | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------+----------------------------------------------------- Changes (by simonmar): * owner: => simonmar * difficulty: => Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 25 05:57:15 2008 From: trac at galois.com (GHC) Date: Tue Nov 25 05:51:03 2008 Subject: [GHC] #2810: Debugger: change context to the module containing the current breakpoint Message-ID: <047.b89e274abc5219595c46be09d48a0b6b@localhost> #2810: Debugger: change context to the module containing the current breakpoint -------------------------------+-------------------------------------------- Reporter: simonmar | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: GHCi | Version: 6.8.3 Severity: normal | Keywords: Difficulty: Moderate (1 day) | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- Moved part of #2740 here. When we stop at a breakpoint, perhaps we should change the current context (`:module`) to the module that contains the breakpoint location. That would at least give access to a similar scope to that in which the breakpoint expression is located. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 25 06:01:05 2008 From: trac at galois.com (GHC) Date: Tue Nov 25 05:54:53 2008 Subject: [GHC] #2740: free variable not available in debugger In-Reply-To: <046.05e1293bbffbc0807e6d01b8f2d22646@localhost> References: <046.05e1293bbffbc0807e6d01b8f2d22646@localhost> Message-ID: <055.db18ddc9bac32f5e5e7f7beb76a2daf7@localhost> #2740: free variable not available in debugger -------------------------+-------------------------------------------------- Reporter: phercek | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.2 Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: debugger | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge * milestone: => 6.10.2 Comment: Fixed: {{{ Tue Nov 25 10:31:13 GMT 2008 Simon Marlow * Fix #2740: we were missing the free variables on some expressions Particularly boolean expresions: the conditional of an 'if', and guards, were missing their free variables. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 25 06:11:30 2008 From: trac at galois.com (GHC) Date: Tue Nov 25 06:05:22 2008 Subject: [GHC] #2799: Panic (core lint failure) with GADTs, GHC 6.10.1 In-Reply-To: <047.02178742ef8c8010079728a64ae52ee1@localhost> References: <047.02178742ef8c8010079728a64ae52ee1@localhost> Message-ID: <056.4ad20947f89603ea3c9fba123c0f009d@localhost> #2799: Panic (core lint failure) with GADTs, GHC 6.10.1 -----------------------------------------------+---------------------------- Reporter: alexey_r | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: typecheck/should_compile/T2799 | Os: Windows Architecture: x86 | -----------------------------------------------+---------------------------- Changes (by simonpj): * testcase: => typecheck/should_compile/T2799 * difficulty: => Unknown * type: bug => merge * owner: chak => igloo Comment: Excellent bug; fixed by {{{ Tue Nov 25 11:05:40 GMT 2008 simonpj@microsoft.com * Fix Trac #2799: TcType.isOverloadedTy }}} Please merge to 6.10 branch. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 25 06:15:18 2008 From: trac at galois.com (GHC) Date: Tue Nov 25 06:09:07 2008 Subject: [GHC] #2787: Panic (core lint failure) with type synonym in GHC 6.10.1 In-Reply-To: <049.16b406b9b4b75d10bbd6f184f46c2987@localhost> References: <049.16b406b9b4b75d10bbd6f184f46c2987@localhost> Message-ID: <058.5caf7b487c5e9eb1799c560e6d4dabd6@localhost> #2787: Panic (core lint failure) with type synonym in GHC 6.10.1 ----------------------------------------+----------------------------------- Reporter: BenMoseley | Owner: chak Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.10.1 Severity: major | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86 | ----------------------------------------+----------------------------------- Changes (by simonpj): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: Happily this seems to be fixed by the same fix as #2799, so I'll close this one. I won't add a test case, since I added one for #2799. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 25 06:15:50 2008 From: trac at galois.com (GHC) Date: Tue Nov 25 06:09:40 2008 Subject: [GHC] #2799: Panic (core lint failure) with GADTs, GHC 6.10.1 In-Reply-To: <047.02178742ef8c8010079728a64ae52ee1@localhost> References: <047.02178742ef8c8010079728a64ae52ee1@localhost> Message-ID: <056.7d11b7985040c2d9174e1cd64e991f72@localhost> #2799: Panic (core lint failure) with GADTs, GHC 6.10.1 -----------------------------------------------+---------------------------- Reporter: alexey_r | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: typecheck/should_compile/T2799 | Os: Windows Architecture: x86 | -----------------------------------------------+---------------------------- Comment (by simonpj): PS: Indeed #2787 was the same bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 25 06:16:32 2008 From: trac at galois.com (GHC) Date: Tue Nov 25 06:10:18 2008 Subject: [GHC] #2808: createDirectoryIfMissing should be atomic In-Reply-To: <046.21f1a9c564db33e6ee9ef7b6ede88c51@localhost> References: <046.21f1a9c564db33e6ee9ef7b6ede88c51@localhost> Message-ID: <055.734a6072086d33b2ac5c7a616401b543@localhost> #2808: createDirectoryIfMissing should be atomic ---------------------------------+------------------------------------------ Reporter: EricKow | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/directory | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ---------------------------------+------------------------------------------ Comment (by EricKow): Replying to [comment:1 duncan]: > It could be atomic but the error code / exception could not necessarily be accurate. It could check afterwards if the path that already existed was a file or directory, but of course that will not be atomic. Hmm, ok, maybe I don't want atomicity but the illusion of it :-) Actually, I'm not sure if this is the right thing for me to want, but I might like some sort of check afterwards (so createDirectoryIfMissing should catch its createDirectory exception, and if the path really is a directory, ignore the exception)... basically whatever it takes to let me continue using this function in my blissful ignorance. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 25 06:23:02 2008 From: trac at galois.com (GHC) Date: Tue Nov 25 06:16:50 2008 Subject: [GHC] #2739: GHC API crashes on template haskell splices In-Reply-To: <044.3bac7d34665c04ceca674c8a12436d56@localhost> References: <044.3bac7d34665c04ceca674c8a12436d56@localhost> Message-ID: <053.26c64d1e6de2e7baccf56f9f55022991@localhost> #2739: GHC API crashes on template haskell splices ---------------------------------+------------------------------------------ Reporter: waern | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * difficulty: => Unknown Comment: This stuff compiles fine using the compiler alone (see below) so it must be something to do with the GHC API. {{{ ghc -c TH.hs bash-3.2$ ghc -c TH2.hs Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Loading package syb ... linking ... done. Loading package array-0.2.0.0 ... linking ... done. Loading package packedstring-0.1.0.1 ... linking ... done. Loading package containers-0.2.0.0 ... linking ... done. Loading package pretty-1.0.1.0 ... linking ... done. Loading package template-haskell ... linking ... done. bash-3.2$ rm *.o rm: remove regular file `TH2.o'? y rm: remove regular file `TH.o'? y bash-3.2$ ghc --make TH2.hs [1 of 2] Compiling TH ( TH.hs, TH.o ) [2 of 2] Compiling TH2 ( TH2.hs, TH2.o ) Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Loading package syb ... linking ... done. Loading package array-0.2.0.0 ... linking ... done. Loading package packedstring-0.1.0.1 ... linking ... done. Loading package containers-0.2.0.0 ... linking ... done. Loading package pretty-1.0.1.0 ... linking ... done. Loading package template-haskell ... linking ... done. bash-3.2$ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.10.1 bash-3.2$ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 25 08:02:36 2008 From: trac at galois.com (GHC) Date: Tue Nov 25 07:56:27 2008 Subject: [GHC] #2807: the 'impossible' happened In-Reply-To: <044.c37aa6a069c13ff1a4ac7b7c3064e42a@localhost> References: <044.c37aa6a069c13ff1a4ac7b7c3064e42a@localhost> Message-ID: <053.897007b5c734363ef5ad16d1995b4246@localhost> #2807: the 'impossible' happened ---------------------------------+------------------------------------------ Reporter: celes | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.6 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by celes): I will upgrade, thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 25 08:18:57 2008 From: trac at galois.com (GHC) Date: Tue Nov 25 08:12:44 2008 Subject: [GHC] #2805: Test ffi009(ghci) fails on PPC Mac OS X In-Reply-To: <050.49e5533b97232a9f431fe6cab3b29ebd@localhost> References: <050.49e5533b97232a9f431fe6cab3b29ebd@localhost> Message-ID: <059.dad70f902adeb9f4f362b29ca195930e@localhost> #2805: Test ffi009(ghci) fails on PPC Mac OS X -----------------------------+---------------------------------------------- Reporter: thorkilnaur | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: ffi009(ghci) | Os: MacOS X Architecture: powerpc | -----------------------------+---------------------------------------------- Comment (by thorkilnaur): You are right: The limitations in Linker.c (for example, that it is unable to handle relocations of {{{external symbol+constant}}}) apply to any compiled code that we try to load up into GHCi. So, for example, to trigger this problem, we could code some C function with lots of {{{double}}} arguments and try to call that function from Haskell using GHCi. And to work around this, assuming we had implemented the PPC_RELOC_JBSR relocation type, we would require the C function to be compiled with {{{-mlongcall}}}. I have implemented rudimentary PPC_RELOC_JBSR support that simply always uses the branch island and with {{{-optc-mlongcall}}} added to the {{{ffi009}}} test case, the test succeeds. To complete this workaround, I would suggest that we change the {{{ASSERT(word + reloc->r_address == 0);}}} into an actual error message that, perhaps, advices the use of the {{{-mlongcall}}} option. But I am still uncertain about which direction to take here. Using the {{{-mlongcall}}} option solves the problem in the present case, but there is no guarantee that it will continue to do so in the future. The fact that the {{{bl xxxxFP+yy}}} instructions are replaced by inline code when using {{{-mlongcall}}} is not documented, as far as I have been able to tell. Some other mechanism could be used in later {{{gcc}}} versions. In addition, man gcc says: {{{ -mlongcall ... In the future, we may cause GCC to ignore all longcall specifica- tions when the linker is known to generate glue. }}} where the "glue" is code, like the jump islands generated by Linker.c, to enable branching with a 24-bit relative address to reach any 32-bit address via a branch island. So, ultimately, we may have to do this anyway. Another idea which I have not looked into at all would be to try to use the linker itself to do all these complex things, instead of having to duplicate the functionality ourselves. As before, any advice, comments, views, new ideas about how to proceed with this are most welcome. Best regards Thorkil -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 25 09:21:55 2008 From: trac at galois.com (GHC) Date: Tue Nov 25 09:15:42 2008 Subject: [GHC] #2811: Unicode support for text I/O Message-ID: <044.4bcdd3c48e1395a70346b0b750638356@localhost> #2811: Unicode support for text I/O -------------------------------+-------------------------------------------- Reporter: igloo | Owner: simonmar Type: feature request | Status: new Priority: high | Milestone: 6.12 branch Component: libraries/base | Version: 6.10.1 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- This means adding Unicode encoding/decoding for Text I/O handles. Consensus was that Text I/O should always use the current locale encoding. You can elect to have no encoding by opening in binary mode, but that's all. Presumably this will need the ability to convert between arbitrary encodings internally, so it would make sense to also expose this functionality as a library. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 25 09:28:33 2008 From: trac at galois.com (GHC) Date: Tue Nov 25 09:22:19 2008 Subject: [GHC] #2812: For ghci, drop editline in favour of haskeline Message-ID: <044.83b1cb097467eb96264cb87a3cc1f7c9@localhost> #2812: For ghci, drop editline in favour of haskeline -------------------------------+-------------------------------------------- Reporter: igloo | Owner: Type: task | Status: new Priority: normal | Milestone: 6.12 branch Component: GHCi | Version: 6.10.1 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- For ghci, drop editline in favour of haskeline. The hard work has already been done by Judah here: http://code.haskell.org/~judah/ghci-haskeline/ However, currently haskeline depends on utf8-string, which we'd rather not pull in as a dependency given we hope not to release with it, so this is semi-blocked on #2811 (Unicode support for text I/O). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 25 09:33:11 2008 From: trac at galois.com (GHC) Date: Tue Nov 25 09:26:57 2008 Subject: [GHC] #2812: For ghci, drop editline in favour of haskeline In-Reply-To: <044.83b1cb097467eb96264cb87a3cc1f7c9@localhost> References: <044.83b1cb097467eb96264cb87a3cc1f7c9@localhost> Message-ID: <053.280522114b71234cbe540668c60c252c@localhost> #2812: For ghci, drop editline in favour of haskeline ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: task | Status: new Priority: high | Milestone: 6.12 branch Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * priority: normal => high -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 25 09:33:49 2008 From: trac at galois.com (GHC) Date: Tue Nov 25 09:27:36 2008 Subject: [GHC] #2813: Create a utf8 bytestring-a-like Message-ID: <044.ad636022be236bf694f594b538272960@localhost> #2813: Create a utf8 bytestring-a-like --------------------------------+------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12 branch Component: libraries (other) | Version: 6.10.1 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple --------------------------------+------------------------------------------- There are a number of things we want a utf8 bytestring-a-like for: * GHC's !FastString to be built on top of * Text.!PrettyPrint.ptext (this means we can drop GHC's utils/Pretty) * template haskell, to use in place of packedstring * possibly to use in the base IO libraries (see also #2811) * possibly to use in haskeline (see also #2812) and probably more besides. Ideally all of this will be done comfortably in time for 6.12! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 25 09:37:14 2008 From: trac at galois.com (GHC) Date: Tue Nov 25 09:31:02 2008 Subject: [GHC] #2813: Create a utf8 bytestring-a-like In-Reply-To: <044.ad636022be236bf694f594b538272960@localhost> References: <044.ad636022be236bf694f594b538272960@localhost> Message-ID: <053.a7f1bbb33824b7c4084f5d04d6888bcc@localhost> #2813: Create a utf8 bytestring-a-like ----------------------------------+----------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12 branch Component: libraries (other) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by igloo): * cc: duncan.coutts@worc.ox.ac.uk (added) Comment: Duncan, you're the meeting point between Tom's stuff and the bytestring team, I believe, so I've assigned this to you. Feel free to unassign/reassign as appropriate, of course! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 25 10:49:12 2008 From: trac at galois.com (GHC) Date: Tue Nov 25 10:42:58 2008 Subject: [GHC] #2809: Patching libffi fails in Solaris In-Reply-To: <041.34e879df044c407444e4cdf62cae4e54@localhost> References: <041.34e879df044c407444e4cdf62cae4e54@localhost> Message-ID: <050.d07bcdf6e38aa12b3a5c4c0c92c2f390@localhost> #2809: Patching libffi fails in Solaris ---------------------------------+------------------------------------------ Reporter: rl | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Build System | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12 branch Comment: Thanks for the report. Adding a line {{{ diff -ur foo bar }}} before each of the lines beginning `---` makes it work. Was this patch made by concatenating multiple individual `diff -u`s, rather than with a single `diff -ur`? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 25 11:13:29 2008 From: trac at galois.com (GHC) Date: Tue Nov 25 11:07:16 2008 Subject: [GHC] #2814: Compiler timeout Message-ID: <044.7cf51bfd9b7a3eea1c42cfa6153ffe56@localhost> #2814: Compiler timeout --------------------+------------------------------------------------------- Reporter: celes | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: MacOS X | Architecture: x86 --------------------+------------------------------------------------------- Compiler times out and consumes 600+ MB of memory when compiling certain code. Previously reported this bug by email (was not registered). It was a more complicated version of this same thing and was in version 6.6. The first attached file is simplest I could make which still causes the problem. The second file is the original which when ran should reverse its input. % ghc --version The Glorious Glasgow Haskell Compilation System, version 6.10.1 % ghc --make test2.hs [1 of 1] Compiling Main ( test2.hs, test2.o ) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 25 11:48:33 2008 From: trac at galois.com (GHC) Date: Tue Nov 25 11:42:20 2008 Subject: [GHC] #2806: Require bang-patterns for unlifted bindings In-Reply-To: <046.9d55d0c05fffd15719c6c19b63c006aa@localhost> References: <046.9d55d0c05fffd15719c6c19b63c006aa@localhost> Message-ID: <055.0e44de8d29b56f02e865be60fdc7cea2@localhost> #2806: Require bang-patterns for unlifted bindings ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by guest): * cc: id@isaac.cedarswampstudios.org (added) Comment: I concur. -Isaac D. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 25 13:24:25 2008 From: trac at galois.com (GHC) Date: Tue Nov 25 13:18:12 2008 Subject: [GHC] #2739: GHC API crashes on template haskell splices In-Reply-To: <044.3bac7d34665c04ceca674c8a12436d56@localhost> References: <044.3bac7d34665c04ceca674c8a12436d56@localhost> Message-ID: <053.b9f40266e5c3a187ea12062b5e19ce35@localhost> #2739: GHC API crashes on template haskell splices ---------------------------------+------------------------------------------ Reporter: waern | Owner: nominolo Type: bug | Status: assigned Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by nominolo): * status: new => assigned * owner: => nominolo Comment: I cannot reproduce a {{{fromJust}}} error, however, when compiling with the GHC API with {{{HscNothing}}} as target, I get a message explaining that the closure for {{{decl}}} could not be found. This makes sense since in nothing-mode we fake a bytecode object to avoid recompilation of that module when its source hasn't changed. So we have to decide how to deal with this. We could probably detect dependency whether TH is being used during dependency analysis and either fail or force the target to {{{HscInterpreted}}} or {{{HscC}}} since the former may fail if, for example, unboxed tuples are used anywhere in the source. Using HEAD's haddock it consequently fails in Linker.getLinkDeps: {{{ $ ../../ghc/utils/haddock/install-inplace/bin/haddock.exe -B ../../ghc/ TH2.hs haddock: internal Haddock or GHC error: expectJust getLinkDeps }}} I have to think about what a reasonable solution would be. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 25 14:09:58 2008 From: trac at galois.com (GHC) Date: Tue Nov 25 14:03:46 2008 Subject: [GHC] #2815: On windows, hGetLine stdin leaks like an inside trader Message-ID: <043.3df837702ae4600d2a6b83af98512acb@localhost> #2815: On windows, hGetLine stdin leaks like an inside trader --------------------+------------------------------------------------------- Reporter: sclv | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Windows | Architecture: Unknown/Multiple --------------------+------------------------------------------------------- 1) Compile the following code, in GHC 6.10.1 or 6.8.3 on Windows XP. 2) Don't type anything, just bring up the task manager and wait. 3) Watch as the memory usage climbs, slowly, and then with increasing vigor. 4) If you start typing things, the memory usage will cease climbing. {{{ main = do forever $ do x <- hGetLine stdin putStrLn x }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 25 15:13:43 2008 From: trac at galois.com (GHC) Date: Tue Nov 25 15:07:28 2008 Subject: [GHC] #2811: Unicode support for text I/O In-Reply-To: <044.4bcdd3c48e1395a70346b0b750638356@localhost> References: <044.4bcdd3c48e1395a70346b0b750638356@localhost> Message-ID: <053.2d37e845b080863648cc053539ce1424@localhost> #2811: Unicode support for text I/O ---------------------------------+------------------------------------------ Reporter: igloo | Owner: simonmar Type: feature request | Status: new Priority: high | Milestone: 6.12 branch Component: libraries/base | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by duncan): Replying to [ticket:2811 igloo]: > You can elect to have no encoding by opening in binary mode, but that's all. With the existing H98 and System.IO api, yes. > Presumably this will need the ability to convert between arbitrary encodings internally, so it would make sense to also expose this functionality as a library. Not arbitrary character sets or encodings thereof, just to and from Unicode. Note that there is already a library that provides converting between pairs of character sets and encodings - the iconv package on hackage. We could probably make another lib that provides a portable lowest common denominator of that and the Win32 encodings API. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 25 18:40:14 2008 From: trac at galois.com (GHC) Date: Tue Nov 25 18:34:00 2008 Subject: [GHC] #2812: For ghci, drop editline in favour of haskeline In-Reply-To: <044.83b1cb097467eb96264cb87a3cc1f7c9@localhost> References: <044.83b1cb097467eb96264cb87a3cc1f7c9@localhost> Message-ID: <053.a60a80811af5a83c3f7c9f029a858da0@localhost> #2812: For ghci, drop editline in favour of haskeline ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: task | Status: new Priority: high | Milestone: 6.12 branch Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by judahj): * cc: judahj (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 26 04:20:46 2008 From: trac at galois.com (GHC) Date: Wed Nov 26 04:14:34 2008 Subject: [GHC] #2814: Compiler timeout In-Reply-To: <044.7cf51bfd9b7a3eea1c42cfa6153ffe56@localhost> References: <044.7cf51bfd9b7a3eea1c42cfa6153ffe56@localhost> Message-ID: <053.849140848ed66b74850136369d43253c@localhost> #2814: Compiler timeout -------------------------+-------------------------------------------------- Reporter: celes | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by simonpj): * status: new => closed * difficulty: => Unknown * resolution: => wontfix Old description: > Compiler times out and consumes 600+ MB of memory when compiling certain > code. Previously reported this bug by email (was not registered). It was > a more complicated version of this same thing and was in version 6.6. The > first attached file is simplest I could make which still causes the > problem. The second file is the original which when ran should reverse > its input. > > % ghc --version > The Glorious Glasgow Haskell Compilation System, version 6.10.1 > % ghc --make test2.hs > [1 of 1] Compiling Main ( test2.hs, test2.o ) > New description: Compiler times out and consumes 600+ MB of memory when compiling certain code. Previously reported this bug by email (was not registered). It was a more complicated version of this same thing and was in version 6.6. The first attached file is simplest I could make which still causes the problem. The second file is the original which when ran should reverse its input. {{{ % ghc --version The Glorious Glasgow Haskell Compilation System, version 6.10.1 % ghc --make test2.hs [1 of 1] Compiling Main ( test2.hs, test2.o ) }}} Comment: Ah! This is a known bug: it's even in the user manual: [http://www.haskell.org/ghc/docs/latest/html/users_guide/bugs.html#bugs- ghc]. It arises when you encode recursion using a data type: {{{ data V = Fun (V -> V) }}} As the manual says, we've never fixed it because it's quite tricky and awkward to do so, and it only ever shows up in non-contrived programs. I guess if it happens in a "real" program we'll have to pay more attention. For the moment I'll mark this "wont-fix" but yell if this programming idiom is truly useful to you in real programs. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 26 05:50:05 2008 From: trac at galois.com (GHC) Date: Wed Nov 26 05:43:49 2008 Subject: [GHC] #2808: createDirectoryIfMissing should be atomic In-Reply-To: <046.21f1a9c564db33e6ee9ef7b6ede88c51@localhost> References: <046.21f1a9c564db33e6ee9ef7b6ede88c51@localhost> Message-ID: <055.bb47ff8cc2eeeb5c6b908bccf0e3a352@localhost> #2808: createDirectoryIfMissing should be atomic ------------------------------------+--------------------------------------- Reporter: EricKow | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: libraries/directory | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ------------------------------------+--------------------------------------- Changes (by simonmar): * owner: => simonmar * difficulty: => Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 26 06:46:49 2008 From: trac at galois.com (GHC) Date: Wed Nov 26 06:40:33 2008 Subject: [GHC] #2815: On windows, hGetLine stdin leaks like an inside trader In-Reply-To: <043.3df837702ae4600d2a6b83af98512acb@localhost> References: <043.3df837702ae4600d2a6b83af98512acb@localhost> Message-ID: <052.3f3857dc0d9a8cf7caadc411cc559cfd@localhost> #2815: On windows, hGetLine stdin leaks like an inside trader ----------------------------+----------------------------------------------- Reporter: sclv | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Windows | Architecture: Unknown/Multiple ----------------------------+----------------------------------------------- Comment (by nominolo): I cannot reproduce this on Vista. Could you compile your program with 6.10.1 and run it with {{{+RTS -hT}}}. Let it run for a while then kill it. It should then have produced a {{{.hp}}} file (for "Heap Profile"). You should have a tool {{{hp2ps}}} coming with 6.10.1 which converts this file to a postscript file. Could you then attach the .hp or .ps file to this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 26 06:47:45 2008 From: trac at galois.com (GHC) Date: Wed Nov 26 06:41:28 2008 Subject: [GHC] #2815: On windows, hGetLine stdin leaks like an inside trader In-Reply-To: <043.3df837702ae4600d2a6b83af98512acb@localhost> References: <043.3df837702ae4600d2a6b83af98512acb@localhost> Message-ID: <052.f23f8689ffb9210135afe4285445a293@localhost> #2815: On windows, hGetLine stdin leaks like an inside trader ----------------------------+----------------------------------------------- Reporter: sclv | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Windows | Architecture: Unknown/Multiple ----------------------------+----------------------------------------------- Comment (by nominolo): On second thought, if this is a runtime system bug this might not be very helpful. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 26 07:07:20 2008 From: trac at galois.com (GHC) Date: Wed Nov 26 07:01:04 2008 Subject: [GHC] #2815: On windows, hGetLine stdin leaks like an inside trader In-Reply-To: <043.3df837702ae4600d2a6b83af98512acb@localhost> References: <043.3df837702ae4600d2a6b83af98512acb@localhost> Message-ID: <052.b990cd3b671cb1724327172498856aba@localhost> #2815: On windows, hGetLine stdin leaks like an inside trader ---------------------------------+------------------------------------------ Reporter: sclv | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * priority: normal => high * difficulty: => Unknown * owner: => simonmar * milestone: => 6.10.2 Comment: I managed to reproduce it, but only with `-threaded`. This is a serious bug, thanks for spotting it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 26 07:53:15 2008 From: trac at galois.com (GHC) Date: Wed Nov 26 07:47:01 2008 Subject: [GHC] #2815: On windows, hGetLine stdin leaks like an inside trader In-Reply-To: <043.3df837702ae4600d2a6b83af98512acb@localhost> References: <043.3df837702ae4600d2a6b83af98512acb@localhost> Message-ID: <052.825274809a968ac70d27312c9a670888@localhost> #2815: On windows, hGetLine stdin leaks like an inside trader ---------------------------------+------------------------------------------ Reporter: sclv | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by felixmar): FWIW i cannot reproduce this either on Windows XP. I have tested with 6.10.1 and 6.8.3, threaded RTS or not and with various optimization settings. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 26 08:17:55 2008 From: trac at galois.com (GHC) Date: Wed Nov 26 08:11:46 2008 Subject: [GHC] #2399: Template Haskell: support for view patterns In-Reply-To: <043.ea0fa95d3ba4304244b4038504ec46d3@localhost> References: <043.ea0fa95d3ba4304244b4038504ec46d3@localhost> Message-ID: <052.0429ed3c748ee89416f4fe5c35fce94d@localhost> #2399: Template Haskell: support for view patterns ---------------------------------+------------------------------------------ Reporter: fons | Owner: Type: feature request | Status: new Priority: low | Milestone: _|_ Component: Template Haskell | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by reinerp): * cc: reiner.pope@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 26 08:27:13 2008 From: trac at galois.com (GHC) Date: Wed Nov 26 08:20:58 2008 Subject: [GHC] #2766: Infix type operators are presented with incorrect syntax in ghci In-Reply-To: <048.ede65a0a07b7bb10f4f547601c287a56@localhost> References: <048.ede65a0a07b7bb10f4f547601c287a56@localhost> Message-ID: <057.20ae81b8e83e3de8cfd280400dd1b47a@localhost> #2766: Infix type operators are presented with incorrect syntax in ghci ---------------------------------+------------------------------------------ Reporter: EyalLotem | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * difficulty: => Unknown Comment: Fixed by {{{ Wed Nov 26 13:22:02 GMT 2008 simonpj@microsoft.com * Fix Trac #2766: printing operator type variables }}} Now we get {{{ Prelude Control.Arrow> :t first :: Arrow (~>) => b~>c -> (b, d)~>(c, d) first :: Arrow (~>) => b~>c -> (b, d)~>(c, d) :: (Arrow (~>)) => (~>) b c -> (~>) (b, d) (c, d) }}} It's be better still to print the operator infix, but the pretty-printer for `Type` does not know about fixities, so I have not done that (yet, anyway). But at least it's a legal type now. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 26 08:32:48 2008 From: trac at galois.com (GHC) Date: Wed Nov 26 08:26:33 2008 Subject: [GHC] #2766: Infix type operators are presented with incorrect syntax in ghci In-Reply-To: <048.ede65a0a07b7bb10f4f547601c287a56@localhost> References: <048.ede65a0a07b7bb10f4f547601c287a56@localhost> Message-ID: <057.2441658b63522a737bb275dbc43e0949@localhost> #2766: Infix type operators are presented with incorrect syntax in ghci -----------------------------------+---------------------------------------- Reporter: EyalLotem | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: ghci/scripts/T2766 | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------+---------------------------------------- Changes (by simonpj): * testcase: => ghci/scripts/T2766 * owner: => igloo * type: bug => merge Comment: Merge to stable. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 26 09:04:02 2008 From: trac at galois.com (GHC) Date: Wed Nov 26 08:57:47 2008 Subject: [GHC] #2814: Compiler timeout In-Reply-To: <044.7cf51bfd9b7a3eea1c42cfa6153ffe56@localhost> References: <044.7cf51bfd9b7a3eea1c42cfa6153ffe56@localhost> Message-ID: <053.c367369705fb802baad00132dc7ad29d@localhost> #2814: Compiler timeout -------------------------+-------------------------------------------------- Reporter: celes | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------+-------------------------------------------------- Comment (by celes): Replying to [comment:1 simonpj]: > Ah! This is a known bug: it's even in the user manual: [http://www.haskell.org/ghc/docs/latest/html/users_guide/bugs.html#bugs- ghc]. It arises when you encode recursion using a data type: > {{{ > data V = Fun (V -> V) > }}} > As the manual says, we've never fixed it because it's quite tricky and awkward to do so, and it only ever shows up in non-contrived programs. I guess if it happens in a "real" program we'll have to pay more attention. > > For the moment I'll mark this "wont-fix" but yell if this programming idiom is truly useful to you in real programs. > > Simon Sorry for not checking the user's manual for existing bugs before posting. As for usefulness in real programs, I think it might be useful for getting around the infinite type problem (I was using it to compile code from the untyped lambda calculus, based on this code: http://sneezy.cs.nott.ac.uk/fplunch/weblog/?p=95 ). Are there better ways to go about this though? Not a big problem for me, instead just interpreting the code isntead of compiling which is about 8x slower, but still really fast compared to other untyped lambda calculus interpreters due to haskell's speed. Thanks, celes -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 26 09:44:21 2008 From: trac at galois.com (GHC) Date: Wed Nov 26 09:38:06 2008 Subject: [GHC] #2816: ghci type messages mangle unicode Message-ID: <042.cda3d53c33f3e686ec1551e0d8688ddf@localhost> #2816: ghci type messages mangle unicode --------------------------+------------------------------------------------- Reporter: rog | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.10.1 | Severity: normal Keywords: unicode utf-8 | Testcase: Os: MacOS X | Architecture: x86 --------------------------+------------------------------------------------- while error messages containing identifiers with unicode characters print fine, other messages from ghci do not. for instance: Prelude> ? :1:0: Not in scope: `?' Prelude> let ? = 4 Prelude> ? 4 Prelude> :type ? ? :: Integer -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 26 09:47:45 2008 From: trac at galois.com (GHC) Date: Wed Nov 26 09:41:31 2008 Subject: [GHC] #2762: Excessive heap usage In-Reply-To: <044.bf1fb1b8e171504548cbe3cb91273ef8@localhost> References: <044.bf1fb1b8e171504548cbe3cb91273ef8@localhost> Message-ID: <053.92a073f84b07ec53c0bdc75d13f4a0bf@localhost> #2762: Excessive heap usage ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * cc: batterseapower@hotmail.com (added) Comment: What we need here is a decent arity analysis, which Max is thinking about. We have {{{ f = \d. let f1 = f d in \y. ...f1... }}} The leak comes from a shared partial application of `f`: {{{ let t = f d in (t e1, t e2) or map (f d) es }}} This is readily fixed. `f` ''looks'' as if it has arity 1, but a simple fixpoint argument shows that it really has arity 2. When we see that, we see that we can eta-expand it to get {{{ f = \d.\x. let f1 = f d in ...f1 d... }}} Now we can inline `f1`, and all is good. I had not previously realised that this arity analysis stuff could fix space leaks. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 26 10:38:34 2008 From: trac at galois.com (GHC) Date: Wed Nov 26 10:32:19 2008 Subject: [GHC] #2817: Template Haskell conversion fails with "malformed type" Message-ID: <046.4aa37e864452514bae7500fd7deea017@localhost> #2817: Template Haskell conversion fails with "malformed type" -------------------------------+-------------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- Nicholas Frisby writes: When using Template Taskell (via Derive) to generate this (exact) instance: {{{ instance Foldable ((->) Int) => Foldable Data.Derivable.InterpreterLib.Test.List where foldMap f (Cons x0 x1) = (const mempty Cons `mappend` foldMap f x0) `mappend` foldMap f x1 foldMap f (Nil) = const mempty Nil }}} I realize the context is unsatisfiable. My issue, is that I can't even reach that "challenge". I get this error instead: {{{ Malformed type AppT ArrowT (ConT GHC.Base.Int) When splicing generated code into the program }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 26 10:41:11 2008 From: trac at galois.com (GHC) Date: Wed Nov 26 10:34:57 2008 Subject: [GHC] #2817: Template Haskell conversion fails with "malformed type" In-Reply-To: <046.4aa37e864452514bae7500fd7deea017@localhost> References: <046.4aa37e864452514bae7500fd7deea017@localhost> Message-ID: <055.a776ea641c492b103d996c873b1c30ba@localhost> #2817: Template Haskell conversion fails with "malformed type" ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonpj): Good bug. Here is a small test case: {{{ module TH( x ) where import Language.Haskell.TH data T f = MkT (f Int) x = $(return (SigE (VarE 'x) (AppT (ConT ''T) (AppT ArrowT (ConT ''Int))))) }}} The bug is in the conversion from TH syntax to `HsSyn` in `Convert.hs`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 26 10:44:30 2008 From: trac at galois.com (GHC) Date: Wed Nov 26 10:38:14 2008 Subject: [GHC] #2817: Template Haskell conversion fails with "malformed type" In-Reply-To: <046.4aa37e864452514bae7500fd7deea017@localhost> References: <046.4aa37e864452514bae7500fd7deea017@localhost> Message-ID: <055.04d5c5880359c7b460f09deb38ca0abe@localhost> #2817: Template Haskell conversion fails with "malformed type" ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: th/T2817 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * testcase: => th/T2817 * owner: => igloo * type: bug => merge Comment: Fixed by {{{ Wed Nov 26 15:40:22 GMT 2008 simonpj@microsoft.com * Fix Trac #2817 (TH syntax -> HsSyn conversion) }}} Pls merge Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 26 14:18:16 2008 From: trac at galois.com (GHC) Date: Wed Nov 26 14:12:05 2008 Subject: [GHC] #2399: Template Haskell: support for view patterns In-Reply-To: <043.ea0fa95d3ba4304244b4038504ec46d3@localhost> References: <043.ea0fa95d3ba4304244b4038504ec46d3@localhost> Message-ID: <052.46b7a6976e286f817c81eef0ddd3611f@localhost> #2399: Template Haskell: support for view patterns ---------------------------------+------------------------------------------ Reporter: fons | Owner: Type: feature request | Status: new Priority: low | Milestone: _|_ Component: Template Haskell | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by guest): * cc: id@isaac.cedarswampstudios.org (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 26 16:27:27 2008 From: trac at galois.com (GHC) Date: Wed Nov 26 16:21:10 2008 Subject: [GHC] #2818: schedule: invalid what_next field Message-ID: <047.464b7aed990b24af643c9609b75f7b8f@localhost> #2818: schedule: invalid what_next field ---------------------+------------------------------------------------------ Reporter: kkwweett | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 6.10.1 | Severity: normal Keywords: schedule | Testcase: Os: Windows | Architecture: x86 ---------------------+------------------------------------------------------ = internal error: schedule: invalid what_next field = I'm studying a program which runs without trouble within ghci but fails to run well once compiled with ghc --make. * The program * The error message * The ways I get or not the error message == The program == It is a computing of the index for which the length of the longuest sequence during a Syracuse process [(/2) if even u, (+1).(*3) if odd u] is reached. ''boundary'' variable is the only parameter. For instance, the program returns '''3''' for {{{ boundary=5 }}} because [[BR]] the 1-process [1->] has 0 element, [[BR]] the 2-process [2->1] has 1 element, [[BR]] the 3-process [3->10,5,16,8,4,2,1] has 7 elements, [[BR]] the 4-process [4->2,1] has 2 elements and [[BR]] the 5-process [5->16,8,4,2,1] has 5 elements [[BR]] so the index for which the maximum is reached is '''3''' (for a length maximum of 7). {{{ -- syracuse.hs import Data.Array import Data.Ord boundary=25999 maximumBy g x = fst $ (foldr (maxBy g) (0,0) x) maxBy comp x y=case (comp x y) of GT -> x EQ -> y LT -> y syrs n = a where a = listArray (1,n) $ 0:[ syr x | x <- [2..n]] syr x = if x' <= n then 1 + a ! x' else 1 + syr x' where x' = if even x then x `div` 2 else 3 * x + 1 main = print $ maximumBy (comparing snd)$ assocs $ syrs boundary }}} == The error message == syracuse.exe: internal error: schedule: invalid what_next field [[BR]] (GHC version 6.10.1 for i386_unknown_mingw32)[[BR]] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug [[BR]] This application has requested the Runtime to terminate it in an unusual way. [[BR]] Please contact the application's support team for more information. [[BR]] == The ways I get or not the error message == I'm running Windows XP SP3 on a ~1GHz CPU/ ~1Go RAM computer.[[BR]] Within ghci, I'm only limited by memory (I get an *** Exception : stack overflow for boundary=140000) and I can compute up to {{{ boundary=130000 }}} for which the program returns '''106239'''. On the other hand, when I compile using {{{ ghc --make syracuse }}} everything 's all right up to boundary=25998 (result:'''23529''', Exit code: 0 ) but as far as boundary>25998, the program displays the result (for instance I can get '''106239''' again) but the error message is also displayed with Exit code: 3. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 26 16:52:46 2008 From: trac at galois.com (GHC) Date: Wed Nov 26 16:46:28 2008 Subject: [GHC] #2818: schedule: invalid what_next field In-Reply-To: <047.464b7aed990b24af643c9609b75f7b8f@localhost> References: <047.464b7aed990b24af643c9609b75f7b8f@localhost> Message-ID: <056.d900f91d2ddc36ee4f37586b7bacd604@localhost> #2818: schedule: invalid what_next field ----------------------------+----------------------------------------------- Reporter: kkwweett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: Keywords: schedule | Testcase: Os: Windows | Architecture: x86 ----------------------------+----------------------------------------------- Changes (by BenMoseley): * cc: ben@moseley.name (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From marlowsd at gmail.com Thu Nov 27 04:05:25 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Nov 27 03:59:12 2008 Subject: build failure for 6.10.1, missing ghcautoconf.h In-Reply-To: References: Message-ID: <492E62D5.7070209@gmail.com> Conal Elliott wrote: > I just tried to build 6.10.1 from the source tarball > (http://haskell.org/ghc/dist/6.10.1/ghc-6.10.1-src.tar.bz2) (plus > extralibs) on Ubuntu 8.10, building with ghc-6.11. I got the following > error: > > Configuring ghc-bin-6.10.1... > /home/conal/downloads/ghc-6.10.1/libraries/cabal-bin > /usr/local/bin/ghc > /home/conal/downloads/ghc-6.10.1/libraries/bootstrapping.conf build > --distpref dist-stage1 --ghc-option=-H32m --ghc-option=-O > --ghc-option=-H32m --ghc-option=-O > Preprocessing executables for ghc-bin-6.10.1... > Building ghc-bin-6.10.1... > > In file included from Main.hs:14:0: > > > /usr/local/lib/ghc-6.11.20081103/ghc-6.11.20081103/include/HsVersions.h:23:0: > error: ../includes/ghcautoconf.h: No such file or directory > make[2]: *** [build.stage.1] Error 1 > make[1]: *** [build.stage.1] Error 2 > make: *** [stage1] Error 1 > conal@compy-doble:~/downloads/ghc-6.10.1$ > > Is this problem known? Does it come from building 6.10.1 with 6.11? I didn't see a followup to this. Conal, are you still seeing this? I don't have any idea what's going on, and we don't see this on our Windows builds, but we can certainly investigate further. Cheers, Simon From trac at galois.com Thu Nov 27 04:08:25 2008 From: trac at galois.com (GHC) Date: Thu Nov 27 04:02:06 2008 Subject: [GHC] #2818: schedule: invalid what_next field In-Reply-To: <047.464b7aed990b24af643c9609b75f7b8f@localhost> References: <047.464b7aed990b24af643c9609b75f7b8f@localhost> Message-ID: <056.9a22e9e3b514fe19f7a26ff43f56fb2e@localhost> #2818: schedule: invalid what_next field -------------------------------+-------------------------------------------- Reporter: kkwweett | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: Keywords: schedule | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by simonmar): * owner: => simonmar * difficulty: => Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 27 07:04:23 2008 From: trac at galois.com (GHC) Date: Thu Nov 27 06:58:06 2008 Subject: [GHC] #2748: Fundep-laden code compiled and ran fine in 6.8, fails in 6.10 In-Reply-To: <048.d339fd8ea08f26d215e7fbe110469ee0@localhost> References: <048.d339fd8ea08f26d215e7fbe110469ee0@localhost> Message-ID: <057.13d60bf17fa5bc62c16b5c29b053aca0@localhost> #2748: Fundep-laden code compiled and ran fine in 6.8, fails in 6.10 ---------------------------------+------------------------------------------ Reporter: sedillard | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * status: new => closed * difficulty: => Unknown * resolution: => invalid Old description: > I was kindly alerted by Ian Lynagh that some code of mine on hackage was > causing 6.10-rc1 to fail to terminate. This code compiles and runs find > on 6.8. Instead of diverging, 6.10.1 raises a type error. I've made a > test case, and I'm creating this ticket to figure out what's going in. Is > it, > > A) The code is incorrect and 6.8 was erroneously accepting it, and only > by luck producing a valid program > > B) The code is correct and 6.10.1's typechecker is being overly > conservative. > > At the core is overlapping instances. I've spent considerable effort > removing them from the library, because I can't just look at the code and > say for certain "this will never overlap with that" because its too > complicated. Overlap errors become the users problem, I myself having > been bitten by them many times as a user of my own library. The solution > is to do without overlapping instances. The types of my instances then go > from something nice like > > {{{ > instance (A t) => C t > instance (B t) => C t --overlap > }}} > > to something nasty like > > {{{ > instance (A (T (T x))) => C (T (T x)) > instance (B (T (T (T x)))) => C (T (T (T x))) --no overlap > }}} > > It's uglier for me to read and write but ultimately better for the user > because I've eliminated a category of errors. If the compiler will let > me, I try to abbreviate 'T (T (T x)))' to 't' in the instance head, but > I'm not always able to because 't' is more general than 'T (T (T x)))'. > I'm not entirely sure how that factors into things. To see what I'm > talking about, compile the attached file and look for the error that says > {{{Couldn't match expected type `vmt' against inferred type `vv :. (b' :. > v)' `vmt' is a rigid type variable...}}}. It has something to do with > functional dependencies. The fundep involved demands that 'vmt' be of the > type 'x :. y :. z :. etc' but in this particular case it's so verbose I > just call it 'vmt'. 6.8 lets me do that. 6.10 doesn't. Who's right? New description: I was kindly alerted by Ian Lynagh that some code of mine on hackage was causing 6.10-rc1 to fail to terminate. This code compiles and runs find on 6.8. Instead of diverging, 6.10.1 raises a type error. I've made a test case, and I'm creating this ticket to figure out what's going in. Is it, A) The code is incorrect and 6.8 was erroneously accepting it, and only by luck producing a valid program B) The code is correct and 6.10.1's typechecker is being overly conservative. At the core is overlapping instances. I've spent considerable effort removing them from the library, because I can't just look at the code and say for certain "this will never overlap with that" because its too complicated. Overlap errors become the users problem, I myself having been bitten by them many times as a user of my own library. The solution is to do without overlapping instances. The types of my instances then go from something nice like {{{ instance (A t) => C t instance (B t) => C t --overlap }}} to something nasty like {{{ instance (A (T (T x))) => C (T (T x)) instance (B (T (T (T x)))) => C (T (T (T x))) --no overlap }}} It's uglier for me to read and write but ultimately better for the user because I've eliminated a category of errors. If the compiler will let me, I try to abbreviate 'T (T (T x)))' to 't' in the instance head, but I'm not always able to because 't' is more general than 'T (T (T x)))'. I'm not entirely sure how that factors into things. To see what I'm talking about, compile the attached file and look for the error that says {{{ Couldn't match expected type `vmt' against inferred type `vv :. (b' :. v)' `vmt' is a rigid type variable... }}} It has something to do with functional dependencies. The fundep involved demands that 'vmt' be of the type 'x :. y :. z :. etc' but in this particular case it's so verbose I just call it 'vmt'. 6.8 lets me do that. 6.10 doesn't. Who's right? Comment: This is a scarily complicated piece of code. I wonder if would look simpler with type functions? Still I took a look. I can see this: {{{ -- Line 147-ish class Map a b u v | u -> a, v -> b, b u -> v, a v -> u where ... instance Map a b (a':.u) (b':.v) => Map a b (a:.a':.u) (b:.b':.v) where ... -- Line 68-ish instance (... ,Map (a:.a:.a:.v) vv ((a:.a:.a:.v):.(a:.a:.a:.v):.m) vmt ...) where ... ) => Det' a ((a:.a:.a:.v):.(a:.a:.a:.v):.(a:.a:.a:.v):.m) }}} Consider this simpler version: {{{ class C a b | a->b instance C Int Bool f :: C Int x => ... }}} GHC rejects the type ignature for 'f' because 'x' must be `Bool`. It's the same in an instance declaration {{{ instance C Int x => ... }}} And that's what you have here. The fundep `b u -> v` in class `Map` together with the instance declaration says that in any constraint {{{ Map ... tb (ta:ta':tu) vmt }}} then `vmt` must be of form `(tb:tb':tv)`. But in your example it isn't. Changing the instance decl to {{{ instance (... ,Map (a:.a:.a:.v) vv ((a:.a:.a:.v):.(a:.a:.a:.v):.m) (vv :. vmt1 :. vmt2) ...) where ... ) => Det' a ((a:.a:.a:.v):.(a:.a:.a:.v):.(a:.a:.a:.v):.m) }}} and replacing `vmt` by `(vv:.vmt1:.vmt2)` in the code, makes the error go away. In short, when you use a type variable like `vmt` in a type signature, GHC assumes you mean a type `variable` and checks that you do. This is presumably a bug in 6.8. I've taken the opportunity to improve the error message to say which fundep is involved. I'll close the bug though. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 27 07:30:44 2008 From: trac at galois.com (GHC) Date: Thu Nov 27 07:24:35 2008 Subject: [GHC] #2742: The -> in ViewPatterns binds more weakly than infix data constructors. In-Reply-To: <044.60b13b19392ff3d7bf14c8ffe9299245@localhost> References: <044.60b13b19392ff3d7bf14c8ffe9299245@localhost> Message-ID: <053.99023c86671f4dd8d4b2b6525062b257@localhost> #2742: The -> in ViewPatterns binds more weakly than infix data constructors. ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * difficulty: => Unknown * type: bug => feature request * milestone: => _|_ Comment: I agree with you. Here's why it's tricky. Haskell allows a pattern like this {{{ case x of a:as -> rhs }}} If view patterns bind more tightly than infix ops, then presumably this would be ok {{{ case x of a : f as -> bs -> rhs }}} and now we get an awkward ambiguity between the two uses of `->`. The change I made to the parser was this: * Remove this production from `texp`: {{{ | fexp '->' exp { LL $ EViewPat $1 $3 } }}} * Add the same production to `exp10`. That added a new shift/reduce conflict, described above, which gets resolved the wrong way. If someone wants to investigate alternatives, that'd be great, so I'll leave this open as a feature request. It's a pure parser question so it does not require deep GHC knowledge. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 27 09:03:24 2008 From: trac at galois.com (GHC) Date: Thu Nov 27 08:57:06 2008 Subject: [GHC] #2729: Stuck when compiling XMonad.StackSet in xmonad 0.9 (hackage version) In-Reply-To: <047.e60b778bc8c8ee75007c390c57c1ee7f@localhost> References: <047.e60b778bc8c8ee75007c390c57c1ee7f@localhost> Message-ID: <056.a2d20bbfe8a6c07897900bbc38299d15@localhost> #2729: Stuck when compiling XMonad.StackSet in xmonad 0.9 (hackage version) ---------------------------------+------------------------------------------ Reporter: mnislaih | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.11 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12 branch Comment: Thanks for the report. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 27 09:04:39 2008 From: trac at galois.com (GHC) Date: Thu Nov 27 08:58:19 2008 Subject: [GHC] #2736: Add bool to Data.Bool In-Reply-To: <044.43d5c08c7d76644c4804eee606da70ae@localhost> References: <044.43d5c08c7d76644c4804eee606da70ae@localhost> Message-ID: <053.f9f366918e958d966dc088b577a33133@localhost> #2736: Add bool to Data.Bool ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: libraries/base | Version: Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown Old description: > The function either is in Data.Either and maybe is in Data.Maybe. The > function if' is a referenced function in the point-free module, but it > doesn't exist, and if is a keyword, not a function. Since Data.Bool is a > library module, and it fits the form of the two modules mentioned > earlier, it should have a function bool. Its exact form may need more > discussion, but in keeping with the other two, I propose: > > bool :: a -> a -> Bool -> a > bool false true False = false > bool false true True = true > > (proposed by BMeph, 2 November 2008) New description: The function either is in Data.Either and maybe is in Data.Maybe. The function if' is a referenced function in the point-free module, but it doesn't exist, and if is a keyword, not a function. Since Data.Bool is a library module, and it fits the form of the two modules mentioned earlier, it should have a function bool. Its exact form may need more discussion, but in keeping with the other two, I propose: {{{ bool :: a -> a -> Bool -> a bool false true False = false bool false true True = true }}} (proposed by BMeph, 2 November 2008) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 27 09:05:25 2008 From: trac at galois.com (GHC) Date: Thu Nov 27 08:59:05 2008 Subject: [GHC] #2736: Add bool to Data.Bool In-Reply-To: <044.43d5c08c7d76644c4804eee606da70ae@localhost> References: <044.43d5c08c7d76644c4804eee606da70ae@localhost> Message-ID: <053.1564e5164e443e525a795ba1ff75e583@localhost> #2736: Add bool to Data.Bool ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * milestone: => Not GHC -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 27 09:07:10 2008 From: trac at galois.com (GHC) Date: Thu Nov 27 09:00:53 2008 Subject: [GHC] #2737: add :tracelocal to ghci debugger to trace only the expressions in a given function In-Reply-To: <046.6f550a6976a51e80c9bdb4b574c0fab8@localhost> References: <046.6f550a6976a51e80c9bdb4b574c0fab8@localhost> Message-ID: <055.8a427bff53858596a790fe64d3c2c577@localhost> #2737: add :tracelocal to ghci debugger to trace only the expressions in a given function ---------------------------------+------------------------------------------ Reporter: phercek | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: GHCi | Version: 6.8.3 Severity: normal | Resolution: Keywords: debugger | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 27 09:10:24 2008 From: trac at galois.com (GHC) Date: Thu Nov 27 09:04:06 2008 Subject: [GHC] #2739: GHC API crashes on template haskell splices In-Reply-To: <044.3bac7d34665c04ceca674c8a12436d56@localhost> References: <044.3bac7d34665c04ceca674c8a12436d56@localhost> Message-ID: <053.3288e42264984b53ad0673ca0f0c422b@localhost> #2739: GHC API crashes on template haskell splices ---------------------------------+------------------------------------------ Reporter: waern | Owner: nominolo Type: bug | Status: assigned Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * milestone: => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 27 09:13:58 2008 From: trac at galois.com (GHC) Date: Thu Nov 27 09:07:52 2008 Subject: [GHC] #2750: Bug in Data.Generics In-Reply-To: <044.cd214fdda0ee80175fd522907e79182f@localhost> References: <044.cd214fdda0ee80175fd522907e79182f@localhost> Message-ID: <053.824bbf07f90a64f77db0c88de73542f7@localhost> #2750: Bug in Data.Generics ---------------------------------+------------------------------------------ Reporter: guest | Owner: jose magalhaes Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * milestone: => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 27 09:19:58 2008 From: trac at galois.com (GHC) Date: Thu Nov 27 09:13:39 2008 Subject: [GHC] #2755: Broken link in GHC API documentation In-Reply-To: <044.a40779a08e2a4155adb6f037645bf002@localhost> References: <044.a40779a08e2a4155adb6f037645bf002@localhost> Message-ID: <053.e8bfcf90bbf7267d480a5d7aa7235ea2@localhost> #2755: Broken link in GHC API documentation ---------------------------------+------------------------------------------ Reporter: waern | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Documentation | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.2 Comment: I'm not sure if this is what you mean, but it looks like all the ghc package docs are using absolute paths rather than relative paths. We probably need to copy something from `libraries/Makefile` to `compiler/Makefile`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 27 09:24:51 2008 From: trac at galois.com (GHC) Date: Thu Nov 27 09:18:40 2008 Subject: [GHC] #2759: Data.Generics.ConstrRep isn't general enough In-Reply-To: <044.ed7d09d66854fb1616fb1d1343b2d811@localhost> References: <044.ed7d09d66854fb1616fb1d1343b2d811@localhost> Message-ID: <053.014d9a3bf354fee24c20fe56a0a45565@localhost> #2759: Data.Generics.ConstrRep isn't general enough ----------------------------------+----------------------------------------- Reporter: guest | Owner: jose magalhaes Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: libraries (other) | Version: 6.10.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by igloo): * component: Compiler => libraries (other) * milestone: => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 27 09:25:07 2008 From: trac at galois.com (GHC) Date: Thu Nov 27 09:18:56 2008 Subject: [GHC] #2760: Data.Generics.Basics.mkNoreptype spelled wrong In-Reply-To: <044.b3884d30a8391ab9f46e5542669e8ee1@localhost> References: <044.b3884d30a8391ab9f46e5542669e8ee1@localhost> Message-ID: <053.5a1acf39584981319d6145607bd4830a@localhost> #2760: Data.Generics.Basics.mkNoreptype spelled wrong ----------------------------------+----------------------------------------- Reporter: guest | Owner: jose magalhaes Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: libraries (other) | Version: 6.10.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by igloo): * component: Compiler => libraries (other) * milestone: => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 27 09:26:34 2008 From: trac at galois.com (GHC) Date: Thu Nov 27 09:20:16 2008 Subject: [GHC] #2763: while installing cabal from darcs, 1.6.0.1 and 1.4.0.2 In-Reply-To: <044.967654beccd358d1d0ac92f7259473da@localhost> References: <044.967654beccd358d1d0ac92f7259473da@localhost> Message-ID: <053.27ae61ff4383f1e9935bf12d6a553aa3@localhost> #2763: while installing cabal from darcs, 1.6.0.1 and 1.4.0.2 ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: cabal ghc ubuntu | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown Old description: > I can't build cabal 1.4.0.2, cabal from darcs and cabal 1.6.0.1 > > Running ubuntu 8.04, running ghc that comes with it > > root@burn:~/projects/haskell/Cabal-1.4.0.2# ghc -v > Glasgow Haskell Compiler, Version 6.8.2, for Haskell 98, stage 2 booted > by GHC version 6.8.2 > Using package config file: /usr/lib/ghc-6.8.2/package.conf > Using package config file: > /home/abez/.ghc/x86_64-linux-6.8.2/package.conf > hiding package mtl-1.1.0.0 to avoid conflict with later version > mtl-1.1.0.1 > wired-in package base mapped to base-3.0.1.0 > wired-in package rts mapped to rts-1.0 > wired-in package haskell98 mapped to haskell98-1.0.1.0 > wired-in package template-haskell mapped to template-haskell-2.2.0.0 > wired-in package ndp not found. > Hsc static flags: -static > *** Deleting temp files: > Deleting: > *** Deleting temp dirs: > Deleting: > ghc-6.8.2: no input files > Usage: For basic information, try the `--help' option. > root@burn:~/projects/haskell/Cabal-1.4.0.2# ghc -v > Glasgow Haskell Compiler, Version 6.8.2, for Haskell 98, stage 2 booted > by GHC version 6.8.2 > Using package config file: /usr/lib/ghc-6.8.2/package.conf > Using package config file: > /home/abez/.ghc/x86_64-linux-6.8.2/package.conf > hiding package mtl-1.1.0.0 to avoid conflict with later version > mtl-1.1.0.1 > wired-in package base mapped to base-3.0.1.0 > wired-in package rts mapped to rts-1.0 > wired-in package haskell98 mapped to haskell98-1.0.1.0 > wired-in package template-haskell mapped to template-haskell-2.2.0.0 > wired-in package ndp not found. > Hsc static flags: -static > *** Deleting temp files: > Deleting: > *** Deleting temp dirs: > Deleting: > ghc-6.8.2: no input files > Usage: For basic information, try the `--help' option. > root@burn:~/projects/haskell/Cabal-1.4.0.2# uname -a > Linux burn 2.6.24-19-generic #1 SMP Wed Aug 20 17:53:40 UTC 2008 x86_64 > GNU/Linux > > > root@burn:~/projects/haskell/Cabal-1.4.0.2# ./Setup build > Preprocessing library Cabal-1.4.0.2... > Building Cabal-1.4.0.2... > [13 of 45] Compiling Distribution.Simple.Utils ( > Distribution/Simple/Utils.hs, dist/build/Distribution/Simple/Utils.o ) > ghc-6.8.2: panic! (the 'impossible' happened) > (GHC version 6.8.2 for x86_64-unknown-linux): > applyTypeToArgs > unix-2.3.0.0:System.Posix.Signals.a38{v rBu} [gid] > (unix-2.3.0.0:System.Posix.Signals.a5{v rBt} [gid] > `cast` (base:GHC.Prim.sym{(w) tc 34v} > (base:Foreign.C.Types.:CoCInt{tc ryy}) > :: base:GHC.Int.Int32{tc 3V} > ~ > base:Foreign.C.Types.CInt{tc rz9})) > unix-2.3.0.0:System.Posix.Signals.Ignore{v rBs} [gid] > (base:Data.Maybe.Nothing{v r6a} [gid] > @ unix-2.3.0.0:System.Posix.Signals.SignalSet{tc rBr}) > eta{v a2Rl} [lid] > (# base:GHC.Prim.State#{(w) tc 32q} > base:GHC.Prim.RealWorld{(w) tc 31E}, > unix-2.3.0.0:System.Posix.Signals.SignalSet{tc rBr} #) > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > Another one: > @burn:~/projects/haskell/cabal$ ./Setup build > Preprocessing library Cabal-1.6.0.1... > Building Cabal-1.6.0.1... > [ 1 of 50] Compiling Distribution.Simple.GHC.Makefile ( > Distribution/Simple/GHC/Makefile.hs, > dist/build/Distribution/Simple/GHC/Makefile.o ) > [ 2 of 50] Compiling Distribution.Compat.Permissions ( > Distribution/Compat/Permissions.hs, > dist/build/Distribution/Compat/Permissions.o ) > [ 3 of 50] Compiling Distribution.Compat.Exception ( > Distribution/Compat/Exception.hs, > dist/build/Distribution/Compat/Exception.o ) > [ 4 of 50] Compiling Distribution.Compat.TempFile ( > Distribution/Compat/TempFile.hs, > dist/build/Distribution/Compat/TempFile.o ) > [ 5 of 50] Compiling Distribution.GetOpt ( Distribution/GetOpt.hs, > dist/build/Distribution/GetOpt.o ) > [ 6 of 50] Compiling Distribution.Compat.ReadP ( > Distribution/Compat/ReadP.hs, dist/build/Distribution/Compat/ReadP.o ) > [ 7 of 50] Compiling Distribution.Text ( Distribution/Text.hs, > dist/build/Distribution/Text.o ) > [ 8 of 50] Compiling Distribution.Version ( Distribution/Version.hs, > dist/build/Distribution/Version.o ) > [ 9 of 50] Compiling Language.Haskell.Extension ( > Language/Haskell/Extension.hs, dist/build/Language/Haskell/Extension.o ) > [10 of 50] Compiling Distribution.System ( Distribution/System.hs, > dist/build/Distribution/System.o ) > [11 of 50] Compiling Distribution.Simple.PreProcess.Unlit ( > Distribution/Simple/PreProcess/Unlit.hs, > dist/build/Distribution/Simple/PreProcess/Unlit.o ) > [12 of 50] Compiling Distribution.ReadE ( Distribution/ReadE.hs, > dist/build/Distribution/ReadE.o ) > [13 of 50] Compiling Distribution.Verbosity ( Distribution/Verbosity.hs, > dist/build/Distribution/Verbosity.o ) > [14 of 50] Compiling Distribution.Package ( Distribution/Package.hs, > dist/build/Distribution/Package.o ) > [15 of 50] Compiling Distribution.ModuleName ( > Distribution/ModuleName.hs, dist/build/Distribution/ModuleName.o ) > [16 of 50] Compiling Distribution.Simple.Utils ( > Distribution/Simple/Utils.hs, dist/build/Distribution/Simple/Utils.o ) > ghc-6.8.2: panic! (the 'impossible' happened) > (GHC version 6.8.2 for x86_64-unknown-linux): > applyTypeToArgs > unix-2.3.0.0:System.Posix.Signals.a38{v roIc} [gid] > (unix-2.3.0.0:System.Posix.Signals.a5{v roIb} [gid] > `cast` (base:GHC.Prim.sym{(w) tc 34v} > (base:Foreign.C.Types.:CoCInt{tc r1dN}) > :: base:GHC.Int.Int32{tc 3V} > ~ > base:Foreign.C.Types.CInt{tc r17X})) > unix-2.3.0.0:System.Posix.Signals.Ignore{v roIa} [gid] > (base:Data.Maybe.Nothing{v r6E} [gid] > @ unix-2.3.0.0:System.Posix.Signals.SignalSet{tc roI9}) > eta{v apPk} [lid] > (# base:GHC.Prim.State#{(w) tc 32q} > base:GHC.Prim.RealWorld{(w) tc 31E}, > unix-2.3.0.0:System.Posix.Signals.SignalSet{tc roI9} #) > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug New description: I can't build cabal 1.4.0.2, cabal from darcs and cabal 1.6.0.1 Running ubuntu 8.04, running ghc that comes with it {{{ root@burn:~/projects/haskell/Cabal-1.4.0.2# ghc -v Glasgow Haskell Compiler, Version 6.8.2, for Haskell 98, stage 2 booted by GHC version 6.8.2 Using package config file: /usr/lib/ghc-6.8.2/package.conf Using package config file: /home/abez/.ghc/x86_64-linux-6.8.2/package.conf hiding package mtl-1.1.0.0 to avoid conflict with later version mtl-1.1.0.1 wired-in package base mapped to base-3.0.1.0 wired-in package rts mapped to rts-1.0 wired-in package haskell98 mapped to haskell98-1.0.1.0 wired-in package template-haskell mapped to template-haskell-2.2.0.0 wired-in package ndp not found. Hsc static flags: -static *** Deleting temp files: Deleting: *** Deleting temp dirs: Deleting: ghc-6.8.2: no input files Usage: For basic information, try the `--help' option. root@burn:~/projects/haskell/Cabal-1.4.0.2# ghc -v Glasgow Haskell Compiler, Version 6.8.2, for Haskell 98, stage 2 booted by GHC version 6.8.2 Using package config file: /usr/lib/ghc-6.8.2/package.conf Using package config file: /home/abez/.ghc/x86_64-linux-6.8.2/package.conf hiding package mtl-1.1.0.0 to avoid conflict with later version mtl-1.1.0.1 wired-in package base mapped to base-3.0.1.0 wired-in package rts mapped to rts-1.0 wired-in package haskell98 mapped to haskell98-1.0.1.0 wired-in package template-haskell mapped to template-haskell-2.2.0.0 wired-in package ndp not found. Hsc static flags: -static *** Deleting temp files: Deleting: *** Deleting temp dirs: Deleting: ghc-6.8.2: no input files Usage: For basic information, try the `--help' option. root@burn:~/projects/haskell/Cabal-1.4.0.2# uname -a Linux burn 2.6.24-19-generic #1 SMP Wed Aug 20 17:53:40 UTC 2008 x86_64 GNU/Linux }}} {{{ root@burn:~/projects/haskell/Cabal-1.4.0.2# ./Setup build Preprocessing library Cabal-1.4.0.2... Building Cabal-1.4.0.2... [13 of 45] Compiling Distribution.Simple.Utils ( Distribution/Simple/Utils.hs, dist/build/Distribution/Simple/Utils.o ) ghc-6.8.2: panic! (the 'impossible' happened) (GHC version 6.8.2 for x86_64-unknown-linux): applyTypeToArgs unix-2.3.0.0:System.Posix.Signals.a38{v rBu} [gid] (unix-2.3.0.0:System.Posix.Signals.a5{v rBt} [gid] `cast` (base:GHC.Prim.sym{(w) tc 34v} (base:Foreign.C.Types.:CoCInt{tc ryy}) :: base:GHC.Int.Int32{tc 3V} ~ base:Foreign.C.Types.CInt{tc rz9})) unix-2.3.0.0:System.Posix.Signals.Ignore{v rBs} [gid] (base:Data.Maybe.Nothing{v r6a} [gid] @ unix-2.3.0.0:System.Posix.Signals.SignalSet{tc rBr}) eta{v a2Rl} [lid] (# base:GHC.Prim.State#{(w) tc 32q} base:GHC.Prim.RealWorld{(w) tc 31E}, unix-2.3.0.0:System.Posix.Signals.SignalSet{tc rBr} #) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Another one: {{{ @burn:~/projects/haskell/cabal$ ./Setup build Preprocessing library Cabal-1.6.0.1... Building Cabal-1.6.0.1... [ 1 of 50] Compiling Distribution.Simple.GHC.Makefile ( Distribution/Simple/GHC/Makefile.hs, dist/build/Distribution/Simple/GHC/Makefile.o ) [ 2 of 50] Compiling Distribution.Compat.Permissions ( Distribution/Compat/Permissions.hs, dist/build/Distribution/Compat/Permissions.o ) [ 3 of 50] Compiling Distribution.Compat.Exception ( Distribution/Compat/Exception.hs, dist/build/Distribution/Compat/Exception.o ) [ 4 of 50] Compiling Distribution.Compat.TempFile ( Distribution/Compat/TempFile.hs, dist/build/Distribution/Compat/TempFile.o ) [ 5 of 50] Compiling Distribution.GetOpt ( Distribution/GetOpt.hs, dist/build/Distribution/GetOpt.o ) [ 6 of 50] Compiling Distribution.Compat.ReadP ( Distribution/Compat/ReadP.hs, dist/build/Distribution/Compat/ReadP.o ) [ 7 of 50] Compiling Distribution.Text ( Distribution/Text.hs, dist/build/Distribution/Text.o ) [ 8 of 50] Compiling Distribution.Version ( Distribution/Version.hs, dist/build/Distribution/Version.o ) [ 9 of 50] Compiling Language.Haskell.Extension ( Language/Haskell/Extension.hs, dist/build/Language/Haskell/Extension.o ) [10 of 50] Compiling Distribution.System ( Distribution/System.hs, dist/build/Distribution/System.o ) [11 of 50] Compiling Distribution.Simple.PreProcess.Unlit ( Distribution/Simple/PreProcess/Unlit.hs, dist/build/Distribution/Simple/PreProcess/Unlit.o ) [12 of 50] Compiling Distribution.ReadE ( Distribution/ReadE.hs, dist/build/Distribution/ReadE.o ) [13 of 50] Compiling Distribution.Verbosity ( Distribution/Verbosity.hs, dist/build/Distribution/Verbosity.o ) [14 of 50] Compiling Distribution.Package ( Distribution/Package.hs, dist/build/Distribution/Package.o ) [15 of 50] Compiling Distribution.ModuleName ( Distribution/ModuleName.hs, dist/build/Distribution/ModuleName.o ) [16 of 50] Compiling Distribution.Simple.Utils ( Distribution/Simple/Utils.hs, dist/build/Distribution/Simple/Utils.o ) ghc-6.8.2: panic! (the 'impossible' happened) (GHC version 6.8.2 for x86_64-unknown-linux): applyTypeToArgs unix-2.3.0.0:System.Posix.Signals.a38{v roIc} [gid] (unix-2.3.0.0:System.Posix.Signals.a5{v roIb} [gid] `cast` (base:GHC.Prim.sym{(w) tc 34v} (base:Foreign.C.Types.:CoCInt{tc r1dN}) :: base:GHC.Int.Int32{tc 3V} ~ base:Foreign.C.Types.CInt{tc r17X})) unix-2.3.0.0:System.Posix.Signals.Ignore{v roIa} [gid] (base:Data.Maybe.Nothing{v r6E} [gid] @ unix-2.3.0.0:System.Posix.Signals.SignalSet{tc roI9}) eta{v apPk} [lid] (# base:GHC.Prim.State#{(w) tc 32q} base:GHC.Prim.RealWorld{(w) tc 31E}, unix-2.3.0.0:System.Posix.Signals.SignalSet{tc roI9} #) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 27 09:37:35 2008 From: trac at galois.com (GHC) Date: Thu Nov 27 09:31:23 2008 Subject: [GHC] #2765: unsetenv not found under Solaris 8 when building ghc-6.10.1 In-Reply-To: <045.123eb53c80ae5471f437c79b85fa80f5@localhost> References: <045.123eb53c80ae5471f437c79b85fa80f5@localhost> Message-ID: <054.3491ce64956e7dfa2d9f9c2e25954c78@localhost> #2765: unsetenv not found under Solaris 8 when building ghc-6.10.1 -------------------------+-------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: sparc | -------------------------+-------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.2 Comment: It's in libc on Linux. My manpage says `CONFORMING TO 4.3BSD, POSIX.1-2001`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 27 09:37:49 2008 From: trac at galois.com (GHC) Date: Thu Nov 27 09:31:32 2008 Subject: [GHC] #2766: Infix type operators are presented with incorrect syntax in ghci In-Reply-To: <048.ede65a0a07b7bb10f4f547601c287a56@localhost> References: <048.ede65a0a07b7bb10f4f547601c287a56@localhost> Message-ID: <057.cea203e54ec00a0a68cb28060bf5281c@localhost> #2766: Infix type operators are presented with incorrect syntax in ghci -----------------------------------+---------------------------------------- Reporter: EyalLotem | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.2 Component: GHCi | Version: 6.10.1 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: ghci/scripts/T2766 | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------+---------------------------------------- Changes (by igloo): * milestone: => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 27 09:37:55 2008 From: trac at galois.com (GHC) Date: Thu Nov 27 09:31:43 2008 Subject: [GHC] #2584: Pretty printing of types with HsDocTy goes wrong In-Reply-To: <051.bf512b6956b3ff06fbdabc8d35b6e47d@localhost> References: <051.bf512b6956b3ff06fbdabc8d35b6e47d@localhost> Message-ID: <060.d7c7054d1fd3cc97c5df552e27a62376@localhost> #2584: Pretty printing of types with HsDocTy goes wrong ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: waern Type: bug | Status: assigned Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.9 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by NeilMitchell): I have now worked around this bug in Hoogle, in quite a clean way, so this no longer effects development builds of Hoogle. If I had been able to use SYB the workaround would have been 15x shorter and much more robust... I did track the bug down somewhat in GHC - see compiler\hsSyn\HsTypes.lhs, line 379: {{{ ppr_mono_ty _ (HsDocTy ty doc) = ppr ty <+> ppr (unLoc doc) }}} All the other ppr_mono_ty functions have a maybeParen call first, which is missing here. You'll need to figure out the relative priorities etc. Or perhaps just remove HsDocTy's when pretty printing? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 27 09:43:14 2008 From: trac at galois.com (GHC) Date: Thu Nov 27 09:37:05 2008 Subject: [GHC] #2767: Type family bug ? In-Reply-To: <043.5d7b08e8b12f70310b2c5608326cbdc1@localhost> References: <043.5d7b08e8b12f70310b2c5608326cbdc1@localhost> Message-ID: <052.fb78566e380f966b0dd3f29e785e63fe@localhost> #2767: Type family bug ? ----------------------------------------+----------------------------------- Reporter: test | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler (Type checker) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------+----------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 27 09:43:27 2008 From: trac at galois.com (GHC) Date: Thu Nov 27 09:37:13 2008 Subject: [GHC] #2769: Export mapAccumR from Data.Map, Data.IntMap In-Reply-To: <047.6884ccd8725fc9653ca909dcd5164d50@localhost> References: <047.6884ccd8725fc9653ca909dcd5164d50@localhost> Message-ID: <056.3b09950a0dbf389810e21dbbb84d0820@localhost> #2769: Export mapAccumR from Data.Map, Data.IntMap ----------------------------------+----------------------------------------- Reporter: Deewiant | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.11 Severity: normal | Resolution: Keywords: containers | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => Not GHC -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 27 09:45:54 2008 From: trac at galois.com (GHC) Date: Thu Nov 27 09:39:37 2008 Subject: [GHC] #2819: Bad example code in documentation of Control.Exception.catch Message-ID: <043.8ffe86f1c4d9c257331fb2a6c7fabfed@localhost> #2819: Bad example code in documentation of Control.Exception.catch -----------------------------+---------------------------------------------- Reporter: mafo | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 6.10.1 | Severity: trivial Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- There is a bug in the documentation of Control.Exception.catch [http://haskell.org/ghc/docs/latest/html/libraries/base/Control- Exception.html#4] If one uses System.IO.openFile then the example code shown in the documentation does not typecheck. The example code is: {{{ catch (openFile f ReadMode) (\e -> hPutStr stderr ("Couldn't open "++f++": " ++ show e)) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 27 09:48:18 2008 From: trac at galois.com (GHC) Date: Thu Nov 27 09:42:00 2008 Subject: [GHC] #2770: Missing check that C compiler is C99 compatible In-Reply-To: <045.e59ec55e01d8ef8d16caa02433e3c648@localhost> References: <045.e59ec55e01d8ef8d16caa02433e3c648@localhost> Message-ID: <054.d261b9992d516b069b58a0883f8b65af@localhost> #2770: Missing check that C compiler is C99 compatible -----------------------------+---------------------------------------------- Reporter: jputcu | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Build System | Version: 6.10.1 Severity: blocker | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -----------------------------+---------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.2 Comment: Thanks for the report. We should work out exactly what we do require, and correct the configure script. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 27 09:51:53 2008 From: trac at galois.com (GHC) Date: Thu Nov 27 09:45:40 2008 Subject: [GHC] #2773: Documentation mentions deprecated flags In-Reply-To: <044.8fbd9fa5930a794c5be22803687b7d92@localhost> References: <044.8fbd9fa5930a794c5be22803687b7d92@localhost> Message-ID: <053.b82c124acba4c17277c5f4b747b48427@localhost> #2773: Documentation mentions deprecated flags ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Documentation | Version: 6.10.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.2 Comment: Thanks for the report -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 27 09:58:20 2008 From: trac at galois.com (GHC) Date: Thu Nov 27 09:52:02 2008 Subject: [GHC] #2774: sIsReadable and sIsWritable return true after socket is closed. In-Reply-To: <047.480c8e606a3bfd77cd4272bd9432134f@localhost> References: <047.480c8e606a3bfd77cd4272bd9432134f@localhost> Message-ID: <056.e38397d7b3186ce980924236183b82fd@localhost> #2774: sIsReadable and sIsWritable return true after socket is closed. ----------------------------------+----------------------------------------- Reporter: felixmar | Owner: Type: bug | Status: new Priority: normal | Milestone: Not GHC Component: libraries/network | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => Not GHC -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 27 10:32:39 2008 From: trac at galois.com (GHC) Date: Thu Nov 27 10:26:24 2008 Subject: [GHC] #2775: Type Family panic In-Reply-To: <044.cf027f74305f326c967336b8f3c587bd@localhost> References: <044.cf027f74305f326c967336b8f3c587bd@localhost> Message-ID: <053.0ec8a3686ccccaf9b0f86664795d995d@localhost> #2775: Type Family panic ---------------------------------+------------------------------------------ Reporter: camio | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: blocker | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 27 10:33:47 2008 From: trac at galois.com (GHC) Date: Thu Nov 27 10:27:33 2008 Subject: [GHC] #2776: Document -pgmL (Use cmd as the literate pre-processor) In-Reply-To: <047.3b71ad52e13d9dd964c5cec1ca82c2e0@localhost> References: <047.3b71ad52e13d9dd964c5cec1ca82c2e0@localhost> Message-ID: <056.2118abb67d1782aa3ab8601de414331f@localhost> #2776: Document -pgmL (Use cmd as the literate pre-processor) ---------------------------------+------------------------------------------ Reporter: Syzygies | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Documentation | Version: 6.10.1 Severity: minor | Resolution: Keywords: pgmL literate | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 27 10:34:04 2008 From: trac at galois.com (GHC) Date: Thu Nov 27 10:27:45 2008 Subject: [GHC] #2784: Cannot call connect with a socket that is already bound. In-Reply-To: <047.de4c3c5f634fbec7d0b7644c39e5f764@localhost> References: <047.de4c3c5f634fbec7d0b7644c39e5f764@localhost> Message-ID: <056.f83078e41f6005aa3f7eb4b1a6242e17@localhost> #2784: Cannot call connect with a socket that is already bound. ----------------------------------+----------------------------------------- Reporter: felixmar | Owner: Type: bug | Status: new Priority: normal | Milestone: Not GHC Component: libraries/network | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => Not GHC -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 27 10:35:56 2008 From: trac at galois.com (GHC) Date: Thu Nov 27 10:29:37 2008 Subject: [GHC] #2785: Memory leakage with socket benchmark program In-Reply-To: <047.470588859e52453dab1b67a6015374ad@localhost> References: <047.470588859e52453dab1b67a6015374ad@localhost> Message-ID: <056.1ecd8ed5618a857a9e5d6c4eba4ab633@localhost> #2785: Memory leakage with socket benchmark program -----------------------------------------+---------------------------------- Reporter: felixmar | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Runtime System | Version: 6.10.1 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -----------------------------------------+---------------------------------- Changes (by igloo): * difficulty: => Unknown * type: bug => run-time performance bug * milestone: => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 27 10:53:38 2008 From: trac at galois.com (GHC) Date: Thu Nov 27 10:47:19 2008 Subject: [GHC] #2795: The Network.Socket library does not take into account that the bits in the network are sent as big enddian. In-Reply-To: <044.6c385a1093d32284095f65013344ce56@localhost> References: <044.6c385a1093d32284095f65013344ce56@localhost> Message-ID: <053.ed70cc62814a941f648148685eb91557@localhost> #2795: The Network.Socket library does not take into account that the bits in the network are sent as big enddian. -----------------------------------------------------------------------+---- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/network | Version: Severity: major | Resolution: invalid Keywords: socket port number big-enddian little-enddian conflict | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -----------------------------------------------------------------------+---- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: Agreed, not a bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 27 10:55:16 2008 From: trac at galois.com (GHC) Date: Thu Nov 27 10:48:56 2008 Subject: [GHC] #2797: ghci stack overflows when ghc does not In-Reply-To: <053.b5bed6c883dfb7d157e5092dcf2242ee@localhost> References: <053.b5bed6c883dfb7d157e5092dcf2242ee@localhost> Message-ID: <062.c68987ef20fb4dd6f298f3795def96af@localhost> #2797: ghci stack overflows when ghc does not -----------------------------------------+---------------------------------- Reporter: TristanAllwood | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.10.2 Component: GHCi | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Changes (by igloo): * difficulty: => Unknown * type: bug => run-time performance bug * milestone: => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 27 11:00:09 2008 From: trac at galois.com (GHC) Date: Thu Nov 27 10:53:49 2008 Subject: [GHC] #2798: Enable "rec" keyword when RecursiveDo is enabled? In-Reply-To: <047.c01de827ffb9a59aafb72de68ac54369@localhost> References: <047.c01de827ffb9a59aafb72de68ac54369@localhost> Message-ID: <056.d34470a88bc788902a481c75c9a29e75@localhost> #2798: Enable "rec" keyword when RecursiveDo is enabled? ---------------------------------+------------------------------------------ Reporter: nominolo | Owner: Type: task | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.11 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * milestone: => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 27 11:00:33 2008 From: trac at galois.com (GHC) Date: Thu Nov 27 10:54:17 2008 Subject: [GHC] #2799: Panic (core lint failure) with GADTs, GHC 6.10.1 In-Reply-To: <047.02178742ef8c8010079728a64ae52ee1@localhost> References: <047.02178742ef8c8010079728a64ae52ee1@localhost> Message-ID: <056.aec32a107994de69a63661a64db1ef62@localhost> #2799: Panic (core lint failure) with GADTs, GHC 6.10.1 -----------------------------------------------+---------------------------- Reporter: alexey_r | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: typecheck/should_compile/T2799 | Os: Windows Architecture: x86 | -----------------------------------------------+---------------------------- Changes (by igloo): * milestone: => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 27 11:07:09 2008 From: trac at galois.com (GHC) Date: Thu Nov 27 11:00:48 2008 Subject: [GHC] #2800: deprecated OPTIONS flag warnings generated during dep chasing? In-Reply-To: <045.0e85c856f9a219b317597d25eed9584a@localhost> References: <045.0e85c856f9a219b317597d25eed9584a@localhost> Message-ID: <054.9d99b6cd9f5568de347576e464e3f7d7@localhost> #2800: deprecated OPTIONS flag warnings generated during dep chasing? ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 27 11:08:36 2008 From: trac at galois.com (GHC) Date: Thu Nov 27 11:02:24 2008 Subject: [GHC] #1074: -fwarn-unused-imports complains about wrong import In-Reply-To: <044.4c9395b3e6188ac7c118df9e58cf802d@localhost> References: <044.4c9395b3e6188ac7c118df9e58cf802d@localhost> Message-ID: <053.c21a09c8ef5c095de70362fb4fb2eda8@localhost> #1074: -fwarn-unused-imports complains about wrong import ---------------------------------+------------------------------------------ Reporter: guest | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.6 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by guest): * cc: gwern0@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 27 11:11:40 2008 From: trac at galois.com (GHC) Date: Thu Nov 27 11:05:20 2008 Subject: [GHC] #2802: Download bundle for Linux libedit2 has reference to libedit0 in editline lib In-Reply-To: <053.d54bc1052404d450eba42b9c4b28a824@localhost> References: <053.d54bc1052404d450eba42b9c4b28a824@localhost> Message-ID: <062.d956bd8ff4ec4976bfb6f601400fb910@localhost> #2802: Download bundle for Linux libedit2 has reference to libedit0 in editline lib -------------------------------+-------------------------------------------- Reporter: Ashley Yakeley | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 6.10.1 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: I don't think configure checking for it would be useful; it can't install a non-libedit ghc if it finds you don't have libedit. And it's hard for configure to give advice for such an OS/distro-specific problem. Also, you get a working GHC regardless; you just can't link programs that depend on the editline package. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 27 11:17:44 2008 From: trac at galois.com (GHC) Date: Thu Nov 27 11:11:24 2008 Subject: [GHC] #2820: GADT code from RepLib causes panic! Message-ID: <051.9b0310aa65e2b3bc01899bcf36ca6482@localhost> #2820: GADT code from RepLib causes panic! -------------------------+-------------------------------------------------- Reporter: ben.kavanagh | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: panic, GADT | Testcase: Os: Linux | Architecture: x86 -------------------------+-------------------------------------------------- While compiling RepLib generics library I encountered a ghc panic. I have isolated the failure to very small example that does some simple computation over a heterogenous list. I have attached the following files RepMinimal.hs. This is the problem reduced to small example. The function that seems to cause the problem is "badFunction". If I remove this function the file compiles. RepSmall.hs. This is a trimmed down core of RepLib where the original problem occurs. I only include it if someone looking at the bug wants to know what this code was used for. below is the output of ghc run. ---------------------- [ben@lapdog RepLib]$ ghc -v RepCombined3.hs Glasgow Haskell Compiler, Version 6.10.1, for Haskell 98, stage 2 booted by GHC version 6.10.1 Using package config file: /usr/lib/ghc-6.10.1/./package.conf hiding package base-3.0.3.0 to avoid conflict with later version base-4.0.0.0 wired-in package ghc-prim mapped to ghc-prim-0.1.0.0 wired-in package integer mapped to integer-0.1.0.0 wired-in package base mapped to base-4.0.0.0 wired-in package rts mapped to rts-1.0 wired-in package haskell98 mapped to haskell98-1.0.1.0 wired-in package syb mapped to syb-0.1.0.0 wired-in package template-haskell mapped to template-haskell-2.3.0.0 wired-in package dph-seq mapped to dph-seq-0.3 wired-in package dph-par mapped to dph-par-0.3 Hsc static flags: -static Created temporary directory: /tmp/ghc3284_0 *** Checking old interface for main:Data.RepLib.RepCombined: *** Parser: *** Renamer/typechecker: *** Desugar: Result size = 176 *** Simplify: Result size = 283 Result size = 283 *** Tidy Core: Result size = 283 *** CorePrep: Result size = 465 *** Stg2Stg: *** CodeGen: *** CodeOutput: *** Deleting temp files: Deleting: /tmp/ghc3284_0/ghc3284_0.s *** Deleting temp dirs: Deleting: /tmp/ghc3284_0 ghc: panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-unknown-linux): initC: srt_lbl Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug ---------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 27 11:19:44 2008 From: trac at galois.com (GHC) Date: Thu Nov 27 11:13:28 2008 Subject: [GHC] #2803: bring full top level of a module in scope when a breakpoint is hit in the module In-Reply-To: <046.652e8c43925e61f6025ee776347b88e6@localhost> References: <046.652e8c43925e61f6025ee776347b88e6@localhost> Message-ID: <055.b064abf64fcc29892181c062ea4edb1f@localhost> #2803: bring full top level of a module in scope when a breakpoint is hit in the module ---------------------------------+------------------------------------------ Reporter: phercek | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: GHCi | Version: 6.8.3 Severity: normal | Resolution: Keywords: debugger | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 27 11:22:30 2008 From: trac at galois.com (GHC) Date: Thu Nov 27 11:16:12 2008 Subject: [GHC] #2805: Test ffi009(ghci) fails on PPC Mac OS X In-Reply-To: <050.49e5533b97232a9f431fe6cab3b29ebd@localhost> References: <050.49e5533b97232a9f431fe6cab3b29ebd@localhost> Message-ID: <059.154ec0c1f71462107b3d953ab8063a68@localhost> #2805: Test ffi009(ghci) fails on PPC Mac OS X -----------------------------+---------------------------------------------- Reporter: thorkilnaur | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: ffi009(ghci) | Os: MacOS X Architecture: powerpc | -----------------------------+---------------------------------------------- Changes (by igloo): * milestone: => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 27 11:22:46 2008 From: trac at galois.com (GHC) Date: Thu Nov 27 11:16:26 2008 Subject: [GHC] #2808: createDirectoryIfMissing should be atomic In-Reply-To: <046.21f1a9c564db33e6ee9ef7b6ede88c51@localhost> References: <046.21f1a9c564db33e6ee9ef7b6ede88c51@localhost> Message-ID: <055.100c226c9e826906c144da3d647a14f8@localhost> #2808: createDirectoryIfMissing should be atomic ------------------------------------+--------------------------------------- Reporter: EricKow | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: libraries/directory | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ------------------------------------+--------------------------------------- Changes (by igloo): * milestone: => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 27 11:22:50 2008 From: trac at galois.com (GHC) Date: Thu Nov 27 11:16:32 2008 Subject: [GHC] #2820: GADT code from RepLib causes panic! In-Reply-To: <051.9b0310aa65e2b3bc01899bcf36ca6482@localhost> References: <051.9b0310aa65e2b3bc01899bcf36ca6482@localhost> Message-ID: <060.7ee90ab9d595779f827edaa4f575005c@localhost> #2820: GADT code from RepLib causes panic! -----------------------------+---------------------------------------------- Reporter: ben.kavanagh | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: duplicate Keywords: panic, GADT | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -----------------------------+---------------------------------------------- Changes (by simonpj): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: Thank you for boiling this down. It turns out to be a dup of #2799, reported a few days ago, which I fixed yesterday. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 27 11:23:07 2008 From: trac at galois.com (GHC) Date: Thu Nov 27 11:16:47 2008 Subject: [GHC] #2816: ghci type messages mangle unicode In-Reply-To: <042.cda3d53c33f3e686ec1551e0d8688ddf@localhost> References: <042.cda3d53c33f3e686ec1551e0d8688ddf@localhost> Message-ID: <051.17ed8c6c8af468a74af928115c80cee1@localhost> #2816: ghci type messages mangle unicode ------------------------------+--------------------------------------------- Reporter: rog | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: unicode utf-8 | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | ------------------------------+--------------------------------------------- Changes (by igloo): * difficulty: => Unknown Old description: > while error messages containing identifiers with unicode characters print > fine, other messages from ghci do not. > > for instance: > > Prelude> ? > :1:0: Not in scope: `?' > Prelude> let ? = 4 > Prelude> ? > 4 > Prelude> :type ? > ? :: Integer New description: while error messages containing identifiers with unicode characters print fine, other messages from ghci do not. for instance: {{{ Prelude> ? :1:0: Not in scope: `?' Prelude> let ? = 4 Prelude> ? 4 Prelude> :type ? ? :: Integer }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 27 11:24:58 2008 From: trac at galois.com (GHC) Date: Thu Nov 27 11:18:38 2008 Subject: [GHC] #2816: ghci type messages mangle unicode In-Reply-To: <042.cda3d53c33f3e686ec1551e0d8688ddf@localhost> References: <042.cda3d53c33f3e686ec1551e0d8688ddf@localhost> Message-ID: <051.5440e0df0b6f75f65c7bdc0fd0e1b0d1@localhost> #2816: ghci type messages mangle unicode ------------------------------+--------------------------------------------- Reporter: rog | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: unicode utf-8 | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | ------------------------------+--------------------------------------------- Changes (by igloo): * milestone: => 6.10.2 Comment: Thanks for the report. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 27 11:37:16 2008 From: trac at galois.com (GHC) Date: Thu Nov 27 11:30:57 2008 Subject: [GHC] #2818: schedule: invalid what_next field In-Reply-To: <047.464b7aed990b24af643c9609b75f7b8f@localhost> References: <047.464b7aed990b24af643c9609b75f7b8f@localhost> Message-ID: <056.5126f6935869689b02de6776a0097c6f@localhost> #2818: schedule: invalid what_next field -------------------------------+-------------------------------------------- Reporter: kkwweett | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: Keywords: schedule | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by igloo): * milestone: => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 27 11:40:37 2008 From: trac at galois.com (GHC) Date: Thu Nov 27 11:34:20 2008 Subject: [GHC] #2741: Delete key not working in GHCi In-Reply-To: <044.515a111ead67730965832db1290b176e@localhost> References: <044.515a111ead67730965832db1290b176e@localhost> Message-ID: <053.db1dd8b5c4644f981024fc4a5b9a2c1e@localhost> #2741: Delete key not working in GHCi -----------------------+---------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -----------------------+---------------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: Putting this: {{{ bind "\e[3~" ed-delete-next-char }}} in `~/.editrc` more-or-less fixes it. For 6.12 we plan a proper solution: #2812. Also, there should soon be a ghci-haskeline package available for use with GHC 6.10, which should behave correctly. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 27 11:42:03 2008 From: trac at galois.com (GHC) Date: Thu Nov 27 11:35:53 2008 Subject: [GHC] #2819: Bad example code in documentation of Control.Exception.catch In-Reply-To: <043.8ffe86f1c4d9c257331fb2a6c7fabfed@localhost> References: <043.8ffe86f1c4d9c257331fb2a6c7fabfed@localhost> Message-ID: <052.c90daa8b52c68dd07131158e2194b59e@localhost> #2819: Bad example code in documentation of Control.Exception.catch ---------------------------------+------------------------------------------ Reporter: mafo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: libraries/base | Version: 6.10.1 Severity: trivial | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 27 16:12:11 2008 From: trac at galois.com (GHC) Date: Thu Nov 27 16:05:51 2008 Subject: [GHC] #2748: Fundep-laden code compiled and ran fine in 6.8, fails in 6.10 In-Reply-To: <048.d339fd8ea08f26d215e7fbe110469ee0@localhost> References: <048.d339fd8ea08f26d215e7fbe110469ee0@localhost> Message-ID: <057.5ab4cf4f81bbe21f3f8b2d96a5f6c9ea@localhost> #2748: Fundep-laden code compiled and ran fine in 6.8, fails in 6.10 ---------------------------------+------------------------------------------ Reporter: sedillard | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by sedillard): Thank you! You're right, this particular function is pretty horrendous, but only because I couldn't figure out how to write it so that the base case is a 1x1 matrix, instead of a 2x2. So to avoid overlap, the inductive case then has to be at least 3x3, which gets to be fairly verbose. The overlapping instance doesn't look too scary, does it? Part of my problem here is that (continuing your example {{{class C}}}) I _want_ to be able to declare something as {{{f :: C Int x => ... }}}. It's not that I don't know what {{{x}}} is, (well, in this case I needed your help to figure it out) but it's just that {{{x}}} might be of some really verbose form. Its not even an issue of overlap, because {{{x}}} doesn't necessarily appear in the instance type (or whatever that thing to the right of {{{=>}}} is called.) It could be {{{ instance (Class C Int x, Class Q x (Bool,Char)) => Class W (Bool,Char) }}} In that instance, {{{x}}} could be some hideously verbose type. It would be nice if I could declare a synonym somewhere in the declaration, just a plain substitution, saying that one is the same as the other. "Hey listen, GHC, I'm going to type "x" here but I really mean "(a,(b,(c,())))." Would this situation be any different using type functions? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 27 21:01:38 2008 From: trac at galois.com (GHC) Date: Thu Nov 27 20:55:17 2008 Subject: [GHC] #2821: rebindable-syntax arrow docs Message-ID: <044.597cb5c52398ae1576f2d9ad485a28ce@localhost> #2821: rebindable-syntax arrow docs -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Documentation Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- http://www.haskell.org/ghc/docs/6.10.1/html/users_guide/syntax-extns.html #rebindable-syntax has perhaps got Arrows wrong. Does it use the "arr" and ">>>" in scope, or does it use the (normally in class Category) "id" and "."? Which should it use? (Does anyone use arrow-sugar with !NoImplicitPrelude?) maybe it's all fine, in which case just mark this "invalid". -Isaac D. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 27 23:07:57 2008 From: trac at galois.com (GHC) Date: Thu Nov 27 23:01:39 2008 Subject: [GHC] #368: Provide a Java Backend In-Reply-To: <049.9a5162d2cca544679bf8d2366946a80b@localhost> References: <049.9a5162d2cca544679bf8d2366946a80b@localhost> Message-ID: <058.f692d1bb5d51d52c36634326921b134a@localhost> #368: Provide a Java Backend ---------------------------------+------------------------------------------ Reporter: rainbowang | Owner: nobody Type: feature request | Status: assigned Priority: normal | Milestone: _|_ Component: Compiler | Version: None Severity: minor | Resolution: None Keywords: | Difficulty: Project (> 1 week) Testcase: N/A | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by PHO): * cc: pho@cielonegro.org (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 27 23:09:25 2008 From: trac at galois.com (GHC) Date: Thu Nov 27 23:03:06 2008 Subject: [GHC] #750: Set -M, -H, -c and other memory-related values based on available virtual/physical memory In-Reply-To: <047.4da04e65e03bdba222f53fcd227ca561@localhost> References: <047.4da04e65e03bdba222f53fcd227ca561@localhost> Message-ID: <056.9416b945b08b9d59d42cbbcf6a44ccbe@localhost> #750: Set -M, -H, -c and other memory-related values based on available virtual/physical memory ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Runtime System | Version: 6.4.1 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: N/A | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by PHO): * cc: pho@cielonegro.org (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 27 23:10:17 2008 From: trac at galois.com (GHC) Date: Thu Nov 27 23:04:00 2008 Subject: [GHC] #836: rebindable if-then-else syntax In-Reply-To: <044.b180e3384940c158d15aeb2fcea0b51c@localhost> References: <044.b180e3384940c158d15aeb2fcea0b51c@localhost> Message-ID: <053.3d78940e8040c4a5513a4b8562a89ae0@localhost> #836: rebindable if-then-else syntax ---------------------------------+------------------------------------------ Reporter: nibro | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.4.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: N/A | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by PHO): * cc: pho@cielonegro.org (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 27 23:13:13 2008 From: trac at galois.com (GHC) Date: Thu Nov 27 23:06:53 2008 Subject: [GHC] #2806: Require bang-patterns for unlifted bindings In-Reply-To: <046.9d55d0c05fffd15719c6c19b63c006aa@localhost> References: <046.9d55d0c05fffd15719c6c19b63c006aa@localhost> Message-ID: <055.5c033416d30e58ead8193ba4c7619cf8@localhost> #2806: Require bang-patterns for unlifted bindings ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by PHO): * cc: pho@cielonegro.org (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 27 23:14:40 2008 From: trac at galois.com (GHC) Date: Thu Nov 27 23:08:26 2008 Subject: [GHC] #2708: Error message should suggest UnboxedTuples language extension In-Reply-To: <042.212746937576e763576cc00131665374@localhost> References: <042.212746937576e763576cc00131665374@localhost> Message-ID: <051.64ff3eb584f13e6c44a5a7e56e773a77@localhost> #2708: Error message should suggest UnboxedTuples language extension ----------------------------------+----------------------------------------- Reporter: tim | Owner: Type: feature request | Status: new Priority: low | Milestone: _|_ Component: Compiler (Parser) | Version: 6.9 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by PHO): * cc: pho@cielonegro.org (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 27 23:15:24 2008 From: trac at galois.com (GHC) Date: Thu Nov 27 23:09:04 2008 Subject: [GHC] #2648: Report out of date interface files robustly In-Reply-To: <046.fcbe859a05356d3f8331ef4b72030e02@localhost> References: <046.fcbe859a05356d3f8331ef4b72030e02@localhost> Message-ID: <055.7fec7bbd46789e93859006fc71debf67@localhost> #2648: Report out of date interface files robustly ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by PHO): * cc: pho@cielonegro.org (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 27 23:16:52 2008 From: trac at galois.com (GHC) Date: Thu Nov 27 23:10:31 2008 Subject: [GHC] #2600: Bind type variables in RULES In-Reply-To: <046.60d3c1925e5a0ef8b7d1f9b2b5ebeabc@localhost> References: <046.60d3c1925e5a0ef8b7d1f9b2b5ebeabc@localhost> Message-ID: <055.f1128336441562b4854fa488047accd6@localhost> #2600: Bind type variables in RULES ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: simonpj Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by PHO): * cc: pho@cielonegro.org (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 27 23:17:45 2008 From: trac at galois.com (GHC) Date: Thu Nov 27 23:11:30 2008 Subject: [GHC] #2526: warn about missing signatures only for exported functions In-Reply-To: <054.8d84f54fed1e47316e9d59e9281759fd@localhost> References: <054.8d84f54fed1e47316e9d59e9281759fd@localhost> Message-ID: <063.990224151386ebf8f5711fabd373597c@localhost> #2526: warn about missing signatures only for exported functions ---------------------------------+------------------------------------------ Reporter: fergushenderson | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by PHO): * cc: pho@cielonegro.org (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 27 23:22:58 2008 From: trac at galois.com (GHC) Date: Thu Nov 27 23:16:39 2008 Subject: [GHC] #1872: Extensible Records In-Reply-To: <044.1644b4d2ed2831e3dac4855a76eabeb0@localhost> References: <044.1644b4d2ed2831e3dac4855a76eabeb0@localhost> Message-ID: <053.b9556dc1b324dd5d85be93dc2842ece4@localhost> #1872: Extensible Records --------------------------------+------------------------------------------- Reporter: gidyn | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: Extensible Records | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple --------------------------------+------------------------------------------- Changes (by PHO): * cc: pho@cielonegro.org (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 28 04:09:52 2008 From: trac at galois.com (GHC) Date: Fri Nov 28 04:03:30 2008 Subject: [GHC] #2821: rebindable-syntax arrow docs In-Reply-To: <044.597cb5c52398ae1576f2d9ad485a28ce@localhost> References: <044.597cb5c52398ae1576f2d9ad485a28ce@localhost> Message-ID: <053.f4ea58e3b605c46ffbe581f00446a1ab@localhost> #2821: rebindable-syntax arrow docs ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * cc: ross@soi.city.ac.uk (added) * difficulty: => Unknown Comment: Looking at the code, the rebindable names are: {{{ loop (|||) app arr (>>>) first }}} Whether these are the "right" ones I don't know (Ross?), but that seems to be the set actually used. No `id` or `(.)` so far as I can see. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 28 04:12:58 2008 From: trac at galois.com (GHC) Date: Fri Nov 28 04:06:37 2008 Subject: [GHC] #2748: Fundep-laden code compiled and ran fine in 6.8, fails in 6.10 In-Reply-To: <048.d339fd8ea08f26d215e7fbe110469ee0@localhost> References: <048.d339fd8ea08f26d215e7fbe110469ee0@localhost> Message-ID: <057.6e02acab5b95c3a99c2fd9b5f3eae9f6@localhost> #2748: Fundep-laden code compiled and ran fine in 6.8, fails in 6.10 ---------------------------------+------------------------------------------ Reporter: sedillard | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonpj): Type functions might help. Instead of {{{ class C a b | a->b instance C [a] (Bool,a,a,a) f :: C [a] x => a -> x }}} (you'll see I chose a verbose type), you'd write {{{ class C a where type F a ... instance C [a] where type F Int = (Bool,a,a,a) ... f :: C [a] => a -> F a }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 28 04:28:29 2008 From: trac at galois.com (GHC) Date: Fri Nov 28 04:22:07 2008 Subject: [GHC] #2808: createDirectoryIfMissing should be atomic In-Reply-To: <046.21f1a9c564db33e6ee9ef7b6ede88c51@localhost> References: <046.21f1a9c564db33e6ee9ef7b6ede88c51@localhost> Message-ID: <055.885ac182df3b39fbd3c14d934d155037@localhost> #2808: createDirectoryIfMissing should be atomic ------------------------------------+--------------------------------------- Reporter: EricKow | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.2 Component: libraries/directory | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ------------------------------------+--------------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: I've fixed the obvious race condition, but as Duncan says it's not possible to make this function completely race-free. I think this is enough to keep Eric happy, though. {{{ Wed Nov 26 11:56:06 GMT 2008 Simon Marlow * add test for createDirectoryIfMissing (#2808) Wed Nov 26 12:36:59 GMT 2008 Simon Marlow * avoid race conditions in createDirectoryIfMissing (#2808) }}} For reference the code is now: {{{ createDirectoryIfMissing create_parents "" = return () createDirectoryIfMissing create_parents path0 = do r <- try $ createDirectory path case (r :: Either IOException ()) of Right _ -> return () Left e | isAlreadyExistsError e -> return () | isDoesNotExistError e && create_parents -> do createDirectoryIfMissing True (dropFileName path) createDirectoryIfMissing True path | otherwise -> throw e where -- we want createDirectoryIfMissing "a/" to behave like -- createDirectoryIfMissing "a". Also, unless we apply -- dropTrailingPathSeparator first, dropFileName won't drop -- anything from "a/". path = dropTrailingPathSeparator path0 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 28 04:59:17 2008 From: trac at galois.com (GHC) Date: Fri Nov 28 04:52:54 2008 Subject: [GHC] #2822: Arity expansion not working right Message-ID: <046.15a4d7e08c29ef55ed5596df1606d405@localhost> #2822: Arity expansion not working right ---------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ---------------------------------------+------------------------------------ With GHC 6.10, the arity of `GHC.Handle.openFile` is reported as 2. But its definition is {{{ openFile fp im = Prelude.catch (...) (...) }}} and `Prelude.catch` has arity 3. Somehow `openFile` isn't getting eta- expanded properly. It's not a huge deal, but arity expansion is an important optimisation so I want to track places it isn't happening. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 28 05:02:01 2008 From: trac at galois.com (GHC) Date: Fri Nov 28 04:55:38 2008 Subject: [GHC] #2823: Another arity expansion bug Message-ID: <046.50a7eb0bd1d6f872efa506bccfff4122@localhost> #2823: Another arity expansion bug ---------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ---------------------------------------+------------------------------------ Roman reports: I've finally tracked down one big optimisation problem (at least, I think it is big). Here is a small example: {{{ foo :: Eq a => a -> a {-# NOINLINE foo #-} foo x = x bar :: Eq a => a -> a {-# INLINE [1] bar #-} bar x = let p = foo (x,x) q = foo (p,p) in fst (fst q) }}} For some reason, bar's arity is 1 which is wrong. If we replace `(fst (fst q))` by `(fst p)`, it gets the correct arity of 2. The problem is that because of the arity, `(bar $dEq)` is then floated out as far as possible which breaks fusion if we have RULES for bar. In case you are interested, this affects `splitSD` in `dph-prim-par/Data/ Array/Parallel/Unlifted/Distributed/Arrays.hs`. I haven't noticed this previously because we didn't use segmented arrays as much. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 28 05:20:56 2008 From: trac at galois.com (GHC) Date: Fri Nov 28 05:14:40 2008 Subject: [GHC] #368: Provide a Java Backend In-Reply-To: <049.9a5162d2cca544679bf8d2366946a80b@localhost> References: <049.9a5162d2cca544679bf8d2366946a80b@localhost> Message-ID: <058.51a9862b4593f5541898708014e4c31e@localhost> #368: Provide a Java Backend ---------------------------------+------------------------------------------ Reporter: rainbowang | Owner: nobody Type: feature request | Status: assigned Priority: normal | Milestone: _|_ Component: Compiler | Version: None Severity: minor | Resolution: None Keywords: | Difficulty: Project (> 1 week) Testcase: N/A | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by MarcWeber): * cc: marco-oweber@gmx.de (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 28 06:18:06 2008 From: trac at galois.com (GHC) Date: Fri Nov 28 06:11:43 2008 Subject: [GHC] #2821: rebindable-syntax arrow docs In-Reply-To: <044.597cb5c52398ae1576f2d9ad485a28ce@localhost> References: <044.597cb5c52398ae1576f2d9ad485a28ce@localhost> Message-ID: <053.7e34dc7f17c9438aa3ab508944eb7638@localhost> #2821: rebindable-syntax arrow docs ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 6.10.1 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by ross): * status: new => closed * resolution: => invalid Comment: So those are the names, and it looks them up in the same way as other rebindable names. The names seem a reasonable choice. I don't see any bug here. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 28 07:19:25 2008 From: trac at galois.com (GHC) Date: Fri Nov 28 07:13:03 2008 Subject: [GHC] #2824: Duplicate symbols generated when Generics flag and syb-with-class "derive" used simultaneously Message-ID: <046.347763e7287f3bda7f4c07ddb98fcdaa@localhost> #2824: Duplicate symbols generated when Generics flag and syb-with-class "derive" used simultaneously -------------------------------------+-------------------------------------- Reporter: jcheney | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: generics, syb-with-class | Testcase: Os: Linux | Architecture: x86 -------------------------------------+-------------------------------------- Attached file Foo.hs compiles fine using {{{ ghc -c Foo.hs }}} But compiling using the -XGenerics flag yields duplicate symbols errors from the assembler: {{{ jcheney@oreb:~/src/FreshLib/bug$ ghc -c -v -XGenerics Foo.hs Glasgow Haskell Compiler, Version 6.10.1, for Haskell 98, stage 2 booted by GHC version 6.6 Using package config file: /usr/local/lib/ghc-6.10.1/./package.conf Using package config file: /home/jcheney/.ghc/i386-linux-6.10.1/package.conf hiding package base-3.0.3.0 to avoid conflict with later version base-4.0.0.0 wired-in package ghc-prim mapped to ghc-prim-0.1.0.0 wired-in package integer mapped to integer-0.1.0.0 wired-in package base mapped to base-4.0.0.0 wired-in package rts mapped to rts-1.0 wired-in package haskell98 mapped to haskell98-1.0.1.0 wired-in package syb mapped to syb-0.1.0.0 wired-in package template-haskell mapped to template-haskell-2.3.0.0 wired-in package dph-seq mapped to dph-seq-0.3 wired-in package dph-par mapped to dph-par-0.3 Hsc static flags: -static Created temporary directory: /tmp/ghc15945_0 *** Checking old interface for main:Foo: *** Parser: *** Renamer/typechecker: *** Simplify: *** CorePrep: *** ByteCodeGen: Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Loading package syb ... linking ... done. Loading package base-3.0.3.0 ... linking ... done. Loading package array-0.2.0.0 ... linking ... done. Loading package packedstring-0.1.0.1 ... linking ... done. Loading package containers-0.2.0.0 ... linking ... done. Loading package pretty-1.0.1.0 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package bytestring-0.9.1.4 ... linking ... done. Loading package syb-with-class-0.4 ... linking ... done. *** Desugar: Result size = 230 *** Simplify: Result size = 141 Result size = 141 *** Tidy Core: Result size = 141 writeBinIface: 9 Names writeBinIface: 42 dict entries *** CorePrep: Result size = 187 *** Stg2Stg: *** CodeGen: *** CodeOutput: *** Assembler: gcc -I. -c /tmp/ghc15945_0/ghc15945_0.s -o Foo.o /tmp/ghc15945_0/ghc15945_0.s: Assembler messages: /tmp/ghc15945_0/ghc15945_0.s:224:0: Error: symbol `Foo_zdgtoFoo_closure' is already defined /tmp/ghc15945_0/ghc15945_0.s:233:0: Error: symbol `Foo_zdgtoFoo_info' is already defined /tmp/ghc15945_0/ghc15945_0.s:273:0: Error: symbol `Foo_zdgfromFoo_closure' is already defined /tmp/ghc15945_0/ghc15945_0.s:291:0: Error: symbol `Foo_zdgfromFoo_info' is already defined *** Deleting temp files: Deleting: /tmp/ghc15945_0/ghc15945_0.s *** Deleting temp dirs: Deleting: /tmp/ghc15945_0 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 28 10:05:08 2008 From: trac at galois.com (GHC) Date: Fri Nov 28 09:58:46 2008 Subject: [GHC] #2092: Quadratic amount of code generated In-Reply-To: <044.4dc3ac8354cd192cb2595466e974beb4@localhost> References: <044.4dc3ac8354cd192cb2595466e974beb4@localhost> Message-ID: <053.779326ba8e38521d565e83be8393c618@localhost> #2092: Quadratic amount of code generated -----------------------------------------+---------------------------------- Reporter: igloo | Owner: Type: run-time performance bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Comment (by simonpj): Although this bug is closed, I'm not convinced we're done. Some time ago I stopped the simplifier creating quite so many join points. The patch that closed this bug narrowed the cases for which my heuristic applied. And with good reason. But I think that if we had bad cases before adding the "don't create a joint point" heuristic, we'll get bad cases with Simon's change too. Looking at the comments, though, I can't see a compelling case for ''not'' always doing the case-of-case and creating a join point. I think it arose in a program that Roman cared about, so I asked him. He replies: {{{ This is what I can find in my archives: > I think this is what happens. We start out with (essentially) > > primes n = f (g h (abs n))) > > where h is a function (which is passed as an argument to g) and f, g and > h are all inlined at some point. > > We end up with > > primes n = let j = \h m -> ( h m) > in > case n >= 0 of > True -> j n > False -> j (-n) > > This is bad because we really want the code for f, g and h to be > combined to produce an efficient loop. So what we want is probably > > primes n = let j = \m -> ( m) > in > case n >= 0 of > True -> j n > False -> j (-n) and: > PROBLEM. > Suppose we have > > f (abs x `div` y) > > and a RULE > > f (a `div` b) = ... > > Then you'd expect the RULE to fire. > But if we inline abs, then, because div is strict, we'll get> > f (case x>0 of > T -> x `div` y > F -> negate x `div y) > > (or, worse, a join point might created if the code was bigger). > Anyway, the f/div RULE can't fire any more. > > Roman also thinks there may be a problem even in the absence > of RULES, but we're not sure it's real. See message attached. > ***Roman will try to find an example*** > > POSSIBLE SOLUTION. > > a) Never push strict functions inside case > > f (case .. of alts) > stays just like that. > b) Only push strict functions inside a case with one alternative > f (case ? of p -> e) ? case ? of p -> f e > > (b) seems less draconian, but if f is lazy and g is strict then > f (g (case?)) ? f (case .. of p-> g..) > and now an f/g rule won?t fire. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 28 11:22:38 2008 From: trac at galois.com (GHC) Date: Fri Nov 28 11:16:15 2008 Subject: [GHC] #2729: Stuck when compiling XMonad.StackSet in xmonad 0.9 (hackage version) In-Reply-To: <047.e60b778bc8c8ee75007c390c57c1ee7f@localhost> References: <047.e60b778bc8c8ee75007c390c57c1ee7f@localhost> Message-ID: <056.4c691af40b2fc4ec67c089a0197e4344@localhost> #2729: Stuck when compiling XMonad.StackSet in xmonad 0.9 (hackage version) ---------------------------------+------------------------------------------ Reporter: mnislaih | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.11 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonpj): I've tried and failed to reproduce this. I downloaded xmonad 0.8 from hackage (that seems to be the latest version) and X11-1.4.4 from hackage. This fails because xmonad 0.8 is incompatible with GHC 6.10 {{{ bash-3.2$ runhaskell Setup.lhs build Preprocessing library xmonad-0.8... Preprocessing executables for xmonad-0.8... Building xmonad-0.8... [1 of 8] Compiling XMonad.StackSet ( XMonad/StackSet.hs, dist/build/XMonad/StackSet.o ) [2 of 8] Compiling XMonad.Core ( XMonad/Core.hs, dist/build/XMonad/Core.o ) XMonad/Core.hs:36:49: Module `Control.Exception' does not export `Exception(ExitException)' }}} (However, `StackSet` compiled ok.) I got the latest xmonad from {{{ darcs get --partial http://code.haskell.org/xmonad }}} That compiled fine, both with GHC 6.10.1 and with HEAD. So I'm stumped. Can you check? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 28 11:29:58 2008 From: trac at galois.com (GHC) Date: Fri Nov 28 11:23:37 2008 Subject: [GHC] #2729: Stuck when compiling XMonad.StackSet in xmonad 0.9 (hackage version) In-Reply-To: <047.e60b778bc8c8ee75007c390c57c1ee7f@localhost> References: <047.e60b778bc8c8ee75007c390c57c1ee7f@localhost> Message-ID: <056.0c0568e95344d85d9d6a674453646e09@localhost> #2729: Stuck when compiling XMonad.StackSet in xmonad 0.9 (hackage version) ---------------------------------+------------------------------------------ Reporter: mnislaih | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.11 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by mnislaih): I will test with the current HEAD on the same box. By the way somehow I managed to add one to the version number, I meant XMonad 0.8 not 0.9. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 28 11:30:32 2008 From: trac at galois.com (GHC) Date: Fri Nov 28 11:24:15 2008 Subject: [GHC] #2729: Stuck when compiling XMonad.StackSet in xmonad 0.9 (hackage version) In-Reply-To: <047.e60b778bc8c8ee75007c390c57c1ee7f@localhost> References: <047.e60b778bc8c8ee75007c390c57c1ee7f@localhost> Message-ID: <056.35b2660d4e30d00e9055da0e8ddb37f6@localhost> #2729: Stuck when compiling XMonad.StackSet in xmonad 0.9 (hackage version) -------------------------------+-------------------------------------------- Reporter: mnislaih | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.11 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by mnislaih): * architecture: Unknown/Multiple => x86_64 (amd64) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 28 12:16:11 2008 From: trac at galois.com (GHC) Date: Fri Nov 28 12:09:54 2008 Subject: [GHC] #2058: Ghci tab-completion cannot handle Unicode In-Reply-To: <047.a8886855c87afec46dd99ad6a799741e@localhost> References: <047.a8886855c87afec46dd99ad6a799741e@localhost> Message-ID: <056.d98553705d22bf39b1ad5d94707cdaa7@localhost> #2058: Ghci tab-completion cannot handle Unicode ---------------------------------+------------------------------------------ Reporter: desegnis | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by judah): This will be fixed once we implement #2812 (use haskeline in ghci). The example repo mentioned in that ticket (ghci-haskeline) does not have this issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 28 12:47:32 2008 From: trac at galois.com (GHC) Date: Fri Nov 28 12:41:10 2008 Subject: [GHC] #2740: free variable not available in debugger In-Reply-To: <046.05e1293bbffbc0807e6d01b8f2d22646@localhost> References: <046.05e1293bbffbc0807e6d01b8f2d22646@localhost> Message-ID: <055.57a0c2803a45d6ddaa9e45e3c19a7e51@localhost> #2740: free variable not available in debugger -------------------------+-------------------------------------------------- Reporter: phercek | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10.2 Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: debugger | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 28 12:48:58 2008 From: trac at galois.com (GHC) Date: Fri Nov 28 12:42:37 2008 Subject: [GHC] #2768: rts/win32/IOManager.h declarations conflict with windows.h In-Reply-To: <047.ee2a51d822f2ec1d2f12177eff0b4289@localhost> References: <047.ee2a51d822f2ec1d2f12177eff0b4289@localhost> Message-ID: <056.f4dd5d320ade9de7ece3a26a4e41caf1@localhost> #2768: rts/win32/IOManager.h declarations conflict with windows.h -------------------------------+-------------------------------------------- Reporter: Deewiant | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10.2 Component: Runtime System | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 28 12:50:19 2008 From: trac at galois.com (GHC) Date: Fri Nov 28 12:43:55 2008 Subject: [GHC] #2817: Template Haskell conversion fails with "malformed type" In-Reply-To: <046.4aa37e864452514bae7500fd7deea017@localhost> References: <046.4aa37e864452514bae7500fd7deea017@localhost> Message-ID: <055.c513bd7673a8352797425bd360550e61@localhost> #2817: Template Haskell conversion fails with "malformed type" ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: th/T2817 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 28 12:51:04 2008 From: trac at galois.com (GHC) Date: Fri Nov 28 12:44:46 2008 Subject: [GHC] #2799: Panic (core lint failure) with GADTs, GHC 6.10.1 In-Reply-To: <047.02178742ef8c8010079728a64ae52ee1@localhost> References: <047.02178742ef8c8010079728a64ae52ee1@localhost> Message-ID: <056.81925ec2629985b850e71f2e4e37d927@localhost> #2799: Panic (core lint failure) with GADTs, GHC 6.10.1 -----------------------------------------------+---------------------------- Reporter: alexey_r | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: major | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: typecheck/should_compile/T2799 | Os: Windows Architecture: x86 | -----------------------------------------------+---------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 28 13:07:02 2008 From: trac at galois.com (GHC) Date: Fri Nov 28 13:00:39 2008 Subject: [GHC] #2766: Infix type operators are presented with incorrect syntax in ghci In-Reply-To: <048.ede65a0a07b7bb10f4f547601c287a56@localhost> References: <048.ede65a0a07b7bb10f4f547601c287a56@localhost> Message-ID: <057.386547f4a1ef6c81ed2a83f599417a8a@localhost> #2766: Infix type operators are presented with incorrect syntax in ghci -----------------------------------+---------------------------------------- Reporter: EyalLotem | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10.2 Component: GHCi | Version: 6.10.1 Severity: major | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: ghci/scripts/T2766 | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------+---------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 28 13:39:58 2008 From: trac at galois.com (GHC) Date: Fri Nov 28 13:33:37 2008 Subject: [GHC] #2063: x86_64: RTS linker depends on working MAP_32BIT In-Reply-To: <043.15abf9ca319b437728a2421245ad0407@localhost> References: <043.15abf9ca319b437728a2421245ad0407@localhost> Message-ID: <052.70700815ffc74ae85355d9b6b8436be4@localhost> #2063: x86_64: RTS linker depends on working MAP_32BIT -------------------------------+-------------------------------------------- Reporter: dons | Owner: igloo Type: task | Status: new Priority: normal | Milestone: 6.10.2 Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: OpenBSD | Difficulty: Moderate (1 day) Testcase: | Os: Unknown/Multiple Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by igloo): * type: merge => task Comment: Both merged. AFAIK we're still waiting on the positive feedback. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 28 13:44:23 2008 From: trac at galois.com (GHC) Date: Fri Nov 28 13:38:00 2008 Subject: [GHC] #2755: Broken link in GHC API documentation In-Reply-To: <044.a40779a08e2a4155adb6f037645bf002@localhost> References: <044.a40779a08e2a4155adb6f037645bf002@localhost> Message-ID: <053.5cc14289cd64584550474d53e8a5460d@localhost> #2755: Broken link in GHC API documentation ---------------------------------+------------------------------------------ Reporter: waern | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Documentation | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * owner: => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 28 13:52:14 2008 From: trac at galois.com (GHC) Date: Fri Nov 28 13:45:51 2008 Subject: [GHC] #2757: runghc doesn't respond to --help In-Reply-To: <047.8ea527abd27e35ccd572a6a7f32be73f@localhost> References: <047.8ea527abd27e35ccd572a6a7f32be73f@localhost> Message-ID: <056.490dfdd3915a6285972556a9e889a268@localhost> #2757: runghc doesn't respond to --help ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * owner: => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 28 14:18:38 2008 From: trac at galois.com (GHC) Date: Fri Nov 28 14:12:25 2008 Subject: [GHC] #2773: Documentation mentions deprecated flags In-Reply-To: <044.8fbd9fa5930a794c5be22803687b7d92@localhost> References: <044.8fbd9fa5930a794c5be22803687b7d92@localhost> Message-ID: <053.5d290feeb4d2f8ee925d27e72167af82@localhost> #2773: Documentation mentions deprecated flags ---------------------------------+------------------------------------------ Reporter: guest | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Documentation | Version: 6.10.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * owner: => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 28 15:30:57 2008 From: trac at galois.com (GHC) Date: Fri Nov 28 15:24:34 2008 Subject: [GHC] #2757: runghc doesn't respond to --help In-Reply-To: <047.8ea527abd27e35ccd572a6a7f32be73f@localhost> References: <047.8ea527abd27e35ccd572a6a7f32be73f@localhost> Message-ID: <056.996254e933ff91d2ac5a04a15b8bfd05@localhost> #2757: runghc doesn't respond to --help ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Easy (1 hr) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed in HEAD and 6.10 branch: {{{ Fri Nov 28 11:17:06 PST 2008 Ian Lynagh * Teach runghc about --help; fixes trac #2757 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 28 15:32:03 2008 From: trac at galois.com (GHC) Date: Fri Nov 28 15:25:40 2008 Subject: [GHC] #2755: Broken link in GHC API documentation In-Reply-To: <044.a40779a08e2a4155adb6f037645bf002@localhost> References: <044.a40779a08e2a4155adb6f037645bf002@localhost> Message-ID: <053.a24ed8a9e8d85d72839a631b114eb640@localhost> #2755: Broken link in GHC API documentation ---------------------------------+------------------------------------------ Reporter: waern | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.10.2 Component: Documentation | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed in HEAD and 6.10 branch: {{{ Fri Nov 28 10:45:11 PST 2008 Ian Lynagh * Use relative URLs in the GHC API haddock docs; fixes #2755 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 28 15:32:59 2008 From: trac at galois.com (GHC) Date: Fri Nov 28 15:26:43 2008 Subject: [GHC] #2773: Documentation mentions deprecated flags In-Reply-To: <044.8fbd9fa5930a794c5be22803687b7d92@localhost> References: <044.8fbd9fa5930a794c5be22803687b7d92@localhost> Message-ID: <053.751f0bbf607bdc568ae28b7e2bc98e09@localhost> #2773: Documentation mentions deprecated flags ---------------------------------+------------------------------------------ Reporter: guest | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.10.2 Component: Documentation | Version: 6.10.1 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed in HEAD and 6.10 branch: {{{ Fri Nov 28 11:36:33 PST 2008 Ian Lynagh * Update docs not to talk about deprecated -optdep-* flags; fixes trac #2773 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 28 17:20:10 2008 From: trac at galois.com (GHC) Date: Fri Nov 28 17:13:46 2008 Subject: [GHC] #2560: killThread and getChanContents appear to interact strangely In-Reply-To: <053.7b90af27065da85db72f8f049c3b99b1@localhost> References: <053.7b90af27065da85db72f8f049c3b99b1@localhost> Message-ID: <062.de55e262fbd23d8a6cc64bd88524a5ba@localhost> #2560: killThread and getChanContents appear to interact strangely ---------------------------------+------------------------------------------ Reporter: batterseapower | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Runtime System | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by igloo): OK, I think the problem is that {{{ readChan = modifyMVar ... }}} and {{{ modifyMVar :: MVar a -> (a -> IO (a,b)) -> IO b modifyMVar m io = block $ do a <- takeMVar m (a',b) <- unblock (io a) `onException` putMVar m a putMVar m a' return b }}} so although you are calling `readChan` with exceptions blocked, they are being unblocked by the library. I'm not sure what the best solution is. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 28 17:37:38 2008 From: trac at galois.com (GHC) Date: Fri Nov 28 17:31:18 2008 Subject: [GHC] #2825: Stack overflow death Message-ID: <044.254ba61a6afd72556d22bd88d81da3dd@localhost> #2825: Stack overflow death -----------------------------+---------------------------------------------- Reporter: osuch | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- GHCI dies without any warning, if evaluation of the function ex3 in the following code fragment is attempted: ex2 x partial sum n = let partial = partial * x / fromIntegral(n) in if (partial + sum == sum) then sum else ex2 x partial (sum + partial) (n+1) ex3 x = ex2 x 1 1.0 1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 28 17:41:30 2008 From: trac at galois.com (GHC) Date: Fri Nov 28 17:35:07 2008 Subject: [GHC] #2825: Stack overflow death In-Reply-To: <044.254ba61a6afd72556d22bd88d81da3dd@localhost> References: <044.254ba61a6afd72556d22bd88d81da3dd@localhost> Message-ID: <053.0984d6ad4000e2a6363b446771b1244f@localhost> #2825: Stack overflow death ---------------------+------------------------------------------------------ Reporter: osuch | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Windows | Architecture: x86 ---------------------+------------------------------------------------------ Changes (by osuch): * os: Unknown/Multiple => Windows * architecture: Unknown/Multiple => x86 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 28 17:54:22 2008 From: trac at galois.com (GHC) Date: Fri Nov 28 17:47:58 2008 Subject: [GHC] #2825: Stack overflow death In-Reply-To: <044.254ba61a6afd72556d22bd88d81da3dd@localhost> References: <044.254ba61a6afd72556d22bd88d81da3dd@localhost> Message-ID: <053.a5be150c4ecb46b952c983d3880b1877@localhost> #2825: Stack overflow death -----------------------+---------------------------------------------------- Reporter: osuch | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -----------------------+---------------------------------------------------- Changes (by igloo): * difficulty: => Unknown Old description: > GHCI dies without any warning, if evaluation of the function ex3 in the > following code fragment is attempted: > > ex2 x partial sum n = let partial = partial * x / fromIntegral(n) > in if (partial + sum == sum) > then sum > else ex2 x partial (sum + partial) (n+1) > > ex3 x = ex2 x 1 1.0 1 New description: GHCI dies without any warning, if evaluation of the function ex3 in the following code fragment is attempted: {{{ ex2 x partial sum n = let partial = partial * x / fromIntegral(n) in if (partial + sum == sum) then sum else ex2 x partial (sum + partial) (n+1) ex3 x = ex2 x 1 1.0 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 28 18:01:20 2008 From: trac at galois.com (GHC) Date: Fri Nov 28 17:54:57 2008 Subject: [GHC] #2825: Stack overflow death In-Reply-To: <044.254ba61a6afd72556d22bd88d81da3dd@localhost> References: <044.254ba61a6afd72556d22bd88d81da3dd@localhost> Message-ID: <053.e97712ad7c0c3ce71521c16e642527b8@localhost> #2825: Stack overflow death -----------------------+---------------------------------------------------- Reporter: osuch | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.2 Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -----------------------+---------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => duplicate * milestone: => 6.10.2 Comment: Thanks for the report; sounds like a duplicate of #2780 / #2783 (will be fixed in 6.10.2). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 29 04:33:52 2008 From: trac at galois.com (GHC) Date: Sat Nov 29 04:27:27 2008 Subject: [GHC] #2764: gen_contents_index generates links with package.haddock in the path In-Reply-To: <050.3f1d57166b0bf0e303ef4a1822302d5d@localhost> References: <050.3f1d57166b0bf0e303ef4a1822302d5d@localhost> Message-ID: <059.7964fc36ecf0ccd310784930e0ba2fdb@localhost> #2764: gen_contents_index generates links with package.haddock in the path ---------------------------------+------------------------------------------ Reporter: juhpetersen | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.10.2 Component: Documentation | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed in HEAD and 6.10 by: {{{ Sun Nov 16 17:41:22 GMT 2008 Ian Lynagh * Fix gen_contents_index when not run inplace; trac #2764 Based on a patch from juhpetersen. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 29 06:59:48 2008 From: trac at galois.com (GHC) Date: Sat Nov 29 06:53:55 2008 Subject: [GHC] #2819: Bad example code in documentation of Control.Exception.catch In-Reply-To: <043.8ffe86f1c4d9c257331fb2a6c7fabfed@localhost> References: <043.8ffe86f1c4d9c257331fb2a6c7fabfed@localhost> Message-ID: <052.672aa449d11dad99ef70b1c9b3cc1b46@localhost> #2819: Bad example code in documentation of Control.Exception.catch ---------------------------------+------------------------------------------ Reporter: mafo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: libraries/base | Version: 6.10.1 Severity: trivial | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by claus): The `catchJust` example there also refers to `errorCalls`, which is in the old exceptions module. Overall, that page could be more explicit about the recent switch to extensible exception, just as it is still explicit about the once new asynchronous exceptions. Perhaps a separate section, on that page, with a brief history of changes, and references? All the examples should be converted to the intended new style, whatever that is;-) Summary, for those looking up this ticket: instead of a single, non- extensible exception type, there are now many specialist exception types and one extensible exception class. If your exception handler isn't specific about which type of exceptions it wants to handle, a type error about ambiguity results. See the instances of the `Exception` class for specific types of exceptions, http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control- Exception.html#1 and annotate the `e` in that example with the type of exception you want (`IOException` here). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 29 09:26:27 2008 From: trac at galois.com (GHC) Date: Sat Nov 29 09:20:02 2008 Subject: [GHC] #2757: runghc doesn't respond to --help In-Reply-To: <047.8ea527abd27e35ccd572a6a7f32be73f@localhost> References: <047.8ea527abd27e35ccd572a6a7f32be73f@localhost> Message-ID: <056.9c3bf3a296e178c91aaeed70e72c9cc3@localhost> #2757: runghc doesn't respond to --help ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Easy (1 hr) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by duncan): Perhaps we should also ask about `runghc --version`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 29 14:46:09 2008 From: trac at galois.com (GHC) Date: Sat Nov 29 14:39:42 2008 Subject: [GHC] #2729: Stuck when compiling XMonad.StackSet in xmonad 0.9 (hackage version) In-Reply-To: <047.e60b778bc8c8ee75007c390c57c1ee7f@localhost> References: <047.e60b778bc8c8ee75007c390c57c1ee7f@localhost> Message-ID: <056.8ebbf33ea8cc427187678ad52fc47482@localhost> #2729: Stuck when compiling XMonad.StackSet in xmonad 0.9 (hackage version) -------------------------------+-------------------------------------------- Reporter: mnislaih | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.11 Severity: major | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by mnislaih): * status: new => closed * resolution: => invalid Comment: I have tried with the current HEAD on the same box and cannot replicate this anymore. XMonad compiles fine! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 29 15:07:45 2008 From: trac at galois.com (GHC) Date: Sat Nov 29 15:01:19 2008 Subject: [GHC] #2748: Fundep-laden code compiled and ran fine in 6.8, fails in 6.10 In-Reply-To: <048.d339fd8ea08f26d215e7fbe110469ee0@localhost> References: <048.d339fd8ea08f26d215e7fbe110469ee0@localhost> Message-ID: <057.a3b1d58c53eb3d470d56ba426c912849@localhost> #2748: Fundep-laden code compiled and ran fine in 6.8, fails in 6.10 ---------------------------------+------------------------------------------ Reporter: sedillard | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by sedillard): Since you were so kind as to track down my type error, I've indulged your curiosity (and my own) and rewritten it using type functions. I can't say that it's any more readable, except for the use of type equality constraints (~) which is exactly the thing I was wishing for. I didn't know about them until I started reading up on type families, but they're also really useful for fundep code. Maybe they should have their own LANGUAGE pragma and -X option? Anyway, thanks again. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 29 17:55:58 2008 From: trac at galois.com (GHC) Date: Sat Nov 29 17:49:32 2008 Subject: [GHC] #2762: Excessive heap usage In-Reply-To: <044.bf1fb1b8e171504548cbe3cb91273ef8@localhost> References: <044.bf1fb1b8e171504548cbe3cb91273ef8@localhost> Message-ID: <053.bd98f3402814199b7c1714dca6c40324@localhost> #2762: Excessive heap usage ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by batterseapower): Well, I've had a look at the arity analysis idea. I'll attached a preliminary version of the analysis. It does indeed fix some "bad" arities, including the one in this example, but it's reasonably costly compile-time wise and doesn't have a non-neglible effect on allocations or runtime in Nofib, with two exceptions: * Bspt allocates a lot more, because the call to concat in Stdlib.seQuence is saturated by the eta-expansion step. This causes the simplifier to inline concat at that use site (even though the arguments are boring, since concat is a thin wrapper around a function poly_go). This in turn leads to RULES not spotting any instances of concat during the compilation of the Init and BSPT modules, so foldr/build fusion just fails to happen. (NB: you need to add the missing phase activation [~1] to the concat RULE in GHC.List to see this effect) * Atoms runtime apparently increases a lot, though there is no apparent difference in the STG generated in the two versions (also attached). I can't work out why this is. Even if we fix these problems is it really worth introducing this analysis, given that it's effects are so small? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 29 18:26:08 2008 From: trac at galois.com (GHC) Date: Sat Nov 29 18:19:39 2008 Subject: [GHC] #2826: Panic compiling lhc-0.6.20081127 Message-ID: <043.1a89b950dd25b1bbdfca8fd6e9acbc4c@localhost> #2826: Panic compiling lhc-0.6.20081127 -----------------------------+---------------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- {{{ $ cabal update $ cabal install lhc-0.6.20081127 }}} All goes well, then, {{{ [104 of 162] Compiling FrontEnd.KindInfer ( src/FrontEnd/KindInfer.hs, dist/build/lhc/lhc-tmp/FrontEnd/KindInfer.o ) [105 of 162] Compiling FrontEnd.TypeSigs ( src/FrontEnd/TypeSigs.hs, dist/build/lhc/lhc-tmp/FrontEnd/TypeSigs.o ) [106 of 162] Compiling FrontEnd.Class ( src/FrontEnd/Class.hs, dist/build/lhc/lhc-tmp/FrontEnd/Class.o ) [107 of 162] Compiling FrontEnd.HsErrors ( src/FrontEnd/HsErrors.hs, dist/build/lhc/lhc-tmp/FrontEnd/HsErrors.o ) [108 of 162] Compiling FrontEnd.Rename ( src/FrontEnd/Rename.hs, dist/build/lhc/lhc-tmp/FrontEnd/Rename.o ) ghc: panic! (the 'impossible' happened) (GHC version 6.10.0.20081007 for x86_64-unknown-linux): urk! lookup local fingerprint main:FrontEnd.Rename.:CoRM{tc r6B5f} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug cabal: Error: some packages failed to install: lhc-0.6.20081127 failed during the building phase. The exception was: exit: ExitFailure 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 30 01:21:02 2008 From: trac at galois.com (GHC) Date: Sun Nov 30 01:14:35 2008 Subject: [GHC] #2827: Win32 releases lack versioned binaries Message-ID: <044.f4f9519bc323ffec43db3e4ff5846813@localhost> #2827: Win32 releases lack versioned binaries --------------------+------------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Windows | Architecture: Unknown/Multiple --------------------+------------------------------------------------------- Versioned binaries, of the form ghc-$ver, are very useful when keeping more than one ghc in %Path%, but the official installer doesn't provide them. Also, i've tried to just copy and rename the exes but i got this error: {{{ > ghc-6.10.1 --make Setup.lhs ghc-6.10.1: panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-unknown-mingw32): can't decompose ghc.exe path: "C:\\ghc\\ghc-6.10.1\\bin\\ghc-6.10.1.exe" Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} should i file that as a separate bug? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 30 06:54:30 2008 From: trac at galois.com (GHC) Date: Sun Nov 30 06:48:05 2008 Subject: [GHC] #2827: Win32 releases lack versioned binaries In-Reply-To: <044.f4f9519bc323ffec43db3e4ff5846813@localhost> References: <044.f4f9519bc323ffec43db3e4ff5846813@localhost> Message-ID: <053.de79d0233389a4f8069c946195dce1b7@localhost> #2827: Win32 releases lack versioned binaries ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Windows | Architecture: Unknown/Multiple ----------------------+----------------------------------------------------- Changes (by guest): * cc: sanzhiyan@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 30 11:19:27 2008 From: trac at galois.com (GHC) Date: Sun Nov 30 11:12:57 2008 Subject: [GHC] #2730: Quasiquote or TH linking may need HPC flag In-Reply-To: <046.eb529fb4a48a2719d84deefae728a2de@localhost> References: <046.eb529fb4a48a2719d84deefae728a2de@localhost> Message-ID: <055.fa33ff52cc599772549e46fc74415fcb@localhost> #2730: Quasiquote or TH linking may need HPC flag ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => duplicate Comment: This is a duplicate of #1779. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 30 11:19:54 2008 From: trac at galois.com (GHC) Date: Sun Nov 30 11:13:26 2008 Subject: [GHC] #1779: unknown symbol `hs_hpc_module' In-Reply-To: <044.e238a8559ffe0a21198f4a819a87e869@localhost> References: <044.e238a8559ffe0a21198f4a819a87e869@localhost> Message-ID: <053.4a63d24c5f9af1d917e63a707b12455c@localhost> #1779: unknown symbol `hs_hpc_module' ---------------------------------+------------------------------------------ Reporter: guest | Owner: AndyGill Type: bug | Status: reopened Priority: low | Milestone: 6.10.2 Component: GHCi | Version: 6.9 Severity: minor | Resolution: Keywords: hpc | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by igloo): See also #2730. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 30 12:01:22 2008 From: trac at galois.com (GHC) Date: Sun Nov 30 11:54:54 2008 Subject: [GHC] #2828: TcTyFuns.uMeta: normalisation shouldn't allow x ~ x Message-ID: <044.818395155a9d2081de37d5cedbd2ca16@localhost> #2828: TcTyFuns.uMeta: normalisation shouldn't allow x ~ x -------------------+-------------------------------------------------------- Reporter: pizza | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86 -------------------+-------------------------------------------------------- {{{ pizza@extracheese:~/proj/truegraph$ ghci stats.hs GHCi, version 6.10.0.20081007: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Main ( stats.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 6.10.0.20081007 for i386-unknown-linux): TcTyFuns.uMeta: normalisation shouldn't allow x ~ x Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} where stats.hs is: {{{ mean :: (Num b) => [a] -> (a -> b) -> b mean set f = let total = sum $ map f set mean' = total / fromIntegral $ length set in mean' }}} NOTE that i'm not even sure if this code is correct or makes sense, i'm in the middle of growing it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 30 12:13:40 2008 From: trac at galois.com (GHC) Date: Sun Nov 30 12:07:11 2008 Subject: [GHC] #1779: unknown symbol `hs_hpc_module' In-Reply-To: <044.e238a8559ffe0a21198f4a819a87e869@localhost> References: <044.e238a8559ffe0a21198f4a819a87e869@localhost> Message-ID: <053.fbdec3366562831f718bf210006738f5@localhost> #1779: unknown symbol `hs_hpc_module' ---------------------------------+------------------------------------------ Reporter: guest | Owner: AndyGill Type: bug | Status: reopened Priority: low | Milestone: 6.10.2 Component: GHCi | Version: 6.9 Severity: minor | Resolution: Keywords: hpc | Difficulty: Unknown Testcase: hpc_ghc_ghci | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * testcase: => hpc_ghc_ghci Comment: I've made a minimal testcase, `hpc_ghc_ghci`. In `libraries/hpc/tests/ghc_ghci`: {{{ $ ../../../../ghc/stage2-inplace/ghc -v0 --interactive B.hs *B> b : ./A.o: unknown symbol `hs_hpc_module' $ ../../../../ghc/stage2-inplace/ghc -v0 --interactive B.hs ../../../../rts/Hpc.o GHCi runtime linker: fatal error: I found a duplicate definition for symbol hs_hpc_rootModule whilst processing object file ../../../../rts/Hpc.o This could be caused by: * Loading two different object files which export the same symbol * Specifying the same object file twice on the GHCi command line * An incorrect `package.conf' entry, causing some object to be loaded twice. GHCi cannot safely continue in this situation. Exiting now. Sorry. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 30 15:54:31 2008 From: trac at galois.com (GHC) Date: Sun Nov 30 15:48:02 2008 Subject: [GHC] #2762: Excessive heap usage In-Reply-To: <044.bf1fb1b8e171504548cbe3cb91273ef8@localhost> References: <044.bf1fb1b8e171504548cbe3cb91273ef8@localhost> Message-ID: <053.39b49a66068a2d34d563b34d2c3c885b@localhost> #2762: Excessive heap usage ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by igloo): Replying to [comment:3 batterseapower]: > Well, I've had a look at the arity analysis idea. I'll attached a preliminary version of the analysis. It does indeed fix some "bad" arities, including the one in this example, Great, thanks! > but it's reasonably costly compile-time wise > > Even if we fix these problems is it really worth introducing this analysis, given that it's effects are so small? Fixing the space leak is important to me. If the performance is an issue, then perhaps it should be an `-O2`-only optimisation? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 30 17:52:55 2008 From: trac at galois.com (GHC) Date: Sun Nov 30 17:46:26 2008 Subject: [GHC] #2829: GHC_SEARCH_PATH broken Message-ID: <046.fd61e0b6076af34dcd134be33a9c2d6e@localhost> #2829: GHC_SEARCH_PATH broken -----------------------------+---------------------------------------------- Reporter: droundy | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- This bug is present in at least ghc 6.8.2 and ghc 6.10.1. According to the documentation: http://www.haskell.org/ghc/docs/6.10.1/html/users_guide/packages.html#ghc- package-path One should be able to specify an environment variable like GHC_PACKAGE_PATH=$HOME/foo: in order to add the file foo to the search path. Instead, the search path is completely replaced--which seems unlikely to be the desired behavior, besides being contrary to the documentation. This feature works fine, however, in ghc 6.6.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 30 17:55:27 2008 From: trac at galois.com (GHC) Date: Sun Nov 30 17:48:58 2008 Subject: [GHC] #2830: undefined reference to `base_DataziTuple_Z63T_con_info' when using instances with context Message-ID: <046.d28b188329eef21fa8e1a7ec215f6dde@localhost> #2830: undefined reference to `base_DataziTuple_Z63T_con_info' when using instances with context --------------------+------------------------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86 --------------------+------------------------------------------------------- Hi, I came across this bug when using HAppS, but it is not related to HAppS, it seems. I have attached the files test4.hs and test5. They differ only in that the former one uses {{{ instance (Serialize Method1) => UpdateEvent Method1 () }}} while the second use uses {{{ instance UpdateEvent Method1 () }}} I can not tell any difference in the effect (in my real app, the example file does not have any senisble meaning), but that?s not the point: I can compile test5.hs without problems, but {{{ $ ghc --make test4.hs [1 of 1] Compiling Main ( test4.hs, test4.o ) Linking test4 ... test4.o: In function `r1c1_info': (.text+0x639): undefined reference to `base_DataziTuple_Z63T_con_info' collect2: ld returned 1 exit status }}} It seems that ghc internally creates a large tuple (63 elements) with the Serialize instances ? or something. The dumped core has some clues, I just can?t read them. Sorry for not testing this with a more up-to-date compiler, but I don?t have one handy. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 30 19:53:16 2008 From: trac at galois.com (GHC) Date: Sun Nov 30 19:46:46 2008 Subject: [GHC] #2440: Bad code with type families In-Reply-To: <041.36cfaf77666d90945b8031e68cebdd8a@localhost> References: <041.36cfaf77666d90945b8031e68cebdd8a@localhost> Message-ID: <050.0c3b2be708005d0aa3c7bc35c249f9ae@localhost> #2440: Bad code with type families -----------------------------------------+---------------------------------- Reporter: rl | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Comment (by batterseapower): Interesting. I can't find $wfoo, but I did find this suspicious looking function: {{{ a_smw :: forall s_afW. Foo.Vec s_afW -> GHC.Types.Int -> Foo.M (Foo.Vec s_afW) GHC.Types.Int [Arity 2 Str: DmdType U(L)L] a_smw = \ (@ s_afW) (ds_Xmw :: Foo.Vec s_afW) (n_Xgx :: GHC.Types.Int) -> case ds_Xmw of _ { Foo.Vec r_afZ [ALWAYS Just D(L)] -> (\ (s_ane :: GHC.Prim.State# s_afW) -> case r_afZ of _ { GHC.STRef.STRef var#_anJ [ALWAYS Just L] -> case GHC.Prim.readMutVar# @ s_afW @ GHC.Types.Int var#_anJ s_ane of _ { (# new_s_ank [ALWAYS Just L], r_anl [ALWAYS Just D(L)] #) -> (# new_s_ank, case r_anl of _ { GHC.Types.I# x_anS [ALWAYS Just L] -> case n_Xgx of _ { GHC.Types.I# y_anW [ALWAYS Just L] -> GHC.Types.I# (GHC.Prim.+# x_anS y_anW) } } #) } }) `cast` (trans (sym (GHC.ST.NTCo:ST s_afW GHC.Types.Int)) (trans (sym (trans (Foo.TFCo:R1:M s_afW) (sym (trans (trans (GHC.ST.ST s_afW) (GHC.ST.ST s_afW)) (GHC.ST.ST s_afW))))) (Foo.M (Foo.Vec s_afW)) GHC.Types.Int) :: GHC.ST.STRep s_afW GHC.Types.Int ~ Foo.M (Foo.Vec s_afW) GHC.Types.Int) } }}} We'd really like to give this an arity of 3, but GHC is currently not smart enough to eta-expand through this type coercion (see the final case of eta_expand in CoreUtils.lhs). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 30 21:17:22 2008 From: trac at galois.com (GHC) Date: Sun Nov 30 21:10:56 2008 Subject: [GHC] #2828: TcTyFuns.uMeta: normalisation shouldn't allow x ~ x In-Reply-To: <044.818395155a9d2081de37d5cedbd2ca16@localhost> References: <044.818395155a9d2081de37d5cedbd2ca16@localhost> Message-ID: <053.a06fb4ec926249a5757f1025daa195a1@localhost> #2828: TcTyFuns.uMeta: normalisation shouldn't allow x ~ x ----------------------+----------------------------------------------------- Reporter: pizza | Owner: chak Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Linux | Architecture: x86 ----------------------+----------------------------------------------------- Changes (by chak): * owner: => chak -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 30 23:12:44 2008 From: trac at galois.com (GHC) Date: Sun Nov 30 23:07:03 2008 Subject: [GHC] #1876: Complete shared library support In-Reply-To: <047.2ab772cd4150dcd51ba47e309570e649@localhost> References: <047.2ab772cd4150dcd51ba47e309570e649@localhost> Message-ID: <056.97c9ad02189b805b9d5ef52fbd0b27d2@localhost> #1876: Complete shared library support ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: clemens Type: task | Status: assigned Priority: high | Milestone: 6.10 branch Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Difficult (1 week) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by juhpetersen): * cc: petersen@haskell.org (added) Comment: Is there anything one can do to help with testing this? -- Ticket URL: GHC The Glasgow Haskell Compiler