From trac at galois.com Tue Apr 1 19:19:07 2008 From: trac at galois.com (GHC) Date: Tue Apr 1 19:15:07 2008 Subject: [GHC] #2181: internal error: END_TSO_QUEUE object entered! In-Reply-To: <047.dee38a6db16ff9d02335c0fd5c0c9f51@localhost> References: <047.dee38a6db16ff9d02335c0fd5c0c9f51@localhost> Message-ID: <056.de1abea0b137838080b6920bb0797176@localhost> #2181: internal error: END_TSO_QUEUE object entered! ----------------------+----------------------------------------------------- Reporter: cconnett | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: sparc Os: Solaris | ----------------------+----------------------------------------------------- Comment (by cconnett): I've attached a tarball of my project source. I'd narrow it down if I knew how to with haskell tools. `make` in the project directory should build the executable `Solve`. Run: `./Solve bf irv u-3-15` Changing `-optc-O3` to `-optc-O1` in the Makefile causes the bug not to occur. Let me know if I can assist in simplifying the code. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 2 01:56:52 2008 From: trac at galois.com (GHC) Date: Wed Apr 2 01:52:51 2008 Subject: [GHC] #2190: unionBuildInfo should not always use nub Message-ID: <042.a0e9a187aa60c1b3182a59d91c6dbe75@localhost> #2190: unionBuildInfo should not always use nub -----------------------------------+---------------------------------------- Reporter: prj | Owner: Type: bug | Status: new Priority: normal | Component: libraries (other) Version: 6.8.2 | Severity: normal Keywords: unionBuildInfo nub | Testcase: Architecture: Multiple | Os: Multiple -----------------------------------+---------------------------------------- In libraries/Cabal/Distribution/PackageDescription.hs, the unionBuildInfo function combines, for example, ldOptions from two BuildInfos, using nub to eliminate duplicate arguments. This is wrong for ldOptions and some other elements. For example, if ldOptions contains: {{{-Xlinker -R -Xlinker /dir1 -Xlinker -R -Xlinker /dir2}}} Then the nubbed result is: {{{-Xlinker -R /dir1 /dir2}}} which doesn't work at all. There may be some redundancy that could be eliminated, but for arguments passed to external programs, it can only be done safely by understanding the semantics of the arguments. Similarly for extraLibs, {{{-lfoo -lbar -lfoo}}} may be necessary if {{{libfoo}}} and {{{libbar}}} reference each other's symbols. Using nub is wrong for at least cppOptions, ccOptions, ldOptions, and extraLibs. But I think it is necessary for some other BuildInfo components, like hsSourceDirs, so it can't be removed completely; that results in an error while building GHC: {{{ Preprocessing library unix-2.3.0.0... Generating Makefile unix-2.3.0.0... Setup: makefile: can't cope with multiple hs-source-dirs yet, sorry }}} So {{{combine}}} could take an extra arguments, which would be nub in some cases or id in others. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 2 03:27:50 2008 From: trac at galois.com (GHC) Date: Wed Apr 2 03:23:57 2008 Subject: [GHC] #1475: Adding imports and exports with Template Haskell In-Reply-To: <044.e6912bf72a7a61e5dd62c8e0004e6c4e@localhost> References: <044.e6912bf72a7a61e5dd62c8e0004e6c4e@localhost> Message-ID: <053.3dec7dcb03ed94adbdd4c311d3cb03c1@localhost> #1475: Adding imports and exports with Template Haskell ------------------------------+--------------------------------------------- Reporter: igloo | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Template Haskell | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ------------------------------+--------------------------------------------- Comment (by simonpj): Whoa! Can you give more detail on your example? At the moment you definitely can't write a TH function that generates a Haskell module, compiles it, and imports it. You can generate those definitions in the current module though. Remember too that a TH definition can mention things in scope, and those things do not need to be imported where the TH function is called. Example {{{ module T(f) where import List f = [| null |] module Foo where import T h = $f }}} Here `$f` expands to `null`, but you do not need to import `List` in module `Foo`. In fact `$f` expands to `Data.List.null`, a kind of absolute reference to `null`. As the intro to this ticket says, TH-generated imports are really only useful for a form of dynamic binding. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 2 06:13:38 2008 From: trac at galois.com (GHC) Date: Wed Apr 2 06:09:46 2008 Subject: [GHC] #2151: GADTs in function Patterns In-Reply-To: <047.2f6478e8e827595da4825a54c1ec722c@localhost> References: <047.2f6478e8e827595da4825a54c1ec722c@localhost> Message-ID: <056.c441db784e3948ec256e5f91643cab76@localhost> #2151: GADTs in function Patterns ----------------------+----------------------------------------------------- Reporter: hpacheco | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: blocker | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ----------------------+----------------------------------------------------- Comment (by hpacheco): I found a workaround for this issue: define a sub-function that handles the erroneous pattern matching. I suggest using this style meanwhile. test :: Type a -> a -> a test (PF func) ID = aux func where aux :: Type (a -> a) -> a aux (Func _ _) = ID -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 2 11:58:29 2008 From: trac at galois.com (GHC) Date: Wed Apr 2 11:54:40 2008 Subject: [GHC] #1475: Adding imports and exports with Template Haskell In-Reply-To: <044.e6912bf72a7a61e5dd62c8e0004e6c4e@localhost> References: <044.e6912bf72a7a61e5dd62c8e0004e6c4e@localhost> Message-ID: <053.9db6cd7c3263f255dbb28db10692973c@localhost> #1475: Adding imports and exports with Template Haskell ------------------------------+--------------------------------------------- Reporter: igloo | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Template Haskell | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ------------------------------+--------------------------------------------- Comment (by m4dc4p): I don't need TH to dynamically create a module, compile it and import it in one go (though my message does imply that). Just being able to add import statements would be enough. Continuing with haskelldb, "table" definitions can be stored in separate modules. For example, If I have two tables, customers and orders, then they would normally be in the modules Acme.Customers and Acme.Orders. If I have a third module which defines all my queries, Acme.Queries, then I import the two tables as: {{{ module Acme.Queries where import qualified Acme.Customers as Customers import qualified Acme.Orders as Orders }}} Notice the qualified imports - those are necessary to avoid name clashes between the two modules (e.g., imagine if both tables have an ID column). As I add more tables, I need to add more import statements. Maybe I have a registration table: {{{ import qualified Acme.Registration as Registration }}} And so on, adding more and more clutter. Right now I have a file that imports about 15 "tables" and it's painful. I'd much rather have TH generate the import definition for me. For example: {{{ module Acme.Queries where $(importTables "Acme", ["Registration", "Customers", "Orders"]) }}} This becomes more important when you consider that I am trying to create a tool for other developers in my organization to use. They don't know Haskell, and I'd rather they didn't know they are learning Haskell until it's too late. Having to add these import statements would be a barrier for them. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 2 12:31:52 2008 From: trac at galois.com (GHC) Date: Wed Apr 2 12:27:48 2008 Subject: [GHC] #1423: compilation with profiling makes gcc run out of memory In-Reply-To: <044.607ca4a41a18c713e70e19a6ccf1c74d@localhost> References: <044.607ca4a41a18c713e70e19a6ccf1c74d@localhost> Message-ID: <053.e259019977db9e5b84caafcb74354fcd@localhost> #1423: compilation with profiling makes gcc run out of memory -----------------------------------------+---------------------------------- Reporter: guest | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.6 Severity: normal | Resolution: fixed Keywords: via-c gcc compile profile | Difficulty: Unknown Testcase: http://malde.org/~ketil/bio | Architecture: x86 Os: Linux | -----------------------------------------+---------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: No problems here with 6.8.2 and a 200M ulimit. The default is now `-fasm`, but even specifying `-fvia-C` it was fine. If you're still having problems, please reopen this report (or open a new one if that seems more appropriate). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 2 13:17:00 2008 From: trac at galois.com (GHC) Date: Wed Apr 2 13:12:59 2008 Subject: [GHC] #2171: Parallel program crashes In-Reply-To: <042.91539dd5667f046cb861faa36a106615@localhost> References: <042.91539dd5667f046cb861faa36a106615@localhost> Message-ID: <051.3822a577e0d7865b37a31c5f0c24eec4@localhost> #2171: Parallel program crashes ---------------------------------------------+------------------------------ Reporter: fed | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: critical | Resolution: Keywords: parallel, crash, race condition | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ---------------------------------------------+------------------------------ Changes (by igloo): * os: Windows => Multiple * architecture: x86 => Multiple Comment: Thanks judah! And that also means it's not a Windows-only problem, which is useful info. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 2 13:58:48 2008 From: trac at galois.com (GHC) Date: Wed Apr 2 13:54:53 2008 Subject: [GHC] #2181: internal error: END_TSO_QUEUE object entered! In-Reply-To: <047.dee38a6db16ff9d02335c0fd5c0c9f51@localhost> References: <047.dee38a6db16ff9d02335c0fd5c0c9f51@localhost> Message-ID: <056.780c0e2a135b6bfa6cad08a1da99c5db@localhost> #2181: internal error: END_TSO_QUEUE object entered! ----------------------+----------------------------------------------------- Reporter: cconnett | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: sparc Os: Solaris | ----------------------+----------------------------------------------------- Comment (by igloo): Can you send the output of `ghc --info` please? If it's a registerised compiler then we don't support changing the optimisations that gcc does, as the assembly mangling we do may get confused. On the other hand, if it's unregisterised then it points to a bug either in gcc or the code that we generate. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 2 14:11:42 2008 From: trac at galois.com (GHC) Date: Wed Apr 2 14:07:38 2008 Subject: [GHC] #2190: unionBuildInfo should not always use nub In-Reply-To: <042.a0e9a187aa60c1b3182a59d91c6dbe75@localhost> References: <042.a0e9a187aa60c1b3182a59d91c6dbe75@localhost> Message-ID: <051.0258c4da7975c087d7c56f34cda6a45f@localhost> #2190: unionBuildInfo should not always use nub --------------------------------+------------------------------------------- Reporter: prj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries (other) | Version: 6.8.2 Severity: normal | Resolution: invalid Keywords: unionBuildInfo nub | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | --------------------------------+------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: Thanks for the report. I've refiled it as a Cabal bug here: http://hackage.haskell.org/trac/hackage/ticket/264 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 2 15:17:47 2008 From: trac at galois.com (GHC) Date: Wed Apr 2 15:14:33 2008 Subject: [GHC] #2181: internal error: END_TSO_QUEUE object entered! In-Reply-To: <047.dee38a6db16ff9d02335c0fd5c0c9f51@localhost> References: <047.dee38a6db16ff9d02335c0fd5c0c9f51@localhost> Message-ID: <056.6302682045130e940c6c1ffa56faef9f@localhost> #2181: internal error: END_TSO_QUEUE object entered! ----------------------+----------------------------------------------------- Reporter: cconnett | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: sparc Os: Solaris | ----------------------+----------------------------------------------------- Comment (by cconnett): [("Project name","The Glorious Glasgow Haskell Compilation System") ,("Project version","6.8.2") ,("Booter version","6.8.1") ,("Stage","2") ,("Interface file version","6") ,("Have interpreter","YES") ,("Object splitting","YES") ,("Have native code generator","NO") ,("Support SMP","YES") ,("Unregisterised","NO") ,("Tables next to code","YES") ,("Win32 DLLs","") ,("RTS ways"," debug thr thr_p thr_debug") ,("Leading underscore","NO") ] -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 2 15:33:42 2008 From: trac at galois.com (GHC) Date: Wed Apr 2 15:29:40 2008 Subject: [GHC] #881: Improve space profiling for references In-Reply-To: <046.89fda28d10e4c9bf9885adf9e31162cb@localhost> References: <046.89fda28d10e4c9bf9885adf9e31162cb@localhost> Message-ID: <055.5b9246cbbaa3206c621015ef5af2d00d@localhost> #881: Improve space profiling for references -----------------------------+---------------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Profiling | Version: 6.4.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Comment (by SamB): Isn't the problem here that the retainer profiling is stopping at the IORef and writing the memory off as retained by "SYSTEM", when it should go back and find out who retains the IORef? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 2 15:44:07 2008 From: trac at galois.com (GHC) Date: Wed Apr 2 15:40:03 2008 Subject: [GHC] #2191: A way to programmatically cause GHC to report the cost center stack associated with a value Message-ID: <043.3641dba02e220ac3643aa7a87adf7815@localhost> #2191: A way to programmatically cause GHC to report the cost center stack associated with a value --------------------------------+------------------------------------------- Reporter: SamB | Owner: Type: feature request | Status: new Priority: normal | Component: Profiling Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- I find that I often wish I could ask GHC to tell me "where did *that* value come from?" as I debug JHC. Since GHC obviously can track this information, it seems like it would be fairly simple to implement a way for it to report this information as instructed by a running program. Perhaps: reportCssFor :: a -> b -> b I wouldn't really have any desire to use this on thunks, since when I want to do this it is usually because I don't like the value (i.e. it isn't in the right normal form), and to know this I must already have evaluated it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 2 19:19:21 2008 From: trac at galois.com (GHC) Date: Wed Apr 2 19:15:23 2008 Subject: [GHC] #1947: Segmentation fault/access violation in generated code In-Reply-To: <051.7113ffd85120a95cf3f282877a678b8a@localhost> References: <051.7113ffd85120a95cf3f282877a678b8a@localhost> Message-ID: <060.a6bb310fc1ec1a609c86b0eace73626b@localhost> #1947: Segmentation fault/access violation in generated code --------------------------+------------------------------------------------- Reporter: NeilMitchell | Owner: igloo Type: task | Status: closed Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: simplrun010 | Architecture: x86 Os: Windows | --------------------------+------------------------------------------------- Changes (by igloo): * testcase: => simplrun010 * status: new => closed * resolution: => fixed Comment: I couldn't reproduce the problem with 6.8.2, but I have now added the program as test `simplrun010` nevertheless. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 2 21:50:56 2008 From: trac at galois.com (GHC) Date: Wed Apr 2 21:47:04 2008 Subject: [GHC] #2191: A way to programmatically cause GHC to report the cost center stack associated with a value In-Reply-To: <043.3641dba02e220ac3643aa7a87adf7815@localhost> References: <043.3641dba02e220ac3643aa7a87adf7815@localhost> Message-ID: <052.39c32935b1fbf1242d178f7cf1dda7db@localhost> #2191: A way to programmatically cause GHC to report the cost center stack associated with a value --------------------------------+------------------------------------------- Reporter: SamB | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Profiling | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- Changes (by tim): * cc: chevalier@alum.wellesley.edu (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 2 22:45:07 2008 From: trac at galois.com (GHC) Date: Wed Apr 2 22:41:03 2008 Subject: [GHC] #907: Case sensitive ghci commands In-Reply-To: <058.4e67421e94a7459b62b3dc5e5c82730f@localhost> References: <058.4e67421e94a7459b62b3dc5e5c82730f@localhost> Message-ID: <067.3b1c6df23be8fa6309bb3489c89f46bc@localhost> #907: Case sensitive ghci commands ---------------------------------+------------------------------------------ Reporter: br1@internet.com.uy | Owner: Type: feature request | Status: new Priority: lowest | Milestone: _|_ Component: GHCi | Version: 6.4.1 Severity: trivial | Resolution: Keywords: case command colon | Difficulty: Easy (1 hr) Testcase: N/A | Architecture: Unknown Os: Unknown | ---------------------------------+------------------------------------------ Comment (by SamB): FWIW, I don't think most of us care one way or the other; probably the only people who care are those who want it case-insensitive? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 2 22:55:12 2008 From: trac at galois.com (GHC) Date: Wed Apr 2 22:51:07 2008 Subject: [GHC] #788: Class aliases (as proposaed by John Meacham) In-Reply-To: <046.352573f276ea0b65a1451eea70e3a225@localhost> References: <046.352573f276ea0b65a1451eea70e3a225@localhost> Message-ID: <055.38d6434604d9a3b6b61acfc104f737b7@localhost> #788: Class aliases (as proposaed by John Meacham) -----------------------------+---------------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: N/A | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Comment (by SamB): Note that the class alias proposal seems to have some syntax errors. I found these in trying to implement class aliases in John's own compiler, JHC -- which I haven't given up on yet, but I am sidetracked fixing (->) for now... -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Apr 3 03:40:37 2008 From: trac at galois.com (GHC) Date: Thu Apr 3 03:36:31 2008 Subject: [GHC] #2141: Internal error on invalid record update In-Reply-To: <041.12bd6af75f291bf77b61c12a037ef054@localhost> References: <041.12bd6af75f291bf77b61c12a037ef054@localhost> Message-ID: <050.4298fc00a55b4899c000545ea1e26ce9@localhost> #2141: Internal error on invalid record update -------------------------------------+-------------------------------------- Reporter: rl | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Changes (by simonpj): * owner: => simonpj Comment: I'm fixing this. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Apr 3 03:41:12 2008 From: trac at galois.com (GHC) Date: Thu Apr 3 03:37:07 2008 Subject: [GHC] #2137: Location of shadowed binding is wrong in warning In-Reply-To: <044.44ee490b4171e22911243bf12a9d127e@localhost> References: <044.44ee490b4171e22911243bf12a9d127e@localhost> Message-ID: <053.0e24a73a617d38f4d367c235e7e04a25@localhost> #2137: Location of shadowed binding is wrong in warning ----------------------+----------------------------------------------------- Reporter: igloo | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: rn064 | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonpj): * owner: => simonpj Comment: I'm fixing this -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Apr 3 03:41:44 2008 From: trac at galois.com (GHC) Date: Thu Apr 3 03:37:37 2008 Subject: [GHC] #2136: Not warned about unused recursive bindings In-Reply-To: <044.36da76cdb274dec6c2086dc5b0767ee6@localhost> References: <044.36da76cdb274dec6c2086dc5b0767ee6@localhost> Message-ID: <053.0455a8e0f488918e61d5efa711f26cd5@localhost> #2136: Not warned about unused recursive bindings ----------------------+----------------------------------------------------- Reporter: igloo | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: rn063 | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonpj): * owner: => simonpj Comment: I'm fixing this -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 4 17:00:20 2008 From: trac at galois.com (GHC) Date: Fri Apr 4 16:57:02 2008 Subject: [GHC] #783: performance problem compiling large file In-Reply-To: <044.a7a580fed8a85952633cd84570dae070@localhost> References: <044.a7a580fed8a85952633cd84570dae070@localhost> Message-ID: <053.d3936bf0fd57aeb22cdd60ffc79d89c5@localhost> #783: performance problem compiling large file ------------------------------------------+--------------------------------- Reporter: guest | Owner: igloo Type: compile-time performance bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.4.2 Severity: normal | Resolution: Keywords: performance | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ------------------------------------------+--------------------------------- Changes (by igloo): * type: merge => compile-time performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 4 17:13:32 2008 From: trac at galois.com (GHC) Date: Fri Apr 4 17:09:29 2008 Subject: [GHC] #2181: internal error: END_TSO_QUEUE object entered! In-Reply-To: <047.dee38a6db16ff9d02335c0fd5c0c9f51@localhost> References: <047.dee38a6db16ff9d02335c0fd5c0c9f51@localhost> Message-ID: <056.82c06337435792484825488dbd575499@localhost> #2181: internal error: END_TSO_QUEUE object entered! ----------------------+----------------------------------------------------- Reporter: cconnett | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: sparc Os: Solaris | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => invalid Comment: OK, so that says that it's not unregisterised, and therefore using `-optc-O3` isn't supported. If you stick with passing just `-O` of `-O2` to GHC then it should work. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 4 17:14:11 2008 From: trac at galois.com (GHC) Date: Fri Apr 4 17:10:09 2008 Subject: [GHC] #2179: Improve error message when `main' is not of the right type In-Reply-To: <047.bbe528ebb3bf93f65afc730c1ab28125@localhost> References: <047.bbe528ebb3bf93f65afc730c1ab28125@localhost> Message-ID: <056.95c65ef17c579a06048a0242fc3f13e2@localhost> #2179: Improve error message when `main' is not of the right type ----------------------+----------------------------------------------------- Reporter: amiddelk | Owner: simonpj Type: proposal | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: trivial | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------+----------------------------------------------------- Changes (by simonpj): * owner: => simonpj Comment: I'm fixing this -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 4 17:15:16 2008 From: trac at galois.com (GHC) Date: Fri Apr 4 17:11:06 2008 Subject: [GHC] #2188: TH scoping problem In-Reply-To: <044.2bbd6efb87952e5e65fa7406d244cf0e@localhost> References: <044.2bbd6efb87952e5e65fa7406d244cf0e@localhost> Message-ID: <053.8cc3a50a4f8021bf63a83631281e43f2@localhost> #2188: TH scoping problem ------------------------------+--------------------------------------------- Reporter: igloo | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Template Haskell | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: TH_scope | Architecture: Unknown Os: Unknown | ------------------------------+--------------------------------------------- Changes (by simonpj): * owner: => simonpj Comment: I'm fixing this. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 4 17:18:06 2008 From: trac at galois.com (GHC) Date: Fri Apr 4 17:14:09 2008 Subject: [GHC] #783: performance problem compiling large file In-Reply-To: <044.a7a580fed8a85952633cd84570dae070@localhost> References: <044.a7a580fed8a85952633cd84570dae070@localhost> Message-ID: <053.7baf67643556d0cc91692843ba60f072@localhost> #783: performance problem compiling large file ------------------------------------------+--------------------------------- Reporter: guest | Owner: Type: compile-time performance bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.4.2 Severity: normal | Resolution: Keywords: performance | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ------------------------------------------+--------------------------------- Changes (by igloo): * owner: igloo => -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 4 17:51:58 2008 From: trac at galois.com (GHC) Date: Fri Apr 4 17:47:53 2008 Subject: [GHC] #2192: occasional segmentation faults when using Control.Parallel Message-ID: <044.41e146963f3d21c260430274434fb250@localhost> #2192: occasional segmentation faults when using Control.Parallel -----------------------+---------------------------------------------------- Reporter: ivant | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: Linux -----------------------+---------------------------------------------------- The attached program fails quite often with segmentation faults or internal errors (unpredictably, in consecutive runs, without changing the source): {{{ % time ./parallel +RTS -N2 zsh: segmentation fault (core dumped) ./parallel +RTS -N2 ./parallel +RTS -N2 2.79s user 0.42s system 107% cpu 2.988 total % time ./parallel +RTS -N2 parallel: internal error: evacuate: strange closure type 65284 (GHC version 6.8.2 for i386_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./parallel +RTS -N2 ./parallel +RTS -N2 3.60s user 0.51s system 108% cpu 3.781 total % time ./parallel +RTS -N2 zsh: segmentation fault (core dumped) ./parallel +RTS -N2 ./parallel +RTS -N2 5.09s user 0.46s system 111% cpu 4.982 total % time ./parallel +RTS -N2 500000 ./parallel +RTS -N2 8.34s user 0.14s system 108% cpu 7.796 total }}} The program can fail both when it is compiled with and without -O2. Changing the value of maxSparks makes a difference (with value 2 it is finishing successfully always (or probably more often)). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 4 18:00:08 2008 From: trac at galois.com (GHC) Date: Fri Apr 4 17:56:10 2008 Subject: [GHC] #2192: occasional segmentation faults when using Control.Parallel In-Reply-To: <044.41e146963f3d21c260430274434fb250@localhost> References: <044.41e146963f3d21c260430274434fb250@localhost> Message-ID: <053.09ccd4f6a3e5f3c9f9539f6dfbb3a3e3@localhost> #2192: occasional segmentation faults when using Control.Parallel -------------------------+-------------------------------------------------- Reporter: ivant | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: major | Resolution: Keywords: par | Testcase: Architecture: x86 | Os: Linux -------------------------+-------------------------------------------------- Changes (by dons): * keywords: => par * severity: normal => major Comment: I wasn't able to reproduce this on OpenBSD/amd64 with ghc 6.8.2. The program runs to completion: {{{ $ ./A +RTS -N2 500000 }}} On a 4 core linux box, however, I triggered some faults: {{{ $ ./A +RTS -N2 500000 $ ./A +RTS -N2 A: internal error: evacuate: strange closure type 23552 (GHC version 6.8.1.20071114 for i386_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug $ ./A +RTS -N4 zsh: segmentation fault ./A +RTS -N4 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 4 18:35:42 2008 From: trac at galois.com (GHC) Date: Fri Apr 4 18:31:31 2008 Subject: [GHC] #2193: Monomorphic Pattern Bindings and Error Messages Message-ID: <043.34ccdeb27bebe4aa866d2df9503f28c8@localhost> #2193: Monomorphic Pattern Bindings and Error Messages -------------------------+-------------------------------------------------- Reporter: sclv | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Multiple | Os: Multiple -------------------------+-------------------------------------------------- Not clear to me if the following should be a type error or if it should be allowed to unify properly. In either case, the error message is borked. {{{ {-# OPTIONS -fglasgow-exts #-} module Test where data Foo x y = Foo {foo1 :: x, foo2 :: y} instance Functor (Foo x) where fmap f (Foo x y) = Foo x (f y) bar :: a -> Foo (forall s. s) a bar a = Foo undefined a main = print (foo2 (fmap (*2) (bar 2))) {- sclv.hs:12:20: Cannot match a monotype with `forall s. s' When matching `forall s. s' and `forall s. s' Expected type: Foo (forall s1. s1) a Inferred type: Foo (forall s1. s1) a In the first argument of `foo2', namely `(fmap ((* 2)) (bar 2))' -} }}} {{{ *Test> :t bar (2 :: Integer) bar (2 :: Integer) :: Foo (forall s. s) Integer *Test> :t foo2 (bar (2 :: Integer)) foo2 (bar (2 :: Integer)) :: Integer *Test> :t fmap (*2) (bar (2 :: Integer)) fmap (*2) (bar (2 :: Integer)) :: Foo (forall s. s) Integer *Test> :t foo2 (fmap (*2) (bar (2 :: Integer))) :1:6: Cannot match a monotype with `forall s. s' When matching `forall s. s' and `forall s. s' Expected type: Foo (forall s1. s1) Integer Inferred type: Foo (forall s1. s1) Integer In the first argument of `foo2', namely `(fmap ((* 2)) (bar (2 :: Integer)))' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 4 19:11:06 2008 From: trac at galois.com (GHC) Date: Fri Apr 4 19:06:58 2008 Subject: [GHC] #1657: throwTo + unsafeInterleaveIO oddness In-Reply-To: <044.21440a48538e444ebfd4d18aeba61e97@localhost> References: <044.21440a48538e444ebfd4d18aeba61e97@localhost> Message-ID: <053.d24d4c2b49944bbfe895160c3ddf393d@localhost> #1657: throwTo + unsafeInterleaveIO oddness ----------------------------+----------------------------------------------- Reporter: guest | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Runtime System | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------------+----------------------------------------------- Changes (by igloo): * owner: => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Apr 5 01:43:19 2008 From: trac at galois.com (GHC) Date: Sat Apr 5 01:39:08 2008 Subject: [GHC] #2194: internal error: R_X86_64_32 relocation out of range Message-ID: <046.dc336ddb5330040c8ab47ea2ef281042@localhost> #2194: internal error: R_X86_64_32 relocation out of range -------------------------------+-------------------------------------------- Reporter: alatter | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Linux -------------------------------+-------------------------------------------- $ ghci Stub.hs Whirlpool.o GHCi, version 6.8.2.20080316: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Loading object (static) Whirlpool.o ... done ghc-6.8.2.20080316: internal error: R_X86_64_32 relocation out of range: (noname) = 0x7fc20c2c3010 (GHC version 6.8.2.20080316 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) ----- I'm running Ubuntu 8.4 Beta on some sort of Intel 64-bit platform (Core, maybe?). To reproduce, you'll want the files from http://planeta.terra.com.br/informatica/paulobarreto/whirlpool.zip And in the same directory, the attached files Stub.hs and Whirlpool.h (not needed just to compile the .c file, but it makes the haskell FFI happy). There are a couple things I tried First: $ gcc Whirlpool.c -c $ ghci Stub Whirlpool.o Second: $ rm *.o $ ghc --make Stub Whirlpool.c $ ghci Stub Whirlpool.o -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Apr 5 05:24:27 2008 From: trac at galois.com (GHC) Date: Sat Apr 5 05:20:17 2008 Subject: [GHC] #2141: Internal error on invalid record update In-Reply-To: <041.12bd6af75f291bf77b61c12a037ef054@localhost> References: <041.12bd6af75f291bf77b61c12a037ef054@localhost> Message-ID: <050.719793d205f6194a00c47799f5ff2565@localhost> #2141: Internal error on invalid record update -------------------------------------+-------------------------------------- Reporter: rl | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Changes (by simonpj): * owner: simonpj => igloo * type: bug => merge Comment: Fixed by {{{ Wed Apr 2 06:20:57 PDT 2008 simonpj@microsoft.com * Fix Trac #2141: invalid record update }}} Ian: can you add a test case as well as merging? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Apr 5 05:25:34 2008 From: trac at galois.com (GHC) Date: Sat Apr 5 05:21:23 2008 Subject: [GHC] #2137: Location of shadowed binding is wrong in warning In-Reply-To: <044.44ee490b4171e22911243bf12a9d127e@localhost> References: <044.44ee490b4171e22911243bf12a9d127e@localhost> Message-ID: <053.6a687b7bc8291fc6e9fb32b71d797812@localhost> #2137: Location of shadowed binding is wrong in warning ----------------------+----------------------------------------------------- Reporter: igloo | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: rn064 | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonpj): * owner: simonpj => igloo * type: bug => merge Comment: Fixed by {{{ Wed Apr 2 08:34:10 PDT 2008 simonpj@microsoft.com * Fix Trac #2137: report correct location for shadowed binding }}} Ian: can you change the test to 'should pass'? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Apr 5 05:27:00 2008 From: trac at galois.com (GHC) Date: Sat Apr 5 05:22:49 2008 Subject: [GHC] #2136: Not warned about unused recursive bindings In-Reply-To: <044.36da76cdb274dec6c2086dc5b0767ee6@localhost> References: <044.36da76cdb274dec6c2086dc5b0767ee6@localhost> Message-ID: <053.803e54ac4a3873a677801846a9e286c7@localhost> #2136: Not warned about unused recursive bindings ----------------------+----------------------------------------------------- Reporter: igloo | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: rn063 | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonpj): * owner: simonpj => igloo * type: bug => merge Comment: Fixed by {{{ Thu Apr 3 04:02:50 PDT 2008 simonpj@microsoft.com * Fix Trac #2136: reporting of unused variables }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Apr 5 05:28:09 2008 From: trac at galois.com (GHC) Date: Sat Apr 5 05:24:08 2008 Subject: [GHC] #2179: Improve error message when `main' is not of the right type In-Reply-To: <047.bbe528ebb3bf93f65afc730c1ab28125@localhost> References: <047.bbe528ebb3bf93f65afc730c1ab28125@localhost> Message-ID: <056.3f855064aa74df99445485e6cbda5b72@localhost> #2179: Improve error message when `main' is not of the right type ----------------------+----------------------------------------------------- Reporter: amiddelk | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: trivial | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------+----------------------------------------------------- Changes (by simonpj): * owner: simonpj => igloo * type: proposal => merge Comment: Fixed by {{{ Thu Apr 3 10:37:46 PDT 2008 simonpj@microsoft.com * Fix Trac #2179: error message for main }}} Ian, can you add a test case please? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Apr 5 05:29:03 2008 From: trac at galois.com (GHC) Date: Sat Apr 5 05:24:50 2008 Subject: [GHC] #2188: TH scoping problem In-Reply-To: <044.2bbd6efb87952e5e65fa7406d244cf0e@localhost> References: <044.2bbd6efb87952e5e65fa7406d244cf0e@localhost> Message-ID: <053.590342dfbfe029db16f923d9479cff11@localhost> #2188: TH scoping problem ------------------------------+--------------------------------------------- Reporter: igloo | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10 branch Component: Template Haskell | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: TH_scope | Architecture: Unknown Os: Unknown | ------------------------------+--------------------------------------------- Changes (by simonpj): * owner: simonpj => igloo * type: bug => merge Comment: Fixed by {{{ Fri Apr 4 13:55:56 PDT 2008 simonpj@microsoft.com * Fix Trac #2188: scoping in TH declarations quotes }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Apr 5 12:05:36 2008 From: trac at galois.com (GHC) Date: Sat Apr 5 12:01:31 2008 Subject: [GHC] #1717: ghc-6.8 configure does not recognise 32bit userland on ppc64 In-Reply-To: <059.9ba98474c2b63eccc55349ae913ba846@localhost> References: <059.9ba98474c2b63eccc55349ae913ba846@localhost> Message-ID: <068.b4e4f3efa69c0d7f3e48011b428b1906@localhost> #1717: ghc-6.8 configure does not recognise 32bit userland on ppc64 ----------------------------------+----------------------------------------- Reporter: kahl@cas.mcmaster.ca | Owner: Type: bug | Status: reopened Priority: normal | Milestone: 6.10 branch Component: Build System | Version: 6.8 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: normal build | Architecture: powerpc64 Os: Linux | ----------------------------------+----------------------------------------- Changes (by igloo): * milestone: 6.8.3 => 6.10 branch Comment: It looks like some normalisation would be necessary: {{{ ian@matrix:~$ uname -m i686 ian@matrix:~$ gcc -dumpmachine i486-linux-gnu }}} {{{ $ uname -m i686 $ gcc -dumpmachine mingw32 }}} I'm moving this to the 6.10 branch, as I don't think there's much advantage to doing this in 6.8.3, but there is the potential for the build to abort in some cases that are OK but that we didn't test. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Apr 5 13:53:35 2008 From: trac at galois.com (GHC) Date: Sat Apr 5 13:49:22 2008 Subject: [GHC] #2045: Link error when compiling with -fhpc In-Reply-To: <044.3e291c48a73368cfaa2c03d4b6685800@localhost> References: <044.3e291c48a73368cfaa2c03d4b6685800@localhost> Message-ID: <053.65cbfe2f3be06c5ab67644750e23f3d3@localhost> #2045: Link error when compiling with -fhpc ----------------------+----------------------------------------------------- Reporter: guest | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * owner: => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Apr 5 16:46:13 2008 From: trac at galois.com (GHC) Date: Sat Apr 5 16:42:00 2008 Subject: [GHC] #2045: Link error when compiling with -fhpc In-Reply-To: <044.3e291c48a73368cfaa2c03d4b6685800@localhost> References: <044.3e291c48a73368cfaa2c03d4b6685800@localhost> Message-ID: <053.9d9e7c877569e4244651fa3fc663a4c9@localhost> #2045: Link error when compiling with -fhpc ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * owner: igloo => Comment: `Vhdl.hs` is a small, self-contained example. Compile with: {{{ ghc --make Vhdl.hs -o gencirc }}} As I understand it GHC is supposed to generate large tuples and then have them disappear later on. My guess is that the HPC ticks are interfering with the elimination, but I'm not sure where that is supposed to happen. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Apr 5 17:11:58 2008 From: trac at galois.com (GHC) Date: Sat Apr 5 17:07:45 2008 Subject: [GHC] #2195: yi: internal error: R_X86_64_PC32 relocation out of range: (noname) = 0x7c436730a Message-ID: <044.cc96d7cce62f73d5dee217e7be0e7f3f@localhost> #2195: yi: internal error: R_X86_64_PC32 relocation out of range: (noname) = 0x7c436730a -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: linker | Testcase: Architecture: x86_64 (amd64) | Os: FreeBSD -------------------------------+-------------------------------------------- FreeBSD 7.0 kmacy@pandemonium [~/devel/tmp/yi-0.3|14:09|30] yi Loading package base ... linking ... done. Loading package array-0.1.0.0 ... linking ... done. Loading package bytestring-0.9.0.1 ... linking ... done. Loading package regex-base-0.72.0.1 ... linking ... done. Loading package regex-posix-0.72.0.2 ... linking ... done. Loading package regex-compat-0.71.0.1 ... linking ... done. Loading package fingertree-0.0 ... linking ... done. Loading package mtl-1.1.0.0 ... linking ... done. Loading package glib-0.9.12.1 ... linking ... done. Loading package cairo-0.9.12.1 ... linking ... done. Loading package containers-0.1.0.1 ... linking ... done. yi: internal error: R_X86_64_PC32 relocation out of range: (noname) = 0x7c436730a (GHC version 6.8.2 for x86_64_unknown_freebsd) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) yi backtrace of core is ~2500 frames of rubbish -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Apr 5 18:03:31 2008 From: trac at galois.com (GHC) Date: Sat Apr 5 17:59:18 2008 Subject: [GHC] #2044: "Can't unify" error in debugger In-Reply-To: <044.9de84d1571c81bf2b4030ee1192776b2@localhost> References: <044.9de84d1571c81bf2b4030ee1192776b2@localhost> Message-ID: <053.7f925207ec41e6b7a541fcefdbe6b14f@localhost> #2044: "Can't unify" error in debugger --------------------+------------------------------------------------------- Reporter: r6144 | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | --------------------+------------------------------------------------------- Changes (by igloo): * owner: => simonpj Comment: ...but not with the HEAD. This program: {{{ {-# LANGUAGE ScopedTypeVariables, ExistentialQuantification #-} import Control.Monad.ST.Strict import Data.Array.ST rsRandom :: ST s a rsRandom = undefined write :: Int -> ST s (forall ss . (STUArray ss Int Double) -> ST ss ()) write i = rsRandom >>= \x -> return (\buf -> writeArray buf i x) }}} is accepted by the 6.8 branch, but not the HEAD. I'd expect it to be rejected too (`x` is monomorphic, and generalisation won't make a higher rank type), so I think the HEAD is right, but I will let Simon PJ have the last word... I don't think this is worth fixing just for 6.8.3, unless there are other programs that the HEAD also accepts that trigger the problem, so if the program ought to be rejected then I think that we can close this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Apr 5 18:53:03 2008 From: trac at galois.com (GHC) Date: Sat Apr 5 18:48:49 2008 Subject: [GHC] #2015: SOE samples crash when running from ghci rather than compiling and running with ghc In-Reply-To: <047.485ea5c57b8e879f2c33305a489b8545@localhost> References: <047.485ea5c57b8e879f2c33305a489b8545@localhost> Message-ID: <056.5037571e017862704357747d84e8c3e8@localhost> #2015: SOE samples crash when running from ghci rather than compiling and running with ghc ----------------------+----------------------------------------------------- Reporter: justinhj | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.8.3 Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: worksforme Keywords: SOE ghci | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Windows | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => worksforme Comment: It works fine for me, with GLFW installed using Cabal: {{{ C:\cygwin\home\ian\soe\SOE\src>ghci Snowflake.lhs GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. [1 of 2] Compiling SOE ( SOE.hs, interpreted ) [2 of 2] Compiling Snowflake ( Snowflake.lhs, interpreted ) Ok, modules loaded: SOE, Snowflake. *Snowflake> main Loading package OpenGL-2.2.1.1 ... linking ... done. Loading package GLFW-0.3 ... linking ... done. Loading package old-locale-1.0.0.0 ... linking ... done. Loading package old-time-1.0.0.0 ... linking ... done. }}} I don't know what your `test.hs` is; SOE doesn't seem to come with one. I notice that your GLFW is an older version than mine, so perhaps this problem has been fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Apr 5 20:28:46 2008 From: trac at galois.com (GHC) Date: Sat Apr 5 20:24:32 2008 Subject: [GHC] #2196: Errors in output from formatTime Message-ID: <044.a53cada5d60b5b73662375cb432c3e02@localhost> #2196: Errors in output from formatTime -------------------------+-------------------------------------------------- Reporter: laney | Owner: Type: bug | Status: new Priority: normal | Component: libraries (other) Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Multiple | Os: Unknown -------------------------+-------------------------------------------------- Hi, I have discovered two errors in the Date/Time libraries distributed with GHC. When running the attached testcase: *Main> timebug Loading package old-locale-1.0.0.0 ... linking ... done. Loading package time-1.1.2.0 ... linking ... done. "Sun, d Apr 2008 00:16:45 UTC" There are two problems here: * Returns "d" for day of month, certainly not right. * Returns "UTC" instead of "UT", incorrect per RFC 822 - http://www.faqs.org/rfcs/rfc822.html section 5.1 Iain -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Apr 5 20:38:06 2008 From: trac at galois.com (GHC) Date: Sat Apr 5 20:34:04 2008 Subject: [GHC] #2083: linker reports missing symbols Main.c:(.text+0x12): undefined reference to `__stginit_ZCMain' In-Reply-To: <054.f4411cf09d2804f4c2a24a7055f19618@localhost> References: <054.f4411cf09d2804f4c2a24a7055f19618@localhost> Message-ID: <063.523b92678fe39880bbb668f087fcf2da@localhost> #2083: linker reports missing symbols Main.c:(.text+0x12): undefined reference to `__stginit_ZCMain' -----------------------------+---------------------------------------------- Reporter: Andrew U. Frank | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: worksforme Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => worksforme Comment: No reply from submitter, and probably caused by an incorrect module header, so closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Apr 5 20:39:07 2008 From: trac at galois.com (GHC) Date: Sat Apr 5 20:34:53 2008 Subject: [GHC] #2084: GHC panic In-Reply-To: <047.2af7ef94b11d6e7558fa16d6fcecb781@localhost> References: <047.2af7ef94b11d6e7558fa16d6fcecb781@localhost> Message-ID: <056.a8b20380ad3f6afb1e34178139ca18c2@localhost> #2084: GHC panic ----------------------+----------------------------------------------------- Reporter: stimberm | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => invalid Comment: No response from submitter, and no testcase, so closing bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Apr 5 23:10:12 2008 From: trac at galois.com (GHC) Date: Sat Apr 5 23:05:57 2008 Subject: [GHC] #2197: GHCi doesn't work when built with way=p Message-ID: <043.8ca8ccba553cfe5b0f79906ba5d25b8c@localhost> #2197: GHCi doesn't work when built with way=p ------------------------+--------------------------------------------------- Reporter: SamB | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Linux ------------------------+--------------------------------------------------- I don't really mind so much that Cabal etc. don't support building GHCi profiling libs (it would be easy enough to do by hand), but the fact that GHCi tries to load the un-profiling GHCi libs is a bit annoying... it doesn't work too well... naesten@hydrogen:~/hacking/haskell/ghc-hashedrepo% ./compiler/stage2/ghc- inplace_p --interactive GHCi, version 6.9.20080305: http://www.haskell.org/ghc/ :? for help ghc_p-6.9.20080305: /home/naesten/hacking/haskell/ghc-hashedrepo/libraries /ghc-prim/dist/build/HSghc-prim-0.1.o: unknown symbol `traceCcszh_fast' Loading package ghc-prim ... linking ... ghc_p-6.9.20080305: unable to load package `ghc-prim' -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Apr 5 23:12:55 2008 From: trac at galois.com (GHC) Date: Sat Apr 5 23:08:41 2008 Subject: [GHC] #2197: GHCi doesn't work when built with way=p In-Reply-To: <043.8ca8ccba553cfe5b0f79906ba5d25b8c@localhost> References: <043.8ca8ccba553cfe5b0f79906ba5d25b8c@localhost> Message-ID: <052.df7b821f9805ae697d1a9b2ef7e3a19f@localhost> #2197: GHCi doesn't work when built with way=p ------------------------+--------------------------------------------------- Reporter: SamB | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.9 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Linux ------------------------+--------------------------------------------------- Comment (by SamB): Btw, the symbol mentioned in the error is from something I'm working on... but the non_p ghci loads fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Apr 5 23:22:58 2008 From: trac at galois.com (GHC) Date: Sat Apr 5 23:18:43 2008 Subject: [GHC] #1580: Get GHC happy with alternate base packages (split base) In-Reply-To: <043.678042925abbf66332cc75519a97afa0@localhost> References: <043.678042925abbf66332cc75519a97afa0@localhost> Message-ID: <052.b0621229af76d68a9986101292ed4442@localhost> #1580: Get GHC happy with alternate base packages (split base) ----------------------+----------------------------------------------------- Reporter: SamB | Owner: Type: task | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by SamB): Replying to [comment:1 igloo]: > Other than splitting up base (#1338), I'm not clear on exactly what you want. Is it more rebindable syntax? For example, the wiki page you point at says you want to replace Read, but I'm not sure exactly what you mean by that. You can make a class called Read, but GHC isn't going to know how to derive instances of it. > > If you could give a more concrete list of changes you want then that would be very helpful. Well, this ghc-prim package I'm seeing in HEAD is a step in the direction I meant ;-). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Apr 5 23:59:18 2008 From: trac at galois.com (GHC) Date: Sat Apr 5 23:55:35 2008 Subject: [GHC] #2191: A way to programmatically cause GHC to report the cost center stack associated with a value In-Reply-To: <043.3641dba02e220ac3643aa7a87adf7815@localhost> References: <043.3641dba02e220ac3643aa7a87adf7815@localhost> Message-ID: <052.e71eb0922171462711cf4c4d621051f4@localhost> #2191: A way to programmatically cause GHC to report the cost center stack associated with a value --------------------------------+------------------------------------------- Reporter: SamB | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Profiling | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- Comment (by SamB): The primitive above appears to do essentially what I want... at least, it prints something in pointy brackets that looks like a CCS when I call it... hmm. Doesn't always work... -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Apr 6 01:15:41 2008 From: trac at galois.com (GHC) Date: Sun Apr 6 01:12:00 2008 Subject: [GHC] #2191: A way to programmatically cause GHC to report the cost center stack associated with a value In-Reply-To: <043.3641dba02e220ac3643aa7a87adf7815@localhost> References: <043.3641dba02e220ac3643aa7a87adf7815@localhost> Message-ID: <052.fc99a194d1569a165526052c9a644700@localhost> #2191: A way to programmatically cause GHC to report the cost center stack associated with a value --------------------------------+------------------------------------------- Reporter: SamB | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Profiling | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- Comment (by SamB): Okay, either I've done something stupid, or I'm missing something really subtle about the css field's validity... shouldn't it always be valid? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Apr 6 05:49:02 2008 From: trac at galois.com (GHC) Date: Sun Apr 6 05:44:46 2008 Subject: [GHC] #2198: Build failure on Mac OS X Tiger Intel Message-ID: <044.e669693b0e2d8babbb9829cda3557205@localhost> #2198: Build failure on Mac OS X Tiger Intel -----------------------+---------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: MacOS X -----------------------+---------------------------------------------------- The ghc in Macports fails to build on my Intel MacBook, running Mac OS 10.5.2. Here's what Gregory Wright, the ghc macports maintainer had to say: ''It is possible that this is yet another file locking bug, which seem especially easy to trigger when running OS X on faster hardware. The warning from PackageConfig.hs may be spurious, the result of the import from InstalledPackageInfo.hi silently failing. There are a few places where important error messages are discarded, on the assumption that the cause of the failure will be obvious.'' I've attached the build log. I'd be happy to provide more information, if it might help. Wouter Swierstra -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Apr 6 13:55:33 2008 From: trac at galois.com (GHC) Date: Sun Apr 6 13:51:21 2008 Subject: [GHC] #2191: A way to programmatically cause GHC to report the cost center stack associated with a value In-Reply-To: <043.3641dba02e220ac3643aa7a87adf7815@localhost> References: <043.3641dba02e220ac3643aa7a87adf7815@localhost> Message-ID: <052.a91a5233500673bd8630727218d0cf0c@localhost> #2191: A way to programmatically cause GHC to report the cost center stack associated with a value --------------------------------+------------------------------------------- Reporter: SamB | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Profiling | Version: 6.8.2 Severity: normal | Resolution: Keywords: patch | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- Changes (by SamB): * keywords: => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Apr 6 14:58:48 2008 From: trac at galois.com (GHC) Date: Sun Apr 6 14:54:31 2008 Subject: [GHC] #2199: th32SnapEnumProcesses in System.Win32.Process prints debugging information to stdout Message-ID: <044.b8fbd1c67ea8e923433d5eaf1eaa88db@localhost> #2199: th32SnapEnumProcesses in System.Win32.Process prints debugging information to stdout --------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: th32SnapEnumProcesses | Testcase: Architecture: Unknown | Os: Windows --------------------------------------+------------------------------------- TSIA, pretty much. I suspect that when the author was developing this function he put in some putStrLn calls for his own use and simply forgot to remove them. For my application I just took the code out of the library and ripped out the offending statements, but I don't think they're really supposed to be there and ought to be either removed or #ifdef'd out somehow. Here's my cleaned up version (I also removed some extraneous parenthesis, FWIW). th32SnapEnumProcesses :: Th32SnapHandle -> IO [ProcessEntry32] th32SnapEnumProcesses h = allocaBytes 556 $ \pe -> do pokeByteOff pe 0 (556 :: DWORD) ok <- c_Process32First h pe readAndNext ok pe [] where errStr = "th32SnapEnumProcesses: Process32First/Process32Next" readAndNext ok pe res | not ok = do err <- getLastError if err == 18 then return $ reverse res else failWith errStr err | otherwise = do entry <- peekProcessEntry32 pe ok' <- c_Process32Next h pe readAndNext ok' pe (entry:res) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Apr 6 14:59:53 2008 From: trac at galois.com (GHC) Date: Sun Apr 6 14:55:36 2008 Subject: [GHC] #2199: th32SnapEnumProcesses in System.Win32.Process prints debugging information to stdout In-Reply-To: <044.b8fbd1c67ea8e923433d5eaf1eaa88db@localhost> References: <044.b8fbd1c67ea8e923433d5eaf1eaa88db@localhost> Message-ID: <053.851703c62139d9e222a1c7c0e6eba852@localhost> #2199: th32SnapEnumProcesses in System.Win32.Process prints debugging information to stdout --------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: th32SnapEnumProcesses | Testcase: Architecture: Unknown | Os: Windows --------------------------------------+------------------------------------- Comment (by guest): Sorry about that formatting, let me try again: {{{ th32SnapEnumProcesses :: Th32SnapHandle -> IO [ProcessEntry32] th32SnapEnumProcesses h = allocaBytes 556 $ \pe -> do pokeByteOff pe 0 (556 :: DWORD) ok <- c_Process32First h pe readAndNext ok pe [] where errStr = "th32SnapEnumProcesses: Process32First/Process32Next" readAndNext ok pe res | not ok = do err <- getLastError if err == 18 then return $ reverse res else failWith errStr err | otherwise = do entry <- peekProcessEntry32 pe ok' <- c_Process32Next h pe readAndNext ok' pe (entry:res) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Apr 6 15:51:17 2008 From: trac at galois.com (GHC) Date: Sun Apr 6 15:47:01 2008 Subject: [GHC] #2097: bug in regEnumKeys (System.Win32.Registry) In-Reply-To: <053.154a24ca3b071941575751aaf8747feb@localhost> References: <053.154a24ca3b071941575751aaf8747feb@localhost> Message-ID: <062.389192385ec899bd7a7278d6fa38e49c@localhost> #2097: bug in regEnumKeys (System.Win32.Registry) -------------------------------+-------------------------------------------- Reporter: MagnusTherning | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: libraries (other) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Windows | -------------------------------+-------------------------------------------- Changes (by igloo): * owner: => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Apr 6 16:39:23 2008 From: trac at galois.com (GHC) Date: Sun Apr 6 16:35:09 2008 Subject: [GHC] #2200: big static random access arrays Message-ID: <043.a925e7306d93d3b9993abaf14c0d8674@localhost> #2200: big static random access arrays --------------------------------+------------------------------------------- Reporter: jsnx | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: static array | Testcase: Architecture: Multiple | Os: Multiple --------------------------------+------------------------------------------- These would be unlike `StorableArray`s because they would be available at compile time, and would be pure values. They would amount to arrays of bytes, of course, but it'd be nice if they could be `(Storable a) => StaticArray a` and we could walk down them or randomly access them to get the `a` values out of them. They should be capable of storing hundreds of thousands of `Int`s. What are some functions that work on these arrays? We need just one: {{{ indexInto :: (Storable a) => StaticArray a -> Word -> a }}} Then we can make a `Monad` to walk up and down the array. It will be some `State` hybrid. No `IO`. A bright person could implement static `Trie`s, `RoseTree`s and other things using this `Monad` -- storing the offsets mixed in with the data in an unholy mess and skipping forward or backward, leveraging "the world?s most beautiful imperative language." It's been suggested (SamB) that this should be implemented in Template Haskell. Important features of this array relative to other arrays and lists in Haskell: Specificity of Index:: A machine `Word` since that contains the finest grained pointer. When indexing into a `Storable a`, the index is multiplied by `sizeOf (undefined :: a)`. Static Nature:: Exists to facilitate large static constants. The array does not support any append or delete operations, there is no way to change any of its values and it can not be copied. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Apr 6 16:44:15 2008 From: trac at galois.com (GHC) Date: Sun Apr 6 16:39:59 2008 Subject: [GHC] #2200: big static random access arrays In-Reply-To: <043.a925e7306d93d3b9993abaf14c0d8674@localhost> References: <043.a925e7306d93d3b9993abaf14c0d8674@localhost> Message-ID: <052.f11f97ccfd348d86b095284c8ea772ff@localhost> #2200: big static random access arrays --------------------------------+------------------------------------------- Reporter: jsnx | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: static array | Testcase: Architecture: Multiple | Os: Multiple --------------------------------+------------------------------------------- Comment (by dons): See this recent thread on compile time data structures, http://thread.gmane.org/gmane.comp.lang.haskell.glasgow.user/14059/focus=37186 In particular, the solutions using Data.Binary to encode data structures. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Apr 6 16:56:47 2008 From: trac at galois.com (GHC) Date: Sun Apr 6 16:52:29 2008 Subject: [GHC] #2097: bug in regEnumKeys (System.Win32.Registry) In-Reply-To: <053.154a24ca3b071941575751aaf8747feb@localhost> References: <053.154a24ca3b071941575751aaf8747feb@localhost> Message-ID: <062.7831219085fd2db56eca5a6d88286606@localhost> #2097: bug in regEnumKeys (System.Win32.Registry) -------------------------------+-------------------------------------------- Reporter: MagnusTherning | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.8.3 Component: libraries (other) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Windows | -------------------------------+-------------------------------------------- Changes (by igloo): * type: bug => merge Comment: Fixed: {{{ Sun Apr 6 21:50:51 BST 2008 Ian Lynagh * malloc a big enough buffer for the registry functions. Fixes trac #2097. We were mallocing a byte per tchar, but tchars are normally 2 bytes big... I think they are at most 4 bytes, so we now malloc 4 * #tchars. Not sure if there is a proper function I should be using for this? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Apr 6 17:44:33 2008 From: trac at galois.com (GHC) Date: Sun Apr 6 17:40:16 2008 Subject: [GHC] #2091: heap corruption in ghc-6.8.2? In-Reply-To: <044.3e0a988db69b0177d74a97127f5c474c@localhost> References: <044.3e0a988db69b0177d74a97127f5c474c@localhost> Message-ID: <053.c131116b424dadca538a7d81e8a4068d@localhost> #2091: heap corruption in ghc-6.8.2? ----------------------+----------------------------------------------------- Reporter: jeffz | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: worksforme Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => worksforme Comment: I can't reproduce this with Debian's wine 0.9.41-1, so it sounds like a wine bug to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Apr 6 17:52:30 2008 From: trac at galois.com (GHC) Date: Sun Apr 6 17:48:13 2008 Subject: [GHC] #2201: "ghc-pkg --user describe '*'" fails with empty user db Message-ID: <045.673a6cc9904f9063d50fb7c9230e5305@localhost> #2201: "ghc-pkg --user describe '*'" fails with empty user db ------------------------+--------------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- With ghc 6.9 and later Cabal uses the new "`ghc-pkg describe '*'`" interface to get info out of `ghc-pkg` about all the installed packages. It makes one call for each package db, for `--global` and `--user` (and any other dbs the user specifies). The `--user` flag now means to list only the packages from the user db and not the ones from the global one too. It's quite possible that the user package db is empty (or equivalently that the file does not exist yet). So what goes wrong is that the new search feature treats an empty search result as a failure. That's obviously a useful thing for some queries but is extremely unhelpful for what Cabal wants. It means Cabal fails to configure anything when the user package db is empty because it does not expect ghc-pkg to fail. This blocks the current Cabal HEAD from working with ghc HEAD. I'd like to put in another request for the `ghc-pkg dump` feature that I suggested originally. It would just dump all the packages in the `describe` format. The difference is that it is not a query so we do not fail if the result set is empty. Also, `dump` should not produce helpful human readable error output like "{{{ghc-pkg: cannot find package matching *}}}" because that will upset Cabal's parser. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Apr 6 18:54:16 2008 From: trac at galois.com (GHC) Date: Sun Apr 6 18:50:21 2008 Subject: [GHC] #2036: Show for Double and Float doesn't use parenthesis for negative zero. In-Reply-To: <047.9085fb42c7e7997d5332318ebe9470cc@localhost> References: <047.9085fb42c7e7997d5332318ebe9470cc@localhost> Message-ID: <056.77f0b20da795aaed73e3c70398d4d859@localhost> #2036: Show for Double and Float doesn't use parenthesis for negative zero. ---------------------------------+------------------------------------------ Reporter: clanehin | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: libraries/haskell98 | Version: 6.6.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ---------------------------------+------------------------------------------ Comment (by igloo): Malcolm agrees that this looks like a language defn bug, so we should just fix the -0 case. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Apr 6 21:45:47 2008 From: trac at galois.com (GHC) Date: Sun Apr 6 21:41:30 2008 Subject: [GHC] #2153: GHCi does not have a :source command to load further .ghci files In-Reply-To: <043.51c925bf8ca398d8c29d97455f25e3eb@localhost> References: <043.51c925bf8ca398d8c29d97455f25e3eb@localhost> Message-ID: <052.3c4132b63087efb25d0e1dd5966447d6@localhost> #2153: GHCi does not have a :source command to load further .ghci files ---------------------+------------------------------------------------------ Reporter: SamB | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------+------------------------------------------------------ Comment (by SamB): Wow, that simple??? What needs to be done to get this in ":?" output? (It should be in the manual, at least...) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Apr 6 23:14:58 2008 From: trac at galois.com (GHC) Date: Sun Apr 6 23:10:43 2008 Subject: [GHC] #2044: "Can't unify" error in debugger In-Reply-To: <044.9de84d1571c81bf2b4030ee1192776b2@localhost> References: <044.9de84d1571c81bf2b4030ee1192776b2@localhost> Message-ID: <053.a966d4467684e5ee021b59e011079073@localhost> #2044: "Can't unify" error in debugger --------------------+------------------------------------------------------- Reporter: r6144 | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | --------------------+------------------------------------------------------- Comment (by r6144): -XImpredicativeTypes (implied by -fglasgow-exts) appears to be necessary for array1.hs as well as igloo's simpler example. To make the original array1.hs compile with GHC 6.9.20080323, I have to expand the do statements involving polymorphic lambda-bound variables, e.g. "do { w <- writeRandoms ; return (newArray_ (0,n-1) >>= w) }" into "writeRandoms >>= \w -> return (newArray_ (0,n-1) >>= w)". If I understand correctly, -XImpredicativeTypes allows w to be polymorphic. After this modification, array1.hs (called array1-orig.hs below) compiles, but the original problem persists: {{{ [haskell]$ ~/apps/ghc-6.9.20080323/bin/ghci GHCi, version 6.9.20080323: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude> :load array1-orig.hs [1 of 1] Compiling Main ( array1-orig.hs, interpreted ) Ok, modules loaded: Main. *Main> :break rsRandomArray Breakpoint 0 activated at array1-orig.hs:(32,0)-(43,86) *Main> main Loading package array-0.1 ... linking ... done. Loading package old-locale-1.0 ... linking ... done. Loading package old-time-1.0 ... linking ... done. Loading package random-1.0 ... linking ... done. Array 1: array Stopped at array1-orig.hs:(32,0)-(43,86) _result :: ST s (UArray Idx Double) = _ [array1-orig.hs:(32,0)-(43,86)] *Main> :step Stopped at array1-orig.hs:32:21-53 ghc-6.9.20080323: panic! (the 'impossible' happened) (GHC version 6.9.20080323 for i386-unknown-linux): Can't unify Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug [array1-orig.hs:32:21-53] *Main> :quit Leaving GHCi. [ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Apr 7 05:32:54 2008 From: trac at galois.com (GHC) Date: Mon Apr 7 05:28:35 2008 Subject: [GHC] #2097: bug in regEnumKeys (System.Win32.Registry) In-Reply-To: <053.154a24ca3b071941575751aaf8747feb@localhost> References: <053.154a24ca3b071941575751aaf8747feb@localhost> Message-ID: <062.063f80c94ab8fd0c33937a7eb40f1428@localhost> #2097: bug in regEnumKeys (System.Win32.Registry) -------------------------------+-------------------------------------------- Reporter: MagnusTherning | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.8.3 Component: libraries (other) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Windows | -------------------------------+-------------------------------------------- Comment (by MagnusTherning): Replying to [comment:5 igloo]: > Fixed: > {{{ > Sun Apr 6 21:50:51 BST 2008 Ian Lynagh > * malloc a big enough buffer for the registry functions. Fixes trac #2097. > We were mallocing a byte per tchar, but tchars are normally 2 bytes big... > I think they are at most 4 bytes, so we now malloc 4 * #tchars. Not sure > if there is a proper function I should be using for this? > }}} One way to be sure is to switch to using wide characters explicitly, i.e. to use RegOpenKeyExW rather than RegOpenKeyEx. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Apr 7 06:40:53 2008 From: trac at galois.com (GHC) Date: Mon Apr 7 06:36:44 2008 Subject: [GHC] #2191: A way to programmatically cause GHC to report the cost center stack associated with a value In-Reply-To: <043.3641dba02e220ac3643aa7a87adf7815@localhost> References: <043.3641dba02e220ac3643aa7a87adf7815@localhost> Message-ID: <052.518eca29ad50081ef2b6a5da06c40496@localhost> #2191: A way to programmatically cause GHC to report the cost center stack associated with a value --------------------------------+------------------------------------------- Reporter: SamB | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Profiling | Version: 6.8.2 Severity: normal | Resolution: Keywords: patch | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- Comment (by SamB): And now I have no clue what in the world this is doing, because when I try to use it to trace the cause of errors in JHC, the trace appears, but the "fail" or "error" call passed as the second argument to traceCcs# doesn't seem to happen :-(. Please assist! Did I do something really stupid? Is something missing from the documentation? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Apr 7 07:15:44 2008 From: trac at galois.com (GHC) Date: Mon Apr 7 07:11:27 2008 Subject: [GHC] #2177: Can Data.Unique safely derive Typeable? In-Reply-To: <045.8724b926d6549afcfc85d1a3ada0af59@localhost> References: <045.8724b926d6549afcfc85d1a3ada0af59@localhost> Message-ID: <054.516b478d913478282255f6cf6aaef105@localhost> #2177: Can Data.Unique safely derive Typeable? -----------------------------+---------------------------------------------- Reporter: japple | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Comment (by japple): I was asking for the first. The second seems unreasonable. The third would be lovely. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Apr 7 17:47:04 2008 From: trac at galois.com (GHC) Date: Mon Apr 7 17:42:48 2008 Subject: [GHC] #2195: yi: internal error: R_X86_64_PC32 relocation out of range: (noname) = 0x7c436730a In-Reply-To: <044.cc96d7cce62f73d5dee217e7be0e7f3f@localhost> References: <044.cc96d7cce62f73d5dee217e7be0e7f3f@localhost> Message-ID: <053.c7560d33e91b5f6c9616dc9f83be3ba1@localhost> #2195: yi: internal error: R_X86_64_PC32 relocation out of range: (noname) = 0x7c436730a ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: duplicate Keywords: linker | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: FreeBSD | ----------------------+----------------------------------------------------- Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: see #2013 upshot: we need a way to do `mmap(... MAP_32BIT ...)` on FreeBSD. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Apr 7 17:47:36 2008 From: trac at galois.com (GHC) Date: Mon Apr 7 17:43:23 2008 Subject: [GHC] #2013: ghci crash on startup: R_X86_64_32S relocation out of range. In-Reply-To: <044.2f007075e8a3e652be5aa7c77056c714@localhost> References: <044.2f007075e8a3e652be5aa7c77056c714@localhost> Message-ID: <053.3083a7a4bfcc7e0148b3e57b1d929f2a@localhost> #2013: ghci crash on startup: R_X86_64_32S relocation out of range. ---------------------+------------------------------------------------------ Reporter: mboes | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: GHCi | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: FreeBSD | ---------------------+------------------------------------------------------ Comment (by simonmar): See also #2195 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Apr 7 17:57:27 2008 From: trac at galois.com (GHC) Date: Mon Apr 7 17:53:12 2008 Subject: [GHC] #2191: A way to programmatically cause GHC to report the cost center stack associated with a value In-Reply-To: <043.3641dba02e220ac3643aa7a87adf7815@localhost> References: <043.3641dba02e220ac3643aa7a87adf7815@localhost> Message-ID: <052.abff1e2991e596a8cdccd1078c1bb8cc@localhost> #2191: A way to programmatically cause GHC to report the cost center stack associated with a value --------------------------------+------------------------------------------- Reporter: SamB | Owner: SamB Type: feature request | Status: new Priority: normal | Milestone: Component: Profiling | Version: 6.8.2 Severity: normal | Resolution: Keywords: patch | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- Changes (by SamB): * owner: => SamB -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Apr 7 18:03:46 2008 From: trac at galois.com (GHC) Date: Mon Apr 7 17:59:27 2008 Subject: [GHC] #2197: GHCi doesn't work when built with way=p In-Reply-To: <043.8ca8ccba553cfe5b0f79906ba5d25b8c@localhost> References: <043.8ca8ccba553cfe5b0f79906ba5d25b8c@localhost> Message-ID: <052.4187069be581a7f543f347e5a3bd4f5c@localhost> #2197: GHCi doesn't work when built with way=p --------------------+------------------------------------------------------- Reporter: SamB | Owner: simonmar Type: bug | Status: new Priority: low | Milestone: 6.10 branch Component: GHCi | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Linux | --------------------+------------------------------------------------------- Changes (by simonmar): * priority: normal => low * difficulty: => Unknown * owner: => simonmar * milestone: => 6.10 branch Comment: GHCi + profiling doesn't work for deeper reasons than this: it would require a lot of work in the byte-code compiler and interpreter. If you try 'ghci -prof' you get an error message, but in this case you built GHCi itself with -prof and tried to use it. I'll make it so that GHCi fails with a helpful error message earlier. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Apr 7 20:53:59 2008 From: trac at galois.com (GHC) Date: Mon Apr 7 20:49:44 2008 Subject: [GHC] #2202: type error causes type checker stack overflow Message-ID: <045.817a1089ed0068d0921ec39de4c6cc2f@localhost> #2202: type error causes type checker stack overflow -----------------------+---------------------------------------------------- Reporter: chiral | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: MacOS X -----------------------+---------------------------------------------------- The following code causes {{{ *** Exception: stack overflow }}} during type checking. I've tried to whittle the test case down, this may not be minimal. The {{{(Ord a)}}} instances and the unused {{{vertexID}}} member of the datatype seem to be necessary, otherwise the infinite type is correctly caught. Does not occur under 6.6.1 {{{ module GHCBug( MeshVertex(..) ) where data (Ord a) => MeshVertex a b = MeshVertex { vertexID :: a, vertexChildren :: [a] } deriving (Show) split :: (Ord a) => a -> [MeshVertex a b] -> [MeshVertex a b] split a m = let av = head m newVTs = preSplit a m av' = av { vertexChildren = newVTs } newMVs = av' : m newMesh = newMVs in newMesh preSplit :: (Ord a) => a -> [MeshVertex a b] -> [MeshVertex a b] preSplit a m = preSplit a $ split a m }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Apr 8 00:03:39 2008 From: trac at galois.com (GHC) Date: Mon Apr 7 23:59:27 2008 Subject: [GHC] #2203: TFs in class instances heads Message-ID: <043.d54d86ddec760e3a2475c6e848a97d7e@localhost> #2203: TFs in class instances heads -------------------------+-------------------------------------------------- Reporter: chak | Owner: chak Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: Multiple | Os: Multiple -------------------------+-------------------------------------------------- Ganesh posted the following example on haskell-cafe: {{{ {-# LANGUAGE ScopedTypeVariables, TypeFamilies, FlexibleInstances #-} module Test1a where class Foo a where type TheFoo a foo :: TheFoo a -> a foo' :: a -> Int class Bar b where bar :: b -> Int instance Foo a => Bar (Either a (TheFoo a)) where bar (Left a) = foo' a bar (Right b) = foo' (foo b :: a) instance Foo Int where type TheFoo Int = Int foo = id foo' = id val :: Either Int Int val = Left 5 res :: Int res = bar val }}} It fails to type check as the type of `bar` cannot be inferred. However, GHC should reject the instance due to the TF in the head despite `FlexibleInstances`. Moreover, the corrected code {{{ {-# LANGUAGE ScopedTypeVariables, TypeFamilies, UndecidableInstances #-} module Test1a where class Foo a where type TheFoo a foo :: TheFoo a -> a foo' :: a -> Int class Bar b where bar :: b -> Int instance (b ~ TheFoo a, Foo a) => Bar (Either a b) where bar (Left a) = foo' a bar (Right b) = foo' (foo b :: a) instance Foo Int where type TheFoo Int = Int foo = id foo' = id val :: Either Int Int val = Left 5 res :: Int res = bar val }}} requires `UndecidableInstances`, although it shouldn't. We should be able to allow equalities of the form `tv ~ F tv1 .. tvn` with tv and tvi being distinct type variables without requiring `UndecidableInstances`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Apr 8 00:11:19 2008 From: trac at galois.com (GHC) Date: Tue Apr 8 00:07:40 2008 Subject: [GHC] #1673: Template Haskell support for type families In-Reply-To: <065.e2dcaba876dc26f94848b54efa34a3d4@localhost> References: <065.e2dcaba876dc26f94848b54efa34a3d4@localhost> Message-ID: <074.5a8f5cdee5185f586e21b3ef3a6621c5@localhost> #1673: Template Haskell support for type families ----------------------------------------+----------------------------------- Reporter: g9ks157k@acme.softbase.org | Owner: Type: feature request | Status: new Priority: low | Milestone: 6.10 branch Component: Template Haskell | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------------------------+----------------------------------- Changes (by hpacheco): * cc: ganesh@earth.li (removed) * cc: hpacheco@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Apr 8 00:11:45 2008 From: trac at galois.com (GHC) Date: Tue Apr 8 00:08:00 2008 Subject: [GHC] #1673: Template Haskell support for type families In-Reply-To: <065.e2dcaba876dc26f94848b54efa34a3d4@localhost> References: <065.e2dcaba876dc26f94848b54efa34a3d4@localhost> Message-ID: <074.c06eb8216cf2af4275455f4eb05a7165@localhost> #1673: Template Haskell support for type families ----------------------------------------+----------------------------------- Reporter: g9ks157k@acme.softbase.org | Owner: Type: feature request | Status: new Priority: low | Milestone: 6.10 branch Component: Template Haskell | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------------------------+----------------------------------- Changes (by hpacheco): * cc: ganesh@earth.li (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Apr 8 00:12:19 2008 From: trac at galois.com (GHC) Date: Tue Apr 8 00:08:05 2008 Subject: [GHC] #2151: GADTs in function Patterns In-Reply-To: <047.2f6478e8e827595da4825a54c1ec722c@localhost> References: <047.2f6478e8e827595da4825a54c1ec722c@localhost> Message-ID: <056.8ab7dda91bf3150ce10c293122aee09e@localhost> #2151: GADTs in function Patterns ----------------------+----------------------------------------------------- Reporter: hpacheco | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: blocker | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ----------------------+----------------------------------------------------- Changes (by hpacheco): * cc: hpacheco@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Apr 8 00:12:40 2008 From: trac at galois.com (GHC) Date: Tue Apr 8 00:08:25 2008 Subject: [GHC] #2157: Equality Constraints with Type Families In-Reply-To: <047.9207b8f452560eac1f90c6a1629a593a@localhost> References: <047.9207b8f452560eac1f90c6a1629a593a@localhost> Message-ID: <056.d59337f27253f933d228a8600b60e13d@localhost> #2157: Equality Constraints with Type Families -------------------------------------+-------------------------------------- Reporter: hpacheco | Owner: chak Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -------------------------------------+-------------------------------------- Changes (by hpacheco): * cc: hpacheco@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Apr 8 00:19:00 2008 From: trac at galois.com (GHC) Date: Tue Apr 8 00:15:16 2008 Subject: [GHC] #1673: Template Haskell support for type families In-Reply-To: <065.e2dcaba876dc26f94848b54efa34a3d4@localhost> References: <065.e2dcaba876dc26f94848b54efa34a3d4@localhost> Message-ID: <074.99414017f6e3209afb1dc59d80a29f65@localhost> #1673: Template Haskell support for type families ----------------------------------------+----------------------------------- Reporter: g9ks157k@acme.softbase.org | Owner: Type: feature request | Status: new Priority: low | Milestone: 6.10 branch Component: Template Haskell | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------------------------+----------------------------------- Comment (by hpacheco): Myself, I would simply like to be able to write TH code to automatically generate type family instances. However, I understand it is not a very important feature. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Apr 8 06:53:00 2008 From: trac at galois.com (GHC) Date: Tue Apr 8 06:48:51 2008 Subject: [GHC] #2203: TFs in class instances heads In-Reply-To: <043.d54d86ddec760e3a2475c6e848a97d7e@localhost> References: <043.d54d86ddec760e3a2475c6e848a97d7e@localhost> Message-ID: <052.06b6b48feb1cab964a2a4132b336760f@localhost> #2203: TFs in class instances heads ----------------------------------------+----------------------------------- Reporter: chak | Owner: chak Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Multiple | Os: Multiple ----------------------------------------+----------------------------------- Changes (by claus): * cc: claus (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Apr 8 13:17:45 2008 From: trac at galois.com (GHC) Date: Tue Apr 8 13:13:23 2008 Subject: [GHC] #2204: Improve 'patterns not matched' warnings Message-ID: <047.57470c7515f5d78414f8813f455c57a5@localhost> #2204: Improve 'patterns not matched' warnings -------------------------+-------------------------------------------------- Reporter: Deewiant | Owner: Type: proposal | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: trivial Keywords: | Testcase: Architecture: Multiple | Os: Multiple -------------------------+-------------------------------------------------- Compiling the following with `-fwarn-incomplete-patterns`: {{{ module Asdf where f :: String -> Int f "0" = 0 g :: Int -> Int g 0 = 0 }}} Yields: {{{ asdf.hs:4:0: Warning: Pattern match(es) are non-exhaustive In the definition of `f': Patterns not matched: [] (GHC.Base.C# #x) : _ with #x `notElem` ['0'] (GHC.Base.C# '0') : (_ : _) asdf.hs:7:0: Warning: Pattern match(es) are non-exhaustive In the definition of `g': Patterns not matched: GHC.Base.I# #x with #x `notElem` [0#] }}} Losing the 'GHC.Base' stuff along with the various octothorpes would make the error messages a lot nicer. Ideally it'd be something like `Patterns not matched: x where x `notElem` [0]` for the second case, for instance. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Apr 8 21:08:00 2008 From: trac at galois.com (GHC) Date: Tue Apr 8 21:03:42 2008 Subject: [GHC] #2205: infix type constructors seem to ignore associativity Message-ID: <047.d51a18254711f69f4bc5b63ba9a2a2c6@localhost> #2205: infix type constructors seem to ignore associativity -------------------------+-------------------------------------------------- Reporter: gckeller | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Parser) Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- In the following program, fst3 and fst3' should be equivalent, but fst3' but fst3' leads to type error: {{{ module Main where infixr 0 :-> data a :-> b = P a b fst3:: (a :-> (b :-> c)) -> a fst3 (P a (P b c)) = a fst3':: (a :-> b :-> c) -> a fst3' (P a (P b c)) = a main = putStrLn $ show $ fst3 (P True (P False True)) }}} the type error is: {{{ TypeConstr.hs:11:0: Occurs check: cannot construct the infinite type: a = a :-> b When generalising the type(s) for `fst3'' }}} pulled last changes on 7/4/2008 (used to work correctly before) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Apr 8 23:49:39 2008 From: trac at galois.com (GHC) Date: Tue Apr 8 23:45:30 2008 Subject: [GHC] #2202: type error causes type checker stack overflow In-Reply-To: <045.817a1089ed0068d0921ec39de4c6cc2f@localhost> References: <045.817a1089ed0068d0921ec39de4c6cc2f@localhost> Message-ID: <054.5d8033dbb9ac6da31e08e6346bf5f310@localhost> #2202: type error causes type checker stack overflow ----------------------------------------+----------------------------------- Reporter: chiral | Owner: chak Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Other | Os: Other ----------------------------------------+----------------------------------- Changes (by chak): * owner: => chak * os: MacOS X => Other * architecture: x86 => Other -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 9 11:51:13 2008 From: trac at galois.com (GHC) Date: Wed Apr 9 11:46:46 2008 Subject: [GHC] #595: Overhaul GHC's overlapping/non-exhaustive pattern checking In-Reply-To: <047.bea78f01cbb904765ad77c751bc8d3af@localhost> References: <047.bea78f01cbb904765ad77c751bc8d3af@localhost> Message-ID: <056.d1bc960876c1e9b3e84002394074792f@localhost> #595: Overhaul GHC's overlapping/non-exhaustive pattern checking ----------------------+----------------------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: None Severity: normal | Resolution: None Keywords: warnings | Difficulty: Difficult (1 week) Testcase: N/A | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by simonpj): And #2204 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 9 11:52:30 2008 From: trac at galois.com (GHC) Date: Wed Apr 9 11:48:04 2008 Subject: [GHC] #2204: Improve 'patterns not matched' warnings In-Reply-To: <047.57470c7515f5d78414f8813f455c57a5@localhost> References: <047.57470c7515f5d78414f8813f455c57a5@localhost> Message-ID: <056.60098b7006ba497946e26242955638d9@localhost> #2204: Improve 'patterns not matched' warnings ----------------------+----------------------------------------------------- Reporter: Deewiant | Owner: Type: proposal | Status: new Priority: low | Milestone: _|_ Component: Compiler | Version: 6.8.2 Severity: trivial | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ----------------------+----------------------------------------------------- Changes (by simonpj): * priority: normal => low * difficulty: => Unknown * milestone: => _|_ Comment: Yes indeed. I think it'd make sense to do this as part of #595. Which is currently awaiting a keen author. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 9 12:21:18 2008 From: trac at galois.com (GHC) Date: Wed Apr 9 12:17:18 2008 Subject: [GHC] #2202: type error causes type checker stack overflow In-Reply-To: <045.817a1089ed0068d0921ec39de4c6cc2f@localhost> References: <045.817a1089ed0068d0921ec39de4c6cc2f@localhost> Message-ID: <054.c68af448c1ddcbfa2e272c22ae50e0bf@localhost> #2202: type error causes type checker stack overflow -------------------------------------+-------------------------------------- Reporter: chiral | Owner: chak Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Other Os: Other | -------------------------------------+-------------------------------------- Changes (by simonpj): * cc: bdonlan@gmail.com (added) * difficulty: => Unknown Comment: I believe this bug from Bryan Donlan is closely related. (He sent the report by email; I don't think there's a ticket for it.) I propose not to chase it down until Manuel has fixed this ticket (he is on the job). Then let's re-investigate. Simon I've found a case where GHC will hang (consuming more and more memory) when it should report an occurs check error. The test case is at [http://fushizen.net/~bd/kaos-ghc-loop.tgz] - the error in question is that the arguments in the `StateT` instance for `HOLift` are reversed like so: {{{ diff --git a/src/Kaos/KaosM.hs b/src/Kaos/KaosM.hs index ec4e69a..268250a 100644 --- a/src/Kaos/KaosM.hs +++ b/src/Kaos/KaosM.hs @@ -88,7 +88,7 @@ genlift' unbox box f m = box $ \s -> f (unbox m s) class HOLift m b | m -> b where genlift :: (forall r'. b r' -> b r') -> (forall r. m r -> m r) -instance HOLift m (StateT s m) where +instance HOLift (StateT s m) m where genlift = genlift' runStateT StateT instance (HOLift m b, KaosDiagM r b) => KaosDiagM r m where }}} I'm using GHC 6.8.2 on ubuntu hardy. Bryan Donlan -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 9 15:13:09 2008 From: trac at galois.com (GHC) Date: Wed Apr 9 15:08:46 2008 Subject: [GHC] #2052: hpc ignores files containing LINES pragmas that refer to .hsc files In-Reply-To: <043.13a31077ae5ebb133355743a92fc5086@localhost> References: <043.13a31077ae5ebb133355743a92fc5086@localhost> Message-ID: <052.8e37976422bccd14c154c8c4d0d2d8d1@localhost> #2052: hpc ignores files containing LINES pragmas that refer to .hsc files ---------------------------+------------------------------------------------ Reporter: dons | Owner: AndyGill Type: bug | Status: assigned Priority: normal | Milestone: 6.8.3 Component: Code Coverage | Version: 6.8.2 Severity: normal | Resolution: Keywords: hpc, hsc2hs | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ---------------------------+------------------------------------------------ Changes (by AndyGill): * status: new => assigned * owner: andy@galois.com => AndyGill Comment: It is not quite that easy, because the Span info has been messed up. Typically this just effects the error messages, but here the info *has* to be correct for hpc to work. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Apr 10 05:03:02 2008 From: trac at galois.com (GHC) Date: Thu Apr 10 04:58:37 2008 Subject: [GHC] #2205: infix type constructors seem to ignore associativity In-Reply-To: <047.d51a18254711f69f4bc5b63ba9a2a2c6@localhost> References: <047.d51a18254711f69f4bc5b63ba9a2a2c6@localhost> Message-ID: <056.4e0264f4cc7aa92816487949483aa2c6@localhost> #2205: infix type constructors seem to ignore associativity -------------------------------+-------------------------------------------- Reporter: gckeller | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Parser) | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: T2205 | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Changes (by simonpj): * testcase: => T2205 * difficulty: => Unknown * status: new => closed * resolution: => fixed Comment: Caused by {{{ Fri Apr 4 13:55:56 PDT 2008 simonpj@microsoft.com * Fix Trac #2188: scoping in TH declarations quotes }}} Fixed by {{{ Thu Apr 10 09:58:03 BST 2008 simonpj@microsoft.com * Fix Trac #2205, which I introduced recently }}} I will push shortly. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Apr 10 05:58:51 2008 From: trac at galois.com (GHC) Date: Thu Apr 10 05:54:23 2008 Subject: [GHC] #2044: "Can't unify" error in debugger In-Reply-To: <044.9de84d1571c81bf2b4030ee1192776b2@localhost> References: <044.9de84d1571c81bf2b4030ee1192776b2@localhost> Message-ID: <053.cceace0a78cffe9eadd600633c23f5e2@localhost> #2044: "Can't unify" error in debugger --------------------+------------------------------------------------------- Reporter: r6144 | Owner: pepe Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | --------------------+------------------------------------------------------- Changes (by simonpj): * owner: simonpj => pepe Comment: The "can't unify" message comes from `RtsClosureInspect`, which is Pepe and Simon's debugger. I suspect it's confused by the for-all in the type. Ian is right, incidentally, that the short program he gives should be rejected unless you specify `-XImpredicativeTypes`. So I'm assigning this bug to Pepe. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Apr 10 05:59:40 2008 From: trac at galois.com (GHC) Date: Thu Apr 10 05:55:13 2008 Subject: [GHC] #2044: "Can't unify" error in debugger In-Reply-To: <044.9de84d1571c81bf2b4030ee1192776b2@localhost> References: <044.9de84d1571c81bf2b4030ee1192776b2@localhost> Message-ID: <053.abe9a775ca35281fae928eea8799615e@localhost> #2044: "Can't unify" error in debugger --------------------+------------------------------------------------------- Reporter: r6144 | Owner: pepe Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | --------------------+------------------------------------------------------- Changes (by simonpj): * cc: mnislaih@gmail.com (added) Comment: And adding Pepe to the cc list. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Apr 10 07:19:08 2008 From: trac at galois.com (GHC) Date: Thu Apr 10 07:14:41 2008 Subject: [GHC] #2206: GADT pattern match with non-rigid return type Message-ID: <046.ef46bda025b4e7ab59ca8efa3b49bcc6@localhost> #2206: GADT pattern match with non-rigid return type -------------------------+-------------------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Keywords: Difficulty: Unknown | Testcase: gadt-escape1 Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- Chris Casinghino (ccasin@seas.upenn.edu) writes: I've been playing with some GADT stuff with Stephanie Weirich and I think we've found a bug in GHC at the intersection of GADTs and existentials. The HEAD version gives a type error when :loading this program into ghci: {{{ > data ExpGADT t where > ExpInt :: Int -> ExpGADT Int > > data Hidden = forall t . Hidden (ExpGADT t) (ExpGADT t) > > hval = Hidden (ExpInt 0) (ExpInt 1) > > weird = case (hval :: Hidden) of Hidden (ExpInt _) a -> a }}} ghc thinks the existential type variable has escaped: {{{ test.hs:11:33: Inferred type is less polymorphic than expected Quantified type variable `t' escapes When checking an existential match that binds a :: ExpGADT t The pattern(s) have type(s): Hidden The body has type: ExpGADT t In a case alternative: Hidden (ExpInt _) a -> a In the expression: case (hval :: Hidden) of Hidden (ExpInt _) a -> a }}} According to the rules in the wobbly types paper, this should typecheck and weird should be given the wobbly type `(ExpGADT Int)`. Perhaps this type error is an intentional deviation from the spec? If so, I'd love to know what implementation issues brought about the change. If not, I suppose it's a bug. Everything works fine if we add a type annotation for weird. Strangely, in ghc 6.8.2, the program is accepted when :loaded, but if after doing so I copy: {{{ let weird2 = case (hval :: Hidden) of Hidden (ExpInt _) a -> a }}} into ghci, I get an error. Anyway, I thought I should point out this discrepancy. I hope it's helpful! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Apr 10 09:14:23 2008 From: trac at galois.com (GHC) Date: Thu Apr 10 09:09:57 2008 Subject: [GHC] #2044: "Can't unify" error in debugger In-Reply-To: <044.9de84d1571c81bf2b4030ee1192776b2@localhost> References: <044.9de84d1571c81bf2b4030ee1192776b2@localhost> Message-ID: <053.7850e3c38c4896cc44fe643812d918d7@localhost> #2044: "Can't unify" error in debugger --------------------+------------------------------------------------------- Reporter: r6144 | Owner: mnislaih Type: bug | Status: assigned Priority: normal | Milestone: 6.8.3 Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | --------------------+------------------------------------------------------- Changes (by mnislaih): * status: new => assigned * owner: pepe => mnislaih Comment: Thanks for CC'ing, I had missed this ticket. At first I though this problem was an instance of #1995, but it turns out your suspicion was right. The RTTI mechanism panics when trying to reconstruct the type for buildBuf in line 3. This is the 'full' error obtained via initTcPrintErrors : {{{ Top level: Cannot match a monotype with `ST s (forall s'. ST s' (STUArray s' Idx Double))' Expected type: ST s (forall s'. ST s' (STUArray s' Idx Double)) Inferred type: t ghc-6.9.20080404: panic! (the 'impossible' happened) (GHC version 6.9.20080404 for i386-apple-darwin): Can't unify }}} So GHC is refusing to unify the tyvar with an impredicative type. This tyvar is created as follows: {{{ newVar kind = mkTyVarTy `fmap` newFlexiTyVar kind }}} in this case with kind argType. How should the tyvars used by the RTTI mechanism be created to handle this situation ? And, do we need to handle it at all? At runtime we handle values, which are monomorphically typed. It looks to me that the type recovered for buildBuf should be just: {{{ buildBuf :: ST s (ST s' (STUArray s' Idx Double) }}} Does that make sense? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Apr 10 10:55:15 2008 From: trac at galois.com (GHC) Date: Thu Apr 10 10:50:46 2008 Subject: [GHC] #2192: occasional segmentation faults when using Control.Parallel In-Reply-To: <044.41e146963f3d21c260430274434fb250@localhost> References: <044.41e146963f3d21c260430274434fb250@localhost> Message-ID: <053.ab85046f304be7969d5c6611389bfb08@localhost> #2192: occasional segmentation faults when using Control.Parallel -------------------------+-------------------------------------------------- Reporter: ivant | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: major | Resolution: Keywords: par | Testcase: Architecture: x86 | Os: Linux -------------------------+-------------------------------------------------- Comment (by guest): Reproduced it on a dual Opteron running Fedora 8: [breitko@megadodo haskell]$ ./parallel +RTS -N2 500000 [breitko@megadodo haskell]$ ./parallel +RTS -N2 parallel: internal error: evacuate: strange closure type -3932344 (GHC version 6.8.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted [breitko@megadodo haskell]$ ./parallel +RTS -N2 Segmentation fault [breitko@megadodo haskell]$ ./parallel +RTS -N2 500000 Successful run, internal error, and segfault seem about equally likely. - chris (chris at chr-breitkopf.de) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Apr 10 10:58:54 2008 From: trac at galois.com (GHC) Date: Thu Apr 10 10:54:28 2008 Subject: [GHC] #2171: Parallel program crashes In-Reply-To: <042.91539dd5667f046cb861faa36a106615@localhost> References: <042.91539dd5667f046cb861faa36a106615@localhost> Message-ID: <051.9a08a11af625136c408a216fa2e02052@localhost> #2171: Parallel program crashes ---------------------------------------------+------------------------------ Reporter: fed | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Runtime System | Version: 6.8.2 Severity: critical | Resolution: Keywords: parallel, crash, race condition | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ---------------------------------------------+------------------------------ Comment (by guest): Reproduced on a dual Opteron system running Fedora 8 x86_64. I get a Segmentation fault about every 3rd run. - chris (chris at chr-breitkopf.de) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Apr 10 11:01:41 2008 From: trac at galois.com (GHC) Date: Thu Apr 10 10:57:13 2008 Subject: [GHC] #2207: Load the interface details for GHC.* even without -O Message-ID: <046.c160dd85a0a0b0a47d62c75151b28378@localhost> #2207: Load the interface details for GHC.* even without -O --------------------------------+------------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- Neil says: I just tried compiling the following program: {{{ foo = (1 :: Int) == (2 :: Int) }}} with `ghc --ddump-simpl`, and no optimisation flags, in GHC 6.6.1 The resultant code is: {{{ Test.foo = case GHC.Base.$f2 of tpl_X8 { GHC.Base.:DEq tpl1_B2 tpl2_B3 -> tpl1_B2 (GHC.Base.I# 1) (GHC.Base.I# 2) } }}} GHC has introduced dictionaries in this example. In comparison, Yhc and nhc wouldn't introduce dictionaries here, as the type class desugaring knows the type of the item is fixed, and makes a direct call to the appropriate function. If the desugaring was changed, it would make programs in GHCi run faster, would reduce the size of programs, and would speed up the optimiser, as it would have less to do. I am not sure how much additional work this would require in the simplifier, but if it was minimal, the gains would probably be worth it. The reason nothing happens is that without -0 GHC does not load the unfoldings for anything from interface files, including `GHC.Base`. Idea: even without -O, load the unfoldings from GHC.* modules. That would pick up a lot of very fundamental stuff, and might, as Neil says, make compilation faster. Relatively easy to try. But would need a good nofib run to test the effects. Any takers? I'd point you at what to change. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Apr 10 12:17:39 2008 From: trac at galois.com (GHC) Date: Thu Apr 10 12:13:16 2008 Subject: [GHC] #2171: Parallel program crashes In-Reply-To: <042.91539dd5667f046cb861faa36a106615@localhost> References: <042.91539dd5667f046cb861faa36a106615@localhost> Message-ID: <051.67ae72416476a65bad1111838eac8ddd@localhost> #2171: Parallel program crashes ---------------------------------------------+------------------------------ Reporter: fed | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Runtime System | Version: 6.8.2 Severity: critical | Resolution: Keywords: parallel, crash, race condition | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ---------------------------------------------+------------------------------ Comment (by MarcWeber): Replying to [ticket:2171 fed]: > I wrote a parallel program for computing prime numbers (see code below). > Compiled it using > ghc -threaded --make primes.hs > Then run > primes 200000 200010 +RTS -N2 -sstderr > In 80% of runs the program crashes with segmentation fault message. My operating system is Windows XP SP2. One time I saw a typical Windows red cross dialog box with access violation report as a result of the run. > But few times the program finished with correct result. > > {{{ > module Main where > > import System.Environment > import Control.Parallel.Strategies > import Data.Maybe > > chunkSize = 1000 > threads = 2 > > maybePrimes :: [Maybe Integer] > maybePrimes = Just 2 : Just 3 : Just 5 : [ if isPrime x then (Just x) else Nothing | x <- candidates 7 11 ] > where > candidates a1 a2 = a1 : a2 : candidates (a1+6) (a2+6) > isPrime x = all ((0 /=) . (x `mod`)) $ takeWhile ((x>=).(^2)) primes > > splitOnSubLists :: Int -> [a] -> [[a]] > splitOnSubLists n xs = > let > (begin, end) = splitAt n xs > in > begin : splitOnSubLists n end > > maybePrimes2 :: [Maybe Integer] > maybePrimes2 = concat $ parBuffer (threads-1) rnf > $ splitOnSubLists chunkSize maybePrimes > > primes :: [Integer] > primes = catMaybes maybePrimes2 > > main = do > args <- getArgs > > (first, last) <- case args of > [] -> return (10, 19) > (x:[]) -> return (f, f+9) where f = read x > (x:y:_) -> return (read x, read y) > > let p = drop (first-1) $ take last $ zip [1..] primes in > mapM (\(x,y) -> putStrLn (show x ++ " -> " ++ show y)) p > }}} I can reproduce this error as well (NixOS Linux, DualCore, x86_64) ghc 6.8.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Apr 10 16:06:25 2008 From: trac at galois.com (GHC) Date: Thu Apr 10 16:01:56 2008 Subject: [GHC] #2208: many .xml files for the User's Manual force xml-mode in emacs Message-ID: <043.dbdf8ae310e46744a6c504b004f1a2cd@localhost> #2208: many .xml files for the User's Manual force xml-mode in emacs ------------------------+--------------------------------------------------- Reporter: SamB | Owner: Type: bug | Status: new Priority: normal | Component: Documentation Version: 6.9 | Severity: normal Keywords: emacs | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- Many (all?) of the XML files for the User's Manual contain the following or similar: {{{ #!xml }}} The "mode:" line, in particular (assuming the user hasn't disabled the feature) overrides the user's choice of mode for XML editing (when the filename ends in .xml or another common XML suffix, anyway). Since I use {{{nxml-mode}}}, not {{{xml-mode}}}, this bothers me. A quick grep turns up: {{{ cd /home/naesten/hacking/haskell/ghc-hashedrepo/docs/users_guide/ grep -n -e 'mode: xml' --recursive . /dev/null ./runghc.xml:39: ;;; mode: xml *** ./packages.xml:1271: ;;; mode: xml *** ./5-00-notes.xml:204: ;;; mode: xml *** ./using.xml:1848: ;;; mode: xml *** ./utils.xml:561: ;;; mode: xml *** ./glasgow_exts.xml:7546: ;;; mode: xml *** ./license.xml:63: ;;; mode: xml *** ./ug-book.xml.in:28: ;;; mode: xml *** ./bugs.xml:404: ;;; mode: xml *** ./6.0-notes.xml:316: ;;; mode: xml *** ./debugging.xml:624: ;;; mode: xml *** ./5-04-notes.xml:285: ;;; mode: xml *** ./win32-dlls.xml:633: ;;; mode: xml *** ./5-02-notes.xml:54: ;;; mode: xml *** ./ghci.xml:2827: ;;; mode: xml *** ./flags.xml:2341: ;;; mode: xml *** ./lang.xml:12: ;;; mode: xml *** ./separate_compilation.xml:1261: ;;; mode: xml *** ./runtime_control.xml:691: ;;; mode: xml *** ./intro.xml:304: ;;; mode: xml *** ./installing.xml:529: ;;; mode: xml *** ./ffi-chap.xml:523: ;;; mode: xml *** ./sooner.xml:542: ;;; mode: xml *** ./parallel.xml:176: ;;; mode: xml *** ./profiling.xml:1713: ;;; mode: xml *** ./ug-book.xml:28: ;;; mode: xml *** ./phases.xml:1071: ;;; mode: xml *** ./gone_wrong.xml:210: ;;; mode: xml *** }}} Of these, probably only the one in {{{ug-book.xml.in}}} is actually useful, since that file doesn't have a name ending in .xml. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Apr 10 17:50:44 2008 From: trac at galois.com (GHC) Date: Thu Apr 10 17:46:17 2008 Subject: [GHC] #2209: MagicHash extraction is wrong on x86_64 with -fasm -O2 Message-ID: <044.b26772684deb839421045da398f72aae@localhost> #2209: MagicHash extraction is wrong on x86_64 with -fasm -O2 -------------------------------+-------------------------------------------- Reporter: quark | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: major Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Linux -------------------------------+-------------------------------------------- I am trying to directly get at the underlying IEEE representation of a Double with this code: {{{ word64ToDouble :: Word64 -> Double word64ToDouble w@(W64# x) = D# (unsafeCoerce# x) doubleToWord64 :: Double -> Word64 doubleToWord64 d@(D# x) = W64# (unsafeCoerce# x) }}} I have, of course, checked "isEEE x" and "(sizeOf x) == 8" etc, to know that it is OK to do this. This works on various x86 computers but fails on x86_64, when compiling with -fasm and -O2 (which I embedded with the OPTIONS pragma in the attached example). The example shows that for a Double "2.0", the Word64 is wrong. And for a Word64 which should represent Nan, "isNaN" fails. Here is the output of the program on "x86_64" (the buggy system): {{{ False: NaN 5697656 expect: 4611686018427387904 }}} Here is the expected output as seen on x86 systems: {{{ True 4611686018427387904 expect: 4611686018427387904 }}} Note that if you insert a "trace" call to display the Integer, Word64, or Double, the example gives the right output! But when you take out the trace, it fails. If a workaround for this problem can be identified, we would really appreciate it, as we are hitting this bug in code that we need to use but cannot workaround. If a fix is identified, it would be great if the fix made it into 6.8.3 (as we are happy to upgrade to that, rather than wait for a next stable release). In our system, we do have a workaround for the "doubleToWord64" bug, but I cannot reproduce it in the small example. What we do is define the function like this: {{{ doubleToWord64 :: Double -> Word64 doubleToWord64 d@(D# x) = if (d == d) then W64# (unsafeCoerce# x) else err ("doubleToWord64 " ++ show d) }}} This works in out system, but not in the attached example. And, again, we have no workaround for "word64ToDouble". -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Apr 10 18:13:28 2008 From: trac at galois.com (GHC) Date: Thu Apr 10 18:09:14 2008 Subject: [GHC] #2191: A way to programmatically cause GHC to report the cost center stack associated with a value In-Reply-To: <043.3641dba02e220ac3643aa7a87adf7815@localhost> References: <043.3641dba02e220ac3643aa7a87adf7815@localhost> Message-ID: <052.ca1278be1761cc902810c0bd72d4383f@localhost> #2191: A way to programmatically cause GHC to report the cost center stack associated with a value -----------------------------+---------------------------------------------- Reporter: SamB | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: Profiling | Version: 6.8.2 Severity: normal | Resolution: Keywords: patch | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by simonmar): * owner: SamB => simonmar * difficulty: => Unknown * milestone: => 6.10 branch Comment: The patch looks ok to me. Let's get it into 6.10. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Apr 10 19:03:48 2008 From: trac at galois.com (GHC) Date: Thu Apr 10 18:59:19 2008 Subject: [GHC] #2197: GHCi doesn't work when built with way=p In-Reply-To: <043.8ca8ccba553cfe5b0f79906ba5d25b8c@localhost> References: <043.8ca8ccba553cfe5b0f79906ba5d25b8c@localhost> Message-ID: <052.64fb2d81af76c7d83debbcb65a4bb6e0@localhost> #2197: GHCi doesn't work when built with way=p --------------------+------------------------------------------------------- Reporter: SamB | Owner: simonmar Type: bug | Status: new Priority: low | Milestone: 6.10 branch Component: GHCi | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Linux | --------------------+------------------------------------------------------- Comment (by SamB): Replying to [comment:2 simonmar]: > GHCi + profiling doesn't work for deeper reasons than this: it would require a lot of work in the byte-code compiler and interpreter. Well, what about using -fobject-code then? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Apr 10 23:59:15 2008 From: trac at galois.com (GHC) Date: Thu Apr 10 23:54:45 2008 Subject: [GHC] #2210: ghci gets into weird state if loading a module with a bad LANGUAGE pragma Message-ID: <042.5443ce857d991a3638a2d4dd2d291753@localhost> #2210: ghci gets into weird state if loading a module with a bad LANGUAGE pragma ------------------------+--------------------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- Try loading a module like this into `ghci`: {{{ {-# LANGUAGE BreakMe #-} }}} This gets `ghci` into an odd wedged state, with a strange prompt, in which `Prelude` is not available. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 11 00:55:07 2008 From: trac at galois.com (GHC) Date: Fri Apr 11 00:50:41 2008 Subject: [GHC] #2206: GADT pattern match with non-rigid return type In-Reply-To: <046.ef46bda025b4e7ab59ca8efa3b49bcc6@localhost> References: <046.ef46bda025b4e7ab59ca8efa3b49bcc6@localhost> Message-ID: <055.6390ed5d6924ec467ef8ca4a55a94a2a@localhost> #2206: GADT pattern match with non-rigid return type --------------------------+------------------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: gadt-escape1 | Architecture: Unknown Os: Unknown | --------------------------+------------------------------------------------- Comment (by chak): The implementation of GADTs in the development version of GHC recently changed completely. It's now based on a combination of implication constraints and type equality constraints. I believe what happens is the following. In the case alternative, we have `a :: ExpGADT t` together with an equality constraint `t ~ Int`. So, GHC is right to claim that `t` escapes its scope; it does albeit escape in conjunction with the equality `t ~ Int`. At the moment, GHC does not properly enforce the constraints on type rigidity, but in the course of investigating the interaction between GADTs and type families, we came to the conclusion that we need to require not only that the type of the scrutinee of a GADT match is rigid, but '''also its return type'''. Hence, the example code should indeed be rejected, but ideally the error message should point out that the return type should be rigid (instead of the somewhat unhelpful message produced currently). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 11 03:45:34 2008 From: trac at galois.com (GHC) Date: Fri Apr 11 03:41:05 2008 Subject: [GHC] #2211: Installing latest GHC-6.8.2 stable: pwd with floating point exception Message-ID: <044.6fa473611ed5d150325a47086f85da68@localhost> #2211: Installing latest GHC-6.8.2 stable: pwd with floating point exception -----------------------+---------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: Linux -----------------------+---------------------------------------------------- I tried to install http://www.haskell.org/ghc/dist/stable/dist/ghc-6.8.2.20080410-i386 -unknown-linux.tar.bz2 on Kubuntu. It was reported to be build properly: http://www.haskell.org/pipermail/cvs-ghc/2008-April/041915.html but I get: {{{ /tmp/ghc-6.8.2.20080410> ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu Which we'll further canonicalise into: i386-unknown-linux checking for path to top of build tree... configure: error: cannot determine current directory }}} From other reports I got to know that this might have to do with the custom 'pwd' of ghc installation. Indeed I get: {{{ /tmp/ghc-6.8.2.20080410> ./utils/pwd/pwd Floating point exception }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 11 07:32:48 2008 From: trac at galois.com (GHC) Date: Fri Apr 11 07:28:18 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.80247da5769d736cc22f42408eb8841b@localhost> #2142: :b doesn't invoke :browse, or even generate an ambiguous command error ----------------------+----------------------------------------------------- Reporter: SamB | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by SamB): By the way, the workaround is to put this in your {{{~/.ghci}}}: {{{ :def b (return . (":browse "++)) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 11 07:35:47 2008 From: trac at galois.com (GHC) Date: Fri Apr 11 07:31:18 2008 Subject: [GHC] #2206: GADT pattern match with non-rigid return type In-Reply-To: <046.ef46bda025b4e7ab59ca8efa3b49bcc6@localhost> References: <046.ef46bda025b4e7ab59ca8efa3b49bcc6@localhost> Message-ID: <055.257e6a807d6dfb146b8bbec9748605ac@localhost> #2206: GADT pattern match with non-rigid return type --------------------------+------------------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: gadt-escape1 | Architecture: Unknown Os: Unknown | --------------------------+------------------------------------------------- Changes (by simonpj): * owner: => simonpj Comment: Indeed. I have a fix for 2206 in my tree (testing now), so I'll take this. However, the whole rigidity thing is shaky (ha ha) at the moment, because boxy types and rigid types are mixed up. We need to take a new look as the dust settles on type equalities. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 11 07:36:26 2008 From: trac at galois.com (GHC) Date: Fri Apr 11 07:31:58 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.147d2180f87b92b7f5e31cb0a21975c2@localhost> #2142: :b doesn't invoke :browse, or even generate an ambiguous command error ----------------------+----------------------------------------------------- Reporter: SamB | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by SamB): Igloo: I think :browse *is* the more common operation. Certainly it is for me. Probably because I don't feel like loading whole programs as bytecode? If GHCi defined :br to be :browse, heavy debugger users could define :b to :break... besides, debugger users haven't had nearly so long to develop the habbit. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 11 09:38:27 2008 From: trac at galois.com (GHC) Date: Fri Apr 11 09:34:01 2008 Subject: [GHC] #2212: Double assignment to coercion variable Message-ID: <046.ad4e8af6cf182013c618bfd8fa17eb5c@localhost> #2212: Double assignment to coercion variable -------------------------+-------------------------------------------------- Reporter: simonpj | Owner: chak Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Keywords: Difficulty: Unknown | Testcase: equal Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- Test `gadt/equal` is failing with {{{ ghc-6.9: panic! (the 'impossible' happened) (GHC version 6.9 for x86_64-unknown-linux): ASSERT failed! file typecheck/TcMType.lhs line 520 t_aaS{tv} [tau] }}} (You may not see this if you don't build a DEBUG compiler.) The problem is that the same coercion variable is being assigned a value twice. Here it is with more info printed, showing the existing and new coercions {{{ ghc-6.9: panic! (the 'impossible' happened) (GHC version 6.9 for x86_64-unknown-linux): writeMetaTyVar t_aaS{tv} [tau] ghc-prim:GHC.Prim.trans{(w) tc 34y} t_abf{tv} [tau] (ghc-prim:GHC.Prim.sym{(w) tc 34v} $co${tc abb} [tv]) ghc-prim:GHC.Prim.trans{(w) tc 34y} (ghc-prim:GHC.Prim.trans{(w) tc 34y} (ghc-prim:GHC.Prim.trans{(w) tc 34y} $co${tc ab2} [tv] (a{tv aaz} [sk], $co${tc aaV} [tv])) ($co${tc aaY} [tv], b{tv aay} [sk])) t_ab8{tv} [tau] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 11 09:44:42 2008 From: trac at galois.com (GHC) Date: Fri Apr 11 09:40:13 2008 Subject: [GHC] #2209: MagicHash extraction is wrong on x86_64 with -fasm -O2 In-Reply-To: <044.b26772684deb839421045da398f72aae@localhost> References: <044.b26772684deb839421045da398f72aae@localhost> Message-ID: <053.af9a3a8f78f07e1a9952fae4acb6336c@localhost> #2209: MagicHash extraction is wrong on x86_64 with -fasm -O2 -------------------------------+-------------------------------------------- Reporter: quark | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: major | Resolution: Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Linux -------------------------------+-------------------------------------------- Changes (by ravi): * cc: ravi (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 11 10:36:03 2008 From: trac at galois.com (GHC) Date: Fri Apr 11 10:31:32 2008 Subject: [GHC] #1365: -fbyte-code is ignored in a OPTIONS_GHC pragma In-Reply-To: <047.0b0f638b3610964bc1921eacae64b292@localhost> References: <047.0b0f638b3610964bc1921eacae64b292@localhost> Message-ID: <056.e57b5f2b97b951a32096d7ce8ac1c937@localhost> #1365: -fbyte-code is ignored in a OPTIONS_GHC pragma -----------------------------+---------------------------------------------- Reporter: mnislaih | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.6.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | -----------------------------+---------------------------------------------- Changes (by SamB): * version: 6.7 => 6.6.1 Comment: I'm beginning to find that restriction rather annoying, too. Why can't object code depend on bytecode? In any case, I would prefer that -fbyte- code in a pragma would cause all dependancies to be byte-compiled, rather than doing nothing. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 11 10:36:55 2008 From: trac at galois.com (GHC) Date: Fri Apr 11 10:32:24 2008 Subject: [GHC] #1365: -fbyte-code is ignored in a OPTIONS_GHC pragma In-Reply-To: <047.0b0f638b3610964bc1921eacae64b292@localhost> References: <047.0b0f638b3610964bc1921eacae64b292@localhost> Message-ID: <056.061110d799700b910d3966698f13999b@localhost> #1365: -fbyte-code is ignored in a OPTIONS_GHC pragma -----------------------------+---------------------------------------------- Reporter: mnislaih | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.6.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | -----------------------------+---------------------------------------------- Changes (by SamB): * cc: SamB (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 11 10:38:36 2008 From: trac at galois.com (GHC) Date: Fri Apr 11 10:34:04 2008 Subject: [GHC] #2213: -Wall incorrectly warns "Defined but not used" for functions exported via RULES Message-ID: <043.a16de73b756c546cfe361c8db1abcd3b@localhost> #2213: -Wall incorrectly warns "Defined but not used" for functions exported via RULES ------------------------+--------------------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- Functions exported via rewrite rules are incorrectly flagged as "defined but not used" when -Wall is enabled: {{{ module M ({- rules -}) where eq :: Eq a => a -> a -> Bool eq = (==) {-# RULES "rule 1" forall x. x == y = y `eq` x #-} }}} Will emit a bogus: {{{ M.hs:4:0: Warning: Defined but not used: `eq' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 11 10:48:52 2008 From: trac at galois.com (GHC) Date: Fri Apr 11 10:44:22 2008 Subject: [GHC] #2044: "Can't unify" error in debugger In-Reply-To: <044.9de84d1571c81bf2b4030ee1192776b2@localhost> References: <044.9de84d1571c81bf2b4030ee1192776b2@localhost> Message-ID: <053.6906d23c7f0946ecf206a650f6bee669@localhost> #2044: "Can't unify" error in debugger --------------------+------------------------------------------------------- Reporter: r6144 | Owner: mnislaih Type: bug | Status: assigned Priority: normal | Milestone: 6.8.3 Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | --------------------+------------------------------------------------------- Comment (by simonpj): I don't fully grok the debugger type reconstruction, but `newBoxyTyVar` might be what you want. It does not insist on unifying with a monotype. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 11 11:20:38 2008 From: trac at galois.com (GHC) Date: Fri Apr 11 11:16:29 2008 Subject: [GHC] #2197: GHCi doesn't work when built with way=p In-Reply-To: <043.8ca8ccba553cfe5b0f79906ba5d25b8c@localhost> References: <043.8ca8ccba553cfe5b0f79906ba5d25b8c@localhost> Message-ID: <052.1da5453a5f5d7462e856311cc5d43659@localhost> #2197: GHCi doesn't work when built with way=p --------------------+------------------------------------------------------- Reporter: SamB | Owner: simonmar Type: bug | Status: new Priority: low | Milestone: 6.10 branch Component: GHCi | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Linux | --------------------+------------------------------------------------------- Changes (by SamB): * cc: SamB (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 11 12:13:58 2008 From: trac at galois.com (GHC) Date: Fri Apr 11 12:09:31 2008 Subject: [GHC] #2192: occasional segmentation faults when using Control.Parallel In-Reply-To: <044.41e146963f3d21c260430274434fb250@localhost> References: <044.41e146963f3d21c260430274434fb250@localhost> Message-ID: <053.1bc1c3bd748ffcbb34bb00462502246c@localhost> #2192: occasional segmentation faults when using Control.Parallel ----------------------+----------------------------------------------------- Reporter: ivant | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: major | Resolution: Keywords: par | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------+----------------------------------------------------- Changes (by simonmar): * owner: => simonmar * difficulty: => Unknown * milestone: => 6.8.3 Comment: I can repeat this one. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 11 12:26:28 2008 From: trac at galois.com (GHC) Date: Fri Apr 11 12:22:08 2008 Subject: [GHC] #2197: GHCi doesn't work when built with way=p In-Reply-To: <043.8ca8ccba553cfe5b0f79906ba5d25b8c@localhost> References: <043.8ca8ccba553cfe5b0f79906ba5d25b8c@localhost> Message-ID: <052.51125f331f04ae7fc2394a80ac3040e0@localhost> #2197: GHCi doesn't work when built with way=p --------------------+------------------------------------------------------- Reporter: SamB | Owner: simonmar Type: bug | Status: new Priority: low | Milestone: 6.10 branch Component: GHCi | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Linux | --------------------+------------------------------------------------------- Comment (by simonmar): Replying to [comment:3 SamB]: > Well, what about using -fobject-code then? Yes, that would make the problem smaller. However you may have noticed that `-fobject-code` doesn't currently apply to expressions typed at the prompt, so that would need to change. And you'd get no debugging support. And we'd need to modify Cabal to generate profiled GHCi libraries, as you pointed out earlier (and modify GHCi to load the profiled versions). So it's possible, but not the work of an afternoon. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 11 13:08:56 2008 From: trac at galois.com (GHC) Date: Fri Apr 11 13:04:43 2008 Subject: [GHC] #1147: Quadratic behaviour in the compacting GC In-Reply-To: <047.3990d03b7d94d2de519d27da619e58b4@localhost> References: <047.3990d03b7d94d2de519d27da619e58b4@localhost> Message-ID: <056.2cbf8f750b11db7711927186bf9e8cd3@localhost> #1147: Quadratic behaviour in the compacting GC --------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: _|_ Component: Runtime System | Version: 6.6 Severity: normal | Resolution: Keywords: ghci compacting | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------------------+------------------------------------- Changes (by SamB): * keywords: => ghci compacting * cc: SamB (added) * type: bug => run-time performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 11 13:09:43 2008 From: trac at galois.com (GHC) Date: Fri Apr 11 13:05:12 2008 Subject: [GHC] #728: switch to compacting collection when swapping occurs In-Reply-To: <047.d71284f919c6246c824e6f6eb3e3cecf@localhost> References: <047.d71284f919c6246c824e6f6eb3e3cecf@localhost> Message-ID: <056.513265a6ac54073a131015350d476f95@localhost> #728: switch to compacting collection when swapping occurs -----------------------------+---------------------------------------------- Reporter: simonmar | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Runtime System | Version: 6.4.1 Severity: major | Resolution: Keywords: compacting | Difficulty: Moderate (1 day) Testcase: N/A | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by SamB): * keywords: => compacting * cc: SamB (added) * severity: normal => major -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 11 13:14:51 2008 From: trac at galois.com (GHC) Date: Fri Apr 11 13:10:19 2008 Subject: [GHC] #2214: trac wishes: "performance feature request" ticket type, "trac" component Message-ID: <043.156bdc7118ceb84356b82cee2d61b60c@localhost> #2214: trac wishes: "performance feature request" ticket type, "trac" component ------------------------+--------------------------------------------------- Reporter: SamB | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- It would be nice if there was a ticket type for performance feature requests. Also, in creating this ticket, I notice there is no component for issues with the trac configuration like this. So that would also be nice ;-). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 11 13:23:41 2008 From: trac at galois.com (GHC) Date: Fri Apr 11 13:19:11 2008 Subject: [GHC] #2215: :disable command to disable breakpoints Message-ID: <043.47da2ed31d640e7b0815bd5873ce0ad5@localhost> #2215: :disable command to disable breakpoints --------------------------------+------------------------------------------- Reporter: SamB | Owner: Type: feature request | Status: new Priority: normal | Component: GHCi Version: 6.9 | Severity: major Keywords: debugger ghci | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- Okay, I've finally gotten around to trying the debugger, and I noticed that there don't seem to be any commands to disable or reenable breakpoints. These would be really nice, and probably not too difficult. The names should be {{{:disable}}}and {{{:enable}}}. (That's what I expected them to be.) Man, I wish there was a severity between "normal" and "major"... -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 11 14:26:59 2008 From: trac at galois.com (GHC) Date: Fri Apr 11 14:22:33 2008 Subject: [GHC] #2192: occasional segmentation faults when using Control.Parallel In-Reply-To: <044.41e146963f3d21c260430274434fb250@localhost> References: <044.41e146963f3d21c260430274434fb250@localhost> Message-ID: <053.eca99b7d43d0ab3b02bd80dd8bfc8433@localhost> #2192: occasional segmentation faults when using Control.Parallel ----------------------------+----------------------------------------------- Reporter: ivant | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.8.3 Component: Runtime System | Version: 6.8.2 Severity: major | Resolution: Keywords: par | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------------+----------------------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge * component: Compiler => Runtime System Comment: This fixes it for me: {{{ Fri Apr 11 10:34:04 PDT 2008 Simon Marlow * FIX #2197: an update frame might point to an IND_OLDGEN }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 11 14:28:57 2008 From: trac at galois.com (GHC) Date: Fri Apr 11 14:24:40 2008 Subject: [GHC] #2171: Parallel program crashes In-Reply-To: <042.91539dd5667f046cb861faa36a106615@localhost> References: <042.91539dd5667f046cb861faa36a106615@localhost> Message-ID: <051.e788399de329804aa3d6ae9e41d41335@localhost> #2171: Parallel program crashes ---------------------------------------------+------------------------------ Reporter: fed | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Runtime System | Version: 6.8.2 Severity: critical | Resolution: Keywords: parallel, crash, race condition | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ---------------------------------------------+------------------------------ Comment (by simonmar): Can someone who can reproduce this bug please try the fix from #2192 (now pushed to HEAD)? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 11 15:42:38 2008 From: trac at galois.com (GHC) Date: Fri Apr 11 15:38:07 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.256020340acaa6a05dd8af72a0b3362d@localhost> #2142: :b doesn't invoke :browse, or even generate an ambiguous command error ----------------------+----------------------------------------------------- Reporter: SamB | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by jyrinx): Replying to [comment:5 SamB]: > By the way, the workaround is to put this in your {{{~/.ghci}}}: > > {{{ > :def b (return . (":browse "++)) > }}} Oh - duh :-D Good idea, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 11 16:21:18 2008 From: trac at galois.com (GHC) Date: Fri Apr 11 16:16:44 2008 Subject: [GHC] #1964: GHC.Prim In-Reply-To: <044.9207dad19026729963694adf6b204b9d@localhost> References: <044.9207dad19026729963694adf6b204b9d@localhost> Message-ID: <053.c3f1be38346d8eb9172e730f7c685c0d@localhost> #1964: GHC.Prim ----------------------+----------------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by SamB): Well, we have a magic ghc-prim package now. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 11 16:29:42 2008 From: trac at galois.com (GHC) Date: Fri Apr 11 16:25:11 2008 Subject: [GHC] #1444: Template Haskell: add proper support for qualified names in non-splicing applications In-Reply-To: <043.13bd5bcef9b2285ee8443a489f6d7487@localhost> References: <043.13bd5bcef9b2285ee8443a489f6d7487@localhost> Message-ID: <052.5696a36cce47f6ea1e22962fdca4dfc2@localhost> #1444: Template Haskell: add proper support for qualified names in non-splicing applications ------------------------------+--------------------------------------------- Reporter: SamB | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: Template Haskell | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ------------------------------+--------------------------------------------- Changes (by SamB): * cc: SamB (added) Comment: Replying to [comment:12 igloo]: > So basically you want pprinting TH to generate portable code. Well, it doesn't have to be pprint. But it would be nice to have a reasonable way... > In general this is impossible as TH can dig out names that aren't exported. Well, obviously it won't be possible to print nonportable code into portable code... but that isn't the point at all ;-). > Apart from that, something like a "canonical" name could work. A nicer alternative might be a way to ask, in the Q monad, which modules (either giving it a list of module Name's, or using the modules that the current module imports) export a given name. It would be nice if it were possible to trace how the name was imported... -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 11 17:14:40 2008 From: trac at galois.com (GHC) Date: Fri Apr 11 17:10:08 2008 Subject: [GHC] #2215: :disable command to disable breakpoints In-Reply-To: <043.47da2ed31d640e7b0815bd5873ce0ad5@localhost> References: <043.47da2ed31d640e7b0815bd5873ce0ad5@localhost> Message-ID: <052.4ebae292a715a5d4f2889a4e100de8e7@localhost> #2215: :disable command to disable breakpoints -----------------------------+---------------------------------------------- Reporter: SamB | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.9 Severity: major | Resolution: Keywords: debugger ghci | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by simonmar): * difficulty: => Unknown Comment: Note that you can do {{{ > :set stop 0 :continue }}} which is effectively what you'd get with `:disable 0`. You can do contitional breakpoints with this trick too, and also breakpoints that are ignored for a certain number of stops. See the docs for `:set stop`: [http://www.haskell.org/ghc/docs/latest/html/users_guide/ghci- commands.html] Admittedly this is a bit clunky, and you can't combine conditional breakpoints with disable, etc. So I'll leave this ticket open. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 11 20:06:34 2008 From: trac at galois.com (GHC) Date: Fri Apr 11 20:02:16 2008 Subject: [GHC] #2216: Bad error message for unboxed types with no -fglasgow-exts flag Message-ID: <042.15c11e3b7bac7b751aafc89a9516ed93@localhost> #2216: Bad error message for unboxed types with no -fglasgow-exts flag ------------------------+--------------------------------------------------- Reporter: tim | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 6.8.2 | Severity: minor Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- If I compile: {{{ module Foo where import GHC.Exts foo = I# 42# }}} with {{{ghc -c}}}, I get: {{{ Overloaded.hs:6:0: parse error (possibly incorrect indentation) }}} A better message would suggest using {{{-fglasgow-exts}}} (or something.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Apr 12 05:33:48 2008 From: trac at galois.com (GHC) Date: Sat Apr 12 05:29:14 2008 Subject: [GHC] #2217: :list command missing from help Message-ID: <044.fbe338f21c5a3bd6c2e8b69d2945b572@localhost> #2217: :list command missing from help -----------------------+---------------------------------------------------- Reporter: mrijn | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.8.2 | Severity: trivial Keywords: | Testcase: Architecture: x86 | Os: MacOS X -----------------------+---------------------------------------------------- The {{{:list}}} command is missing from the list that {{{:help}}} displays. It should be listed under ''Commands for debugging'' between {{{:history}}} and {{{:print}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Apr 12 15:20:00 2008 From: trac at galois.com (GHC) Date: Sat Apr 12 15:15:39 2008 Subject: [GHC] #2187: Top-level bindings are broken for polymorphic values In-Reply-To: <045.4e9ad0d5e8f90abbc43e5cdae1d520dd@localhost> References: <045.4e9ad0d5e8f90abbc43e5cdae1d520dd@localhost> Message-ID: <054.a7ce8482e63f831d4c00bcf58a55dbdd@localhost> #2187: Top-level bindings are broken for polymorphic values ----------------------+----------------------------------------------------- Reporter: yallop | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by SamB): * cc: SamB (added) Comment: *more* ugly warts? I thought we were trying to get *rid* of those ... Any bets on which 6.10.x release will revert this? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Apr 12 16:17:42 2008 From: trac at galois.com (GHC) Date: Sat Apr 12 16:13:11 2008 Subject: [GHC] #2218: ghci leaks memory on :reload etc Message-ID: <045.8a6d8f2645e2e281aaf28111fdc114b6@localhost> #2218: ghci leaks memory on :reload etc -----------------------+---------------------------------------------------- Reporter: ganesh | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: Linux -----------------------+---------------------------------------------------- Memory usage seems to increase on every :reload of interpreted code; I understand that the bytecode isn't being GCed. This is rather inconvenient for development on a memory constrained system. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Apr 13 21:57:29 2008 From: trac at galois.com (GHC) Date: Sun Apr 13 21:52:49 2008 Subject: [GHC] #2120: Arrays allow out-of-bounds indexes In-Reply-To: <046.df9dbe29ac2a6f0cde1841f7056aebbe@localhost> References: <046.df9dbe29ac2a6f0cde1841f7056aebbe@localhost> Message-ID: <055.37cdbcd9b4389e32eb31dd0ee222fe2d@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: Multiple Os: Multiple | -------------------------------+-------------------------------------------- Changes (by ajd): * cc: alexander.dunlap@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Apr 14 00:32:21 2008 From: trac at galois.com (GHC) Date: Mon Apr 14 00:27:46 2008 Subject: [GHC] #2218: ghci leaks memory on :reload etc In-Reply-To: <045.8a6d8f2645e2e281aaf28111fdc114b6@localhost> References: <045.8a6d8f2645e2e281aaf28111fdc114b6@localhost> Message-ID: <054.c42814715cc0c33c1053ad9dc5103f6e@localhost> #2218: ghci leaks memory on :reload etc -----------------------+---------------------------------------------------- Reporter: ganesh | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Linux -----------------------+---------------------------------------------------- Changes (by guest): * cc: kfrdbs@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Apr 14 03:13:42 2008 From: trac at galois.com (GHC) Date: Mon Apr 14 03:09:02 2008 Subject: [GHC] #2219: GADT match fails to refine type variable Message-ID: <044.d581efc20e7649a6ed48131c2b7ba2cd@localhost> #2219: GADT match fails to refine type variable ---------------------------------+------------------------------------------ Reporter: dolio | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 6.9 | Severity: normal Keywords: gadt type family | Testcase: Architecture: x86 | Os: Linux ---------------------------------+------------------------------------------ The following code is accepted by the type checker in 6.8.2, but is rejected by a HEAD build, 6.9.20080411: {{{ {-# LANGUAGE TypeFamilies, GADTs, EmptyDataDecls, TypeOperators #-} data Zero data Succ a data FZ data FS fn data Fin n fn where FZ :: Fin (Succ n) FZ FS :: Fin n fn -> Fin (Succ n) (FS fn) data Nil data a ::: b type family Lookup ts fn :: * type instance Lookup (t ::: ts) FZ = t type instance Lookup (t ::: ts) (FS fn) = Lookup ts fn data Tuple n ts where Nil :: Tuple Zero Nil (:::) :: t -> Tuple n ts -> Tuple (Succ n) (t ::: ts) proj :: Fin n fn -> Tuple n ts -> Lookup ts fn proj FZ (v ::: _) = v proj (FS fn) (_ ::: vs) = proj fn vs }}} The error in question is: {{{ Bug.hs:25:16: Occurs check: cannot construct the infinite type: t = Lookup (t ::: ts) fn In the pattern: v ::: _ In the definition of `proj': proj FZ (v ::: _) = v }}} Which seems to indicate that the pattern match against {{{FZ}}} in the first case is failing to refine the type variable {{{fn}}} to {{{FZ}}}. Reversing the order of the cases yields the same error, so either the match against FS is working correctly, or the type checker thinks that it can solve {{{Lookup (t ::: ts) fn ~ Lookup ts fn}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Apr 14 09:28:13 2008 From: trac at galois.com (GHC) Date: Mon Apr 14 09:23:35 2008 Subject: [GHC] #1886: GHC API should preserve and provide access to comments In-Reply-To: <044.eac6e4e9449b44410013b3e7df813e47@localhost> References: <044.eac6e4e9449b44410013b3e7df813e47@localhost> Message-ID: <053.a4bc77278698745f0fda08cc14484da9@localhost> #1886: GHC API should preserve and provide access to comments ---------------------------------------------------------------+------------ Reporter: claus | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: GHC API | Version: 6.9 Severity: normal | Resolution: Keywords: GHC API, comments, program transformation, layout | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------------------------------------------------+------------ Comment (by claus): see also this thread on `cvs-ghc`, messages before and after this one: [http://www.haskell.org/pipermail/cvs-ghc/2007-November/039526.html should haddock.ghc be a sub-repo of ghc?] -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Apr 14 09:48:59 2008 From: trac at galois.com (GHC) Date: Mon Apr 14 09:44:17 2008 Subject: [GHC] #1886: GHC API should preserve and provide access to comments In-Reply-To: <044.eac6e4e9449b44410013b3e7df813e47@localhost> References: <044.eac6e4e9449b44410013b3e7df813e47@localhost> Message-ID: <053.0dcca58f404f2aee636ceda38c07d8be@localhost> #1886: GHC API should preserve and provide access to comments ---------------------------------------------------------------+------------ Reporter: claus | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: GHC API | Version: 6.9 Severity: normal | Resolution: Keywords: GHC API, comments, program transformation, layout | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------------------------------------------------+------------ Changes (by j.waldmann): * cc: j.waldmann (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Apr 14 13:41:02 2008 From: trac at galois.com (GHC) Date: Mon Apr 14 13:36:23 2008 Subject: [GHC] #2220: Subprocesses do not close open FDs Message-ID: <045.c8c0847f8d8ff9265acf5e0d94c0a49c@localhost> #2220: Subprocesses do not close open FDs -------------------------+-------------------------------------------------- Reporter: Baughn | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Multiple | Os: Multiple -------------------------+-------------------------------------------------- When creating a subprocess, for example with runInteractiveProcess, only pipes that are created in the process of creating the process are closed appropriately; any FDs created elsewhere in the program are ignored. As unix pipes are only considered closed once every process that could conceivably write to one has closed it, one consequence of this is that programs that rely on detecting EOF will be unable to do so. Another is that the system may leak FDs over the runtime of the program, conceivably running out. As an example, this makes it impossible to write a fully functional shell with pipes in GHC; in a shell command like "
| cat | cat", the second cat may acquire a reference to the pipe used for writing to the first one, which will prevent that pipe from ever being considered closed. A brute-force solution would be to attempt to close every possible FD when creating subprocesses. This is undesirable for several reasons - most obviously performance, but also because there are legitimate reasons to pass FDs other than stdin/out/err to a subprocess. A more elegant one would be for all FDs opened by any means to be marked as close-on-exec on creation, and provide a call to clear this bit if transferring it to a specific subprocess is desired. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Apr 14 13:51:36 2008 From: trac at galois.com (GHC) Date: Mon Apr 14 13:46:55 2008 Subject: [GHC] #2220: Subprocesses do not close open FDs In-Reply-To: <045.c8c0847f8d8ff9265acf5e0d94c0a49c@localhost> References: <045.c8c0847f8d8ff9265acf5e0d94c0a49c@localhost> Message-ID: <054.b1b4497e342189095362e314c26c2cc0@localhost> #2220: Subprocesses do not close open FDs -------------------------------+-------------------------------------------- Reporter: Baughn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Multiple | Os: Multiple -------------------------------+-------------------------------------------- Comment (by Baughn): If setting FD_CLOEXEC (close on exec) is picked, then.. since it has to be set in a separate call after opening the FD, there is a potential race condition if any other thread calls exec. Probably only one OS thread should do I/O or forks - my understanding is that this is already the case, but it had to be mentioned. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Apr 14 16:49:59 2008 From: trac at galois.com (GHC) Date: Mon Apr 14 16:45:18 2008 Subject: [GHC] #2221: Can't use quotationes ([| ... |]) insides declaration splices Message-ID: <045.c35167d86424a00c668b9f902bbda2e4@localhost> #2221: Can't use quotationes ([| ... |]) insides declaration splices -----------------------+---------------------------------------------------- Reporter: m4dc4p | Owner: Type: bug | Status: new Priority: normal | Component: Template Haskell Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: Windows -----------------------+---------------------------------------------------- Normal Template Haskell allows many levels of splicing and quotations: {{{ > runQ [| (const $([|"Int"|])) |] AppE (VarE GHC.Base.const) (LitE (StringL "Int")) }}} And TH can parse declarations easily: {{{ > runQ [d| type T = Int|] [TySynD T [] (ConT GHC.Base.Int)] }}} But splicing inside a declaration gives a syntax error: {{{ > runQ [d| type T = $([t|Int|])|] parse error on input `$(' }}} Another example. Bulat Ziganshin defines the cnst function (http://www.haskell.org/bz/th3.htm) as: {{{ cnst 0 str = [| str |] cnst n str = [| \_ -> $(cnst (n-1) str) |] }}} Which evaluates to a function that takes n arguments and returns the string given. It would make sense that a function to define a data constructor which takes n arguments could be written similarly: {{{ dataCnst n = [d|data D = D $(dataCnst' n)|] dataCnst' n = [t|Int|] ++ dataCnst' (n - 1) }}} Finally, a function that makes a data type which varies the field type based on an argument: {{{ dataVar n = [d|data D = D $(dataVar' n)|] dataVar' "Int" = ''Int dataVar' "String" = ''String etc. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Apr 14 16:50:26 2008 From: trac at galois.com (GHC) Date: Mon Apr 14 16:45:46 2008 Subject: [GHC] #2221: Can't use quotations ([| ... |]) insides declaration splices In-Reply-To: <045.c35167d86424a00c668b9f902bbda2e4@localhost> References: <045.c35167d86424a00c668b9f902bbda2e4@localhost> Message-ID: <054.fdc157f799cfdd74b80db09296ffdf6e@localhost> #2221: Can't use quotations ([| ... |]) insides declaration splices ---------------------------------+------------------------------------------ Reporter: m4dc4p | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Windows ---------------------------------+------------------------------------------ Changes (by m4dc4p): * summary: Can't use quotationes ([| ... |]) insides declaration splices => Can't use quotations ([| ... |]) insides declaration splices -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Apr 14 18:20:59 2008 From: trac at galois.com (GHC) Date: Mon Apr 14 18:16:19 2008 Subject: [GHC] #1877: Change the meaning of -fextended-default-rules In-Reply-To: <047.a9d9acd5b305477a9660b9018aae5df1@localhost> References: <047.a9d9acd5b305477a9660b9018aae5df1@localhost> Message-ID: <056.d567211fb604040f5aafbb6180caae20@localhost> #1877: Change the meaning of -fextended-default-rules ----------------------+----------------------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by SamB): Replying to [comment:3 igloo]: > OK, thanks for pointing that out, sorear. It sounds like we need 2 flags then: One to control behaviour for code typed at the GHCi prompt, and one for the behaviour for code from files. In which case we should leave the existing flag with its current meaning and add one to control the behaviour for code typed at the GHCi prompt. What about the -X flag? We could use that one for source files and -fextended-default-rules for GHCi. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Apr 14 20:14:21 2008 From: trac at galois.com (GHC) Date: Mon Apr 14 20:09:45 2008 Subject: [GHC] #1592: Unexpected boxing in generated code In-Reply-To: <043.c04e3bd244a4eae851af8c18594bf095@localhost> References: <043.c04e3bd244a4eae851af8c18594bf095@localhost> Message-ID: <052.8e0f78b2f3d6d4346123d50f2537ed63@localhost> #1592: Unexpected boxing in generated code ----------------------+----------------------------------------------------- Reporter: neil | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.6.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by SamB): neil, you really need to work on your style ;-). More seriously, maybe your compiler should use {{{seq}}} to indicate that it wants things to be strict? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Apr 15 01:25:32 2008 From: trac at galois.com (GHC) Date: Tue Apr 15 01:20:54 2008 Subject: [GHC] #2219: GADT match fails to refine type variable In-Reply-To: <044.d581efc20e7649a6ed48131c2b7ba2cd@localhost> References: <044.d581efc20e7649a6ed48131c2b7ba2cd@localhost> Message-ID: <053.96edf17162fc0b3504d17203f1e8af55@localhost> #2219: GADT match fails to refine type variable ----------------------------------------+----------------------------------- Reporter: dolio | Owner: chak Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: gadt type family | Testcase: Architecture: x86 | Os: Linux ----------------------------------------+----------------------------------- Changes (by chak): * owner: => chak -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Apr 15 02:27:38 2008 From: trac at galois.com (GHC) Date: Tue Apr 15 02:23:02 2008 Subject: [GHC] #2222: Template Haskell: reify returns incorrect types when ommiting type signatures Message-ID: <043.ad3979036d0a8d6334de105353abe0e3@localhost> #2222: Template Haskell: reify returns incorrect types when ommiting type signatures ------------------------+--------------------------------------------------- Reporter: fons | Owner: Type: bug | Status: new Priority: normal | Component: Template Haskell Version: 6.8.2 | Severity: major Keywords: | Testcase: Architecture: Unknown | Os: Multiple ------------------------+--------------------------------------------------- Replicable with GHC versions 6.8.2 and 6.9 (20080219 snapshot). Workaround: supply type signatures. See the following examples: `ReifyPlusTypeInferenceBugs.hs` {{{ {-# LANGUAGE TemplateHaskell #-} module ReifyPlusTypeInferenceBugs where import Language.Haskell.TH -- First problem: -- * reify doesn't return the expected type of names binded to -- polymorphic expressions -- a :: Num a => a -- uncommenting the line above fixes the problem a = 1 -- The following splice should print -- "inside b: forall a_0 . GHC.Num.Num a_0 => a_0" -- but instead, it merely prints a type variable "inside b: t_0" b = $(do VarI _ t _ _ <- reify 'a runIO $ putStrLn ("inside b: " ++ pprint t) [| undefined |]) -- Second problem: -- * reify doesn't return the expected type of names binded to -- TH-spliced expressions if no explicit type signature -- declaration is provided. -- c :: Bool -- uncommenting the line above fixes the problem c = $([| True |]) -- this splice should print "inside d: GHC.Base.Bool" -- but, again, it prints just a type variable: "inside d: t_0" d = $(do VarI _ t _ _ <- reify 'c runIO $ putStrLn ("inside d: " ++ pprint t) [| undefined |] ) -- Strangely enough, reify works differently if called inside a declaration -- splice. This time, the type returned is closer to be right -- but unnecesary type variables are included: -- "type of c: forall a_0 a_1 . GHC.Base.Bool" $(do VarI _ t _ _ <- reify 'c runIO $ putStrLn ("type of c: " ++ pprint t) return [] ) -- Even more strange is the fact that the order of declaration of -- splices seems to matter. Declaring the exact example again .... -- e :: Bool -- uncommenting the line above solves the problem e = $([| True |]) -- this splice works as expected!!! ??? -- "inside f: GHC.Base.Bool" f = $(do VarI _ t _ _ <- reify 'e runIO $ putStrLn ("inside f: " ++ pprint t) [| undefined |] ) -- Here, we still get unnecesary variables, but, for some reason, -- _just_ one in this case: -- "type of e: forall a_0 . GHC.Base.Bool" $(do VarI _ t _ _ <- reify 'e runIO $ putStrLn ("type of e: " ++ pprint t) return [] ) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Apr 15 03:55:51 2008 From: trac at galois.com (GHC) Date: Tue Apr 15 03:51:08 2008 Subject: [GHC] #2220: Subprocesses do not close open FDs In-Reply-To: <045.c8c0847f8d8ff9265acf5e0d94c0a49c@localhost> References: <045.c8c0847f8d8ff9265acf5e0d94c0a49c@localhost> Message-ID: <054.bdf222995a129ac8067f46de4695fd24@localhost> #2220: Subprocesses do not close open FDs -------------------------------+-------------------------------------------- Reporter: Baughn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Multiple | Os: Multiple -------------------------------+-------------------------------------------- Changes (by Baughn): * cc: sveina@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Apr 15 04:53:47 2008 From: trac at galois.com (GHC) Date: Tue Apr 15 04:49:04 2008 Subject: [GHC] #2044: "Can't unify" error in debugger In-Reply-To: <044.9de84d1571c81bf2b4030ee1192776b2@localhost> References: <044.9de84d1571c81bf2b4030ee1192776b2@localhost> Message-ID: <053.8c6a273a4fc41a853ca9628cc07afe5c@localhost> #2044: "Can't unify" error in debugger --------------------+------------------------------------------------------- Reporter: r6144 | Owner: mnislaih Type: bug | Status: assigned Priority: normal | Milestone: 6.8.3 Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | --------------------+------------------------------------------------------- Comment (by mnislaih): The way I see it, :print is dealing with concrete values here, and a value has a factual type. It does not make sense to impose restrictions like class predicates or higher rank foralls on the value's type. Thus I believe those higher-rank foralls should be dropped. If we have a function type on the other hand, the foralls should be respected. But :print should not touch the types of function types anyway. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Apr 15 05:15:18 2008 From: trac at galois.com (GHC) Date: Tue Apr 15 05:10:34 2008 Subject: [GHC] #2044: "Can't unify" error in debugger In-Reply-To: <044.9de84d1571c81bf2b4030ee1192776b2@localhost> References: <044.9de84d1571c81bf2b4030ee1192776b2@localhost> Message-ID: <053.8973000a4fcdd2a41399a87bc0259c81@localhost> #2044: "Can't unify" error in debugger --------------------+------------------------------------------------------- Reporter: r6144 | Owner: mnislaih Type: bug | Status: assigned Priority: normal | Milestone: 6.8.3 Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | --------------------+------------------------------------------------------- Comment (by simonpj): A value can be * A basic type like `Int` * A function, like `Int -> Int` * An overloaded function like `forall a. Eq a => a -> a`, or non-function like `forall a. Num a => a` * A polymorphic function like `forall a. [a] -> [a]`, or non-function like `forall a. [a]` * With impredicative polymorphism, a data structure containing polymorphic values, like `[forall a. a ->a]` or `[forall a. Eq a = a -> a]` These are all perfectly concrete values. A function of type `forall a. Eq a => a -> a` takes two arguments not one, for example. I'm not sure what you mean by a "factual type", nor what you mean by "should not touch the types of function types". It's true that in the '''representation''', the foralls are dropped, so a function of type `forall a. [a] -> [a]` takes just one argument. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Apr 15 07:03:32 2008 From: trac at galois.com (GHC) Date: Tue Apr 15 06:58:51 2008 Subject: [GHC] #2044: "Can't unify" error in debugger In-Reply-To: <044.9de84d1571c81bf2b4030ee1192776b2@localhost> References: <044.9de84d1571c81bf2b4030ee1192776b2@localhost> Message-ID: <053.5988916874a52f8d7239ac14e0da60dd@localhost> #2044: "Can't unify" error in debugger --------------------+------------------------------------------------------- Reporter: r6144 | Owner: mnislaih Type: bug | Status: assigned Priority: normal | Milestone: 6.8.3 Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | --------------------+------------------------------------------------------- Comment (by mnislaih): Sorry, by "should not touch the types of function types", I mean that :print can only reconstruct types for non-function values, and thus it does not deal with the types of function values. A function value for :print is a Fun closure. When a call to a polymorphic function is done, the outer level foralls are instantiated and eliminated. The role of :print is to find out what is the particular instantiation. But this is true for outer level foralls only. For higher rank foralls inside Type Constructors, that is, impredicative types (is this the correct terminology ?) I am in doubt, since I don't understand the implications of impredicative types. These foralls are restrictions too after all, which have already been checked. Is it ok to drop them? I need to do some reading. By the way an interesting question about typeclass predicates. Suppose we have a function type `forall a. Show a => a -> a`. If :print recovers a concrete type for the first arg., then by assumption this type is an instance of Show. If :print does not recover a type, it would be nice to pack the dictionary, which :print has access to, and say "x has type Show a => a and you can call show for it in GHCi", but I don't see how that can be expressed. But even more, maybe can we use the dictionaries themselves for recovering more types ? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 16 05:00:16 2008 From: trac at galois.com (GHC) Date: Wed Apr 16 04:55:30 2008 Subject: [GHC] #2044: "Can't unify" error in debugger In-Reply-To: <044.9de84d1571c81bf2b4030ee1192776b2@localhost> References: <044.9de84d1571c81bf2b4030ee1192776b2@localhost> Message-ID: <053.511499a379e4754772e6f56b78b36fce@localhost> #2044: "Can't unify" error in debugger --------------------+------------------------------------------------------- Reporter: r6144 | Owner: mnislaih Type: bug | Status: assigned Priority: normal | Milestone: 6.8.3 Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | --------------------+------------------------------------------------------- Comment (by simonpj): I don't understand your debugger well enough to give you a coherent response. My guess is that `newBoxyTyVar` will get you past the current "cant unify", albeit perhaps present some other part of your debugger with a polymorphic type it didn't expect. I suggest you have a chat with Simon M and/or Bernie initially. Meanwhile this bug is only going to affect people using the more exotic GHC extensions, I think. Still, doing something less unfriendly than crashing would be a useful step forward, and you can probably do that regardless? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 16 05:23:13 2008 From: trac at galois.com (GHC) Date: Wed Apr 16 05:18:27 2008 Subject: [GHC] #2044: "Can't unify" error in debugger In-Reply-To: <044.9de84d1571c81bf2b4030ee1192776b2@localhost> References: <044.9de84d1571c81bf2b4030ee1192776b2@localhost> Message-ID: <053.6aff1201287b5a1860f95139572bb42e@localhost> #2044: "Can't unify" error in debugger --------------------+------------------------------------------------------- Reporter: r6144 | Owner: mnislaih Type: bug | Status: assigned Priority: normal | Milestone: 6.8.3 Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | --------------------+------------------------------------------------------- Comment (by mnislaih): I tried with boxy tyvars and that makes the trick almost. The problem now is in the side-effect free unification procedure living in types/Unify.hs (previously TcGadt.hs). It fails when asked, at some point later in the debugger, to unify the type of rsRandomArray with itself. I think I will simply switch to boxyUnify here too, and that should suffice to close this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 16 05:24:48 2008 From: trac at galois.com (GHC) Date: Wed Apr 16 05:20:00 2008 Subject: [GHC] #2044: "Can't unify" error in debugger In-Reply-To: <044.9de84d1571c81bf2b4030ee1192776b2@localhost> References: <044.9de84d1571c81bf2b4030ee1192776b2@localhost> Message-ID: <053.8d38d618d960b3b6a5cf894d9b7a3bec@localhost> #2044: "Can't unify" error in debugger --------------------+------------------------------------------------------- Reporter: r6144 | Owner: mnislaih Type: bug | Status: assigned Priority: normal | Milestone: 6.8.3 Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | --------------------+------------------------------------------------------- Comment (by mnislaih): Oops, I mean the type of `buildBuf` {{{ buildBuf :: ST s (forall s'. ST s' (STUArray s' Idx Double)) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 16 14:18:30 2008 From: trac at galois.com (GHC) Date: Wed Apr 16 14:13:50 2008 Subject: [GHC] #2218: ghci leaks memory on :reload etc In-Reply-To: <045.8a6d8f2645e2e281aaf28111fdc114b6@localhost> References: <045.8a6d8f2645e2e281aaf28111fdc114b6@localhost> Message-ID: <054.d30bd4d44757867b7998762531b71bb7@localhost> #2218: ghci leaks memory on :reload etc --------------------+------------------------------------------------------- Reporter: ganesh | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | --------------------+------------------------------------------------------- Changes (by simonmar): * difficulty: => Unknown Comment: Object code is not GC'd, but byte-code certainly should be. It's not impossible we have a space leak though. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 16 14:22:01 2008 From: trac at galois.com (GHC) Date: Wed Apr 16 14:17:15 2008 Subject: [GHC] #2220: Subprocesses do not close open FDs In-Reply-To: <045.c8c0847f8d8ff9265acf5e0d94c0a49c@localhost> References: <045.c8c0847f8d8ff9265acf5e0d94c0a49c@localhost> Message-ID: <054.d3acac080e45f513a38d895a2a085484@localhost> #2220: Subprocesses do not close open FDs ----------------------------+----------------------------------------------- Reporter: Baughn | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ----------------------------+----------------------------------------------- Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: See #1780, and the discussion on haskell-cafe that is linked from it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 16 14:22:14 2008 From: trac at galois.com (GHC) Date: Wed Apr 16 14:17:35 2008 Subject: [GHC] #1780: runInteractiveProcess broken with >2 processes on POSIX In-Reply-To: <044.d5b4cf5d496c65f6f766ac301f4fef42@localhost> References: <044.d5b4cf5d496c65f6f766ac301f4fef42@localhost> Message-ID: <053.4e1411d585311b9c2945468591007ade@localhost> #1780: runInteractiveProcess broken with >2 processes on POSIX -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: libraries/process | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | -------------------------------+-------------------------------------------- Comment (by simonmar): See also #2220. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 16 14:22:34 2008 From: trac at galois.com (GHC) Date: Wed Apr 16 14:17:46 2008 Subject: [GHC] #2220: Subprocesses do not close open FDs In-Reply-To: <045.c8c0847f8d8ff9265acf5e0d94c0a49c@localhost> References: <045.c8c0847f8d8ff9265acf5e0d94c0a49c@localhost> Message-ID: <054.396c3942c1ad6a2532c29de896bab0b9@localhost> #2220: Subprocesses do not close open FDs -------------------------------+-------------------------------------------- Reporter: Baughn | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/process | Version: 6.8.2 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -------------------------------+-------------------------------------------- Changes (by simonmar): * component: Runtime System => libraries/process -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 16 14:42:17 2008 From: trac at galois.com (GHC) Date: Wed Apr 16 14:37:41 2008 Subject: [GHC] #1780: runInteractiveProcess broken with >2 processes on POSIX In-Reply-To: <044.d5b4cf5d496c65f6f766ac301f4fef42@localhost> References: <044.d5b4cf5d496c65f6f766ac301f4fef42@localhost> Message-ID: <053.22dadd91a8cef0c5e46560fcea6c8b74@localhost> #1780: runInteractiveProcess broken with >2 processes on POSIX -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: libraries/process | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -------------------------------+-------------------------------------------- Changes (by Baughn): * cc: sveina@gmail.com (added) * os: Linux => Multiple * architecture: x86 => Multiple Comment: A C programmer would be able to close any/all FDs between forking and execing; here, with the two operations folded into one, *not* closing FDs by default becomes an unavoidable security hole as well as everything else. I'd argue that not closing them violates the principle of having security by default - anyone who cares about FDs will know to mark them as not- automatically-closed; anyone who doesn't will likely be very surprised when a subprocess uses one they left over to overwrite their database, even by accident. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 16 15:10:59 2008 From: trac at galois.com (GHC) Date: Wed Apr 16 15:06:15 2008 Subject: [GHC] #2218: ghci leaks memory on :reload etc In-Reply-To: <045.8a6d8f2645e2e281aaf28111fdc114b6@localhost> References: <045.8a6d8f2645e2e281aaf28111fdc114b6@localhost> Message-ID: <054.36f46dad387839d1c5f9667aba22fa46@localhost> #2218: ghci leaks memory on :reload etc --------------------+------------------------------------------------------- Reporter: ganesh | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | --------------------+------------------------------------------------------- Comment (by ganesh): OK, since the behaviour I described isn't known I'll provide proper reproduction instructions. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 16 15:46:28 2008 From: trac at galois.com (GHC) Date: Wed Apr 16 15:41:41 2008 Subject: [GHC] #2222: Template Haskell: reify returns incorrect types when ommiting type signatures In-Reply-To: <043.ad3979036d0a8d6334de105353abe0e3@localhost> References: <043.ad3979036d0a8d6334de105353abe0e3@localhost> Message-ID: <052.af51b7eb7405a92ef844dc373031ab10@localhost> #2222: Template Haskell: reify returns incorrect types when ommiting type signatures ------------------------------+--------------------------------------------- Reporter: fons | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 6.8.2 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Multiple | ------------------------------+--------------------------------------------- Changes (by simonpj): * difficulty: => Unknown Comment: OK, so there are several things going on here. 1. For `a`, you are hitting the Monomorphism Restriction. Since `a` is monomorphic, it gets type `t0`, where `t0` is a unification variable. Right at the very end of the module we might see `(f a)` where `f :: Int -> Int`, and then (but only then) we'd discover that `t0` is really `Int`. The difficulty is that reification (for local variables) can ask for the type of a variable before all the evidence is in. A much more direct examples would be {{{ \x. ... $( ...reify 'x'... ) ... }}} The type of `x` may not be determined by the time the splice runs. I can't see a way round this, except by making reification illegal for local variables, or perhaps for non-rigid ones, or something. 2. Although you wrote your definitions in order `b,c,d`, and they are not recursive, GHC is treating them as a mutually recursive group, and, as luck would have it, checks `d` first. So the reification inside `d` see's `c`'s type before `c`'s right hand side has been examined, and we are back in situation (1). Why are they treated as mutually recursive? Here's the comment from `RnSource`: {{{ Note [Splices] ~~~~~~~~~~~~~~ Consider f = ... h = ...$(thing "f")... The splice can expand into literally anything, so when we do dependency analysis we must assume that it might mention 'f'. So we simply treat all locally-defined names as mentioned by any splice. This is terribly brutal, but I don't see what else to do. For example, it'll mean that every locally-defined thing will appear to be used, so no unused- binding warnings. But if we miss the dependency, then we might typecheck 'h' before 'f', and that will crash the type checker because 'f' isn't in scope. Currently, I'm not treating a splice as also mentioning every import, which is a bit inconsistent -- but there are a lot of them. We might thereby get some bogus unused-import warnings, but we won't crash the type checker. Not very satisfactory really. }}} Remember that TH allows dynamic binding! Again, I don't see a good way around this either. You might say that you expect TH splices to be run top-to-bottom, but what if one at the bottom is used further up: {{{ f = ...g... ... h = $(bar 4) g = $(foo 3) }}} Now we have to run the splice for `g` before we can get a type for `g`; and we need a type for `g` before we can typecheck `f`. Anyway I hope that explains some of what is going on. The real issues here are ones of design, rather than bugs of implementation. Good design ideas would be very welcome -- the TH design is clearly warty in places. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 16 16:47:54 2008 From: trac at galois.com (GHC) Date: Wed Apr 16 16:43:04 2008 Subject: [GHC] #989: Windows "native" port In-Reply-To: <047.96e16f269cc7176052a090de33c91146@localhost> References: <047.96e16f269cc7176052a090de33c91146@localhost> Message-ID: <056.9d4931b396b6266c34801db11430591a@localhost> #989: Windows "native" port ----------------------+----------------------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: Severity: normal | Resolution: Keywords: | Difficulty: Difficult (1 week) Testcase: N/A | Architecture: x86 Os: Windows | ----------------------+----------------------------------------------------- Changes (by sharpe): * version: 6.7 => Comment: Win port of gmp at [http://fp.gladman.plus.com/computing/gmp4win.htm], perhaps move gmp out of dist altogether and only link w/ .so or .dll? Support utils (cgprof, hp2ps,.. etc.) need minor modifications to build and keep cl from choking on e.g. some exotic C macros (and simple ones such as macros suffixed with semi-colon). RTS is more challenging as it contains a mix of C89, C99, C++ code which gcc happily compiles; minor inconsistencies (STATIC_INLINE here, static inline there), gcc extensions not supported by cl, inline assembly, void pointer arithmetic etc. Adapting the build system is pretty terrible (esp. proper autoconf,libtool), custom make rules, custom config.h, custom mk files and some custom Makefile.win32 do the trick but are more difficult to maintain in the future (cmake?). Used winsock is deprecated, also i will need to look into signal handling as this doesn't behave properly (mingw?). Registered boot attempts fail with alignment errors, as of yet not resolved (->mix gcc/cl?); will continue on unregistered 6.4 series builds. Haven't got to real low-level stuff, YASM seems ok and is easily integrated w/ VS2008. prepping the environment is pretty easy once you've got around the unixy build system (include vcvars variables PATH,LIBPATH,INCLUDE etc.), btw utils/pwd does not work in mingw using series 6.8.2 (easily resolved). merging changes will be another fun item. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 16 17:10:48 2008 From: trac at galois.com (GHC) Date: Wed Apr 16 17:05:59 2008 Subject: [GHC] #989: Windows "native" port In-Reply-To: <047.96e16f269cc7176052a090de33c91146@localhost> References: <047.96e16f269cc7176052a090de33c91146@localhost> Message-ID: <056.6531102fcf95b0ed7472ec9a09dc5b16@localhost> #989: Windows "native" port ----------------------+----------------------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: Severity: normal | Resolution: Keywords: | Difficulty: Difficult (1 week) Testcase: N/A | Architecture: x86 Os: Windows | ----------------------+----------------------------------------------------- Changes (by NeilMitchell): * cc: ndmitchell@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 16 17:44:49 2008 From: trac at galois.com (GHC) Date: Wed Apr 16 17:40:02 2008 Subject: [GHC] #2223: Int64.toInteger Message-ID: <045.8abd8f650d1173426a900315be0a8333@localhost> #2223: Int64.toInteger -----------------------+---------------------------------------------------- Reporter: gnezdo | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 6.8.2 | Severity: major Keywords: | Testcase: Architecture: x86 | Os: Linux -----------------------+---------------------------------------------------- {{{ GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude> 0 == (-1 `Data.Bits.shift` 32 :: Data.Int.Int64) False Prelude> 0 == toInteger (-1 `Data.Bits.shift` 32 :: Data.Int.Int64) True -- ^^^ BUG }}} The problem appears to be in the recently changed rts/PrimOps.cmm::int64ToIntegerzh_fast: {{{ if ( hi != 0 && hi != 0xFFFFFFFF ) { words_needed = 2; } else { // minimum is one word words_needed = 1; } }}} So, 0xFFFFFFFF00000000 becomes 0. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 16 20:54:57 2008 From: trac at galois.com (GHC) Date: Wed Apr 16 20:50:07 2008 Subject: [GHC] #2224: -fhpc inteferes/prevents rewrite rules from firing Message-ID: <043.0a1d2cb80ab6ed909cbaaf8b919814c3@localhost> #2224: -fhpc inteferes/prevents rewrite rules from firing ---------------------------+------------------------------------------------ Reporter: dons | Owner: andy@galois.com Type: bug | Status: new Priority: normal | Component: Code Coverage Version: 6.8.2 | Severity: normal Keywords: rules, hpc | Testcase: Architecture: Unknown | Os: Unknown ---------------------------+------------------------------------------------ Use case: I'm writing tests for rewrite rules, and using HPC to determine if rules were fired (and their code exercised). HPC is quite cool here, since it lets us see which rules fired, without needing to explicitly export functions to test. However, -fhpc seems to prevent many rules from firing (likely due to ticks getting in the way?) For example: {{{ import qualified Data.ByteString.Char8 as C main = print (C.pack "literal") }}} When compiled normally, triggers a nice rewrite rule: {{{ $ ghc -O2 A.hs -ddump-simpl-stats A.hs -c 1 ByteString pack/packAddress }}} Now with -fhpc: {{{ 2 RuleFired 1 unpack 1 unpack-list }}} What's the best way to ensure the same code is exercised with and without -fhpc here? (I'd quite like to get this working, since rewrite rules benefit from testing.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 16 21:01:31 2008 From: trac at galois.com (GHC) Date: Wed Apr 16 20:56:41 2008 Subject: [GHC] #2213: -Wall incorrectly warns "Defined but not used" for functions exported via RULES In-Reply-To: <043.a16de73b756c546cfe361c8db1abcd3b@localhost> References: <043.a16de73b756c546cfe361c8db1abcd3b@localhost> Message-ID: <052.8d3003955baca9fc85eb31ca5ff17e4f@localhost> #2213: -Wall incorrectly warns "Defined but not used" for functions exported via RULES -------------------------+-------------------------------------------------- Reporter: dons | Owner: dons Type: bug | Status: assigned Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- Changes (by dons): * status: new => assigned * owner: => dons Comment: Ah, worked this one out. `-fglasgow-exts` is needed to enable rules, otherwise they're considered comments. (Hence the type error in this rule is silently ignored). Note however, strangely, `-frewrite-rules` *doesn't* fix this. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Apr 17 00:01:16 2008 From: trac at galois.com (GHC) Date: Wed Apr 16 23:56:26 2008 Subject: [GHC] #2225: hackage library encoding-0.4 crashes ghc 6.8.2 Message-ID: <044.e9d9476ef5821d5acc4a3c27e27ec664@localhost> #2225: hackage library encoding-0.4 crashes ghc 6.8.2 ------------------------+--------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- This is on i386 ubuntu gutsy. Output of "runghc Setup.hs build" is: {{{ encoding-0.4$ runghc Setup.hs build Preprocessing library encoding-0.4... Building encoding-0.4... [ 1 of 37] Compiling Data.Encoding.Helper.Template ( Data/Encoding/Helper/Template.hs, dist/build/Data/Enco\ ding/Helper/Template.o ) [ 2 of 37] Compiling Data.Encoding.GB18030Data ( Data/Encoding/GB18030Data.hs, dist/build/Data/Encoding/GB1\ 8030Data.o ) [ 3 of 37] Compiling Data.Encoding.Base ( Data/Encoding/Base.hs, dist/build/Data/Encoding/Base.o ) [ 4 of 37] Compiling Data.Encoding.GB18030 ( Data/Encoding/GB18030.hs, dist/build/Data/Encoding/GB18030.o ) [ 5 of 37] Compiling Data.Encoding.KOI8U ( Data/Encoding/KOI8U.hs, dist/build/Data/Encoding/KOI8U.o ) [ 6 of 37] Compiling Data.Encoding.KOI8R ( Data/Encoding/KOI8R.hs, dist/build/Data/Encoding/KOI8R.o ) [ 7 of 37] Compiling Data.Encoding.CP1258 ( Data/Encoding/CP1258.hs, dist/build/Data/Encoding/CP1258.o ) Loading package base ... linking ... done. Loading package pretty-1.0.0.0 ... linking ... done. Loading package array-0.1.0.0 ... linking ... done. Loading package packedstring-0.1.0.0 ... linking ... done. Loading package containers-0.1.0.1 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package bytestring-0.9.0.1 ... linking ... done. ghc-6.8.2: internal error: loadObj: can't map `dist/build/Data/Encoding/Helper/Template.o' (GHC version 6.8.2 for i386_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug encoding-0.4$ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Apr 17 01:38:49 2008 From: trac at galois.com (GHC) Date: Thu Apr 17 01:33:59 2008 Subject: [GHC] #2224: -fhpc inteferes/prevents rewrite rules from firing In-Reply-To: <043.0a1d2cb80ab6ed909cbaaf8b919814c3@localhost> References: <043.0a1d2cb80ab6ed909cbaaf8b919814c3@localhost> Message-ID: <052.1065fb8d0081e1a853fb855d7550a039@localhost> #2224: -fhpc inteferes/prevents rewrite rules from firing ------------------------------+--------------------------------------------- Reporter: dons | Owner: andy@galois.com Type: bug | Status: new Priority: normal | Milestone: Component: Code Coverage | Version: 6.8.2 Severity: normal | Resolution: Keywords: rules, hpc | Testcase: Architecture: Unknown | Os: Unknown ------------------------------+--------------------------------------------- Comment (by AndyGill): I'm not sure what to do here. To match code that contains ticks, and rewrite them requires either * removing ticks - generally a bad idea! * recreating the ticks, which is hard/impossible to do in some cases. I suppose we could have an option to ignore ticks in rules, but this leads to false positives. Also consider: {{{ {-# RULES "pack/packAddress" forall s . pack (unpackCString# s) = B.packAddress s #-} }}} pack and unpackCString are strict, so we have tick equivalence! {{{ tick<1>pack(tick<2>unpackCString# (tick<3> s)) }}} is the same as {{{ tick<1,2,3>pack(unpackCString# s) }}} The tick lifting has given us the original match. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Apr 17 03:59:54 2008 From: trac at galois.com (GHC) Date: Thu Apr 17 03:55:03 2008 Subject: [GHC] #2224: -fhpc inteferes/prevents rewrite rules from firing In-Reply-To: <043.0a1d2cb80ab6ed909cbaaf8b919814c3@localhost> References: <043.0a1d2cb80ab6ed909cbaaf8b919814c3@localhost> Message-ID: <052.dd4f2109fee5cb0e7e446e52f0a08da1@localhost> #2224: -fhpc inteferes/prevents rewrite rules from firing ---------------------------+------------------------------------------------ Reporter: dons | Owner: andy@galois.com Type: bug | Status: new Priority: normal | Milestone: Component: Code Coverage | Version: 6.8.2 Severity: normal | Resolution: Keywords: rules, hpc | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------------+------------------------------------------------ Changes (by simonpj): * difficulty: => Unknown Comment: In general, coverage testing is incompatible with optimisation, although it seems surprising (to me) robust: {{{ f x = g (h x) g x = x h x = x }}} then if we inline busily we'll get {{{ f x = x }}} and in fact this ''does'' happen, but none of the relevant ticks are lost. In effect, the optimiser knows how to commute stuff with ticks, because ticks get encoded as `case` expressions. There's a paper in here, actually, because the code does get shaken around quite a bit, despite the ticks littering it. (Mind you, we don't yet have an operational semantics to tell us what ticks ''should'' do, though that would not be hard to write. That too should be in the paper.) But this robustness breaks down for rewrite rules, because they inspect the structure of terms, and that's messed up by the ticks. For a composition of strict functions, matters are more straightforward, as Andy says, because all the ticks float to the outside. To take his example, if we have {{{ f x = ...(pack (unpack s))... }}} after tick decoration it'll look like {{{ f x = ...(tick (pack (tick (unpack s)))... }}} then the tick around the `(unpack s)` will float out (since `pack` is strict), so we'll end up with something like {{{ f x = ...(tick (tick (pack (unpack s)))... }}} So if we simply did not tick-ify the LHS of a rule you'd think the rule would work. And it seems to: try this with `-fhpc -O`. {{{ module Foo where f g x = g x {-# NOINLINE g #-} g x = x {-# NOINLINE h #-} h x = x foo y = f g (h y) {-# RULES "gh" forall x. g (h x) = g x #-} }}} (NB: The rule `gh` doesn't fire until after strictness analysis has told us that `g` is strict; and that late firing definitely could be a problem.) Conclusion: we aren't decorating RULES with ticks anyway, and that must be the Right Thing for the LHS of the rule. (We almost certainly ''should'' decorate their right-hand sides -- that's a bug.) The problem, I guess, comes with lazy functions, where the ticks don't float. And indeed, if `f` is lazy, so does not provably consume its argument, what would you ''like'' to happen for {{{ RULE "f" forall x. f (g x) = x }}} In an expression `...(f (tick (g x)))...`, what do you want to happen to the `` tick? Do you want to show `(g x)` as covered? Or not? The most plausible answer is, I think, that we'd like to show `(g x)` as covered, so we'd like to do the following rewrite {{{ ...(f (tick (g x)))... ==> ....(tick x).... }}} That is, the tick should not get in the way of matching, but should not be discarded either. Instead it should be saved up and wrapped around the result. Interesting. This is '''very like''' what happens for let-expressions. See Section 4.1 of the [http://research.microsoft.com/%7Esimonpj/papers /spec-constr/spec-constr.pdf call-pattern specialisation paper], and `Note [Matching lets]` in `specialise/Rules.lhs`. So I speculate that, if this is the semantics we want, we could adjust the rule matcher to ignore-but- accumulate ticks, just as it does lets. Andy if you want to pursue this, I can guide you to the right place. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Apr 17 04:23:39 2008 From: trac at galois.com (GHC) Date: Thu Apr 17 04:18:51 2008 Subject: [GHC] #1877: Change the meaning of -fextended-default-rules In-Reply-To: <047.a9d9acd5b305477a9660b9018aae5df1@localhost> References: <047.a9d9acd5b305477a9660b9018aae5df1@localhost> Message-ID: <056.6e69a2179e9bb746e0b5a6a7e9334eee@localhost> #1877: Change the meaning of -fextended-default-rules ----------------------+----------------------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by simonpj): I'm missing something. * If you put `-fextended-default-rules` (or a corresponding `-X` language flag) in a module, it should apply to that module. * If you `:set -fno-extended-default-rules` at the GHCi prompt, it should switch it off for GHCi. Ah, hmm, maybe I see. Say you `:set -fallow-overlapping-instances` at the GHCi prompt. That setting ''also'' applies when GHCi compiles a module, doesn't it? If you didn't want overlapping instances in the module there's no way to switch it off, short of putting `-fno-allow-overlapping- instances` in the module, which seems wrong. But in the case of extended-defaults, GHCi typically has it on, but we ''don't'' want to have it on by default for a module. That's a new situation. An ad-hoc solution would be to splat the flags with `-fno- extended-defaults` just before GHCi compiles a module. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Apr 17 11:18:55 2008 From: trac at galois.com (GHC) Date: Thu Apr 17 11:14:09 2008 Subject: [GHC] #2223: Int64.toInteger In-Reply-To: <045.8abd8f650d1173426a900315be0a8333@localhost> References: <045.8abd8f650d1173426a900315be0a8333@localhost> Message-ID: <054.a580e4d9a986a35cad2c56629b802fea@localhost> #2223: Int64.toInteger -------------------------------+-------------------------------------------- Reporter: gnezdo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.8.2 Severity: major | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Linux -------------------------------+-------------------------------------------- Changes (by gnezdo): * cc: wolfgang.thaller@gmx.net (added) Comment: A bit of source browsing indicates this could be the patch that introduced the code in question. {{{ Fri Nov 24 01:41:29 PST 2006 wolfgang.thaller@gmx.net * Support I64->I32 casts in the NCG, and use them for I64->Integer conversions We can avoid using any other long long operations in PrimOps.cmm. One more step towards compiling the RTS using the NCG. }}} Wolfgang, could you comment on the correctness of the proposed patch? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Apr 17 14:27:59 2008 From: trac at galois.com (GHC) Date: Thu Apr 17 14:23:10 2008 Subject: [GHC] #2224: -fhpc inteferes/prevents rewrite rules from firing In-Reply-To: <043.0a1d2cb80ab6ed909cbaaf8b919814c3@localhost> References: <043.0a1d2cb80ab6ed909cbaaf8b919814c3@localhost> Message-ID: <052.dc4a384b014480dd6abccc829ea15995@localhost> #2224: -fhpc inteferes/prevents rewrite rules from firing ---------------------------+------------------------------------------------ Reporter: dons | Owner: andy@galois.com Type: bug | Status: new Priority: normal | Milestone: Component: Code Coverage | Version: 6.8.2 Severity: normal | Resolution: Keywords: rules, hpc | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------------+------------------------------------------------ Comment (by simonmar): Replying to [comment:2 simonpj]: > In general, coverage testing is incompatible with optimisation, although it seems surprising (to me) robust: > {{{ > f x = g (h x) > g x = x > h x = x > }}} > then if we inline busily we'll get > {{{ > f x = x > }}} > and in fact this ''does'' happen, but none of the relevant ticks are lost. In effect, the optimiser knows how to commute stuff with ticks, because ticks get encoded as `case` expressions. There's a paper in here, actually, because the code does get shaken around quite a bit, despite the ticks littering it. (Mind you, we don't yet have an operational semantics to tell us what ticks ''should'' do, though that would not be hard to write. That too should be in the paper.) We said a little about this in the GHCi debugger paper, although I agree a formal treatment would be useful. You may remember the basic idea is that we tell the simplifier that the tick has side effects. The principle we want the simplifier to preserve is that the tick in `case tick of _ -> e` should be evaluated ''if and only if e would be evaluated by the standard lazy operational semantics''. We don't care about ordering: the simplifier can re-order two ticks, as long as it can be sure that both expressions would have been evaluated according to the semantics. (in the debugger you'll see the effect of reordering, but HPC doesn't care). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 18 08:35:28 2008 From: trac at galois.com (GHC) Date: Fri Apr 18 08:30:35 2008 Subject: [GHC] #1346: bootstrap from HC files In-Reply-To: <047.353746f1d61af31dcc9643e79add3cec@localhost> References: <047.353746f1d61af31dcc9643e79add3cec@localhost> Message-ID: <056.12cc6959d803b285d96a72017819a51f@localhost> #1346: bootstrap from HC files --------------------------+------------------------------------------------- Reporter: simonmar | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Build System | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Architecture: Unknown Os: Unknown | --------------------------+------------------------------------------------- Changes (by dwmw2): * cc: dwmw2@infradead.org (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 18 12:56:35 2008 From: trac at galois.com (GHC) Date: Fri Apr 18 12:51:40 2008 Subject: [GHC] #2006: unreachable GADT pattern clauses show up as warnings with -Wall In-Reply-To: <044.a004885c928a62e2a73bf12df457c462@localhost> References: <044.a004885c928a62e2a73bf12df457c462@localhost> Message-ID: <053.b489dcfd5ba17dd4054ac77400fe5ba8@localhost> #2006: unreachable GADT pattern clauses show up as warnings with -Wall ----------------------+----------------------------------------------------- Reporter: ryani | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by mnislaih): * cc: mnislaih@gmail.com (added) Comment: I am being annoyed by this too. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 18 19:31:39 2008 From: trac at galois.com (GHC) Date: Fri Apr 18 19:26:44 2008 Subject: [GHC] #1964: GHC.Prim In-Reply-To: <044.9207dad19026729963694adf6b204b9d@localhost> References: <044.9207dad19026729963694adf6b204b9d@localhost> Message-ID: <053.f39ae3f77903a9059b59634d45625ede@localhost> #1964: GHC.Prim ----------------------+----------------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by igloo): We do have a `ghc-prim` package, but it isn't magic (i.e. the compiler doesn't treat it specially). The magic is still for the `GHC.Prim` module (which now lives in the `ghc-prim` package). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 18 19:48:37 2008 From: trac at galois.com (GHC) Date: Fri Apr 18 19:43:55 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.4ba382d2692664500d52982f506bfec7@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.8.3 Component: Compiler | Version: 6.8.2 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by fons): * cc: alfonso.acosta@gmail.com (added) * version: 6.8.1 => 6.8.2 * component: GHCi => Compiler * severity: normal => major * summary: unconditional relative branch out of range (GHC version 6.8.1 for powerpc_apple_darwin) => unconditional relative branch out of range (GHC version 6.8.1/6.8.2 for powerpc_apple_darwin) Comment: I'm suffering exactly the same problem with ghc 6.8.2 in Leopard/ppcG4. I can reproduce the bug both with macports ghc and http://www.informatik .uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/mac/ghcs/ghc-6.8.2 -powerpc-apple-darwin-static-libs.tar.bz2 Furthermore, the problem is not limited to interactive mode. Compilation fails for this cabal package http://hackage.haskell.org/cgi-bin/hackage- scripts/package/type-level-0.1 Removing the genAliases splice from Data.TypeLevel.Num.Aliases fixes the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 18 19:57:40 2008 From: trac at galois.com (GHC) Date: Fri Apr 18 19:52:45 2008 Subject: [GHC] #2214: trac wishes: "performance feature request" ticket type, "trac" component In-Reply-To: <043.156bdc7118ceb84356b82cee2d61b60c@localhost> References: <043.156bdc7118ceb84356b82cee2d61b60c@localhost> Message-ID: <052.cd4909c5bab38955a20f19dffeee1e96@localhost> #2214: trac wishes: "performance feature request" ticket type, "trac" component ----------------------+----------------------------------------------------- Reporter: SamB | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: I'm not sure that performance bug vs performance feature request is a useful distinction to make. If you disagree, please reopen and give an example of what a performance feature request might be. I also don't think it is worth adding a `trac` component; we already have a `None` component that could be used for this. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 18 20:09:59 2008 From: trac at galois.com (GHC) Date: Fri Apr 18 20:05:08 2008 Subject: [GHC] #2211: Installing latest GHC-6.8.2 stable: pwd with floating point exception In-Reply-To: <044.6fa473611ed5d150325a47086f85da68@localhost> References: <044.6fa473611ed5d150325a47086f85da68@localhost> Message-ID: <053.22ccb321aac45434c0d8b397935223ad@localhost> #2211: Installing latest GHC-6.8.2 stable: pwd with floating point exception ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: Thanks for the report. However, this is caused by your system libraries (libc?) being too old for the binaries. The binary works for me. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 18 20:19:43 2008 From: trac at galois.com (GHC) Date: Fri Apr 18 20:14:47 2008 Subject: [GHC] #2097: bug in regEnumKeys (System.Win32.Registry) In-Reply-To: <053.154a24ca3b071941575751aaf8747feb@localhost> References: <053.154a24ca3b071941575751aaf8747feb@localhost> Message-ID: <062.2f506a9f400ede7cdf1da5d0f3dc764c@localhost> #2097: bug in regEnumKeys (System.Win32.Registry) -------------------------------+-------------------------------------------- Reporter: MagnusTherning | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.8.3 Component: libraries (other) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Windows | -------------------------------+-------------------------------------------- Comment (by igloo): Replying to [comment:6 MagnusTherning]: > Replying to [comment:5 igloo]: > > Fixed: > > {{{ > > Sun Apr 6 21:50:51 BST 2008 Ian Lynagh > > * malloc a big enough buffer for the registry functions. Fixes trac #2097. > > We were mallocing a byte per tchar, but tchars are normally 2 bytes big... > > I think they are at most 4 bytes, so we now malloc 4 * #tchars. Not sure > > if there is a proper function I should be using for this? > > }}} > > One way to be sure is to switch to using wide characters explicitly, i.e. to use RegOpenKeyExW rather than RegOpenKeyEx. We are using wide characters explicitly (`RegEnumKeyW`); the question is how large a buffer to pass as the third argument. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 18 20:19:57 2008 From: trac at galois.com (GHC) Date: Fri Apr 18 20:15:09 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.af3e466108187e6dc89a8fb91c1c1b06@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.8.3 Component: Compiler | Version: 6.8.2 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | ----------------------+----------------------------------------------------- Comment (by fons): Replying to [comment:9 fons]: > Removing the genAliases splice from Data.TypeLevel.Num.Aliases fixes the problem. The problem can also be fixed by removing the unnnecesary ghc package dependency from the cabal description (its intention is to make clear to other compilers that the code was ghc-dependent) This makes more sense. However, other cabal packages with the ghc dependency can be compiled without problems (e.g. http://hackage.haskell.org/cgi-bin/hackage- scripts/package/parameterized-data-0.1 ) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Apr 19 05:43:15 2008 From: trac at galois.com (GHC) Date: Sat Apr 19 05:38:17 2008 Subject: [GHC] #2097: bug in regEnumKeys (System.Win32.Registry) In-Reply-To: <053.154a24ca3b071941575751aaf8747feb@localhost> References: <053.154a24ca3b071941575751aaf8747feb@localhost> Message-ID: <062.f554c67137df2915c7a2f0a261b25cb8@localhost> #2097: bug in regEnumKeys (System.Win32.Registry) -------------------------------+-------------------------------------------- Reporter: MagnusTherning | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.8.3 Component: libraries (other) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Windows | -------------------------------+-------------------------------------------- Comment (by MagnusTherning): Replying to [comment:7 igloo]: > > We are using wide characters explicitly (`RegEnumKeyW`); the question is how large a buffer to pass as the third argument. All right, maybe I should have been a bit more clear :-) AFAIK the use of `TCHAR` is something that allows the programmer to switch between Unicode (in Windows parlance) and ASCII at compile time. If the "W functions" are used explicitly I think it'd be better to also use `wchar_t` explicitly rather than hide them behind `TCHAR`s. According to Wikipedia "unicode" means UTF-16 on Windows, so allowing up to 4 bytes per character will be enough, though likely a bit wasteful. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Apr 19 23:17:07 2008 From: trac at galois.com (GHC) Date: Sat Apr 19 23:12:09 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.493db0a1d2833203750ab4bcc6af2bb1@localhost> #2142: :b doesn't invoke :browse, or even generate an ambiguous command error ----------------------+----------------------------------------------------- Reporter: SamB | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by SamB): From #haskell, Sat Apr 19 22:47-23:10 {{{ SamB: I much prefer it meaning :browse }}} {{{ * scook0 still has 6.6 installed, and therefore doesn't feel qualified to offer an opinion :) }}} {{{ I never use the debugger. But then, I never use :browse, either. }}} {{{ I'd prefer :browse. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Apr 20 11:31:23 2008 From: trac at galois.com (GHC) Date: Sun Apr 20 11:26:23 2008 Subject: [GHC] #1346: bootstrap from HC files In-Reply-To: <047.353746f1d61af31dcc9643e79add3cec@localhost> References: <047.353746f1d61af31dcc9643e79add3cec@localhost> Message-ID: <056.80ef7cbbefa34f6e12d282945305f198@localhost> #1346: bootstrap from HC files --------------------------+------------------------------------------------- Reporter: simonmar | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Build System | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Architecture: Unknown Os: Unknown | --------------------------+------------------------------------------------- Comment (by kili): The diff I uploaded contains some comments inline. It's for ghc-6.8.2 but also applies to the latest stable snapshot (ghc-6.8.2.20080401). As written earlier, it's possible to create a HC file bundle (with some additional created files) and to build a stage1 compiler with this. I'm a little bit uncertain how to proceed -- either go ahead using libcompat (which is a little bit ugly), or try to rebuild all the libraries immediately with that stage1 compiler (but without using utils/ghc-pkg, since it's not yet buildable), then build the remaining tools. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Apr 21 06:48:05 2008 From: trac at galois.com (GHC) Date: Mon Apr 21 06:43:00 2008 Subject: [GHC] #601: Replace GMP In-Reply-To: <047.118762464fe3464def09b9461b8cccc5@localhost> References: <047.118762464fe3464def09b9461b8cccc5@localhost> Message-ID: <056.2e8dedfe4d8629a9153be1b11f07900a@localhost> #601: Replace GMP ----------------------+----------------------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: None Severity: normal | Resolution: None Keywords: | Difficulty: Difficult (1 week) Testcase: N/A | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by igloo): http://darcs.haskell.org/libraries/integer-ultra-simple/ is a very simple (and inefficient) pure Haskell implementation. It validates, except `print003` and `print006` give different output (probably OK, due to different `Integer` representations) and `simplrun004(optc)` needs more stack space. This is not a reasonable replacement for Integer, although it's close to something that might be. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Apr 21 10:52:59 2008 From: trac at galois.com (GHC) Date: Mon Apr 21 10:47:54 2008 Subject: [GHC] #2226: duplicate samples in heap profiling (-hc) output on 6.8.2 Message-ID: <046.1e179a2ccae41d3a00bbbbb417b91596@localhost> #2226: duplicate samples in heap profiling (-hc) output on 6.8.2 -------------------------------+-------------------------------------------- Reporter: clemens | Owner: Type: bug | Status: new Priority: normal | Component: Profiling Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Unknown -------------------------------+-------------------------------------------- I tried to catch a bug in xmonad by using heap profiling (-hc). Compiled all libraries with -prof -auto-all. The .hp output seems broken as samples are written to the file multiple times. See attached example of xmonad. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Apr 21 17:05:13 2008 From: trac at galois.com (GHC) Date: Mon Apr 21 17:00:07 2008 Subject: [GHC] #2227: (fgl) reimplement Data.Graph.Inductive.Query.Dominators Message-ID: <044.d93b0278ed43cd6406c691042576f145@localhost> #2227: (fgl) reimplement Data.Graph.Inductive.Query.Dominators -------------------------+-------------------------------------------------- Reporter: int-e | Owner: Type: proposal | Status: new Priority: normal | Component: libraries (other) Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: Multiple | Os: Multiple -------------------------+-------------------------------------------------- As pointed out at http://www.haskell.org/pipermail/haskell- cafe/2008-April/041739.html ff., {{{Data.Graph.Inductive.Query.Dominators.dom}}} is buggy. Furthermore, it's slow, so instead of submitting the quick fix from that thread, I've rewritten the module from scratch using a more efficient algorithm. The algorithm works by calculating the immediate dominators of the graph nodes first, so the patch also adds a function that returns those. It should be handy for flow graph analysis. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Apr 21 20:05:26 2008 From: trac at galois.com (GHC) Date: Mon Apr 21 20:00:20 2008 Subject: [GHC] #2228: runghc screws up terminal buffering mode and doesn't reset it Message-ID: <044.5a9b5cb0e6f9fbb1f5c64639b7a5180d@localhost> #2228: runghc screws up terminal buffering mode and doesn't reset it -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.8.2 | Severity: major Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Linux -------------------------------+-------------------------------------------- If I use runghc to run a Haskell script that reads from stdin, my terminal gets put into a strange buffering mode. This makes the script essentially unusable: characters are echoed twice, and Backspace and EOF don't work. The state is not even reset afterwards, so future non-Haskell programs act strangely as well. {{{ $ cat cat.hs main = putStr =<< getContents $ stty speed 38400 baud; line = 0; eol = M-^?; eol2 = M-^?; swtch = M-^?; iutf8 $ runghc cat.hs hheelllloo ^D^?^D^D^C cat.hs: exception :: GhcException $ stty speed 38400 baud; line = 0; eol = M-^?; eol2 = M-^?; swtch = M-^?; min = 1; time = 0; iutf8 -icanon }}} There is no problem if the script is compiled with ghc instead of interpreted with runghc. I'm using ghc 6.8.2-2ubuntu1 on hardy amd64. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Apr 21 20:12:56 2008 From: trac at galois.com (GHC) Date: Mon Apr 21 20:07:50 2008 Subject: [GHC] #2227: (fgl) reimplement Data.Graph.Inductive.Query.Dominators In-Reply-To: <044.d93b0278ed43cd6406c691042576f145@localhost> References: <044.d93b0278ed43cd6406c691042576f145@localhost> Message-ID: <053.0492ed648ede55e4b11d9f606ccf892a@localhost> #2227: (fgl) reimplement Data.Graph.Inductive.Query.Dominators ----------------------------------+----------------------------------------- Reporter: int-e | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 6.9 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Multiple | Os: Multiple ----------------------------------+----------------------------------------- Comment (by int-e): FGL is not a core package (but an extra package shipped with ghc), so the library submission guidelines don't apply. As per Don Stewart's suggestion on libraries@haskell.org I've contacted Martin Erwig about this. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Apr 21 23:45:49 2008 From: trac at galois.com (GHC) Date: Mon Apr 21 23:40:42 2008 Subject: [GHC] #2229: ghc crashes on trying to build encoding module Message-ID: <044.59be979a984add956a2884258740e486@localhost> #2229: ghc crashes on trying to build encoding module ------------------------+--------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- It gets this far: Building encoding-0.4... [ 7 of 37] Compiling Data.Encoding.CP1258 ( Data/Encoding/CP1258.hs, dist/build/Data/Encoding/CP1258.o ) Loading package base ... linking ... done. Loading package pretty-1.0.0.0 ... linking ... done. Loading package array-0.1.0.0 ... linking ... done. Loading package packedstring-0.1.0.0 ... linking ... done. Loading package containers-0.1.0.1 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package bytestring-0.9.0.1 ... linking ... done. ghc-6.8.2: internal error: loadObj: can't map `dist/build/Data/Encoding/Helper/Template.o' (GHC version 6.8.2 for i386_unknown_linux) 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 Apr 21 23:50:19 2008 From: trac at galois.com (GHC) Date: Mon Apr 21 23:45:13 2008 Subject: [GHC] #2229: ghc crashes on trying to build encoding module In-Reply-To: <044.59be979a984add956a2884258740e486@localhost> References: <044.59be979a984add956a2884258740e486@localhost> Message-ID: <053.1109118a6b6bb3eace7140f8b498c739@localhost> #2229: ghc crashes on trying to build encoding module -------------------------+-------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: duplicate Keywords: | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- Changes (by ajd): * status: new => closed * resolution: => duplicate Comment: Duplicate of #2225. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Apr 22 04:44:59 2008 From: trac at galois.com (GHC) Date: Tue Apr 22 04:39:59 2008 Subject: [GHC] #2044: "Can't unify" error in debugger In-Reply-To: <044.9de84d1571c81bf2b4030ee1192776b2@localhost> References: <044.9de84d1571c81bf2b4030ee1192776b2@localhost> Message-ID: <053.ecb48bd1e0579168ce98101315114ba8@localhost> #2044: "Can't unify" error in debugger --------------------+------------------------------------------------------- Reporter: r6144 | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.8.3 Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | --------------------+------------------------------------------------------- Changes (by mnislaih): * status: assigned => new * owner: mnislaih => igloo * type: bug => merge * cc: igloo@earth.li (added) Comment: Fixed, merge to stable {{{ Mon Apr 21 10:13:22 PDT 2008 pepe * Fix #2044 (:printing impredicatively typed things) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Apr 22 05:36:49 2008 From: trac at galois.com (GHC) Date: Tue Apr 22 05:31:43 2008 Subject: [GHC] #2230: ghci crashes with .o mismatches Message-ID: <044.be341cfd46c6613b9f91a7d73d3966e2@localhost> #2230: ghci crashes with .o mismatches ------------------------+--------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- Basic recipe is: 1) have multi-file program, compile with ghc --make (this creates some .o files in course of compilation) 2) edit some files and then run ghci and attempt to load main file with :l file.hs 3) ghci tries to load some of the compiled .o files, and crashes. Workaround is to delete the .o's before running ghci. Loading package binary-0.4.2 ... linking ... done. : internal error: loadObj: can't map `Records.o' (GHC version 6.8.2 for i386_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Apr 22 14:01:26 2008 From: trac at galois.com (GHC) Date: Tue Apr 22 13:56:34 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.074ebdcaf924385ae8bad7b2c8c35f76@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.8.3 Component: Compiler | Version: 6.8.2 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | ----------------------+----------------------------------------------------- Comment (by thorkilnaur): Thanks a lot for this information. In addition, the problem occurs for test case {{{ghci024(ghci)}}} as well, both HEAD and STABLE, for the tnaur PPC OSX builders which are Mac OS X 10.4 (Tiger). Best regards Thorkil -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Apr 22 14:25:05 2008 From: trac at galois.com (GHC) Date: Tue Apr 22 14:19:57 2008 Subject: [GHC] #2231: GHC RTS Segfault Message-ID: <044.d4bb1e8e3d1948707d5b62e9fdca3bb9@localhost> #2231: GHC RTS Segfault -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Linux -------------------------------+-------------------------------------------- As discussed this afternoon on #ghc. From the attached tarball, unpack, cd sessions2, ghci Control/Concurrent/Session/Queens.hs, main What should happen is that it prints "False". However, for me it consistently segfaults. GDB reveals things like: {{{ *Control.Concurrent.Session.Queens> main Loading package mtl-1.1.0.0 ... linking ... done. Loading package array-0.1.0.0 ... linking ... done. Loading package containers-0.1.0.1 ... linking ... done. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x41001950 (LWP 26393)] 0x00002b76022eae6b in memcpy () from /lib/libc.so.6 (gdb) bt #0 0x00002b76022eae6b in memcpy () from /lib/libc.so.6 #1 0x000000000167f7b9 in schedule (initialCapability=, task=0x1b9d100) at Schedule.c:2847 #2 0x000000000167f94f in workerStart (task=0x1b9d100) at Schedule.c:2528 #3 0x00002b760205e017 in start_thread () from /lib/libpthread.so.0 #4 0x00002b76023385bd in clone () from /lib/libc.so.6 #5 0x0000000000000000 in ?? () }}} For some people, the first time you run main, it doesn't segfault but also doesn't print anything. Then the second time you run main, it will segfault then. Compiling with ghc does result in the right (non-segfaulting) behaviour, both with -threaded and without. For me, this is with 6.8.2, but Igloo confirmed that it segfaults HEAD too. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Apr 22 14:26:51 2008 From: trac at galois.com (GHC) Date: Tue Apr 22 14:21:44 2008 Subject: [GHC] #2231: GHC RTS Segfault In-Reply-To: <044.d4bb1e8e3d1948707d5b62e9fdca3bb9@localhost> References: <044.d4bb1e8e3d1948707d5b62e9fdca3bb9@localhost> Message-ID: <053.e8ebe4d3553c1f246210224e80a172c3@localhost> #2231: GHC RTS Segfault -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Linux -------------------------------+-------------------------------------------- Changes (by guest): * cc: Matthew, Sackman, (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Apr 22 14:28:46 2008 From: trac at galois.com (GHC) Date: Tue Apr 22 14:23:37 2008 Subject: [GHC] #2231: GHC RTS Segfault In-Reply-To: <044.d4bb1e8e3d1948707d5b62e9fdca3bb9@localhost> References: <044.d4bb1e8e3d1948707d5b62e9fdca3bb9@localhost> Message-ID: <053.bdc75517b0c1a0e1b0e87eaeeb97d608@localhost> #2231: GHC RTS Segfault -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Linux -------------------------------+-------------------------------------------- Comment (by guest): I think the most important line out of this afternoon's #ghc discussion is: 05:43PM OK, tso->why_blocked is 56139, so it's definitely caused by corruption from somewhere -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Apr 22 18:10:37 2008 From: trac at galois.com (GHC) Date: Tue Apr 22 18:05:30 2008 Subject: [GHC] #2232: Overhaul System.Process Message-ID: <047.3d68f1557285e41c09bc2624d93ec3e1@localhost> #2232: Overhaul System.Process ----------------------------------+----------------------------------------- Reporter: simonmar | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/process | Version: 6.8.2 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown ----------------------------------+----------------------------------------- == Overhaul of System.Process == From the patch: {{{ Tue Apr 22 15:02:16 PDT 2008 Simon Marlow * Overhall System.Process - fix #1780: pipes created by runInteractiveProcess are set close-on-exec by default - add a new, more general, form of process creation: createProcess Each of stdin, stdout and stderr may individually be taken from existing Handles or attached to new pipes. Also it has a nicer API. - add readProcess from Don Stewart's newpopen package. This function behaves like C's popen(). - Move System.Cmd.{system,rawSystem} into System.Process. Later we can depecate System.Cmd. - Don't use O_NONBLOCK for pipes, as it can confuse the process attached to the pipe (requires a fix to GHC.Handle in the base package). - move the tests from the GHC testsuite into the package itself, and add a couple more - bump the version to 2.0 }}} Haddock for the new API is here: [http://darcs.haskell.org/~simonmar/process/System-Process.html] Patch is attached. So far I've only modified the Unix parts of the code, the Windows parts still need to be updated. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Apr 22 18:12:49 2008 From: trac at galois.com (GHC) Date: Tue Apr 22 18:07:42 2008 Subject: [GHC] #2233: Overhaul System.Process Message-ID: <047.24a366415ff9b59c03e5bf49850898a6@localhost> #2233: Overhaul System.Process ----------------------------------+----------------------------------------- Reporter: simonmar | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/process | Version: 6.8.2 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown ----------------------------------+----------------------------------------- == Overhaul of System.Process == From the patch: {{{ Tue Apr 22 15:02:16 PDT 2008 Simon Marlow * Overhall System.Process - fix #1780: pipes created by runInteractiveProcess are set close-on-exec by default - add a new, more general, form of process creation: createProcess Each of stdin, stdout and stderr may individually be taken from existing Handles or attached to new pipes. Also it has a nicer API. - add readProcess from Don Stewart's newpopen package. This function behaves like C's popen(). - Move System.Cmd.{system,rawSystem} into System.Process. Later we can depecate System.Cmd. - Don't use O_NONBLOCK for pipes, as it can confuse the process attached to the pipe (requires a fix to GHC.Handle in the base package). - move the tests from the GHC testsuite into the package itself, and add a couple more - bump the version to 2.0 }}} Haddock for the new API is here: [http://darcs.haskell.org/~simonmar/process/System-Process.html] Patch is attached. So far I've only modified the Unix parts of the code, the Windows parts still need to be updated. Discussion period: 4 weeks (20 May) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 23 06:40:24 2008 From: trac at galois.com (GHC) Date: Wed Apr 23 06:35:15 2008 Subject: [GHC] #2231: GHC RTS Segfault In-Reply-To: <044.d4bb1e8e3d1948707d5b62e9fdca3bb9@localhost> References: <044.d4bb1e8e3d1948707d5b62e9fdca3bb9@localhost> Message-ID: <053.f104f29a2dfe57187e26c38291c3ff80@localhost> #2231: GHC RTS Segfault -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Linux -------------------------------+-------------------------------------------- Comment (by guest): from ghc 6.8.2 with -DDEBUG {{{ *Control.Concurrent.Session.Queens> main Loading package mtl-1.1.0.0 ... linking ... done. Loading package array-0.1.0.0 ... linking ... done. Loading package containers-0.1.0.1 ... linking ... done. : internal error: ASSERTION FAILED: file RaiseAsync.c, line 551 (GHC version 6.8.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Program received signal SIGABRT, Aborted. [Switching to Thread 0x41001950 (LWP 9533)] 0x00002b1b9b4e31d5 in raise () from /lib/libc.so.6 (gdb) bt #0 0x00002b1b9b4e31d5 in raise () from /lib/libc.so.6 #1 0x00002b1b9b4e4680 in abort () from /lib/libc.so.6 #2 0x0000000001684308 in rtsFatalInternalErrorFn (s=0x179d658 "ASSERTION FAILED: file %s, line %u\n", ap=0x41000bb0) at RtsMessages.c:164 #3 0x0000000001683ecc in barf (s=0x179d658 "ASSERTION FAILED: file %s, line %u\n") at RtsMessages.c:40 #4 0x0000000001683f26 in _assertFail (filename=0x17ab104 "RaiseAsync.c", linenum=551) at RtsMessages.c:55 #5 0x00000000016afd7e in performBlockedException (cap=0x1ba6120, source=0x2b1b9be8ac58, target=0x2b1b9b889000) at RaiseAsync.c:551 #6 0x00000000016afc77 in maybePerformBlockedException (cap=0x1ba6120, tso=0x2b1b9b889000) at RaiseAsync.c:526 #7 0x000000000168e88d in threadPaused (cap=0x1ba6120, tso=0x2b1b9b889000) at ThreadPaused.c:195 #8 0x000000000167b3d7 in interpretBCO (cap=0x1ba6120) at Interpreter.c:741 #9 0x00000000016878c7 in schedule (initialCapability=0x1ba6120, task=0x1bc3400) at Schedule.c:628 #10 0x0000000001689901 in workerStart (task=0x1bc3400) at Schedule.c:2528 #11 0x00002b1b9b29d017 in start_thread () from /lib/libpthread.so.0 #12 0x00002b1b9b5775bd in clone () from /lib/libc.so.6 #13 0x0000000000000000 in ?? () }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 23 08:11:31 2008 From: trac at galois.com (GHC) Date: Wed Apr 23 08:06:27 2008 Subject: [GHC] #2192: occasional segmentation faults when using Control.Parallel In-Reply-To: <044.41e146963f3d21c260430274434fb250@localhost> References: <044.41e146963f3d21c260430274434fb250@localhost> Message-ID: <053.35b1d34ec0a9db9b8eac2f9928b17021@localhost> #2192: occasional segmentation faults when using Control.Parallel ----------------------------+----------------------------------------------- Reporter: ivant | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.8.3 Component: Runtime System | Version: 6.8.2 Severity: major | Resolution: fixed Keywords: par | 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 Apr 23 08:16:32 2008 From: trac at galois.com (GHC) Date: Wed Apr 23 08:11:25 2008 Subject: [GHC] #2097: bug in regEnumKeys (System.Win32.Registry) In-Reply-To: <053.154a24ca3b071941575751aaf8747feb@localhost> References: <053.154a24ca3b071941575751aaf8747feb@localhost> Message-ID: <062.57d47b2031218c311853bfd5a78f5829@localhost> #2097: bug in regEnumKeys (System.Win32.Registry) -------------------------------+-------------------------------------------- Reporter: MagnusTherning | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.8.3 Component: libraries (other) | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Windows | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: I've merged the patch now, and I'm pretty sure it's safe, if not optimal, so I'm closing the ticket. Patches to improve it are of course welcomed! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 23 08:22:43 2008 From: trac at galois.com (GHC) Date: Wed Apr 23 08:17:34 2008 Subject: [GHC] #2231: GHC RTS Segfault In-Reply-To: <044.d4bb1e8e3d1948707d5b62e9fdca3bb9@localhost> References: <044.d4bb1e8e3d1948707d5b62e9fdca3bb9@localhost> Message-ID: <053.8b6f8db7ac48f038a1962e97e163fabe@localhost> #2231: GHC RTS Segfault -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Linux -------------------------------+-------------------------------------------- Changes (by guest): * cc: Matthew, Sackman (removed) * cc: "Matthew, Sackman" (added) Comment: And now with +RTS -DS -C0 -V0: {{{ Starting program: /usr/local/lib/ghc-6.8.2/ghc-6.8.2 -B/usr/local/lib/ghc-6.8.2 --interactive +RTS -DS -C0 -V0 -RTS Control/Concurrent/Session/Queens.hs [Thread debugging using libthread_db enabled] [New Thread 0x2b5545f39490 (LWP 11372)] [New Thread 0x40800950 (LWP 11375)] [New Thread 0x41001950 (LWP 11376)] GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Warning: Freeing non-allocated memory at 0x1ba9850 Warning: Freeing non-allocated memory at 0x1ba7820 Loading package base ... linking ... done. [ 1 of 12] Compiling Control.Concurrent.Session.Bool ( Control/Concurrent/Session/Bool.hs, interpreted ) [ 2 of 12] Compiling Control.Concurrent.Session.Number ( Control/Concurrent/Session/Number.hs, interpreted ) [ 3 of 12] Compiling Control.Concurrent.Session.List ( Control/Concurrent/Session/List.hs, interpreted ) [ 4 of 12] Compiling Control.Concurrent.Session.Map ( Control/Concurrent/Session/Map.hs, interpreted ) [ 5 of 12] Compiling Control.Concurrent.Session.SessionType ( Control/Concurrent/Session/SessionType.hs, interpreted ) [ 6 of 12] Compiling Control.Concurrent.Session.SMonad ( Control/Concurrent/Session/SMonad.hs, interpreted ) [ 7 of 12] Compiling Control.Concurrent.Session.Runtime ( Control/Concurrent/Session/Runtime.hs, interpreted ) [ 8 of 12] Compiling Control.Concurrent.Session.Pid ( Control/Concurrent/Session/Pid.hs, interpreted ) [ 9 of 12] Compiling Control.Concurrent.Session.Interleaving ( Control/Concurrent/Session/Interleaving.hs, interpreted ) [10 of 12] Compiling Control.Concurrent.Session.SessionTypeMonad ( Control/Concurrent/Session/SessionTypeMonad.hs, interpreted ) [11 of 12] Compiling Control.Concurrent.Session ( Control/Concurrent/Session.hs, interpreted ) [12 of 12] Compiling Control.Concurrent.Session.Queens ( Control/Concurrent/Session/Queens.hs, interpreted ) Ok, modules loaded: Control.Concurrent.Session, Control.Concurrent.Session.SessionTypeMonad, Control.Concurrent.Session.Queens, Control.Concurrent.Session.SMonad, Control.Concurrent.Session.SessionType, Control.Concurrent.Session.Number, Control.Concurrent.Session.Bool, Control.Concurrent.Session.List, Control.Concurrent.Session.Interleaving, Control.Concurrent.Session.Pid, Control.Concurrent.Session.Runtime, Control.Concurrent.Session.Map. *Control.Concurrent.Session.Queens> main Loading package mtl-1.1.0.0 ... linking ... done. Loading package array-0.1.0.0 ... linking ... done. Loading package containers-0.1.0.1 ... linking ... done. : internal error: ASSERTION FAILED: file Schedule.c, line 674 (GHC version 6.8.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Program received signal SIGABRT, Aborted. [Switching to Thread 0x41001950 (LWP 11376)] 0x00002b5545c211d5 in raise () from /lib/libc.so.6 (gdb) bt #0 0x00002b5545c211d5 in raise () from /lib/libc.so.6 #1 0x00002b5545c22680 in abort () from /lib/libc.so.6 #2 0x0000000001684308 in rtsFatalInternalErrorFn (s=0x179d658 "ASSERTION FAILED: file %s, line %u\n", ap=0x41000fa0) at RtsMessages.c:164 #3 0x0000000001683ecc in barf (s=0x179d658 "ASSERTION FAILED: file %s, line %u\n") at RtsMessages.c:40 #4 0x0000000001683f26 in _assertFail (filename=0x179df4b "Schedule.c", linenum=674) at RtsMessages.c:55 #5 0x0000000001687a52 in schedule (initialCapability=0x1ba6120, task=0x1bc3550) at Schedule.c:674 #6 0x0000000001689901 in workerStart (task=0x1bc3550) at Schedule.c:2528 #7 0x00002b55459db017 in start_thread () from /lib/libpthread.so.0 #8 0x00002b5545cb55bd in clone () from /lib/libc.so.6 #9 0x0000000000000000 in ?? () }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 23 08:23:05 2008 From: trac at galois.com (GHC) Date: Wed Apr 23 08:17:56 2008 Subject: [GHC] #2231: GHC RTS Segfault In-Reply-To: <044.d4bb1e8e3d1948707d5b62e9fdca3bb9@localhost> References: <044.d4bb1e8e3d1948707d5b62e9fdca3bb9@localhost> Message-ID: <053.22076cc9607d5a2391f015a17ce3e0bf@localhost> #2231: GHC RTS Segfault -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Linux -------------------------------+-------------------------------------------- Changes (by guest): * cc: "Matthew, Sackman", (removed) * cc: matthew@wellquite.org (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 23 13:46:46 2008 From: trac at galois.com (GHC) Date: Wed Apr 23 13:41:35 2008 Subject: [GHC] #2234: Profiled binaries create empty files Message-ID: <044.7102554d75e5a8588c921a04c46a11b1@localhost> #2234: Profiled binaries create empty files ------------------------+--------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: minor Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- gwern@localhost:1891~>ghc --version [ 1:20PM] The Glorious Glasgow Haskell Compilation System, version 6.8.2 I recently happened to go through the effort to build a copy of Darcs with profiling enabled (to profile, obviously), and while the profiling runs were quite as helpful as I could've wished, I've since noticed something very annoying: gwern@localhost:1922~>~/bin/bin/darcs whatsnew [ 1:35PM] No changes! gwern@localhost:1923~>cat darcs.prof [ 1:36PM] gwern@localhost:1924~>ls [ 1:36PM] bin/ _darcs/ darcs.prof hacryptopp/ hiersort/ hope/ idris/ ivor/ par-gc-ismm08.pdf pics2/ torrent/ Note the complete lack of any +RTS-RTS flags; nevertheless, an annoying empty file has been created to clutter up my home directory. And deleting it is pointless since it'll just get created. Even worse, this stupid file will appear anywhere I use the profiled darcs (at last count, slocate knew of at least 12 such darcs.prof). And since my system is set up for profiling, it'll only get worse as more and more binaries get built for profiling. I understand from Igloo there's some vague user-friendliness rationale behind GHC's littering, but I'm skeptical that this is really the best way to go about matters. -- gwern -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 23 15:00:58 2008 From: trac at galois.com (GHC) Date: Wed Apr 23 14:55:48 2008 Subject: [GHC] #2158: deriving (Ix) and listArray give unexpected results In-Reply-To: <044.54d602356c43d2c31db7911ab87aa37c@localhost> References: <044.54d602356c43d2c31db7911ab87aa37c@localhost> Message-ID: <053.ec6fa7f626bbd0652347a104f5ee9fff@localhost> #2158: deriving (Ix) and listArray give unexpected results ----------------------------+----------------------------------------------- Reporter: guest | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.8.3 Component: libraries/base | Version: 6.6 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: arr019 | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 23 16:21:46 2008 From: trac at galois.com (GHC) Date: Wed Apr 23 16:16:42 2008 Subject: [GHC] #2044: "Can't unify" error in debugger In-Reply-To: <044.9de84d1571c81bf2b4030ee1192776b2@localhost> References: <044.9de84d1571c81bf2b4030ee1192776b2@localhost> Message-ID: <053.5c55e43ee013774722d5bde11007fda7@localhost> #2044: "Can't unify" error in debugger ----------------------+----------------------------------------------------- Reporter: r6144 | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.8.3 Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: print033 | Architecture: x86 Os: Linux | ----------------------+----------------------------------------------------- Changes (by igloo): * testcase: => print033 * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 23 16:22:01 2008 From: trac at galois.com (GHC) Date: Wed Apr 23 16:16:50 2008 Subject: [GHC] #2141: Internal error on invalid record update In-Reply-To: <041.12bd6af75f291bf77b61c12a037ef054@localhost> References: <041.12bd6af75f291bf77b61c12a037ef054@localhost> Message-ID: <050.e3d5828cc438723e8b828bbc84a9564e@localhost> #2141: Internal error on invalid record update -------------------------------------+-------------------------------------- Reporter: rl | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: rnfail054 | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Changes (by igloo): * testcase: => rnfail054 * status: new => closed * resolution: => fixed Comment: Merged, and rnfail054 added. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 23 16:22:23 2008 From: trac at galois.com (GHC) Date: Wed Apr 23 16:17:15 2008 Subject: [GHC] #2179: Improve error message when `main' is not of the right type In-Reply-To: <047.bbe528ebb3bf93f65afc730c1ab28125@localhost> References: <047.bbe528ebb3bf93f65afc730c1ab28125@localhost> Message-ID: <056.998ee848cfa2d3833405d7db9bab7f3f@localhost> #2179: Improve error message when `main' is not of the right type -----------------------+---------------------------------------------------- Reporter: amiddelk | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: trivial | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: tcfail199 | Architecture: x86_64 (amd64) Os: Linux | -----------------------+---------------------------------------------------- Changes (by igloo): * testcase: => tcfail199 * status: new => closed * resolution: => fixed Comment: Test added (tcfail199) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 23 16:33:10 2008 From: trac at galois.com (GHC) Date: Wed Apr 23 16:28:04 2008 Subject: [GHC] #2044: "Can't unify" error in debugger In-Reply-To: <044.9de84d1571c81bf2b4030ee1192776b2@localhost> References: <044.9de84d1571c81bf2b4030ee1192776b2@localhost> Message-ID: <053.04bd13cd94f28707f45ac23129f871bf@localhost> #2044: "Can't unify" error in debugger ----------------------+----------------------------------------------------- Reporter: r6144 | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.8.3 Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: print033 | Architecture: x86 Os: Linux | ----------------------+----------------------------------------------------- Changes (by igloo): * cc: igloo@earth.li (removed) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 23 18:17:27 2008 From: trac at galois.com (GHC) Date: Wed Apr 23 18:12:17 2008 Subject: [GHC] #2227: (fgl) reimplement Data.Graph.Inductive.Query.Dominators In-Reply-To: <044.d93b0278ed43cd6406c691042576f145@localhost> References: <044.d93b0278ed43cd6406c691042576f145@localhost> Message-ID: <053.56ebd0ea104529d6a466ec4b71bc0e4f@localhost> #2227: (fgl) reimplement Data.Graph.Inductive.Query.Dominators ----------------------------------+----------------------------------------- Reporter: int-e | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Component: libraries (other) | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Testcase: Architecture: Multiple | Os: Multiple ----------------------------------+----------------------------------------- Changes (by int-e): * status: new => closed * resolution: => fixed Comment: Martin Erwig kindly applied the patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 23 19:31:59 2008 From: trac at galois.com (GHC) Date: Wed Apr 23 19:26:59 2008 Subject: [GHC] #2223: Int64.toInteger In-Reply-To: <045.8abd8f650d1173426a900315be0a8333@localhost> References: <045.8abd8f650d1173426a900315be0a8333@localhost> Message-ID: <054.1e1d16ba7e06fed022f2a536539461ad@localhost> #2223: Int64.toInteger -------------------------------+-------------------------------------------- Reporter: gnezdo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.8.2 Severity: major | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Linux -------------------------------+-------------------------------------------- Comment (by wolfgang): Yes, my code was wrong. I think your code still leaves out most corner cases: Consider 0xFFFFFFFF00000001, or 0x0000000080000000. If the high word is 0 of -1 , and the sign bit of the low word matches that, THEN one word is enough. So I would recommend the following (untested): {{{ if ( (hi == 0 && %ge( lo, 0 )) || (hi == 0xFFFFFFFF && %lt(lo, 0) ) { words_needed = 1; // minimum is one word } else { words_needed = 2; } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 23 20:19:32 2008 From: trac at galois.com (GHC) Date: Wed Apr 23 20:14:21 2008 Subject: [GHC] #2221: Can't use quotations ([| ... |]) insides declaration splices In-Reply-To: <045.c35167d86424a00c668b9f902bbda2e4@localhost> References: <045.c35167d86424a00c668b9f902bbda2e4@localhost> Message-ID: <054.416b0b983caab22e59970d9d528131a3@localhost> #2221: Can't use quotations ([| ... |]) insides declaration splices ------------------------------+--------------------------------------------- Reporter: m4dc4p | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Template Haskell | Version: 6.8.2 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ------------------------------+--------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: Thanks for the report. The problem you're seeing here is that you can't splice in types; for more info, see #1476. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 23 20:19:43 2008 From: trac at galois.com (GHC) Date: Wed Apr 23 20:14:33 2008 Subject: [GHC] #1476: Template Haskell: splicing types and patterns In-Reply-To: <044.82d6405cd82a3ed24c1f19d7ab79c38b@localhost> References: <044.82d6405cd82a3ed24c1f19d7ab79c38b@localhost> Message-ID: <053.17fcbb706158717359dfdc908b8b0a36@localhost> #1476: Template Haskell: splicing types and patterns ------------------------------+--------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Template Haskell | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ------------------------------+--------------------------------------------- Comment (by igloo): See also #2221. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Apr 24 03:52:14 2008 From: trac at galois.com (GHC) Date: Thu Apr 24 03:47:01 2008 Subject: [GHC] #2235: Bogus occurs check with type families Message-ID: <046.5974fa5687299769939135165fbad968@localhost> #2235: Bogus occurs check with type families -------------------------+-------------------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- Consider this program, using type families: {{{ data Even; data Odd type family Flip a :: * type instance Flip Even = Odd type instance Flip Odd = Even data List a b where Nil :: List a Even Cons :: a -> List a b -> List a (Flip b) tailList :: List a b -> List a (Flip b) tailList (Cons _ xs) = xs }}} I get the error (from the HEAD) {{{ Occurs check: cannot construct the infinite type: b = Flip (Flip b) In the pattern: Cons _ xs In the definition of `tailList': tailList (Cons _ xs) = xs }}} There's a bug here -- reporting an occurs check is premature. We should really be able to infer the type {{{ tailList :: (b ~ Flip (Flip b)) => List a b -> List a (Flip b) }}} But we get the same bogus occurs-check error with this signature. This example also illustrates why we might want closed families. If you look at the type constraints arising from tailList you'll see that you get `(c ~ Flip b, b ~ Flip c)` where c is the existential you get from the GADT match. Now, ''we'' know that `b = Flip (Flip b)` is always true, but GHC doesn't. After all, you could add new type instances {{{ type instance Flip Int = Bool type instance Flip Bool = Char }}} and then the equation wouldn't hold. What we really want is a *closed* type family, like this {{{ type family Flip a where Flip Even = Odd Flip Odd = Even }}} (preferably supported by kinds) and even *then* it's not clear whether it's reasonable to expect the compiler to solve the above problem by trying all possiblities. This relates to #2101 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Apr 24 08:19:30 2008 From: trac at galois.com (GHC) Date: Thu Apr 24 08:14:23 2008 Subject: [GHC] #2223: Int64.toInteger In-Reply-To: <045.8abd8f650d1173426a900315be0a8333@localhost> References: <045.8abd8f650d1173426a900315be0a8333@localhost> Message-ID: <054.457d243d99ff5b5ea5ce1cfdfdb6580b@localhost> #2223: Int64.toInteger ----------------------------+----------------------------------------------- Reporter: gnezdo | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.8.2 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: arith011 | Architecture: x86 Os: Linux | ----------------------------+----------------------------------------------- Changes (by igloo): * testcase: => arith011 * difficulty: => Unknown * owner: => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Apr 24 08:29:29 2008 From: trac at galois.com (GHC) Date: Thu Apr 24 08:24:18 2008 Subject: [GHC] #2223: Int64.toInteger In-Reply-To: <045.8abd8f650d1173426a900315be0a8333@localhost> References: <045.8abd8f650d1173426a900315be0a8333@localhost> Message-ID: <054.9591d3512aaf34c8f319ccfa08418069@localhost> #2223: Int64.toInteger ----------------------------+----------------------------------------------- Reporter: gnezdo | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Runtime System | Version: 6.8.2 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: arith011 | Architecture: x86 Os: Linux | ----------------------------+----------------------------------------------- Changes (by igloo): * milestone: => 6.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Apr 24 08:33:11 2008 From: trac at galois.com (GHC) Date: Thu Apr 24 08:27:56 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.c4d92573ba2825f28e61f5aea453a4a7@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: normal | Milestone: 6.8.3 Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: hsetbuffering buffering buffer | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | --------------------------------------------+------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.8.3 Comment: Thanks for the report! It works for me on Linux; I can't test on Windows at the moment. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Apr 24 08:34:46 2008 From: trac at galois.com (GHC) Date: Thu Apr 24 08:29:33 2008 Subject: [GHC] #2194: internal error: R_X86_64_32 relocation out of range In-Reply-To: <046.dc336ddb5330040c8ab47ea2ef281042@localhost> References: <046.dc336ddb5330040c8ab47ea2ef281042@localhost> Message-ID: <055.75bd5f55fe2968c0b8edfbe9d8ad88ef@localhost> #2194: internal error: R_X86_64_32 relocation out of range ----------------------+----------------------------------------------------- Reporter: alatter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------+----------------------------------------------------- Changes (by igloo): * difficulty: => Unknown Old description: > $ ghci Stub.hs Whirlpool.o > GHCi, version 6.8.2.20080316: http://www.haskell.org/ghc/ :? for help > Loading package base ... linking ... done. > Loading object (static) Whirlpool.o ... done > ghc-6.8.2.20080316: internal error: R_X86_64_32 relocation out of range: > (noname) = 0x7fc20c2c3010 > > (GHC version 6.8.2.20080316 for x86_64_unknown_linux) > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > Aborted (core dumped) > > ----- > > I'm running Ubuntu 8.4 Beta on some sort of Intel 64-bit platform (Core, > maybe?). > > To reproduce, you'll want the files from > http://planeta.terra.com.br/informatica/paulobarreto/whirlpool.zip > > And in the same directory, the attached files Stub.hs and Whirlpool.h > (not needed just to compile the .c file, but it makes the haskell FFI > happy). > > There are a couple things I tried > > First: > > $ gcc Whirlpool.c -c > $ ghci Stub Whirlpool.o > > > Second: > $ rm *.o > $ ghc --make Stub Whirlpool.c > $ ghci Stub Whirlpool.o > New description: {{{ $ ghci Stub.hs Whirlpool.o GHCi, version 6.8.2.20080316: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Loading object (static) Whirlpool.o ... done ghc-6.8.2.20080316: internal error: R_X86_64_32 relocation out of range: (noname) = 0x7fc20c2c3010 (GHC version 6.8.2.20080316 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) }}} I'm running Ubuntu 8.4 Beta on some sort of Intel 64-bit platform (Core, maybe?). To reproduce, you'll want the files from http://planeta.terra.com.br/informatica/paulobarreto/whirlpool.zip And in the same directory, the attached files Stub.hs and Whirlpool.h (not needed just to compile the .c file, but it makes the haskell FFI happy). There are a couple things I tried First: {{{ $ gcc Whirlpool.c -c $ ghci Stub Whirlpool.o }}} Second: {{{ $ rm *.o $ ghc --make Stub Whirlpool.c $ ghci Stub Whirlpool.o }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Apr 24 08:42:01 2008 From: trac at galois.com (GHC) Date: Thu Apr 24 08:36:48 2008 Subject: [GHC] #2194: internal error: R_X86_64_32 relocation out of range In-Reply-To: <046.dc336ddb5330040c8ab47ea2ef281042@localhost> References: <046.dc336ddb5330040c8ab47ea2ef281042@localhost> Message-ID: <055.ae9d75b9f9259ddeacf08f326d9be18a@localhost> #2194: internal error: R_X86_64_32 relocation out of range ----------------------+----------------------------------------------------- Reporter: alatter | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------+----------------------------------------------------- Changes (by igloo): * milestone: => 6.8.3 Comment: Thanks for the report. This seems to work in the HEAD: {{{ $ gcc Whirlpool.c -c $ ghci Whirlpool.o GHCi, version 6.9.20080423: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Loading object (static) Whirlpool.o ... done final link ... done Prelude> }}} I don't know off-hand how big the fix was, and thus how feasible it is to merge it into 6.8.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Apr 24 08:42:57 2008 From: trac at galois.com (GHC) Date: Thu Apr 24 08:37:43 2008 Subject: [GHC] #2196: Errors in output from formatTime In-Reply-To: <044.a53cada5d60b5b73662375cb432c3e02@localhost> References: <044.a53cada5d60b5b73662375cb432c3e02@localhost> Message-ID: <053.be5c74eab9d8c97adb6039bdd052b335@localhost> #2196: Errors in output from formatTime -------------------------------+-------------------------------------------- Reporter: laney | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Unknown | -------------------------------+-------------------------------------------- Changes (by igloo): * difficulty: => Unknown Old description: > Hi, > > I have discovered two errors in the Date/Time libraries distributed with > GHC. > > When running the attached testcase: > > *Main> timebug > Loading package old-locale-1.0.0.0 ... linking ... done. > Loading package time-1.1.2.0 ... linking ... done. > "Sun, d Apr 2008 00:16:45 UTC" > > There are two problems here: > > * Returns "d" for day of month, certainly not right. > * Returns "UTC" instead of "UT", incorrect per RFC 822 - > http://www.faqs.org/rfcs/rfc822.html section 5.1 > > Iain New description: Hi, I have discovered two errors in the Date/Time libraries distributed with GHC. When running the attached testcase: {{{ *Main> timebug Loading package old-locale-1.0.0.0 ... linking ... done. Loading package time-1.1.2.0 ... linking ... done. "Sun, d Apr 2008 00:16:45 UTC" }}} There are two problems here: * Returns "d" for day of month, certainly not right. * Returns "UTC" instead of "UT", incorrect per RFC 822 - http://www.faqs.org/rfcs/rfc822.html section 5.1 Iain -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Apr 24 08:50:59 2008 From: trac at galois.com (GHC) Date: Thu Apr 24 08:45:45 2008 Subject: [GHC] #2196: Errors in output from formatTime In-Reply-To: <044.a53cada5d60b5b73662375cb432c3e02@localhost> References: <044.a53cada5d60b5b73662375cb432c3e02@localhost> Message-ID: <053.2175bec2ce35be465867ad7af7bdd941@localhost> #2196: Errors in output from formatTime -------------------------------+-------------------------------------------- Reporter: laney | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries (other) | Version: 6.8.2 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Unknown | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => invalid Comment: Thanks for the report. However, the time package says: {{{ Author: Ashley Yakeley Maintainer: }}} so please send any bug reports to Ashley. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Apr 24 08:52:23 2008 From: trac at galois.com (GHC) Date: Thu Apr 24 08:47:09 2008 Subject: [GHC] #2198: Build failure on Mac OS X Tiger Intel In-Reply-To: <044.e669693b0e2d8babbb9829cda3557205@localhost> References: <044.e669693b0e2d8babbb9829cda3557205@localhost> Message-ID: <053.40320fdfdeb37aadd4e91eeb180c05d6@localhost> #2198: Build failure on Mac OS X Tiger Intel --------------------------+------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | --------------------------+------------------------------------------------- Changes (by igloo): * difficulty: => Unknown Old description: > The ghc in Macports fails to build on my Intel MacBook, running Mac OS > 10.5.2. Here's what Gregory Wright, the ghc macports maintainer had to > say: > > ''It is possible that this is yet another file locking bug, which seem > especially > easy to trigger when running OS X on faster hardware. The warning from > PackageConfig.hs may be spurious, the result of the import from > InstalledPackageInfo.hi > silently failing. There are a few places where important error messages > are discarded, on the assumption that the cause of the failure will be > obvious.'' > > I've attached the build log. I'd be happy to provide more information, if > it might help. > > Wouter Swierstra New description: The ghc in Macports fails to build on my Intel !MacBook, running Mac OS 10.5.2. Here's what Gregory Wright, the ghc macports maintainer had to say: ''It is possible that this is yet another file locking bug, which seem especially easy to trigger when running OS X on faster hardware. The warning from !PackageConfig.hs may be spurious, the result of the import from !InstalledPackageInfo.hi silently failing. There are a few places where important error messages are discarded, on the assumption that the cause of the failure will be obvious.'' I've attached the build log. I'd be happy to provide more information, if it might help. Wouter Swierstra -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Apr 24 08:56:05 2008 From: trac at galois.com (GHC) Date: Thu Apr 24 08:50:51 2008 Subject: [GHC] #2198: Build failure on Mac OS X Tiger Intel In-Reply-To: <044.e669693b0e2d8babbb9829cda3557205@localhost> References: <044.e669693b0e2d8babbb9829cda3557205@localhost> Message-ID: <053.a2ef594ab79b0e508dee5a66a45b800b@localhost> #2198: Build failure on Mac OS X Tiger Intel --------------------------+------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Build System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | --------------------------+------------------------------------------------- Changes (by igloo): * milestone: => 6.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Apr 24 08:56:58 2008 From: trac at galois.com (GHC) Date: Thu Apr 24 08:51:45 2008 Subject: [GHC] #2199: th32SnapEnumProcesses in System.Win32.Process prints debugging information to stdout In-Reply-To: <044.b8fbd1c67ea8e923433d5eaf1eaa88db@localhost> References: <044.b8fbd1c67ea8e923433d5eaf1eaa88db@localhost> Message-ID: <053.c868545e8c804ad095997f7b0b6b4f6b@localhost> #2199: th32SnapEnumProcesses in System.Win32.Process prints debugging information to stdout -----------------------------------+---------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: th32SnapEnumProcesses | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Windows | -----------------------------------+---------------------------------------- Changes (by igloo): * difficulty: => Unknown Old description: > TSIA, pretty much. I suspect that when the author was developing this > function he put in some putStrLn calls for his own use and simply forgot > to remove them. For my application I just took the code out of the > library and ripped out the offending statements, but I don't think > they're really supposed to be there and ought to be either removed or > #ifdef'd out somehow. Here's my cleaned up version (I also removed some > extraneous parenthesis, FWIW). > > th32SnapEnumProcesses :: Th32SnapHandle -> IO [ProcessEntry32] > th32SnapEnumProcesses h = allocaBytes 556 $ \pe -> do > pokeByteOff pe 0 (556 :: DWORD) > ok <- c_Process32First h pe > readAndNext ok pe [] > where > errStr = "th32SnapEnumProcesses: Process32First/Process32Next" > readAndNext ok pe res > | not ok = do > err <- getLastError > if err == 18 > then return $ reverse res > else failWith errStr err > | otherwise = do > entry <- peekProcessEntry32 pe > ok' <- c_Process32Next h pe > readAndNext ok' pe (entry:res) New description: TSIA, pretty much. I suspect that when the author was developing this function he put in some putStrLn calls for his own use and simply forgot to remove them. For my application I just took the code out of the library and ripped out the offending statements, but I don't think they're really supposed to be there and ought to be either removed or #ifdef'd out somehow. Here's my cleaned up version (I also removed some extraneous parenthesis, FWIW). {{{ th32SnapEnumProcesses :: Th32SnapHandle -> IO [ProcessEntry32] th32SnapEnumProcesses h = allocaBytes 556 $ \pe -> do pokeByteOff pe 0 (556 :: DWORD) ok <- c_Process32First h pe readAndNext ok pe [] where errStr = "th32SnapEnumProcesses: Process32First/Process32Next" readAndNext ok pe res | not ok = do err <- getLastError if err == 18 then return $ reverse res else failWith errStr err | otherwise = do entry <- peekProcessEntry32 pe ok' <- c_Process32Next h pe readAndNext ok' pe (entry:res) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Apr 24 10:21:45 2008 From: trac at galois.com (GHC) Date: Thu Apr 24 10:16:43 2008 Subject: [GHC] #1958: collect2: ld terminated with signal 10 [Bus error]: Building parsec on a PPC Mac OS X 10.5 Leopard as part of GHC 6.9 In-Reply-To: <050.c31695132cb1b93380c95a8b6c208782@localhost> References: <050.c31695132cb1b93380c95a8b6c208782@localhost> Message-ID: <059.77ba22da14cb6c6390e35d3839d650c1@localhost> #1958: collect2: ld terminated with signal 10 [Bus error]: Building parsec on a PPC Mac OS X 10.5 Leopard as part of GHC 6.9 -------------------------+-------------------------------------------------- Reporter: thorkilnaur | Owner: thorkilnaur Type: bug | Status: new Priority: high | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | -------------------------+-------------------------------------------------- Comment (by thorkilnaur): Apple has responded to the "Bug ID# 5655246 (PPC Leopard (Xcode 3.0) linker ld gets "Bus error" sometimes)" that I reported a while back, saying that this issue has been addressed in "the latest seed release of Xcode 3.1, build 9M2165" and asking for an update of the bug report. I will get to that within the next couple of days. Best regards Thorkil -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Apr 24 10:30:16 2008 From: trac at galois.com (GHC) Date: Thu Apr 24 10:25:04 2008 Subject: [GHC] #1843: ghc 6.8.1 broken on Mac OS X Leopard PPC In-Reply-To: <044.ed2a345fe747cd9c97e2c67af33b571b@localhost> References: <044.ed2a345fe747cd9c97e2c67af33b571b@localhost> Message-ID: <053.5dc8907aed97d663475fd22aa81de708@localhost> #1843: ghc 6.8.1 broken on Mac OS X Leopard PPC ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: high | Milestone: 6.8.2 Component: Compiler | Version: 6.8.1 Severity: critical | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | ----------------------+----------------------------------------------------- Comment (by thorkilnaur): Just for the curious, since we have applied a work-around: Apple has responded to the "Bug ID #: 5637618 (PPC Leopard (Xcode 3.0) linker ld reports "unknown scattered relocation type 4")", saying that this issue has been addressed in "the latest seed release of Xcode 3.1, build 9M2165". Best regards Thorkil -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Apr 24 10:54:55 2008 From: trac at galois.com (GHC) Date: Thu Apr 24 10:49:45 2008 Subject: [GHC] #2223: Int64.toInteger In-Reply-To: <045.8abd8f650d1173426a900315be0a8333@localhost> References: <045.8abd8f650d1173426a900315be0a8333@localhost> Message-ID: <054.51ea17e5b4ed8ed9ffdad705208c24d8@localhost> #2223: Int64.toInteger ----------------------------+----------------------------------------------- Reporter: gnezdo | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.8.3 Component: Runtime System | Version: 6.8.2 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: arith011 | Architecture: x86 Os: Linux | ----------------------------+----------------------------------------------- Changes (by igloo): * type: bug => merge Comment: I've applied the original (Mike Gunter's) patch; it is sufficient as far as I can see. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Apr 24 11:44:37 2008 From: trac at galois.com (GHC) Date: Thu Apr 24 11:39:38 2008 Subject: [GHC] #2200: big static random access arrays In-Reply-To: <043.a925e7306d93d3b9993abaf14c0d8674@localhost> References: <043.a925e7306d93d3b9993abaf14c0d8674@localhost> Message-ID: <052.066f8e7fa327028dab6c5c76a0c8fe53@localhost> #2200: big static random access arrays -----------------------------+---------------------------------------------- Reporter: jsnx | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: static array | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -----------------------------+---------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => _|_ Comment: I don't think that this is very high on our list of priorities, but if someone else wanted to attempt it then we would certainly be able to give advice if you get stuck. I'm not sure exactly what design you envisage, but it may not require changes to GHC at all; I would certainly expect that to be the case for something implemented with TH. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Apr 24 11:45:16 2008 From: trac at galois.com (GHC) Date: Thu Apr 24 11:40:01 2008 Subject: [GHC] #2201: "ghc-pkg --user describe '*'" fails with empty user db In-Reply-To: <045.673a6cc9904f9063d50fb7c9230e5305@localhost> References: <045.673a6cc9904f9063d50fb7c9230e5305@localhost> Message-ID: <054.63e00d12a1056af5e9ab2bd59910766e@localhost> #2201: "ghc-pkg --user describe '*'" fails with empty user db ----------------------+----------------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Apr 24 11:47:07 2008 From: trac at galois.com (GHC) Date: Thu Apr 24 11:42:10 2008 Subject: [GHC] #2202: type error causes type checker stack overflow In-Reply-To: <045.817a1089ed0068d0921ec39de4c6cc2f@localhost> References: <045.817a1089ed0068d0921ec39de4c6cc2f@localhost> Message-ID: <054.175dddd650b3a500280a4327c39b9ecc@localhost> #2202: type error causes type checker stack overflow -------------------------------------+-------------------------------------- Reporter: chiral | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler (Type checker) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Other Os: Other | -------------------------------------+-------------------------------------- Changes (by igloo): * milestone: => 6.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Apr 24 11:47:30 2008 From: trac at galois.com (GHC) Date: Thu Apr 24 11:42:21 2008 Subject: [GHC] #2203: TFs in class instances heads In-Reply-To: <043.d54d86ddec760e3a2475c6e848a97d7e@localhost> References: <043.d54d86ddec760e3a2475c6e848a97d7e@localhost> Message-ID: <052.e719ccc915a021b4b9e3fadfad5fb36d@localhost> #2203: TFs in class instances heads -------------------------------------+-------------------------------------- Reporter: chak | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -------------------------------------+-------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Apr 24 11:48:11 2008 From: trac at galois.com (GHC) Date: Thu Apr 24 11:42:58 2008 Subject: [GHC] #2212: Double assignment to coercion variable In-Reply-To: <046.ad4e8af6cf182013c618bfd8fa17eb5c@localhost> References: <046.ad4e8af6cf182013c618bfd8fa17eb5c@localhost> Message-ID: <055.2e7887be8a853e010a2d4f192e59d75c@localhost> #2212: Double assignment to coercion variable ----------------------+----------------------------------------------------- Reporter: simonpj | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: equal | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * milestone: => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Apr 24 11:48:29 2008 From: trac at galois.com (GHC) Date: Thu Apr 24 11:43:17 2008 Subject: [GHC] #2219: GADT match fails to refine type variable In-Reply-To: <044.d581efc20e7649a6ed48131c2b7ba2cd@localhost> References: <044.d581efc20e7649a6ed48131c2b7ba2cd@localhost> Message-ID: <053.24832639251103178320c65c3f705e0e@localhost> #2219: GADT match fails to refine type variable -------------------------------------+-------------------------------------- Reporter: dolio | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: gadt type family | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | -------------------------------------+-------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Apr 24 11:48:58 2008 From: trac at galois.com (GHC) Date: Thu Apr 24 11:43:50 2008 Subject: [GHC] #2224: -fhpc inteferes/prevents rewrite rules from firing In-Reply-To: <043.0a1d2cb80ab6ed909cbaaf8b919814c3@localhost> References: <043.0a1d2cb80ab6ed909cbaaf8b919814c3@localhost> Message-ID: <052.e4669f7d1bfd3af8b2890743510158ef@localhost> #2224: -fhpc inteferes/prevents rewrite rules from firing ---------------------------+------------------------------------------------ Reporter: dons | Owner: andy@galois.com Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Code Coverage | Version: 6.8.2 Severity: normal | Resolution: Keywords: rules, hpc | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * milestone: => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Apr 24 11:54:29 2008 From: trac at galois.com (GHC) Date: Thu Apr 24 11:49:15 2008 Subject: [GHC] #2207: Load the interface details for GHC.* even without -O In-Reply-To: <046.c160dd85a0a0b0a47d62c75151b28378@localhost> References: <046.c160dd85a0a0b0a47d62c75151b28378@localhost> Message-ID: <055.b53951e9e32cafa3fa75277ac5d77445@localhost> #2207: Load the interface details for GHC.* even without -O -----------------------------+---------------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * milestone: => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Apr 24 11:57:20 2008 From: trac at galois.com (GHC) Date: Thu Apr 24 11:52:06 2008 Subject: [GHC] #2208: many .xml files for the User's Manual force xml-mode in emacs In-Reply-To: <043.dbdf8ae310e46744a6c504b004f1a2cd@localhost> References: <043.dbdf8ae310e46744a6c504b004f1a2cd@localhost> Message-ID: <052.c81a8638dd5bab921063cfda05372610@localhost> #2208: many .xml files for the User's Manual force xml-mode in emacs ---------------------------+------------------------------------------------ Reporter: SamB | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8 branch Component: Documentation | Version: 6.9 Severity: normal | Resolution: Keywords: emacs | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.8 branch Comment: If the mode line is removed, will the sgml-parent line still work? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Apr 24 12:14:16 2008 From: trac at galois.com (GHC) Date: Thu Apr 24 12:09:03 2008 Subject: [GHC] #2209: MagicHash extraction is wrong on x86_64 with -fasm -O2 In-Reply-To: <044.b26772684deb839421045da398f72aae@localhost> References: <044.b26772684deb839421045da398f72aae@localhost> Message-ID: <053.5b94c2bc08111ba8555a70c03422b15a@localhost> #2209: MagicHash extraction is wrong on x86_64 with -fasm -O2 ----------------------+----------------------------------------------------- Reporter: quark | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------+----------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.8.3 Comment: In my validated-HEAD, this gives me {{{ /tmp/ghc4469_0/ghc4469_0.s:460:0: Error: suffix or operands invalid for `test' /tmp/ghc4469_0/ghc4469_0.s:463:0: Error: suffix or operands invalid for `test' /tmp/ghc4469_0/ghc4469_0.s:474:0: Error: suffix or operands invalid for `movsd' }}} complaining about these 3 lines: {{{ testq %xmm0,%xmm0 testq %xmm0,%xmm0 movsd .Ln1c1(%rip),%rsi }}} We do claim that this ("Casting an unboxed type to another unboxed type of the same size") works in the `unsafeCoerce#` docs, so we ought to fix it! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Apr 24 13:01:25 2008 From: trac at galois.com (GHC) Date: Thu Apr 24 12:56:11 2008 Subject: [GHC] #2213: -Wall incorrectly warns "Defined but not used" for functions exported via RULES In-Reply-To: <043.a16de73b756c546cfe361c8db1abcd3b@localhost> References: <043.a16de73b756c546cfe361c8db1abcd3b@localhost> Message-ID: <052.22f2b5629373eb133ad29dd3f15dc146@localhost> #2213: -Wall incorrectly warns "Defined but not used" for functions exported via RULES ----------------------+----------------------------------------------------- Reporter: dons | Owner: dons Type: bug | Status: assigned Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch Comment: This is currently rather odd. You need one of `ScopedTypeVariables`, `PolymorphicComponents`, `ExistentialQuantification`, `Rank2Types` and `RankNTypes` enabled, as these all turn on lexing of `forall`. Really, there ought to be a flag for rewrite rules instead (which also turns on lexing of `forall`). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Apr 24 13:03:09 2008 From: trac at galois.com (GHC) Date: Thu Apr 24 12:57:55 2008 Subject: [GHC] #2215: :disable command to disable breakpoints In-Reply-To: <043.47da2ed31d640e7b0815bd5873ce0ad5@localhost> References: <043.47da2ed31d640e7b0815bd5873ce0ad5@localhost> Message-ID: <052.6ea307d8e4301a53d1aa64e1a907427a@localhost> #2215: :disable command to disable breakpoints -----------------------------+---------------------------------------------- Reporter: SamB | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.9 Severity: major | Resolution: Keywords: debugger ghci | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * milestone: => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Apr 24 13:11:06 2008 From: trac at galois.com (GHC) Date: Thu Apr 24 13:06:07 2008 Subject: [GHC] #2216: Better error message for unboxed types with no -fglasgow-exts flag In-Reply-To: <042.15c11e3b7bac7b751aafc89a9516ed93@localhost> References: <042.15c11e3b7bac7b751aafc89a9516ed93@localhost> Message-ID: <051.6051e6f06a46ec24bf72b361680c7dd4@localhost> #2216: Better error message for unboxed types with no -fglasgow-exts flag -------------------------------+-------------------------------------------- Reporter: tim | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler (Parser) | Version: 6.8.2 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => _|_ Comment: Yes, this is hard, because we really want to know whether there was a space before the #, but we don't know that at the point we want to give the error. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Apr 24 13:16:12 2008 From: trac at galois.com (GHC) Date: Thu Apr 24 13:11:02 2008 Subject: [GHC] #2217: :list command missing from help In-Reply-To: <044.fbe338f21c5a3bd6c2e8b69d2945b572@localhost> References: <044.fbe338f21c5a3bd6c2e8b69d2945b572@localhost> Message-ID: <053.f6fc817e9657daeb6b6c01c6b07ef80e@localhost> #2217: :list command missing from help ---------------------+------------------------------------------------------ Reporter: mrijn | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: GHCi | Version: 6.8.2 Severity: trivial | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ---------------------+------------------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Apr 24 13:16:51 2008 From: trac at galois.com (GHC) Date: Thu Apr 24 13:11:46 2008 Subject: [GHC] #2218: ghci leaks memory on :reload etc In-Reply-To: <045.8a6d8f2645e2e281aaf28111fdc114b6@localhost> References: <045.8a6d8f2645e2e281aaf28111fdc114b6@localhost> Message-ID: <054.9c83a67bd2044af7263b4f99bdbc4a4b@localhost> #2218: ghci leaks memory on :reload etc --------------------+------------------------------------------------------- Reporter: ganesh | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | --------------------+------------------------------------------------------- Changes (by igloo): * milestone: => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Apr 24 13:17:21 2008 From: trac at galois.com (GHC) Date: Thu Apr 24 13:12:08 2008 Subject: [GHC] #2222: Template Haskell: reify returns incorrect types when ommiting type signatures In-Reply-To: <043.ad3979036d0a8d6334de105353abe0e3@localhost> References: <043.ad3979036d0a8d6334de105353abe0e3@localhost> Message-ID: <052.18e3f0f32d1da01500281ae31ec033fa@localhost> #2222: Template Haskell: reify returns incorrect types when ommiting type signatures ------------------------------+--------------------------------------------- Reporter: fons | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Template Haskell | Version: 6.8.2 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * milestone: => _|_ -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Apr 24 22:53:42 2008 From: trac at galois.com (GHC) Date: Thu Apr 24 22:48:26 2008 Subject: [GHC] #601: Replace GMP In-Reply-To: <047.118762464fe3464def09b9461b8cccc5@localhost> References: <047.118762464fe3464def09b9461b8cccc5@localhost> Message-ID: <056.ffaafde56ff9782921ed6e1a4002cdeb@localhost> #601: Replace GMP ----------------------+----------------------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: None Severity: normal | Resolution: None Keywords: | Difficulty: Difficult (1 week) Testcase: N/A | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by igloo): http://darcs.haskell.org/libraries/integer-simple/ is a much more efficient implementation than ultra-simple. It validates on 32bit and 64bit machines, although simplrun004(optc) may fail by running out of stack space. This is probably because the Integer operations and/or representation are lazy, but this is fixable. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 25 04:39:49 2008 From: trac at galois.com (GHC) Date: Fri Apr 25 04:34:33 2008 Subject: [GHC] #2236: Deep stacks make execution time go through the roof Message-ID: <046.3a0daf0dccbb67382aad82aeb994d473@localhost> #2236: Deep stacks make execution time go through the roof -----------------------------------------+---------------------------------- Reporter: simonpj | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown -----------------------------------------+---------------------------------- In the code below, switching from `mapM_` to `mapM` causes a 20x change in execution time. The code being executed is very very similar (try `-ddump-simpl`), and the number of bytes allocated is not dissimilar. But the GC time is dramatically more (presumably because we are repeatedly scanning a very deep stack) and, more puzzlingly, the MUT time is much more too. It all seems to be to do with the stack depth. Not only that, but I think the effect is non-linear: doubling n from 200k to 400k nearly quadruples runtime. Doubling again to 800k makes it say 'Killed'. {{{ module Main(main) where import System.IO import System.IO (openFile, IOMode(..), hPutStr) n = 200000::Int main = main_fast main_slow = do -- Use mapM h <- openFile "bardump2" WriteMode mapM (do_it h) testlst main_fast = do -- Use mapM_ h <- openFile "bardump2" WriteMode mapM_ (do_it h) testlst do_it h x = hPutStr h "yes" testlst = [1..n] }}} Thanks to Ben for identifying this. Below are some figures {{{ -------------------------------------- main = main_fast, N= 300,000 251,371,168 bytes allocated in the heap 14,041,824 bytes copied during GC (scavenged) 1,504 bytes copied during GC (not scavenged) 8,413,184 bytes maximum residency (5 sample(s)) 448 collections in generation 0 ( 2.00s) 5 collections in generation 1 ( 0.01s) 17 Mb total memory in use INIT time 0.00s ( 0.00s elapsed) MUT time 1.17s ( 1.18s elapsed) GC time 2.01s ( 2.03s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 3.18s ( 3.22s elapsed) %GC time 63.3% (63.1% elapsed) Alloc rate 215,201,590 bytes per MUT second Productivity 36.7% of total user, 36.2% of total elapsed -------------------------------------- main = main_slow, N= 300,000 227,615,792 bytes allocated in the heap 49,224 bytes copied during GC (scavenged) 1,440 bytes copied during GC (not scavenged) 40,960 bytes maximum residency (1 sample(s)) 435 collections in generation 0 ( 0.00s) 1 collections in generation 1 ( 0.00s) 1 Mb total memory in use INIT time 0.00s ( 0.00s elapsed) MUT time 0.15s ( 0.15s elapsed) GC time 0.00s ( 0.00s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 0.15s ( 0.16s elapsed) %GC time 0.0% (1.8% elapsed) Alloc rate 1,537,851,022 bytes per MUT second Productivity 100.0% of total user, 95.4% of total elapsed --------------------------------------------- Non-linear effect n fast/slow Mut GC Tot 400k fast 0.19 0 0.2 slow 2.14 3.64 5.78 200k fast 0.09 0 0.09 slow 0.48 0.96 1.44 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 25 07:16:02 2008 From: trac at galois.com (GHC) Date: Fri Apr 25 07:10:49 2008 Subject: [GHC] #2237: qualified names not permitted everywhere in instances Message-ID: <044.979df1df57c1530008974aa6ad0b7805@localhost> #2237: qualified names not permitted everywhere in instances ------------------------+--------------------------------------------------- Reporter: claus | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Parser) Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- consider using a class that is imported qualified only: - we cannot define instance methods, as their qualified names are not accepted (this restriction makes sense at top-level, but not in instances) - we cannot refer to instances in instance contexts, as their qualified names are not accepted (they are accepted in class contexts, and -XFlexibleInstances accepts them in instance contexts) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 25 07:29:57 2008 From: trac at galois.com (GHC) Date: Fri Apr 25 07:24:40 2008 Subject: [GHC] #2237: qualified names not permitted everywhere in instances In-Reply-To: <044.979df1df57c1530008974aa6ad0b7805@localhost> References: <044.979df1df57c1530008974aa6ad0b7805@localhost> Message-ID: <053.13dec1c36953402cd0d9020906f6e790@localhost> #2237: qualified names not permitted everywhere in instances -------------------------------+-------------------------------------------- Reporter: claus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Changes (by simonpj): * difficulty: => Unknown Comment: Looks fine to me. In your example program * You don't need the qualification on `fmap`; it's unambiguous without. * The instance for `Dope` really isn't H98 and is rejected for that reason. This works: {{{ module Foo where import qualified Prelude data T a = MkT instance (Prelude.Show a) => Prelude.Show (T a) where show = Prelude.error "urk" class Prelude.Show a => Dope a instance Prelude.Show a => Dope (T a) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 25 07:46:33 2008 From: trac at galois.com (GHC) Date: Fri Apr 25 07:41:18 2008 Subject: [GHC] #2238: panic nameModule tpl_B1{v} Message-ID: <044.2c7ef9e7b09c867edd5544536ef8fbf1@localhost> #2238: panic nameModule tpl_B1{v} ------------------------+--------------------------------------------------- Reporter: claus | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- using the attached code, we get {{{ *Main> cfd True "cfd" *Main> ctf True :1:0: No instance for (CTF Bool how) arising from a use of `ctf' at :1:0-7 Possible fix: add an instance declaration for (CTF Bool how) In the expression: ctf True In the definition of `it': it = ctf True }}} but if we uncomment the `CTF` instance, we get panic, even for cfd.. {{{ *Main> cfd True : panic! (the 'impossible' happened) (GHC version 6.9.20080217 for i386-unknown-mingw32): nameModule tpl_B1{v} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *Main> ctf True : panic! (the 'impossible' happened) (GHC version 6.9.20080217 for i386-unknown-mingw32): nameModule tpl_B1{v} 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 Apr 25 07:52:24 2008 From: trac at galois.com (GHC) Date: Fri Apr 25 07:47:07 2008 Subject: [GHC] #2238: panic nameModule tpl_B1{v} In-Reply-To: <044.2c7ef9e7b09c867edd5544536ef8fbf1@localhost> References: <044.2c7ef9e7b09c867edd5544536ef8fbf1@localhost> Message-ID: <053.f3bf3d2b63620916bfe7215362963987@localhost> #2238: panic nameModule tpl_B1{v} -------------------------+-------------------------------------------------- Reporter: claus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- Comment (by claus): btw, before the panic, this was meant to pin down an issue with TFs (vs FDs), where TFs don't improve types sufficiently for instance selection. compare: {{{ *Main> :t undefined :: CTF Bool how => how undefined :: CTF Bool how => how :: HowTF Bool *Main> :t undefined :: CFD Bool how => how undefined :: CFD Bool how => how :: A }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 25 08:22:07 2008 From: trac at galois.com (GHC) Date: Fri Apr 25 08:16:53 2008 Subject: [GHC] #2237: qualified names not permitted everywhere in instances In-Reply-To: <044.979df1df57c1530008974aa6ad0b7805@localhost> References: <044.979df1df57c1530008974aa6ad0b7805@localhost> Message-ID: <053.e700bf2c4fd84c567788726cfaf6ff2a@localhost> #2237: qualified names not permitted everywhere in instances -------------------------------+-------------------------------------------- Reporter: claus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Comment (by claus): Replying to [comment:1 simonpj]: > Looks fine to me. In your example program > * You don't need the qualification on `fmap`; it's unambiguous without. but it isn't in scope! isn't it a bug that i can define `fmap` if it isn't in scope, but not `Prelude.fmap`, even though it is? and the unambiguity doesn't go all that far, either: {{{ module QI where import Prelude hiding (Functor(..)) import qualified Prelude (Functor(..)) data X a = X a deriving Show instance Prelude.Functor X where fmap f (X a) = X (f a) where q = (reverse fmap,Prelude.fmap not [True],reverse QI.fmap) fmap = "fmap" }}} in `q`, `fmap` appears to refer to `QI.fmap`, not to `Prelude.fmap`, as it does in the `fmap` definition.. > * The instance for `Dope` really isn't H98 and is rejected for that reason. oops, yes. sorry about that (i'm constantly amazed at what isn't H98!-). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 25 08:27:34 2008 From: trac at galois.com (GHC) Date: Fri Apr 25 08:22:18 2008 Subject: [GHC] #2193: Monomorphic Pattern Bindings and Error Messages In-Reply-To: <043.34ccdeb27bebe4aa866d2df9503f28c8@localhost> References: <043.34ccdeb27bebe4aa866d2df9503f28c8@localhost> Message-ID: <052.a7135cbea7189b5f3e780da9f215c64b@localhost> #2193: Monomorphic Pattern Bindings and Error Messages ----------------------+----------------------------------------------------- Reporter: sclv | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ----------------------+----------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.8.3 Comment: Thanks for the report! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 25 08:38:02 2008 From: trac at galois.com (GHC) Date: Fri Apr 25 08:32:50 2008 Subject: [GHC] #2206: GADT pattern match with non-rigid return type In-Reply-To: <046.ef46bda025b4e7ab59ca8efa3b49bcc6@localhost> References: <046.ef46bda025b4e7ab59ca8efa3b49bcc6@localhost> Message-ID: <055.04f46bee2d6a2eeff34f975546ed0043@localhost> #2206: GADT pattern match with non-rigid return type --------------------------+------------------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: gadt-escape1 | Architecture: Unknown Os: Unknown | --------------------------+------------------------------------------------- Changes (by igloo): * milestone: => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 25 08:41:00 2008 From: trac at galois.com (GHC) Date: Fri Apr 25 08:35:43 2008 Subject: [GHC] #2199: th32SnapEnumProcesses in System.Win32.Process prints debugging information to stdout In-Reply-To: <044.b8fbd1c67ea8e923433d5eaf1eaa88db@localhost> References: <044.b8fbd1c67ea8e923433d5eaf1eaa88db@localhost> Message-ID: <053.db14b66b685a8e73f6ba8238d8658d10@localhost> #2199: th32SnapEnumProcesses in System.Win32.Process prints debugging information to stdout -----------------------------------+---------------------------------------- Reporter: guest | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: th32SnapEnumProcesses | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Windows | -----------------------------------+---------------------------------------- Changes (by igloo): * owner: => igloo Comment: Thanks for the report; I'll fix this. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 25 08:43:52 2008 From: trac at galois.com (GHC) Date: Fri Apr 25 08:38:34 2008 Subject: [GHC] #2239: lack of improvement/reduction with TFs Message-ID: <044.40f3b78a317b6571e596e1e3328f356b@localhost> #2239: lack of improvement/reduction with TFs -------------------------+-------------------------------------------------- Reporter: claus | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 6.9 | Severity: normal Keywords: TF vs FD | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- {{{ {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE TypeFamilies #-} data A = A data B = B class C a where c :: a -> String instance C Bool where c _ = "Bool" instance C Char where c _ = "Char" -- via TFs type family TF a type instance TF A = Char type instance TF B = Bool tf :: forall a b. (b ~ TF a,C b) => a -> String tf a = c (undefined:: b) -- via FDs class FD a b | a -> b instance FD A Char instance FD B Bool fd :: forall a b. (FD a b,C b) => a -> String fd a = c (undefined:: b) }}} for some reason, the TF version doesn't work as well as the FD version: {{{ *Main> fd A "Char" *Main> fd B "Bool" *Main> tf A :1:0: No instance for (C (TF A)) arising from a use of `tf' at :1:0-3 Possible fix: add an instance declaration for (C (TF A)) In the expression: tf A In the definition of `it': it = tf A *Main> :t undefined :: (b~TF A)=>b undefined :: (b~TF A)=>b :: TF A *Main> :t undefined :: (FD A b)=>b undefined :: (FD A b)=>b :: Char }}} this is with `GHCi, version 6.9.20080217`. the result of the TF is "known", even if not used: {{{ *Main> :t undefined :: (b~TF A,b~Char)=>b undefined :: (b~TF A,b~Char)=>b :: TF A *Main> :t undefined :: (b~TF A,b~Bool)=>b :1:0: Couldn't match expected type `Bool' against inferred type `Char' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 25 08:44:50 2008 From: trac at galois.com (GHC) Date: Fri Apr 25 08:39:33 2008 Subject: [GHC] #2229: ghc crashes on trying to build encoding module In-Reply-To: <044.59be979a984add956a2884258740e486@localhost> References: <044.59be979a984add956a2884258740e486@localhost> Message-ID: <053.085333fee0fa62b3833ab8c2a46cc4e9@localhost> #2229: ghc crashes on trying to build encoding module ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * difficulty: => Unknown Old description: > It gets this far: > > Building encoding-0.4... > [ 7 of 37] Compiling Data.Encoding.CP1258 ( Data/Encoding/CP1258.hs, > dist/build/Data/Encoding/CP1258.o ) > Loading package base ... linking ... done. > Loading package pretty-1.0.0.0 ... linking ... done. > Loading package array-0.1.0.0 ... linking ... done. > Loading package packedstring-0.1.0.0 ... linking ... done. > Loading package containers-0.1.0.1 ... linking ... done. > Loading package template-haskell ... linking ... done. > Loading package bytestring-0.9.0.1 ... linking ... done. > ghc-6.8.2: internal error: loadObj: can't map > `dist/build/Data/Encoding/Helper/Template.o' > (GHC version 6.8.2 for i386_unknown_linux) > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug New description: It gets this far: {{{ Building encoding-0.4... [ 7 of 37] Compiling Data.Encoding.CP1258 ( Data/Encoding/CP1258.hs, dist/build/Data/Encoding/CP1258.o ) Loading package base ... linking ... done. Loading package pretty-1.0.0.0 ... linking ... done. Loading package array-0.1.0.0 ... linking ... done. Loading package packedstring-0.1.0.0 ... linking ... done. Loading package containers-0.1.0.1 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package bytestring-0.9.0.1 ... linking ... done. ghc-6.8.2: internal error: loadObj: can't map `dist/build/Data/Encoding/Helper/Template.o' (GHC version 6.8.2 for i386_unknown_linux) 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 Apr 25 08:45:14 2008 From: trac at galois.com (GHC) Date: Fri Apr 25 08:39:56 2008 Subject: [GHC] #2225: hackage library encoding-0.4 crashes ghc 6.8.2 In-Reply-To: <044.e9d9476ef5821d5acc4a3c27e27ec664@localhost> References: <044.e9d9476ef5821d5acc4a3c27e27ec664@localhost> Message-ID: <053.39a942a039027b01c5ffb2fa308d4481@localhost> #2225: hackage library encoding-0.4 crashes ghc 6.8.2 ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * difficulty: => Unknown Comment: Also reported as #2229. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 25 08:53:14 2008 From: trac at galois.com (GHC) Date: Fri Apr 25 08:47:57 2008 Subject: [GHC] #2225: hackage library encoding-0.4 crashes ghc 6.8.2 In-Reply-To: <044.e9d9476ef5821d5acc4a3c27e27ec664@localhost> References: <044.e9d9476ef5821d5acc4a3c27e27ec664@localhost> Message-ID: <053.6942ae358c50585adb35e328901ea38e@localhost> #2225: hackage library encoding-0.4 crashes ghc 6.8.2 ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * milestone: => 6.8.3 Comment: Thanks for the report; can you please tell us what {{{ ghc --info }}} says? Also, does `dist/build/Data/Encoding/Helper/Template.o` exist? And what does this do? {{{ ghci -package template-haskell dist/build/Data/Encoding/Helper/Template.o }}} I can't reproduce the problem: {{{ $ uname -a Linux matrix 2.6.18-4-amd64 #1 SMP Fri May 4 00:37:33 UTC 2007 i686 GNU/Linux $ runghc Setup.hs configure Configuring encoding-0.4... Warning: No license-file field. $ runghc Setup.hs build Preprocessing library encoding-0.4... Building encoding-0.4... [ 1 of 37] Compiling Data.Encoding.Helper.Template ( Data/Encoding/Helper/Templa te.hs, dist/build/Data/Encoding/Helper/Template.o ) [ 2 of 37] Compiling Data.Encoding.GB18030Data ( Data/Encoding/GB18030Data.hs, d ist/build/Data/Encoding/GB18030Data.o ) [ 3 of 37] Compiling Data.Encoding.Base ( Data/Encoding/Base.hs, dist/build/Data /Encoding/Base.o ) [ 4 of 37] Compiling Data.Encoding.GB18030 ( Data/Encoding/GB18030.hs, dist/buil d/Data/Encoding/GB18030.o ) [ 5 of 37] Compiling Data.Encoding.KOI8U ( Data/Encoding/KOI8U.hs, dist/build/Da ta/Encoding/KOI8U.o ) [ 6 of 37] Compiling Data.Encoding.KOI8R ( Data/Encoding/KOI8R.hs, dist/build/Da ta/Encoding/KOI8R.o ) [ 7 of 37] Compiling Data.Encoding.CP1258 ( Data/Encoding/CP1258.hs, dist/build/ Data/Encoding/CP1258.o ) Loading package base ... linking ... done. Loading package pretty-1.0.0.0 ... linking ... done. Loading package array-0.1.0.0 ... linking ... done. Loading package packedstring-0.1.0.0 ... linking ... done. Loading package containers-0.1.0.1 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package bytestring-0.9.0.1 ... linking ... done. [ 8 of 37] Compiling Data.Encoding.CP1257 ( Data/Encoding/CP1257.hs, dist/build/ Data/Encoding/CP1257.o ) [...] }}} Can anyone else? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 25 08:55:34 2008 From: trac at galois.com (GHC) Date: Fri Apr 25 08:50:19 2008 Subject: [GHC] #2237: qualified names not permitted everywhere in instances In-Reply-To: <044.979df1df57c1530008974aa6ad0b7805@localhost> References: <044.979df1df57c1530008974aa6ad0b7805@localhost> Message-ID: <053.fbee38201f00ac755646fca0c7db4455@localhost> #2237: qualified names not permitted everywhere in instances -------------------------------+-------------------------------------------- Reporter: claus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Comment (by simonpj): GHC is faithfully implementing Section 4.3.2 of the Haskell Report. You nay not like it, but that's what it's doing. I think. If, having read the section (esp the sentence "This rule is identical to...") then get back to me. S -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 25 09:02:36 2008 From: trac at galois.com (GHC) Date: Fri Apr 25 08:57:20 2008 Subject: [GHC] #2226: duplicate samples in heap profiling (-hc) output on 6.8.2 In-Reply-To: <046.1e179a2ccae41d3a00bbbbb417b91596@localhost> References: <046.1e179a2ccae41d3a00bbbbb417b91596@localhost> Message-ID: <055.756fa4282461153faf5c0e0a349cd239@localhost> #2226: duplicate samples in heap profiling (-hc) output on 6.8.2 -----------------------+---------------------------------------------------- Reporter: clemens | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Profiling | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Unknown | -----------------------+---------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.8.3 Comment: Can you please give us complete reproduction instructions, i.e. tell us exactly what code you are using, and what flags you are compiling and running with? (ideally in a way that doesn't need us to use xmonad as our actual window manager!) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 25 12:02:25 2008 From: trac at galois.com (GHC) Date: Fri Apr 25 11:57:07 2008 Subject: [GHC] #2237: qualified names not permitted everywhere in instances In-Reply-To: <044.979df1df57c1530008974aa6ad0b7805@localhost> References: <044.979df1df57c1530008974aa6ad0b7805@localhost> Message-ID: <053.33ab25831399efc1b00f8524edf78544@localhost> #2237: qualified names not permitted everywhere in instances -------------------------------+-------------------------------------------- Reporter: claus | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Parser) | Version: 6.9 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => invalid Comment: OK I think we are agreeing that GHC implements the spec. We can argue separately about whether the language should be changed! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 25 13:52:59 2008 From: trac at galois.com (GHC) Date: Fri Apr 25 13:47:42 2008 Subject: [GHC] #2237: qualified names not permitted everywhere in instances In-Reply-To: <044.979df1df57c1530008974aa6ad0b7805@localhost> References: <044.979df1df57c1530008974aa6ad0b7805@localhost> Message-ID: <053.ab3debca61562535e028bbbe18966b07@localhost> #2237: qualified names not permitted everywhere in instances -------------------------------+-------------------------------------------- Reporter: claus | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Parser) | Version: 6.9 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Comment (by claus): Replying to [comment:4 simonpj]: > OK I think we are agreeing that GHC implements the spec. We can argue separately about whether the language should be changed! yes, agreed. one suggestion: could GHC point to the spec for this error message in the case of an instance method definition? something like {{{ Qualified name in instance method definition: .. please refer to Section 4.3.2 of the Haskell 98 report }}} as part of the message would have spared me the confusion, by pointing out that (a) the compiler is aware of the non-toplevel context and (b) there is a spec reason for the restriction. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 25 14:59:59 2008 From: trac at galois.com (GHC) Date: Fri Apr 25 14:54:49 2008 Subject: [GHC] #2240: Random "interface file corrupt" while building Message-ID: <044.8830de44dcf6496f1725044215132bc4@localhost> #2240: Random "interface file corrupt" while building -----------------------+---------------------------------------------------- Reporter: ryani | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: Windows -----------------------+---------------------------------------------------- I don't have a repro case for this right now; I'll try get my code back to the state that caused the problem. I was getting random ".hi file corrupt/magic number mismatch" errors about a module I was importing during a single file compile; sometimes it would give me that error, sometimes it would compile successfully. Rebuilding the module being complained about didn't seem to have an effect. GHC6.8.2 on WinXP/x86. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 25 16:25:46 2008 From: trac at galois.com (GHC) Date: Fri Apr 25 16:21:03 2008 Subject: [GHC] #1958: collect2: ld terminated with signal 10 [Bus error]: Building parsec on a PPC Mac OS X 10.5 Leopard as part of GHC 6.9 In-Reply-To: <050.c31695132cb1b93380c95a8b6c208782@localhost> References: <050.c31695132cb1b93380c95a8b6c208782@localhost> Message-ID: <059.aa83bac8b32b40e6369e8c90c785b336@localhost> #1958: collect2: ld terminated with signal 10 [Bus error]: Building parsec on a PPC Mac OS X 10.5 Leopard as part of GHC 6.9 -------------------------+-------------------------------------------------- Reporter: thorkilnaur | Owner: thorkilnaur Type: bug | Status: new Priority: high | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | -------------------------+-------------------------------------------------- Comment (by malcolm.wallace@cs.york.ac.uk): I got this error today {{{ collect2: ld terminated with signal 10 [Bus error] }}} whilst attempting to build the gtk2hs package for ghc-6.8.2. My machine is a PowerPC, running Leopard 10.5.2, and the ghc is the one from the ghc binary download page for powerpc-tiger. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 25 17:23:51 2008 From: trac at galois.com (GHC) Date: Fri Apr 25 17:18:40 2008 Subject: [GHC] #2240: Random "interface file corrupt" while building In-Reply-To: <044.8830de44dcf6496f1725044215132bc4@localhost> References: <044.8830de44dcf6496f1725044215132bc4@localhost> Message-ID: <053.84b586f7b77c7e0a4fa9f81426391ade@localhost> #2240: Random "interface file corrupt" while building ----------------------+----------------------------------------------------- Reporter: ryani | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------+----------------------------------------------------- Changes (by simonmar): * difficulty: => Unknown * milestone: => _|_ Comment: We've seen this too. Unfortunately I've been unable to reliably reproduce it, and I've eyeballed the code and can't figure out how it is happening. So thanks for submitting the bug, however I think we'll have to leave this at milestone _|_ until we can find a way to track it down. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 25 20:36:31 2008 From: trac at galois.com (GHC) Date: Fri Apr 25 20:31:12 2008 Subject: [GHC] #2199: th32SnapEnumProcesses in System.Win32.Process prints debugging information to stdout In-Reply-To: <044.b8fbd1c67ea8e923433d5eaf1eaa88db@localhost> References: <044.b8fbd1c67ea8e923433d5eaf1eaa88db@localhost> Message-ID: <053.8040d26352447245575d26eafda1a90e@localhost> #2199: th32SnapEnumProcesses in System.Win32.Process prints debugging information to stdout -----------------------------------+---------------------------------------- Reporter: guest | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: th32SnapEnumProcesses | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Windows | -----------------------------------+---------------------------------------- Changes (by igloo): * type: bug => merge * milestone: => 6.8.3 Comment: {{{ Fri Apr 25 06:10:30 PDT 2008 Ian Lynagh * Remove debugging prints that were accidentally left in }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 25 20:38:37 2008 From: trac at galois.com (GHC) Date: Fri Apr 25 20:33:17 2008 Subject: [GHC] #2230: ghci crashes with .o mismatches In-Reply-To: <044.be341cfd46c6613b9f91a7d73d3966e2@localhost> References: <044.be341cfd46c6613b9f91a7d73d3966e2@localhost> Message-ID: <053.fd226c5dbd986cbfc3b47761a7a96b28@localhost> #2230: ghci crashes with .o mismatches ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * difficulty: => Unknown Old description: > Basic recipe is: > > 1) have multi-file program, compile with ghc --make (this creates some .o > files in course of compilation) > > 2) edit some files and then run ghci and attempt to load main file with > :l file.hs > > 3) ghci tries to load some of the compiled .o files, and crashes. > > Workaround is to delete the .o's before running ghci. > > > Loading package binary-0.4.2 ... linking ... done. > : internal error: loadObj: can't map `Records.o' > (GHC version 6.8.2 for i386_unknown_linux) > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > Aborted (core dumped) New description: Basic recipe is: 1) have multi-file program, compile with ghc --make (this creates some .o files in course of compilation) 2) edit some files and then run ghci and attempt to load main file with :l file.hs 3) ghci tries to load some of the compiled .o files, and crashes. Workaround is to delete the .o's before running ghci. {{{ Loading package binary-0.4.2 ... linking ... done. : internal error: loadObj: can't map `Records.o' (GHC version 6.8.2 for i386_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 25 20:46:11 2008 From: trac at galois.com (GHC) Date: Fri Apr 25 20:40:52 2008 Subject: [GHC] #2230: ghci crashes with .o mismatches In-Reply-To: <044.be341cfd46c6613b9f91a7d73d3966e2@localhost> References: <044.be341cfd46c6613b9f91a7d73d3966e2@localhost> Message-ID: <053.245b339a6c75ceb75ff8af6760b1331d@localhost> #2230: ghci crashes with .o mismatches ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: worksforme Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => worksforme Comment: This works for me. If you can reproduce it, please reopen this bug and attach example code and some instructions that demonstrate the bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 25 20:47:28 2008 From: trac at galois.com (GHC) Date: Fri Apr 25 20:42:10 2008 Subject: [GHC] #2234: Profiled binaries create empty files In-Reply-To: <044.7102554d75e5a8588c921a04c46a11b1@localhost> References: <044.7102554d75e5a8588c921a04c46a11b1@localhost> Message-ID: <053.b66539aa7704a89eccd689c2f5d8025b@localhost> #2234: Profiled binaries create empty files ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * difficulty: => Unknown Old description: > gwern@localhost:1891~>ghc --version > [ 1:20PM] > > The Glorious Glasgow Haskell Compilation System, version 6.8.2 > > I recently happened to go through the effort to build a copy of Darcs > with profiling enabled (to profile, obviously), and while the profiling > runs were quite as helpful as I could've wished, I've since noticed > something very annoying: > > gwern@localhost:1922~>~/bin/bin/darcs whatsnew > [ 1:35PM] > > No changes! > > gwern@localhost:1923~>cat darcs.prof > [ 1:36PM] > > gwern@localhost:1924~>ls > [ 1:36PM] > > bin/ _darcs/ darcs.prof hacryptopp/ hiersort/ hope/ idris/ > ivor/ par-gc-ismm08.pdf pics2/ torrent/ > > Note the complete lack of any +RTS-RTS flags; nevertheless, an annoying > empty file has been created to clutter up my home directory. And deleting > it is pointless since it'll just get created. Even worse, this stupid > file will appear anywhere I use the profiled darcs (at last count, > slocate knew of at least 12 such darcs.prof). And since my system is set > up for profiling, it'll only get worse as more and more binaries get > built for profiling. > > I understand from Igloo there's some vague user-friendliness rationale > behind GHC's littering, but I'm skeptical that this is really the best > way to go about matters. > > -- > gwern New description: {{{ gwern@localhost:1891~>ghc --version [ 1:20PM] The Glorious Glasgow Haskell Compilation System, version 6.8.2 }}} I recently happened to go through the effort to build a copy of Darcs with profiling enabled (to profile, obviously), and while the profiling runs were quite as helpful as I could've wished, I've since noticed something very annoying: {{{ gwern@localhost:1922~>~/bin/bin/darcs whatsnew [ 1:35PM] No changes! gwern@localhost:1923~>cat darcs.prof [ 1:36PM] gwern@localhost:1924~>ls [ 1:36PM] bin/ _darcs/ darcs.prof hacryptopp/ hiersort/ hope/ idris/ ivor/ par-gc-ismm08.pdf pics2/ torrent/ }}} Note the complete lack of any +RTS-RTS flags; nevertheless, an annoying empty file has been created to clutter up my home directory. And deleting it is pointless since it'll just get created. Even worse, this stupid file will appear anywhere I use the profiled darcs (at last count, slocate knew of at least 12 such darcs.prof). And since my system is set up for profiling, it'll only get worse as more and more binaries get built for profiling. I understand from Igloo there's some vague user-friendliness rationale behind GHC's littering, but I'm skeptical that this is really the best way to go about matters. -- gwern -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 25 20:48:14 2008 From: trac at galois.com (GHC) Date: Fri Apr 25 20:42:55 2008 Subject: [GHC] #2231: GHC RTS Segfault In-Reply-To: <044.d4bb1e8e3d1948707d5b62e9fdca3bb9@localhost> References: <044.d4bb1e8e3d1948707d5b62e9fdca3bb9@localhost> Message-ID: <053.8efb7b9b063043f8f3ae4e9d6b054793@localhost> #2231: GHC RTS Segfault ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------------+----------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 25 21:31:16 2008 From: trac at galois.com (GHC) Date: Fri Apr 25 21:25:58 2008 Subject: [GHC] #2238: panic nameModule tpl_B1{v} In-Reply-To: <044.2c7ef9e7b09c867edd5544536ef8fbf1@localhost> References: <044.2c7ef9e7b09c867edd5544536ef8fbf1@localhost> Message-ID: <053.5a1ca0fcc1d83359d9970f47ff8fdeb6@localhost> #2238: panic nameModule tpl_B1{v} ----------------------+----------------------------------------------------- Reporter: claus | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch Comment: Thanks for the report. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Apr 26 06:50:28 2008 From: trac at galois.com (GHC) Date: Sat Apr 26 06:45:09 2008 Subject: [GHC] #2241: unknown epilogue mangling, WARNING: Epilogue junk Message-ID: <044.0ef05bf90ce4d790f040426b074d4277@localhost> #2241: unknown epilogue mangling, WARNING: Epilogue junk -------------------------+-------------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- At some point (before the 10th Apr) we started getting epilogue junk in the HEAD, e.g.: {{{ ../compiler/ghc-inplace -Werror -H64m -Onot -fasm -optc-O2 -I../includes -I. -Iparallel -Ism -DCOMPILING_RTS -package-name rts -fvia-C -static -I../gmp/gmpbuild -I../libffi/build/include -I. -dcmm-lint -c Apply.cmm -o Apply.o ghc-asm: unknown epilogue mangling? x86_64-unknown-linux WARNING: Epilogue junk?: addq $8, %rsp ret .size stg_PAP_entry, .-stg_PAP_entry .p2align 4,,15 .globl stg_PAP_apply .type stg_PAP_apply, @function }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Apr 26 13:42:04 2008 From: trac at galois.com (GHC) Date: Sat Apr 26 13:36:45 2008 Subject: [GHC] #2239: lack of improvement/reduction with TFs In-Reply-To: <044.40f3b78a317b6571e596e1e3328f356b@localhost> References: <044.40f3b78a317b6571e596e1e3328f356b@localhost> Message-ID: <053.b7bd36492da5d08fa82d5fd9a38a4281@localhost> #2239: lack of improvement/reduction with TFs -------------------------------------+-------------------------------------- Reporter: claus | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: TF vs FD | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch Comment: Thanks for the report. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Apr 26 13:44:47 2008 From: trac at galois.com (GHC) Date: Sat Apr 26 13:39:29 2008 Subject: [GHC] #2236: Deep stacks make execution time go through the roof In-Reply-To: <046.3a0daf0dccbb67382aad82aeb994d473@localhost> References: <046.3a0daf0dccbb67382aad82aeb994d473@localhost> Message-ID: <055.ea866047d7352452c4f1e6025e600c4c@localhost> #2236: Deep stacks make execution time go through the roof --------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------------------+------------------------------------- Changes (by igloo): * milestone: => 6.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Apr 26 13:45:23 2008 From: trac at galois.com (GHC) Date: Sat Apr 26 13:40:02 2008 Subject: [GHC] #2235: Bogus occurs check with type families In-Reply-To: <046.5974fa5687299769939135165fbad968@localhost> References: <046.5974fa5687299769939135165fbad968@localhost> Message-ID: <055.f41bfe80f1ee94471d8f5b8d1b5959dd@localhost> #2235: Bogus occurs check with type families ----------------------+----------------------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * milestone: => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Apr 26 13:47:37 2008 From: trac at galois.com (GHC) Date: Sat Apr 26 13:42:16 2008 Subject: [GHC] #2234: Profiled binaries create empty files In-Reply-To: <044.7102554d75e5a8588c921a04c46a11b1@localhost> References: <044.7102554d75e5a8588c921a04c46a11b1@localhost> Message-ID: <053.2210cc486bc2a34835d7f00184409e99@localhost> #2234: Profiled binaries create empty files ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * milestone: => 6.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Apr 26 14:19:21 2008 From: trac at galois.com (GHC) Date: Sat Apr 26 14:14:00 2008 Subject: [GHC] #2228: runghc screws up terminal buffering mode and doesn't reset it In-Reply-To: <044.5a9b5cb0e6f9fbb1f5c64639b7a5180d@localhost> References: <044.5a9b5cb0e6f9fbb1f5c64639b7a5180d@localhost> Message-ID: <053.ab10b6c15c71f34c79ef11df6729d04e@localhost> #2228: runghc screws up terminal buffering mode and doesn't reset it --------------------+------------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: GHCi | Version: 6.8.2 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | --------------------+------------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.8.3 Comment: I can't reproduce this. Both before and after I get {{{ $ stty -a speed 38400 baud; rows 24; columns 80; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0; -parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany -imaxbel iutf8 opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke }}} (amd64/Linux, with Debian's 6.8.2-4). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Apr 26 14:43:26 2008 From: trac at galois.com (GHC) Date: Sat Apr 26 14:38:06 2008 Subject: [GHC] #2234: Profiled binaries create empty files In-Reply-To: <044.7102554d75e5a8588c921a04c46a11b1@localhost> References: <044.7102554d75e5a8588c921a04c46a11b1@localhost> Message-ID: <053.f1a71c3488275c47548c69729bb130d9@localhost> #2234: Profiled binaries create empty files ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: low | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * priority: normal => low Comment: I'm not sure exactly what the test for whether or not we need to open the file would be. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Apr 26 15:23:34 2008 From: trac at galois.com (GHC) Date: Sat Apr 26 15:18:13 2008 Subject: [GHC] #2231: GHC RTS Segfault In-Reply-To: <044.d4bb1e8e3d1948707d5b62e9fdca3bb9@localhost> References: <044.d4bb1e8e3d1948707d5b62e9fdca3bb9@localhost> Message-ID: <053.7b1e259f0ab4320caf823e804a765919@localhost> #2231: GHC RTS Segfault ----------------------------+----------------------------------------------- Reporter: guest | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------------+----------------------------------------------- Changes (by igloo): * owner: => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Apr 26 15:25:30 2008 From: trac at galois.com (GHC) Date: Sat Apr 26 15:20:09 2008 Subject: [GHC] #2226: duplicate samples in heap profiling (-hc) output on 6.8.2 In-Reply-To: <046.1e179a2ccae41d3a00bbbbb417b91596@localhost> References: <046.1e179a2ccae41d3a00bbbbb417b91596@localhost> Message-ID: <055.9b5de711a74d3238de4aef9fb0e2aab2@localhost> #2226: duplicate samples in heap profiling (-hc) output on 6.8.2 -----------------------+---------------------------------------------------- Reporter: clemens | Owner: Type: bug | Status: new Priority: lowest | Milestone: 6.8.3 Component: Profiling | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Unknown | -----------------------+---------------------------------------------------- Changes (by igloo): * priority: normal => lowest Comment: Priority => lowest while we're waiting for more info -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Apr 26 15:25:59 2008 From: trac at galois.com (GHC) Date: Sat Apr 26 15:20:38 2008 Subject: [GHC] #2225: hackage library encoding-0.4 crashes ghc 6.8.2 In-Reply-To: <044.e9d9476ef5821d5acc4a3c27e27ec664@localhost> References: <044.e9d9476ef5821d5acc4a3c27e27ec664@localhost> Message-ID: <053.1c154fb780db8de693fd5dd4717e8803@localhost> #2225: hackage library encoding-0.4 crashes ghc 6.8.2 ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: lowest | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * priority: normal => lowest Comment: Priority => lowest while we're waiting for more info -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Apr 26 16:57:18 2008 From: trac at galois.com (GHC) Date: Sat Apr 26 16:51:56 2008 Subject: [GHC] #2198: Build failure on Mac OS X Tiger Intel In-Reply-To: <044.e669693b0e2d8babbb9829cda3557205@localhost> References: <044.e669693b0e2d8babbb9829cda3557205@localhost> Message-ID: <053.fa83b5086bafc1b96275eb1875164b81@localhost> #2198: Build failure on Mac OS X Tiger Intel --------------------------+------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.8.3 Component: Build System | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | --------------------------+------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Thanks for the report. Happily, from http://www.haskell.org/pipermail /glasgow-haskell-users/2008-April/014661.html it sounds like this bug has already been fixed by {{{ [pass -no-user-package-conf to ghc-inplace Simon Marlow **20080104162840] { }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Apr 26 17:19:17 2008 From: trac at galois.com (GHC) Date: Sat Apr 26 17:13:59 2008 Subject: [GHC] #2242: review and apply small patch removing no longer existing modules from ghc package db Message-ID: <048.7571d8417ac796999235d29ed6043af6@localhost> #2242: review and apply small patch removing no longer existing modules from ghc package db --------------------------+------------------------------------------------- Reporter: MarcWeber | Owner: Type: task | Status: new Priority: normal | Component: Build System Version: 6.8.2 | Severity: minor Keywords: | Testcase: Architecture: Unknown | Os: Unknown --------------------------+------------------------------------------------- See patch description -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Apr 26 17:20:20 2008 From: trac at galois.com (GHC) Date: Sat Apr 26 17:15:00 2008 Subject: [GHC] #2243: review and apply small patch removing no longer existing modules from ghc package db Message-ID: <048.1c657e7d878b9e4b4af84a238ffbca14@localhost> #2243: review and apply small patch removing no longer existing modules from ghc package db --------------------------+------------------------------------------------- Reporter: MarcWeber | Owner: Type: task | Status: new Priority: normal | Component: Build System Version: 6.8.2 | Severity: minor Keywords: | Testcase: Architecture: Unknown | Os: Unknown --------------------------+------------------------------------------------- See patch description. Another small hasktags patch making it find more tags is included as well -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Apr 26 18:50:43 2008 From: trac at galois.com (GHC) Date: Sat Apr 26 18:45:22 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.0f668ef82609073bc02b09072938129a@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: low | Milestone: 6.8.3 Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: hsetbuffering buffering buffer | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | --------------------------------------------+------------------------------- Changes (by igloo): * priority: normal => low Comment: OK, I can reproduce the problem. At the Haskell level the problem is that asyncRead# isn't returning when a key is pressed; I haven't followed all the RTS stuff through to see where it goes wrong. Could be related to #806. I doubt we'll get to this for 6.8.3, so I'm marking it as low priority. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Apr 26 19:18:47 2008 From: trac at galois.com (GHC) Date: Sat Apr 26 19:13:36 2008 Subject: [GHC] #2186: unsafePerformIO prevents space leak? In-Reply-To: <043.a1d3979db09afe9cd755cca819ea107a@localhost> References: <043.a1d3979db09afe9cd755cca819ea107a@localhost> Message-ID: <052.f19c46917f502edd1e051f3a1e868454@localhost> #2186: unsafePerformIO prevents space leak? ----------------------+----------------------------------------------------- Reporter: ravi | Owner: Type: bug | Status: new Priority: lowest | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Linux | ----------------------+----------------------------------------------------- Changes (by igloo): * priority: normal => lowest Comment: (waiting for response) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Apr 26 19:21:00 2008 From: trac at galois.com (GHC) Date: Sat Apr 26 19:15:41 2008 Subject: [GHC] #2242: review and apply small patch removing no longer existing modules from ghc package db In-Reply-To: <048.7571d8417ac796999235d29ed6043af6@localhost> References: <048.7571d8417ac796999235d29ed6043af6@localhost> Message-ID: <057.926b1f0d2a56b416590296ba12a46c3e@localhost> #2242: review and apply small patch removing no longer existing modules from ghc package db -----------------------------+---------------------------------------------- Reporter: MarcWeber | Owner: Type: task | Status: closed Priority: normal | Milestone: Component: Build System | Version: 6.8.2 Severity: minor | Resolution: duplicate Keywords: | Testcase: Architecture: Unknown | Os: Unknown -----------------------------+---------------------------------------------- Changes (by MarcWeber): * status: new => closed * resolution: => duplicate -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Apr 26 20:09:16 2008 From: trac at galois.com (GHC) Date: Sat Apr 26 20:04:00 2008 Subject: [GHC] #2171: Parallel program crashes In-Reply-To: <042.91539dd5667f046cb861faa36a106615@localhost> References: <042.91539dd5667f046cb861faa36a106615@localhost> Message-ID: <051.e0efcdb79b4b973925c6e141654fc112@localhost> #2171: Parallel program crashes ---------------------------------------------+------------------------------ Reporter: fed | Owner: Type: bug | Status: new Priority: lowest | Milestone: 6.8.3 Component: Runtime System | Version: 6.8.2 Severity: critical | Resolution: Keywords: parallel, crash, race condition | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ---------------------------------------------+------------------------------ Changes (by igloo): * priority: normal => lowest Comment: (waiting for response) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Apr 26 20:13:53 2008 From: trac at galois.com (GHC) Date: Sat Apr 26 20:08:31 2008 Subject: [GHC] #2169: Compilation fails first time without giving an error, later succeeds without changing code In-Reply-To: <043.846fc3dda75c676953124f0b37d400e0@localhost> References: <043.846fc3dda75c676953124f0b37d400e0@localhost> Message-ID: <052.32da5da83a00fff4e6a4651b0fb6735f@localhost> #2169: Compilation fails first time without giving an error, later succeeds without changing code ----------------------+----------------------------------------------------- Reporter: nccb | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------+----------------------------------------------------- Changes (by igloo): * milestone: 6.8.3 => _|_ Comment: We really can't do anything about this without a way to reproduce it, so I'm putting it in the _|_ milestone. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Apr 27 07:04:50 2008 From: trac at galois.com (GHC) Date: Sun Apr 27 06:59:34 2008 Subject: [GHC] #2134: Intermittent file locking bug in installPackage.hs In-Reply-To: <041.defdf7e8a14c6388acd7b4588b2e7fd6@localhost> References: <041.defdf7e8a14c6388acd7b4588b2e7fd6@localhost> Message-ID: <050.d9a07679088be09e82064f36c390b669@localhost> #2134: Intermittent file locking bug in installPackage.hs -------------------------------+-------------------------------------------- Reporter: gw | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: libraries (other) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Changes (by igloo): * cc: duncan.coutts@worc.ox.ac.uk (added) Comment: It looks like we need to merge {{{ [fix 'clean' bug on windows caused by leaked Handle. Andrea Vezzosi **20080318161237 Using readFile to read dist/setup-config keeps the Handle open when we try to delete the file, causing an error. So we instead read the file strictly and close the Handle early. }}} but I'm not sure which Cabal repo it should be merged into. Duncan? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Apr 27 07:20:58 2008 From: trac at galois.com (GHC) Date: Sun Apr 27 07:15:38 2008 Subject: [GHC] #2129: runInteractiveCommand/Process docs don't mention if handles are text or binary In-Reply-To: <045.fab4515899caecbd52d0aae843491315@localhost> References: <045.fab4515899caecbd52d0aae843491315@localhost> Message-ID: <054.51d7282a7b172bc88a06ea749498cd79@localhost> #2129: runInteractiveCommand/Process docs don't mention if handles are text or binary -------------------------------+-------------------------------------------- Reporter: duncan | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: libraries/process | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | -------------------------------+-------------------------------------------- Changes (by igloo): * owner: => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Apr 27 08:33:33 2008 From: trac at galois.com (GHC) Date: Sun Apr 27 08:28:39 2008 Subject: [GHC] #2036: Show for Double and Float doesn't use parenthesis for negative zero. In-Reply-To: <047.9085fb42c7e7997d5332318ebe9470cc@localhost> References: <047.9085fb42c7e7997d5332318ebe9470cc@localhost> Message-ID: <056.f301cb40eae474edf2a00383ca5410c4@localhost> #2036: Show for Double and Float doesn't use parenthesis for negative zero. ---------------------------------+------------------------------------------ Reporter: clanehin | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: libraries/haskell98 | Version: 6.6.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * owner: => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Apr 27 08:38:03 2008 From: trac at galois.com (GHC) Date: Sun Apr 27 08:32:48 2008 Subject: [GHC] #2025: supply a testsuite archive together with a source release (for ghc-6.8.3) In-Reply-To: <045.0e8ff99e04b969df257e0d8f895be8f0@localhost> References: <045.0e8ff99e04b969df257e0d8f895be8f0@localhost> Message-ID: <054.f59e37c49ae83576a6676af41b1d42bf@localhost> #2025: supply a testsuite archive together with a source release (for ghc-6.8.3) -----------------------------+---------------------------------------------- Reporter: maeder | Owner: Type: feature request | Status: new Priority: low | Milestone: 6.8.3 Component: Build System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Multiple Os: Multiple | -----------------------------+---------------------------------------------- Changes (by igloo): * priority: normal => low Comment: We'll do this just after the release. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Apr 27 08:57:15 2008 From: trac at galois.com (GHC) Date: Sun Apr 27 08:51:53 2008 Subject: [GHC] #2052: hpc ignores files containing LINES pragmas that refer to .hsc files In-Reply-To: <043.13a31077ae5ebb133355743a92fc5086@localhost> References: <043.13a31077ae5ebb133355743a92fc5086@localhost> Message-ID: <052.33b1ac1e896cac228cb2cb34735ee6b7@localhost> #2052: hpc ignores files containing LINES pragmas that refer to .hsc files ---------------------------+------------------------------------------------ Reporter: dons | Owner: AndyGill Type: bug | Status: assigned Priority: normal | Milestone: 6.8.3 Component: Code Coverage | Version: 6.8.2 Severity: normal | Resolution: Keywords: hpc, hsc2hs | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ---------------------------+------------------------------------------------ Comment (by igloo): Hmm; you can generate the ticks and report percentages at least, I'd have thought? While this isn't ideal, it's better than nothing. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Apr 27 09:57:43 2008 From: trac at galois.com (GHC) Date: Sun Apr 27 09:52:22 2008 Subject: [GHC] #2039: Using GHC 6.8.2 as a library does not work well under Windows in GHCi In-Reply-To: <051.1396b5ecbcb18e529c703113b3b39dd0@localhost> References: <051.1396b5ecbcb18e529c703113b3b39dd0@localhost> Message-ID: <060.1778397a3b64923b75bd9df5861fdc23@localhost> #2039: Using GHC 6.8.2 as a library does not work well under Windows in GHCi ----------------------------------------------------------+----------------- Reporter: PVerswyvelen | Owner: Type: bug | Status: new Priority: lowest | Milestone: 6.8.3 Component: GHC API | Version: 6.8.2 Severity: major | Resolution: Keywords: GHC API GHCi runtime linker duplicate symbol | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------------------------------------------+----------------- Changes (by igloo): * priority: normal => lowest Comment: I can't reproduce this (with ghci or ghcii.sh, under cmd, msys or cygwin), e.g.: {{{ $ ghcii.sh -package ghc q.hs GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Loading package old-locale-1.0.0.0 ... linking ... done. Loading package old-time-1.0.0.0 ... linking ... done. Loading package filepath-1.1.0.0 ... linking ... done. Loading package directory-1.0.0.0 ... linking ... done. Loading package array-0.1.0.0 ... linking ... done. Loading package containers-0.1.0.1 ... linking ... done. Loading package hpc-0.5.0.0 ... linking ... done. Loading package bytestring-0.9.0.1 ... linking ... done. Loading package pretty-1.0.0.0 ... linking ... done. Loading package packedstring-0.1.0.0 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package Win32-2.1.1.0 ... linking ... done. Loading package process-1.0.0.0 ... linking ... done. Loading package Cabal-1.2.3.0 ... linking ... done. Loading package random-1.0.0.0 ... linking ... done. Loading package haskell98 ... linking ... done. Loading package ghc-6.8.2 ... linking ... done. [1 of 1] Compiling Main ( q.hs, interpreted ) Ok, modules loaded: Main. *Main> main 4 *Main> :q Leaving GHCi. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Apr 27 11:41:20 2008 From: trac at galois.com (GHC) Date: Sun Apr 27 11:35:57 2008 Subject: [GHC] #1944: round function causes cblas NaNs In-Reply-To: <052.7827d863c451a2b4d8c8af2c2416f81c@localhost> References: <052.7827d863c451a2b4d8c8af2c2416f81c@localhost> Message-ID: <061.7942f7e941355c155852aac2cf982e71@localhost> #1944: round function causes cblas NaNs ---------------------------+------------------------------------------------ Reporter: SevenThunders | Owner: Type: bug | Status: new Priority: low | Milestone: 6.8.3 Component: Compiler | Version: 6.8.1 Severity: critical | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ---------------------------+------------------------------------------------ Changes (by igloo): * priority: normal => low Comment: We are unlikely to get to this in time for 6.8.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Apr 27 12:06:51 2008 From: trac at galois.com (GHC) Date: Sun Apr 27 12:01:26 2008 Subject: [GHC] #1874: getDirectoryContents yields "invalid argument" instead of "permission error" In-Reply-To: <044.aea88e13611e8c8d6805f551748c45bd@localhost> References: <044.aea88e13611e8c8d6805f551748c45bd@localhost> Message-ID: <053.ac0e44fc9f80dcc4550e8eea8afc11e8@localhost> #1874: getDirectoryContents yields "invalid argument" instead of "permission error" ------------------------------------------------------------------+--------- Reporter: Orphi | Owner: Type: bug | Status: new Priority: lowest | Milestone: 6.8.3 Component: libraries/directory | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: getDirectoryContents "C:\\System Volume Information" | Architecture: x86 Os: Windows | ------------------------------------------------------------------+--------- Changes (by igloo): * priority: normal => lowest Comment: I can't get any exception at all out of getDirectoryContents on Windows. {{{ $ cat q.hs module Main (main) where import Control.Exception import Prelude hiding (catch) import System.Directory main :: IO () main = do (readFile "c:\\cygwin\\tmp\\ian\\noperm" >> return ()) `catch` print (getDirectoryContents "c:\\cygwin\\tmp\\ian\\npd" >> return ()) `catch` print putStrLn "Foo" }}} {{{ $ ls -l total 643 ---------- 1 ian None 0 Apr 27 16:57 noperm d---------+ 2 ian None 0 Apr 27 16:57 npd -rwxr-xr-x 1 ian None 644760 Apr 27 16:59 q.exe -rwxr-xr-x 1 ian None 498 Apr 27 16:59 q.exe.manifest -rwxr-xr-x 1 ian None 305 Apr 27 16:57 q.hi -rw-r--r-- 1 ian None 324 Apr 27 16:59 q.hs -rwxr-xr-x 1 ian None 5494 Apr 27 16:59 q.o }}} {{{ $ ./q.exe c:\cygwin\tmp\ian\noperm: openFile: permission denied (Permission denied) Foo }}} Can anyone tell me how I can reproduce the problem please? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Apr 27 12:09:02 2008 From: trac at galois.com (GHC) Date: Sun Apr 27 12:03:46 2008 Subject: [GHC] #1861: Uncompilable code generated In-Reply-To: <044.4b0f9f84f991debabab1e254e1bf05b5@localhost> References: <044.4b0f9f84f991debabab1e254e1bf05b5@localhost> Message-ID: <053.8e6abc59dc4a566428a35d4cb3951654@localhost> #1861: Uncompilable code generated ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: lowest | Milestone: 6.8.3 Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by igloo): * priority: normal => lowest Comment: (waiting for response) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Apr 27 12:24:36 2008 From: trac at galois.com (GHC) Date: Sun Apr 27 12:19:14 2008 Subject: [GHC] #1574: Broken link testing In-Reply-To: <056.4175938f47088948409e38405f44cd8f@localhost> References: <056.4175938f47088948409e38405f44cd8f@localhost> Message-ID: <065.11ba31a0a8da1ab235e26b79dac058a6@localhost> #1574: Broken link testing -------------------------------+-------------------------------------------- Reporter: iampure@gmail.com | Owner: igloo Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: Documentation | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Changes (by igloo): * milestone: 6.8.3 => 6.10 branch Comment: punting -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Apr 27 12:44:04 2008 From: trac at galois.com (GHC) Date: Sun Apr 27 12:38:45 2008 Subject: [GHC] #2223: Int64.toInteger In-Reply-To: <045.8abd8f650d1173426a900315be0a8333@localhost> References: <045.8abd8f650d1173426a900315be0a8333@localhost> Message-ID: <054.7efc8ef39a8a599eefb29dfdf9323f69@localhost> #2223: Int64.toInteger ----------------------------+----------------------------------------------- Reporter: gnezdo | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.8.3 Component: Runtime System | Version: 6.8.2 Severity: major | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: arith011 | Architecture: x86 Os: Linux | ----------------------------+----------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged {{{ Thu Apr 24 14:15:26 BST 2008 Ian Lynagh * Fix int64ToInteger 0xFFFFFFFF00000000 on 32bit machine; trac #2223 Patch from Mike Gunter. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Apr 27 12:44:02 2008 From: trac at galois.com (GHC) Date: Sun Apr 27 12:38:50 2008 Subject: [GHC] #2071: hp2ps does not handle SCCs with spaces in the identifiers In-Reply-To: <043.db084f3257628fb450a2954b1e1b4fcc@localhost> References: <043.db084f3257628fb450a2954b1e1b4fcc@localhost> Message-ID: <052.12d0546d2a4a5e382fb33113239558f5@localhost> #2071: hp2ps does not handle SCCs with spaces in the identifiers -----------------------+---------------------------------------------------- Reporter: benl | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.8.3 Component: Profiling | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -----------------------+---------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed (in the sense that we now give an error if spaces are used in an SCC name) in HEAD and 6.8 branch: {{{ Sun Apr 27 12:48:08 BST 2008 Ian Lynagh * Fix an error if an SCC name contains a space; fixes trac #2071 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Apr 27 12:45:44 2008 From: trac at galois.com (GHC) Date: Sun Apr 27 12:40:52 2008 Subject: [GHC] #2036: Show for Double and Float doesn't use parenthesis for negative zero. In-Reply-To: <047.9085fb42c7e7997d5332318ebe9470cc@localhost> References: <047.9085fb42c7e7997d5332318ebe9470cc@localhost> Message-ID: <056.de4d73dbe90f19cc658ccfecf551ec8c@localhost> #2036: Show for Double and Float doesn't use parenthesis for negative zero. ---------------------------------+------------------------------------------ Reporter: clanehin | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: libraries/haskell98 | Version: 6.6.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ---------------------------------+------------------------------------------ Comment (by igloo): Fixed in HEAD and 6.8 branch: {{{ Sun Apr 27 14:32:30 BST 2008 Ian Lynagh * Just (-0/1) is now printed as Just (-0.0), not Just -0.0; trac #2036 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Apr 27 12:47:06 2008 From: trac at galois.com (GHC) Date: Sun Apr 27 12:42:06 2008 Subject: [GHC] #2036: Show for Double and Float doesn't use parenthesis for negative zero. In-Reply-To: <047.9085fb42c7e7997d5332318ebe9470cc@localhost> References: <047.9085fb42c7e7997d5332318ebe9470cc@localhost> Message-ID: <056.309fe71148fc07c23c569477ef4e2c11@localhost> #2036: Show for Double and Float doesn't use parenthesis for negative zero. ---------------------------------+------------------------------------------ Reporter: clanehin | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.8.3 Component: libraries/haskell98 | Version: 6.6.1 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Apr 27 12:49:48 2008 From: trac at galois.com (GHC) Date: Sun Apr 27 12:44:24 2008 Subject: [GHC] #2129: runInteractiveCommand/Process docs don't mention if handles are text or binary In-Reply-To: <045.fab4515899caecbd52d0aae843491315@localhost> References: <045.fab4515899caecbd52d0aae843491315@localhost> Message-ID: <054.5ce42bca013c3bf0726f2f3097b1c38c@localhost> #2129: runInteractiveCommand/Process docs don't mention if handles are text or binary -------------------------------+-------------------------------------------- Reporter: duncan | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.8.3 Component: libraries/process | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed in HEAD and 6.8 branch by {{{ Sun Apr 27 12:16:38 BST 2008 Ian Lynagh * Improve docs; fixes trac #2129. In haddock docs, say that runInteractiveCommand and runInteractiveProcess return handles in binary mode, and that hSetBinaryMode should be used if you need text mode. Sun Apr 27 14:08:55 BST 2008 Ian Lynagh * Wibble imports Haddock can now see hSetBinaryMode, so can make a link to it. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Apr 27 12:51:25 2008 From: trac at galois.com (GHC) Date: Sun Apr 27 12:46:01 2008 Subject: [GHC] #2199: th32SnapEnumProcesses in System.Win32.Process prints debugging information to stdout In-Reply-To: <044.b8fbd1c67ea8e923433d5eaf1eaa88db@localhost> References: <044.b8fbd1c67ea8e923433d5eaf1eaa88db@localhost> Message-ID: <053.20684e77438d685d82b34a3cf10a2609@localhost> #2199: th32SnapEnumProcesses in System.Win32.Process prints debugging information to stdout -----------------------------------+---------------------------------------- Reporter: guest | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: th32SnapEnumProcesses | Difficulty: Unknown Testcase: | Architecture: Unknown 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 Apr 27 13:04:25 2008 From: trac at galois.com (GHC) Date: Sun Apr 27 12:59:02 2008 Subject: [GHC] #2244: load in GHCi doesn't work with UTF-8 filenames Message-ID: <047.b0858d6d8758a91eff606da681db9fc0@localhost> #2244: load in GHCi doesn't work with UTF-8 filenames -------------------------+-------------------------------------------------- Reporter: malebria | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.8.2 | Severity: minor Keywords: | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- When I try to load a file with a UTF-8 character, I got: Prelude> :load P?blico/codigo/haskell/Hora.hs : can't find file: P?blico/codigo/haskell/Hora.hs With the command line it goes fine: malebria@quindinho:~$ ghci P?blico/codigo/haskell/Hora.hs GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. [1 of 1] Compiling Hora ( P?blico/codigo/haskell/Hora.hs, interpreted ) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Apr 27 14:00:43 2008 From: trac at galois.com (GHC) Date: Sun Apr 27 13:55:27 2008 Subject: [GHC] #2012: compiling via-C does not work on ppc In-Reply-To: <045.6ad3ccd84b7b179a5baec1657fb43453@localhost> References: <045.6ad3ccd84b7b179a5baec1657fb43453@localhost> Message-ID: <054.293158eb53ab2d7c04f4b52549e49486@localhost> #2012: compiling via-C does not work on ppc ----------------------+----------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: low | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by igloo): * priority: normal => low Comment: We are unlikely to get to this for 6.8.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Apr 27 14:05:53 2008 From: trac at galois.com (GHC) Date: Sun Apr 27 14:00:37 2008 Subject: [GHC] #1962: make binary-dist creates nested directories under solaris In-Reply-To: <045.1c0f16657d83ea78ed7447a0378acec8@localhost> References: <045.1c0f16657d83ea78ed7447a0378acec8@localhost> Message-ID: <054.8911b955f4ca0ddd6f5c2a05f875d45e@localhost> #1962: make binary-dist creates nested directories under solaris --------------------------+------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Build System | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Solaris | --------------------------+------------------------------------------------- Changes (by igloo): * milestone: 6.8.3 => 6.10 branch Comment: This doesn't actually cause any real problems, so I'm punting on it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Apr 27 14:24:58 2008 From: trac at galois.com (GHC) Date: Sun Apr 27 14:19:40 2008 Subject: [GHC] #2013: ghci crash on startup: R_X86_64_32S relocation out of range. In-Reply-To: <044.2f007075e8a3e652be5aa7c77056c714@localhost> References: <044.2f007075e8a3e652be5aa7c77056c714@localhost> Message-ID: <053.45c0ee2ef8b73dcdc642c5dd7b95d4c8@localhost> #2013: ghci crash on startup: R_X86_64_32S relocation out of range. ---------------------+------------------------------------------------------ Reporter: mboes | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: GHCi | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: FreeBSD | ---------------------+------------------------------------------------------ Changes (by igloo): * owner: => simonmar Comment: Simon, what's the status of this? Should we apply the patch for 6.8.3? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Apr 27 14:25:51 2008 From: trac at galois.com (GHC) Date: Sun Apr 27 14:20:26 2008 Subject: [GHC] #1281: runghc, runhaskell invoke wrong ghc when not first ghc in PATH In-Reply-To: <051.688c37be95655ef452fcfa7bd4cd6ebf@localhost> References: <051.688c37be95655ef452fcfa7bd4cd6ebf@localhost> Message-ID: <060.a78812c90010edf2aee2aae5437b2624@localhost> #1281: runghc, runhaskell invoke wrong ghc when not first ghc in PATH --------------------------+------------------------------------------------- Reporter: Isaac Dupree | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Linux | --------------------------+------------------------------------------------- Changes (by igloo): * milestone: 6.8.3 => 6.10 branch Comment: Punting on this. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Apr 27 14:53:09 2008 From: trac at galois.com (GHC) Date: Sun Apr 27 14:47:52 2008 Subject: [GHC] #2134: Intermittent file locking bug in installPackage.hs In-Reply-To: <041.defdf7e8a14c6388acd7b4588b2e7fd6@localhost> References: <041.defdf7e8a14c6388acd7b4588b2e7fd6@localhost> Message-ID: <050.da5eca6d459f95fa5b7bd693725369fe@localhost> #2134: Intermittent file locking bug in installPackage.hs -------------------------------+-------------------------------------------- Reporter: gw | Owner: duncan Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: libraries (other) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Changes (by duncan): * owner: => duncan Comment: Yep, to cabal-branches/cabal-1.2 We'll make a point release on that branch for ghc-6.8.3, probably 1.2.3.1 since we do not expect to push any patches that involve API changes. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Apr 27 16:05:34 2008 From: trac at galois.com (GHC) Date: Sun Apr 27 16:00:11 2008 Subject: [GHC] #2184: if findExecutable finds a file that matchs the argument, check if it is an executable In-Reply-To: <043.14945e7e7a44f91d6d7e77f4c5d2fcfb@localhost> References: <043.14945e7e7a44f91d6d7e77f4c5d2fcfb@localhost> Message-ID: <052.afbd2e9d93667739ab6e2e566884bf23@localhost> #2184: if findExecutable finds a file that matchs the argument, check if it is an executable ---------------------------------------------+------------------------------ Reporter: iago | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: libraries/directory | Version: 6.8.2 Severity: normal | Resolution: Keywords: findExecutable check executable | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ---------------------------------------------+------------------------------ Changes (by igloo): * milestone: 6.8.3 => 6.10 branch Comment: Hmm, the system function that we use on Windows returns the first path, regardless of whether or not it is executable. I think we should punt on this for now, and revisit it or 6.10. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Apr 27 18:29:10 2008 From: trac at galois.com (GHC) Date: Sun Apr 27 18:23:50 2008 Subject: [GHC] #2069: GHC crashes when both -shared and --make flags are specified In-Reply-To: <049.a76d3ffa368ec969b89faebab8692341@localhost> References: <049.a76d3ffa368ec969b89faebab8692341@localhost> Message-ID: <058.318e2b0d055701ab4cae6b6a37f92a73@localhost> #2069: GHC crashes when both -shared and --make flags are specified ------------------------+--------------------------------------------------- Reporter: bchallenor | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ------------------------+--------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: It was already fixed in the HEAD. I've now also fixed it in the 6.8 branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Apr 27 18:42:26 2008 From: trac at galois.com (GHC) Date: Sun Apr 27 18:37:04 2008 Subject: [GHC] #2217: :list command missing from help In-Reply-To: <044.fbe338f21c5a3bd6c2e8b69d2945b572@localhost> References: <044.fbe338f21c5a3bd6c2e8b69d2945b572@localhost> Message-ID: <053.316aa8123e85969fb4473d823330e9d9@localhost> #2217: :list command missing from help ---------------------+------------------------------------------------------ Reporter: mrijn | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.8.3 Component: GHCi | Version: 6.8.2 Severity: trivial | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ---------------------+------------------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed in HEAD and 6.8 branch {{{ Sun Apr 27 12:00:49 PDT 2008 Ian Lynagh * Add :list to ghci's :? help; fixes trac #2217 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Apr 27 18:44:45 2008 From: trac at galois.com (GHC) Date: Sun Apr 27 18:39:27 2008 Subject: [GHC] #2134: Intermittent file locking bug in installPackage.hs In-Reply-To: <041.defdf7e8a14c6388acd7b4588b2e7fd6@localhost> References: <041.defdf7e8a14c6388acd7b4588b2e7fd6@localhost> Message-ID: <050.ca62f45dfe6e7c5f0a700162e84d5708@localhost> #2134: Intermittent file locking bug in installPackage.hs -------------------------------+-------------------------------------------- Reporter: gw | Owner: duncan Type: bug | Status: closed Priority: normal | Milestone: 6.8.3 Component: libraries (other) | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: OK, I've merged the patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Apr 27 18:49:34 2008 From: trac at galois.com (GHC) Date: Sun Apr 27 18:44:09 2008 Subject: [GHC] #2093: getSymbolicLinkStatus (and possibly other functions) broken on systems with large file system support In-Reply-To: <049.6b21dc8703db26b4a3f8f2aed151d2af@localhost> References: <049.6b21dc8703db26b4a3f8f2aed151d2af@localhost> Message-ID: <058.e5706669a5c8339d68c982e0aacc24b6@localhost> #2093: getSymbolicLinkStatus (and possibly other functions) broken on systems with large file system support ----------------------------+----------------------------------------------- Reporter: JeremyShaw | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.8.3 Component: libraries/unix | Version: 6.8.2 Severity: major | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------------+----------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Thanks for the patch! I've applied it to HEAD and 6.8 branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Apr 27 21:27:04 2008 From: trac at galois.com (GHC) Date: Sun Apr 27 21:21:40 2008 Subject: [GHC] #1944: round function causes cblas NaNs In-Reply-To: <052.7827d863c451a2b4d8c8af2c2416f81c@localhost> References: <052.7827d863c451a2b4d8c8af2c2416f81c@localhost> Message-ID: <061.aecd960e36910b1e244c95c7813d1ea2@localhost> #1944: round function causes cblas NaNs ---------------------------+------------------------------------------------ Reporter: SevenThunders | Owner: Type: bug | Status: new Priority: low | Milestone: 6.8.3 Component: Compiler | Version: 6.8.1 Severity: critical | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ---------------------------+------------------------------------------------ Comment (by SevenThunders): Sorry to hear that it gets low priority. Especially since it basically implies that you can not link to external math libraries safely in 6.8.2 and above on windows at least. If I have time I will try to get a test case that shows the bug with amd's acml library. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Apr 28 01:34:41 2008 From: trac at galois.com (GHC) Date: Mon Apr 28 01:29:17 2008 Subject: [GHC] #2228: runghc screws up terminal buffering mode and doesn't reset it In-Reply-To: <044.5a9b5cb0e6f9fbb1f5c64639b7a5180d@localhost> References: <044.5a9b5cb0e6f9fbb1f5c64639b7a5180d@localhost> Message-ID: <053.d5639e57cdc48423bfc553cda898f0ce@localhost> #2228: runghc screws up terminal buffering mode and doesn't reset it --------------------+------------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: GHCi | Version: 6.8.2 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Linux | --------------------+------------------------------------------------------- Changes (by andersk): * architecture: x86_64 (amd64) => Multiple Comment: [I'm the original reporter.] Are you sure they're the same? I've reproduced this on hardy's 6.8.2-2ubuntu1, sid's 6.8.2-4, and a hand-compiled 6.8.2 on etch and RHEL4, on amd64 and i386, from both gnome-terminal and the Linux console, and I've had friends reproduce it as well. After stopping runghc cat.hs with ^C, the difference I see in the stty -a output is that icanon changes to -icanon (which might be easy to miss visually?). With 6.6.1, I see the same double echo, raw controls behavior while runghc cat.hs is running, but everything is correctly reset when it is stopped. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Apr 28 03:28:20 2008 From: trac at galois.com (GHC) Date: Mon Apr 28 03:22:55 2008 Subject: [GHC] #2238: panic nameModule tpl_B1{v} In-Reply-To: <044.2c7ef9e7b09c867edd5544536ef8fbf1@localhost> References: <044.2c7ef9e7b09c867edd5544536ef8fbf1@localhost> Message-ID: <053.5c67e4ed059f2c24c94e87b30745794e@localhost> #2238: panic nameModule tpl_B1{v} ----------------------+----------------------------------------------------- Reporter: claus | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonpj): * owner: => simonpj Comment: I'm fixing this Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Apr 28 03:35:49 2008 From: trac at galois.com (GHC) Date: Mon Apr 28 03:30:22 2008 Subject: [GHC] #2237: qualified names not permitted everywhere in instances In-Reply-To: <044.979df1df57c1530008974aa6ad0b7805@localhost> References: <044.979df1df57c1530008974aa6ad0b7805@localhost> Message-ID: <053.8b472a18d849ed63258fd5ea30e9f756@localhost> #2237: qualified names not permitted everywhere in instances -------------------------------+-------------------------------------------- Reporter: claus | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Parser) | Version: 6.9 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Comment (by simonpj): Good suggestion. I had a look, but it's really not convenient to do this. Haskell ''never'' allows a qualified name in a binding position, and it's the code that parses bindings that emits the error message. Of course this'd be fixable by adding some more context information, but it looks like more than just adding a boolean flag to me. So I think other feature requests are probably higher priority. But if you'd like to have a go yourself, the error comes from RdrHsSyn.checkFunBind. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Apr 28 06:21:25 2008 From: trac at galois.com (GHC) Date: Mon Apr 28 06:16:00 2008 Subject: [GHC] #2228: runghc screws up terminal buffering mode and doesn't reset it In-Reply-To: <044.5a9b5cb0e6f9fbb1f5c64639b7a5180d@localhost> References: <044.5a9b5cb0e6f9fbb1f5c64639b7a5180d@localhost> Message-ID: <053.93a185b2348f55d04ba8814764667eb5@localhost> #2228: runghc screws up terminal buffering mode and doesn't reset it --------------------+------------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: GHCi | Version: 6.8.2 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Linux | --------------------+------------------------------------------------------- Comment (by igloo): Here's complete output from a gnome-terminal: {{{ $ cat cat.hs main = putStr =<< getContents $ stty -a speed 38400 baud; rows 56; columns 80; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = M-^?; eol2 = M-^?; swtch = M-^?; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0; -parenb -parodd cs8 hupcl -cstopb cread -clocal -crtscts -ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc ixany imaxbel -iutf8 opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke $ runghc cat.hs hheelllloo ^D^?^D^D cat.hs: exception :: GhcException $ stty -a speed 38400 baud; rows 56; columns 80; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = M-^?; eol2 = M-^?; swtch = M-^?; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0; -parenb -parodd cs8 hupcl -cstopb cread -clocal -crtscts -ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc ixany imaxbel -iutf8 opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke $ }}} Incidentally, I have to press another key after control-C for it to actually terminate. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Apr 28 06:34:12 2008 From: trac at galois.com (GHC) Date: Mon Apr 28 06:28:46 2008 Subject: [GHC] #2228: runghc screws up terminal buffering mode and doesn't reset it In-Reply-To: <044.5a9b5cb0e6f9fbb1f5c64639b7a5180d@localhost> References: <044.5a9b5cb0e6f9fbb1f5c64639b7a5180d@localhost> Message-ID: <053.ea6fc15db622c271e13191fa95febe27@localhost> #2228: runghc screws up terminal buffering mode and doesn't reset it --------------------+------------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: GHCi | Version: 6.8.2 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Linux | --------------------+------------------------------------------------------- Comment (by andersk): Is it possible that your shell is resetting icanon between the runghc and stty commands? My shell is bash, but I just tried with zsh instead and got the same result you did. Try this instead: {{{ stty -a sh -c "trap 'stty -a' INT; runghc cat.hs" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Apr 28 07:50:09 2008 From: trac at galois.com (GHC) Date: Mon Apr 28 07:44:44 2008 Subject: [GHC] #1944: round function causes cblas NaNs In-Reply-To: <052.7827d863c451a2b4d8c8af2c2416f81c@localhost> References: <052.7827d863c451a2b4d8c8af2c2416f81c@localhost> Message-ID: <061.6228becea0e6b313471a26f5a65ead08@localhost> #1944: round function causes cblas NaNs ---------------------------+------------------------------------------------ Reporter: SevenThunders | Owner: Type: bug | Status: new Priority: low | Milestone: 6.8.3 Component: Compiler | Version: 6.8.1 Severity: critical | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ---------------------------+------------------------------------------------ Comment (by simonpj): It's not that we don't want to fix it; it's just that with 30 days to 6.8.3 we can only fix things that can be done fairly quickly. And this bug only seems to show up in rather complicated and hard-to-reproduce situation. Anything you can do to help us get a reproducible error would be very helpful. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Apr 28 11:14:43 2008 From: trac at galois.com (GHC) Date: Mon Apr 28 11:09:17 2008 Subject: [GHC] #2228: runghc screws up terminal buffering mode and doesn't reset it In-Reply-To: <044.5a9b5cb0e6f9fbb1f5c64639b7a5180d@localhost> References: <044.5a9b5cb0e6f9fbb1f5c64639b7a5180d@localhost> Message-ID: <053.4402fe1612f64d1aefd2ba5d0042b9f4@localhost> #2228: runghc screws up terminal buffering mode and doesn't reset it --------------------+------------------------------------------------------- Reporter: guest | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: GHCi | Version: 6.8.2 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Linux | --------------------+------------------------------------------------------- Changes (by igloo): * owner: => igloo Comment: Aha, yes, thanks, I can reproduce it with bash. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Apr 28 11:42:00 2008 From: trac at galois.com (GHC) Date: Mon Apr 28 11:36:33 2008 Subject: [GHC] #2238: panic nameModule tpl_B1{v} In-Reply-To: <044.2c7ef9e7b09c867edd5544536ef8fbf1@localhost> References: <044.2c7ef9e7b09c867edd5544536ef8fbf1@localhost> Message-ID: <053.38fa34d4df8751670cf599f8f22750ce@localhost> #2238: panic nameModule tpl_B1{v} ----------------------+----------------------------------------------------- Reporter: claus | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: T2238 | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonpj): * testcase: => T2238 * owner: simonpj => igloo * type: bug => merge Comment: Fixed by {{{ Mon Apr 28 14:47:30 BST 2008 simonpj@microsoft.com * Fix Trac #2238: do not use newtype for a class with equality predicates }}} Only really necessary for the HEAD, but probably worth a go at merging to the branch, if it goes cleanly. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Apr 28 12:10:19 2008 From: trac at galois.com (GHC) Date: Mon Apr 28 12:04:52 2008 Subject: [GHC] #1969: enormous compile times In-Reply-To: <045.1ab99ac1a52ae6b35a7131dc801608a9@localhost> References: <045.1ab99ac1a52ae6b35a7131dc801608a9@localhost> Message-ID: <054.a8db29d67e996842a9d42abc480a85e6@localhost> #1969: enormous compile times -------------------------+-------------------------------------------------- Reporter: duncan | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: performance | Difficulty: Difficult (1 week) Testcase: | Architecture: Multiple Os: Multiple | -------------------------+-------------------------------------------------- Changes (by simonpj): * owner: => igloo * type: compile-time performance bug => merge Comment: Ian: you absolutely nailed the problem, thank you. I refactored a bit, and behold the specialiser pass runs really fast on that code now. Here's the patch, which might be worth merging to the branch: {{{ Mon Apr 28 16:57:11 BST 2008 simonpj@microsoft.com * Fix Trac #1969: perfomance bug in the specialiser }}} You might want to check that it cures the problem on the original code? I don't quite know how to add a test; maybe not worth the trouble. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Apr 28 12:12:02 2008 From: trac at galois.com (GHC) Date: Mon Apr 28 12:06:36 2008 Subject: [GHC] #1969: enormous compile times In-Reply-To: <045.1ab99ac1a52ae6b35a7131dc801608a9@localhost> References: <045.1ab99ac1a52ae6b35a7131dc801608a9@localhost> Message-ID: <054.43303c8c5220684de2b8440ff40d1095@localhost> #1969: enormous compile times -------------------------+-------------------------------------------------- Reporter: duncan | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: performance | Difficulty: Difficult (1 week) Testcase: | Architecture: Multiple Os: Multiple | -------------------------+-------------------------------------------------- Comment (by simonpj): PS: I've just noticed that the original report described a problem even without -O, so that part at least can't be cured by my patch, since the specialiser only runs with -O. So, perhaps you can see if that is the case, and re-open if so? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Apr 28 15:07:21 2008 From: trac at galois.com (GHC) Date: Mon Apr 28 15:01:53 2008 Subject: [GHC] #2228: runghc screws up terminal buffering mode and doesn't reset it In-Reply-To: <044.5a9b5cb0e6f9fbb1f5c64639b7a5180d@localhost> References: <044.5a9b5cb0e6f9fbb1f5c64639b7a5180d@localhost> Message-ID: <053.1be72bc3def2d2f9766b0feacb1c1928@localhost> #2228: runghc screws up terminal buffering mode and doesn't reset it --------------------+------------------------------------------------------- Reporter: guest | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: GHCi | Version: 6.8.2 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Linux | --------------------+------------------------------------------------------- Comment (by simonmar): Yes, zsh saves the terminal settings and restores them after every program; use `ttyctl -u` to stop it doing that. There are a couple of problems here. * GHCi is setting stdin/stdout to `NoBuffering` in runghc, and it shouldn't be. I think this is because runghc is executing multiple commands, and GHCi is resetting the buffering between the commands. * GHCi is exiting via `topHandlerFastExit` which omits all of the shutdown cleanup that the RTS normally does, in particular the restoring of the terminal state (`RtsStartup.c:hs_exit_()`). igloo: I can probably fix this, but I'm not completely sure about the second issue - I think it was you that introduced the `topHandlerFastExit` thing. It doesn't look quite right to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Apr 28 15:50:13 2008 From: trac at galois.com (GHC) Date: Mon Apr 28 15:44:53 2008 Subject: [GHC] #1861: Uncompilable code generated In-Reply-To: <044.4b0f9f84f991debabab1e254e1bf05b5@localhost> References: <044.4b0f9f84f991debabab1e254e1bf05b5@localhost> Message-ID: <053.4f9b89d1b7710535b2b531536f942ec9@localhost> #1861: Uncompilable code generated ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: lowest | Milestone: 6.8.3 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by guest): * version: 6.8.1 => 6.9 Comment: The GHC optimizations have regressed (I'll send a separate report) so the program has to be changed a little to generate uncompilable code: {{{ main = interact $ show . (< (1e400 :: Double)) . read }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Apr 28 16:01:48 2008 From: trac at galois.com (GHC) Date: Mon Apr 28 15:56:29 2008 Subject: [GHC] #2245: Numeric literal printed wrong in error message Message-ID: <044.08dd2bddd379c7c8cb24c2c904f28812@localhost> #2245: Numeric literal printed wrong in error message -----------------------+---------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: MacOS X -----------------------+---------------------------------------------------- Compile the following with -Wall {{{ default (T) data T = T deriving (Eq, Ord, Read, Show) instance Num T instance Fractional T main = interact $ show . (< 1e400) . read }}} The error message says {{{ Bug.hs:7:28: Warning: Defaulting the following constraint(s) to type `T' `Fractional b' arising from the literal `Infinity' at Bug.hs:7:28-32 }}} There is no literal Infinity in my program, I wrote 1e400, which could be a perfectly good literal for the type T. I don't wanted printed as Infinity. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Apr 28 16:04:22 2008 From: trac at galois.com (GHC) Date: Mon Apr 28 15:59:31 2008 Subject: [GHC] #1958: collect2: ld terminated with signal 10 [Bus error]: Building parsec on a PPC Mac OS X 10.5 Leopard as part of GHC 6.9 In-Reply-To: <050.c31695132cb1b93380c95a8b6c208782@localhost> References: <050.c31695132cb1b93380c95a8b6c208782@localhost> Message-ID: <059.eeb022fd0687f91aad3901c1dc4f9e51@localhost> #1958: collect2: ld terminated with signal 10 [Bus error]: Building parsec on a PPC Mac OS X 10.5 Leopard as part of GHC 6.9 -------------------------+-------------------------------------------------- Reporter: thorkilnaur | Owner: thorkilnaur Type: bug | Status: new Priority: high | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | -------------------------+-------------------------------------------------- Comment (by thorkilnaur): I am delighted to report that I was unable to provoke the "Bus error" reaction using the "Developer preview" version of Xcode3.1 that I tried out, prompted by the Apple response. The "tnaur PPC OSX stable 2" builder (which is a Mac OS X 10.5 Leopard) has succeeded for the first time, ever, with this version of Xcode3.1 (see http://darcs.haskell.org/buildbot/all/builders/tnaur%20PPC%20OSX%20stable%202/builds/90). I suggest that we close this ticket when Apple releases a version of Xcode with this problem solved. Best regards Thorkil -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Apr 28 16:07:48 2008 From: trac at galois.com (GHC) Date: Mon Apr 28 16:02:30 2008 Subject: [GHC] #2246: Numeric literal very badly optimized Message-ID: <044.ea64e9326ad25932314b8864281b1a7d@localhost> #2246: Numeric literal very badly optimized -----------------------+---------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: major Keywords: | Testcase: Architecture: x86 | Os: MacOS X -----------------------+---------------------------------------------------- Compile the following program with -ddump-simpl {{{ main = interact $ show . (< 1e40) . read }}} Note how there's no literal value 1e40::Double anywhere in the code. Instead there's a call to fromRat to do the conversion. Now replace 1e40 with (1e40::Double), and the code looks good. So it seems that when defaulting is involved the code is '''much''' worse. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Apr 28 17:46:19 2008 From: trac at galois.com (GHC) Date: Mon Apr 28 17:41:17 2008 Subject: [GHC] #1780: runInteractiveProcess broken with >2 processes on POSIX In-Reply-To: <044.d5b4cf5d496c65f6f766ac301f4fef42@localhost> References: <044.d5b4cf5d496c65f6f766ac301f4fef42@localhost> Message-ID: <053.4fcbcce13c53b5f3709e7f0c871f856b@localhost> #1780: runInteractiveProcess broken with >2 processes on POSIX -------------------------------+-------------------------------------------- Reporter: guest | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: libraries/process | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -------------------------------+-------------------------------------------- Changes (by simonmar): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Apr 28 18:43:18 2008 From: trac at galois.com (GHC) Date: Mon Apr 28 18:37:51 2008 Subject: [GHC] #1933: Zero times in profiling with GHC-6.8.1 In-Reply-To: <056.353a18a91ecfd8fecb6c03c68c7e7fde@localhost> References: <056.353a18a91ecfd8fecb6c03c68c7e7fde@localhost> Message-ID: <065.338b688c8b1d5c56cc8396a2366417e7@localhost> #1933: Zero times in profiling with GHC-6.8.1 -------------------------------+-------------------------------------------- Reporter: daniel.is.fischer | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Profiling | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | -------------------------------+-------------------------------------------- Changes (by simonmar): * cc: daniel.is.fischer@web.de (added) Comment: Daniel: could you try this modified version of your test program and let me know the results? {{{ #include #include #include #include #include static volatile int tock = 0; static void handler(int i) { tock = 1; } int main(int argc, char *argv[]) { struct sigevent ev; timer_t timer; struct itimerspec it; struct sigaction action; int m,n,count = 0; ev.sigev_notify = SIGEV_SIGNAL; ev.sigev_signo = SIGVTALRM; action.sa_handler = handler; action.sa_flags = 0; sigemptyset(&action.sa_mask); if (sigaction(SIGVTALRM, &action, NULL) == -1) { printf("SIGVTALRM problem\n"); exit(3); } if (timer_create(CLOCK_PROCESS_CPUTIME_ID, &ev, &timer) != 0) { printf("No CLOCK_PROCESS_CPUTIME_ID timer\n"); exit(1); } it.it_value.tv_sec = 0; it.it_value.tv_nsec = 1; it.it_interval = it.it_value; if (timer_settime(timer, 0, &it, NULL) != 0) { printf("settime problem\n"); exit(4); } tock = 0; for(n = 3; n < 20000; n++){ for(m = 2; m <= n/2; m++){ if (!(n%m)) count++; if (tock) goto out; } } out: if (!tock) { printf("no CLOCK_REALTIME signal\n"); exit(5); } timer_delete(timer); if (timer_create(CLOCK_REALTIME, &ev, &timer) != 0) { printf("No CLOCK_REALTIME timer\n"); exit(2); } it.it_value.tv_sec = 0; it.it_value.tv_nsec = 1; it.it_interval = it.it_value; if (timer_settime(timer, 0, &it, NULL) != 0) { printf("settime problem\n"); exit(4); } tock = 0; usleep(100); if (!tock) { printf("no CLOCK_REALTIME signal\n"); exit(5); } timer_delete(timer); exit(0); } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Apr 28 18:52:14 2008 From: trac at galois.com (GHC) Date: Mon Apr 28 18:46:56 2008 Subject: [GHC] #2013: ghci crash on startup: R_X86_64_32S relocation out of range. In-Reply-To: <044.2f007075e8a3e652be5aa7c77056c714@localhost> References: <044.2f007075e8a3e652be5aa7c77056c714@localhost> Message-ID: <053.22a944178f0d476be7100d059dbc8905@localhost> #2013: ghci crash on startup: R_X86_64_32S relocation out of range. ---------------------+------------------------------------------------------ Reporter: mboes | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: GHCi | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: FreeBSD | ---------------------+------------------------------------------------------ Comment (by simonmar): The patch is a proof of concept, it needs someone to clean it up (i.e. `#ifdef freebsd` the changes, basically). Also something different needs to be done for HEAD, so after fixing this in 6.8.3 we need to move the ticket onto the 6.10 milestone. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Apr 28 18:52:36 2008 From: trac at galois.com (GHC) Date: Mon Apr 28 18:47:10 2008 Subject: [GHC] #714: Inconsistency between handling functional dependencies in class and signature constraints In-Reply-To: <062.a7978807e311bf94b9011dbbf8edf8af@localhost> References: <062.a7978807e311bf94b9011dbbf8edf8af@localhost> Message-ID: <071.96328be5f75f4a6f08868d50f24812ac@localhost> #714: Inconsistency between handling functional dependencies in class and signature constraints -------------------------------------+-------------------------------------- Reporter: claus.reinke@talk21.com | Owner: simonpj Type: bug | Status: new Priority: low | Milestone: _|_ Component: Compiler (Type checker) | Version: 6.5 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Comment (by claus): could this please be re-milestoned, for 6.10, as that seems to be the target for completing the overhaul mentioned by Simon PJ. since this is reported as a scope error, the same inconsistency now applies to TFs, but there we have the additional oddity that the signature constraint is simply dropped even if there are no type instances at all..: {{{ class FD a b | a -> b -- class FD a b => CFD a -- Not in scope: type variable `b' fd :: FD a b => a fd = undefined type family TF a -- class TF a ~ b => CTF a -- Not in scope: type variable `b' tf :: TF a ~ b => a tf = undefined }}} {{{ *Main> :t fd fd :: (FD a b) => a *Main> :t tf tf :: a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Apr 28 19:11:30 2008 From: trac at galois.com (GHC) Date: Mon Apr 28 19:06:02 2008 Subject: [GHC] #2247: GHC accepts FD violations, unless the conflicing instances are used Message-ID: <044.b5dc7ac6137d6de05ce0c6a9f5daf089@localhost> #2247: GHC accepts FD violations, unless the conflicing instances are used -------------------------+-------------------------------------------------- Reporter: claus | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 6.9 | Severity: normal Keywords: TF vs FD | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- consider {{{ class FD a b | a -> b instance CFD a b => FD a b class {- FD a b => -} CFD a b instance CFD Bool Char instance CFD Bool Bool f :: CFD Bool Bool => Bool f = True g :: CFD Bool Char => Bool g = False f' :: FD Bool Bool => Bool f' = True g' :: FD Bool Char => Bool g' = False }}} the class instance for `FD` is odd, because there is no guarantee that instances of `CFD` comply to the FD (and Hugs rejects that instance, unless the superclass constraint for `CFD` is uncommented). as it stands, this code specifies two FD-conflicting instances of class `FD`, but they are implied, not explicit. GHCi accepts this code, and only complains if the two conflicting instances are used, explicitly, in the same expression: {{{ *Main> f True *Main> g False *Main> (f,g) (True,False) *Main> f' True *Main> g' False *Main> (f',g') :1:0: Couldn't match expected type `Bool' against inferred type `Char' When using functional dependencies to combine FD Bool Char, arising from a use of `g'' at :1:4-5 FD Bool Bool, arising from a use of `f'' at :1:1-2 When generalising the type(s) for `it' *Main> do {let {x=f} ;let {y=g} ; return (x,y) } (True,False) *Main> do {let {x=f'} ;let {y=g'} ; return (x,y) } :1:0: Couldn't match expected type `Char' against inferred type `Bool' When using functional dependencies to combine FD Bool Bool, arising from a use of `f'' at :1:11-12 FD Bool Char, arising from a use of `g'' at :1:23-24 When generalising the type(s) for `it' *Main> let x=f' *Main> let y=g' *Main> (x,y) (True,False) }}} so we can have FD-conflicting instances in the same code, even use them in the same GHCi session, as long as they don't meet in the same line.. for further details and questions, see this message: [http://www.haskell.org/pipermail/haskell-cafe/2008-April/042219.html some questions about type improvement, FDs vs TFs, and Hugs vs GHCi] -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Apr 28 19:17:13 2008 From: trac at galois.com (GHC) Date: Mon Apr 28 19:12:01 2008 Subject: [GHC] #1780: runInteractiveProcess broken with >2 processes on POSIX In-Reply-To: <044.d5b4cf5d496c65f6f766ac301f4fef42@localhost> References: <044.d5b4cf5d496c65f6f766ac301f4fef42@localhost> Message-ID: <053.add0449c5e47f2f8193dd1976d71a454@localhost> #1780: runInteractiveProcess broken with >2 processes on POSIX -------------------------------+-------------------------------------------- Reporter: guest | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.8.3 Component: libraries/process | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -------------------------------+-------------------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: Please merge these two: {{{ Mon Apr 28 14:59:04 PDT 2008 Simon Marlow * FIX #1780: set pipe descriptors FD_CLOEXEC in the parent Tue Apr 22 13:47:19 PDT 2008 Simon Marlow * don't set O_NONBLOCK on FDs passed to fdToHandle }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Apr 28 19:25:23 2008 From: trac at galois.com (GHC) Date: Mon Apr 28 19:19:58 2008 Subject: [GHC] #2155: More deadlock issues with concurrent I/O In-Reply-To: <046.2b787244ac57309bd0e0c416ba277e1a@localhost> References: <046.2b787244ac57309bd0e0c416ba277e1a@localhost> Message-ID: <055.3a6c17c47b9794899abf6fab8cd1e184@localhost> #2155: More deadlock issues with concurrent I/O -------------------------------+-------------------------------------------- Reporter: dfranke | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.8.3 Component: libraries/process | Version: 6.8.2 Severity: major | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | -------------------------------+-------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => duplicate Comment: Now fixed, it was indeed a duplicate of #1780. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Apr 28 19:46:47 2008 From: trac at galois.com (GHC) Date: Mon Apr 28 19:41:19 2008 Subject: [GHC] #2152: bogus inlining of foreign import "foo.h &foo" In-Reply-To: <047.0a1ee6738155b38bc12c1c5c56928fad@localhost> References: <047.0a1ee6738155b38bc12c1c5c56928fad@localhost> Message-ID: <056.5faac23054a6f92b2e692bfff90c92f0@localhost> #2152: bogus inlining of foreign import "foo.h &foo" ----------------------+----------------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by simonmar): This is not an issue in HEAD, incedentally, which now doesn't need or use external header files when compiling via C. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Apr 29 09:17:37 2008 From: trac at galois.com (GHC) Date: Tue Apr 29 09:12:07 2008 Subject: [GHC] #2228: runghc screws up terminal buffering mode and doesn't reset it In-Reply-To: <044.5a9b5cb0e6f9fbb1f5c64639b7a5180d@localhost> References: <044.5a9b5cb0e6f9fbb1f5c64639b7a5180d@localhost> Message-ID: <053.c245d529866f86b94f4002753e7fed5c@localhost> #2228: runghc screws up terminal buffering mode and doesn't reset it --------------------+------------------------------------------------------- Reporter: guest | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: GHCi | Version: 6.8.2 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Linux | --------------------+------------------------------------------------------- Changes (by igloo): * owner: igloo => simonmar Comment: Perhaps it should just be `topHandler`. As long as `ghc-e004` and `ghc-e005` still pass it's probably fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Apr 29 09:18:52 2008 From: trac at galois.com (GHC) Date: Tue Apr 29 09:13:23 2008 Subject: [GHC] #2152: bogus inlining of foreign import "foo.h &foo" In-Reply-To: <047.0a1ee6738155b38bc12c1c5c56928fad@localhost> References: <047.0a1ee6738155b38bc12c1c5c56928fad@localhost> Message-ID: <056.93df53cfac348ee67ba19d38517ef56c@localhost> #2152: bogus inlining of foreign import "foo.h &foo" ----------------------+----------------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: low | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * priority: normal => low Comment: This probably isn't worth spending the time on just for 6.8.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Apr 29 09:21:19 2008 From: trac at galois.com (GHC) Date: Tue Apr 29 09:15:48 2008 Subject: [GHC] #714: Inconsistency between handling functional dependencies in class and signature constraints In-Reply-To: <062.a7978807e311bf94b9011dbbf8edf8af@localhost> References: <062.a7978807e311bf94b9011dbbf8edf8af@localhost> Message-ID: <071.f8d3835f060ece7fcaca7371bb088aa1@localhost> #714: Inconsistency between handling functional dependencies in class and signature constraints -------------------------------------+-------------------------------------- Reporter: claus.reinke@talk21.com | Owner: simonpj Type: bug | Status: new Priority: low | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.5 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Changes (by igloo): * milestone: _|_ => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Apr 29 10:04:38 2008 From: trac at galois.com (GHC) Date: Tue Apr 29 09:59:39 2008 Subject: [GHC] #1958: collect2: ld terminated with signal 10 [Bus error]: Building parsec on a PPC Mac OS X 10.5 Leopard as part of GHC 6.9 In-Reply-To: <050.c31695132cb1b93380c95a8b6c208782@localhost> References: <050.c31695132cb1b93380c95a8b6c208782@localhost> Message-ID: <059.2678082e54ff7d0dddcc8acebc23ab7c@localhost> #1958: collect2: ld terminated with signal 10 [Bus error]: Building parsec on a PPC Mac OS X 10.5 Leopard as part of GHC 6.9 -------------------------+-------------------------------------------------- Reporter: thorkilnaur | Owner: thorkilnaur Type: bug | Status: new Priority: high | Milestone: Not GHC Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | -------------------------+-------------------------------------------------- Changes (by igloo): * milestone: 6.8.3 => Not GHC Comment: Great, thanks Thorkil! So, I think the plan is to just sit and wait? If someone could shout when Xcode3.1 is released, that would be very useful. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Apr 29 10:06:05 2008 From: trac at galois.com (GHC) Date: Tue Apr 29 10:00:36 2008 Subject: [GHC] #2117: ppc "./Setup build" seg-faults on Mac OS leopard In-Reply-To: <045.49291ad5dcecd52c54fd505935d3d802@localhost> References: <045.49291ad5dcecd52c54fd505935d3d802@localhost> Message-ID: <054.b714074d88f1f7fbb003dbba22274f93@localhost> #2117: ppc "./Setup build" seg-faults on Mac OS leopard ----------------------+----------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => duplicate Comment: I'm closing this as a duplicate of #1958. Please reopen if you think that that's wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Apr 29 10:05:05 2008 From: trac at galois.com (GHC) Date: Tue Apr 29 10:02:41 2008 Subject: [GHC] #1958: collect2: ld terminated with signal 10 [Bus error]: Building parsec on a PPC Mac OS X 10.5 Leopard as part of GHC 6.9 In-Reply-To: <050.c31695132cb1b93380c95a8b6c208782@localhost> References: <050.c31695132cb1b93380c95a8b6c208782@localhost> Message-ID: <059.036a0bd13773503a556844d218b90de2@localhost> #1958: collect2: ld terminated with signal 10 [Bus error]: Building parsec on a PPC Mac OS X 10.5 Leopard as part of GHC 6.9 -------------------------+-------------------------------------------------- Reporter: thorkilnaur | Owner: thorkilnaur Type: bug | Status: new Priority: high | Milestone: Not GHC Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | -------------------------+-------------------------------------------------- Comment (by igloo): (and the same for #2117) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Apr 29 10:16:38 2008 From: trac at galois.com (GHC) Date: Tue Apr 29 10:11:08 2008 Subject: [GHC] #1933: Zero times in profiling with GHC-6.8.1 In-Reply-To: <056.353a18a91ecfd8fecb6c03c68c7e7fde@localhost> References: <056.353a18a91ecfd8fecb6c03c68c7e7fde@localhost> Message-ID: <065.a56533913535bd7e5e9d15117e4ee4be@localhost> #1933: Zero times in profiling with GHC-6.8.1 -------------------------------+-------------------------------------------- Reporter: daniel.is.fischer | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Profiling | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | -------------------------------+-------------------------------------------- Comment (by daniel.is.fischer): That says: no CLOCK_REALTIME signal. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Apr 29 12:15:50 2008 From: trac at galois.com (GHC) Date: Tue Apr 29 12:10:19 2008 Subject: [GHC] #2152: bogus inlining of foreign import "foo.h &foo" In-Reply-To: <047.0a1ee6738155b38bc12c1c5c56928fad@localhost> References: <047.0a1ee6738155b38bc12c1c5c56928fad@localhost> Message-ID: <056.da5341abb6370af34e91edbf3e1c9be4@localhost> #2152: bogus inlining of foreign import "foo.h &foo" ----------------------+----------------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: low | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by simonpj): Punting for 6.8.3 is probably ok, but it's on my list because NOINLINE should make a definition opaque, but doesn't. That's because `exprIsConApp_maybe` doesn't take account of it. In principle this might affect other program too. I'll get to it. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Apr 29 12:36:30 2008 From: trac at galois.com (GHC) Date: Tue Apr 29 12:31:01 2008 Subject: [GHC] #2248: .exe extension missing when compiling a file ending in dot + digits + dot hs Message-ID: <046.59221d2fec02e33b156d46e404241b5d@localhost> #2248: .exe extension missing when compiling a file ending in dot + digits + dot hs ------------------------+--------------------------------------------------- Reporter: oboudry | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: minor Keywords: | Testcase: Architecture: x86 | Os: Windows ------------------------+--------------------------------------------------- Hi all, I just encountered this very minor bug on Windows/GHC 6.8.2 When compiling a file that ends in `.N.hs` where N is a series of digits, the executable is missing the `.exe` extension. I can of course workaround the problem by specifying the file name with the -o flag. Here is a series of test I made to determine when the bug occurs. Look at the `Linking ...` line that shows the executable name. {{{ C:\Temp\Haskell>ghc --make Test_0.hs [1 of 1] Compiling Main ( Test_0.hs, Test_0.o ) Linking Test_0.exe ... C:\Temp\Haskell>ren Test_0.hs Test.0.hs C:\Temp\Haskell>ghc --make Test.0.hs [1 of 1] Compiling Main ( Test.0.hs, Test.0.o ) Linking Test.0 ... C:\Temp\Haskell>ren Test.0.hs Test.012.hs C:\Temp\Haskell>ghc --make Test.012.hs [1 of 1] Compiling Main ( Test.012.hs, Test.012.o ) Linking Test.012 ... }}} Best regards, Olivier. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Apr 29 18:09:37 2008 From: trac at galois.com (GHC) Date: Tue Apr 29 18:04:28 2008 Subject: [GHC] #2249: Undeclared variable in cmm reports as panic Message-ID: <047.3bf0f01140bc39be71a2a471d7ca96ac@localhost> #2249: Undeclared variable in cmm reports as panic -------------------------------+-------------------------------------------- Reporter: millenix | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: minor Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Linux -------------------------------+-------------------------------------------- In CMM code, if one makes an assignment to a variable that's not been declared, the compiler panics, in addition to reporting an almost sensible error message. Here's code to make it happen: {{{ testingbug { var = 1; } }}} And here's the output it causes: {{{ ghc-6.9.20080305: panic! (the 'impossible' happened) (GHC version 6.9.20080305 for x86_64-unknown-linux): CmmParse: var not a register Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I see two problems here: 1. As the output notes, the compiler should not panic just because the user fed it noticeably bad code. It should just report the underlying message, with a line/column reference to the offending code. 2. The error message should quote the variable name about which it's complaining. When I initially discovered this, the variable name in question was `data`, and that was rather confusing. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Apr 29 18:21:58 2008 From: trac at galois.com (GHC) Date: Tue Apr 29 18:16:29 2008 Subject: [GHC] #1415: Provide a way to runInteractiveCommand without passing all your filedescriptors In-Reply-To: <044.b269c673165d64cf3a451e210e04330b@localhost> References: <044.b269c673165d64cf3a451e210e04330b@localhost> Message-ID: <053.8b9c39349b9bd308ac540a7bfb8d09bb@localhost> #1415: Provide a way to runInteractiveCommand without passing all your filedescriptors -------------------------------+-------------------------------------------- Reporter: igloo | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: libraries/process | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Changes (by simonmar): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Apr 29 18:42:07 2008 From: trac at galois.com (GHC) Date: Tue Apr 29 18:36:36 2008 Subject: [GHC] #2250: unpackFamily with AF_INET on Windows fails match Message-ID: <044.9136a0e7b8ebc803db4744ef0ab955c3@localhost> #2250: unpackFamily with AF_INET on Windows fails match -----------------------+---------------------------------------------------- Reporter: larsv | Owner: Type: bug | Status: new Priority: normal | Component: libraries/network Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: Windows -----------------------+---------------------------------------------------- In the HostEntry returned by Network.BSD.getHostByName, evaluating the hostFamily field causes the following error, which is pointing at the unpackFamily function: {{{ *** Exception: Network/Socket.hsc:(1711,17)-(1777,13): Non-exhaustive patterns in case }}} This occurs with 6.8.2 and 6.9.20080323 i386. The machine is running Windows Server 2008 x64. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Apr 29 18:45:13 2008 From: trac at galois.com (GHC) Date: Tue Apr 29 18:39:51 2008 Subject: [GHC] #1861: Uncompilable code generated In-Reply-To: <044.4b0f9f84f991debabab1e254e1bf05b5@localhost> References: <044.4b0f9f84f991debabab1e254e1bf05b5@localhost> Message-ID: <053.09cab044939e2592eab863b113a7ca6b@localhost> #1861: Uncompilable code generated ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by igloo): * priority: lowest => normal Comment: OK, thanks, I can reproduce this now. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Apr 29 18:49:56 2008 From: trac at galois.com (GHC) Date: Tue Apr 29 18:44:26 2008 Subject: [GHC] #2152: bogus inlining of foreign import "foo.h &foo" In-Reply-To: <047.0a1ee6738155b38bc12c1c5c56928fad@localhost> References: <047.0a1ee6738155b38bc12c1c5c56928fad@localhost> Message-ID: <056.148d29cd755767c91bab57295bfc570f@localhost> #2152: bogus inlining of foreign import "foo.h &foo" ----------------------+----------------------------------------------------- Reporter: simonmar | Owner: simonpj Type: bug | Status: new Priority: low | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonmar): * owner: => simonpj -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Apr 29 18:54:42 2008 From: trac at galois.com (GHC) Date: Tue Apr 29 18:49:19 2008 Subject: [GHC] #2249: Undeclared variable in cmm reports as panic In-Reply-To: <047.3bf0f01140bc39be71a2a471d7ca96ac@localhost> References: <047.3bf0f01140bc39be71a2a471d7ca96ac@localhost> Message-ID: <056.447fc4425ff8b259dd932e33f568bc04@localhost> #2249: Undeclared variable in cmm reports as panic ----------------------+----------------------------------------------------- Reporter: millenix | Owner: Type: bug | Status: new Priority: low | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------+----------------------------------------------------- Changes (by simonmar): * priority: normal => low * difficulty: => Unknown * milestone: => 6.10 branch Comment: I feel I should point out that GHC's .cmm compiler is not really intended to be used by anyone but us. Its diagnostics are terrible, it is almost completely undocumented, and we change it freely. Anyway, I'll milestone this for 6.10 because we'll be doing a sweep over that code. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Apr 29 19:35:59 2008 From: trac at galois.com (GHC) Date: Tue Apr 29 19:30:30 2008 Subject: [GHC] #2250: unpackFamily on Windows 2008 fails match In-Reply-To: <044.9136a0e7b8ebc803db4744ef0ab955c3@localhost> References: <044.9136a0e7b8ebc803db4744ef0ab955c3@localhost> Message-ID: <053.5e9f03231e1851faa5b287e00186ebdc@localhost> #2250: unpackFamily on Windows 2008 fails match ----------------------------------+----------------------------------------- Reporter: larsv | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/network | Version: 6.9 Severity: normal | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Windows ----------------------------------+----------------------------------------- Changes (by larsv): * summary: unpackFamily with AF_INET on Windows fails match => unpackFamily on Windows 2008 fails match Comment: The machine is dual-stack with both ipv4 and ipv6 stacks. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Apr 29 20:29:31 2008 From: trac at galois.com (GHC) Date: Tue Apr 29 20:24:00 2008 Subject: [GHC] #2251: Missing conversion rules for realToFrac causing slowdowns in Int->Double conversions Message-ID: <043.8c82860b9314968cdbf6c4c8d14295bd@localhost> #2251: Missing conversion rules for realToFrac causing slowdowns in Int->Double conversions --------------------------------------------+------------------------------- Reporter: dons | Owner: dons Type: bug | Status: new Priority: normal | Component: Runtime System Version: 6.8.2 | Severity: normal Keywords: floating point, performance | Testcase: Architecture: Unknown | Os: Unknown --------------------------------------------+------------------------------- GHC.Real and GHC.Float currently have: {{{ -- | general coercion from integral types fromIntegral :: (Integral a, Num b) => a -> b fromIntegral = fromInteger . toInteger {-# RULES "fromIntegral/Int->Int" fromIntegral = id :: Int -> Int #-} -- | general coercion to fractional types realToFrac :: (Real a, Fractional b) => a -> b realToFrac = fromRational . toRational {-# RULES "realToFrac/Int->Int" realToFrac = id :: Int -> Int #-} }}} But these avoid some primops that can make these conversions more efficient. {{{ {-# RULES "realToFrac/Int->Double" realToFrac = i2d :: Int -> Double #-} int2Double :: Int -> Double int2Double (I# x) = D# (int2Double# x) }}} A rule to use the in2Double# primop over realToFrac directly, improves the running time of this program: {{{ import Data.Array.Parallel.Unlifted main = do let c = replicateU n (2::Double) a = mapU realToFrac (enumFromToU 0 (n-1) ) :: UArr Double print (sumU (zipWithU (*) c a)) }}} From 113 seconds, to 0.194s! A massive speedup. We should fill out the rules here with at least those for which GHC has primitives: {{{ {-# RULES "realToFrac/Int->Double" realToFrac = int2Double :: Int -> Double "realToFrac/Int->Float" realToFrac = int2Float :: Int -> Float #-} }}} to the realToFrac and fromIntegral rules in GHC.Float -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 30 04:20:21 2008 From: trac at galois.com (GHC) Date: Wed Apr 30 04:14:52 2008 Subject: [GHC] #2213: Confusing flags for rewrite rules In-Reply-To: <043.a16de73b756c546cfe361c8db1abcd3b@localhost> References: <043.a16de73b756c546cfe361c8db1abcd3b@localhost> Message-ID: <052.ccac0fc145b5e85d108768e55dfd8315@localhost> #2213: Confusing flags for rewrite rules ----------------------+----------------------------------------------------- Reporter: dons | Owner: dons Type: bug | Status: assigned Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonpj): * summary: -Wall incorrectly warns "Defined but not used" for functions exported via RULES => Confusing flags for rewrite rules Comment: I agree this is totally weird, and we must fix it for 6.10. The current situation is: * RULES pragmas are discarded by the lexer unless `explicitForallEnabled` is on * `explicitForAllEnabled` is set only by the flags Ian mentions above * Those flags are set by `-fglasgow-exts` There is an '''optimisation''' flag `-frewrite-rules`, which controls whether rewrite rules are ''applied'' during optimisation. It's not meant to be a language-extension flag. We could have a '''language-extension''' flag `-XRewriteRules`, which switches on RULES in source code. (Even without it, optimisation could still use imported rules, as controlled by the optimisation flag `-frewrite-rules`.) It could be switched on by `-fglasgow-exts`. It would switch on lexing of `forall`. Presumably RULES should be ignored without `-XRewriteRules`. (Would we want a warning? And yet another warning-supression flag?) I'm a bit concerned that this would break old programs that don't use `-fglasgow- exts`, but do have `-XScopedTypeVariables` (say), by silently discarding their rewrite rules. This seems like a strong argument for adding a warning for discarded RULES. This warning would also have warned Don in the program that started this ticket. Should the optimisation flag still be called `-frewrite-rules`. I think we should re-title it `-frun-rewrite-rules` (implied by -O of course). Nothing very hard here, but better to get the design right first. Comments? Meanwhile I'll re-title the ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 30 04:55:19 2008 From: trac at galois.com (GHC) Date: Wed Apr 30 04:49:58 2008 Subject: [GHC] #2252: Extreme performance degradation on minor code change Message-ID: <045.d1b4df9f6c6e8d98e33057d0d5841a02@localhost> #2252: Extreme performance degradation on minor code change -------------------------------+-------------------------------------------- Reporter: simona | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Linux -------------------------------+-------------------------------------------- The attached code runs two similar calculations (call them '''a''' and '''b''') 1000 times. If I calculate '''a''' and then '''b''' and then do the same 1000 times again the code runs in: {{{ time ./tests/BadPerform real 0m40.429s user 0m40.360s sys 0m0.054s }}} If I run '''a''' 1000 times, then '''b''' 1000 times, the code runs in: {{{ time ./tests/GoodPerform real 0m0.083s user 0m0.081s sys 0m0.001s }}} These are the times for ghc 6.6.1. For ghc 6.8.2, the first time reduces to 34s and the second time is identical. Reproducing this bug is a bit involved: My program links to glpk which in turn uses gmp. Thus, you would have to: * install GLPK somewhere * extract the attached `sparsePolyhedra-0.1.0` cabal package * create a local copy of `libgmp` and `libglpk` in which all symbols containing '''gmp''' are renamed to '''mygmp''' * `cd` to `sparsePolyhedra-0.1.0` * in `genLibs.sh` change the paths containing `/users/absint/simona/local/lib` to where you installed GMP and GLPK * run `genLibs.sh` which will create local copies of * in `sparsePolyhedra.cabal` change the path `/users/absint/simona/current/source/sparseDomain` to the current directory * build and register the cabal package * compile the attached `BadPerform.hs` and `GoodPerform.hs` I guess this is quite complicated. I could send you the IM Core of these two files instead, if that helps. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 30 05:09:53 2008 From: trac at galois.com (GHC) Date: Wed Apr 30 05:04:25 2008 Subject: [GHC] #2251: Missing conversion rules for realToFrac causing slowdowns in Int->Double conversions In-Reply-To: <043.8c82860b9314968cdbf6c4c8d14295bd@localhost> References: <043.8c82860b9314968cdbf6c4c8d14295bd@localhost> Message-ID: <052.c52e1905ca135598cc29a959e8f13f5e@localhost> #2251: Missing conversion rules for realToFrac causing slowdowns in Int->Double conversions -----------------------------------------+---------------------------------- Reporter: dons | Owner: dons Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: floating point, performance | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------------------+---------------------------------- Changes (by simonpj): * difficulty: => Unknown Comment: Thanks Don. Would you care to offer a patch? (Don't forget to include comments that explain how big the performance improvement is; I find that giving a little program in that comment (as you do above) is a great way to capture the idea.) I gather that when you say "...at least those for which GHC has primitives" you mean that there are some important ones missing. If so, propose away. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 30 11:54:05 2008 From: trac at galois.com (GHC) Date: Wed Apr 30 11:48:31 2008 Subject: [GHC] #1969: enormous compile times In-Reply-To: <045.1ab99ac1a52ae6b35a7131dc801608a9@localhost> References: <045.1ab99ac1a52ae6b35a7131dc801608a9@localhost> Message-ID: <054.41bb4be026ec754ff07d5e92d8f4951f@localhost> #1969: enormous compile times ------------------------------------------+--------------------------------- Reporter: duncan | Owner: igloo Type: compile-time performance bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: performance | Difficulty: Difficult (1 week) Testcase: | Architecture: Multiple Os: Multiple | ------------------------------------------+--------------------------------- Changes (by igloo): * type: merge => compile-time performance bug Comment: I've merged the patch, but I think there's more work to be done here. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 30 12:23:06 2008 From: trac at galois.com (GHC) Date: Wed Apr 30 12:17:35 2008 Subject: [GHC] #1933: Zero times in profiling with GHC-6.8.1 In-Reply-To: <056.353a18a91ecfd8fecb6c03c68c7e7fde@localhost> References: <056.353a18a91ecfd8fecb6c03c68c7e7fde@localhost> Message-ID: <065.22af26f6f28eec08ce4da31390581b55@localhost> #1933: Zero times in profiling with GHC-6.8.1 -------------------------------+-------------------------------------------- Reporter: daniel.is.fischer | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.8.3 Component: Profiling | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | -------------------------------+-------------------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: Ok, I've added that as the autoconf test, so hopefully it should detect that your system has a non-working timer_create(). I don't understand why the earlier patch didn't work, but still. To merge: {{{ ue Apr 29 14:29:45 PDT 2008 Simon Marlow * FIX #1933: use a better test for timer_create() }}} Also Igloo: just as a sanity check could you make sure that after this patch configure is still detecting a working timer_create() on your systems? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 30 12:30:49 2008 From: trac at galois.com (GHC) Date: Wed Apr 30 12:25:16 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.81e1133385aa7123d99153d3258b0dd2@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: normal | Milestone: 6.8.3 Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: hsetbuffering buffering buffer | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | --------------------------------------------+------------------------------- Changes (by simonmar): * priority: low => normal Comment: This is important to folks here at Galois; I'll try to look at it before 6.8.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 30 12:49:47 2008 From: trac at galois.com (GHC) Date: Wed Apr 30 12:44:14 2008 Subject: [GHC] #2247: GHC accepts FD violations, unless the conflicing instances are used In-Reply-To: <044.b5dc7ac6137d6de05ce0c6a9f5daf089@localhost> References: <044.b5dc7ac6137d6de05ce0c6a9f5daf089@localhost> Message-ID: <053.5655af44102033a0336161a4f993abc0@localhost> #2247: GHC accepts FD violations, unless the conflicing instances are used ----------------------------------------+----------------------------------- Reporter: claus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: TF vs FD | Testcase: Architecture: Unknown | Os: Unknown ----------------------------------------+----------------------------------- Comment (by claus): here is a slight variation that does not rely on a GHCi session to raise the issue {{{ module Improve where class FD a b | a -> b instance CFD a b => FD a b class {- FD a b => -} CFD a b instance CFD Bool Char instance CFD Bool Bool f' :: FD Bool Bool => Bool f' = True g' :: FD Bool Char => Bool g' = False x = f' }}} {{{ module Main where import Improve y = g' main = print (x,y) }}} GHC (6.9.20080217) accepts this, and the executable outputs `(True,False)`, even though the first component depends on `instance FD Bool Bool` while the second depends on `instance FD Bool Char`. Inlining `x` as `f'` is sufficient to raise the expected error message. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 30 14:00:40 2008 From: trac at galois.com (GHC) Date: Wed Apr 30 13:55:08 2008 Subject: [GHC] #2251: Missing conversion rules for realToFrac causing slowdowns in Int->Double conversions In-Reply-To: <043.8c82860b9314968cdbf6c4c8d14295bd@localhost> References: <043.8c82860b9314968cdbf6c4c8d14295bd@localhost> Message-ID: <052.2a49a080bc99ec1b0d76878dfee16980@localhost> #2251: Missing conversion rules for realToFrac causing slowdowns in Int->Double conversions -----------------------------------------+---------------------------------- Reporter: dons | Owner: dons Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: floating point, performance | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------------------+---------------------------------- Changes (by dons): * status: new => closed * resolution: => fixed Comment: I've pushed a patch adding the rules for Int->Double and Int->Float. See: http://www.haskell.org/pipermail/cvs-libraries/2008-April/008493.html -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 30 15:04:00 2008 From: trac at galois.com (GHC) Date: Wed Apr 30 14:58:26 2008 Subject: [GHC] #2148: x86_64 code use several GiB of memory generates: internal error: ASSERTION FAILED: file sm/Storage.c, line 1126 In-Reply-To: <049.51a60eabf072f65f71f65ffe2a95214c@localhost> References: <049.51a60eabf072f65f71f65ffe2a95214c@localhost> Message-ID: <058.4ae6e6c5516558482a4dac0a90e45192@localhost> #2148: x86_64 code use several GiB of memory generates: internal error: ASSERTION FAILED: file sm/Storage.c, line 1126 ----------------------------+----------------------------------------------- Reporter: twhitehead | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.8.3 Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------------+----------------------------------------------- Changes (by simonmar): * priority: normal => high -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 30 15:19:40 2008 From: trac at galois.com (GHC) Date: Wed Apr 30 15:14:08 2008 Subject: [GHC] #2253: Native code generator could do better Message-ID: <043.862f2d1bf55b0e0d2dddbf6af3659352@localhost> #2253: Native code generator could do better -----------------------------------------+---------------------------------- Reporter: dons | Owner: Type: run-time performance bug | Status: new Priority: normal | Component: Compiler (NCG) Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Unknown -----------------------------------------+---------------------------------- An example set of programs that came up in the ndp library, where the C backend outperforms the current native code generator. Logging them here so we don't forget to check again with the new backend. == Program 1 == {{{ import Data.Array.Vector import Data.Bits main = print . sumU $ zipWith3U (\x y z -> x * y * z) (enumFromToU 1 (100000000 :: Int)) (enumFromToU 2 (100000001 :: Int)) (enumFromToU 7 (100000008 :: Int)) }}} Core: {{{ Main.$s$wfold = \ (sc_sPH :: Int#) (sc1_sPI :: Int#) (sc2_sPJ :: Int#) (sc3_sPK :: Int#) -> case ># sc2_sPJ 100000000 of wild_aJo { False -> case ># sc1_sPI 100000001 of wild1_XK6 { False -> case ># sc_sPH 100000008 of wild2_XKd { False -> Main.$s$wfold (+# sc_sPH 1) (+# sc1_sPI 1) (+# sc2_sPJ 1) (+# sc3_sPK (*# (*# sc2_sPJ sc1_sPI) sc_sPH)); True -> sc3_sPK }; True -> sc3_sPK }; True -> sc3_sPK } }}}} Which is great. C backend: {{{ Main_zdszdwfold_info: .text .p2align 4,,15 .text .align 8 .type Main_zdszdwfold_info, @function cmpq $100000000, %r8 jg .L9 cmpq $100000001, %rdi jg .L9 cmpq $100000008, %rsi jg .L9 movq %r8, %rdx incq %r8 imulq %rdi, %rdx incq %rdi imulq %rsi, %rdx incq %rsi addq %rdx, %r9 jmp Main_zdszdwfold_info .L5: .L7: .p2align 6,,7 .L9: movq %r9, %rbx jmp *(%rbp) }}} Native code generator: {{{ Main_zdszdwfold_info: cmpq $100000000,%r8 jg .LcRP cmpq $100000001,%rdi jg .LcRR cmpq $100000008,%rsi jg .LcRU movq %rdi,%rax imulq %rsi,%rax movq %r8,%rcx imulq %rax,%rcx movq %r9,%rax addq %rcx,%rax leaq 1(%r8),%rcx leaq 1(%rdi),%rdx incq %rsi movq %rdx,%rdi movq %rcx,%r8 movq %rax,%r9 jmp Main_zdszdwfold_info .LcRP: movq %r9,%rbx jmp *(%rbp) .LcRR: movq %r9,%rbx jmp *(%rbp) .LcRU: movq %r9,%rbx jmp *(%rbp) }}} Runtime performance: C backend: 0.269 Asm backend: 0.410s == Program 2 == Source: {{{ import Data.Array.Vector import Data.Bits main = print . sumU . mapU (`shiftL` 2) $ appendU (replicateU 1000000000 (1::Int)) (replicateU 1000000000 (7::Int)) }}} Core: {{{ $s$wfold_rPr = \ (sc_sOw :: Int#) (sc1_sOx :: Int#) -> case sc_sOw of wild_X1j { __DEFAULT -> $s$wfold_rPr (+# wild_X1j 1) (+# sc1_sOx 28); 1000000000 -> sc1_sOx } }}} Runtime: Native backend: 2.637 C backend: 2.365 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 30 15:30:02 2008 From: trac at galois.com (GHC) Date: Wed Apr 30 15:24:28 2008 Subject: [GHC] #2136: Not warned about unused recursive bindings In-Reply-To: <044.36da76cdb274dec6c2086dc5b0767ee6@localhost> References: <044.36da76cdb274dec6c2086dc5b0767ee6@localhost> Message-ID: <053.48fc662abedababd60acc5bbaf4aabe1@localhost> #2136: Not warned about unused recursive bindings ----------------------+----------------------------------------------------- Reporter: igloo | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: rn063 | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: This doesn't merge cleanly, and I (the reporter) don't think it's very important for 6.8.3, so I'm closing it as it's fixed in the HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 30 15:34:47 2008 From: trac at galois.com (GHC) Date: Wed Apr 30 15:29:14 2008 Subject: [GHC] #2137: Location of shadowed binding is wrong in warning In-Reply-To: <044.44ee490b4171e22911243bf12a9d127e@localhost> References: <044.44ee490b4171e22911243bf12a9d127e@localhost> Message-ID: <053.50ccd9d348480c1d5edd17f1f0458b51@localhost> #2137: Location of shadowed binding is wrong in warning ----------------------+----------------------------------------------------- Reporter: igloo | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: rn064 | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Test now passes correctly. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 30 16:18:41 2008 From: trac at galois.com (GHC) Date: Wed Apr 30 16:13:11 2008 Subject: [GHC] #2253: Native code generator could do better In-Reply-To: <043.862f2d1bf55b0e0d2dddbf6af3659352@localhost> References: <043.862f2d1bf55b0e0d2dddbf6af3659352@localhost> Message-ID: <052.1472f3823365cb624955c6a03c56135a@localhost> #2253: Native code generator could do better -----------------------------------------+---------------------------------- Reporter: dons | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Multiple | Os: Unknown -----------------------------------------+---------------------------------- Changes (by dons): * architecture: x86_64 (amd64) => Multiple Comment: == Program 3 == Source: {{{ import Data.Array.Vector main = print . sumU . consU 0xdeadbeef . replicateU (100000000::Int) $ (8::Int) }}} Core: {{{ Main.$s$wfold = \ (sc_sMc :: Int#) (sc1_sMd :: Int#) -> case sc_sMc of wild_X13 { __DEFAULT -> Main.$s$wfold (+# wild_X13 1) (+# sc1_sMd 8); 100000000 -> sc1_sMd } }}} Native backend: {{{ Main_zdszdwfold_info: movq %rsi,%rax cmpq $100000000,%rax jne .LcND movq %rdi,%rbx jmp *(%rbp) .LcND: leaq 8(%rdi),%rcx leaq 1(%rax),%rsi movq %rcx,%rdi jmp Main_zdszdwfold_info }}} C backend: {{{ Main_zdszdwfold_info: cmpq $100000000, %rsi je .L5 .L3: leaq 1(%rsi), %rsi addq $8, %rdi jmp Main_zdszdwfold_info .L5: movq %rdi, %rbx jmp *(%rbp) }}} Runtime: Native backend: 0.143 C backend: 0.120 == Program 4 == Source: {{{ import Data.Array.Vector import Data.Bits main = print . sumU . mapU (`shiftL` 1) . filterU (<20). mapU (*2) . mapU (+1) . replicateU (100000000::Int) $ (8::Int) }}} Core: {{{ Main.$wfold = \ (ww_sNZ :: Int#) (ww1_sO3 :: Int#) -> case ww1_sO3 of wild_X1j { __DEFAULT -> Main.$wfold (+# ww_sNZ 36) (+# wild_X1j 1); 100000000 -> ww_sNZ } }}} (Ridiculously awesome!) Native backend: {{{ Main_zdwfold_info: movq %rdi,%rax cmpq $100000000,%rax jne .LcPY movq %rsi,%rbx jmp *(%rbp) .LcPY: incq %rax addq $36,%rsi movq %rax,%rdi jmp Main_zdwfold_info }}} C backend: {{{ Main_zdwfold_info: cmpq $100000000, %rdi je .L5 .L3: addq $36, %rsi leaq 1(%rdi), %rdi jmp Main_zdwfold_info .L5: movq %rsi, %rbx jmp *(%rbp) }}} Runtime: C backend: 0.120s Native backend: 0.195s == Program 5 == Source: {{{ import Data.Array.Vector import Data.Bits main = print . sumU . mapU fstS $ zipU (enumFromToU 1 (100000000 :: Int)) (enumFromToU 2 (100000001 :: Int)) }}} Core: {{{ Main.$s$wfold = \ (sc_sRJ :: Int#) (sc1_sRK :: Int#) (sc2_sRL :: Int#) -> case ># sc1_sRK 100000000 of wild_aM2 { False -> case ># sc_sRJ 100000001 of wild1_XMw { False -> Main.$s$wfold (+# sc_sRJ 1) (+# sc1_sRK 1) (+# sc2_sRL sc1_sRK); True -> sc2_sRL }; True -> sc2_sRL } }}} Native backend: {{{ Main_zdszdwfold_info: cmpq $100000000,%rdi jg .LcTr cmpq $100000001,%rsi jg .LcTu movq %r8,%rax addq %rdi,%rax leaq 1(%rdi),%rcx incq %rsi movq %rcx,%rdi movq %rax,%r8 jmp Main_zdszdwfold_info .LcTr: movq %r8,%rbx jmp *(%rbp) .LcTu: movq %r8,%rbx jmp *(%rbp) }}} C backend: {{{ Main_zdszdwfold_info: cmpq $100000000, %rdi jg .L5 cmpq $100000001, %rsi jg .L5 leaq (%rdi,%r8), %rax incq %rsi incq %rdi movq %rax, %r8 jmp Main_zdszdwfold_info .L3: .L5: movq %r8, %rbx jmp *(%rbp) }}} Runtime: Native backend: 0.216 C backend: 0.194 == Program 6 == Source: {{{ n = 40000000 main = do let c = replicateU n (2::Double) a = mapU fromIntegral (enumFromToU 0 (n-1) ) :: UArr Double print (sumU (zipWithU (*) c a)) }}} Core {{{ Main.$s$wfold = \ (sc_sXT :: Int#) (sc1_sXU :: Int#) (sc2_sXV :: Double#) -> case sc1_sXU of wild_X1h { __DEFAULT -> case ># sc_sXT 39999999 of wild1_aMi { False -> Main.$s$wfold (+# sc_sXT 1) (+# wild_X1h 1) (+## sc2_sXV (*## 2.0 (int2Double# sc_sXT))); True -> sc2_sXV }; 40000000 -> sc2_sXV } }}} Native backend: {{{ Main_zdszdwfold_info: movq %rdi,%rax cmpq $40000000,%rax jne .LcZK jmp *(%rbp) .LcZK: cmpq $39999999,%rsi jg .LcZN cvtsi2sdq %rsi,%xmm0 mulsd .LnZP(%rip),%xmm0 movsd %xmm5,%xmm7 addsd %xmm0,%xmm7 incq %rax incq %rsi movq %rax,%rdi movsd %xmm7,%xmm5 jmp Main_zdszdwfold_info .LcZN: jmp *(%rbp) }}} C backend: {{{ Main_zdszdwfold_info: cmpq $40000000, %rdi je .L9 .L5: cmpq $39999999, %rsi jg .L9 cvtsi2sdq %rsi, %xmm0 leaq 1(%rdi), %rdi incq %rsi addsd %xmm0, %xmm0 addsd %xmm0, %xmm5 jmp Main_zdszdwfold_info .L9: jmp *(%rbp) }}} Runtime: Native backend: 0.192 C backend: 0.142 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 30 17:10:35 2008 From: trac at galois.com (GHC) Date: Wed Apr 30 17:05:20 2008 Subject: [GHC] #1780: runInteractiveProcess broken with >2 processes on POSIX In-Reply-To: <044.d5b4cf5d496c65f6f766ac301f4fef42@localhost> References: <044.d5b4cf5d496c65f6f766ac301f4fef42@localhost> Message-ID: <053.98835781b885f86c3b88a5f102cdbd70@localhost> #1780: runInteractiveProcess broken with >2 processes on POSIX -------------------------------+-------------------------------------------- Reporter: guest | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.8.3 Component: libraries/process | Version: 6.6.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Both merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 30 17:13:35 2008 From: trac at galois.com (GHC) Date: Wed Apr 30 17:08:02 2008 Subject: [GHC] #1933: Zero times in profiling with GHC-6.8.1 In-Reply-To: <056.353a18a91ecfd8fecb6c03c68c7e7fde@localhost> References: <056.353a18a91ecfd8fecb6c03c68c7e7fde@localhost> Message-ID: <065.447e94346e75c5ace57840433e428824@localhost> #1933: Zero times in profiling with GHC-6.8.1 -------------------------------+-------------------------------------------- Reporter: daniel.is.fischer | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.8.3 Component: Profiling | Version: 6.8.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged, and looks good: {{{ checking for timer_create... yes checking for timer_settime... yes checking for a working timer_create(CLOCK_REALTIME)... yes }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 30 17:41:38 2008 From: trac at galois.com (GHC) Date: Wed Apr 30 17:36:51 2008 Subject: [GHC] #2252: Extreme performance degradation on minor code change In-Reply-To: <045.d1b4df9f6c6e8d98e33057d0d5841a02@localhost> References: <045.d1b4df9f6c6e8d98e33057d0d5841a02@localhost> Message-ID: <054.f340798885a57a6ab6fbd9182762c032@localhost> #2252: Extreme performance degradation on minor code change ----------------------+----------------------------------------------------- Reporter: simona | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------+----------------------------------------------------- Changes (by simonpj): * difficulty: => Unknown Comment: That is odd, I grant you. However your code repeats the same computation 1000 times. That computation is in the I/O monad, ''but it does no I/O'' (or at least only outside the loop). Hence a clever optimiser might spot that it must give the same result every time, and compute that result just once. I bet that is what is happening here. The "clever optimiser" may be somehow put off the scent by the minor change in structure of your program -- without more info I couldn't say exactly why. If I'm right, then it's arguably bad that a minor change could make such a big performance difference. But repeating an identical computation 1000 times is equally arguably not something that a compiler should be robustly optimising for. Of course I could be on the wrong track. Try `-ddump-simpl` and attach the output from that. You might like to look into that output for top- level definitions that look like `lvl_*`; these are the ones floated of loops. Also try `-fno-full-laziness` to switch off the full laziness transformation, and see if that make Good perform the same as Bad. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 30 17:45:28 2008 From: trac at galois.com (GHC) Date: Wed Apr 30 17:39:54 2008 Subject: [GHC] #2251: Missing conversion rules for realToFrac causing slowdowns in Int->Double conversions In-Reply-To: <043.8c82860b9314968cdbf6c4c8d14295bd@localhost> References: <043.8c82860b9314968cdbf6c4c8d14295bd@localhost> Message-ID: <052.5e7e4e9f0187dd43333f4b90638c2bfa@localhost> #2251: Missing conversion rules for realToFrac causing slowdowns in Int->Double conversions -----------------------------------------+---------------------------------- Reporter: dons | Owner: dons Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: floating point, performance | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------------------+---------------------------------- Comment (by simonpj): Thanks! I've found that comments in source files are more often read than those in patch messages, so I've transferred some of your comments into the source file itself. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 30 19:50:40 2008 From: trac at galois.com (GHC) Date: Wed Apr 30 19:45:05 2008 Subject: [GHC] #2254: have Control.Arrow re-export (>>>) and (<<<) Message-ID: <043.08bb6362803b2111fd61efa7055513a2@localhost> #2254: have Control.Arrow re-export (>>>) and (<<<) -------------------------+-------------------------------------------------- Reporter: ross | Owner: Type: proposal | Status: new Priority: normal | Component: libraries/base Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- #1773 split the Arrow class, making (>>>) and (<<<) functions in Control.Category. This breaks programs that use Control.Arrow. To avoid some of the breakage, the proposal is that Control.Arrow should re-export (>>>) and (<<<), imported from Control.Category. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 30 19:53:44 2008 From: trac at galois.com (GHC) Date: Wed Apr 30 19:48:09 2008 Subject: [GHC] #2204: Improve 'patterns not matched' warnings In-Reply-To: <047.57470c7515f5d78414f8813f455c57a5@localhost> References: <047.57470c7515f5d78414f8813f455c57a5@localhost> Message-ID: <056.34ce82cb2cf1201a87951847547a3d55@localhost> #2204: Improve 'patterns not matched' warnings -----------------------------+---------------------------------------------- Reporter: Deewiant | Owner: Type: feature request | Status: new Priority: low | Milestone: _|_ Component: Compiler | Version: 6.8.2 Severity: trivial | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -----------------------------+---------------------------------------------- Changes (by ross): * type: proposal => feature request -- Ticket URL: GHC The Glasgow Haskell Compiler