From trac at galois.com Mon Feb 1 05:34:58 2010 From: trac at galois.com (GHC) Date: Mon Feb 1 05:06:37 2010 Subject: [GHC] #3851: type family does not get expanded in ghc-6.12.1 Message-ID: <047.9b73a510640cabe71061dde181079f57@abbot.galois.com> #3851: type family does not get expanded in ghc-6.12.1 ---------------------------------+------------------------------------------ Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 6.12.1 | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: GHC rejects valid program ---------------------------------+------------------------------------------ The following code (which is a trimmed down version of an application of the multirec library) does not compile on ghc-6.12.1, but it does with ghc-6.10.4. Why? {{{ {-# LANGUAGE GADTs, TypeFamilies #-} type family TF a :: * -> * type instance TF () = App (Equ ()) data Equ ix ix' where Refl :: Equ ix ix data App f x = App (f x) -- does not typecheck in 6.12.1 (but works in 6.10.4) bar :: TF () () -> () bar (App Refl) = () -- does typecheck in 6.12.1 and 6.10.4 ar :: App (Equ ()) () -> () ar (App Refl) = () }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 1 06:55:33 2010 From: trac at galois.com (GHC) Date: Mon Feb 1 06:27:10 2010 Subject: [GHC] #3852: Building GHC 6.12.1 with Cabal 1.9.0 installed Message-ID: <047.f658e84343f0f5a46a74754708d40840@abbot.galois.com> #3852: Building GHC 6.12.1 with Cabal 1.9.0 installed ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.2 Component: Build System | Version: 6.12.1 Keywords: | Difficulty: Easy (less than 1 hour) Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Building GHC failed ---------------------------------+------------------------------------------ Reported by Nicolas Martyanoff `` on glasgow-haskell- users. I expect the build system is picking up Cabal 1.9.0 in preference to the version in the source tree. ---- I thought it might be good to build GHC 6.12.1 with itself just to be sure it's working fine before make a dist, but I now get the following error: {{{ "/usr/local/bin/ghc" -H32m -O -package-conf libraries/bootstrapping.conf -package-name ghc-6.12.1 -hide-all-packages -i -icompiler/nativeGen -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/cprAnalysis -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/main -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage1/build -icompiler/stage1/build/autogen -Icompiler/stage1/build -Icompiler/stage1/build/autogen -Icompiler/stage1 -Icompiler/../libraries/base/cbits -Icompiler/../libraries/base/include -Icompiler/. -Icompiler/parser -Icompiler/utils -optP-include -optPcompiler/stage1/build/autogen/cabal_macros.h -package Cabal-1.9.0 -package array-0.3.0.0 -package base-4.2.0.0 -package bin-package- db-0.0.0.0 -package bytestring-0.9.1.5 -package containers-0.3.0.0 -package directory-1.0.1.0 -package filepath-1.1.0.3 -package hpc-0.5.0.4 -package old-time-1.0.0.3 -package process-1.0.1.2 -package unix-2.4.0.0 -DSTAGE=1 -Wall -fno-warn-name-shadowing -fno-warn-orphans -XCPP -XMagicHash -XUnboxedTuples -XPatternGuards -XForeignFunctionInterface -XEmptyDataDecls -XTypeSynonymInstances -XMultiParamTypeClasses -XFlexibleInstances -XRank2Types -XScopedTypeVariables -XDeriveDataTypeable -XRelaxedPolyRec -odir compiler/stage1/build -hidir compiler/stage1/build -stubdir compiler/stage1/build -hisuf hi -osuf o -hcsuf hc -c compiler/main/Packages.lhs -o compiler/stage1/build/Packages.o compiler/main/Packages.lhs:233:63: Couldn't match expected type `InstalledPackageInfo_ String' against inferred type `Cabal-1.8.0.2:Distribution.InstalledPackageInfo.InstalledPackageInfo_ m' Expected type: [InstalledPackageInfo_ String] Inferred type: [Cabal-1.8.0.2:Distribution.InstalledPackageInfo.InstalledPackageInfo_ m] In the second argument of `map', namely `conf' In the first argument of `return', namely `(map installedPackageInfoToPackageConfig conf)' gmake[1]: *** [compiler/stage1/build/Packages.o] Error 1 gmake: *** [all] Error 2 }}} I tried to "ghc-pkg mask" Cabal-1.8.0.2, then Cabal-1.9.0, didn't change anything. Does someone know what's going on here, and what can be done to fix it ? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 1 09:44:11 2010 From: trac at galois.com (GHC) Date: Mon Feb 1 09:15:49 2010 Subject: [GHC] #3852: Building GHC 6.12.1 with Cabal 1.9.0 installed In-Reply-To: <047.f658e84343f0f5a46a74754708d40840@abbot.galois.com> References: <047.f658e84343f0f5a46a74754708d40840@abbot.galois.com> Message-ID: <056.1383ccfe1972796f8f5c5ccd7065d0cb@abbot.galois.com> #3852: Building GHC 6.12.1 with Cabal 1.9.0 installed ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.2 Component: Build System | Version: 6.12.1 Keywords: | Difficulty: Easy (less than 1 hour) Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Building GHC failed ---------------------------------+------------------------------------------ Comment(by galdor): I just got the exact same result on a Linux x86_64 platform, so it's really platform/os independant. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 1 23:03:52 2010 From: trac at galois.com (GHC) Date: Mon Feb 1 22:35:29 2010 Subject: [GHC] #3658: Dynamically link GHCi on platforms that support it In-Reply-To: <047.129d39e2608fc274aa7ba90c094c6a82@abbot.galois.com> References: <047.129d39e2608fc274aa7ba90c094c6a82@abbot.galois.com> Message-ID: <056.cc68afd60f085b822c5a5ba975156e42@abbot.galois.com> #3658: Dynamically link GHCi on platforms that support it ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: task | Status: new Priority: high | Milestone: 6.14.1 Component: GHCi | Version: 6.10.4 Keywords: | Difficulty: Unknown Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Changes (by PHO): * cc: pho@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 1 23:16:02 2010 From: trac at galois.com (GHC) Date: Mon Feb 1 22:50:18 2010 Subject: [GHC] #1007: Add parsing (and some more) to the time package In-Reply-To: <062.66343fec3008d814f93042c54e27472f@abbot.galois.com> References: <062.66343fec3008d814f93042c54e27472f@abbot.galois.com> Message-ID: <071.0b39608a5ed7f44006c752f2f8fa268c@abbot.galois.com> #1007: Add parsing (and some more) to the time package ----------------------------------------+----------------------------------- Reporter: bringert@? | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: Keywords: | Difficulty: Unknown Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ----------------------------------------+----------------------------------- Changes (by PHO): * cc: pho@? (added) * failure: => None/Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 1 23:19:50 2010 From: trac at galois.com (GHC) Date: Mon Feb 1 22:51:54 2010 Subject: [GHC] #2578: "ld: atom sorting error for ..." on OS X In-Reply-To: <044.426e3c7e28718ff62aa1ff6b2d89715c@abbot.galois.com> References: <044.426e3c7e28718ff62aa1ff6b2d89715c@abbot.galois.com> Message-ID: <053.6f294d6ba3845c703575bb3b2002e53c@abbot.galois.com> #2578: "ld: atom sorting error for ..." on OS X ---------------------------------+------------------------------------------ Reporter: igloo | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.12.2 Component: Compiler | Version: 6.10.4 Keywords: | Difficulty: Unknown Os: MacOS X | Testcase: Architecture: Unknown/Multiple | Failure: Incorrect warning at compile-time ---------------------------------+------------------------------------------ Changes (by PHO): * cc: pho@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 1 23:21:08 2010 From: trac at galois.com (GHC) Date: Mon Feb 1 22:52:43 2010 Subject: [GHC] #781: GHCi on x86_64, cannot link to static data in shared libs In-Reply-To: <044.a73c522b97030f99c5fa39d521657f06@abbot.galois.com> References: <044.a73c522b97030f99c5fa39d521657f06@abbot.galois.com> Message-ID: <053.7ac388948700843a2e0e6b139006581e@abbot.galois.com> #781: GHCi on x86_64, cannot link to static data in shared libs -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: high | Milestone: 6.14.1 Component: Compiler | Version: 6.5 Keywords: getEnvironment | Difficulty: Unknown Os: Linux | Testcase: getEnvironment01 Architecture: x86_64 (amd64) | Failure: GHCi crash -------------------------------+-------------------------------------------- Changes (by PHO): * cc: pho@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 1 23:21:49 2010 From: trac at galois.com (GHC) Date: Mon Feb 1 22:53:24 2010 Subject: [GHC] #3837: hsc2hs and utf-8 In-Reply-To: <052.70cf87bf85ce9569a1df195436a13aa0@abbot.galois.com> References: <052.70cf87bf85ce9569a1df195436a13aa0@abbot.galois.com> Message-ID: <061.df25e667aa55caff6a523846bc0b7768@abbot.galois.com> #3837: hsc2hs and utf-8 ---------------------------------+------------------------------------------ Reporter: TaruKarttunen | Owner: Type: bug | Status: new Priority: normal | Component: hsc2hs Version: 6.12.1 | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Changes (by PHO): * cc: pho@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 1 23:25:25 2010 From: trac at galois.com (GHC) Date: Mon Feb 1 22:57:09 2010 Subject: [GHC] #3654: Mach-O GHCi linker lacks support for a range of relocation entries In-Reply-To: <043.db5a4c9ebf484eb57b87a6d38bef8362@abbot.galois.com> References: <043.db5a4c9ebf484eb57b87a6d38bef8362@abbot.galois.com> Message-ID: <052.65a47b64673612a2ad9ec97cfac02b15@abbot.galois.com> #3654: Mach-O GHCi linker lacks support for a range of relocation entries ---------------------------------+------------------------------------------ Reporter: chak | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Runtime System | Version: 6.13 Keywords: | Difficulty: Unknown Os: MacOS X | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Changes (by PHO): * cc: pho@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 1 23:27:03 2010 From: trac at galois.com (GHC) Date: Mon Feb 1 22:58:48 2010 Subject: [GHC] #3550: Dynamic libraries don't work on Mac OS/X In-Reply-To: <056.c6f0034a4d5f342c60f11476270241e0@abbot.galois.com> References: <056.c6f0034a4d5f342c60f11476270241e0@abbot.galois.com> Message-ID: <065.13955226bf27fdc3e9703be620a32b74@abbot.galois.com> #3550: Dynamic libraries don't work on Mac OS/X ----------------------------------+----------------------------------------- Reporter: StephenBlackheath | Owner: StephenBlackheath Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: Compiler | Version: 6.11 Keywords: dynamic mac osx | Difficulty: Unknown Os: MacOS X | Testcase: http://upcycle.it/~blackh/ghc/test-case.tar.bz2 Architecture: Unknown/Multiple | Failure: None/Unknown ----------------------------------+----------------------------------------- Changes (by PHO): * cc: pho@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 1 23:37:29 2010 From: trac at galois.com (GHC) Date: Mon Feb 1 23:09:06 2010 Subject: [GHC] #698: GHC's internal memory allocator never releases memory back to the OS In-Reply-To: <044.7b3e64b5d690837bd58d2f69df4bfac4@abbot.galois.com> References: <044.7b3e64b5d690837bd58d2f69df4bfac4@abbot.galois.com> Message-ID: <053.87d65d9ff3d34374bfc53608c98f3f18@abbot.galois.com> #698: GHC's internal memory allocator never releases memory back to the OS ---------------------------------+------------------------------------------ Reporter: guest | Owner: igloo Type: bug | Status: new Priority: low | Milestone: 6.12 branch Component: Runtime System | Version: 6.4.1 Keywords: | Difficulty: Moderate (less than a day) Os: Unknown/Multiple | Testcase: N/A Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Changes (by PHO): * cc: pho@? (added) * failure: => None/Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 2 02:18:55 2010 From: trac at galois.com (GHC) Date: Tue Feb 2 01:50:37 2010 Subject: [GHC] #3850: EmptyDataDecls and type context In-Reply-To: <049.f27f0f58200e17d4e5b9ff32a4c6b128@abbot.galois.com> References: <049.f27f0f58200e17d4e5b9ff32a4c6b128@abbot.galois.com> Message-ID: <058.7d94ac6d7ed4dc4e28d2d59d14529abf@abbot.galois.com> #3850: EmptyDataDecls and type context ---------------------------------+------------------------------------------ Reporter: Paczesiowa | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.12.1 Keywords: emptydatadecls | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: GHC rejects valid program ---------------------------------+------------------------------------------ Comment(by simonpj): Why do you want this? It's utterly useless. Contexts on data declarations are a mis-feature of Haskell, and are especially useless when there are no constructors. Can't you just delete it? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 2 02:25:35 2010 From: trac at galois.com (GHC) Date: Tue Feb 2 01:57:10 2010 Subject: [GHC] #3831: SpecConstr should exploit cases where there is exactly one call pattern (was: GHC uses too much memory compiling terminfo) In-Reply-To: <044.5fe60f4f535f1251caca48895d45a780@abbot.galois.com> References: <044.5fe60f4f535f1251caca48895d45a780@abbot.galois.com> Message-ID: <053.856496239476e64126c44288485f7ad6@abbot.galois.com> #3831: SpecConstr should exploit cases where there is exactly one call pattern ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.2 Component: Compiler | Version: 6.13 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: simplCore/should_compile/T3831 Architecture: Unknown/Multiple | Failure: Compile-time performance bug ---------------------------------+------------------------------------------ Changes (by simonpj): * testcase: => simplCore/should_compile/T3831 Comment: I've fixed the blowup with {{{ Mon Feb 1 00:24:20 GMT Standard Time 2010 simonpj@microsoft.com * Fix Trac #3831: blowup in SpecConstr It turned out that there were two bugs. First, we were getting an exponential number of specialisations when we had a deep nest of join points. See Note [Avoiding exponential blowup]. I fixed this by dividing sc_count (in ScEnv) by the number of specialisations when recursing. Crude but effective. Second, when making specialisations I was looking at the result of applying specExpr to the RHS of the function, whereas I should have been looking at the original RHS. See Note [Specialise original body]. There's a tantalising missed opportunity here, though. In this example (recorded as a test simplCore/should_compile/T3831), each join point has *exactly one* call pattern, so we should really just specialise for that alone, in which case there's zero code-blow-up. In particular, we don't need the *original* RHS at all. I need to think more about how to exploit this. But the blowup is now limited, so compiling terminfo with -O2 works again. }}} I'm going to leave the ticket open because of the "tantalising opportunity", but I'll retitle it. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 2 03:32:00 2010 From: trac at galois.com (GHC) Date: Tue Feb 2 03:03:48 2010 Subject: [GHC] #3840: ghc-6.12.1 takes longer to compile code and produces bigger binaries compared to ghc-6.10.4 In-Reply-To: <045.ee0c11e517a19af640fa74e960df89c8@abbot.galois.com> References: <045.ee0c11e517a19af640fa74e960df89c8@abbot.galois.com> Message-ID: <054.eef61d2eadd63e38cf5497c47fab9fc4@abbot.galois.com> #3840: ghc-6.12.1 takes longer to compile code and produces bigger binaries compared to ghc-6.10.4 -------------------------+-------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.12.1 Keywords: | Difficulty: Os: Linux | Testcase: Architecture: x86 | Failure: None/Unknown -------------------------+-------------------------------------------------- Comment(by maeder): I should mention that all instances in our ATC-files are "orphan". -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 2 04:21:32 2010 From: trac at galois.com (GHC) Date: Tue Feb 2 03:53:06 2010 Subject: [GHC] #3831: SpecConstr should exploit cases where there is exactly one call pattern In-Reply-To: <044.5fe60f4f535f1251caca48895d45a780@abbot.galois.com> References: <044.5fe60f4f535f1251caca48895d45a780@abbot.galois.com> Message-ID: <053.2692062bd3e8f9024c7b54a365cca501@abbot.galois.com> #3831: SpecConstr should exploit cases where there is exactly one call pattern ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.2 Component: Compiler | Version: 6.13 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: simplCore/should_compile/T3831 Architecture: Unknown/Multiple | Failure: Compile-time performance bug ---------------------------------+------------------------------------------ Comment(by simonmar): Does the bug need fixing in the 6.12 branch, or should it be re- milestoned? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 2 07:35:04 2010 From: trac at galois.com (GHC) Date: Tue Feb 2 07:06:40 2010 Subject: [GHC] #3848: Error message typo in rts/RtsAPI.c In-Reply-To: <044.0702ff6eeab4c6d918d0c693dbbdade1@abbot.galois.com> References: <044.0702ff6eeab4c6d918d0c693dbbdade1@abbot.galois.com> Message-ID: <053.b776258ead9184a83138e3627c352bf5@abbot.galois.com> #3848: Error message typo in rts/RtsAPI.c ---------------------------------+------------------------------------------ Reporter: larsv | Owner: igloo Type: merge | Status: new Priority: high | Milestone: 6.12.2 Component: Runtime System | Version: 6.12.1 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: simonmar => igloo * status: assigned => new * type: bug => merge Comment: Fixed: {{{ Sat Jan 30 01:46:28 PST 2010 Simon Marlow * Fix typo in error message (#3848) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 2 10:30:01 2010 From: trac at galois.com (GHC) Date: Tue Feb 2 10:01:44 2010 Subject: [GHC] #3850: EmptyDataDecls and type context In-Reply-To: <049.f27f0f58200e17d4e5b9ff32a4c6b128@abbot.galois.com> References: <049.f27f0f58200e17d4e5b9ff32a4c6b128@abbot.galois.com> Message-ID: <058.3ba48783a803679cac810efebaea4122@abbot.galois.com> #3850: EmptyDataDecls and type context ---------------------------------+------------------------------------------ Reporter: Paczesiowa | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.12.1 Keywords: emptydatadecls | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: GHC rejects valid program ---------------------------------+------------------------------------------ Comment(by Paczesiowa): I don't have anything to do with this, maybe you should ask Oleg about such definition for labels. I just wanted to fix HList (it fails to compile with 6.12) and I've discovered, that 6.12 works different than 6.10 and also reports really misleading error message. So, I'm not interested in making this usage work like in 6.10, but there should be a better error message and some info in docs, that the behavior changed. Oleg's code: http://old-darcs.well-typed.com/HList/Data/HList/Label2.hs -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 2 11:10:03 2010 From: trac at galois.com (GHC) Date: Tue Feb 2 10:41:41 2010 Subject: [GHC] #3831: SpecConstr should exploit cases where there is exactly one call pattern In-Reply-To: <044.5fe60f4f535f1251caca48895d45a780@abbot.galois.com> References: <044.5fe60f4f535f1251caca48895d45a780@abbot.galois.com> Message-ID: <053.cfc8ab75077166cd4dace5c77c6df5b7@abbot.galois.com> #3831: SpecConstr should exploit cases where there is exactly one call pattern ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: bug | Status: new Priority: high | Milestone: 6.14 branch Component: Compiler | Version: 6.13 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: simplCore/should_compile/T3831 Architecture: Unknown/Multiple | Failure: Compile-time performance bug ---------------------------------+------------------------------------------ Changes (by simonmar): * milestone: 6.12.2 => 6.14 branch Comment: Simon says it doesn't need fixing in 6.12, so moving the ticket to the 6.14 branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 2 12:13:51 2010 From: trac at galois.com (GHC) Date: Tue Feb 2 11:45:24 2010 Subject: [GHC] #3853: make tags work in the new build system Message-ID: <044.1c7a267759f0c130b8c8034100c59294@abbot.galois.com> #3853: make tags work in the new build system ---------------------------------+------------------------------------------ Reporter: igloo | Owner: igloo Type: task | Status: new Priority: normal | Milestone: 6.12 branch Component: Build System | Version: 6.12.1 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Make tags work in the new build system. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 2 14:03:09 2010 From: trac at galois.com (GHC) Date: Tue Feb 2 13:34:44 2010 Subject: [GHC] #3854: trac priority and milestone are completely hidden when not logged in Message-ID: <044.2544b5f2e45b50f95f7c0c872ae64db4@abbot.galois.com> #3854: trac priority and milestone are completely hidden when not logged in ---------------------------------+------------------------------------------ Reporter: igloo | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: None | Version: 6.12.1 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ trac priority and milestone are completely hidden when not logged in. Only editing should be disabled. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 2 14:58:34 2010 From: trac at galois.com (GHC) Date: Tue Feb 2 14:30:08 2010 Subject: [GHC] #3855: switch back to using a darcs repo for bytestring, and reenable the "redundant specialise pragmas" warning Message-ID: <044.441fcc2099f706fa07f52d002867d10e@abbot.galois.com> #3855: switch back to using a darcs repo for bytestring, and reenable the "redundant specialise pragmas" warning ---------------------------------+------------------------------------------ Reporter: igloo | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.14.1 Component: Build System | Version: 6.13 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Switch back to using a darcs repo for bytestring. Then reenable the "redundant specialise pragmas" warning (the 0.9.1.5 release contains some redundant specialise pragmas, which breaks the build). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 2 15:07:10 2010 From: trac at galois.com (GHC) Date: Tue Feb 2 14:38:42 2010 Subject: [GHC] #3856: Share code between C wrappers Message-ID: <044.cba3c7154542d8f645c7639175d0041b@abbot.galois.com> #3856: Share code between C wrappers ---------------------------------+------------------------------------------ Reporter: igloo | Owner: igloo Type: task | Status: new Priority: normal | Milestone: 6.12 branch Component: Driver | Version: 6.12.1 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ `driver/ghci/ghci.c` and `driver/gcc/gcc.c` do more-or-less the same thing in different ways; I think `gcc.c` is the newer, and simpler. Share code if possible. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 2 18:51:10 2010 From: trac at galois.com (GHC) Date: Tue Feb 2 18:22:45 2010 Subject: [GHC] #3857: gchi compiles but gch fails Message-ID: <043.9f80f259cad70033a07c8d21fdd444ca@abbot.galois.com> #3857: gchi compiles but gch fails ------------------------+--------------------------------------------------- Reporter: dstr | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.12.1 | Keywords: Os: MacOS X | Testcase: Architecture: x86 | Failure: GHC rejects valid program ------------------------+--------------------------------------------------- The following module loads into ghci but gch reports an error module Temp where { data Ftype = Numa Integer | Str [Char] ; instance Show Ftype where show (Str s) = s; show (Numa n) = show n } gch error ==== Undefined symbols: "_ZCMain_main_closure", referenced from: _ZCMain_main_closure$non_lazy_ptr in libHSrts.a(Main.o) "___stginit_ZCMain", referenced from: ___stginit_ZCMain$non_lazy_ptr in libHSrts.a(Main.o) ld: symbol(s) not found collect2: ld returned 1 exit status And in gchi any function (ReadFtype) placed at the end of the module gives error: Onlyghci.hs:9:0: parse error on input `readFtype' This same function placed before the instance command compiles. Not sure if this is relevant but I am using Mac OS X Version 10.6 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 3 00:12:37 2010 From: trac at galois.com (GHC) Date: Tue Feb 2 23:46:09 2010 Subject: [GHC] #3850: EmptyDataDecls and type context In-Reply-To: <049.f27f0f58200e17d4e5b9ff32a4c6b128@abbot.galois.com> References: <049.f27f0f58200e17d4e5b9ff32a4c6b128@abbot.galois.com> Message-ID: <058.ae2b3224f7f50866e636335e6bed11a9@abbot.galois.com> #3850: EmptyDataDecls and type context ---------------------------------+------------------------------------------ Reporter: Paczesiowa | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.12.1 Keywords: emptydatadecls | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: GHC rejects valid program ---------------------------------+------------------------------------------ Comment(by guest): I believe contexts on data declarations might not be totally useless, even if there are no constructors. The HList code in question had the following declaration data HNat x => Label x ns desc -- labels are exclusively type-level entities The context HNat is asserted not because we want to use any of HNat's methods. Rather, the constraint HNat was asserted as a kind predicate -- to show to the user that the type variable x is of a kind natural numbers, so to speak. Therefore, the type (Label HZero Foo Foo) is the correct instance of label. On the other hand, the type (Label Bool Foo Foo) is not a correct instance and will be flagged as such by the compiler. Oleg -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 3 02:28:12 2010 From: trac at galois.com (GHC) Date: Wed Feb 3 02:01:43 2010 Subject: [GHC] #3850: EmptyDataDecls and type context In-Reply-To: <049.f27f0f58200e17d4e5b9ff32a4c6b128@abbot.galois.com> References: <049.f27f0f58200e17d4e5b9ff32a4c6b128@abbot.galois.com> Message-ID: <058.79afacb21ded66d090b0dbe90cce3a86@abbot.galois.com> #3850: EmptyDataDecls and type context ---------------------------------+------------------------------------------ Reporter: Paczesiowa | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.12.1 Keywords: emptydatadecls | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: GHC rejects valid program ---------------------------------+------------------------------------------ Comment(by simonpj): What makes you think that GHC will reject the type `(Label Bool Foo Foo)`? I don't think it will. The only effect of a context on a data decl is that a use of the constructor, either in pattern matching or in an expression, gives rise to that constraint. That's all. So the constraint is no more than a comment. I suggest you use a comment! I'm really want a proper kind system, though. It's silly that we can't give the kind of Label. But contexts are not the way to do it. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From mechvel at botik.ru Wed Feb 3 10:44:31 2010 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Wed Feb 3 10:18:48 2010 Subject: profiling,-O in 6.12.1 Message-ID: <20100203154431.GA28848@scico.botik.ru> Dear GHC team, It looks like ghc-6.12.1 reports erroneous time profiling -- when the Main module of the project is made under -O. This is for ghc-6.12.1 made from source for Debian Linux and i386-like. Main.main calls for Complete.complete, `complete' calls for eLoop inside its source. eLoop must take almost all the time. My whole user library is made under -O -prof, and --enable-library-profiling. Main is compiled by ghc $dmCpOpt -prof --make Main and run by ./Main +RTS -M400m -pT -RTS For this key, the profiling report Main.prof looks natural and shows eLoop -- 97%. But for ghc $dmCpOpt -O -prof --make Make, it shows a different thing: zero for eLoop and 99% for `main'. How could this additional -O mislead the compiler? Also, as I recall, -O is still by default -- ? Could you explain, please? Regards, ----------------- Serge Mechveliani mechvel@botik.ru From trac at galois.com Wed Feb 3 11:57:14 2010 From: trac at galois.com (GHC) Date: Wed Feb 3 11:28:51 2010 Subject: [GHC] #3858: the resolution of abbreviated commands in ghci is surprising. Message-ID: <045.e262695a6b52bf0109375403f12dce74@abbot.galois.com> #3858: the resolution of abbreviated commands in ghci is surprising. ---------------------------------+------------------------------------------ Reporter: Saizan | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.12.1 | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ {{{ GHCi, version 6.12.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package ffi-1.0 ... linking ... done. Prelude> :i True data Bool = ... | True -- Defined in GHC.Bool Prelude> :def ifoo \_ -> putStrLn "ifoo" >> return "" Prelude> :i True ifoo }}} It seems that abbreviations are resolved to the command, that matches the prefix, which is defined last. I've found this behaviour very confusing in practice. I'd expect rebinding :i to some command that's not :info to require an explicit declaration. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 3 13:40:15 2010 From: trac at galois.com (GHC) Date: Wed Feb 3 13:11:56 2010 Subject: [GHC] #3857: gchi compiles but gch fails In-Reply-To: <043.9f80f259cad70033a07c8d21fdd444ca@abbot.galois.com> References: <043.9f80f259cad70033a07c8d21fdd444ca@abbot.galois.com> Message-ID: <052.e6c0affa7ba96296761ce263328fb1cf@abbot.galois.com> #3857: gchi compiles but gch fails ------------------------+--------------------------------------------------- Reporter: dstr | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.12.1 | Keywords: Os: MacOS X | Testcase: Architecture: x86 | Failure: GHC rejects valid program ------------------------+--------------------------------------------------- Comment(by maeder): The ghc linker message is normal since the module's name is not Main and there's no main function (of type IO ()). The curly braces around the module body are unusual but it works to add something before the final closing "}" if the instance definitions after the second "where" are also put in curly braces. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 3 14:07:58 2010 From: trac at galois.com (GHC) Date: Wed Feb 3 13:39:33 2010 Subject: [GHC] #3859: Problems with toClockTime on NetBSD Message-ID: <044.b73ad5191ac77fa3291243672b7b74cf@abbot.galois.com> #3859: Problems with toClockTime on NetBSD ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: Compiler | Version: 6.12.1 Keywords: | Difficulty: Os: NetBSD | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ http://bugs.darcs.net/msg8960 (part of http://bugs.darcs.net/issue1524) says: {{{ Got it: reproducing the crash (tough on such a slow machine where rebuilding these things is quite the process, yay me): GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 3 14:28:29 2010 From: trac at galois.com (GHC) Date: Wed Feb 3 13:59:58 2010 Subject: [GHC] #3860: bindists should check you have a new enough make Message-ID: <044.a622b795cb6118a0360beec79e99efa2@abbot.galois.com> #3860: bindists should check you have a new enough make ---------------------------------+------------------------------------------ Reporter: igloo | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.12.2 Component: Build System | Version: 6.12.1 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ The `configure.ac` check for `make` being too old should be put in the distrib `configure.ac.in` too. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 3 14:36:29 2010 From: trac at galois.com (GHC) Date: Wed Feb 3 14:08:02 2010 Subject: [GHC] #3857: gchi compiles but gch fails In-Reply-To: <043.9f80f259cad70033a07c8d21fdd444ca@abbot.galois.com> References: <043.9f80f259cad70033a07c8d21fdd444ca@abbot.galois.com> Message-ID: <052.b89f76da2b13ba4d23537c6d3518cba5@abbot.galois.com> #3857: gchi compiles but gch fails --------------------------------------+------------------------------------- Reporter: dstr | Owner: Type: bug | Status: closed Priority: normal | Component: Compiler Version: 6.12.1 | Resolution: invalid Keywords: | Os: MacOS X Testcase: | Architecture: x86 Failure: GHC rejects valid program | --------------------------------------+------------------------------------- Changes (by maeder): * status: new => closed * resolution: => invalid Comment: To place a further declaration after the instance, the instance must be terminated by a semicolon, that does not indicate a further instance equation. This works: {{{ data Ftype = Numa Integer | Str [Char] ; instance Show Ftype where show (Str s) = s; show (Numa n) = show n ; bla = undefined }}} This does not: {{{ data Ftype = Numa Integer | Str [Char] ; instance Show Ftype where show (Str s) = s; show (Numa n) = show n ; bla = undefined }}} And this works: {{{ data Ftype = Numa Integer | Str [Char] ; instance Show Ftype where { show (Str s) = s; show (Numa n) = show n } ; bla = undefined }}} but not without ";" after "}". So this is no bug, but just a complicated misunderstanding. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 3 15:27:43 2010 From: trac at galois.com (GHC) Date: Wed Feb 3 14:59:17 2010 Subject: [GHC] #3861: Make testing dynlibs on Windows work Message-ID: <044.b19a96075a430af404f6d4402b137111@abbot.galois.com> #3861: Make testing dynlibs on Windows work ---------------------------+------------------------------------------------ Reporter: igloo | Owner: igloo Type: task | Status: new Priority: high | Milestone: 6.12.2 Component: Test Suite | Version: 6.12.1 Keywords: | Difficulty: Os: Windows | Testcase: Architecture: x86 | Failure: None/Unknown ---------------------------+------------------------------------------------ In http://www.haskell.org/pipermail/cvs-ghc/2010-January/052238.html Duncan writes: {{{ Management of shared libs on Windows is going to be a bit of a pain. For the purposes of testing we will want to just modify the %PATH% to include the lib dir containing the dlls. This should be enough for the testsuite, to ensure no regressions. Ian: could you look at this? We'll want all the dlls installed into the ghc lib dir I think (or a subdir if you prefer). Then the testsuite on Windows would need to add that directory to the %PATH% so that executables generated by ghc will be able to find the dlls. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 3 15:28:31 2010 From: trac at galois.com (GHC) Date: Wed Feb 3 15:00:03 2010 Subject: [GHC] #3861: Make testing dynlibs on Windows work In-Reply-To: <044.b19a96075a430af404f6d4402b137111@abbot.galois.com> References: <044.b19a96075a430af404f6d4402b137111@abbot.galois.com> Message-ID: <053.8554f8c0e2fd50b981c33a03a91fba7b@abbot.galois.com> #3861: Make testing dynlibs on Windows work ---------------------------+------------------------------------------------ Reporter: igloo | Owner: igloo Type: task | Status: new Priority: high | Milestone: 6.12.2 Component: Test Suite | Version: 6.12.1 Keywords: | Difficulty: Os: Windows | Testcase: Architecture: x86 | Failure: None/Unknown ---------------------------+------------------------------------------------ Description changed by igloo: Old description: > In http://www.haskell.org/pipermail/cvs-ghc/2010-January/052238.html > Duncan writes: > {{{ > Management of shared libs on Windows is going to be a bit of a pain. For > the purposes of testing we will want to just modify the %PATH% to include > the lib dir containing the dlls. This should be enough for the testsuite, > to ensure no regressions. > > Ian: could you look at this? We'll want all the dlls installed into the > ghc lib dir I think (or a subdir if you prefer). Then the testsuite on > Windows would need to add that directory to the %PATH% so that > executables generated by ghc will be able to find the dlls. > }}} New description: In http://www.haskell.org/pipermail/cvs-ghc/2010-January/052238.html Duncan writes: {{{ Management of shared libs on Windows is going to be a bit of a pain. For the purposes of testing we will want to just modify the %PATH% to include the lib dir containing the dlls. This should be enough for the testsuite, to ensure no regressions. Ian: could you look at this? We'll want all the dlls installed into the ghc lib dir I think (or a subdir if you prefer). Then the testsuite on Windows would need to add that directory to the %PATH% so that executables generated by ghc will be able to find the dlls. }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 4 07:55:37 2010 From: trac at galois.com (GHC) Date: Thu Feb 4 07:27:07 2010 Subject: [GHC] #594: Support use of SSE2 in the x86 native code genreator In-Reply-To: <047.5190f55d4ad1363b95d98c092787782f@abbot.galois.com> References: <047.5190f55d4ad1363b95d98c092787782f@abbot.galois.com> Message-ID: <056.ff69b01c847e8881496b4cf5dad4b3ae@abbot.galois.com> #594: Support use of SSE2 in the x86 native code genreator -----------------------------------------+---------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: closed Priority: normal | Milestone: 6.14.1 Component: Compiler (NCG) | Version: 6.4.1 Resolution: fixed | Keywords: Difficulty: Moderate (less than a day) | Os: Unknown/Multiple Testcase: N/A | Architecture: Unknown/Multiple Failure: Runtime performance bug | -----------------------------------------+---------------------------------- Changes (by simonmar): * status: assigned => closed * resolution: => fixed Comment: Done: {{{ Thu Feb 4 10:48:49 GMT 2010 Simon Marlow * Implement SSE2 floating-point support in the x86 native code generator (#594) The new flag -msse2 enables code generation for SSE2 on x86. It results in substantially faster floating-point performance; the main reason for doing this was that our x87 code generation is appallingly bad, and since we plan to drop -fvia-C soon, we need a way to generate half-decent floating-point code. The catch is that SSE2 is only available on CPUs that support it (P4+, AMD K8+). We'll have to think hard about whether we should enable it by default for the libraries we ship. In the meantime, at least -msse2 should be an acceptable replacement for "-fvia-C -optc-ffast-math -fexcess-precision". SSE2 also has the advantage of performing all operations at the correct precision, so floating-point results are consistent with other platforms. I also tweaked the x87 code generation a bit while I was here, now it's slighlty less bad than before. }}} I measured the FF ray tracer benchmark, and `-msse2` seems on par with, or possibly better than, `"-fvia-C -optc-O3 -fexcess-precision -ffast-math"`, although the results are quite variable on the machine I tried it on. I suspect we're suffering from randomly misaligned Doubles on the stack and heap. -- Ticket URL: GHC The Glasgow Haskell Compiler From mechvel at botik.ru Thu Feb 4 10:50:53 2010 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Thu Feb 4 10:25:09 2010 Subject: profiling,-O in 6.12.1 In-Reply-To: <4B6A9856.3080706@gmail.com> References: <20100203154431.GA28848@scico.botik.ru> <201002031738.36212.daniel.is.fischer@web.de> <20100203175901.GA29456@scico.botik.ru> <4B6A9856.3080706@gmail.com> Message-ID: <20100204155053.GA31384@scico.botik.ru> To my > >>>It looks like ghc-6.12.1 reports erroneous time profiling -- > >>>when the Main module of the project is made under -O. > >>>[..] > >>>This is for ghc-6.12.1 made from source for Debian Linux and > >>>i386-like. > >>> [] > >The key combination > > ghc $dmCpOpt -prof --make Main > >shows 95% for eLoop, > >and adding -O to this line shows 0% for eLoop, independently on > >presence of -auto-all in this line > >(the whole library is made under -O -prof). > > > >Yes, I recall that the effect may be of inlining. Simon Marlow wrote on Thu, Feb 04, 2010 > Inlining should not in general affect the shape of the profile. I can't > say much else here without seeing the specific code. Finally, by setting -O0 -prof I have found "who of top-levels takes most of time" -- hopefully, the same functions will occur for -O. I do not know, maybe, this is a known bug (Simon writes, there exists some report). Anyway, it is important to debug profiling -- to making unnecessary any irregular tricks with -inline-not. Dear GHC team, if I put my project to a public place, would you find out what is the effect there about -O -prof ? Although the whole program is large, but probably, the very example with `main' + Complete.complete + a single SCC, is simple for you to detect the effect source. Regards, ----------------- Serge Mechveliani mechvel@botik.ru From trac at galois.com Thu Feb 4 13:19:23 2010 From: trac at galois.com (GHC) Date: Thu Feb 4 12:50:50 2010 Subject: [GHC] #3862: ghc crash while building hledger with cabal Message-ID: <047.37b3f072a5f2a5fc14090219a1e5d9bd@abbot.galois.com> #3862: ghc crash while building hledger with cabal ---------------------------------+------------------------------------------ Reporter: simonmic | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Keywords: Os: MacOS X | Testcase: Architecture: Unknown/Multiple | Failure: Compile-time crash ---------------------------------+------------------------------------------ {{{ $ cabal install -fweb -fvty -fchart --constraint 'template-haskell < 2.4' Resolving dependencies... Configuring hledger-0.8... Preprocessing library hledger-0.8... Preprocessing executables for hledger-0.8... Building hledger-0.8... ar: creating archive dist/build/libHShledger-0.8.a [29 of 32] Compiling Commands.Convert ( Commands/Convert.hs, dist/build/hledger/hledger-tmp/Commands/Convert.o ) ghc: panic! (the 'impossible' happened) (GHC version 6.10.4 for i386-apple-darwin): applyTypeToArgs parsec-2.1.0.1:Text.ParserCombinators.Parsec.Prim.a32{v rwo} [gid] @ csv-0.1.1:Text.CSV.CSV{tc r2Ve} (csv-0.1.1:Text.CSV.a22{v r2Va} [gid] `cast` (ghc-prim:GHC.Prim.sym{(w) tc 34v} ((parsec-2.1.0.1:Text.ParserCombinators.Parsec.Prim.:CoGenParser{tc rhR}) ghc-prim:GHC.Types.Char{(w) tc 3o} ghc-prim:GHC.Unit.(){(w) tc 40} csv-0.1.1:Text.CSV.CSV{tc r2Ve}) :: parsec-2.1.0.1:Text.ParserCombinators.Parsec.Prim.State{tc rhV} ghc-prim:GHC.Types.Char{(w) tc 3o} ghc- prim:GHC.Unit.(){(w) tc 40} -> parsec-2.1.0.1:Text.ParserCombinators.Parsec.Prim.Consumed{tc rit} (parsec-2.1.0.1:Text.ParserCombinators.Parsec.Prim.Reply{tc ris} ghc-prim:GHC.Types.Char{(w) tc 3o} ghc-prim:GHC.Unit.(){(w) tc 40} csv-0.1.1:Text.CSV.CSV{tc r2Ve}) ~ parsec-2.1.0.1:Text.ParserCombinators.Parsec.Prim.GenParser{tc rhk} ghc-prim:GHC.Types.Char{(w) tc 3o} ghc-prim:GHC.Unit.(){(w) tc 40} csv-0.1.1:Text.CSV.CSV{tc r2Ve})) csvfile{v s3Vz} [lid] forall st{tv i3Im} [tv] a{tv i3In} [tv]. parsec-2.1.0.1:Text.ParserCombinators.Parsec.Prim.GenParser{tc rhk} csv-0.1.1:Text.CSV.CSV{tc r2Ve} st{tv i3Im} [tv] a{tv i3In} [tv] -> [base:GHC.Base.String{tc 36u}] -> parsec-2.1.0.1:Text.ParserCombinators.Parsec.Prim.State{tc rhV} csv-0.1.1:Text.CSV.CSV{tc r2Ve} st{tv i3Im} [tv] -> parsec-2.1.0.1:Text.ParserCombinators.Parsec.Prim.Consumed{tc rit} (parsec-2.1.0.1:Text.ParserCombinators.Parsec.Prim.Reply{tc ris} csv-0.1.1:Text.CSV.CSV{tc r2Ve} st{tv i3Im} [tv] a{tv i3In} [tv]) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Seen for the first time today. Does not happen when using ghc --make. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 4 16:38:22 2010 From: trac at galois.com (GHC) Date: Thu Feb 4 16:09:50 2010 Subject: [GHC] #3862: ghc crash while building hledger with cabal In-Reply-To: <047.37b3f072a5f2a5fc14090219a1e5d9bd@abbot.galois.com> References: <047.37b3f072a5f2a5fc14090219a1e5d9bd@abbot.galois.com> Message-ID: <056.08883119cf6553e8d1b704ca6a811473@abbot.galois.com> #3862: ghc crash while building hledger with cabal ---------------------------------+------------------------------------------ Reporter: simonmic | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Keywords: Os: MacOS X | Testcase: Architecture: Unknown/Multiple | Failure: Compile-time crash ---------------------------------+------------------------------------------ Comment(by simonmic): Happens with -O. Another way to reproduce: $ darcs get --lazy http://joyful.com/repos/hledger && cd hledger $ ghc --make Commands/Convert.hs -O -- Ticket URL: GHC The Glasgow Haskell Compiler From seth.baldwin at comcast.net Thu Feb 4 20:19:39 2010 From: seth.baldwin at comcast.net (Seth442) Date: Thu Feb 4 19:51:04 2010 Subject: foreign import PlaySound causing GHCi to crash Message-ID: <27414694.post@talk.nabble.com> Hello, I am trying to write a Haskell program that plays wav files using foreign import on the Win32 function PlaySound: BOOL PlaySound( LPCTSTR pszSound, HMODULE hmod, DWORD fdwSound ); I wrote the following module to import the function, which I successfully compiled with GHC using ?ghc --make Sound.hs? (much of this module is adapted from someone else?s code) --Sound.hs {-# LANGUAGE ForeignFunctionInterface #-} module Sound where import Foreign import Foreign.C import CString import System.IO import Data.Bits import System.Win32 data SoundFlag = Async | Filename | Sync deriving () --I found these values online marshall_SoundFlag :: SoundFlag -> Int32 marshall_SoundFlag arg1 = case arg1 of Async -> 0 Sync -> 1 Filename -> 131072 foreign import ccall "PlaySound" play :: CString -> Int32 -> Int32 -> IO Bool playSound :: String -> Int32 -> SoundFlag -> IO Bool playSound filename hmod flag = play (unsafePerformIO (newCString filename)) hmod (marshall_SoundFlag flag) Then I wrote the following to test it: --testSound.hs {-# LANGUAGE ForeignFunctionInterface #-} import Sound main = do x <- playSound "test.wav" 0 Filename print x When I load the test program in ghci, it loads properly. When I run main, it successfully plays the sound, then prints ?True? and then crashes. Every time. When I try to compile the test program, I get the following error message: Linking testSound.exe ... .\Sound.o:fake:(.text+0x50): undefined reference to 'PlaySound' .\Sound.o:fake:(.text+0x5a2): undefined reference to 'PlaySound' collect2: ld returned 1 exit status I'm wondering if their is a problem with the way I converted data from haskell to C. I'm also concerned that my GHC compiler is not set up properly for this type of program. GHCi seems to be unable to figure out what PlaySound is supposed to be until Sound.hs is compiled, at which point it plays the sound but then crashes. Any help would be appreciated. -- View this message in context: http://old.nabble.com/foreign-import-PlaySound-causing-GHCi-to-crash-tp27414694p27414694.html Sent from the Haskell - Glasgow-haskell-bugs mailing list archive at Nabble.com. From trac at galois.com Thu Feb 4 22:31:24 2010 From: trac at galois.com (GHC) Date: Thu Feb 4 22:02:53 2010 Subject: [GHC] #3863: Absolute paths to GCC and perl should not be baked into the compiler. Message-ID: <043.6af4ab2709d2ca444a0f5e553082c752@abbot.galois.com> #3863: Absolute paths to GCC and perl should not be baked into the compiler. ---------------------------------+------------------------------------------ Reporter: benl | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.13 | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Installing GHC failed ---------------------------------+------------------------------------------ Building with {{{sh boot ; ./configure ; make}}} leaves me with the following lines in {{{compiler/main/Config.hs}}} {{{ cGCC = "/export/home/benl/software/gcc-4.1.2/bin/gcc" cGHC_PERL = "/opt/csw/bin/perl" }}} These absolute paths are baked into the compiler, and if I then do a {{{make binary-dist}}} the resulting binary distribution is unusable for anyone else. Note that {{{compiler/main/SysTools.hs:105}}} says that these vars should not include paths, and rightly so. I'm currently working around this by hacking {{{mk/config.mk}}} after running {{{./configure}}}. We probably need a better story about which GCC and perl to use for the build, vs which ones to use when compiling programs. I vote that the default should be to use the ones in the PATH unless explicitly configured not to. Note that on SPARC/Solaris the default system GCC is unusable, so people that do not have root access will always need to run GHC against a privately installed GCC. Tickets #2966 and #3842 are related. -- Ticket URL: GHC The Glasgow Haskell Compiler From Malcolm.Wallace at cs.york.ac.uk Fri Feb 5 03:34:44 2010 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Fri Feb 5 03:06:09 2010 Subject: foreign import PlaySound causing GHCi to crash In-Reply-To: <27414694.post@talk.nabble.com> References: <27414694.post@talk.nabble.com> Message-ID: <013A37EC-2E13-46AE-84BD-100BD8D1E74B@cs.york.ac.uk> > foreign import ccall "PlaySound" play :: CString -> Int32 -> Int32 - > > IO Bool Is it possible that the foreign function should use the "stdcall" convention rather than "ccall"? IIRC, the difference is in who is responsible for cleaning the the stack after the call returns, which might match one of the symptoms you see. Regards, Malcolm From trac at galois.com Fri Feb 5 06:07:15 2010 From: trac at galois.com (GHC) Date: Fri Feb 5 05:38:40 2010 Subject: [GHC] #3848: Error message typo in rts/RtsAPI.c In-Reply-To: <044.0702ff6eeab4c6d918d0c693dbbdade1@abbot.galois.com> References: <044.0702ff6eeab4c6d918d0c693dbbdade1@abbot.galois.com> Message-ID: <053.e78c7b4a3bb064c90eeeb5762b55fd31@abbot.galois.com> #3848: Error message typo in rts/RtsAPI.c -----------------------------+---------------------------------------------- Reporter: larsv | Owner: igloo Type: merge | Status: closed Priority: high | Milestone: 6.12.2 Component: Runtime System | Version: 6.12.1 Resolution: fixed | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 5 06:35:51 2010 From: trac at galois.com (GHC) Date: Fri Feb 5 06:07:27 2010 Subject: [GHC] #3863: Absolute paths to GCC and perl should not be baked into the compiler. In-Reply-To: <043.6af4ab2709d2ca444a0f5e553082c752@abbot.galois.com> References: <043.6af4ab2709d2ca444a0f5e553082c752@abbot.galois.com> Message-ID: <052.f152ff955d2ffbd8e3f0534236074adb@abbot.galois.com> #3863: Absolute paths to GCC and perl should not be baked into the compiler. ---------------------------------+------------------------------------------ Reporter: benl | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.13 | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Compile-time crash ---------------------------------+------------------------------------------ Changes (by maeder): * cc: Christian.Maeder@? (added) * failure: Installing GHC failed => Compile-time crash -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 5 06:52:30 2010 From: trac at galois.com (GHC) Date: Fri Feb 5 06:24:03 2010 Subject: [GHC] #3863: Absolute paths to GCC and perl should not be baked into the compiler. In-Reply-To: <043.6af4ab2709d2ca444a0f5e553082c752@abbot.galois.com> References: <043.6af4ab2709d2ca444a0f5e553082c752@abbot.galois.com> Message-ID: <052.29fc7957a6e7ac5963630a74d605e7b5@abbot.galois.com> #3863: Absolute paths to GCC and perl should not be baked into the compiler. ---------------------------------+------------------------------------------ Reporter: benl | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.2 Component: Build System | Version: 6.13 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Compile-time crash ---------------------------------+------------------------------------------ Changes (by igloo): * priority: normal => high * milestone: => 6.12.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 5 11:13:29 2010 From: trac at galois.com (GHC) Date: Fri Feb 5 10:44:54 2010 Subject: [GHC] #3864: Bad error message if $TMP does not exist Message-ID: <051.eea869a73bc370d7e77925ccc5070f1d@abbot.galois.com> #3864: Bad error message if $TMP does not exist ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Keywords: Os: Windows | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.10.4 $ set TMP=c:\none $ ghc --make Main.hs CreateDirectory: does not exist (The system cannot find the path specified.) }}} If the {{{%TMP%}}} environment variable is set to a directory that does not exist, then GHC gives a very uninformative error message. I suggest that {{{CreateDirectory}}} always give the name of the directory when it fails, and that GHC traps this error and gives a better error. Tracking this bug down took a while - I'd like to spare other users my pain :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 5 11:23:17 2010 From: trac at galois.com (GHC) Date: Fri Feb 5 10:54:41 2010 Subject: [GHC] #3864: Bad error message if $TMP does not exist In-Reply-To: <051.eea869a73bc370d7e77925ccc5070f1d@abbot.galois.com> References: <051.eea869a73bc370d7e77925ccc5070f1d@abbot.galois.com> Message-ID: <060.426cd832d4a437c94c06ee80e9a363c9@abbot.galois.com> #3864: Bad error message if $TMP does not exist ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.2 Component: Compiler | Version: 6.10.4 Keywords: | Difficulty: Os: Windows | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Changes (by igloo): * priority: normal => high * milestone: => 6.12.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 5 14:10:15 2010 From: trac at galois.com (GHC) Date: Fri Feb 5 13:41:54 2010 Subject: [GHC] #3472: Porting through .hc files broken In-Reply-To: <046.fbcd146ac7544c3ae31be3ef2ccbd0d8@abbot.galois.com> References: <046.fbcd146ac7544c3ae31be3ef2ccbd0d8@abbot.galois.com> Message-ID: <055.ed448c9441b07e583ac569cc0b3be5d9@abbot.galois.com> #3472: Porting through .hc files broken ---------------------------------+------------------------------------------ Reporter: pumpkin | Type: bug Status: closed | Priority: normal Milestone: 6.12 branch | Component: Build System Version: 6.12.1 RC1 | Resolution: fixed Keywords: | Difficulty: Unknown Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Changes (by john435): * status: new => closed * resolution: => fixed Comment: Replying to [comment:5 ksf]: > We either have to come up with a solution for using hsc2hs (take the intermediate C files to the target and compile/run them?) or convert .hsc files to autoconf + CPP (yeuch). > > It's quite straight-forward to split up the %.hsc->%.hs rule in two, the first one generating %_hsc_make with a cross-compiler, the second one moving the binary over to the target, executing it and piping the result into %.hs. Compiling on the target is certainly feasible, too, but I happen to have a working [http://healthyweightlosspills.com/weight_loss_pills.html weight loss pills] cross-compiler. > > I am, however, stuck with make, in the area of separating the build directories into stage1/stage2 for the libraries as well as transferring ./configure output over from the target to the build platform, without having that trigger recompilation of stage1 (and the package info being a bit messed up wrt. -l flags, but that's a minor concern) > > Compiling the stage2 libraries with [http://treatmentofmesothelioma.org/mesothelioma.html mesothelioma] actual target info also opens up the issue that we can't use the native gcc as it's quite likely to fail, not so much while compiling (at least .hc), but linking: My linux doesn't come with libutil, for example. Both using a cross-gcc and replacing gcc with touch should work, I've not had much time to investigate this. > > The main issue, however, is that we're infecting perfectly cross- platform .hc with platform-specific information by preprocessing Haskell instead of C: It might be feasible to generate C stubs for all hsc2hs macros and calling them via the ffi, leaving resolving of platform- specific things until later. The whole build-process depending on .o s being generated even when all you want to have are .hc s isn't helping things. > > And then there's David's LLVM work... I'm currently slurping his thesis because porting via LLVM looks very, very, elegant and painless, at least from afar. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 5 14:12:27 2010 From: trac at galois.com (GHC) Date: Fri Feb 5 13:43:53 2010 Subject: [GHC] #3061: GHC's GC default heap growth strategy is not as good as other runtimes In-Reply-To: <043.619b1558281745ecd214227681115d78@abbot.galois.com> References: <043.619b1558281745ecd214227681115d78@abbot.galois.com> Message-ID: <052.510a97a9274396806222fecd817e876a@abbot.galois.com> #3061: GHC's GC default heap growth strategy is not as good as other runtimes --------------------------------------+------------------------------------- Reporter: dons | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12 branch Component: Runtime System | Version: 6.10.1 Resolution: fixed | Keywords: performance, GC Difficulty: Unknown | Os: Unknown/Multiple Testcase: yes | Architecture: Unknown/Multiple Failure: Runtime performance bug | --------------------------------------+------------------------------------- Changes (by john435): * status: new => closed * resolution: => fixed Comment: Replying to [comment:1 simonmar]: > So you're not allowed to use GC settings in the shootout? I think this benchmark is pathological for our default GC settings. The reason is that we use a small fixed-size allocation area, which is usually good for cache behaviour, but in this benchmark when we get to the larger tree sizes, we always GC before the tree has been constructed, and the GC therefore has to copy [http://treatmentofmesothelioma.org/mesothelioma.html mesothelioma] the tree, possibly multiple times. In fact this is very similar to a standard GC benchmark that we use. > > I'd be quite interested to know what [http://healthyweightlosspills.com/healthy weight loss] other runtimes do here. I played a little with scaling up the size of the allocation area if we find we're copying a lot, but didn't see a dramatic improvement. Thank you for your answer. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 5 17:27:16 2010 From: trac at galois.com (GHC) Date: Fri Feb 5 16:58:42 2010 Subject: [GHC] #3773: Haddoc documentation on wrong function argument In-Reply-To: <044.635ed03af9d418169b269fce9db0718f@abbot.galois.com> References: <044.635ed03af9d418169b269fce9db0718f@abbot.galois.com> Message-ID: <053.f1459d6641ea33f8c0ec4fb3d56b87b1@abbot.galois.com> #3773: Haddoc documentation on wrong function argument ----------------------------+----------------------------------------------- Reporter: tibbe | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: Documentation | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ----------------------------+----------------------------------------------- Changes (by igloo): * owner: waern => igloo * status: reopened => new -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 5 17:33:37 2010 From: trac at galois.com (GHC) Date: Fri Feb 5 17:05:00 2010 Subject: [GHC] #3847: Windows installer has incorrect documentation shortcut In-Reply-To: <051.dbb06debb35b6c2c5d7b37d30c3d1f07@abbot.galois.com> References: <051.dbb06debb35b6c2c5d7b37d30c3d1f07@abbot.galois.com> Message-ID: <060.cb34d7f815ecf50cdd677530f62db084@abbot.galois.com> #3847: Windows installer has incorrect documentation shortcut ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.2 Component: Compiler | Version: 6.12.1 Keywords: | Difficulty: Os: Windows | Testcase: Architecture: Unknown/Multiple | Failure: Documentation bug ---------------------------------+------------------------------------------ Changes (by igloo): * priority: normal => high * milestone: => 6.12.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 5 17:48:33 2010 From: trac at galois.com (GHC) Date: Fri Feb 5 17:19:56 2010 Subject: [GHC] #3681: hsc2hs wrapper script throws away $HSC2HS_EXTRA's value when specified C compiler to use In-Reply-To: <042.c4b5030684625e3b4acbf7f52bd1fe70@abbot.galois.com> References: <042.c4b5030684625e3b4acbf7f52bd1fe70@abbot.galois.com> Message-ID: <051.4019aa2709f339f5af4abad7942a9429@abbot.galois.com> #3681: hsc2hs wrapper script throws away $HSC2HS_EXTRA's value when specified C compiler to use ------------------------+--------------------------------------------------- Reporter: nwn | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: hsc2hs | Version: 6.12.1 RC1 Keywords: | Difficulty: Os: MacOS X | Testcase: Architecture: x86 | Failure: Other ------------------------+--------------------------------------------------- Comment(by igloo): The above kludge patch is in 6.12.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 5 17:56:46 2010 From: trac at galois.com (GHC) Date: Fri Feb 5 17:28:27 2010 Subject: [GHC] #3550: Dynamic libraries don't work on Mac OS/X In-Reply-To: <056.c6f0034a4d5f342c60f11476270241e0@abbot.galois.com> References: <056.c6f0034a4d5f342c60f11476270241e0@abbot.galois.com> Message-ID: <065.f9c8dabcb28a1be8e23a2f05dd69a30b@abbot.galois.com> #3550: Dynamic libraries don't work on Mac OS/X ----------------------------------+----------------------------------------- Reporter: StephenBlackheath | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: Compiler | Version: 6.11 Keywords: dynamic mac osx | Difficulty: Unknown Os: MacOS X | Testcase: http://upcycle.it/~blackh/ghc/test-case.tar.bz2 Architecture: Unknown/Multiple | Failure: None/Unknown ----------------------------------+----------------------------------------- Changes (by igloo): * owner: StephenBlackheath => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 6 03:10:25 2010 From: trac at galois.com (GHC) Date: Sat Feb 6 02:41:59 2010 Subject: [GHC] #1845: unconditional relative branch out of range (GHC version 6.8.1-6.10.4 for powerpc_apple_darwin) (was: unconditional relative branch out of range (GHC version 6.8.1/6.8.2 for powerpc_apple_darwin)) In-Reply-To: <044.65389402080b2ab045a1b2fde12245f8@abbot.galois.com> References: <044.65389402080b2ab045a1b2fde12245f8@abbot.galois.com> Message-ID: <053.a85f2bc45f6eea3c0d206e0ffe8676b0@abbot.galois.com> #1845: unconditional relative branch out of range (GHC version 6.8.1-6.10.4 for powerpc_apple_darwin) -------------------------+-------------------------------------------------- Reporter: guest | Owner: thorkilnaur Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.10.4 Keywords: | Difficulty: Unknown Os: MacOS X | Testcase: Architecture: powerpc | Failure: Compile-time crash -------------------------+-------------------------------------------------- Changes (by verti): * failure: None/Unknown => Compile-time crash Comment: I also recieved this error when attempting to resolve an issue with a Yi installation by applying some suggested constraints. [[BR]] A "hello" example had been compiled before this, and ''cabal install'' of all items listed in the Haskell Platform was successful. [[BR]] Using OS X Leopard, PPC G5, GHC 6.10.4[[BR]] {{{ $ cabal install yi --constraint="data-accessor < 0.2.1" --constraint ="template-haskell < 2.4" Resolving dependencies... Configuring data-accessor-monads-fd-0.2... Preprocessing library data-accessor-monads-fd-0.2... Building data-accessor-monads-fd-0.2... [1 of 1] Compiling Data.Accessor.Monad.FD.State ( src/Data/Accessor/Monad/FD/State.hs, dist/build/Data/Accessor/Monad/FD/State.o ) ar: creating archive dist/build/libHSdata-accessor-monads-fd-0.2.a Installing library in /Users/administrator/.cabal/lib/data-accessor-monads-fd-0.2/ghc-6.10.4 Registering data-accessor-monads-fd-0.2... Reading package info from "dist/installed-pkg-config" ... done. Writing new package config file... done. Configuring data-accessor-template-0.2.1.3... Preprocessing library data-accessor-template-0.2.1.3... Building data-accessor-template-0.2.1.3... [1 of 2] Compiling Data.Accessor.Template ( src-3/Data/Accessor/Template.hs, dist/build/Data/Accessor/Template.o ) [2 of 2] Compiling Data.Accessor.Template.Example ( src/Data/Accessor/Template/Example.hs, dist/build/Data/Accessor/Template/Example.o ) Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Loading package syb ... linking ... done. Loading package base-3.0.3.1 ... linking ... done. Loading package utility-ht-0.0.5.1 ... linking ... done. Loading package array-0.2.0.0 ... linking ... done. Loading package containers-0.2.0.1 ... linking ... done. Loading package packedstring-0.1.0.1 ... linking ... done. Loading package pretty-1.0.1.0 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package transformers-0.1.4.0 ... linking ... done. Loading package data-accessor-0.2.0.2 ... linking ... done. ar: creating archive dist/build/libHSdata-accessor-template-0.2.1.3.a Installing library in /Users/administrator/.cabal/lib/data-accessor-template-0.2.1.3/ghc-6.10.4 Registering data-accessor-template-0.2.1.3... Reading package info from "dist/installed-pkg-config" ... done. Writing new package config file... done. [1 of 1] Compiling Main ( /var/folders/nC/nCwTbMclGKiVINNMLpEVRE+++TI/-Tmp-/pointedlist-0.3.548338/pointedlist-0.3.5/Setup.hs, /var/folders/nC/nCwTbMclGKiVINNMLpEVRE+++TI/-Tmp-/pointedlist-0.3.548338/pointedlist-0.3.5/dist/setup/Main.o ) Linking /var/folders/nC/nCwTbMclGKiVINNMLpEVRE+++TI/-Tmp-/pointedlist-0.3.548338/pointedlist-0.3.5/dist/setup/setup ... Configuring pointedlist-0.3.5... Preprocessing library pointedlist-0.3.5... Building pointedlist-0.3.5... [1 of 2] Compiling Data.List.PointedList ( Data/List/PointedList.hs, dist/build/Data/List/PointedList.o ) [2 of 2] Compiling Data.List.PointedList.Circular ( Data/List/PointedList/Circular.hs, dist/build/Data/List/PointedList/Circular.o ) ar: creating archive dist/build/libHSpointedlist-0.3.5.a Installing library in /Users/administrator/.cabal/lib/pointedlist-0.3.5/ghc-6.10.4 Registering pointedlist-0.3.5... Reading package info from "dist/installed-pkg-config" ... done. Writing new package config file... done. Configuring yi-0.6.1... Preprocessing library yi-0.6.1... Preprocessing executables for yi-0.6.1... Building yi-0.6.1... [ 1 of 120] Compiling System.FriendlyPath ( System/FriendlyPath.hs, dist/build/System/FriendlyPath.o ) [ 2 of 120] Compiling Shim.ProjectContent ( Shim/ProjectContent.hs, dist/build/Shim/ProjectContent.o ) [ 3 of 120] Compiling Parser.Incremental ( Parser/Incremental.hs, dist/build/Parser/Incremental.o ) [ 4 of 120] Compiling Data.Trie ( Data/Trie.hs, dist/build/Data/Trie.o ) [ 5 of 120] Compiling Data.DelayList ( Data/DelayList.hs, dist/build/Data/DelayList.o ) [ 6 of 120] Compiling Data.Rope ( Data/Rope.hs, dist/build/Data/Rope.o ) [ 7 of 120] Compiling Data.Prototype ( Data/Prototype.hs, dist/build/Data/Prototype.o ) [ 8 of 120] Compiling HConf.Utils ( HConf/Utils.hs, dist/build/HConf/Utils.o ) [ 9 of 120] Compiling HConf.Paths ( HConf/Paths.hs, dist/build/HConf/Paths.o ) [ 10 of 120] Compiling Paths_yi ( dist/build/autogen/Paths_yi.hs, dist/build/Paths_yi.o ) [ 11 of 120] Compiling HConf ( HConf.hs, dist/build/HConf.o ) [ 12 of 120] Compiling Yi.Char.Unicode ( Yi/Char/Unicode.hs, dist/build/Yi/Char/Unicode.o ) [ 13 of 120] Compiling Yi.UI.Common[boot] ( Yi/UI/Common.hs-boot, dist/build/Yi/UI/Common.o-boot ) [ 14 of 120] Compiling Yi.String ( Yi/String.hs, dist/build/Yi/String.o ) [ 15 of 120] Compiling Yi.Monad ( Yi/Monad.hs, dist/build/Yi/Monad.o ) [ 16 of 120] Compiling Yi.Keymap.Completion ( Yi/Keymap/Completion.hs, dist/build/Yi/Keymap/Completion.o ) [ 17 of 120] Compiling Yi.Editor[boot] ( Yi/Editor.hs-boot, dist/build/Yi/Editor.o-boot ) [ 18 of 120] Compiling Yi.Debug ( Yi/Debug.hs, dist/build/Yi/Debug.o ) [ 19 of 120] Compiling Yi.Prelude ( Yi/Prelude.hs, dist/build/Yi/Prelude.o ) [ 20 of 120] Compiling Yi.Dynamic ( Yi/Dynamic.hs, dist/build/Yi/Dynamic.o ) [ 21 of 120] Compiling Yi.Event ( Yi/Event.hs, dist/build/Yi/Event.o ) [ 22 of 120] Compiling Yi.Interact ( Yi/Interact.hs, dist/build/Yi/Interact.o ) [ 23 of 120] Compiling Yi.Keymap[boot] ( Yi/Keymap.hs-boot, dist/build/Yi/Keymap.o-boot ) [ 24 of 120] Compiling Yi.Style ( Yi/Style.hs, dist/build/Yi/Style.o ) [ 25 of 120] Compiling Yi.Style.Library ( Yi/Style/Library.hs, dist/build/Yi/Style/Library.o ) [ 26 of 120] Compiling Yi.Interpreter ( Yi/Interpreter.hs, dist/build/Yi/Interpreter.o ) [ 27 of 120] Compiling Shim.Utils ( Shim/Utils.hs, dist/build/Shim/Utils.o ) [ 28 of 120] Compiling Shim.CabalInfo ( Shim/CabalInfo.hs, dist/build/Shim/CabalInfo.o ) [ 29 of 120] Compiling Yi.Buffer.Misc[boot] ( Yi/Buffer/Misc.hs-boot, dist/build/Yi/Buffer/Misc.o-boot ) [ 30 of 120] Compiling Yi.Buffer.Basic ( Yi/Buffer/Basic.hs, dist/build/Yi/Buffer/Basic.o ) Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Loading package bytestring-0.9.1.4 ... linking ... done. Loading package syb ... linking ... done. Loading package array-0.2.0.0 ... linking ... done. Loading package containers-0.2.0.1 ... linking ... done. Loading package extensible-exceptions-0.1.1.1 ... linking ... done. Loading package terminfo-0.3.1.1 ... linking ... done. Loading package unix-2.3.2.0 ... linking ... done. Loading package base-3.0.3.1 ... linking ... done. Loading package utf8-string-0.3.6 ... linking ... done. Loading package vty-3.1.8.4 ... linking ... done. Loading package unix-compat-0.1.2.1 ... linking ... done. Loading package mtl-1.1.0.2 ... linking ... done. Loading package uniplate-1.5.1 ... linking ... done. Loading package old-locale-1.0.0.1 ... linking ... done. Loading package time-1.1.4 ... linking ... done. Loading package split-0.1.2 ... linking ... done. Loading package rosezipper-0.1 ... linking ... done. Loading package parsec-2.1.0.1 ... linking ... done. Loading package regex-base-0.93.1 ... linking ... done. Loading package regex-tdfa-1.1.2 ... linking ... done. Loading package binary-0.5.0.2 ... linking ... done. Loading package pureMD5-1.0.0.3 ... linking ... done. Loading package transformers-0.1.4.0 ... linking ... done. Loading package data-accessor-0.2.0.2 ... linking ... done. Loading package pointedlist-0.3.5 ... linking ... done. Loading package ghc-paths-0.1.0.6 ... linking ... done. Loading package fingertree-0.0.1.0 ... linking ... done. Loading package dlist-0.5 ... linking ... done. Loading package filepath-1.1.0.2 ... linking ... done. Loading package old-time-1.0.0.2 ... linking ... done. Loading package directory-1.0.0.3 ... linking ... done. Loading package packedstring-0.1.0.1 ... linking ... done. Loading package pretty-1.0.1.0 ... linking ... done. Loading package process-1.0.1.1 ... linking ... done. Loading package random-1.0.0.1 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package derive-0.1.4 ... linking ... done. Loading package utility-ht-0.0.5.1 ... linking ... done. Loading package data-accessor-template-0.2.1.3 ... linking ... done. Loading package monads-fd-0.0.0.1 ... linking ... done. Loading package data-accessor-monads-fd-0.2 ... linking ... done. Loading package Cabal-1.6.0.3 ... linking ... done. Loading package haskell98 ... linking ... done. Loading package hpc-0.5.0.3 ... linking ... done. ghc: internal error: unconditional relative branch out of range: jump island out of range (GHC version 6.10.4 for powerpc_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug cabal: Error: some packages failed to install: yi-0.6.1 failed during the building phase. The exception was: exit: ExitFailure 6 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 6 15:35:08 2010 From: trac at galois.com (GHC) Date: Sat Feb 6 15:06:31 2010 Subject: [GHC] #3859: Problems with toClockTime on NetBSD In-Reply-To: <044.b73ad5191ac77fa3291243672b7b74cf@abbot.galois.com> References: <044.b73ad5191ac77fa3291243672b7b74cf@abbot.galois.com> Message-ID: <053.8158bc9312445a983f86787ac3534944@abbot.galois.com> #3859: Problems with toClockTime on NetBSD ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: Compiler | Version: 6.12.1 Keywords: | Difficulty: Os: NetBSD | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Comment(by kristerw): I would guess this is with NetBSD-current... NetBSD changed time_t to become a 64-bit type shortly after NetBSD 5 was released, and this caused some breakage for ghc. I sent patches for most of the issues before 6.12 was released, but I know of at least one more place that need to be updated: ghc think that struct timeval look like struct timeval {time_t tv_sec; time_t tv_usec;}; while it according to POSIX look like struct timeval {time_t tv_sec; suseconds_t tv_usec;}; which matter on NetBSD now, as time_t is 64 bits, and suseconds_t is 32 bits. I just tried some patches for this, but it does not seem to solve all problems... :( I'll investigate some more, but will probably not have the time until late next week... -- Ticket URL: GHC The Glasgow Haskell Compiler From seth.baldwin at comcast.net Sat Feb 6 18:00:00 2010 From: seth.baldwin at comcast.net (Seth442) Date: Sat Feb 6 17:31:17 2010 Subject: foreign import PlaySound causing GHCi to crash In-Reply-To: <013A37EC-2E13-46AE-84BD-100BD8D1E74B@cs.york.ac.uk> References: <27414694.post@talk.nabble.com> <013A37EC-2E13-46AE-84BD-100BD8D1E74B@cs.york.ac.uk> Message-ID: <27484270.post@talk.nabble.com> Malcolm Wallace wrote: > >> foreign import ccall "PlaySound" play :: CString -> Int32 -> Int32 - >> > IO Bool > > Is it possible that the foreign function should use the "stdcall" > convention rather than "ccall"? > > IIRC, the difference is in who is responsible for cleaning the the > stack after the call returns, which might match one of the symptoms > you see. > > Regards, > Malcolm > _______________________________________________ > Glasgow-haskell-bugs mailing list > Glasgow-haskell-bugs@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs > > Wow, that fixed the problem! Thanks! -- View this message in context: http://old.nabble.com/foreign-import-PlaySound-causing-GHCi-to-crash-tp27414694p27484270.html Sent from the Haskell - Glasgow-haskell-bugs mailing list archive at Nabble.com. From trac at galois.com Sun Feb 7 10:08:17 2010 From: trac at galois.com (GHC) Date: Sun Feb 7 09:39:37 2010 Subject: [GHC] #3865: On amd64, reading attached file gives "hGetContents: invalid argument (Invalid or incomplete multibyte or wide character)" Message-ID: <042.a7ec652299d0254e84130a2697248679@abbot.galois.com> #3865: On amd64, reading attached file gives "hGetContents: invalid argument (Invalid or incomplete multibyte or wide character)" -------------------------------+-------------------------------------------- Reporter: dsf | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.13 | Keywords: Os: Linux | Testcase: Architecture: x86_64 (amd64) | Failure: None/Unknown -------------------------------+-------------------------------------------- This error seems to be related somehow to locale, but it never happens on the i386 so I'm a bit mystified. I had another file which got the error in a build environment that didn't have any files in /usr/lib/locales, but worked when those files were there. The attached file fails whether the files are in /usr/lib/locales or not. Just read it to get the error: readFile "testinput" >>= putStr Hopefully it is reproducible out there and isn't related to our build. We are using ghc 6.13-20091231. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 7 14:10:05 2010 From: trac at galois.com (GHC) Date: Sun Feb 7 13:41:22 2010 Subject: [GHC] #3866: Constr Eq instance should have better documentation or semantics Message-ID: <053.48fcc2bcaa72d91af4e5c6324198c5c7@abbot.galois.com> #3866: Constr Eq instance should have better documentation or semantics ---------------------------------+------------------------------------------ Reporter: batterseapower | Owner: Type: bug | Status: new Priority: normal | Component: libraries (other) Version: 6.12.1 | Keywords: syb Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ The following code doesn't do what you expect: {{{ data WithData = forall a. Data a => WithData a tupleDataCast :: Data a => ([WithData] -> c) -> a -> Maybe c tupleDataCast f x | Just (s, _) <- find ((toConstr x ==) . snd) tuples = trace (show (toConstr x, s)) $ Just (f [gmapQi i WithData x | i <- [0..s - 1]]) | otherwise = Nothing where tuples = [2..] `zip` [toConstr ((), ()), toConstr ((), (), ()), toConstr ((), (), (), ()), toConstr ((), (), (), (), ()), toConstr ((), (), (), (), (), ())] }}} The reason is that, for example: {{{ Prelude Data.Data> toConstr False == toConstr () True Prelude Data.Data> toConstr True == toConstr () False }}} The Constr data type is only compared on the index. The DataType information in the Constr is totally ignored. This is very surprising behaviour! According to a mailing list thread (http://www.mail-archive.com/glasgow- haskell-bugs@haskell.org/msg08207.html) this is done for efficiency reasons. Either the documentation should mention this behaviour, or the Eq instance should be fixed. My preference is for the latter -- though existing expectations of Constr == efficiency and semantics may be too entrenched to change the behaviour now. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 7 18:08:11 2010 From: trac at galois.com (GHC) Date: Sun Feb 7 17:39:32 2010 Subject: [GHC] #3867: ghc: panic! (linkBCO: >= 64k ptrs) Message-ID: <048.056cb4f380ed3fd1c06f05836f332dd5@abbot.galois.com> #3867: ghc: panic! (linkBCO: >= 64k ptrs) ---------------------------------+------------------------------------------ Reporter: archgrove | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.12.1 | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: GHC rejects valid program ---------------------------------+------------------------------------------ dict is a [String] with around 100,000 entries (around 1.4MB of data), exported from a module Dict. ghci will happily import this module, but any operations on this list (e.g. take 1 dict) fail with a ghc panic. I admit it's perhaps not the best idea to work with a list of this magnitude, but in this case a better error message would be useful. {{{ GHCi, version 6.12.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package ffi-1.0 ... linking ... done. Prelude> :load Dict [1 of 1] Compiling Dict ( Dict.hs, interpreted ) Ok, modules loaded: Dict. *Dict> take 1 dict ghc: panic! (the 'impossible' happened) (GHC version 6.12.1 for i386-apple-darwin): linkBCO: >= 64k ptrs 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 Feb 8 00:06:26 2010 From: trac at galois.com (GHC) Date: Sun Feb 7 23:37:43 2010 Subject: [GHC] #3868: UDP in network module Message-ID: <044.79a2ee71f22f53486bc318403d6e54b4@abbot.galois.com> #3868: UDP in network module --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Component: libraries (other) Version: 6.12.1 | Keywords: Os: Linux | Testcase: Architecture: x86 | Failure: None/Unknown --------------------------------+------------------------------------------- The Network module (at least in 6.10.4) doesn't seem to have any way of creating UDP sockets, requiring using a combination of Network.Socket and Network.BSD, which are quite low level and whose docs are rather sparse. It would be useful if the higher level module also supported UDP. Also, the PortNum constructor in Network.Socket requires the port number in network byte order, i.e. on the x86 you have to byte-swap the PortNum arg. It would save a bit of confusion if (at minimum) the Haddock docs mentioned this. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 8 01:38:13 2010 From: trac at galois.com (GHC) Date: Mon Feb 8 01:09:59 2010 Subject: [GHC] #3869: RTS GC Statistics from -S should be logged via the eventlog system Message-ID: <042.ba02c1597aeebebb22784b09f5ce7c9a@abbot.galois.com> #3869: RTS GC Statistics from -S should be logged via the eventlog system ---------------------------------+------------------------------------------ Reporter: cjs | Owner: Type: feature request | Status: new Priority: normal | Component: Runtime System Version: 6.12.1 | Keywords: gc, garbage collection, statistics Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ The -Sfilename option to the RTS gives useful GC statistics, but it's hard to correlate these with other events, particularly to see if GC is interrupting critical sections in mutator threads. If the same information were instead logged via the eventlog system (perhaps enabled via a "-lg" option) one could get more insight into the garbage generation and collection behaviour of one's program. Note that it's probably not necessary also to store the information given at the end of the run with both "-s" and "-S", though it may be interesting to contemplate moving this sort of thing into the eventlog file as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 8 07:03:52 2010 From: trac at galois.com (GHC) Date: Mon Feb 8 06:35:08 2010 Subject: [GHC] #3787: GHC 6.12.1 panic In-Reply-To: <047.0ece8a101cc798eefac149b629f279fa@abbot.galois.com> References: <047.0ece8a101cc798eefac149b629f279fa@abbot.galois.com> Message-ID: <056.f304850d7662e5e9d3280f9922cb5f3e@abbot.galois.com> #3787: GHC 6.12.1 panic ----------------------------------------+----------------------------------- Reporter: blamario | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler (Type checker) | Version: 6.12.1 Keywords: panic | Difficulty: Os: Linux | Testcase: Architecture: x86_64 (amd64) | Failure: Compile-time crash ----------------------------------------+----------------------------------- Changes (by simonmar): * priority: high => normal * component: Compiler => Compiler (Type checker) * milestone: 6.12.2 => 6.14.1 Comment: This bug is something that we plan to fix in 6.14.1 with the new type inference engine, and there's a workaround for 6.12. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 8 07:09:33 2010 From: trac at galois.com (GHC) Date: Mon Feb 8 06:40:49 2010 Subject: [GHC] #3788: Improved message for GHC "No instance for" Errors In-Reply-To: <048.485a2dc2f99474a564b523723eb1f48f@abbot.galois.com> References: <048.485a2dc2f99474a564b523723eb1f48f@abbot.galois.com> Message-ID: <057.d0ba1bdbdcc548b97fc0a6ee2cafeafd@abbot.galois.com> #3788: Improved message for GHC "No instance for" Errors ---------------------------+------------------------------------------------ Reporter: rhapsodyv | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12.2 Component: Compiler | Version: 6.10.4 Resolution: wontfix | Keywords: errors Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => wontfix Comment: Not clear what is being proposed, no response from submitter. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 8 07:11:10 2010 From: trac at galois.com (GHC) Date: Mon Feb 8 06:42:32 2010 Subject: [GHC] #3782: Data Parallel "Impossible happened" compiler error In-Reply-To: <044.3d41e65d193faf115a9d9aeea6bab909@abbot.galois.com> References: <044.3d41e65d193faf115a9d9aeea6bab909@abbot.galois.com> Message-ID: <053.a39dcde302d3d37958be021f5511353a@abbot.galois.com> #3782: Data Parallel "Impossible happened" compiler error --------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: Data Parallel Haskell | Version: 6.12.1 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown --------------------------------------+------------------------------------- Changes (by simonmar): * cc: rl@? (added) Comment: Roman, have you seen this? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 8 07:20:35 2010 From: trac at galois.com (GHC) Date: Mon Feb 8 06:51:55 2010 Subject: [GHC] #3782: Data Parallel "Impossible happened" compiler error In-Reply-To: <044.3d41e65d193faf115a9d9aeea6bab909@abbot.galois.com> References: <044.3d41e65d193faf115a9d9aeea6bab909@abbot.galois.com> Message-ID: <053.880c7e91d13ac13383a56d587514442a@abbot.galois.com> #3782: Data Parallel "Impossible happened" compiler error --------------------------------------+------------------------------------- Reporter: guest | Owner: rl Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: Data Parallel Haskell | Version: 6.12.1 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown --------------------------------------+------------------------------------- Changes (by rl): * owner: => rl Comment: Oops, no, I missed it. Thanks! The problem is that at the moment, DPH doesn't handle sum types with more than 2 constructors. This is basically a question of implementing the relevant library functions but there are a lot of them and unfortunately, I doubt we'll this any time soon. I'll try to make the message more informative, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 8 07:31:36 2010 From: trac at galois.com (GHC) Date: Mon Feb 8 07:02:54 2010 Subject: [GHC] #3866: Constr Eq instance should have better documentation or semantics In-Reply-To: <053.48fcc2bcaa72d91af4e5c6324198c5c7@abbot.galois.com> References: <053.48fcc2bcaa72d91af4e5c6324198c5c7@abbot.galois.com> Message-ID: <062.bcb9da64a7c0ba61a00d85c3e0f25e74@abbot.galois.com> #3866: Constr Eq instance should have better documentation or semantics ---------------------------------+------------------------------------------ Reporter: batterseapower | Owner: dreixel Type: bug | Status: assigned Priority: normal | Component: libraries (other) Version: 6.12.1 | Keywords: syb Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Changes (by dreixel): * owner: => dreixel * status: new => assigned Comment: I see that this can indeed be confusing, but changing the current semantics of equality of Constr would probably break lots of existing code. So I propose to update the documentation to make this behavior more clear. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 8 07:33:34 2010 From: trac at galois.com (GHC) Date: Mon Feb 8 07:04:49 2010 Subject: [GHC] #3870: Avoid Haddock-links to the Prelude Message-ID: <044.20d302777de4b1a04d5f7bc22a0bc7ca@abbot.galois.com> #3870: Avoid Haddock-links to the Prelude ---------------------------------+------------------------------------------ Reporter: waern | Owner: Type: bug | Status: new Priority: normal | Component: Documentation Version: 6.12.1 | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Documentation bug ---------------------------------+------------------------------------------ If you're generating documenatation that links to the base package, you will see that some links to standard types go to the `Prelude` and some to the hierarchical libararies. For example, `Int` goes to `Prelude.Int`, while `Either` goes to `Data.Either.Either`. This happens because the `Prelude` imports some types from the hierarchical libraries, while some are imported directly from internal GHC modules (e.g. `GHC.Base`). In the first case, the hierarchical module is choosen as the best place to link to since it's closer than the `Prelude` in the topological sort to the original module. In the latter case, the hierarchical module and the `Prelude` are of equal number of imports away from the original module, so none is considered a better place to link to. In this case one of the modules is arbitrarily chosen and it happens to be the `Prelude`. I think it would be nice if the links would always go to the hierarchical libraries. Maybe the best way to achieve that would be to add `{-# OPTIONS_HADDOCK NotHome #-}` to the `Prelude`. This flag is not yet documented (I should get around to that). It tells Haddock to prefer linking to another module if one is available. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 8 08:08:48 2010 From: trac at galois.com (GHC) Date: Mon Feb 8 07:40:04 2010 Subject: [GHC] #3865: On amd64, reading attached file gives "hGetContents: invalid argument (Invalid or incomplete multibyte or wide character)" In-Reply-To: <042.a7ec652299d0254e84130a2697248679@abbot.galois.com> References: <042.a7ec652299d0254e84130a2697248679@abbot.galois.com> Message-ID: <051.8d7b48a08e39562b98cfff9ec008f19f@abbot.galois.com> #3865: On amd64, reading attached file gives "hGetContents: invalid argument (Invalid or incomplete multibyte or wide character)" ---------------------------+------------------------------------------------ Reporter: dsf | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.13 Resolution: invalid | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86_64 (amd64) Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => invalid Comment: The file is encoded in ISO8859-1 (aka Latin-1), so in order to read it you either need to use a Latin-1 locale, or explicitly set the encoding using `hSetEncoding h latin1`. Presumably on your x86-64 system the locale is set to UTF-8, but on your i386 system it is set to Latin-1. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 8 08:10:24 2010 From: trac at galois.com (GHC) Date: Mon Feb 8 07:41:40 2010 Subject: [GHC] #3868: UDP in network module In-Reply-To: <044.79a2ee71f22f53486bc318403d6e54b4@abbot.galois.com> References: <044.79a2ee71f22f53486bc318403d6e54b4@abbot.galois.com> Message-ID: <053.d9f4796f1201add54e2abda7c445c22d@abbot.galois.com> #3868: UDP in network module ----------------------------------+----------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 6.12.1 Keywords: | Difficulty: Os: Linux | Testcase: Architecture: x86 | Failure: None/Unknown ----------------------------------+----------------------------------------- Changes (by simonmar): * cc: johan.tibell@? (added) Comment: Johan - want to move/close this ticket? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 8 08:14:58 2010 From: trac at galois.com (GHC) Date: Mon Feb 8 07:46:45 2010 Subject: [GHC] #3869: RTS GC Statistics from -S should be logged via the eventlog system In-Reply-To: <042.ba02c1597aeebebb22784b09f5ce7c9a@abbot.galois.com> References: <042.ba02c1597aeebebb22784b09f5ce7c9a@abbot.galois.com> Message-ID: <051.dc19066e8ea148c75393f65a3bf1b491@abbot.galois.com> #3869: RTS GC Statistics from -S should be logged via the eventlog system ---------------------------------------------------+------------------------ Reporter: cjs | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.14 branch Component: Runtime System | Version: 6.12.1 Keywords: gc, garbage collection, statistics | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------------------------+------------------------ Changes (by simonmar): * milestone: => 6.14 branch Comment: Yes, I think that would be a good idea, it's something I had in mind actually. That way ThreadScope could give include a graph of the heap size amongst other things. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 8 08:45:10 2010 From: trac at galois.com (GHC) Date: Mon Feb 8 08:16:26 2010 Subject: [GHC] #3865: On amd64, reading attached file gives "hGetContents: invalid argument (Invalid or incomplete multibyte or wide character)" In-Reply-To: <042.a7ec652299d0254e84130a2697248679@abbot.galois.com> References: <042.a7ec652299d0254e84130a2697248679@abbot.galois.com> Message-ID: <051.2007d98675c2a27543426eb6df74f7e7@abbot.galois.com> #3865: On amd64, reading attached file gives "hGetContents: invalid argument (Invalid or incomplete multibyte or wide character)" ---------------------------+------------------------------------------------ Reporter: dsf | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.13 Resolution: invalid | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86_64 (amd64) Failure: None/Unknown | ---------------------------+------------------------------------------------ Comment(by dsf): Oh, I didn't realize that ? was in latin1 (0xee.) Hmm, the error is coming from hscolour, I'm concerned it might run into UTF-8 files it can't handle if I change the locale to Latin-1. Maybe I'll change the file encoding to UTF-8. Should hscolour be able to handle files of either encoding? Should it be using openBinaryFile? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 8 08:54:30 2010 From: trac at galois.com (GHC) Date: Mon Feb 8 08:25:55 2010 Subject: [GHC] #3865: On amd64, reading attached file gives "hGetContents: invalid argument (Invalid or incomplete multibyte or wide character)" In-Reply-To: <042.a7ec652299d0254e84130a2697248679@abbot.galois.com> References: <042.a7ec652299d0254e84130a2697248679@abbot.galois.com> Message-ID: <051.8904e756a44ee21785248530f6f652e7@abbot.galois.com> #3865: On amd64, reading attached file gives "hGetContents: invalid argument (Invalid or incomplete multibyte or wide character)" ---------------------------+------------------------------------------------ Reporter: dsf | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.13 Resolution: invalid | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86_64 (amd64) Failure: None/Unknown | ---------------------------+------------------------------------------------ Comment(by malcolm.wallace@?): hscolour-1.16 contains a bugfix for encoding issues: when built with ghc-6.12.1, it now forces the input and output encodings to be UTF-8. This matches ghc's behaviour, which is also to insist that Haskell source files must be encoded in UTF-8. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 8 09:15:29 2010 From: trac at galois.com (GHC) Date: Mon Feb 8 08:46:58 2010 Subject: [GHC] #3870: Avoid Haddock-links to the Prelude In-Reply-To: <044.20d302777de4b1a04d5f7bc22a0bc7ca@abbot.galois.com> References: <044.20d302777de4b1a04d5f7bc22a0bc7ca@abbot.galois.com> Message-ID: <053.a3ec3b32b83ad28fcda11415298fba38@abbot.galois.com> #3870: Avoid Haddock-links to the Prelude ---------------------------------+------------------------------------------ Reporter: waern | Owner: Type: feature request | Status: new Priority: normal | Component: Documentation Version: 6.12.1 | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Documentation bug ---------------------------------+------------------------------------------ Changes (by ross): * type: bug => feature request Comment: Isn't the reason Prelude.Int is chosen that GHC.Base is hidden, because it isn't part of the public interface of the package? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 8 09:16:16 2010 From: trac at galois.com (GHC) Date: Mon Feb 8 08:47:43 2010 Subject: [GHC] #3865: On amd64, reading attached file gives "hGetContents: invalid argument (Invalid or incomplete multibyte or wide character)" In-Reply-To: <042.a7ec652299d0254e84130a2697248679@abbot.galois.com> References: <042.a7ec652299d0254e84130a2697248679@abbot.galois.com> Message-ID: <051.a6ae7a2b898864eb216c52891396456c@abbot.galois.com> #3865: On amd64, reading attached file gives "hGetContents: invalid argument (Invalid or incomplete multibyte or wide character)" ---------------------------+------------------------------------------------ Reporter: dsf | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.13 Resolution: invalid | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86_64 (amd64) Failure: None/Unknown | ---------------------------+------------------------------------------------ Comment(by dsf): Ok, I get it now. There were some places where LANG was explicitly unset in our autobuilder, I removed them and things are working smoothly now. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 8 11:33:22 2010 From: trac at galois.com (GHC) Date: Mon Feb 8 11:04:41 2010 Subject: [GHC] #3851: type family does not get expanded in ghc-6.12.1 In-Reply-To: <047.9b73a510640cabe71061dde181079f57@abbot.galois.com> References: <047.9b73a510640cabe71061dde181079f57@abbot.galois.com> Message-ID: <056.16bc5d5591380723e084f78ffb036ecc@abbot.galois.com> #3851: type family does not get expanded in ghc-6.12.1 ----------------------------------------+----------------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.12.1 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: GHC rejects valid program ----------------------------------------+----------------------------------- Comment(by simonpj): It's because of an awkward interaction. When matching a GADT, GHC currently requires the context of the pattern to be "rigid", so that it knows exactly what type refinement happens as a result of the match. Well, is a type-function application rigid? Presumably not in 6.12. I'm not sure why it was considered rigid in 6.10. All this grunge about rigidity will be swept away with the new outside-in type inference machinery (see our ICFP'09 paper), so I'm quite reluctant to try to "fix" this. Can you work around it for now, perhaps by using less perspicuous type signatures? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 8 11:33:36 2010 From: trac at galois.com (GHC) Date: Mon Feb 8 11:04:52 2010 Subject: [GHC] #3870: Avoid Haddock-links to the Prelude In-Reply-To: <044.20d302777de4b1a04d5f7bc22a0bc7ca@abbot.galois.com> References: <044.20d302777de4b1a04d5f7bc22a0bc7ca@abbot.galois.com> Message-ID: <053.98445edfbfbd650ac8262e9ce15dcc54@abbot.galois.com> #3870: Avoid Haddock-links to the Prelude ---------------------------------+------------------------------------------ Reporter: waern | Owner: Type: feature request | Status: new Priority: normal | Component: Documentation Version: 6.12.1 | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Documentation bug ---------------------------------+------------------------------------------ Comment(by waern): Replying to [comment:1 ross]: > Isn't the reason Prelude.Int is chosen that GHC.Base is hidden, because it isn't part of the public interface of the package? GHC.Base is not chosen because it is hidden, but that leaves the choice to either Prelude.Int or Data.Int. Haddock prefers the module that is closest to the original module in the dependency tree. Since both Prelude.Int and Data.Int directly imports GHC.Base, they are at the same level of the dependency tree and thus Haddock has to make an arbitrary choice. If Prelude had imported Data.Int and not GHC.Base (just for illustration; such a restructuring may be hard to do since Prelude imports many more things via GHC.Base), the link would go to Data.Int. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 8 11:49:32 2010 From: trac at galois.com (GHC) Date: Mon Feb 8 11:20:58 2010 Subject: [GHC] #3850: EmptyDataDecls and type context In-Reply-To: <049.f27f0f58200e17d4e5b9ff32a4c6b128@abbot.galois.com> References: <049.f27f0f58200e17d4e5b9ff32a4c6b128@abbot.galois.com> Message-ID: <058.3f08c1e695e072d0a65b961a173bb4c2@abbot.galois.com> #3850: EmptyDataDecls and type context ---------------------------------+------------------------------------------ Reporter: Paczesiowa | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.12.1 Keywords: emptydatadecls | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: GHC rejects valid program ---------------------------------+------------------------------------------ Changes (by simonpj): * owner: => igloo * type: bug => merge Comment: OK well I still think it's stupid, but I accept that it's a needless change in behaviour from 6.10, so I'll make 6.12 accept the declaration just as 6.10 did. That way you won't have to change HList. {{{ Mon Feb 8 16:37:51 GMT 2010 simonpj@microsoft.com * Fix Trac #3850 This patch simply avoids a needless difference in behaviour from 6.10, and one that happens to affect HList. See Note [Stupid theta]. }}} Please merge to 6.12 branch. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 8 18:08:44 2010 From: trac at galois.com (GHC) Date: Mon Feb 8 17:39:59 2010 Subject: [GHC] #3868: UDP in network module In-Reply-To: <044.79a2ee71f22f53486bc318403d6e54b4@abbot.galois.com> References: <044.79a2ee71f22f53486bc318403d6e54b4@abbot.galois.com> Message-ID: <053.48a4ffcc72338d5d9980995583f7a818@abbot.galois.com> #3868: UDP in network module --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: libraries (other) | Version: 6.12.1 Resolution: worksforme | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86 Failure: None/Unknown | --------------------------------+------------------------------------------- Changes (by tibbe): * status: new => closed * resolution: => worksforme Comment: You should be able to create an UDP socket by using the `AF_INET` socket family and the `Datagram` socket type. I believe `fromIntegral PORT_NUMBER` will do the correct translation for port numbers, but I agree that the documentation could be better. I you still have problems creating a datagram socket please file a bug at the new trac location: http://trac.haskell.org/network P.S. The network library doesn't handle zero length datagrams correctly, see [http://trac.haskell.org/network/ticket/7 this ticket]. You can use network-bytestring instead which doesn't have this problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 9 06:04:45 2010 From: trac at galois.com (GHC) Date: Tue Feb 9 05:36:01 2010 Subject: [GHC] #3866: Constr Eq instance should have better documentation or semantics In-Reply-To: <053.48fcc2bcaa72d91af4e5c6324198c5c7@abbot.galois.com> References: <053.48fcc2bcaa72d91af4e5c6324198c5c7@abbot.galois.com> Message-ID: <062.37fc0e2332e647244d000fe23574bd31@abbot.galois.com> #3866: Constr Eq instance should have better documentation or semantics ---------------------------------+------------------------------------------ Reporter: batterseapower | Owner: dreixel Type: bug | Status: assigned Priority: normal | Component: libraries (other) Version: 6.12.1 | Keywords: syb Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Comment(by dreixel): I propose the following change: {{{ --- | Representation of constructors +-- | Representation of constructors. Note that for efficiency reasons equality +-- of 'Constr's compares only the associated 'ConstrRep' (which can be accessed +-- with 'constrRep'). See for +-- an example of how this might cause unexpected behavior. data Constr = Constr { conrep :: ConstrRep , constring :: String }}} Patch attached. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 9 07:54:27 2010 From: trac at galois.com (GHC) Date: Tue Feb 9 07:25:45 2010 Subject: [GHC] #3862: ghc crash while building hledger with cabal In-Reply-To: <047.37b3f072a5f2a5fc14090219a1e5d9bd@abbot.galois.com> References: <047.37b3f072a5f2a5fc14090219a1e5d9bd@abbot.galois.com> Message-ID: <056.7f8e4bb08a6fb273704d908cd0a31993@abbot.galois.com> #3862: ghc crash while building hledger with cabal ---------------------------------+------------------------------------------ Reporter: simonmic | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Keywords: | Difficulty: Os: MacOS X | Testcase: Architecture: Unknown/Multiple | Failure: Compile-time crash ---------------------------------+------------------------------------------ Comment(by simonpj): I suspect this is fixed in 6.12 (see eg #3528), but I couldn't try it because I get this when installing dependencies. Maybe `HUnit` isn't 6.12 compatible. {{{ cabal install --with-ghc=$head1 --user HUnit Resolving dependencies... Downloading HUnit-1.2.0.0... Configuring HUnit-1.2.0.0... Preprocessing library HUnit-1.2.0.0... Building HUnit-1.2.0.0... [1 of 5] Compiling Test.HUnit.Terminal ( Test/HUnit/Terminal.lhs, dist/build/Test/HUnit/Terminal.o ) [2 of 5] Compiling Test.HUnit.Lang ( Test/HUnit/Lang.lhs, dist/build/Test/HUnit/Lang.o ) Test/HUnit/Lang.lhs:23:43: Module `Control.Exception' does not export `throwDyn' cabal: Error: some packages failed to install: HUnit-1.2.0.0 failed during the building phase. The exception was: ExitFailure 1 bash-3.2$ }}} Would you like to try with 6.12? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 9 08:10:49 2010 From: trac at galois.com (GHC) Date: Tue Feb 9 07:42:01 2010 Subject: [GHC] #3845: compiling template haskell internal error: ... not in scope during type checking, but it passed the renamer In-Reply-To: <048.f5696685aefedadc5457b44787ff59f6@abbot.galois.com> References: <048.f5696685aefedadc5457b44787ff59f6@abbot.galois.com> Message-ID: <057.886b503462d98e19b883903f68ecf4e5@abbot.galois.com> #3845: compiling template haskell internal error: ... not in scope during type checking, but it passed the renamer ---------------------------------+------------------------------------------ Reporter: JakeWheat | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.12.1 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Comment(by simonpj): Thanks for this. I see what is happening -- it is a palpable bug. To fix it I have changed the `HsType` data type a bit. But that's part of the GHC library API, and we aren't supposed to change the API in a patch- release (ie in 6.12.2). So we have two alternatives * Fix it in the HEAD, but not 6.12 * Fix it in 6.12, but thereby change the 6.12 API a bit Any opinions? Can you use the HEAD? The default is the first alternative. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 9 10:52:38 2010 From: trac at galois.com (GHC) Date: Tue Feb 9 10:24:04 2010 Subject: [GHC] #2959: Merge in LambdaVM (Haskell to Java/JVM bytecode translator) In-Reply-To: <046.4436609d3a414ddff94df71de1efe346@abbot.galois.com> References: <046.4436609d3a414ddff94df71de1efe346@abbot.galois.com> Message-ID: <055.c62deb5418e9b53c4357de5fad84f4e3@abbot.galois.com> #2959: Merge in LambdaVM (Haskell to Java/JVM bytecode translator) ---------------------------------+------------------------------------------ Reporter: kgardas | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.11 Keywords: | Difficulty: Unknown Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Comment(by balliet): Hi, I'm the author of LambdaVM. I was recently pointed here by a potential LambdaVM user, I had no idea a ticket existed for it. Apologies for not posting sooner. I'd agree with Simon M that LambdaVM is really in no state to be merged into the GHC tree right now. Aside from me not having time right now to update it for GHC HEAD, and maintain it, there are a few other issues: * At the time I was writing LambdaVM I was more or less using the LambdaVM tree as my GHC playground. There are lots of patches that aren't directly related to LambdaVM. Some of them probably should probably be dumped, and others merged separately from LambdaVM. This all needs to be sorted out. * I made lots of deep changes to the compiler that might sit well with everyone. For example, plumbing sub-word size types (Word8#, etc) though the whole compiler, to better support interfacing with existing java code. I split the unlifted kind into ptr and non-ptr subkinds, to support some level of polymorphism with unlifted types (java object types are foreign imported unlifted types). The unboxed array types are parametrized over their element type (for example UArray# Word#), since int[] and byte[] are very different in the JVM. Finding a happy medium between proper JVM support and over complicating the rest of the compiler will probably take some work. * I'm not happy at all with how the JVM backend is invoked. Right now it is setup as a separate "way", which was convenient because I could have a native and JVM compiler in one binary, but I think I'm really abusing the "way" system with this. We'd have to figure out a story for cross compilers (which is more or less what LambdaVM is). I hate to have to do what gcc does, and require a totally separate binary for each target. It seems that with all the DynFlags plumbing that is already in place supporting multiple targets in one binary (at least in the front end at least) should be possible. And that is just the stuff I could remember off the top of my head (which hasn't been in it for a while). While I wouldn't hold your breath waiting for this all to come together, I wouldn't give up on it yet. I still have to finish my thesis (which is the reason LambdaVM exists) one of these days (hopefully soon, the school isn't going to be happy with me if I don't get on that...) and when that happens I'll certainly update LambdaVM to GHC HEAD. After the thesis is behind me I can think about trying to merge it. So stay tuned. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 9 12:11:58 2010 From: trac at galois.com (GHC) Date: Tue Feb 9 11:43:12 2010 Subject: [GHC] #3851: type family does not get expanded in ghc-6.12.1 In-Reply-To: <047.9b73a510640cabe71061dde181079f57@abbot.galois.com> References: <047.9b73a510640cabe71061dde181079f57@abbot.galois.com> Message-ID: <056.1f545b9deb31ee8cfe97986e9cd9c89c@abbot.galois.com> #3851: type family does not get expanded in ghc-6.12.1 ----------------------------------------+----------------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.12.1 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: GHC rejects valid program ----------------------------------------+----------------------------------- Comment(by dreixel): Note, however, that if we use a data family {{{ data family DF a :: * -> * data instance DF () a = D (App (Equ ()) a) bar :: DF () () -> () bar (D (App Refl)) = () }}} then both 6.10.4 and 6.12.1 fail to compile, and I wouldn't know how to write this signature in any other way. In any case, the example with type families makes the multirec library basically unusable in 6.12. The workaround would require giving type signatures which are easily 10 lines long. Is there a milestone for the implementation of the new type-inference machinery? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 9 12:24:55 2010 From: trac at galois.com (GHC) Date: Tue Feb 9 11:56:07 2010 Subject: [GHC] #3676: realToFrac doesn't sanely convert between floating types In-Reply-To: <046.c71a4f69a48e7e64e18a56e29c643e03@abbot.galois.com> References: <046.c71a4f69a48e7e64e18a56e29c643e03@abbot.galois.com> Message-ID: <055.9f4804a703a4ad665896ae14b9d8ee25@abbot.galois.com> #3676: realToFrac doesn't sanely convert between floating types ----------------------------------+----------------------------------------- Reporter: draconx | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: libraries (other) | Version: 6.12.1 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: x86_64 (amd64) | Failure: None/Unknown ----------------------------------+----------------------------------------- Changes (by draconx): * version: 6.10.4 => 6.12.1 Comment: Still present in 6.12.1. I just discovered that the issue is worse than originally described: the behaviour of realToFrac *changes* if it gets inlined. Consider the following: {{{ module Main where {-# NOINLINE holycow #-} holycow :: (Real a, Fractional b) => a -> b holycow = realToFrac main = do print (realToFrac (0/0 :: Double) :: Double) print (holycow (0/0 :: Double) :: Double) }}} If you compile without optimisation, both lines print -Infinity as originally described. However, if you enable optimisation, the first line prints NaN (yay!) but the second line still prints -Infinity. GHC seems to be optimising based on the incorrect assumption that realToFrac :: Double -> Double is the identity function. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 9 13:18:45 2010 From: trac at galois.com (GHC) Date: Tue Feb 9 12:49:58 2010 Subject: [GHC] #3838: Performance issues with blackholes In-Reply-To: <047.ef7e7bc3345d4bdf14652daf490fba4d@abbot.galois.com> References: <047.ef7e7bc3345d4bdf14652daf490fba4d@abbot.galois.com> Message-ID: <056.8ebedc7e851b4a6c8cb5a2454b901f07@abbot.galois.com> #3838: Performance issues with blackholes ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.14 branch Component: Runtime System | Version: 6.12.1 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Runtime performance bug ---------------------------------+------------------------------------------ Comment(by bos): See also http://github.com/bos/event/commit/29abdc23d7d693e0f050ea81d288c9ba541f20ff for an example of how this makes performance with IORefs very difficult to understand or predict. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 9 16:25:51 2010 From: trac at galois.com (GHC) Date: Tue Feb 9 15:57:02 2010 Subject: [GHC] #3871: Missing reference in manpage Message-ID: <051.223f75e0ebf270e8f5107d53f1d88e6c@abbot.galois.com> #3871: Missing reference in manpage ---------------------------------+------------------------------------------ Reporter: marcotmarcot | Owner: Type: bug | Status: new Priority: normal | Component: Documentation Version: 6.12.1 | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ from ghc(1): -e expr Evaluate expr; see for details. I think there's a word missing after see. Greetings. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 9 21:56:28 2010 From: trac at galois.com (GHC) Date: Tue Feb 9 21:27:38 2010 Subject: [GHC] #3838: Performance issues with blackholes In-Reply-To: <047.ef7e7bc3345d4bdf14652daf490fba4d@abbot.galois.com> References: <047.ef7e7bc3345d4bdf14652daf490fba4d@abbot.galois.com> Message-ID: <056.76f525a44f0ad6ef2a073c7f78801ecd@abbot.galois.com> #3838: Performance issues with blackholes ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.14 branch Component: Runtime System | Version: 6.12.1 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Runtime performance bug ---------------------------------+------------------------------------------ Changes (by tibbe): * cc: tibbe (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 10 06:51:51 2010 From: trac at galois.com (GHC) Date: Wed Feb 10 06:22:59 2010 Subject: [GHC] #3676: realToFrac doesn't sanely convert between floating types In-Reply-To: <046.c71a4f69a48e7e64e18a56e29c643e03@abbot.galois.com> References: <046.c71a4f69a48e7e64e18a56e29c643e03@abbot.galois.com> Message-ID: <055.9e1b82e3999519c2ac3b4077de26676c@abbot.galois.com> #3676: realToFrac doesn't sanely convert between floating types ----------------------------------+----------------------------------------- Reporter: draconx | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: libraries (other) | Version: 6.12.1 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: x86_64 (amd64) | Failure: None/Unknown ----------------------------------+----------------------------------------- Comment(by simonpj): Yes, that's because the library `GHC.Float` contains the (clearly incorrect) RULE {{{ "realToFrac/Double->Double" realToFrac = id :: Double -> Double }}} This ticket really really needs someone who knows and cares about numbers to figure out what the Right Thing is. It's a library issue involving only Haskell source code. Would someone like to help? Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 10 09:30:04 2010 From: trac at galois.com (GHC) Date: Wed Feb 10 09:01:18 2010 Subject: [GHC] #3866: Constr Eq instance should have better documentation or semantics In-Reply-To: <053.48fcc2bcaa72d91af4e5c6324198c5c7@abbot.galois.com> References: <053.48fcc2bcaa72d91af4e5c6324198c5c7@abbot.galois.com> Message-ID: <062.16db6dd9932d91e1d5d94978cfb17ba7@abbot.galois.com> #3866: Constr Eq instance should have better documentation or semantics ---------------------------------+------------------------------------------ Reporter: batterseapower | Owner: dreixel Type: bug | Status: assigned Priority: normal | Component: libraries (other) Version: 6.12.1 | Keywords: syb Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Comment(by NeilMitchell): dreixel: Thanks for doing and patch and writing some better documentation. However, wouldn't it be better to avoid details of the implementation, skip the bug report link, and just document the API. How about: {{{ -- | Representation of constructors. Note that equality on constructors with different types may not work -- i.e. the constructors for 'False' and 'Nothing' may compare equal. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 10 10:24:30 2010 From: trac at galois.com (GHC) Date: Wed Feb 10 09:55:39 2010 Subject: [GHC] #3872: New way to make the simplifier diverge Message-ID: <046.1b2e753f6779610f3b007d619b3ca555@abbot.galois.com> #3872: New way to make the simplifier diverge ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.12.1 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ GHC's simplifier can go into a loop if you use fixpoints in a funny way, as documented here http://www.haskell.org/ghc/docs/latest/html/users_guide/bugs.html#bugs-ghc (12.2.1, third bullet). But GADTs provide new opportunities. This ticket records one, thanks to Ryan Ingram and Matthieu Sozeau: {{{ {-# LANGUAGE GADTs #-} module Contr where newtype I f = I (f ()) data R o a where R :: (a (I a) -> o) -> R o (I a) run :: R o (I (R o)) -> R o (I (R o)) -> o run x (R f) = f x rir :: (R o) (I (R o)) rir = R (\x -> run x x) absurd :: a absurd = run rir rir }}} Now the simplifier can loop. Look: {{{ run rir rir = {inline run} case rir of R f -> f rir = {case of known constructor} let { f = \x -> run x x } in f rir = {inline f} run rir rir }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 10 10:26:43 2010 From: trac at galois.com (GHC) Date: Wed Feb 10 09:57:53 2010 Subject: [GHC] #3845: compiling template haskell internal error: ... not in scope during type checking, but it passed the renamer In-Reply-To: <048.f5696685aefedadc5457b44787ff59f6@abbot.galois.com> References: <048.f5696685aefedadc5457b44787ff59f6@abbot.galois.com> Message-ID: <057.a6ef0a36bf15ef07a66c4f942c348484@abbot.galois.com> #3845: compiling template haskell internal error: ... not in scope during type checking, but it passed the renamer ---------------------------------+------------------------------------------ Reporter: JakeWheat | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.12.1 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Comment(by simonpj): Fixed in the HEAD by {{{ Wed Feb 10 06:51:55 PST 2010 simonpj@microsoft.com * Keep track of explicit kinding in HsTyVarBndr; plus fix Trac #3845 To print HsTypes correctly we should remember whether the Kind on a HsTyVarBndr came from type inference, or was put there by the user. See Note [Printing KindedTyVars] in HsTypes. So instead of changing a UserTyVar to a KindedTyVar during kind checking, we simply add a PostTcKind to the UserTyVar. The change was provoked by Trac #3830, although other changes mean that #3830 gets a diferent and better error message now. So this patch is simply doing the Right Thing for the future. This patch also fixes Trac #3845, which was caused by a *type splice* not remembering the free *term variables* mentioned in it. Result was that we build a 'let' when it should have been 'letrec'. Hence a new FreeVars field in HsSpliceTy. While I was at it, I got rid of HsSpliceTyOut and use a PostTcKind on HsSpliceTy instead, just like on the UserTyVar. M ./compiler/deSugar/DsMeta.hs -6 +7 M ./compiler/hsSyn/Convert.lhs -1 +1 M ./compiler/hsSyn/HsDecls.lhs -1 +1 M ./compiler/hsSyn/HsTypes.lhs -31 +53 M ./compiler/hsSyn/HsUtils.lhs -1 +5 M ./compiler/parser/Parser.y.pp -8 +6 M ./compiler/parser/RdrHsSyn.lhs -4 +2 M ./compiler/rename/RnHsSyn.lhs -3 +2 M ./compiler/rename/RnTypes.lhs -5 +4 M ./compiler/typecheck/TcClassDcl.lhs -1 +2 M ./compiler/typecheck/TcEnv.lhs -6 +3 M ./compiler/typecheck/TcGenDeriv.lhs -1 +2 M ./compiler/typecheck/TcHsType.lhs -45 +14 M ./compiler/typecheck/TcSplice.lhs -7 +5 M ./compiler/typecheck/TcSplice.lhs-boot -1 +2 M ./compiler/typecheck/TcTyClsDecls.lhs -16 +16 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 10 13:32:24 2010 From: trac at galois.com (GHC) Date: Wed Feb 10 13:03:35 2010 Subject: [GHC] #3676: realToFrac doesn't sanely convert between floating types In-Reply-To: <046.c71a4f69a48e7e64e18a56e29c643e03@abbot.galois.com> References: <046.c71a4f69a48e7e64e18a56e29c643e03@abbot.galois.com> Message-ID: <055.34144a25af15a68f0847503b2f1227f1@abbot.galois.com> #3676: realToFrac doesn't sanely convert between floating types ----------------------------------+----------------------------------------- Reporter: draconx | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: libraries (other) | Version: 6.12.1 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: x86_64 (amd64) | Failure: None/Unknown ----------------------------------+----------------------------------------- Comment(by isaacdupree): my gut feeling has been there should be a function or functions specifically to convert between different floating types. I think this is something that needs to be invented and proposed on libraries@ . (I'm not volunteering to do it this week because I'm going to a conference, but I'm willing to get the conversation started next week) -Isaac Dupree -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 10 16:15:50 2010 From: trac at galois.com (GHC) Date: Wed Feb 10 15:47:02 2010 Subject: [GHC] #3845: compiling template haskell internal error: ... not in scope during type checking, but it passed the renamer In-Reply-To: <048.f5696685aefedadc5457b44787ff59f6@abbot.galois.com> References: <048.f5696685aefedadc5457b44787ff59f6@abbot.galois.com> Message-ID: <057.f66e851e482d9cbba7bdd2480e659bff@abbot.galois.com> #3845: compiling template haskell internal error: ... not in scope during type checking, but it passed the renamer ---------------------------------+------------------------------------------ Reporter: JakeWheat | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.12.1 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Comment(by JakeWheat): Replying to [comment:1 simonpj]: > So we have two alternatives > * Fix it in the HEAD, but not 6.12 > * Fix it in 6.12, but thereby change the 6.12 API a bit > > Any opinions? Can you use the HEAD? > > The default is the first alternative. The default is fine for me. Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 10 16:57:31 2010 From: trac at galois.com (GHC) Date: Wed Feb 10 16:28:40 2010 Subject: [GHC] #3873: template haskell: incorrect Warning: defined but not used Message-ID: <048.7f0aac360228e50b2a27c089f24cb981@abbot.galois.com> #3873: template haskell: incorrect Warning: defined but not used ---------------------------------+------------------------------------------ Reporter: JakeWheat | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.12.1 | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Incorrect warning at compile-time ---------------------------------+------------------------------------------ example code: {{{ {-# LANGUAGE TemplateHaskell #-} module THWarnBug where import Language.Haskell.TH mhlt :: Q Type mhlt = do let u = [t| String |] [t| $u |] }}} compiling gives: {{{ $ ghc -c -Wall THWarnBug.hs THWarnBug.hs:9:6: Warning: Defined but not used: `u' }}} but obviously u is used. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 10 23:03:10 2010 From: trac at galois.com (GHC) Date: Wed Feb 10 22:34:49 2010 Subject: [GHC] #3874: GHC.Exts.traceEvent segfaults Message-ID: <042.5001be7fcc4218b1286fd5d57d850c3a@abbot.galois.com> #3874: GHC.Exts.traceEvent segfaults -------------------------------+-------------------------------------------- Reporter: cjs | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 6.12.1 | Keywords: event, eventlog Os: Linux | Testcase: Architecture: x86_64 (amd64) | Failure: None/Unknown -------------------------------+-------------------------------------------- When I call the GC.Exts.traceEvent function (argument: "hello") with event logging enabled (i.e., compiled with -eventlog and run with -ls) my program generates a segmentation fault. Here is the gdb backtrace: {{{ #0 0x00007f3ad6744a2f in vfprintf () from /lib/libc.so.6 #1 0x00007f3ad677039a in vsnprintf () from /lib/libc.so.6 #2 0x00000000004476c4 in postLogMsg (eb=0x8160d0, type=19, msg=0x7f3ad5d7e010 "hello", ap=0x0) at rts/eventlog/EventLog.c:403 #3 0x0000000000447853 in postUserMsg (cap=0x69b780, msg=0x7f3ad5d7e010 "hello") at rts/eventlog/EventLog.c:433 #4 0x000000000043b012 in traceUserMsg (cap=0x69b780, msg=0x7f3ad5d7e010 "hello") at rts/Trace.c:290 #5 0x000000000044e237 in stg_traceEventzh () #6 0x0000000000000000 in ?? () }}} It's not at all clear to me what could be going wrong here. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 10 23:18:13 2010 From: trac at galois.com (GHC) Date: Wed Feb 10 22:49:36 2010 Subject: [GHC] #3874: GHC.Exts.traceEvent segfaults In-Reply-To: <042.5001be7fcc4218b1286fd5d57d850c3a@abbot.galois.com> References: <042.5001be7fcc4218b1286fd5d57d850c3a@abbot.galois.com> Message-ID: <051.e8cc5197c9d33aa04fd25c4c68338162@abbot.galois.com> #3874: GHC.Exts.traceEvent segfaults -------------------------------+-------------------------------------------- Reporter: cjs | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 6.12.1 | Keywords: event, eventlog Os: Linux | Testcase: Architecture: x86_64 (amd64) | Failure: None/Unknown -------------------------------+-------------------------------------------- Comment(by cjs): Oh, and for further fun, I've walked through the calls from traceMessage down, and I don't see anywhere where we check for format specifiers in the string the user passes in. I think we want to change this function: {{{ void postUserMsg(Capability *cap, char *msg) { postLogMsg(&capEventBuf[cap->no], EVENT_USER_MSG, msg, NULL); } }}} to have the body {{{ postLogMsg(&capEventBuf[cap->no], EVENT_USER_MSG, "%s", msg, NULL); }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 11 00:12:18 2010 From: trac at galois.com (GHC) Date: Wed Feb 10 23:43:51 2010 Subject: [GHC] #3874: GHC.Exts.traceEvent segfaults In-Reply-To: <042.5001be7fcc4218b1286fd5d57d850c3a@abbot.galois.com> References: <042.5001be7fcc4218b1286fd5d57d850c3a@abbot.galois.com> Message-ID: <051.dee9c0ae95159b2380ab2972ba403c2c@abbot.galois.com> #3874: GHC.Exts.traceEvent segfaults -------------------------------+-------------------------------------------- Reporter: cjs | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 6.12.1 | Keywords: event, eventlog Os: Linux | Testcase: Architecture: x86_64 (amd64) | Failure: None/Unknown -------------------------------+-------------------------------------------- Comment(by cjs): "You can't call varargs functions like that," at least not on this system. Also, we need to fix that printf format args issue. So here's your new code: {{{ void postUserMsg(Capability *cap, char *msg) { postFormatUserMsg(cap, "%s", msg); } static void postSafeuserMsg(Capability *cap, char *format, ...) { va_list ap; va_start(ap, format); postLogMsg(&capEventBuf[cap->no], EVENT_USER_MSG, format, ap); va_end(ap); } }}} Note that there are a few other places in the code where you'll have to do similar things, such as in rts/Trace.c the call to traceCap_stderr in traceUserMsg. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 11 03:45:00 2010 From: trac at galois.com (GHC) Date: Thu Feb 11 03:16:14 2010 Subject: [GHC] #2443: @EnableWin32DLLs@ in mk/config.mk In-Reply-To: <045.5cbd6ee8b0d9740b3306b11c8e19da4a@abbot.galois.com> References: <045.5cbd6ee8b0d9740b3306b11c8e19da4a@abbot.galois.com> Message-ID: <054.f7d92aea83ac56dce3214b6b158e55f3@abbot.galois.com> #2443: @EnableWin32DLLs@ in mk/config.mk ---------------------------+------------------------------------------------ Reporter: rurban | Owner: rurban Type: bug | Status: closed Priority: normal | Milestone: 6.12 branch Component: Build System | Version: 6.8.3 Resolution: fixed | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: x86 Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by benl): * status: assigned => closed * failure: => None/Unknown * resolution: => fixed Comment: Windows DLLs should work now, and this config var was removed. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 11 03:54:47 2010 From: trac at galois.com (GHC) Date: Thu Feb 11 03:25:57 2010 Subject: [GHC] #3875: DPH QuickHull example crashes on SPARC with -N > 1 Message-ID: <043.48127cd9f809a0bcf184a76857f65e8a@abbot.galois.com> #3875: DPH QuickHull example crashes on SPARC with -N > 1 ------------------------+--------------------------------------------------- Reporter: benl | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.13 | Keywords: Os: Solaris | Testcase: Architecture: sparc | Failure: Runtime crash ------------------------+--------------------------------------------------- {{{ ... ghc-head-build/libraries/dph/examples/quickhull$ par/quickhull 10000 +RTS -N1 N = 10000: 503/520 503/520 503/520 ... ghc-head-build/libraries/dph/examples/quickhull$ par/quickhull 10000 +RTS -N2 Bus Error (core dumped) }}} GDB says: {{{ (gdb) bt #0 0x0197f5ec in eval_thunk_selector () #1 0x019806e0 in scavenge_block () #2 0x01981b48 in scavenge_loop () #3 0x01974934 in scavenge_until_all_done () #4 0x01975828 in GarbageCollect () #5 0x0196cd3c in scheduleDoGC () #6 0x0196e708 in schedule () #7 0x0196ba54 in real_main () #8 0x0196bbfc in hs_main () #9 0x000121bc in _start () }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 11 03:58:13 2010 From: trac at galois.com (GHC) Date: Thu Feb 11 03:29:21 2010 Subject: [GHC] #3875: DPH QuickHull example crashes on SPARC with -N > 1 In-Reply-To: <043.48127cd9f809a0bcf184a76857f65e8a@abbot.galois.com> References: <043.48127cd9f809a0bcf184a76857f65e8a@abbot.galois.com> Message-ID: <052.9091b249fed4bedc67556e685a7f754f@abbot.galois.com> #3875: DPH QuickHull example crashes on SPARC with -N > 1 ------------------------+--------------------------------------------------- Reporter: benl | Owner: benl Type: bug | Status: assigned Priority: normal | Component: Compiler Version: 6.13 | Keywords: Os: Solaris | Testcase: Architecture: sparc | Failure: Runtime crash ------------------------+--------------------------------------------------- Changes (by benl): * owner: => benl * status: new => assigned -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 11 03:59:49 2010 From: trac at galois.com (GHC) Date: Thu Feb 11 03:31:21 2010 Subject: [GHC] #3874: GHC.Exts.traceEvent segfaults In-Reply-To: <042.5001be7fcc4218b1286fd5d57d850c3a@abbot.galois.com> References: <042.5001be7fcc4218b1286fd5d57d850c3a@abbot.galois.com> Message-ID: <051.a323644c46102b8223da4e6d976bd7d1@abbot.galois.com> #3874: GHC.Exts.traceEvent segfaults -------------------------------+-------------------------------------------- Reporter: cjs | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 6.12.1 | Keywords: event, eventlog Os: Linux | Testcase: Architecture: x86_64 (amd64) | Failure: Runtime crash -------------------------------+-------------------------------------------- Changes (by cjs): * failure: None/Unknown => Runtime crash -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 11 04:05:21 2010 From: trac at galois.com (GHC) Date: Thu Feb 11 03:36:31 2010 Subject: [GHC] #3875: DPH QuickHull example crashes on SPARC with -N > 1 In-Reply-To: <043.48127cd9f809a0bcf184a76857f65e8a@abbot.galois.com> References: <043.48127cd9f809a0bcf184a76857f65e8a@abbot.galois.com> Message-ID: <052.0cb55e4917a41c16d321889f838b818c@abbot.galois.com> #3875: DPH QuickHull example crashes on SPARC with -N > 1 ------------------------+--------------------------------------------------- Reporter: benl | Owner: benl Type: bug | Status: assigned Priority: normal | Component: Compiler Version: 6.13 | Keywords: Os: Solaris | Testcase: Architecture: sparc | Failure: Runtime crash ------------------------+--------------------------------------------------- Comment(by benl): Sadly, compiling with `-debug` and running the same program with `+RTS -Dg` makes it work. Heisenbugs are my least favourite. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 11 04:23:01 2010 From: trac at galois.com (GHC) Date: Thu Feb 11 03:54:32 2010 Subject: [GHC] #3874: GHC.Exts.traceEvent segfaults In-Reply-To: <042.5001be7fcc4218b1286fd5d57d850c3a@abbot.galois.com> References: <042.5001be7fcc4218b1286fd5d57d850c3a@abbot.galois.com> Message-ID: <051.f85e942383cb2c80b8262644010f7ca1@abbot.galois.com> #3874: GHC.Exts.traceEvent segfaults -------------------------------+-------------------------------------------- Reporter: cjs | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 6.12.1 | Keywords: event, eventlog Os: Linux | Testcase: Architecture: x86_64 (amd64) | Failure: Runtime crash -------------------------------+-------------------------------------------- Comment(by cjs): My earlier "postSafeuserMsg" patch was wrong in several ways; instead use the attachment just added now, 3874-1.patch, which is tested and fixes more bugs. With a test program {{{main = traceEvent "hello"}}}, this fixes the following cases that were previously segfaulted: {{{ ghc -eventlog -o test test.hs && ./test +RTS -ls ghc -debug -eventlog -o test test.hs && ./test +RTS -ls -v }}} However, the following test case still segfaults: {{{ ghc -eventlog -o test test.hs && ./test +RTS -ls -v }}} The backtrace for this case is quite different: {{{ #0 0x000000000043dcef in postSchedEvent () #1 0x00000000004358a6 in createThread () #2 0x000000000044e759 in createIOThread () #3 0x000000000044e812 in rts_evalLazyIO () #4 0x0000000000430d11 in real_main () #5 0x0000000000430e1f in hs_main () #6 0x00007f1df3e245a6 in __libc_start_main () from /lib/libc.so.6 #7 0x0000000000402f09 in _start () at ../sysdeps/x86_64/elf/start.S:113 }}} I had a quick look here, and the problem does not appear to be the same va_list issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 11 05:02:39 2010 From: trac at galois.com (GHC) Date: Thu Feb 11 04:33:49 2010 Subject: [GHC] #3676: realToFrac doesn't sanely convert between floating types In-Reply-To: <046.c71a4f69a48e7e64e18a56e29c643e03@abbot.galois.com> References: <046.c71a4f69a48e7e64e18a56e29c643e03@abbot.galois.com> Message-ID: <055.b137da5f347b517f8f54a81d595bc92b@abbot.galois.com> #3676: realToFrac doesn't sanely convert between floating types ----------------------------------+----------------------------------------- Reporter: draconx | Owner: simonmar Type: bug | Status: assigned Priority: normal | Milestone: 6.12.2 Component: libraries (other) | Version: 6.12.1 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: x86_64 (amd64) | Failure: None/Unknown ----------------------------------+----------------------------------------- Changes (by simonmar): * owner: => simonmar * status: new => assigned -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 11 05:12:03 2010 From: trac at galois.com (GHC) Date: Thu Feb 11 04:43:10 2010 Subject: [GHC] #3676: realToFrac doesn't sanely convert between floating types In-Reply-To: <046.c71a4f69a48e7e64e18a56e29c643e03@abbot.galois.com> References: <046.c71a4f69a48e7e64e18a56e29c643e03@abbot.galois.com> Message-ID: <055.8430394d9786591565d552dabc830286@abbot.galois.com> #3676: realToFrac doesn't sanely convert between floating types ----------------------------------+----------------------------------------- Reporter: draconx | Owner: simonmar Type: bug | Status: assigned Priority: normal | Milestone: 6.12.2 Component: libraries (other) | Version: 6.12.1 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: x86_64 (amd64) | Failure: None/Unknown ----------------------------------+----------------------------------------- Comment(by simonmar): I think it's pretty straightforward. `toRational` should be able to convert NaN, Infinity and -Infinity correctly to Rational, and there is already code in fromRational to convert them back to the floating point types correctly (I imagine it's there in order to make things like `read "NaN"` work). The Haskell report doesn't say anything about the implementation of `toRational`, so I think this is correct. I'm validating a patch now. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 11 05:58:35 2010 From: trac at galois.com (GHC) Date: Thu Feb 11 05:30:09 2010 Subject: [GHC] #3874: GHC.Exts.traceEvent segfaults In-Reply-To: <042.5001be7fcc4218b1286fd5d57d850c3a@abbot.galois.com> References: <042.5001be7fcc4218b1286fd5d57d850c3a@abbot.galois.com> Message-ID: <051.87039154b8520f0f8ca542668fcd9db4@abbot.galois.com> #3874: GHC.Exts.traceEvent segfaults --------------------------------+------------------------------------------- Reporter: cjs | Owner: simonmar Type: bug | Status: assigned Priority: high | Milestone: 6.12.2 Component: Runtime System | Version: 6.12.1 Keywords: event, eventlog | Difficulty: Os: Linux | Testcase: Architecture: x86_64 (amd64) | Failure: Runtime crash --------------------------------+------------------------------------------- Changes (by simonmar): * owner: => simonmar * priority: normal => high * status: new => assigned * milestone: => 6.12.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 11 06:24:39 2010 From: trac at galois.com (GHC) Date: Thu Feb 11 05:55:51 2010 Subject: [GHC] #3875: DPH QuickHull example crashes on SPARC with -N > 1 In-Reply-To: <043.48127cd9f809a0bcf184a76857f65e8a@abbot.galois.com> References: <043.48127cd9f809a0bcf184a76857f65e8a@abbot.galois.com> Message-ID: <052.90f922382e8514938c7120e67f1fb8b7@abbot.galois.com> #3875: DPH QuickHull example crashes on SPARC with -N > 1 -------------------------------+-------------------------------------------- Reporter: benl | Owner: benl Type: bug | Status: assigned Priority: high | Milestone: 6.12.2 Component: Runtime System | Version: 6.13 Keywords: | Difficulty: Os: Solaris | Testcase: Architecture: sparc | Failure: Runtime crash -------------------------------+-------------------------------------------- Changes (by simonmar): * priority: normal => high * component: Compiler => Runtime System * milestone: => 6.12.2 Comment: Is this only on Sparc? I wonder if there is a missing `write_barrier()` somewhere. This is likely to be a tricky one - `eval_thunk_selector` is a notorious bug farm. I thought I'd got them all, but evidently not. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 11 06:31:50 2010 From: trac at galois.com (GHC) Date: Thu Feb 11 06:02:57 2010 Subject: [GHC] #3845: compiling template haskell internal error: ... not in scope during type checking, but it passed the renamer In-Reply-To: <048.f5696685aefedadc5457b44787ff59f6@abbot.galois.com> References: <048.f5696685aefedadc5457b44787ff59f6@abbot.galois.com> Message-ID: <057.8ecd3be7cc4bbb0caf9dd6e40c24d7d5@abbot.galois.com> #3845: compiling template haskell internal error: ... not in scope during type checking, but it passed the renamer ---------------------------+------------------------------------------------ Reporter: JakeWheat | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.12.1 Resolution: fixed | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: OK, good, closing then. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 11 06:32:12 2010 From: trac at galois.com (GHC) Date: Thu Feb 11 06:03:18 2010 Subject: [GHC] #3873: template haskell: incorrect Warning: defined but not used In-Reply-To: <048.7f0aac360228e50b2a27c089f24cb981@abbot.galois.com> References: <048.7f0aac360228e50b2a27c089f24cb981@abbot.galois.com> Message-ID: <057.f92aa7514573d7f852ce60c7eb103d53@abbot.galois.com> #3873: template haskell: incorrect Warning: defined but not used ------------------------------------------------+--------------------------- Reporter: JakeWheat | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.12.1 Resolution: fixed | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Incorrect warning at compile-time | ------------------------------------------------+--------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: Happily the fix for #3845 does this too. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 11 07:00:34 2010 From: trac at galois.com (GHC) Date: Thu Feb 11 06:31:55 2010 Subject: [GHC] #3876: assignement of thrown extension to variable of type string Message-ID: <051.214114d7a628f8b146f84a9a126abc23@abbot.galois.com> #3876: assignement of thrown extension to variable of type string ---------------------------------+------------------------------------------ Reporter: andrewufrank | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ in an unusual case (exception thrown in code in the return) the thrown exception is returned from the function and then assigned to a variable with another type (e.g. string); if the variable is later evaluated, the exception is then actually thrown there (and not in the original function). the bug is the problem in the asignement of a thrown exception to another type. the coding style is unfortunate and not encourage, but the compiler should report an error. (code like = do ... return (case x of 0 -> throw Anexception ) produces the error. i attach a file to demonstrate the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 11 08:27:20 2010 From: trac at galois.com (GHC) Date: Thu Feb 11 07:58:28 2010 Subject: [GHC] #3676: realToFrac doesn't sanely convert between floating types In-Reply-To: <046.c71a4f69a48e7e64e18a56e29c643e03@abbot.galois.com> References: <046.c71a4f69a48e7e64e18a56e29c643e03@abbot.galois.com> Message-ID: <055.60e51de51a86d71ddfc682ba9a98d8f9@abbot.galois.com> #3676: realToFrac doesn't sanely convert between floating types ----------------------------------+----------------------------------------- Reporter: draconx | Owner: simonmar Type: bug | Status: assigned Priority: normal | Milestone: 6.12.2 Component: libraries (other) | Version: 6.12.1 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: x86_64 (amd64) | Failure: None/Unknown ----------------------------------+----------------------------------------- Comment(by draconx): Don't forget negative zero. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 11 09:10:08 2010 From: trac at galois.com (GHC) Date: Thu Feb 11 08:41:19 2010 Subject: [GHC] #3676: realToFrac doesn't sanely convert between floating types In-Reply-To: <046.c71a4f69a48e7e64e18a56e29c643e03@abbot.galois.com> References: <046.c71a4f69a48e7e64e18a56e29c643e03@abbot.galois.com> Message-ID: <055.b717556135d67af1e776feee39aac4c2@abbot.galois.com> #3676: realToFrac doesn't sanely convert between floating types ----------------------------------+----------------------------------------- Reporter: draconx | Owner: simonmar Type: bug | Status: assigned Priority: normal | Milestone: 6.12.2 Component: libraries (other) | Version: 6.12.1 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: x86_64 (amd64) | Failure: None/Unknown ----------------------------------+----------------------------------------- Comment(by simonmar): I've fixed this, but I'm not sure the fix is an improvement. {{{ Thu Feb 11 02:19:55 PST 2010 Simon Marlow * Handle NaN, -Infinity and Infinity in the toRational for Float/Double (#3676) M ./GHC/Float.lhs -2 +9 M ./GHC/Real.lhs -1 +2 }}} and in ghc: {{{ Thu Feb 11 05:15:43 PST 2010 Simon Marlow * don't constant fold division that would result in negative zero (#3676) }}} It has some slightly odd consequences. Someone ought to take a broader look at this in the context of refining the Haskell standard. e.g. {{{ Prelude> toRational (-0 :: Double) == - toRational (0 :: Double) False }}} whereas previously this was True. The underlying problem is that the Rational type doesn't really include these strange values; it has been hacked in a few places so that certain unnormalised Rational values are used to represent strange floating point values, e.g. `0 :% 0` represents `NaN` and `fromRational` knows about it, but there's no official way to generate one of these (`0/0 :: Rational` gives an exception), they are only used "internally" by the libraries to make `read "NaN" :: Double` work. The change I made is to make `toRational (0/0 :: Double)` generate `0 :% 0`, and similarly for the other strange values, but these had odd consequences, because these special `Rational` values are not normalised. However, this does fix a real bug (the subject of this ticket). What do people think? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 11 09:40:07 2010 From: trac at galois.com (GHC) Date: Thu Feb 11 09:11:15 2010 Subject: [GHC] #3676: realToFrac doesn't sanely convert between floating types In-Reply-To: <046.c71a4f69a48e7e64e18a56e29c643e03@abbot.galois.com> References: <046.c71a4f69a48e7e64e18a56e29c643e03@abbot.galois.com> Message-ID: <055.b1deb1f8e24fc90b15e0c4b3f40323e3@abbot.galois.com> #3676: realToFrac doesn't sanely convert between floating types ----------------------------------+----------------------------------------- Reporter: draconx | Owner: simonmar Type: bug | Status: assigned Priority: normal | Milestone: 6.12.2 Component: libraries (other) | Version: 6.12.1 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: x86_64 (amd64) | Failure: None/Unknown ----------------------------------+----------------------------------------- Comment(by draconx): While it presumably goes against the report, I personally feel that floating point types do not belong as members of the Real class *at all*. The same is true for a number of other classes that they belong to. In the altfloat package, where I've been experimenting with solutions to this and other problems, I used a class {{{ class FloatConvert a b where toFloating :: a -> b }}} which provides the necessary conversions: both between floating point types, and from real types to floating point types. It should be noted that the functions `double2Float#` and `float2Double#` in GHC.Exts perform correct conversion. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 11 11:42:52 2010 From: trac at galois.com (GHC) Date: Thu Feb 11 11:14:11 2010 Subject: [GHC] #3676: realToFrac doesn't sanely convert between floating types In-Reply-To: <046.c71a4f69a48e7e64e18a56e29c643e03@abbot.galois.com> References: <046.c71a4f69a48e7e64e18a56e29c643e03@abbot.galois.com> Message-ID: <055.016804a4b1d407a999c1d4461ed22fee@abbot.galois.com> #3676: realToFrac doesn't sanely convert between floating types ----------------------------------+----------------------------------------- Reporter: draconx | Owner: simonmar Type: bug | Status: assigned Priority: normal | Milestone: 6.12.2 Component: libraries (other) | Version: 6.12.1 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: x86_64 (amd64) | Failure: None/Unknown ----------------------------------+----------------------------------------- Comment(by maeder): I suppose arithmetic on these non-normalised rationals does also not behave like on doubles (IEEE). I would expect toRational to fail on NaN and Infinity and to convert -0 to 0. But rather than introducing a multi-parameter type class I would just add non-overloaded plain conversion functions between Float, Double, CDouble, etc. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 11 13:22:50 2010 From: trac at galois.com (GHC) Date: Thu Feb 11 12:54:10 2010 Subject: [GHC] #3676: realToFrac doesn't sanely convert between floating types In-Reply-To: <046.c71a4f69a48e7e64e18a56e29c643e03@abbot.galois.com> References: <046.c71a4f69a48e7e64e18a56e29c643e03@abbot.galois.com> Message-ID: <055.a82026b2c097c231a99ffb158b1de8bf@abbot.galois.com> #3676: realToFrac doesn't sanely convert between floating types ----------------------------------+----------------------------------------- Reporter: draconx | Owner: simonmar Type: bug | Status: assigned Priority: normal | Milestone: 6.12.2 Component: libraries (other) | Version: 6.12.1 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: x86_64 (amd64) | Failure: None/Unknown ----------------------------------+----------------------------------------- Comment(by draconx): The problem with non-overloaded functions is that there are a lot of them: 12 with the four floating types that currently exist, and 30 if long double is ever added (two types: LDouble & CLDouble). This problem could be mitigated by only providing the trivial conversions when FFI types are involved: that is, provide Double <=> CDouble, but don't bother with Float <=> CDouble. On the other hand, we could use a single parameter version of altfloat's technique as follows: {{{ class FloatConvert a where toDouble :: a -> Double }}} since Double can represent all values of every other floating type (at least until long double exists). Then we could have a `fromDouble` member in the RealFloat class, and define `toFloating = fromDouble . toDouble` -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 11 20:23:15 2010 From: trac at galois.com (GHC) Date: Thu Feb 11 19:54:22 2010 Subject: [GHC] #3862: ghc crash while building hledger with cabal In-Reply-To: <047.37b3f072a5f2a5fc14090219a1e5d9bd@abbot.galois.com> References: <047.37b3f072a5f2a5fc14090219a1e5d9bd@abbot.galois.com> Message-ID: <056.ccd0b7c5018eef5ebaa74bd894c18509@abbot.galois.com> #3862: ghc crash while building hledger with cabal ---------------------------------+------------------------------------------ Reporter: simonmic | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Keywords: | Difficulty: Os: MacOS X | Testcase: Architecture: Unknown/Multiple | Failure: Compile-time crash ---------------------------------+------------------------------------------ Comment(by simonmic): Thank you, unfortunately things my app depends on don't yet work in the 6.12 world and I want to do one more 6.10-based release. This started recently so I'll look a bit harder for a workaround. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 11 20:24:39 2010 From: trac at galois.com (GHC) Date: Thu Feb 11 19:55:49 2010 Subject: [GHC] #3877: XOverlappingInstances flag not working Message-ID: <049.206d67806f9e5ec684138c11197151cd@abbot.galois.com> #3877: XOverlappingInstances flag not working -------------------------------+-------------------------------------------- Reporter: traz161616 | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 6.12.1 | Keywords: XOverlappingInstances Os: Linux | Testcase: Architecture: x86_64 (amd64) | Failure: GHC rejects valid program -------------------------------+-------------------------------------------- I tried compiling the attached snippet with both ghc 6.12.1 and 6.10.4. The result is that even with XOverlappingInstances flag it still does not allow the program although it is provided with a concrete instance. The code snippet is: {- File overlap.hs -} {-# OPTIONS_GHC -XOverlappingInstances -XTypeSynonymInstances #-} type PairIS = (Int,String) instance Show PairIS where show (a,b) = "(("++(show a)++","++(show b)++"))" test :: Int -> String -> String test a b = show (a,b) The OS is :Linux 2.6.31-19-server #56-Ubuntu SMP x86_64 The gcc version is (irrelevant): gcc version 4.4.1 The error message is: Glasgow Haskell Compiler, Version 6.12.1, for Haskell 98, stage 2 booted by GHC version 6.8.2 Using binary package database: /usr/local/lib/ghc-6.12.1/package.conf.d/package.cache wired-in package ghc-prim mapped to ghc- prim-0.2.0.0-9d35c97e886f807a1e6d024aaa91dcec wired-in package integer-gmp mapped to integer- gmp-0.2.0.0-9a51ffb34a83618a1a3d4e472b9977a0 wired-in package base mapped to base-4.2.0.0-b340bbd470b5859bcbb920aea62a12cf wired-in package rts mapped to builtin_rts wired-in package haskell98 mapped to haskell98-1.0.1.1-0fdaf3b26bc38c43ce8371edf538dbf6 wired-in package template-haskell mapped to template- haskell-2.4.0.0-fc13d9708caa0cfdc4173ee31dc2bf26 wired-in package dph-seq mapped to dph- seq-0.4.0-b8a71915f9569cbd3a6895da8311707a wired-in package dph-par mapped to dph- par-0.4.0-68df56bb8ae18f20e3518a7b338d7ebc Hsc static flags: -static D:\code\overlap.hs:8:11: Overlapping instances for Show (Int, String) arising from a use of `show' at D:\code\overlap.hs:8:11-20 Matching instances: instance (Show a, Show b) => Show (a, b) -- Defined in GHC.Show instance [overlap ok] Show PairIS -- Defined at D:\code\overlap.hs:4:9-19 In the expression: show (a, b) In the definition of `test': test a b = show (a, b) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 11 20:27:26 2010 From: trac at galois.com (GHC) Date: Thu Feb 11 19:58:30 2010 Subject: [GHC] #3862: ghc panic (applyTypeToArgs) building hledger with -O (was: ghc crash while building hledger with cabal) In-Reply-To: <047.37b3f072a5f2a5fc14090219a1e5d9bd@abbot.galois.com> References: <047.37b3f072a5f2a5fc14090219a1e5d9bd@abbot.galois.com> Message-ID: <056.f462fbd9e32310fb1f007f3fb6badcc8@abbot.galois.com> #3862: ghc panic (applyTypeToArgs) building hledger with -O ---------------------------------+------------------------------------------ Reporter: simonmic | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Keywords: | Difficulty: Os: MacOS X | Testcase: Architecture: Unknown/Multiple | Failure: Compile-time crash ---------------------------------+------------------------------------------ -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 11 20:36:56 2010 From: trac at galois.com (GHC) Date: Thu Feb 11 20:08:00 2010 Subject: [GHC] #3862: ghc panic (applyTypeToArgs) building hledger with -O In-Reply-To: <047.37b3f072a5f2a5fc14090219a1e5d9bd@abbot.galois.com> References: <047.37b3f072a5f2a5fc14090219a1e5d9bd@abbot.galois.com> Message-ID: <056.4c40b268f80fcc6a5ddc1ce1688c15a6@abbot.galois.com> #3862: ghc panic (applyTypeToArgs) building hledger with -O ---------------------------------+------------------------------------------ Reporter: simonmic | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Keywords: | Difficulty: Os: MacOS X | Testcase: Architecture: Unknown/Multiple | Failure: Compile-time crash ---------------------------------+------------------------------------------ Comment(by simonmic): Workaround found. I had: $ ghc-pkg list parsec /opt/local/lib/ghc-6.10.4/./package.conf: parsec-2.1.0.1 /Users/simon/.ghc/i386-darwin-6.10.4/package.conf: parsec-2.1.0.1 The issue happens when I have cabal installed parsec in the --user space. Unregistering that one and relying on the parsec that came with the ghc binary installer made the problem go away. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 12 06:10:52 2010 From: trac at galois.com (GHC) Date: Fri Feb 12 05:41:57 2010 Subject: [GHC] #3878: doesFileExist doesn't work for some /dev files in ghc 6.12 Message-ID: <051.66116fcdcc5dbc814d38dc907d308ada@abbot.galois.com> #3878: doesFileExist doesn't work for some /dev files in ghc 6.12 -------------------------------+-------------------------------------------- Reporter: marcotmarcot | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.12.1 | Keywords: Os: Linux | Testcase: Architecture: x86_64 (amd64) | Failure: Incorrect result at runtime -------------------------------+-------------------------------------------- Hi. I've noticed this with a program that checks for a lvm image. Here's the situation: Prelude System.Directory> doesFileExist "/dev/null" True Prelude System.Directory> doesFileExist "/dev/stdin" True Prelude System.Directory> doesFileExist "/dev/sda0" False Prelude System.Directory> doesFileExist "/dev/zezinho/sid" False All of these files exist in my system: marcot@zezinho:/dev$ ls -l null sda1 stdin zezinho/sid /proc/self/fd/0 mapper/zezinho-sid /dev/pts/5 crw--w---- 1 marcot tty 136, 5 Fev 12 09:09 /dev/pts/5 brw-rw---- 1 root disk 254, 4 Fev 12 08:55 mapper/zezinho-sid crw-rw-rw- 1 root root 1, 3 Fev 12 08:33 null lrwx------ 1 marcot marcot 64 Fev 12 09:09 /proc/self/fd/0 -> /dev/pts/5 brw-rw---- 1 root disk 8, 1 Fev 12 08:55 sda1 lrwxrwxrwx 1 root root 15 Fev 12 08:33 stdin -> /proc/self/fd/0 lrwxrwxrwx 1 root root 21 Fev 12 08:55 zezinho/sid -> ../mapper /zezinho-sid -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 12 06:57:41 2010 From: trac at galois.com (GHC) Date: Fri Feb 12 06:28:44 2010 Subject: [GHC] #3862: ghc panic (applyTypeToArgs) building hledger with -O In-Reply-To: <047.37b3f072a5f2a5fc14090219a1e5d9bd@abbot.galois.com> References: <047.37b3f072a5f2a5fc14090219a1e5d9bd@abbot.galois.com> Message-ID: <056.28b953a66f387d321ca8c9333db3eb64@abbot.galois.com> #3862: ghc panic (applyTypeToArgs) building hledger with -O ---------------------------------+------------------------------------------ Reporter: simonmic | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: fixed | Keywords: Difficulty: | Os: MacOS X Testcase: | Architecture: Unknown/Multiple Failure: Compile-time crash | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Ah, so you probably had an inconsistency in your package dependencies. GHC 6.12 would have detected and reported it, probably. Optimistically closing, in anticipation that 6.12 would give a better error message. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 12 09:51:50 2010 From: trac at galois.com (GHC) Date: Fri Feb 12 09:23:03 2010 Subject: [GHC] #3877: XOverlappingInstances flag not working In-Reply-To: <049.206d67806f9e5ec684138c11197151cd@abbot.galois.com> References: <049.206d67806f9e5ec684138c11197151cd@abbot.galois.com> Message-ID: <058.9c42c6688c24472d36e672044aa8c0c1@abbot.galois.com> #3877: XOverlappingInstances flag not working ----------------------------------------+----------------------------------- Reporter: traz161616 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.12.1 Keywords: XOverlappingInstances | Difficulty: Os: Linux | Testcase: Architecture: x86_64 (amd64) | Failure: GHC rejects valid program ----------------------------------------+----------------------------------- Old description: > I tried compiling the attached snippet with both ghc 6.12.1 and 6.10.4. > The result is that even with XOverlappingInstances flag it still does not > allow the program although it is provided with a concrete instance. > > The code snippet is: > {- File overlap.hs -} > {-# OPTIONS_GHC -XOverlappingInstances -XTypeSynonymInstances #-} > > type PairIS = (Int,String) > instance Show PairIS where > show (a,b) = "(("++(show a)++","++(show b)++"))" > > test :: Int -> String -> String > test a b = show (a,b) > > The OS is :Linux 2.6.31-19-server #56-Ubuntu SMP x86_64 > The gcc version is (irrelevant): gcc version 4.4.1 > > The error message is: > > Glasgow Haskell Compiler, Version 6.12.1, for Haskell 98, stage 2 booted > by GHC version 6.8.2 > Using binary package database: > /usr/local/lib/ghc-6.12.1/package.conf.d/package.cache > wired-in package ghc-prim mapped to ghc- > prim-0.2.0.0-9d35c97e886f807a1e6d024aaa91dcec > wired-in package integer-gmp mapped to integer- > gmp-0.2.0.0-9a51ffb34a83618a1a3d4e472b9977a0 > wired-in package base mapped to > base-4.2.0.0-b340bbd470b5859bcbb920aea62a12cf > wired-in package rts mapped to builtin_rts > wired-in package haskell98 mapped to > haskell98-1.0.1.1-0fdaf3b26bc38c43ce8371edf538dbf6 > wired-in package template-haskell mapped to template- > haskell-2.4.0.0-fc13d9708caa0cfdc4173ee31dc2bf26 > wired-in package dph-seq mapped to dph- > seq-0.4.0-b8a71915f9569cbd3a6895da8311707a > wired-in package dph-par mapped to dph- > par-0.4.0-68df56bb8ae18f20e3518a7b338d7ebc > Hsc static flags: -static > > D:\code\overlap.hs:8:11: > Overlapping instances for Show (Int, String) > arising from a use of `show' at D:\code\overlap.hs:8:11-20 > Matching instances: > instance (Show a, Show b) => Show (a, b) -- Defined in GHC.Show > instance [overlap ok] Show PairIS > -- Defined at D:\code\overlap.hs:4:9-19 > In the expression: show (a, b) > In the definition of `test': test a b = show (a, b) New description: I tried compiling the attached snippet with both ghc 6.12.1 and 6.10.4. The result is that even with XOverlappingInstances flag it still does not allow the program although it is provided with a concrete instance. The code snippet is: {{{ {- File overlap.hs -} {-# OPTIONS_GHC -XOverlappingInstances -XTypeSynonymInstances #-} type PairIS = (Int,String) instance Show PairIS where show (a,b) = "(("++(show a)++","++(show b)++"))" test :: Int -> String -> String test a b = show (a,b) }}} The OS is :Linux 2.6.31-19-server #56-Ubuntu SMP x86_64 The gcc version is (irrelevant): gcc version 4.4.1 The error message is: {{{ Glasgow Haskell Compiler, Version 6.12.1, for Haskell 98, stage 2 booted by GHC version 6.8.2 Using binary package database: /usr/local/lib/ghc-6.12.1/package.conf.d/package.cache wired-in package ghc-prim mapped to ghc- prim-0.2.0.0-9d35c97e886f807a1e6d024aaa91dcec wired-in package integer-gmp mapped to integer- gmp-0.2.0.0-9a51ffb34a83618a1a3d4e472b9977a0 wired-in package base mapped to base-4.2.0.0-b340bbd470b5859bcbb920aea62a12cf wired-in package rts mapped to builtin_rts wired-in package haskell98 mapped to haskell98-1.0.1.1-0fdaf3b26bc38c43ce8371edf538dbf6 wired-in package template-haskell mapped to template- haskell-2.4.0.0-fc13d9708caa0cfdc4173ee31dc2bf26 wired-in package dph-seq mapped to dph- seq-0.4.0-b8a71915f9569cbd3a6895da8311707a wired-in package dph-par mapped to dph- par-0.4.0-68df56bb8ae18f20e3518a7b338d7ebc Hsc static flags: -static D:\code\overlap.hs:8:11: Overlapping instances for Show (Int, String) arising from a use of `show' at D:\code\overlap.hs:8:11-20 Matching instances: instance (Show a, Show b) => Show (a, b) -- Defined in GHC.Show instance [overlap ok] Show PairIS -- Defined at D:\code\overlap.hs:4:9-19 In the expression: show (a, b) In the definition of `test': test a b = show (a, b) }}} -- Comment(by simonpj): Currently this is by design; see http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class- extensions.html#instance-overlap. Note esp the remarks at the end, which point out that the current design is not the only possible one. So there's no great implementation challenge here; it's a design question. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 12 10:00:48 2010 From: trac at galois.com (GHC) Date: Fri Feb 12 09:31:55 2010 Subject: [GHC] #3851: type family does not get expanded in ghc-6.12.1 In-Reply-To: <047.9b73a510640cabe71061dde181079f57@abbot.galois.com> References: <047.9b73a510640cabe71061dde181079f57@abbot.galois.com> Message-ID: <056.3230e2fdfc486999fe14507c30bf7c28@abbot.galois.com> #3851: type family does not get expanded in ghc-6.12.1 ----------------------------------------+----------------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.12.1 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: GHC rejects valid program ----------------------------------------+----------------------------------- Comment(by simonpj): Realistically 3 months. I didn't know that multirec relied crucially on ''both'' type functions ''and'' GADTs in combination. I'm pretty reluctant to invest the time it'd take to figure out why 6.12 isn't behaving the same way as 6.10 given that it's code that will be nuked shortly. Maybe multirec users can stick to 6.10 for now. That's not a very good answer I know. But you are on the bleeding edge here. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 12 15:59:07 2010 From: trac at galois.com (GHC) Date: Fri Feb 12 15:30:08 2010 Subject: [GHC] #3879: Enable shared libraries on Windows Message-ID: <044.9c60c8933d3ae7c91357b118536a70e9@abbot.galois.com> #3879: Enable shared libraries on Windows ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: feature request | Status: new Priority: high | Milestone: 6.14.1 Component: Compiler | Version: 6.12.1 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ http://www.haskell.org/pipermail/cvs-ghc/2010-January/052220.html {{{ Windows DLLs should be working now. To turn on the "dyn" way add the string "i386-unknown-mingw32" to PlatformSupportsSharedLibs in mk/config.mk }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 12 15:59:24 2010 From: trac at galois.com (GHC) Date: Fri Feb 12 15:30:26 2010 Subject: [GHC] #3879: Enable shared libraries on Windows In-Reply-To: <044.9c60c8933d3ae7c91357b118536a70e9@abbot.galois.com> References: <044.9c60c8933d3ae7c91357b118536a70e9@abbot.galois.com> Message-ID: <053.4c5552fc6ce3eb3fb13d8443740ab004@abbot.galois.com> #3879: Enable shared libraries on Windows ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: feature request | Status: new Priority: high | Milestone: 6.14.1 Component: Compiler | Version: 6.12.1 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Description changed by igloo: Old description: > http://www.haskell.org/pipermail/cvs-ghc/2010-January/052220.html > > {{{ > Windows DLLs should be working now. To turn on the "dyn" way add the > string "i386-unknown-mingw32" to PlatformSupportsSharedLibs in > mk/config.mk > }}} New description: http://www.haskell.org/pipermail/cvs-ghc/2010-January/052220.html {{{ Windows DLLs should be working now. To turn on the "dyn" way add the string "i386-unknown-mingw32" to PlatformSupportsSharedLibs in mk/config.mk }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 12 16:38:58 2010 From: trac at galois.com (GHC) Date: Fri Feb 12 16:10:21 2010 Subject: [GHC] #1969: enormous compile times In-Reply-To: <045.1ab99ac1a52ae6b35a7131dc801608a9@abbot.galois.com> References: <045.1ab99ac1a52ae6b35a7131dc801608a9@abbot.galois.com> Message-ID: <054.dad03dc9b2152c4890675fe9a4e34bf3@abbot.galois.com> #1969: enormous compile times -------------------------------------------+-------------------------------- Reporter: duncan | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.1 Resolution: fixed | Keywords: performance Difficulty: Difficult (2-5 days) | Os: Unknown/Multiple Testcase: T1969 | Architecture: Unknown/Multiple Failure: Compile-time performance bug | -------------------------------------------+-------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: We think the main performance issue is fixed now. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 12 17:44:15 2010 From: trac at galois.com (GHC) Date: Fri Feb 12 17:15:16 2010 Subject: [GHC] #3880: remove LazyUniqFM Message-ID: <044.6f40659eb88b7fbb52a7726ef5522c7f@abbot.galois.com> #3880: remove LazyUniqFM ---------------------------------+------------------------------------------ Reporter: igloo | Owner: igloo Type: task | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler | Version: 6.12.1 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ remove LazyUniqFM: http://www.haskell.org/pipermail/cvs- ghc/2009-November/050939.html -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 13 11:25:43 2010 From: trac at galois.com (GHC) Date: Sat Feb 13 10:56:51 2010 Subject: [GHC] #3840: ghc-6.12.1 takes longer to compile code and produces bigger binaries compared to ghc-6.10.4 In-Reply-To: <045.ee0c11e517a19af640fa74e960df89c8@abbot.galois.com> References: <045.ee0c11e517a19af640fa74e960df89c8@abbot.galois.com> Message-ID: <054.8e6e0d25f65e5cf391e9193b6cf93a6a@abbot.galois.com> #3840: ghc-6.12.1 takes longer to compile code and produces bigger binaries compared to ghc-6.10.4 -------------------------+-------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.12.1 Keywords: | Difficulty: Os: Linux | Testcase: Architecture: x86 | Failure: None/Unknown -------------------------+-------------------------------------------------- Comment(by maeder): I've tried with ghc-6.13.20100211 and the results are much better though not as good as for ghc-6.10.4 {{{ 1,3M dist/build/hets/hets-tmp/HasCASL/ATC_HasCASL.o 872K dist/build/hets/hets-tmp/CASL/ATC_CASL.o 600K dist/build/hets/hets-tmp/SoftFOL/ATC_SoftFOL.o 592K dist/build/hets/hets-tmp/ATC/Sml_cats.o 560K dist/build/hets/hets-tmp/Maude/ATC_Maude.o 552K dist/build/hets/hets-tmp/OWL/AS.o 548K dist/build/hets/hets-tmp/SoftFOL/Sign.o 544K dist/build/hets/hets-tmp/Maude/AS_Maude.o 540K dist/build/hets/hets-tmp/Static/DevGraph.o 500K dist/build/hets/hets-tmp/HasCASL/As.o 468K dist/build/hets/hets-tmp/ATC/DevGraph.o }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 14 02:45:57 2010 From: trac at galois.com (GHC) Date: Sun Feb 14 02:17:00 2010 Subject: [GHC] #1349: Generalise the ! and UNPACK mechanism for data types, to unpack function arguments In-Reply-To: <046.9dd17815048ce25749ab5bff260d2925@abbot.galois.com> References: <046.9dd17815048ce25749ab5bff260d2925@abbot.galois.com> Message-ID: <055.dcb1e17852b1b84ff55f3ee196705131@abbot.galois.com> #1349: Generalise the ! and UNPACK mechanism for data types, to unpack function arguments ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: task | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.6.1 Keywords: | Difficulty: Unknown Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Changes (by bos): * cc: bos@? (added) * failure: => None/Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 14 02:50:55 2010 From: trac at galois.com (GHC) Date: Sun Feb 14 02:21:55 2010 Subject: [GHC] #1349: Generalise the ! and UNPACK mechanism for data types, to unpack function arguments In-Reply-To: <046.9dd17815048ce25749ab5bff260d2925@abbot.galois.com> References: <046.9dd17815048ce25749ab5bff260d2925@abbot.galois.com> Message-ID: <055.a4f569cc1c6e161f502c36cb485eed58@abbot.galois.com> #1349: Generalise the ! and UNPACK mechanism for data types, to unpack function arguments ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: task | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.6.1 Keywords: | Difficulty: Unknown Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Changes (by tibbe): * cc: johan.tibell@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 14 10:53:08 2010 From: trac at galois.com (GHC) Date: Sun Feb 14 10:24:07 2010 Subject: [GHC] #3837: hsc2hs and utf-8 In-Reply-To: <052.70cf87bf85ce9569a1df195436a13aa0@abbot.galois.com> References: <052.70cf87bf85ce9569a1df195436a13aa0@abbot.galois.com> Message-ID: <061.46e3cb2ddc4e4a35539eb4e82624548e@abbot.galois.com> #3837: hsc2hs and utf-8 ---------------------------------+------------------------------------------ Reporter: TaruKarttunen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: hsc2hs | Version: 6.12.1 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Description changed by igloo: Old description: > hsc2hs is broken on a source file containing certain utf-8 characters in > the comments. > > Attached is an example module. > > The probable culprit is: > showCChar c = ['\\', > intToDigit (ord c `quot` 64), > intToDigit (ord c `quot` 8 `mod` 8), > intToDigit (ord c `mod` 8)] > in hsc2hs code. New description: hsc2hs is broken on a source file containing certain utf-8 characters in the comments. Attached is an example module. The probable culprit is: {{{ showCChar c = ['\\', intToDigit (ord c `quot` 64), intToDigit (ord c `quot` 8 `mod` 8), intToDigit (ord c `mod` 8)] }}} in hsc2hs code. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 14 12:04:18 2010 From: trac at galois.com (GHC) Date: Sun Feb 14 11:35:15 2010 Subject: [GHC] #3881: section parse errors, e.g. ( let x=1 in x + ) Message-ID: <044.57191cd3116ea39f27ede6dafb550260@abbot.galois.com> #3881: section parse errors, e.g. ( let x=1 in x + ) ----------------------------------+----------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.16.1 Component: Compiler (Parser) | Version: 6.12.1 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ----------------------------------+----------------------------------------- These parse errors were brought up on the Haskell' list: http://www.haskell.org/pipermail/haskell-prime/2010-February/003093.html {{{ Prelude> :t ( let x=1 in x + ) :1:18: parse error on input `)' }}} {{{ Prelude> :t ( if True then 1 else 2 + ) :1:27: parse error on input `)' }}} Milestoned for 6.16.1, as it sounds like the language definition may get changed in H'. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 14 12:19:19 2010 From: trac at galois.com (GHC) Date: Sun Feb 14 11:50:25 2010 Subject: [GHC] #2458: Unknown symbol `_environ' on MacOS X In-Reply-To: <048.8d22aecac33c2afb7c79a5628eb01872@abbot.galois.com> References: <048.8d22aecac33c2afb7c79a5628eb01872@abbot.galois.com> Message-ID: <057.6588f32170d0561c648b57382b304125@abbot.galois.com> #2458: Unknown symbol `_environ' on MacOS X -----------------------------+---------------------------------------------- Reporter: IgorBoehm | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: libraries/base | Version: 6.10.1 Resolution: | Keywords: environ Difficulty: Unknown | Os: MacOS X Testcase: | Architecture: x86 Failure: None/Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * owner: igloo => * status: reopened => new * milestone: 6.10.1 => 6.12.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 14 12:22:46 2010 From: trac at galois.com (GHC) Date: Sun Feb 14 11:53:42 2010 Subject: [GHC] #3647: unify handling and error messages for -X vs. {-#LANGUAGE ...#-} pragmas/extensions In-Reply-To: <047.73fc8cca3ba98859dc9d57483a25d637@abbot.galois.com> References: <047.73fc8cca3ba98859dc9d57483a25d637@abbot.galois.com> Message-ID: <056.97d031282589543a900b5152874d80c5@abbot.galois.com> #3647: unify handling and error messages for -X vs. {-#LANGUAGE ...#-} pragmas/extensions --------------------------------+------------------------------------------- Reporter: eflister | Owner: Type: feature request | Status: reopened Priority: normal | Milestone: 6.14 branch Component: Compiler (Parser) | Version: 6.10.4 Resolution: | Keywords: language pragma extensions error message warning Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | --------------------------------+------------------------------------------- Changes (by igloo): * milestone: => 6.14 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 14 12:30:53 2010 From: trac at galois.com (GHC) Date: Sun Feb 14 12:01:55 2010 Subject: [GHC] #3695: GHC-6.12.1-RC2-20091121 build fails when using stage-1 compiler In-Reply-To: <048.637bc11df320fbea10c8c8161b9f7491@abbot.galois.com> References: <048.637bc11df320fbea10c8c8161b9f7491@abbot.galois.com> Message-ID: <057.9e113f68d6f0ce417f0efa5caf10a6fd@abbot.galois.com> #3695: GHC-6.12.1-RC2-20091121 build fails when using stage-1 compiler ----------------------------------+----------------------------------------- Reporter: jberthold | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.12.1 RC1 Resolution: fixed | Keywords: Difficulty: | Os: Solaris Testcase: | Architecture: sparc Failure: Building GHC failed | ----------------------------------+----------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: The {{{ /bin/sh: syntax error at line 1: `;' }}} problem was fixed by {{{ Tue Dec 1 12:59:27 GMT 2009 Ian Lynagh * Avoid running empty for loops; fixes trac #3683 Solaris's sh gives /bin/sh: syntax error at line 1: `;' unexpected when faced with something like for x in ; do ...; done Patch from Christian Maeder. }}} As other people have successfully compiled 6.12.1 on Sparc/Solaris, I am optimistically assuming the other problem is also fixed. If not, please reopen the ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 14 12:42:51 2010 From: trac at galois.com (GHC) Date: Sun Feb 14 12:13:48 2010 Subject: [GHC] #3739: ghc-cabal mishandles relative paths in arguments In-Reply-To: <048.33ad0d7b937dcb44ba82750481db301b@abbot.galois.com> References: <048.33ad0d7b937dcb44ba82750481db301b@abbot.galois.com> Message-ID: <057.c050561371f0b42d94f820a365d22da5@abbot.galois.com> #3739: ghc-cabal mishandles relative paths in arguments ---------------------------------+------------------------------------------ Reporter: asuffield | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14 branch Component: Build System | Version: Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Changes (by igloo): * milestone: => 6.14 branch Comment: Related to this, there has also been talk of allowing paths in `package.conf` files to be relative to the location of the `package.conf` file. This would be a step towards relocatable installations. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 14 12:55:39 2010 From: trac at galois.com (GHC) Date: Sun Feb 14 12:26:35 2010 Subject: [GHC] #3818: ghc-pkg prints warnings to stdout instead of stderr In-Reply-To: <046.3fb054c38af92e36aa356532b619a97e@abbot.galois.com> References: <046.3fb054c38af92e36aa356532b619a97e@abbot.galois.com> Message-ID: <055.93ba18cd490707a6d0480d30708efee3@abbot.galois.com> #3818: ghc-pkg prints warnings to stdout instead of stderr ---------------------------------+------------------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: Package system | Version: 6.12.1 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Changes (by igloo): * milestone: => 6.14.1 Comment: There is quite a mix of stderr/stdout. This really needs a policy to be decided, and a sweep over all the prints to be done. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 14 12:55:58 2010 From: trac at galois.com (GHC) Date: Sun Feb 14 12:26:59 2010 Subject: [GHC] #3822: guards in arrow notation (Arrows extension) case statement cause compiler panic In-Reply-To: <056.c7c33f6cdeb1bfb88ba85665acc1134b@abbot.galois.com> References: <056.c7c33f6cdeb1bfb88ba85665acc1134b@abbot.galois.com> Message-ID: <065.c41a496b0847569ad4daca4a8fbe721e@abbot.galois.com> #3822: guards in arrow notation (Arrows extension) case statement cause compiler panic -----------------------------------------+---------------------------------- Reporter: StephenBlackheath | Owner: ross Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.12.1 Keywords: arrows guards case panic | Difficulty: Os: Unknown/Multiple | Testcase: patternGuard.hs Architecture: Unknown/Multiple | Failure: Compile-time crash -----------------------------------------+---------------------------------- Description changed by igloo: Old description: > The attached test case causes this panic message: > > ----- > ghc: panic! (the 'impossible' happened) > (GHC version 6.12.1 for x86_64-unknown-linux): > initC: srt_lbl > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > ----- > > The offending line is the one with '| neg'. It doesn't panic if you use > the commented out line below it instead. > > This kind of case statement is specific to arrow notation (provided by > the Arrows extension) - the compiler uses ArrowChoice to implement it. New description: The attached test case causes this panic message: {{{ ghc: panic! (the 'impossible' happened) (GHC version 6.12.1 for x86_64-unknown-linux): initC: srt_lbl Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The offending line is the one with '| neg'. It doesn't panic if you use the commented out line below it instead. This kind of case statement is specific to arrow notation (provided by the Arrows extension) - the compiler uses ArrowChoice to implement it. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 14 13:45:33 2010 From: trac at galois.com (GHC) Date: Sun Feb 14 13:16:34 2010 Subject: [GHC] #3822: guards in arrow notation (Arrows extension) case statement cause compiler panic In-Reply-To: <056.c7c33f6cdeb1bfb88ba85665acc1134b@abbot.galois.com> References: <056.c7c33f6cdeb1bfb88ba85665acc1134b@abbot.galois.com> Message-ID: <065.5f15338d298922057f135f498694eee0@abbot.galois.com> #3822: guards in arrow notation (Arrows extension) case statement cause compiler panic -----------------------------------------+---------------------------------- Reporter: StephenBlackheath | Owner: ross Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: Compiler | Version: 6.12.1 Keywords: arrows guards case panic | Difficulty: Os: Unknown/Multiple | Testcase: patternGuard.hs Architecture: Unknown/Multiple | Failure: Compile-time crash -----------------------------------------+---------------------------------- Changes (by igloo): * milestone: => 6.12.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 14 13:55:50 2010 From: trac at galois.com (GHC) Date: Sun Feb 14 13:26:52 2010 Subject: [GHC] #3826: Can't infer type (type family as "element" type) In-Reply-To: <042.84e771ed5687c0b090cc1169d5855922@abbot.galois.com> References: <042.84e771ed5687c0b090cc1169d5855922@abbot.galois.com> Message-ID: <051.2855bf24366fb9fd8f7a07beaea481de@abbot.galois.com> #3826: Can't infer type (type family as "element" type) ----------------------------------------+----------------------------------- Reporter: spl | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler (Type checker) | Version: 6.12.1 Keywords: type families | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: GHC rejects valid program ----------------------------------------+----------------------------------- Changes (by igloo): * owner: => simonpj * milestone: => 6.14.1 Comment: This sounds like a question for you, Simon. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 14 13:56:08 2010 From: trac at galois.com (GHC) Date: Sun Feb 14 13:27:03 2010 Subject: [GHC] #3827: Compiling fails on linux-powerpc In-Reply-To: <050.513cd5a1d672cd1796d29f3e29565e48@abbot.galois.com> References: <050.513cd5a1d672cd1796d29f3e29565e48@abbot.galois.com> Message-ID: <059.2b0dbd7b2ba0aa11b6f1e0dec6781772@abbot.galois.com> #3827: Compiling fails on linux-powerpc ----------------------------+----------------------------------------------- Reporter: speleologic | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.12.1 Keywords: | Difficulty: Os: Linux | Testcase: Architecture: powerpc | Failure: Building GHC failed ----------------------------+----------------------------------------------- Description changed by igloo: Old description: > I get the following error after doing ./configure && make > > ghc-stage1: panic! (the 'impossible' happened) > (GHC version 6.12.1 for powerpc-unknown-linux): > Error in array index > > The command where the failure happens is: > > "inplace/bin/ghc-stage1" -H32m -O -package-name ghc-prim-0.2.0.0 > -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist- > install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries > /ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist- > install/build/autogen -Ilibraries/ghc-prim/. -optP-include > -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h > -package rts-1.0 -split-objs -package-name ghc-prim -XCPP -XMagicHash > -XForeignFunctionInterface -XUnliftedFFITypes -XUnboxedTuples > -XEmptyDataDecls -XNoImplicitPrelude -O2 -XGenerics -fno-warn-deprecated- > flags -odir libraries/ghc-prim/dist-install/build -hidir libraries > /ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist- > install/build -hisuf hi -osuf o -hcsuf hc -c libraries/ghc- > prim/./GHC/Types.hs -o libraries/ghc-prim/dist-install/build/GHC/Types.o New description: I get the following error after doing ./configure && make {{{ ghc-stage1: panic! (the 'impossible' happened) (GHC version 6.12.1 for powerpc-unknown-linux): Error in array index }}} The command where the failure happens is: {{{ "inplace/bin/ghc-stage1" -H32m -O -package-name ghc-prim-0.2.0.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist- install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries /ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist- install/build/autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package rts-1.0 -split-objs -package-name ghc-prim -XCPP -XMagicHash -XForeignFunctionInterface -XUnliftedFFITypes -XUnboxedTuples -XEmptyDataDecls -XNoImplicitPrelude -O2 -XGenerics -fno-warn-deprecated- flags -odir libraries/ghc-prim/dist-install/build -hidir libraries /ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist- install/build -hisuf hi -osuf o -hcsuf hc -c libraries/ghc- prim/./GHC/Types.hs -o libraries/ghc-prim/dist-install/build/GHC/Types.o }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 14 14:00:36 2010 From: trac at galois.com (GHC) Date: Sun Feb 14 13:31:32 2010 Subject: [GHC] #3827: Compiling fails on linux-powerpc In-Reply-To: <050.513cd5a1d672cd1796d29f3e29565e48@abbot.galois.com> References: <050.513cd5a1d672cd1796d29f3e29565e48@abbot.galois.com> Message-ID: <059.46eb124dbc894695be1eaecbf652010f@abbot.galois.com> #3827: Compiling fails on linux-powerpc ----------------------------+----------------------------------------------- Reporter: speleologic | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.12.1 Keywords: | Difficulty: Os: Linux | Testcase: Architecture: powerpc | Failure: Building GHC failed ----------------------------+----------------------------------------------- Changes (by igloo): * milestone: => _|_ Comment: It sounds like you're trying to do a registerised build, and the PPC/Linux platform has bitrotted. We are unlikely to look into this as PPC/Linux is a [wiki:Platforms tier 2 platform], but if someone else wants to look into it feel free to talk to the cvs-ghc list if you get stuck. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 14 14:01:07 2010 From: trac at galois.com (GHC) Date: Sun Feb 14 13:32:03 2010 Subject: [GHC] #3828: Error in array index In-Reply-To: <042.183a30ca9d84f0b1998a7b985bfd6d87@abbot.galois.com> References: <042.183a30ca9d84f0b1998a7b985bfd6d87@abbot.galois.com> Message-ID: <051.c60a7e536673c30f5767f0f908de101b@abbot.galois.com> #3828: Error in array index -------------------------+-------------------------------------------------- Reporter: CBa | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.12.1 Keywords: sunos | Difficulty: Os: Solaris | Testcase: Architecture: sparc | Failure: Compile-time crash -------------------------+-------------------------------------------------- Description changed by igloo: Old description: > I simply compile ghc-6.12.1 on solaris with ghc 6.8.3. > > when compiling libraries/ghc-prim/./GHC/Types.hs: > > ghc-stage1: panic! (the 'impossible' happened) > (GHC version 6.12.1 for sparc-sun-solaris2): > Error in array index New description: I simply compile ghc-6.12.1 on solaris with ghc 6.8.3. when compiling `libraries/ghc-prim/./GHC/Types.hs`: {{{ ghc-stage1: panic! (the 'impossible' happened) (GHC version 6.12.1 for sparc-sun-solaris2): Error in array index }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 14 14:02:20 2010 From: trac at galois.com (GHC) Date: Sun Feb 14 13:33:19 2010 Subject: [GHC] #3695: GHC-6.12.1-RC2-20091121 build fails when using stage-1 compiler In-Reply-To: <048.637bc11df320fbea10c8c8161b9f7491@abbot.galois.com> References: <048.637bc11df320fbea10c8c8161b9f7491@abbot.galois.com> Message-ID: <057.96ce72f9578181f83eabdc23ac6817d1@abbot.galois.com> #3695: GHC-6.12.1-RC2-20091121 build fails when using stage-1 compiler ----------------------------------+----------------------------------------- Reporter: jberthold | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.12.1 RC1 Resolution: fixed | Keywords: Difficulty: | Os: Solaris Testcase: | Architecture: sparc Failure: Building GHC failed | ----------------------------------+----------------------------------------- Comment(by igloo): Actually, #3828 seems to be reporting the same issue in 6.12.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 14 14:02:53 2010 From: trac at galois.com (GHC) Date: Sun Feb 14 13:33:50 2010 Subject: [GHC] #3827: Compiling fails on linux-powerpc In-Reply-To: <050.513cd5a1d672cd1796d29f3e29565e48@abbot.galois.com> References: <050.513cd5a1d672cd1796d29f3e29565e48@abbot.galois.com> Message-ID: <059.ba0ef708f383cd34f672062135817635@abbot.galois.com> #3827: Compiling fails on linux-powerpc ----------------------------+----------------------------------------------- Reporter: speleologic | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.12.1 Keywords: | Difficulty: Os: Linux | Testcase: Architecture: powerpc | Failure: Building GHC failed ----------------------------+----------------------------------------------- Comment(by igloo): See also #3828 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 14 14:05:48 2010 From: trac at galois.com (GHC) Date: Sun Feb 14 13:36:45 2010 Subject: [GHC] #3828: Error in array index In-Reply-To: <042.183a30ca9d84f0b1998a7b985bfd6d87@abbot.galois.com> References: <042.183a30ca9d84f0b1998a7b985bfd6d87@abbot.galois.com> Message-ID: <051.2ff1e3bb444b8b9575b7ab130ba1dd6b@abbot.galois.com> #3828: Error in array index -------------------------+-------------------------------------------------- Reporter: CBa | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.12.1 Keywords: sunos | Difficulty: Os: Solaris | Testcase: Architecture: sparc | Failure: Compile-time crash -------------------------+-------------------------------------------------- Changes (by igloo): * milestone: => _|_ Comment: See also #3695. It's a little suspicious that the same failure happens on 2 platforms, but as they are both [wiki:Platforms tier 2] we really need someone else, with better access to one of the platforms, to look into the problem. Incidentally, it's probably easier to run the testsuite with stage1 and see if there is a small failing test, rather than trying to debug GHC itself. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 14 14:11:32 2010 From: trac at galois.com (GHC) Date: Sun Feb 14 13:42:33 2010 Subject: [GHC] #3837: hsc2hs and utf-8 In-Reply-To: <052.70cf87bf85ce9569a1df195436a13aa0@abbot.galois.com> References: <052.70cf87bf85ce9569a1df195436a13aa0@abbot.galois.com> Message-ID: <061.838c2a1dc3c08c65bd20ba6604a3d4fc@abbot.galois.com> #3837: hsc2hs and utf-8 ---------------------------------+------------------------------------------ Reporter: TaruKarttunen | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: hsc2hs | Version: 6.12.1 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Changes (by igloo): * milestone: => 6.12.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 14 14:12:24 2010 From: trac at galois.com (GHC) Date: Sun Feb 14 13:43:29 2010 Subject: [GHC] #3840: ghc-6.12.1 takes longer to compile code and produces bigger binaries compared to ghc-6.10.4 In-Reply-To: <045.ee0c11e517a19af640fa74e960df89c8@abbot.galois.com> References: <045.ee0c11e517a19af640fa74e960df89c8@abbot.galois.com> Message-ID: <054.baebf81f5643b938908b8f4fa36e527d@abbot.galois.com> #3840: ghc-6.12.1 takes longer to compile code and produces bigger binaries compared to ghc-6.10.4 -------------------------+-------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: Compiler | Version: 6.12.1 Keywords: | Difficulty: Os: Linux | Testcase: Architecture: x86 | Failure: None/Unknown -------------------------+-------------------------------------------------- Changes (by igloo): * milestone: => 6.12.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 14 14:13:39 2010 From: trac at galois.com (GHC) Date: Sun Feb 14 13:44:50 2010 Subject: [GHC] #3850: EmptyDataDecls and type context In-Reply-To: <049.f27f0f58200e17d4e5b9ff32a4c6b128@abbot.galois.com> References: <049.f27f0f58200e17d4e5b9ff32a4c6b128@abbot.galois.com> Message-ID: <058.5d05166de8b160e262e28e42f286f453@abbot.galois.com> #3850: EmptyDataDecls and type context ----------------------------------------+----------------------------------- Reporter: Paczesiowa | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.12.1 Resolution: fixed | Keywords: emptydatadecls Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: GHC rejects valid program | ----------------------------------------+----------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 14 14:21:23 2010 From: trac at galois.com (GHC) Date: Sun Feb 14 13:52:20 2010 Subject: [GHC] #3836: ghc6 6.12.1 fails to build from source in S390 In-Reply-To: <044.fa2981fa8c9b1277f742d78343cf4e59@abbot.galois.com> References: <044.fa2981fa8c9b1277f742d78343cf4e59@abbot.galois.com> Message-ID: <053.4ef207706a59eba3bddc2a61c01529cc@abbot.galois.com> #3836: ghc6 6.12.1 fails to build from source in S390 ------------------------------+--------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: Documentation | Version: 6.12.1 Keywords: | Difficulty: Os: Linux | Testcase: Architecture: Other | Failure: Building GHC failed ------------------------------+--------------------------------------------- Changes (by igloo): * milestone: => 6.12.2 Comment: I've attached the workaround kaol sent me that Debian is using currently. We should fix this properly, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 14 14:40:33 2010 From: trac at galois.com (GHC) Date: Sun Feb 14 14:11:35 2010 Subject: [GHC] #3867: ghc: panic! (linkBCO: >= 64k ptrs) In-Reply-To: <048.056cb4f380ed3fd1c06f05836f332dd5@abbot.galois.com> References: <048.056cb4f380ed3fd1c06f05836f332dd5@abbot.galois.com> Message-ID: <057.4537f985fdffdc3979e2ed1c9836b678@abbot.galois.com> #3867: ghc: panic! (linkBCO: >= 64k ptrs) ---------------------------------+------------------------------------------ Reporter: archgrove | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: Compiler | Version: 6.12.1 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: GHC rejects valid program ---------------------------------+------------------------------------------ Changes (by igloo): * milestone: => 6.12.2 Comment: This creates a suitable `Dict.hs`: {{{ main :: IO () main = writeFile "Dict.hs" ("module Dict where\ndict = " ++ show strs) strs :: [String] strs = take 100000 xs xs :: [String] xs = "" : [ c : cs | cs <- xs, c <- ['a'..'z']] }}} and 1.2G of RAM later: {{{ GHCi, version 6.13.20100211: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package ffi-1.0 ... linking ... done. [1 of 1] Compiling Dict ( Dict.hs, interpreted ) Ok, modules loaded: Dict. *Dict> take 1 dict ghc-stage2: panic! (the 'impossible' happened) (GHC version 6.13.20100211 for x86_64-unknown-linux): linkBCO: >= 64k ptrs Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *Dict> Leaving GHCi. ghci Dict.hs 54.32s user 0.82s system 83% cpu 1:05.89 total }}} This ought to be quite straightforward to fix, as I think all the hard work was already done when fixing the >= 64k insns problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 14 15:10:30 2010 From: trac at galois.com (GHC) Date: Sun Feb 14 14:41:35 2010 Subject: [GHC] #3851: type family does not get expanded in ghc-6.12.1 In-Reply-To: <047.9b73a510640cabe71061dde181079f57@abbot.galois.com> References: <047.9b73a510640cabe71061dde181079f57@abbot.galois.com> Message-ID: <056.e885bbdb19a1d828e41bc2fc395c7b7e@abbot.galois.com> #3851: type family does not get expanded in ghc-6.12.1 ----------------------------------------+----------------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler (Type checker) | Version: 6.12.1 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: GHC rejects valid program ----------------------------------------+----------------------------------- Changes (by igloo): * milestone: => 6.14.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 14 15:12:21 2010 From: trac at galois.com (GHC) Date: Sun Feb 14 14:43:18 2010 Subject: [GHC] #3849: 6.12.1: make framework-pkg on OS X creates package with broken installer In-Reply-To: <046.4b66a7f2c2a8beb4c5056f2100e3f907@abbot.galois.com> References: <046.4b66a7f2c2a8beb4c5056f2100e3f907@abbot.galois.com> Message-ID: <055.7ec2cd36a78839d2a49aa8a37d136fb5@abbot.galois.com> #3849: 6.12.1: make framework-pkg on OS X creates package with broken installer ---------------------------------+------------------------------------------ Reporter: korpios | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: Build System | Version: 6.12.1 Keywords: | Difficulty: Os: MacOS X | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Changes (by igloo): * milestone: => 6.12.2 Comment: Did you run `./configure` before `make framework-pkg`? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 14 15:13:20 2010 From: trac at galois.com (GHC) Date: Sun Feb 14 14:44:19 2010 Subject: [GHC] #3846: .ghci file is ignored on Mac OS X In-Reply-To: <046.8eef4df2140a161a09f528ad32c120bd@abbot.galois.com> References: <046.8eef4df2140a161a09f528ad32c120bd@abbot.galois.com> Message-ID: <055.1fe8521bfc6dacdf8e42f14fb77cd30c@abbot.galois.com> #3846: .ghci file is ignored on Mac OS X ------------------------+--------------------------------------------------- Reporter: mvanier | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.4 Keywords: | Difficulty: Os: MacOS X | Testcase: Architecture: x86 | Failure: Other ------------------------+--------------------------------------------------- Description changed by igloo: Old description: > I'm running ghc 6.10.4 on Mac OS X, and no matter what I do, my .ghci > file is completely ignored. Even if I put .ghci in the same directory > I'm invoking ghci from, all the commands are ignored. Other than that, > as far as I can tell, ghci works fine. My .ghci file contains only these > lines: > > :set -fglasgow-exts -W > > :set -v0 > > I can invoke these options successfully by calling ghci with the options > enabled, but I'd rather use a .ghci file. New description: I'm running ghc 6.10.4 on Mac OS X, and no matter what I do, my .ghci file is completely ignored. Even if I put .ghci in the same directory I'm invoking ghci from, all the commands are ignored. Other than that, as far as I can tell, ghci works fine. My .ghci file contains only these lines: {{{ :set -fglasgow-exts -W :set -v0 }}} I can invoke these options successfully by calling ghci with the options enabled, but I'd rather use a .ghci file. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 14 15:34:49 2010 From: trac at galois.com (GHC) Date: Sun Feb 14 15:05:46 2010 Subject: [GHC] #3846: .ghci file is ignored on Mac OS X In-Reply-To: <046.8eef4df2140a161a09f528ad32c120bd@abbot.galois.com> References: <046.8eef4df2140a161a09f528ad32c120bd@abbot.galois.com> Message-ID: <055.b26a979c3f6bd26998f6be183931191e@abbot.galois.com> #3846: .ghci file is ignored on Mac OS X -------------------------+-------------------------------------------------- Reporter: mvanier | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.10.4 Resolution: worksforme | Keywords: Difficulty: | Os: MacOS X Testcase: | Architecture: x86 Failure: Other | -------------------------+-------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => worksforme Comment: It works for me on OS X, albeit with 6.12.1. It could be that the problem is that it doesn't do exactly what you expect; for example, without a `.ghci`: {{{ $ ghci q.hs GHCi, version 6.12.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package ffi-1.0 ... linking ... done. [1 of 1] Compiling Main ( q.hs, interpreted ) Ok, modules loaded: Main. *Main> }}} and with `:set -v0` in `.ghci`: {{{ $ ghci q.hs GHCi, version 6.12.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package ffi-1.0 ... linking ... done. *Main> }}} Note that `.ghci` isn't read, and so `-v0` isn't applied, before the early messages are printed. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 14 15:42:03 2010 From: trac at galois.com (GHC) Date: Sun Feb 14 15:13:02 2010 Subject: [GHC] #3843: Merge plugins into HEAD In-Reply-To: <046.ca48414b16194ff9c91e1168584b7961@abbot.galois.com> References: <046.ca48414b16194ff9c91e1168584b7961@abbot.galois.com> Message-ID: <055.0fad81e2a752634aa94562d021b7907d@abbot.galois.com> #3843: Merge plugins into HEAD ---------------------------------+------------------------------------------ Reporter: dreixel | Owner: simonpj Type: task | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler | Version: 6.13 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Changes (by igloo): * milestone: => 6.14.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 14 17:20:37 2010 From: trac at galois.com (GHC) Date: Sun Feb 14 16:51:38 2010 Subject: [GHC] #3858: the resolution of abbreviated commands in ghci is surprising. In-Reply-To: <045.e262695a6b52bf0109375403f12dce74@abbot.galois.com> References: <045.e262695a6b52bf0109375403f12dce74@abbot.galois.com> Message-ID: <054.cbac9991d071150a29d261dc380d85b1@abbot.galois.com> #3858: the resolution of abbreviated commands in ghci is surprising. ---------------------------------+------------------------------------------ Reporter: Saizan | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: GHCi | Version: 6.12.1 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Changes (by igloo): * milestone: => 6.14.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 14 17:21:39 2010 From: trac at galois.com (GHC) Date: Sun Feb 14 16:52:48 2010 Subject: [GHC] #3866: Constr Eq instance should have better documentation or semantics In-Reply-To: <053.48fcc2bcaa72d91af4e5c6324198c5c7@abbot.galois.com> References: <053.48fcc2bcaa72d91af4e5c6324198c5c7@abbot.galois.com> Message-ID: <062.485506d3fd0f184bba969718b7707300@abbot.galois.com> #3866: Constr Eq instance should have better documentation or semantics ----------------------------------+----------------------------------------- Reporter: batterseapower | Owner: dreixel Type: bug | Status: assigned Priority: normal | Milestone: 6.12.2 Component: libraries (other) | Version: 6.12.1 Keywords: syb | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ----------------------------------+----------------------------------------- Changes (by igloo): * milestone: => 6.12.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 14 17:24:19 2010 From: trac at galois.com (GHC) Date: Sun Feb 14 16:55:16 2010 Subject: [GHC] #3870: Avoid Haddock-links to the Prelude In-Reply-To: <044.20d302777de4b1a04d5f7bc22a0bc7ca@abbot.galois.com> References: <044.20d302777de4b1a04d5f7bc22a0bc7ca@abbot.galois.com> Message-ID: <053.7162d63e550181852a16be52c61f4196@abbot.galois.com> #3870: Avoid Haddock-links to the Prelude ---------------------------------+------------------------------------------ Reporter: waern | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Documentation | Version: 6.12.1 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Documentation bug ---------------------------------+------------------------------------------ Changes (by igloo): * milestone: => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 14 17:24:30 2010 From: trac at galois.com (GHC) Date: Sun Feb 14 16:55:26 2010 Subject: [GHC] #3871: Missing reference in manpage In-Reply-To: <051.223f75e0ebf270e8f5107d53f1d88e6c@abbot.galois.com> References: <051.223f75e0ebf270e8f5107d53f1d88e6c@abbot.galois.com> Message-ID: <060.37c12d3d86b2d67f85da7963e7720809@abbot.galois.com> #3871: Missing reference in manpage ---------------------------------+------------------------------------------ Reporter: marcotmarcot | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 6.12.1 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Description changed by igloo: Old description: > from ghc(1): > -e expr > Evaluate expr; see for details. > > I think there's a word missing after see. > > Greetings. New description: from ghc(1): {{{ -e expr Evaluate expr; see for details. }}} I think there's a word missing after see. Greetings. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 14 17:26:28 2010 From: trac at galois.com (GHC) Date: Sun Feb 14 16:57:22 2010 Subject: [GHC] #3871: Missing reference in manpage In-Reply-To: <051.223f75e0ebf270e8f5107d53f1d88e6c@abbot.galois.com> References: <051.223f75e0ebf270e8f5107d53f1d88e6c@abbot.galois.com> Message-ID: <060.e7693971e4efe88aceaf383529867e20@abbot.galois.com> #3871: Missing reference in manpage ---------------------------------+------------------------------------------ Reporter: marcotmarcot | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: Documentation | Version: 6.12.1 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Changes (by igloo): * milestone: => 6.12.2 Comment: This looks like a problem with how the conversion is done from the docbook source. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 14 17:29:51 2010 From: trac at galois.com (GHC) Date: Sun Feb 14 17:00:59 2010 Subject: [GHC] #3876: assignement of thrown extension to variable of type string In-Reply-To: <051.214114d7a628f8b146f84a9a126abc23@abbot.galois.com> References: <051.214114d7a628f8b146f84a9a126abc23@abbot.galois.com> Message-ID: <060.b05a0dcd00e5e3d2e9889ce6aff01eb8@abbot.galois.com> #3876: assignement of thrown extension to variable of type string ---------------------------------+------------------------------------------ Reporter: andrewufrank | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Description changed by igloo: Old description: > in an unusual case (exception thrown in code in the return) the thrown > exception is returned from the function and then assigned to a variable > with another type (e.g. string); if the variable is later evaluated, the > exception is then actually thrown there (and not in the original > function). > > the bug is the problem in the asignement of a thrown exception to another > type. the coding style is unfortunate and not encourage, but the compiler > should report an error. > > (code like > = do ... > return (case x of > 0 -> throw Anexception > ) > produces the error. > > > i attach a file to demonstrate the problem. New description: in an unusual case (exception thrown in code in the return) the thrown exception is returned from the function and then assigned to a variable with another type (e.g. string); if the variable is later evaluated, the exception is then actually thrown there (and not in the original function). the bug is the problem in the asignement of a thrown exception to another type. the coding style is unfortunate and not encourage, but the compiler should report an error. (code like {{{ = do ... return (case x of 0 -> throw Anexception ) }}} produces the error. i attach a file to demonstrate the problem. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 14 17:33:44 2010 From: trac at galois.com (GHC) Date: Sun Feb 14 17:04:50 2010 Subject: [GHC] #3876: assignement of thrown extension to variable of type string In-Reply-To: <051.214114d7a628f8b146f84a9a126abc23@abbot.galois.com> References: <051.214114d7a628f8b146f84a9a126abc23@abbot.galois.com> Message-ID: <060.82241817528250bd467ac7c8017233ed@abbot.galois.com> #3876: assignement of thrown extension to variable of type string ---------------------------+------------------------------------------------ Reporter: andrewufrank | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: wontfix | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => wontfix Comment: I think every use of throw would be warned about if we did this. It sounds like you want `Control.Exception.throwIO` instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 14 17:36:03 2010 From: trac at galois.com (GHC) Date: Sun Feb 14 17:07:09 2010 Subject: [GHC] #3877: XOverlappingInstances flag not working In-Reply-To: <049.206d67806f9e5ec684138c11197151cd@abbot.galois.com> References: <049.206d67806f9e5ec684138c11197151cd@abbot.galois.com> Message-ID: <058.aac42dd095a1ab9d4119a213db826bb4@abbot.galois.com> #3877: XOverlappingInstances flag not working ----------------------------------------+----------------------------------- Reporter: traz161616 | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler (Type checker) | Version: 6.12.1 Keywords: XOverlappingInstances | Difficulty: Os: Linux | Testcase: Architecture: x86_64 (amd64) | Failure: GHC rejects valid program ----------------------------------------+----------------------------------- Changes (by igloo): * milestone: => 6.14.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 14 17:36:28 2010 From: trac at galois.com (GHC) Date: Sun Feb 14 17:07:23 2010 Subject: [GHC] #3878: doesFileExist doesn't work for some /dev files in ghc 6.12 In-Reply-To: <051.66116fcdcc5dbc814d38dc907d308ada@abbot.galois.com> References: <051.66116fcdcc5dbc814d38dc907d308ada@abbot.galois.com> Message-ID: <060.7534181beffb1c44bfb01197bb794c84@abbot.galois.com> #3878: doesFileExist doesn't work for some /dev files in ghc 6.12 -------------------------------+-------------------------------------------- Reporter: marcotmarcot | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.12.1 Keywords: | Difficulty: Os: Linux | Testcase: Architecture: x86_64 (amd64) | Failure: Incorrect result at runtime -------------------------------+-------------------------------------------- Description changed by igloo: Old description: > Hi. I've noticed this with a program that checks for a lvm image. > Here's the situation: > > Prelude System.Directory> doesFileExist "/dev/null" > True > Prelude System.Directory> doesFileExist "/dev/stdin" > True > Prelude System.Directory> doesFileExist "/dev/sda0" > False > Prelude System.Directory> doesFileExist "/dev/zezinho/sid" > False > > All of these files exist in my system: > > marcot@zezinho:/dev$ ls -l null sda1 stdin zezinho/sid /proc/self/fd/0 > mapper/zezinho-sid /dev/pts/5 > crw--w---- 1 marcot tty 136, 5 Fev 12 09:09 /dev/pts/5 > brw-rw---- 1 root disk 254, 4 Fev 12 08:55 mapper/zezinho-sid > crw-rw-rw- 1 root root 1, 3 Fev 12 08:33 null > lrwx------ 1 marcot marcot 64 Fev 12 09:09 /proc/self/fd/0 -> > /dev/pts/5 > brw-rw---- 1 root disk 8, 1 Fev 12 08:55 sda1 > lrwxrwxrwx 1 root root 15 Fev 12 08:33 stdin -> /proc/self/fd/0 > lrwxrwxrwx 1 root root 21 Fev 12 08:55 zezinho/sid -> ../mapper > /zezinho-sid New description: Hi. I've noticed this with a program that checks for a lvm image. Here's the situation: {{{ Prelude System.Directory> doesFileExist "/dev/null" True Prelude System.Directory> doesFileExist "/dev/stdin" True Prelude System.Directory> doesFileExist "/dev/sda0" False Prelude System.Directory> doesFileExist "/dev/zezinho/sid" False }}} All of these files exist in my system: {{{ marcot@zezinho:/dev$ ls -l null sda1 stdin zezinho/sid /proc/self/fd/0 mapper/zezinho-sid /dev/pts/5 crw--w---- 1 marcot tty 136, 5 Fev 12 09:09 /dev/pts/5 brw-rw---- 1 root disk 254, 4 Fev 12 08:55 mapper/zezinho-sid crw-rw-rw- 1 root root 1, 3 Fev 12 08:33 null lrwx------ 1 marcot marcot 64 Fev 12 09:09 /proc/self/fd/0 -> /dev/pts/5 brw-rw---- 1 root disk 8, 1 Fev 12 08:55 sda1 lrwxrwxrwx 1 root root 15 Fev 12 08:33 stdin -> /proc/self/fd/0 lrwxrwxrwx 1 root root 21 Fev 12 08:55 zezinho/sid -> ../mapper /zezinho-sid }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 14 17:37:11 2010 From: trac at galois.com (GHC) Date: Sun Feb 14 17:08:11 2010 Subject: [GHC] #3878: doesFileExist doesn't work for some /dev files in ghc 6.12 In-Reply-To: <051.66116fcdcc5dbc814d38dc907d308ada@abbot.galois.com> References: <051.66116fcdcc5dbc814d38dc907d308ada@abbot.galois.com> Message-ID: <060.0f6d9dd2d3d96abe09648b769d661e3a@abbot.galois.com> #3878: doesFileExist doesn't work for some /dev files in ghc 6.12 -------------------------------+-------------------------------------------- Reporter: marcotmarcot | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: Compiler | Version: 6.12.1 Keywords: | Difficulty: Os: Linux | Testcase: Architecture: x86_64 (amd64) | Failure: Incorrect result at runtime -------------------------------+-------------------------------------------- Changes (by igloo): * milestone: => 6.12.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 14 18:43:37 2010 From: trac at galois.com (GHC) Date: Sun Feb 14 18:14:32 2010 Subject: [GHC] #3841: build for libffi assumes tar supports -z In-Reply-To: <045.69f9c4089a918348ebb9aaa08d9cec23@abbot.galois.com> References: <045.69f9c4089a918348ebb9aaa08d9cec23@abbot.galois.com> Message-ID: <054.4a5a40a1c71424ceee83c3beae14f9f1@abbot.galois.com> #3841: build for libffi assumes tar supports -z ----------------------------------+----------------------------------------- Reporter: duncan | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 6.12.1 Resolution: fixed | Keywords: Difficulty: | Os: Solaris Testcase: | Architecture: Unknown/Multiple Failure: Building GHC failed | ----------------------------------+----------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed by: {{{ Sun Feb 14 22:04:50 GMT 2010 Ian Lynagh * Don't rely on tar supporting -z; trac #3841 }}} in the `ghc` repo, and: {{{ Sun Feb 14 22:05:56 GMT 2010 Ian Lynagh * Don't rely on tar supporting -j; trac #3841 }}} in the `integer-gmp` repo. In both HEAD and 6.12. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 14 23:50:04 2010 From: trac at galois.com (GHC) Date: Sun Feb 14 23:21:03 2010 Subject: [GHC] #3882: Adding libraries to an inplace GHC should JustWork(TM) Message-ID: <043.fd5706c6c2ab11f161c0980406d37e06@abbot.galois.com> #3882: Adding libraries to an inplace GHC should JustWork(TM) ---------------------------------+------------------------------------------ Reporter: benl | Owner: Type: feature request | Status: new Priority: normal | Component: Build System Version: 6.13 | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ After building the head I end up with the boot libraries built and working in `./libraries`. However, if I add a new darcs checkout to this dir (say `./libraries/parallel`) and type `make` then nothing happens. The trouble is that the library is missing `ghc.mk` and `GNUmakefile`. These files are created by `sh boot`, but if I do that at top-level it creates a new `ghc.mk` and `GNUmakefile` for *all* of the libraries, instead of just the new one. This means that when I type `make` now it wants to rebuild a bunch of things unrelated to the new library. There are some instructions at http://hackage.haskell.org/trac/ghc/wiki/Debugging/InstallingPackagesInplace but I am not keen on doing that for each additional package I need. Plan A on that page will also install packages in my local .cabal which will be a problem if I'm doing multiple builds in the same account. What should happen, is that if I place a new library in ./libraries and type `make` then this gets built and registered with the inplace compiler, just like the ones already there. There should also be an easy way to get and update all the libraries needed by the testsuite and nofib -- ie parallel, regex, mtl. I vaguely remember a command like `./darcs-all get --extralibs` but that doesn't work anymore. Adding a line for `libraries/parallel` to `./packages` doesn't work either because the ``darcs-all get`` script only checks `darcs.haskell.org` and not `hackage.haskell.org` as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 15 01:31:55 2010 From: trac at galois.com (GHC) Date: Mon Feb 15 01:02:55 2010 Subject: [GHC] #3875: DPH QuickHull example crashes on SPARC with -N > 1 In-Reply-To: <043.48127cd9f809a0bcf184a76857f65e8a@abbot.galois.com> References: <043.48127cd9f809a0bcf184a76857f65e8a@abbot.galois.com> Message-ID: <052.3aa37fe07345e9b76b323c2ed2a4b3b9@abbot.galois.com> #3875: DPH QuickHull example crashes on SPARC with -N > 1 -------------------------------+-------------------------------------------- Reporter: benl | Owner: benl Type: bug | Status: assigned Priority: high | Milestone: 6.12.2 Component: Runtime System | Version: 6.13 Keywords: | Difficulty: Os: Solaris | Testcase: Architecture: sparc | Failure: Runtime crash -------------------------------+-------------------------------------------- Comment(by benl): The same program works fine on x86/Linux. Another DPH benchmark `sumsq` crashes about 1 time in 20 on the SPARC/Solaris, so it does sound like a race condition of some kind. This wikipedia page http://en.wikipedia.org/wiki/Memory_ordering suggests that SPARC TSO and x86 memory ordering should be similar, and if that's true then I don't know why SPARC is crashing and x86 isn't. I'll do some digging. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 15 02:45:51 2010 From: trac at galois.com (GHC) Date: Mon Feb 15 02:16:52 2010 Subject: [GHC] #3866: Constr Eq instance should have better documentation or semantics In-Reply-To: <053.48fcc2bcaa72d91af4e5c6324198c5c7@abbot.galois.com> References: <053.48fcc2bcaa72d91af4e5c6324198c5c7@abbot.galois.com> Message-ID: <062.3b2d2d7da4762f973d4bc2fa987dbcdb@abbot.galois.com> #3866: Constr Eq instance should have better documentation or semantics ----------------------------------+----------------------------------------- Reporter: batterseapower | Owner: dreixel Type: bug | Status: assigned Priority: normal | Milestone: 6.12.2 Component: libraries (other) | Version: 6.12.1 Keywords: syb | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ----------------------------------+----------------------------------------- Comment(by dreixel): Neil: thanks for the feedback. I am also happy with your documentation proposal. If no one adds anything to the discussion I will submit a new patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 15 13:26:03 2010 From: trac at galois.com (GHC) Date: Mon Feb 15 12:56:58 2010 Subject: [GHC] #3736: GHC specialising instead of inlining In-Reply-To: <044.6187e75fed543439fb0c0aaede8523f0@abbot.galois.com> References: <044.6187e75fed543439fb0c0aaede8523f0@abbot.galois.com> Message-ID: <053.49221842d09680fd3607124c74cb2258@abbot.galois.com> #3736: GHC specialising instead of inlining -------------------------+-------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Keywords: | Difficulty: Os: Linux | Testcase: Architecture: x86 | Failure: Runtime performance bug -------------------------+-------------------------------------------------- Comment(by igloo): If I understand correctly `Main.hs` is a self-contained file containing the code you're talking about, and can be built with just bootlibs: {{{ $ time ./Main 1 ./Main 1 2.88s user 0.15s system 99% cpu 3.030 total $ time ./Main 2 ./Main 2 1.07s user 0.16s system 99% cpu 1.233 total }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 15 20:10:01 2010 From: trac at galois.com (GHC) Date: Mon Feb 15 19:40:57 2010 Subject: [GHC] #3875: DPH QuickHull example crashes on SPARC with -N > 1 In-Reply-To: <043.48127cd9f809a0bcf184a76857f65e8a@abbot.galois.com> References: <043.48127cd9f809a0bcf184a76857f65e8a@abbot.galois.com> Message-ID: <052.a1d6d111552b75ea87e3554877e69624@abbot.galois.com> #3875: DPH QuickHull example crashes on SPARC with -N > 1 -------------------------------+-------------------------------------------- Reporter: benl | Owner: benl Type: bug | Status: assigned Priority: high | Milestone: 6.12.2 Component: Runtime System | Version: 6.13 Keywords: | Difficulty: Os: Solaris | Testcase: Architecture: sparc | Failure: Runtime crash -------------------------------+-------------------------------------------- Comment(by benl): The `concprog002` testsuite program also crashes consistently with `-N16` and -`N32`. Once when running it when -N16 it said: {{{ benl@greyarea:~/devel/ghc/ghc-head-devel/tmp$ ./Server +RTS -N16 > /dev/null Server: thread blocked indefinitely in an MVar operation Server: thread blocked indefinitely in an MVar operation }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 16 04:54:26 2010 From: trac at galois.com (GHC) Date: Tue Feb 16 04:25:33 2010 Subject: [GHC] #3840: ghc-6.12.1 takes longer to compile code and produces bigger binaries compared to ghc-6.10.4 In-Reply-To: <045.ee0c11e517a19af640fa74e960df89c8@abbot.galois.com> References: <045.ee0c11e517a19af640fa74e960df89c8@abbot.galois.com> Message-ID: <054.83b0049f9ed0e260e94ab5506a425022@abbot.galois.com> #3840: ghc-6.12.1 takes longer to compile code and produces bigger binaries compared to ghc-6.10.4 -------------------------+-------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: Compiler | Version: 6.12.1 Keywords: | Difficulty: Os: Linux | Testcase: Architecture: x86 | Failure: None/Unknown -------------------------+-------------------------------------------------- Comment(by maeder): I've attached a small subset of our sources that hopefully illustrate the problem. {{{ tar zxvf Hets.tgz cd Hets ghc --make -O -iatermlib/src Common/atc.hs ls -S1sh */*.o */*/*.o */*/*/*.o rm */*.o */*/*.o */*/*/*.o }}} The only packages required to compile are base, containers, array, old- time, time and ghc-prim. It'll compile 15 files. The generated instances are in the file ATC/AS_Annotation.hs. The size of the file ATC/AS_Annotation.o is: {{{ ghc-6.10.4: 116K ghc-6.12.1: 528K ghc-6.13.20100211: 196K }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 16 09:16:32 2010 From: trac at galois.com (GHC) Date: Tue Feb 16 08:47:31 2010 Subject: [GHC] #3882: Adding libraries to an inplace GHC should JustWork(TM) In-Reply-To: <043.fd5706c6c2ab11f161c0980406d37e06@abbot.galois.com> References: <043.fd5706c6c2ab11f161c0980406d37e06@abbot.galois.com> Message-ID: <052.16c9deccfd4e69830daa567914f70977@abbot.galois.com> #3882: Adding libraries to an inplace GHC should JustWork(TM) ---------------------------------+------------------------------------------ Reporter: benl | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.13 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Comment(by simonmar): Yes, I agree it would be nice if this worked. The main sticking point is that we have to configure things in the right order, which means knowing the dependencies. The build system currently does this by hardcoding the order into `ghc.mk`, which is yucky. Probably we should have a global dependency-resolution phase done by `ghc-cabal` by re-using as much as we can from `cabal-install`. In the meantime we could say that any new libraries just get added to the end of the list, but that would go wrong if any of them depended on each other. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 17 01:51:55 2010 From: trac at galois.com (GHC) Date: Wed Feb 17 01:22:47 2010 Subject: [GHC] #2301: Proper handling of SIGINT/SIGQUIT In-Reply-To: <045.f06a53427920f75d02000e2372e27573@abbot.galois.com> References: <045.f06a53427920f75d02000e2372e27573@abbot.galois.com> Message-ID: <054.e9c1f4dab9c82b6a230abff733c79507@abbot.galois.com> #2301: Proper handling of SIGINT/SIGQUIT ---------------------------+------------------------------------------------ Reporter: duncan | Type: bug Status: new | Priority: normal Milestone: 6.14.1 | Component: libraries/process Version: 6.8.2 | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by PHO): * cc: pho@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 17 05:46:19 2010 From: trac at galois.com (GHC) Date: Wed Feb 17 05:17:08 2010 Subject: [GHC] #3883: --show-iface hangs on certain .hi files Message-ID: <047.4162e6106725348d0d62ce3a75b5669c@abbot.galois.com> #3883: --show-iface hangs on certain .hi files ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 6.14.1 Component: Compiler | Version: 6.13 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ In a GHC build, try {{{ inplace/bin/ghc-stage2 --show-iface array/dist- install/build/Data/Array/Base.hi }}} This hangs for me, right after {{{ b0318967c2f8fdf2005760546e36e780 $fIArrayUArrayBool_$cunsafeAccum :: forall i e'. GHC.Arr.Ix i => (GHC.Bool.Bool -> e' -> GHC.Bool.Bool) -> Data.Array.Base.UArray i GHC.Bool.Bool -> [(GHC.Types.Int, e')] -> Data.Array.Base.UArray i GHC.Bool.Bool {- Arity: 4, HasNoCafRefs, Strictness: ALU(LLLL)L, Inline: INLINE{3},^C }}} and the GHC process is uninteruptible, which suggests it has gone into an infinite non-allocating loop. Appears to be HEAD only. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 17 06:27:02 2010 From: trac at galois.com (GHC) Date: Wed Feb 17 05:57:49 2010 Subject: [GHC] #3884: killThread documentation Message-ID: <052.cea2c79fd729cdd7da906ce94a830473@abbot.galois.com> #3884: killThread documentation ---------------------------------+------------------------------------------ Reporter: Roel van Dijk | Owner: Type: proposal | Status: new Priority: normal | Component: Documentation Version: 6.12.1 | Keywords: killThread throwTo Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ The documentation for killThread states that: > killThread terminates the given thread (GHC only). However, this is not unconditionally true. It is possible to create a thread that is unkillable. The following fails to terminate: {{{ module Main where import Control.Concurrent ( forkIO, killThread ) import Control.Exception ( block ) main :: IO () main = do tid <- block $ forkIO $ let x = x in x killThread tid }}} This is not unexpected, but could be made a bit clearer in the documentation. Perhaps something like: "killThread attempts to terminate the given thread (GHC only)". -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 17 18:51:56 2010 From: trac at galois.com (GHC) Date: Wed Feb 17 18:22:45 2010 Subject: [GHC] #2889: Compilation fails - Can't opne temporary In-Reply-To: <046.8fe469503d4d0471dd07d5bc59e9501a@abbot.galois.com> References: <046.8fe469503d4d0471dd07d5bc59e9501a@abbot.galois.com> Message-ID: <055.ff9f3c4b9ddd59d8454010b66576f10d@abbot.galois.com> #2889: Compilation fails - Can't opne temporary ---------------------------+------------------------------------------------ Reporter: fobrock | Owner: Type: bug | Status: reopened Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: Unknown | Os: Windows Testcase: | Architecture: x86 Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by fuentesjr): * status: closed => reopened * failure: => None/Unknown * version: 6.10.1 => 6.10.4 * resolution: invalid => Comment: I came across this similar issue but I only see it under cygwin on windows (windows 7 with haskell platform 2009.2.0.2). Thought it might help: (fuentesjr@think ~/<1>haskell/test) ghc --make -v dnet Glasgow Haskell Compiler, Version 6.10.4, for Haskell 98, stage 2 booted by GHC version 6.10.1 Using package config file: C:\Program Files\Haskell Platform\2009.2.0.2\package.conf hiding package base-3.0.3.1 to avoid conflict with later version base-4.1.0.0 wired-in package ghc-prim mapped to ghc-prim-0.1.0.0 wired-in package integer mapped to integer-0.1.0.1 wired-in package base mapped to base-4.1.0.0 wired-in package rts mapped to rts-1.0 wired-in package haskell98 mapped to haskell98-1.0.1.0 wired-in package syb mapped to syb-0.1.0.1 wired-in package template-haskell mapped to template-haskell-2.3.0.1 wired-in package dph-seq mapped to dph-seq-0.3 wired-in package dph-par mapped to dph-par-0.3 Hsc static flags: -static *** Chasing dependencies: Chasing modules from: *dnet.hs Stable obj: [Main] Stable BCO: [] Ready for upsweep [NONREC ModSummary { ms_hs_date = Sat Feb 13 12:52:40 Pacific Standard Time 2010 ms_mod = main:Main, ms_imps = [Network.HTTP] ms_srcimps = [] }] compile: input file dnet.hs Created temporary directory: C:\Users\fuentesjr\/ghc3976_0 *** Checking old interface for main:Main: [1 of 1] Skipping Main ( dnet.hs, dnet.o ) *** Deleting temp files: Deleting: C:\Users\fuentesjr\/ghc3976_0/ghc3976_0.s Warning: deleting non-existent C:\Users\fuentesjr\/ghc3976_0/ghc3976_0.s Upsweep completely successful. *** Deleting temp files: Deleting: link: linkables are ... LinkableM (Wed Feb 17 15:02:21 Pacific Standard Time 2010) main:Main [DotO dnet.o] Linking dnet.exe ... *** Windres: C:\Program Files\Haskell Platform\2009.2.0.2\bin/windres --preprocessor="C:\Program Files\Haskell Platform\2009.2.0.2\gcc" "-BC:\Program Files\Haskell Platform\2009.2.0.2\gcc-lib/" "-IC:\Program Files\Haskell Platform\2009.2.0.2\include/mingw" "-E" "-xc" "-DRC_INVOKED" --use-temp-file --input=C:\Users\fuentesjr\/ghc3976_0/ghc3976_0.rc --output=C:\Users\fuentesjr\/ghc3976_0/ghc3976_0.o --output-format=coff C:\Program Files\Haskell Platform\2009.2.0.2\bin/windres: can't open temporary file `\/cca00592.irc': No such file or directory *** Deleting temp files: Deleting: C:\Users\fuentesjr\/ghc3976_0/ghc3976_0.o C:\Users\fuentesjr\/ghc3976_0/ghc3976_0.rc Warning: deleting non-existent C:\Users\fuentesjr\/ghc3976_0/ghc3976_0.o *** Deleting temp dirs: Deleting: C:\Users\fuentesjr\/ghc3976_0 (fuentesjr@think ~/<1>haskell/test) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 17 19:07:15 2010 From: trac at galois.com (GHC) Date: Wed Feb 17 18:38:01 2010 Subject: [GHC] #3885: A bug appeared trying to run an opengl(-haskell) program Message-ID: <044.2fdcc8b4e9abed95b49ed1247d222599@abbot.galois.com> #3885: A bug appeared trying to run an opengl(-haskell) program -----------------------+---------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Keywords: Os: Linux | Testcase: Architecture: x86 | Failure: Compile-time crash -----------------------+---------------------------------------------------- mh@dsktp:/media/VENUS/python$ ghc helloWorld.hs -o ej Binary: Int64 truncated to fit in 32 bit Int ghc: panic! (the 'impossible' happened) (GHC version 6.10.4 for i386-unknown-linux): Prelude.chr: bad argument Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 17 19:31:46 2010 From: trac at galois.com (GHC) Date: Wed Feb 17 19:02:33 2010 Subject: [GHC] #3736: GHC specialising instead of inlining In-Reply-To: <044.6187e75fed543439fb0c0aaede8523f0@abbot.galois.com> References: <044.6187e75fed543439fb0c0aaede8523f0@abbot.galois.com> Message-ID: <053.161603991ae61df6cc7edfa87198f59d@abbot.galois.com> #3736: GHC specialising instead of inlining -------------------------+-------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Keywords: | Difficulty: Os: Linux | Testcase: Architecture: x86 | Failure: Runtime performance bug -------------------------+-------------------------------------------------- Comment(by guest): Yes, this seems to do the same. In general it is problematic to have more than one test case in an executable, since GHC decides between specialisation and inlining of a function depending on the number of calls. But in this case it looks like GHC makes the same decision. Btw. how did you manage to create this self-contained module? Manually? I remember there was a program that performs assembling one module from several ones in order to get whole program analysis. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 18 00:16:11 2010 From: trac at galois.com (GHC) Date: Wed Feb 17 23:47:28 2010 Subject: [GHC] #3869: RTS GC Statistics from -S should be logged via the eventlog system In-Reply-To: <042.ba02c1597aeebebb22784b09f5ce7c9a@abbot.galois.com> References: <042.ba02c1597aeebebb22784b09f5ce7c9a@abbot.galois.com> Message-ID: <051.13e4dad698e06a078c1381475d356fa1@abbot.galois.com> #3869: RTS GC Statistics from -S should be logged via the eventlog system ---------------------------------------------------+------------------------ Reporter: cjs | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.14 branch Component: Runtime System | Version: 6.12.1 Keywords: gc, garbage collection, statistics | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------------------------+------------------------ Comment(by cjs): This may well be valuable enough for me to add myself. I'm guessing the user interface would be an "-lg" option. The internals I suspect are easy enough; Simon, do you have general suggestions on how you would want this done? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 18 05:44:03 2010 From: trac at galois.com (GHC) Date: Thu Feb 18 05:14:51 2010 Subject: [GHC] #3885: A bug appeared trying to run an opengl(-haskell) program In-Reply-To: <044.2fdcc8b4e9abed95b49ed1247d222599@abbot.galois.com> References: <044.2fdcc8b4e9abed95b49ed1247d222599@abbot.galois.com> Message-ID: <053.c7550d33f06c4a05ba97f6cfaa361484@abbot.galois.com> #3885: A bug appeared trying to run an opengl(-haskell) program ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: fixed | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86 Failure: Compile-time crash | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: This was a bug in GHC 6.10.4 where it didn't detect that an old `.hi` file was incompatible and tried to read it. Remove all `.hi` files, or upgrade to GHC 6.12.1, and you should be ok. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 18 05:47:53 2010 From: trac at galois.com (GHC) Date: Thu Feb 18 05:19:13 2010 Subject: [GHC] #3869: RTS GC Statistics from -S should be logged via the eventlog system In-Reply-To: <042.ba02c1597aeebebb22784b09f5ce7c9a@abbot.galois.com> References: <042.ba02c1597aeebebb22784b09f5ce7c9a@abbot.galois.com> Message-ID: <051.1ea822818f9f18ce835777cddffa2712@abbot.galois.com> #3869: RTS GC Statistics from -S should be logged via the eventlog system ---------------------------------------------------+------------------------ Reporter: cjs | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.14 branch Component: Runtime System | Version: 6.12.1 Keywords: gc, garbage collection, statistics | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------------------------+------------------------ Comment(by simonmar): Replying to [comment:2 cjs]: > This may well be valuable enough for me to add myself. I'm guessing the user interface would be an "-lg" option. The internals I suspect are easy enough; Simon, do you have general suggestions on how you would want this done? Add a new event "GC_STATS" or something, with fields for bytes allocated, bytes copied, bytes live, generation collected. We might want to add more fields in the future, but the format allows us to do that. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 18 07:59:53 2010 From: trac at galois.com (GHC) Date: Thu Feb 18 07:30:39 2010 Subject: [GHC] #3736: GHC specialising instead of inlining In-Reply-To: <044.6187e75fed543439fb0c0aaede8523f0@abbot.galois.com> References: <044.6187e75fed543439fb0c0aaede8523f0@abbot.galois.com> Message-ID: <053.5babefa0eb3e49c4333e4a61053b8120@abbot.galois.com> #3736: GHC specialising instead of inlining -------------------------+-------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Keywords: | Difficulty: Os: Linux | Testcase: Architecture: x86 | Failure: Runtime performance bug -------------------------+-------------------------------------------------- Comment(by igloo): Replying to [comment:9 guest]: > Btw. how did you manage to create this self-contained module? Manually? Yes, helped by `-Wall -Werror` to easily find unnecessary code. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 18 08:00:04 2010 From: trac at galois.com (GHC) Date: Thu Feb 18 07:30:48 2010 Subject: [GHC] #3736: GHC specialising instead of inlining In-Reply-To: <044.6187e75fed543439fb0c0aaede8523f0@abbot.galois.com> References: <044.6187e75fed543439fb0c0aaede8523f0@abbot.galois.com> Message-ID: <053.c9aac8c61bb41440cf0a0b148bb42d85@abbot.galois.com> #3736: GHC specialising instead of inlining -------------------------+-------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler | Version: 6.10.4 Keywords: | Difficulty: Os: Linux | Testcase: Architecture: x86 | Failure: Runtime performance bug -------------------------+-------------------------------------------------- Changes (by igloo): * milestone: => 6.14.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 18 08:00:14 2010 From: trac at galois.com (GHC) Date: Thu Feb 18 07:30:57 2010 Subject: [GHC] #3737: inlining happens on foldl1 and does not happen on direct application of combinator In-Reply-To: <044.fddf7c34bfc36e2b8667f9dd59d27ab6@abbot.galois.com> References: <044.fddf7c34bfc36e2b8667f9dd59d27ab6@abbot.galois.com> Message-ID: <053.612a2beeddf8cfcd1a7ebab989865694@abbot.galois.com> #3737: inlining happens on foldl1 and does not happen on direct application of combinator -------------------------+-------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler | Version: 6.10.4 Keywords: | Difficulty: Os: Linux | Testcase: Architecture: x86 | Failure: Runtime performance bug -------------------------+-------------------------------------------------- Changes (by igloo): * milestone: => 6.14.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 18 08:00:48 2010 From: trac at galois.com (GHC) Date: Thu Feb 18 07:31:33 2010 Subject: [GHC] #3811: Parse errors should display text being parsed In-Reply-To: <048.46ad97689e6bccb5e95c9352fb6afccc@abbot.galois.com> References: <048.46ad97689e6bccb5e95c9352fb6afccc@abbot.galois.com> Message-ID: <057.d3a9deb643f416daa3daf26ce62a76cc@abbot.galois.com> #3811: Parse errors should display text being parsed ----------------------------------+----------------------------------------- Reporter: asuffield | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14 branch Component: Compiler (Parser) | Version: 6.12.1 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ----------------------------------+----------------------------------------- Changes (by igloo): * milestone: => 6.14 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 18 08:05:37 2010 From: trac at galois.com (GHC) Date: Thu Feb 18 07:36:25 2010 Subject: [GHC] #3829: GHC leaks memory when compiling many files In-Reply-To: <045.39f8c05a1a27aec7ca785e89572f98be@abbot.galois.com> References: <045.39f8c05a1a27aec7ca785e89572f98be@abbot.galois.com> Message-ID: <054.940036ad44dfdebc251fdeb7731879d9@abbot.galois.com> #3829: GHC leaks memory when compiling many files -------------------------------+-------------------------------------------- Reporter: maltem | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler | Version: 6.12.1 Keywords: | Difficulty: Os: Linux | Testcase: Architecture: x86_64 (amd64) | Failure: Compile-time performance bug -------------------------------+-------------------------------------------- Changes (by igloo): * milestone: => 6.14.1 Comment: Thanks for the report. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 18 08:06:36 2010 From: trac at galois.com (GHC) Date: Thu Feb 18 07:37:28 2010 Subject: [GHC] #691: Make the testsuite standalone In-Reply-To: <047.1357de85d43f63c0185b887daf484d05@abbot.galois.com> References: <047.1357de85d43f63c0185b887daf484d05@abbot.galois.com> Message-ID: <056.95c13d3a803760113f9add69b225a4ec@abbot.galois.com> #691: Make the testsuite standalone -----------------------------------------+---------------------------------- Reporter: simonmar | Owner: Type: task | Status: closed Priority: normal | Milestone: Not GHC Component: Test Suite | Version: 6.4.1 Resolution: fixed | Keywords: Difficulty: Moderate (less than a day) | Os: Unknown/Multiple Testcase: N/A | Architecture: Unknown/Multiple Failure: None/Unknown | -----------------------------------------+---------------------------------- Changes (by igloo): * status: new => closed * failure: => None/Unknown * resolution: => fixed Comment: The testsuite is now standalone. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 18 22:36:45 2010 From: trac at galois.com (GHC) Date: Thu Feb 18 22:07:29 2010 Subject: [GHC] #3886: Standalone deriving of NFData causes panic Message-ID: <046.4d0bac3e7ba9c1023afa62c4cce4ccf2@abbot.galois.com> #3886: Standalone deriving of NFData causes panic ---------------------------------+------------------------------------------ Reporter: blarsen | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.12.1 | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Compile-time crash ---------------------------------+------------------------------------------ Using the -XStandaloneDeriving option, I tried to generate an NFData instance for the CNF type from the funsat 0.60 package on Hackage. {{{ {-# LANGUAGE StandaloneDeriving #-} module Broken where import Funsat.Types import Control.Parallel.Strategies deriving instance NFData AST }}} With ghc 6.12.1 on 32-bit Ubuntu, the above causes a panic: ghc: panic! (the 'impossible' happened) (GHC version 6.12.1 for i386-unknown-linux): genDerivBinds: bad derived class deepseq-1.1.0.0:Control.DeepSeq.NFData{tc rou} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 18 22:41:26 2010 From: trac at galois.com (GHC) Date: Thu Feb 18 22:12:10 2010 Subject: [GHC] #3886: Standalone deriving of NFData causes panic In-Reply-To: <046.4d0bac3e7ba9c1023afa62c4cce4ccf2@abbot.galois.com> References: <046.4d0bac3e7ba9c1023afa62c4cce4ccf2@abbot.galois.com> Message-ID: <055.e08b1e62fd828490f3e8af290bc42c2b@abbot.galois.com> #3886: Standalone deriving of NFData causes panic ---------------------------------+------------------------------------------ Reporter: blarsen | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.12.1 | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Compile-time crash ---------------------------------+------------------------------------------ Comment(by blarsen): Replying to [ticket:3886 blarsen]: Whoops, the `deriving' line should be this: {{{ deriving instance NFData CNF }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 18 23:25:26 2010 From: trac at galois.com (GHC) Date: Thu Feb 18 22:56:17 2010 Subject: [GHC] #3875: DPH QuickHull example crashes on SPARC with -N > 1 In-Reply-To: <043.48127cd9f809a0bcf184a76857f65e8a@abbot.galois.com> References: <043.48127cd9f809a0bcf184a76857f65e8a@abbot.galois.com> Message-ID: <052.0e54c1f3b03e5d95c27e68bac3f16542@abbot.galois.com> #3875: DPH QuickHull example crashes on SPARC with -N > 1 -------------------------------+-------------------------------------------- Reporter: benl | Owner: benl Type: bug | Status: assigned Priority: high | Milestone: 6.12.2 Component: Runtime System | Version: 6.13 Keywords: | Difficulty: Os: Solaris | Testcase: Architecture: sparc | Failure: Runtime crash -------------------------------+-------------------------------------------- Comment(by benl): After compiling quickhull with {{{ ... inplace/bin/ghc-stage2 --make vect.hs -threaded -fdph-par -package dph-bench -package-conf ../lib/dph-bench.conf -Odph -fforce-recomp -debug }}} Running {{{ ./vect 10000 +RTS -N16 -- crashes ./vect 10000 +RTS -N16 -qg -- works, no parallel GC ./vect 10000 +RTS -N16 -A100M -H100M -S -- works, only 2 GCs run }}} And it always crashes in the first GC cycle. {{{ ./vect 100000 +RTS -N2 -S Alloc Copied Live GC GC TOT TOT Page Flts bytes bytes bytes user elap user elap 524688 309168 295340 0.07 0.05 0.08 0.06 0 0 (Gen: 1) Bus Error (core dumped) }}} Note: `+RTS -DS` (debug sanity) does not sanity check the heap when running with `-threaded`. See `rts/sm/Sanity.c` -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 19 03:24:51 2010 From: trac at galois.com (GHC) Date: Fri Feb 19 02:55:40 2010 Subject: [GHC] #3875: DPH QuickHull example crashes on SPARC with -N > 1 In-Reply-To: <043.48127cd9f809a0bcf184a76857f65e8a@abbot.galois.com> References: <043.48127cd9f809a0bcf184a76857f65e8a@abbot.galois.com> Message-ID: <052.3a77a7126820193dbedcc52f9c135c73@abbot.galois.com> #3875: DPH QuickHull example crashes on SPARC with -N > 1 -------------------------------+-------------------------------------------- Reporter: benl | Owner: benl Type: bug | Status: assigned Priority: high | Milestone: 6.12.2 Component: Runtime System | Version: 6.13 Keywords: | Difficulty: Os: Solaris | Testcase: Architecture: sparc | Failure: Runtime crash -------------------------------+-------------------------------------------- Comment(by benl): This looks like a race in the bale-out code at the bottom of `eval_thunk_selector`. An instrumented version of the code shows these events. The program was previously crashing when it tried to dereference the last, misaligned pointer. {{{ tid= 3 p=fece84f4 entering eval_thunk_selector. tid= 3 p=fece84f4 info_ptr_table=19a0750 tid= 3 p=fece84f4 bailing out tid= 0 p=fece84f4 entering eval_thunk_selector. tid= 0 p=fece84f4 info_ptr_table=fec96b21 BLERGH!!!!!! stopping program }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 19 07:19:40 2010 From: trac at galois.com (GHC) Date: Fri Feb 19 06:50:24 2010 Subject: [GHC] #3884: killThread documentation In-Reply-To: <052.cea2c79fd729cdd7da906ce94a830473@abbot.galois.com> References: <052.cea2c79fd729cdd7da906ce94a830473@abbot.galois.com> Message-ID: <061.f162afbb2a8135309195fffb25e571b2@abbot.galois.com> #3884: killThread documentation ---------------------------------+------------------------------------------ Reporter: Roel van Dijk | Owner: Type: proposal | Status: new Priority: normal | Component: Documentation Version: 6.12.1 | Keywords: killThread throwTo Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Changes (by Roel van Dijk): * cc: vandijk.roel@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 19 08:21:52 2010 From: trac at galois.com (GHC) Date: Fri Feb 19 07:52:37 2010 Subject: [GHC] #3887: getOptions'.parseLanguage(2) went past eof token Message-ID: <048.ec35efc0ff206f24e97b95678340e2dc@abbot.galois.com> #3887: getOptions'.parseLanguage(2) went past eof token --------------------------+------------------------------------------------- Reporter: osaunders | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Keywords: Os: MacOS X | Testcase: Architecture: x86 | Failure: GHCi crash --------------------------+------------------------------------------------- > :l qgen2 ghc: panic! (the 'impossible' happened) (GHC version 6.10.4 for i386-apple-darwin): getOptions'.parseLanguage(2) went past eof token -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 19 13:03:46 2010 From: trac at galois.com (GHC) Date: Fri Feb 19 12:34:33 2010 Subject: [GHC] #322: fromInteger-related pattern match overlap warnings In-Reply-To: <047.ace5220e5df89abf8e6e92924cc2e86b@abbot.galois.com> References: <047.ace5220e5df89abf8e6e92924cc2e86b@abbot.galois.com> Message-ID: <056.fb2fc44d82a3b254c551ddfe9c548a4c@abbot.galois.com> #322: fromInteger-related pattern match overlap warnings ---------------------------+------------------------------------------------ Reporter: ashley-y | Owner: simonpj Type: bug | Status: assigned Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.4 Resolution: None | Keywords: warnings Difficulty: Unknown | Os: Unknown/Multiple Testcase: ds060 | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by marcotmarcot): * failure: => None/Unknown Comment: I'm thinking about this bug, and the only way I can see to avoid it, is by knowing in compile-time, that is, when the compiler checks if the Patterns are complete, how the value (1 :: Integer) will be converted to (1 :: Maybe Int). This is defined in "fromInteger = Just . fromInteger", which is a user code. So the user code will have to be evaluated in compile time. Is this already done in any case? I don't think so, as this would create the possibility of the compilation not terminating. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 19 13:19:15 2010 From: trac at galois.com (GHC) Date: Fri Feb 19 12:49:57 2010 Subject: [GHC] #595: Overhaul GHC's overlapping/non-exhaustive pattern checking In-Reply-To: <047.bea78f01cbb904765ad77c751bc8d3af@abbot.galois.com> References: <047.bea78f01cbb904765ad77c751bc8d3af@abbot.galois.com> Message-ID: <056.df3f5887dc80441b42dc2637aab376d7@abbot.galois.com> #595: Overhaul GHC's overlapping/non-exhaustive pattern checking ------------------------------------------------+--------------------------- Reporter: simonmar | Owner: marcotmarcot Type: task | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: None Resolution: None | Keywords: warnings Difficulty: Difficult (2-5 days) | Os: Unknown/Multiple Testcase: N/A | Architecture: Unknown/Multiple Failure: Incorrect warning at compile-time | ------------------------------------------------+--------------------------- Comment(by marcotmarcot): Hi. I won't work with this task, because I've not found the relevance. [http://hackage.haskell.org/trac/ghc/ticket/322 Issue #322] doens't seem to be fixable, and [http://hackage.haskell.org/trac/ghc/ticket/2204 issue #2204] and [http://hackage.haskell.org/trac/ghc/ticket/1307 #1307] are only about improving the error message. Greetings. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 19 13:19:43 2010 From: trac at galois.com (GHC) Date: Fri Feb 19 12:50:26 2010 Subject: [GHC] #595: Overhaul GHC's overlapping/non-exhaustive pattern checking In-Reply-To: <047.bea78f01cbb904765ad77c751bc8d3af@abbot.galois.com> References: <047.bea78f01cbb904765ad77c751bc8d3af@abbot.galois.com> Message-ID: <056.f8e3cc7e40816751c26d742f4678803f@abbot.galois.com> #595: Overhaul GHC's overlapping/non-exhaustive pattern checking ------------------------------------------------+--------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: None Resolution: None | Keywords: warnings Difficulty: Difficult (2-5 days) | Os: Unknown/Multiple Testcase: N/A | Architecture: Unknown/Multiple Failure: Incorrect warning at compile-time | ------------------------------------------------+--------------------------- Changes (by marcotmarcot): * owner: marcotmarcot => -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 19 13:28:19 2010 From: trac at galois.com (GHC) Date: Fri Feb 19 12:59:03 2010 Subject: [GHC] #3888: Suggest -XGeneralizedNewtypeDeriving for newtypes Message-ID: <044.7be0aa9566c791a35440567dc37cdff2@abbot.galois.com> #3888: Suggest -XGeneralizedNewtypeDeriving for newtypes ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.12.1 | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ newtype A = A Int deriving Enum t.hs:1:27: Can't make a derived instance of `Enum A' (`A' has non-nullary constructors) In the newtype declaration for `A' But perhaps -XGeneralizedNewtypeDeriving should be suggested (ideally only if the wrapped type actually had such an instance)? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 19 14:40:30 2010 From: trac at galois.com (GHC) Date: Fri Feb 19 14:11:13 2010 Subject: [GHC] #2204: Improve 'patterns not matched' warnings In-Reply-To: <047.57470c7515f5d78414f8813f455c57a5@abbot.galois.com> References: <047.57470c7515f5d78414f8813f455c57a5@abbot.galois.com> Message-ID: <056.950e522a48c938949e6e7331b90df967@abbot.galois.com> #2204: Improve 'patterns not matched' warnings ---------------------------------+------------------------------------------ Reporter: Deewiant | Owner: Type: feature request | Status: new Priority: low | Milestone: _|_ Component: Compiler | Version: 6.8.2 Keywords: | Difficulty: Unknown Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Changes (by marcotmarcot): * cc: marcot@? (added) * failure: => None/Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 19 14:40:40 2010 From: trac at galois.com (GHC) Date: Fri Feb 19 14:11:21 2010 Subject: [GHC] #595: Overhaul GHC's overlapping/non-exhaustive pattern checking In-Reply-To: <047.bea78f01cbb904765ad77c751bc8d3af@abbot.galois.com> References: <047.bea78f01cbb904765ad77c751bc8d3af@abbot.galois.com> Message-ID: <056.45a61f1e741845640d711562a92e87c6@abbot.galois.com> #595: Overhaul GHC's overlapping/non-exhaustive pattern checking ------------------------------------------------+--------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: None Resolution: None | Keywords: warnings Difficulty: Difficult (2-5 days) | Os: Unknown/Multiple Testcase: N/A | Architecture: Unknown/Multiple Failure: Incorrect warning at compile-time | ------------------------------------------------+--------------------------- Changes (by marcotmarcot): * cc: marcot@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 19 19:28:07 2010 From: trac at galois.com (GHC) Date: Fri Feb 19 18:58:48 2010 Subject: [GHC] #3856: Share code between C wrappers In-Reply-To: <044.cba3c7154542d8f645c7639175d0041b@abbot.galois.com> References: <044.cba3c7154542d8f645c7639175d0041b@abbot.galois.com> Message-ID: <053.71e2e766da8f113850a1e81fbc204936@abbot.galois.com> #3856: Share code between C wrappers ---------------------------+------------------------------------------------ Reporter: igloo | Owner: igloo Type: task | Status: closed Priority: normal | Milestone: 6.12 branch Component: Driver | Version: 6.12.1 Resolution: fixed | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed by: {{{ Thu Feb 18 09:09:31 PST 2010 Ian Lynagh * Refactor gcc.c, pulling out the reusable code Thu Feb 18 09:17:16 PST 2010 Ian Lynagh * Use the shared C wrapper code in ghci.c too Fri Feb 19 05:42:22 PST 2010 Ian Lynagh * Fix build on Windows }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 19 19:45:42 2010 From: trac at galois.com (GHC) Date: Fri Feb 19 19:16:23 2010 Subject: [GHC] #3889: configure script is generating the incorrect value for HAVE_GNU_NONEXEC_STACK Message-ID: <042.acec9ff49216bf41d3a8043c63fec786@abbot.galois.com> #3889: configure script is generating the incorrect value for HAVE_GNU_NONEXEC_STACK -------------------------------+-------------------------------------------- Reporter: dmp | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.13 | Keywords: Os: Linux | Testcase: Architecture: x86_64 (amd64) | Failure: Other -------------------------------+-------------------------------------------- My system (Fedora 12 x86_64) supports the GNU non-executable stack note, but the configure script is not detecting it correctly. The test program used to check for this note causes a compiler error which causes configure to incorrectly determine the system does not support this feature. A better test program is needed to determine if the non-executable stack is actually supported. This problem turns out to be the root cause of some strange behavior I encountered, which I repeat here in case others have a similar problem. I was attempting to verify that my programs were being dynamically linked using {{{ldd}}}, but {{{ldd}}} was reporting that the binary was not a dynamically linked executable. ldd was having a problem due to SELinux which was not happy with the executable stack on the programs generated by ghc. Looking through past tickets I found #703 which says that ghc does generate code using the non-executable stack note. Thus I found that the build system was not correctly setting the value. Now to the details of the problem. The configure.ac contains the following check to see if the system supports the non-executable stack note. {{{ 827 dnl *** check for GNU non-executable stack note support (ELF only) 828 dnl (.section .note.GNU-stack,"",@progbits) 829 830 AC_MSG_CHECKING(for GNU non-executable stack support) 831 AC_COMPILE_IFELSE( 832 [AC_LANG_PROGRAM([__asm__ (".section .note.GNU- stack,\"\",@progbits");], [0])], 833 [AC_MSG_RESULT(yes) 834 AC_DEFINE([HAVE_GNU_NONEXEC_STACK],[1], 835 [Define to 1 if GNU non-executable stack notes are supported.]) 836 ], 837 [AC_MSG_RESULT(no)]) }}} On my system (Fedora 12) this test generates the assembler error shown which causes configure to incorrectly say that the compiler does not support the non-executable stack note. {{{ $ /usr/lib64/ccache/gcc -c -g -O2 conftest.c /tmp/ccohqUvf.s: Assembler messages: /tmp/ccohqUvf.s:126: Error: can't resolve `.note.GNU-stack' {.note.GNU- stack section} - `.Ltext0' {.text section} }}} I believe the assembler error is related to the debug info that is generating references to the label containing the .section .note.GNU- stack. I've included the the generated assembly below for reference. If the -g flag is removed the assembler error goes away. Not being an autoconf expert I can think of two options for a better autoconf test. 1. Don't use -g when compiling the current test program. 1. Use a variation of $ gcc -Wa,-al,--noexecstack t.c | grep '.note .GNU-stack' {{{ $ /usr/lib64/ccache/gcc -c -g -O2 -S conftest.c $ cat conftest.s .file "t.c" .section .debug_abbrev,"",@progbits .Ldebug_abbrev0: .section .debug_info,"",@progbits .Ldebug_info0: .section .debug_line,"",@progbits .Ldebug_line0: .text .Ltext0: #APP .section .note.GNU-stack,"",@progbits #NO_APP .p2align 4,,15 .globl main .type main, @function main: .LFB0: .file 1 "t.c" .loc 1 106 0 .cfi_startproc .loc 1 110 0 xorl %eax, %eax ret .cfi_endproc .LFE0: .size main, .-main .Letext0: .section .debug_info .long 0x4f .value 0x3 .long .Ldebug_abbrev0 .byte 0x8 .uleb128 0x1 .long .LASF0 .byte 0x1 .string "t.c" .long .LASF1 .quad .Ltext0 .quad .Letext0 .long .Ldebug_line0 .uleb128 0x2 .byte 0x1 .long .LASF2 .byte 0x1 .byte 0x69 .long 0x4b .quad .LFB0 .quad .LFE0 .byte 0x1 .byte 0x9c .uleb128 0x3 .byte 0x4 .byte 0x5 .string "int" .byte 0x0 .section .debug_abbrev .uleb128 0x1 .uleb128 0x11 .byte 0x1 .uleb128 0x25 .uleb128 0xe .uleb128 0x13 .uleb128 0xb .uleb128 0x3 .uleb128 0x8 .uleb128 0x1b .uleb128 0xe .uleb128 0x11 .uleb128 0x1 .uleb128 0x12 .uleb128 0x1 .uleb128 0x10 .uleb128 0x6 .byte 0x0 .byte 0x0 .uleb128 0x2 .uleb128 0x2e .byte 0x0 .uleb128 0x3f .uleb128 0xc .uleb128 0x3 .uleb128 0xe .uleb128 0x3a .uleb128 0xb .uleb128 0x3b .uleb128 0xb .uleb128 0x49 .uleb128 0x13 .uleb128 0x11 .uleb128 0x1 .uleb128 0x12 .uleb128 0x1 .uleb128 0x40 .uleb128 0xa .byte 0x0 .byte 0x0 .uleb128 0x3 .uleb128 0x24 .byte 0x0 .uleb128 0xb .uleb128 0xb .uleb128 0x3e .uleb128 0xb .uleb128 0x3 .uleb128 0x8 .byte 0x0 .byte 0x0 .byte 0x0 .section .debug_pubnames,"",@progbits .long 0x17 .value 0x2 .long .Ldebug_info0 .long 0x53 .long 0x2d .string "main" .long 0x0 .section .debug_aranges,"",@progbits .long 0x2c .value 0x2 .long .Ldebug_info0 .byte 0x8 .byte 0x0 .value 0x0 .value 0x0 .quad .Ltext0 .quad .Letext0-.Ltext0 .quad 0x0 .quad 0x0 .section .debug_str,"MS",@progbits,1 .LASF1: .string "/home/dave/tmp" .LASF0: .string "GNU C 4.4.2 20091027 (Red Hat 4.4.2-7)" .LASF2: .string "main" .ident "GCC: (GNU) 4.4.2 20091027 (Red Hat 4.4.2-7)" .section .note.GNU-stack,"",@progbits }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 19 20:48:16 2010 From: trac at galois.com (GHC) Date: Fri Feb 19 20:18:59 2010 Subject: [GHC] #3890: runghc sometimes won't allow redirecting of stdout/stderr Message-ID: <047.7734ea51821b1889479275321f4cfa90@abbot.galois.com> #3890: runghc sometimes won't allow redirecting of stdout/stderr ---------------------------------+------------------------------------------ Reporter: simonmic | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 6.10.4 | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ See attached test.hs. Here's stdout working normally: $ runhaskell test.hs | cat output $ But after uncommenting either the cmdArgs line or the defaultMainWithArgs line, stdout can't be captured: $ runhaskell test.hs | cat $ It does appear on the console if you don't redirect though. The same goes for stderr. This prevents me testing uncompiled scripts with shelltestrunner. I'm on mac os 10.5. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 19 20:50:07 2010 From: trac at galois.com (GHC) Date: Fri Feb 19 20:20:48 2010 Subject: [GHC] #3890: runghc sometimes won't allow redirecting of stdout/stderr In-Reply-To: <047.7734ea51821b1889479275321f4cfa90@abbot.galois.com> References: <047.7734ea51821b1889479275321f4cfa90@abbot.galois.com> Message-ID: <056.3be0444e4f300aeeb3e2059ec0447a65@abbot.galois.com> #3890: runghc sometimes won't allow redirecting of stdout/stderr ---------------------------------+------------------------------------------ Reporter: simonmic | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 6.10.4 | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Comment(by simonmic): {{{ stdout working normally: $ runhaskell test.hs | cat output $ after uncommenting either commented line below, stdout can't be captured: $ runhaskell test.hs | cat $ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 20 02:43:32 2010 From: trac at galois.com (GHC) Date: Sat Feb 20 02:14:10 2010 Subject: [GHC] #3891: evacuate: strange closure types THUNK_STATIC and CONSTR_NOCAF_STATIC on ia64 Message-ID: <043.d1ba2c877f373a38174c3627ee9fb741@abbot.galois.com> #3891: evacuate: strange closure types THUNK_STATIC and CONSTR_NOCAF_STATIC on ia64 -----------------------+---------------------------------------------------- Reporter: kaol | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.12.1 | Keywords: Os: Linux | Testcase: Architecture: ia64 | Failure: Compile-time crash -----------------------+---------------------------------------------------- I've been trying to get GHC to build on ia64 for a while now, bootstrapping it with 6.8.2. I never succeeded at that with 6.10, but with 6.12.1 I thought I did. I found linker flags that apparently made the build succeed and even got the stage 3 compiler compiled so I thought that it would be ok. But now that I try to bootstrap 6.12.1 with 6.12.1, I run into trouble. The build fails when it tries to compile utils/ghc-pwd/ghc-pwd with {{{ ghc: internal error: evacuate: strange closure type 8 (GHC version 6.12.1 for ia64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug ./configure: line 2666: 28415 Aborted "$WithGhc" -v0 --make ghc-pwd -o ghc-pwd ./configure: line 2668: utils/ghc-pwd/ghc-pwd: No such file or directory }}} On another try on another computer, I saw type 15 in there. These values correspond to THUNK_STATIC and CONSTR_NOCAF_STATIC and I can see that there's no cases for those in Evac.c. Any idea about what's going on with this? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 20 10:11:40 2010 From: trac at galois.com (GHC) Date: Sat Feb 20 09:42:21 2010 Subject: [GHC] #3887: getOptions'.parseLanguage(2) went past eof token In-Reply-To: <048.ec35efc0ff206f24e97b95678340e2dc@abbot.galois.com> References: <048.ec35efc0ff206f24e97b95678340e2dc@abbot.galois.com> Message-ID: <057.1ce5e647370a8c10b593b54d3f386a58@abbot.galois.com> #3887: getOptions'.parseLanguage(2) went past eof token -------------------------+-------------------------------------------------- Reporter: osaunders | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: fixed | Keywords: Difficulty: | Os: MacOS X Testcase: | Architecture: x86 Failure: GHCi crash | -------------------------+-------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Thanks for the report. The problem is the `-X` in your LANGUAGE pragma. It should just be {{{ {-# LANGUAGE NoMonomorphismRestriction #-} }}} Happily, the bad error message is already fixed in 6.12.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 20 10:14:06 2010 From: trac at galois.com (GHC) Date: Sat Feb 20 09:44:45 2010 Subject: [GHC] #322: fromInteger-related pattern match overlap warnings In-Reply-To: <047.ace5220e5df89abf8e6e92924cc2e86b@abbot.galois.com> References: <047.ace5220e5df89abf8e6e92924cc2e86b@abbot.galois.com> Message-ID: <056.b21df0edd27e6f2cf04891bf8834535d@abbot.galois.com> #322: fromInteger-related pattern match overlap warnings ---------------------------+------------------------------------------------ Reporter: ashley-y | Owner: simonpj Type: bug | Status: assigned Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.4 Resolution: None | Keywords: warnings Difficulty: Unknown | Os: Unknown/Multiple Testcase: ds060 | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Comment(by igloo): You can't make the warning perfect, but in cases where we are not sure we have 3 choices: * warn * don't warn * give a different warning, saying that we aren't sure (this warning could be en/disabled separately) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 20 13:36:57 2010 From: trac at galois.com (GHC) Date: Sat Feb 20 13:07:36 2010 Subject: [GHC] #3773: Haddoc documentation on wrong function argument In-Reply-To: <044.635ed03af9d418169b269fce9db0718f@abbot.galois.com> References: <044.635ed03af9d418169b269fce9db0718f@abbot.galois.com> Message-ID: <053.a82e07adbed74f0a623f03f416ae9aa3@abbot.galois.com> #3773: Haddoc documentation on wrong function argument ----------------------------+----------------------------------------------- Reporter: tibbe | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.12.2 Component: Documentation | Version: 6.10.4 Resolution: fixed | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ----------------------------+----------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: I've merged the GHC HEAD haddock repo with the haddock HEAD, and pushed this patch to the GHC 6.12 branch: {{{ Thu Jan 14 18:53:18 GMT 2010 Isaac Dupree * fix html arg-doc off-by-one and silliness }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 20 17:38:27 2010 From: trac at galois.com (GHC) Date: Sat Feb 20 17:09:07 2010 Subject: [GHC] #3860: bindists should check you have a new enough make In-Reply-To: <044.a622b795cb6118a0360beec79e99efa2@abbot.galois.com> References: <044.a622b795cb6118a0360beec79e99efa2@abbot.galois.com> Message-ID: <053.caa64d62f082810e16f16de5a5d019bf@abbot.galois.com> #3860: bindists should check you have a new enough make ---------------------------+------------------------------------------------ Reporter: igloo | Owner: igloo Type: bug | Status: closed Priority: high | Milestone: 6.12.2 Component: Build System | Version: 6.12.1 Resolution: fixed | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed in HEAD and 6.12 by: {{{ Sat Feb 20 21:11:57 GMT 2010 Ian Lynagh * Check for suitable versions of make in bindists; fixes trac #3860 We already had a check in configure of the actual build. This patch adds it to the configure of the bindists too. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 21 08:10:39 2010 From: trac at galois.com (GHC) Date: Sun Feb 21 07:43:28 2010 Subject: [GHC] #2965: GHC on OS X does not compile 64-bit In-Reply-To: <045.2214e7d1fe4dd43486128c197fdb9227@abbot.galois.com> References: <045.2214e7d1fe4dd43486128c197fdb9227@abbot.galois.com> Message-ID: <054.b5213b6b1192c3c65a6255c705d573a9@abbot.galois.com> #2965: GHC on OS X does not compile 64-bit --------------------------------+------------------------------------------- Reporter: Axman6 | Owner: thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: Keywords: 64bit | Difficulty: Unknown Os: MacOS X | Testcase: Architecture: x86_64 (amd64) | Failure: None/Unknown --------------------------------+------------------------------------------- Changes (by khalsah): * cc: khalsah@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 21 11:17:08 2010 From: trac at galois.com (GHC) Date: Sun Feb 21 10:47:45 2010 Subject: [GHC] #3891: evacuate: strange closure types THUNK_STATIC and CONSTR_NOCAF_STATIC on ia64 In-Reply-To: <043.d1ba2c877f373a38174c3627ee9fb741@abbot.galois.com> References: <043.d1ba2c877f373a38174c3627ee9fb741@abbot.galois.com> Message-ID: <052.10dfc581665bc1c32b8cb6521b431088@abbot.galois.com> #3891: evacuate: strange closure types THUNK_STATIC and CONSTR_NOCAF_STATIC on ia64 -----------------------+---------------------------------------------------- Reporter: kaol | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.12.1 | Keywords: Os: Linux | Testcase: Architecture: ia64 | Failure: Compile-time crash -----------------------+---------------------------------------------------- Comment(by kaol): I did some more testing on this. Looks like LC_CTYPE triggers this bug. {{{LC_CTYPE=C inplace/bin/ghc-stage2}}} fails with the above error but {{{LC_CTYPE=fi_FI inplace/bin/ghc-stage2}}} works. I don't even need to give any arguments to it to trigger this. Using {{{--info}}} worked, with both. This is the output of -v9: {{{ Glasgow Haskell Compiler, Version 6.12.1, for Haskell 98, stage 2 booted by GHC version 6.8.2 Using binary package databaseghc-stage2: internal error: evacuate: strange closure type 15 (GHC version 6.12.1 for ia64_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 Sun Feb 21 12:29:43 2010 From: trac at galois.com (GHC) Date: Sun Feb 21 12:00:18 2010 Subject: [GHC] #3853: make tags work in the new build system In-Reply-To: <044.1c7a267759f0c130b8c8034100c59294@abbot.galois.com> References: <044.1c7a267759f0c130b8c8034100c59294@abbot.galois.com> Message-ID: <053.879fd2048f567506e349e2d610fa4e8a@abbot.galois.com> #3853: make tags work in the new build system ---------------------------+------------------------------------------------ Reporter: igloo | Owner: igloo Type: task | Status: closed Priority: normal | Milestone: 6.12 branch Component: Build System | Version: 6.12.1 Resolution: fixed | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed by: {{{ Sun Feb 21 16:44:32 GMT 2010 Ian Lynagh * Make "make tags" work in the new build system }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 21 14:14:16 2010 From: trac at galois.com (GHC) Date: Sun Feb 21 13:44:52 2010 Subject: [GHC] #3680: Improve docs for 'length' In-Reply-To: <056.32b26bd2c9b5e88047fb0bedd9442617@abbot.galois.com> References: <056.32b26bd2c9b5e88047fb0bedd9442617@abbot.galois.com> Message-ID: <065.d34187642fc86c13ee00d8e505a38d6f@abbot.galois.com> #3680: Improve docs for 'length' ----------------------------------+----------------------------------------- Reporter: daniel.is.fischer | Owner: igloo Type: feature request | Status: new Priority: high | Milestone: 6.12.2 Component: libraries/base | Version: 6.10.4 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Documentation bug ----------------------------------+----------------------------------------- Changes (by igloo): * owner: => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 21 14:46:30 2010 From: trac at galois.com (GHC) Date: Sun Feb 21 14:17:05 2010 Subject: [GHC] #3852: Building GHC 6.12.1 with Cabal 1.9.0 installed In-Reply-To: <047.f658e84343f0f5a46a74754708d40840@abbot.galois.com> References: <047.f658e84343f0f5a46a74754708d40840@abbot.galois.com> Message-ID: <056.2dad69b6f1b6f467f0c752130041fb04@abbot.galois.com> #3852: Building GHC 6.12.1 with Cabal 1.9.0 installed ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.2 Component: Build System | Version: 6.12.1 Keywords: | Difficulty: Easy (less than 1 hour) Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Building GHC failed ---------------------------------+------------------------------------------ Changes (by igloo): * cc: duncan (added) Comment: I'm having problems installing Cabal HEAD as a user with 6.8.2: {{{ $ ghc --make Setup [...] $ ./Setup configure --user --prefix=`pwd`/inst [...] $ ./Setup build -v [...] Registering Cabal-1.9.0... /usr/bin/ghc-pkg update - --global --user --package- conf=dist/package.conf.inplace Setup: Unable to rename "/usr/lib/ghc-6.8.2/package.conf" to "/usr/lib/ghc-6.8.2/package.conf.old" ghc-pkg.bin: /usr/lib/ghc-6.8.2/package.conf: renameFile: permission denied (Permission denied) }}} Duncan, any idea what's going on? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 21 15:55:57 2010 From: trac at galois.com (GHC) Date: Sun Feb 21 15:26:32 2010 Subject: [GHC] #3861: Make testing dynlibs on Windows work In-Reply-To: <044.b19a96075a430af404f6d4402b137111@abbot.galois.com> References: <044.b19a96075a430af404f6d4402b137111@abbot.galois.com> Message-ID: <053.801aacc559abc54a4fb7802e30dca85c@abbot.galois.com> #3861: Make testing dynlibs on Windows work ---------------------------+------------------------------------------------ Reporter: igloo | Owner: igloo Type: task | Status: new Priority: high | Milestone: 6.14.1 Component: Test Suite | Version: 6.12.1 Keywords: | Difficulty: Os: Windows | Testcase: Architecture: x86 | Failure: None/Unknown ---------------------------+------------------------------------------------ Changes (by igloo): * milestone: 6.12.2 => 6.14.1 Comment: #3879 is milestoned for 6.14.1, so we can't do this before then. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 21 16:02:36 2010 From: trac at galois.com (GHC) Date: Sun Feb 21 15:33:15 2010 Subject: [GHC] #3879: Enable shared libraries on Windows In-Reply-To: <044.9c60c8933d3ae7c91357b118536a70e9@abbot.galois.com> References: <044.9c60c8933d3ae7c91357b118536a70e9@abbot.galois.com> Message-ID: <053.7a805db2fd7df6f804cd0c8e7805cd7a@abbot.galois.com> #3879: Enable shared libraries on Windows ---------------------------------+------------------------------------------ Reporter: igloo | Owner: benl Type: feature request | Status: new Priority: high | Milestone: 6.14.1 Component: Compiler | Version: 6.12.1 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Changes (by igloo): * owner: => benl Comment: I needed this patch to get `rts/RtsDllMain.c` to compile: {{{ hunk ./rts/RtsDllMain.c 12 +#include "RtsDllMain.h" hunk ./rts/RtsDllMain.c 22 -DllMain ( HINSTANCE hInstance +DllMain ( HINSTANCE hInstance STG_UNUSED hunk ./rts/RtsDllMain.c 24 - , LPVOID reserved + , LPVOID reserved STG_UNUSED addfile ./rts/RtsDllMain.h hunk ./rts/RtsDllMain.h 1 + +#include "Rts.h" + +#ifdef HAVE_WINDOWS_H +#include +#endif + +/* I'd be mildly surprised if this wasn't defined, but still. */ +#if defined(__PIC__) && defined(mingw32_TARGET_OS) +BOOL +WINAPI +DllMain ( HINSTANCE hInstance + , DWORD reason + , LPVOID reserved + ); +#endif + }}} but then the build fails with: {{{ "inplace/bin/ghc-stage1.exe" -shared -dynamic -dynload deploy -no-auto- link-packages `cat rts/libs.depend` rts/dist/build/Adjustor.thr_dyn_o rts/dist/build/Arena.thr_dyn_o rts/dist/build/Capability.thr_dyn_o rts/dist/build/ClosureFlags.thr_dyn_o rts/dist/build/Disassembler.thr_dyn_o rts/dist/build/FrontPanel.thr_dyn_o rts/dist/build/Globals.thr_dyn_o rts/dist/build/Hash.thr_dyn_o rts/dist/build/Hpc.thr_dyn_o rts/dist/build/HsFFI.thr_dyn_o rts/dist/build/Inlines.thr_dyn_o rts/dist/build/Interpreter.thr_dyn_o rts/dist/build/LdvProfile.thr_dyn_o rts/dist/build/Linker.thr_dyn_o rts/dist/build/Papi.thr_dyn_o rts/dist/build/Printer.thr_dyn_o rts/dist/build/ProfHeap.thr_dyn_o rts/dist/build/Profiling.thr_dyn_o rts/dist/build/Proftimer.thr_dyn_o rts/dist/build/RaiseAsync.thr_dyn_o rts/dist/build/RetainerProfile.thr_dyn_o rts/dist/build/RetainerSet.thr_dyn_o rts/dist/build/RtsAPI.thr_dyn_o rts/dist/build/RtsDllMain.thr_dyn_o rts/dist/build/RtsFlags.thr_dyn_o rts/dist/build/RtsMain.thr_dyn_o rts/dist/build/RtsMessages.thr_dyn_o rts/dist/build/RtsStartup.thr_dyn_o rts/dist/build/RtsUtils.thr_dyn_o rts/dist/build/STM.thr_dyn_o rts/dist/build/Schedule.thr_dyn_o rts/dist/build/Sparks.thr_dyn_o rts/dist/build/Stable.thr_dyn_o rts/dist/build/Stats.thr_dyn_o rts/dist/build/StgCRun.thr_dyn_o rts/dist/build/StgPrimFloat.thr_dyn_o rts/dist/build/Task.thr_dyn_o rts/dist/build/ThreadLabels.thr_dyn_o rts/dist/build/ThreadPaused.thr_dyn_o rts/dist/build/Threads.thr_dyn_o rts/dist/build/Ticky.thr_dyn_o rts/dist/build/Timer.thr_dyn_o rts/dist/build/Trace.thr_dyn_o rts/dist/build/WSDeque.thr_dyn_o rts/dist/build/Weak.thr_dyn_o rts/dist/build/hooks/FlagDefaults.thr_dyn_o rts/dist/build/hooks/MallocFail.thr_dyn_o rts/dist/build/hooks/OnExit.thr_dyn_o rts/dist/build/hooks/OutOfHeap.thr_dyn_o rts/dist/build/hooks/RtsOpts.thr_dyn_o rts/dist/build/hooks/StackOverflow.thr_dyn_o rts/dist/build/parallel/0Hash.thr_dyn_o rts/dist/build/parallel/0Unpack.thr_dyn_o rts/dist/build/parallel/Dist.thr_dyn_o rts/dist/build/parallel/Global.thr_dyn_o rts/dist/build/parallel/GranSim.thr_dyn_o rts/dist/build/parallel/HLComms.thr_dyn_o rts/dist/build/parallel/LLComms.thr_dyn_o rts/dist/build/parallel/Pack.thr_dyn_o rts/dist/build/parallel/ParInit.thr_dyn_o rts/dist/build/parallel/ParTicky.thr_dyn_o rts/dist/build/parallel/Parallel.thr_dyn_o rts/dist/build/parallel/ParallelDebug.thr_dyn_o rts/dist/build/parallel/RBH.thr_dyn_o rts/dist/build/sm/BlockAlloc.thr_dyn_o rts/dist/build/sm/Compact.thr_dyn_o rts/dist/build/sm/Evac.thr_dyn_o rts/dist/build/sm/GC.thr_dyn_o rts/dist/build/sm/GCAux.thr_dyn_o rts/dist/build/sm/GCUtils.thr_dyn_o rts/dist/build/sm/MBlock.thr_dyn_o rts/dist/build/sm/MarkWeak.thr_dyn_o rts/dist/build/sm/Sanity.thr_dyn_o rts/dist/build/sm/Scav.thr_dyn_o rts/dist/build/sm/Storage.thr_dyn_o rts/dist/build/sm/Sweep.thr_dyn_o rts/dist/build/eventlog/EventLog.thr_dyn_o rts/dist/build/win32/AsyncIO.thr_dyn_o rts/dist/build/win32/AwaitEvent.thr_dyn_o rts/dist/build/win32/ConsoleHandler.thr_dyn_o rts/dist/build/win32/GetTime.thr_dyn_o rts/dist/build/win32/IOManager.thr_dyn_o rts/dist/build/win32/OSMem.thr_dyn_o rts/dist/build/win32/OSThreads.thr_dyn_o rts/dist/build/win32/ThrIOManager.thr_dyn_o rts/dist/build/win32/Ticker.thr_dyn_o rts/dist/build/win32/WorkQueue.thr_dyn_o rts/dist/build/win32/seh_excn.thr_dyn_o rts/dist/build/sm/Evac_thr.thr_dyn_o rts/dist/build/sm/Scav_thr.thr_dyn_o rts/dist/build/Apply.thr_dyn_o rts/dist/build/Exception.thr_dyn_o rts/dist/build/HeapStackCheck.thr_dyn_o rts/dist/build/PrimOps.thr_dyn_o rts/dist/build/StgMiscClosures.thr_dyn_o rts/dist/build/StgStartup.thr_dyn_o rts/dist/build/StgStdThunks.thr_dyn_o rts/dist/build/Updates.thr_dyn_o rts/dist/build/AutoApply.thr_dyn_o rts/dist/build/win32/libHSbase.dll.a rts/dist/build/win32/libHSghc- prim.dll.a rts/dist/build/win32/libHSffi.dll.a -o rts/dist/build /libHSrts_thr-ghc6.13.20100221.dll Creating library file: rts/dist/build/libHSrts_thr-ghc6.13.20100221.dll.a rts\dist\build\PrimOps.thr_dyn_o:fake:(.text+0x4ab): undefined reference to `_imp__sm_mutex' rts\dist\build\PrimOps.thr_dyn_o:fake:(.text+0x4cf): undefined reference to `_imp__sm_mutex' rts\dist\build\PrimOps.thr_dyn_o:fake:(.text+0x5e6): undefined reference to `_imp__sm_mutex' rts\dist\build\PrimOps.thr_dyn_o:fake:(.text+0x608): undefined reference to `_imp__sm_mutex' collect2: ld returned 1 exit status make[1]: *** [rts/dist/build/libHSrts_thr-ghc6.13.20100221.dll] Error 1 make: *** [all] Error 2 }}} Ben, any idea what's going on? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 21 19:11:47 2010 From: trac at galois.com (GHC) Date: Sun Feb 21 18:42:26 2010 Subject: [GHC] #3879: Enable shared libraries on Windows In-Reply-To: <044.9c60c8933d3ae7c91357b118536a70e9@abbot.galois.com> References: <044.9c60c8933d3ae7c91357b118536a70e9@abbot.galois.com> Message-ID: <053.99e13a9f6522b22bbe49e066797e2d06@abbot.galois.com> #3879: Enable shared libraries on Windows ---------------------------------+------------------------------------------ Reporter: igloo | Owner: benl Type: feature request | Status: new Priority: high | Milestone: 6.14.1 Component: Compiler | Version: 6.12.1 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Comment(by benl): Yes, in `rts/PrimOps.cmm` there is: {{{ import sm_mutex; }}} Because `sm_mutex` has an import statement it thinks this symbol is from some other package (dll) so is trying to use the dll's IAT (Import Address Table) to access it. However, `sm_mutex` is compiled into the rts package directly, so won't appear in the IAT, hence the undefined reference. This is a bit of a mess because for other reasons (I forget the exact details), bootstrapping via-c requires this import statement to be there. I actually added it myself a few weeks ago to fix the build on SPARC again, which was after I last built on Windows. (sigh) Adding a `#if defined(mingw32_HOST_OS)` around `import sm_mutex` should solve the problem. I've just moved house and don't have a Windows machine to test on right now, but I expect this will fix it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 21 19:23:05 2010 From: trac at galois.com (GHC) Date: Sun Feb 21 18:53:42 2010 Subject: [GHC] #3879: Enable shared libraries on Windows In-Reply-To: <044.9c60c8933d3ae7c91357b118536a70e9@abbot.galois.com> References: <044.9c60c8933d3ae7c91357b118536a70e9@abbot.galois.com> Message-ID: <053.48e4746bcdc6864128c292e6f09ffbec@abbot.galois.com> #3879: Enable shared libraries on Windows ---------------------------------+------------------------------------------ Reporter: igloo | Owner: benl Type: feature request | Status: new Priority: high | Milestone: 6.14.1 Component: Compiler | Version: 6.12.1 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Comment(by benl): I mean `#if !defined(mingw32_HOST_OS)` I recall that the problem with bootstrapping via-c was that without the import statement, no C-level prototype for this variable is emitted, and it's not imported via `Cmm.h`. If you add the above `#ifdef` and then try to boot the compiler via-c on windows it'll probably die. It'll still work with the NCG though. I don't have a better solution ATM. Note that `sm_mutex` is actually defined (for real) in `rts/sm/Storage.c` -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 21 21:49:54 2010 From: trac at galois.com (GHC) Date: Sun Feb 21 21:20:29 2010 Subject: [GHC] #3892: some libraries work with runghc but not ghc Message-ID: <048.4ace4dabfed751f50a9c2d73c7117ed6@abbot.galois.com> #3892: some libraries work with runghc but not ghc --------------------------+------------------------------------------------- Reporter: dougbrown | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Keywords: Os: MacOS X | Testcase: Architecture: x86 | Failure: GHC rejects valid program --------------------------+------------------------------------------------- Symptom: Code using some libraries (e.g. array, complex, list) works interpretted (runghc) and compiled (ghc). Code using some other libraries (e.g. graph, intset, map, set, tree) works interpretted, but has undefined symbols when compiled with ghc. ghc and platform are installed on a mac mini running snow leopard from haskell-platform-2009.2.0.2-i386.dmg. -optc-m32 -opta-m32 -optl-m32 are inserted into /Library/Frameworks/GHC.framework/Versions/Current/usr/bin/ghc-6.10.4. Example working: > cat testarray.hs import Data.Array main :: IO () main = do putStrLn $ show $ array (1,3) [(1,"one"),(2,"two"),(3,"three")] > runghc testarray.hs array (1,3) [(1,"one"),(2,"two"),(3,"three")] > ghc testarray.hs > ./a.out array (1,3) [(1,"one"),(2,"two"),(3,"three")] Example failure: > cat testset.hs import Data.Set as Set main :: IO () main = do putStrLn $ show $ Set.fromList [3..5] > runghc testset.hs fromList [3,4,5] > ghc testset.hs Undefined symbols: "_containerszm0zi2zi0zi1_DataziSet_fromList_closure", referenced from: _rBM_info in testset.o _rBM_srt in testset.o "_containerszm0zi2zi0zi1_DataziSet_zdf3_closure", referenced from: _rBK_info in testset.o _rBK_srt in testset.o "___stginit_containerszm0zi2zi0zi1_DataziSet_", referenced from: ___stginit_Main_ in testset.o ld: symbol(s) not found collect2: ld returned 1 exit status Some other info: ghc -v shows it loading these libraries: -L/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.4 -L/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.4/array-0.2.0.0 -L/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.4/base-4.1.0.0 -L/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.4/directory-1.0.0.3 -L/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.4/filepath-1.1.0.2 -L/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.4/ghc- prim-0.1.0.0 -L/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.4/haskell98-1.0.1.0 -L/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.4/integer-0.1.0.1 -L/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.4/old- locale-1.0.0.1 -L/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.4/old- time-1.0.0.2 -L/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.4/process-1.0.1.1 -L/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.4/random-1.0.0.1 -L/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.4/syb-0.1.0.1 -L/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.4/unix-2.3.2.0 Now we're getting outside my area of expertise... It looks to me like the working libraries are in array and base, which ARE loaded by ghc, and the failing libraries are in /Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.4/containers-0.2.0.1 which is NOT loaded by ghc. I tried to work around it with ghc -L/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.4/containers-0.2.0.1 testset.hs and it did NOT work. It looks to me like all the .a files contain code for the correct architecture. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 22 03:08:40 2010 From: trac at galois.com (GHC) Date: Mon Feb 22 02:39:18 2010 Subject: [GHC] #3875: DPH QuickHull example crashes on SPARC with -N > 1 In-Reply-To: <043.48127cd9f809a0bcf184a76857f65e8a@abbot.galois.com> References: <043.48127cd9f809a0bcf184a76857f65e8a@abbot.galois.com> Message-ID: <052.043b5e25ff328913b1754e932ac3fced@abbot.galois.com> #3875: DPH QuickHull example crashes on SPARC with -N > 1 -----------------------------+---------------------------------------------- Reporter: benl | Owner: benl Type: bug | Status: closed Priority: high | Milestone: 6.12.2 Component: Runtime System | Version: 6.13 Resolution: fixed | Keywords: Difficulty: | Os: Solaris Testcase: | Architecture: sparc Failure: Runtime crash | -----------------------------+---------------------------------------------- Changes (by benl): * status: assigned => closed * resolution: => fixed Comment: {{{ Sun Feb 21 19:16:27 PST 2010 Ben.Lippmeier@anu.edu.au * Fix #3875: Crash in parallel GC, wrong pointer was being tested. M ./rts/sm/Evac.c -1 +1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 22 03:39:06 2010 From: trac at galois.com (GHC) Date: Mon Feb 22 03:09:38 2010 Subject: [GHC] #3828: Error in array index In-Reply-To: <042.183a30ca9d84f0b1998a7b985bfd6d87@abbot.galois.com> References: <042.183a30ca9d84f0b1998a7b985bfd6d87@abbot.galois.com> Message-ID: <051.d14db80f133ec2e55384315359eacf3f@abbot.galois.com> #3828: Error in array index -------------------------+-------------------------------------------------- Reporter: CBa | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.12.1 Keywords: sunos | Difficulty: Os: Solaris | Testcase: Architecture: sparc | Failure: Compile-time crash -------------------------+-------------------------------------------------- Comment(by simonpj): Make sure there are no old .hi files lying around, or start in a completely clean tree. GHC 6.8 gave this kind of error if it found a .hi file written by a different version of GHC. (Since improved.) Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 22 05:48:27 2010 From: trac at galois.com (GHC) Date: Mon Feb 22 05:19:02 2010 Subject: [GHC] #3893: GHC on Windows lacks C++ support Message-ID: <051.81a9ee5b2b7c5a4a4d6cf6b90f475163@abbot.galois.com> #3893: GHC on Windows lacks C++ support ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.12.1 | Keywords: Os: Windows | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ In GHC 6.10 support was added to the Windows distribution for building C++. In GHC 6.12 a key library to make this support work was removed, probably be accident. The missing file is {{C:\ghc\ghc-6.12.1\mingw\lib\libstdc++.a}}, which I have solved by copying the file from {{C:\ghc\ghc-6.10.4\gcc-lib}}. It would be best if the correct file was copied from the right Mingw release. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 22 07:58:04 2010 From: trac at galois.com (GHC) Date: Mon Feb 22 07:28:40 2010 Subject: [GHC] #3892: some libraries work with runghc but not ghc In-Reply-To: <048.4ace4dabfed751f50a9c2d73c7117ed6@abbot.galois.com> References: <048.4ace4dabfed751f50a9c2d73c7117ed6@abbot.galois.com> Message-ID: <057.699ef62394004db239c3dee820affab4@abbot.galois.com> #3892: some libraries work with runghc but not ghc ----------------------------------------+----------------------------------- Reporter: dougbrown | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: invalid | Keywords: Difficulty: | Os: MacOS X Testcase: | Architecture: x86 Failure: GHC rejects valid program | ----------------------------------------+----------------------------------- Changes (by simonmar): * status: new => closed * resolution: => invalid Comment: When using `ghc` you need to either use `--make` to have packages automatically linked in, or pass `-package` options for the packages that you use. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 22 07:59:16 2010 From: trac at galois.com (GHC) Date: Mon Feb 22 07:29:53 2010 Subject: [GHC] #3875: DPH QuickHull example crashes on SPARC with -N > 1 In-Reply-To: <043.48127cd9f809a0bcf184a76857f65e8a@abbot.galois.com> References: <043.48127cd9f809a0bcf184a76857f65e8a@abbot.galois.com> Message-ID: <052.ae376c724e0fdf50a5fc6823e8732eb5@abbot.galois.com> #3875: DPH QuickHull example crashes on SPARC with -N > 1 -----------------------------+---------------------------------------------- Reporter: benl | Owner: benl Type: merge | Status: reopened Priority: high | Milestone: 6.12.2 Component: Runtime System | Version: 6.13 Resolution: | Keywords: Difficulty: | Os: Solaris Testcase: | Architecture: sparc Failure: Runtime crash | -----------------------------+---------------------------------------------- Changes (by simonmar): * status: closed => reopened * type: bug => merge * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 22 07:59:28 2010 From: trac at galois.com (GHC) Date: Mon Feb 22 07:30:07 2010 Subject: [GHC] #3875: DPH QuickHull example crashes on SPARC with -N > 1 In-Reply-To: <043.48127cd9f809a0bcf184a76857f65e8a@abbot.galois.com> References: <043.48127cd9f809a0bcf184a76857f65e8a@abbot.galois.com> Message-ID: <052.a1ac6320010f8eed42058f4875966631@abbot.galois.com> #3875: DPH QuickHull example crashes on SPARC with -N > 1 -----------------------------+---------------------------------------------- Reporter: benl | Owner: igloo Type: merge | Status: new Priority: high | Milestone: 6.12.2 Component: Runtime System | Version: 6.13 Resolution: | Keywords: Difficulty: | Os: Solaris Testcase: | Architecture: sparc Failure: Runtime crash | -----------------------------+---------------------------------------------- Changes (by simonmar): * owner: benl => igloo * status: reopened => new -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 22 08:06:49 2010 From: trac at galois.com (GHC) Date: Mon Feb 22 07:37:22 2010 Subject: [GHC] #3828: Error in array index In-Reply-To: <042.183a30ca9d84f0b1998a7b985bfd6d87@abbot.galois.com> References: <042.183a30ca9d84f0b1998a7b985bfd6d87@abbot.galois.com> Message-ID: <051.3f7db36b845993f045531b30b568ace1@abbot.galois.com> #3828: Error in array index -------------------------+-------------------------------------------------- Reporter: CBa | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.12.1 Keywords: sunos | Difficulty: Os: Solaris | Testcase: Architecture: sparc | Failure: Compile-time crash -------------------------+-------------------------------------------------- Comment(by simonmar): Replying to [comment:5 simonpj]: > GHC 6.8 gave this kind of error if it found a .hi file written by a different version of GHC. (Since improved.) I don't think that's it - here's the code that checks hi file versions in GHC 6.8: {{{ let our_ver = show opt_HiVersion when (check_ver /= our_ver) $ -- This will be caught by readIface which will emit an error -- msg containing the iface module name. throwDyn (ProgramError ( "mismatched interface file versions: expected " ++ our_ver ++ ", found " ++ check_ver)) }}} In fact, GHC has checked hi file versions since 6.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 22 10:21:25 2010 From: trac at galois.com (GHC) Date: Mon Feb 22 09:51:58 2010 Subject: [GHC] #3894: UnicodeSyntax ellipsis character Message-ID: <052.fcffdb71337a0152c9f16660dc875a0f@abbot.galois.com> #3894: UnicodeSyntax ellipsis character ---------------------------------+------------------------------------------ Reporter: Roel van Dijk | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.12.1 | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Other ---------------------------------+------------------------------------------ The !UnicodeSyntax extension allows the "?" character to be used instead of "..". I think this is wrong. It should be the "?" character. The [http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax- extns.html#unicode-syntax documentation] for !UnicodeSyntax says two conflicting things about "..". For the Unicode alternative it shows the expected HORIZONTAL ELLIPSES character, but both the code point and the name refer to the MIDLINE variant. GHC only accepts code that uses the MIDLINE variant. This leaves two options: 1. Fix the documentation to show the "?" MIDLINE variant under the Unicode variant column. 2. Change the ellipses alternative to "?" (U+2026) instead of "?" (U+22EF). I personally prefer option 2. But [http://en.wikipedia.org/wiki/Ellipsis#Computer_representations according to Wikipedia] the "?" character is for general use while the "?" character is for use in mathematics. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 22 10:43:41 2010 From: trac at galois.com (GHC) Date: Mon Feb 22 10:14:14 2010 Subject: [GHC] #3894: UnicodeSyntax ellipsis character In-Reply-To: <052.fcffdb71337a0152c9f16660dc875a0f@abbot.galois.com> References: <052.fcffdb71337a0152c9f16660dc875a0f@abbot.galois.com> Message-ID: <061.c7d4d68277ba0e0c81ef41af8a5d8e5d@abbot.galois.com> #3894: UnicodeSyntax ellipsis character ---------------------------------+------------------------------------------ Reporter: Roel van Dijk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.12.1 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Other ---------------------------------+------------------------------------------ Comment(by igloo): Wouldn't "U+2025 TWO DOT LEADER" be a better choice? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 22 11:02:41 2010 From: trac at galois.com (GHC) Date: Mon Feb 22 10:33:15 2010 Subject: [GHC] #3894: UnicodeSyntax ellipsis character In-Reply-To: <052.fcffdb71337a0152c9f16660dc875a0f@abbot.galois.com> References: <052.fcffdb71337a0152c9f16660dc875a0f@abbot.galois.com> Message-ID: <061.a2276b78effeb3147d1c318524127dc4@abbot.galois.com> #3894: UnicodeSyntax ellipsis character ---------------------------------+------------------------------------------ Reporter: Roel van Dijk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.12.1 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Other ---------------------------------+------------------------------------------ Comment(by Roel van Dijk): Replying to [comment:1 igloo]: > Wouldn't "U+2025 TWO DOT LEADER" be a better choice? It certainly looks nice. But I think semantically an ellipsis is a more logical choice. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 22 11:44:11 2010 From: trac at galois.com (GHC) Date: Mon Feb 22 11:14:43 2010 Subject: [GHC] #3893: GHC on Windows lacks C++ support In-Reply-To: <051.81a9ee5b2b7c5a4a4d6cf6b90f475163@abbot.galois.com> References: <051.81a9ee5b2b7c5a4a4d6cf6b90f475163@abbot.galois.com> Message-ID: <060.b0d2dc6f44b9e7c339a3a346ee1d2a9a@abbot.galois.com> #3893: GHC on Windows lacks C++ support ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.12.1 | Keywords: Os: Windows | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Changes (by NeilMitchell): * cc: ndmitchell@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 22 13:59:16 2010 From: trac at galois.com (GHC) Date: Mon Feb 22 13:29:55 2010 Subject: [GHC] #3879: Enable shared libraries on Windows In-Reply-To: <044.9c60c8933d3ae7c91357b118536a70e9@abbot.galois.com> References: <044.9c60c8933d3ae7c91357b118536a70e9@abbot.galois.com> Message-ID: <053.11886ddebb49ce06a38978ed661bb2f5@abbot.galois.com> #3879: Enable shared libraries on Windows ---------------------------------+------------------------------------------ Reporter: igloo | Owner: benl Type: feature request | Status: new Priority: high | Milestone: 6.14.1 Component: Compiler | Version: 6.12.1 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Comment(by igloo): Thanks! Hrmm, with that fixed ld runs out of memory for me when running {{{ "inplace/bin/ghc-stage1.exe" compiler/stage2/build/AsmCodeGen.dyn_o compiler/stage2/build/TargetReg.dyn_o compiler/stage2/build/NCGMonad.dyn_o compiler/stage2/build/Instruction.dyn_o compiler/stage2/build/Size.dyn_o compiler/stage2/build/Reg.dyn_o compiler/stage2/build/RegClass.dyn_o compiler/stage2/build/PprBase.dyn_o compiler/stage2/build/PIC.dyn_o compiler/stage2/build/Platform.dyn_o compiler/stage2/build/Alpha/Regs.dyn_o compiler/stage2/build/Alpha/RegInfo.dyn_o compiler/stage2/build/Alpha/Instr.dyn_o compiler/stage2/build/Alpha/CodeGen.dyn_o compiler/stage2/build/X86/Regs.dyn_o compiler/stage2/build/X86/RegInfo.dyn_o compiler/stage2/build/X86/Instr.dyn_o compiler/stage2/build/X86/Cond.dyn_o compiler/stage2/build/X86/Ppr.dyn_o compiler/stage2/build/X86/CodeGen.dyn_o compiler/stage2/build/PPC/Regs.dyn_o compiler/stage2/build/PPC/RegInfo.dyn_o compiler/stage2/build/PPC/Instr.dyn_o compiler/stage2/build/PPC/Cond.dyn_o compiler/stage2/build/PPC/Ppr.dyn_o compiler/stage2/build/PPC/CodeGen.dyn_o compiler/stage2/build/SPARC/Base.dyn_o compiler/stage2/build/SPARC/Regs.dyn_o compiler/stage2/build/SPARC/RegPlate.dyn_o compiler/stage2/build/SPARC/Imm.dyn_o compiler/stage2/build/SPARC/AddrMode.dyn_o compiler/stage2/build/SPARC/Cond.dyn_o compiler/stage2/build/SPARC/Instr.dyn_o compiler/stage2/build/SPARC/Stack.dyn_o compiler/stage2/build/SPARC/ShortcutJump.dyn_o compiler/stage2/build/SPARC/Ppr.dyn_o compiler/stage2/build/SPARC/CodeGen.dyn_o compiler/stage2/build/SPARC/CodeGen/Amode.dyn_o compiler/stage2/build/SPARC/CodeGen/Base.dyn_o compiler/stage2/build/SPARC/CodeGen/CCall.dyn_o compiler/stage2/build/SPARC/CodeGen/CondCode.dyn_o compiler/stage2/build/SPARC/CodeGen/Gen32.dyn_o compiler/stage2/build/SPARC/CodeGen/Gen64.dyn_o compiler/stage2/build/SPARC/CodeGen/Sanity.dyn_o compiler/stage2/build/SPARC/CodeGen/Expand.dyn_o compiler/stage2/build/RegAlloc/Liveness.dyn_o compiler/stage2/build/RegAlloc/Graph/Main.dyn_o compiler/stage2/build/RegAlloc/Graph/Stats.dyn_o compiler/stage2/build/RegAlloc/Graph/ArchBase.dyn_o compiler/stage2/build/RegAlloc/Graph/ArchX86.dyn_o compiler/stage2/build/RegAlloc/Graph/Coalesce.dyn_o compiler/stage2/build/RegAlloc/Graph/Spill.dyn_o compiler/stage2/build/RegAlloc/Graph/SpillClean.dyn_o compiler/stage2/build/RegAlloc/Graph/SpillCost.dyn_o compiler/stage2/build/RegAlloc/Graph/TrivColorable.dyn_o compiler/stage2/build/RegAlloc/Linear/Main.dyn_o compiler/stage2/build/RegAlloc/Linear/JoinToTargets.dyn_o compiler/stage2/build/RegAlloc/Linear/State.dyn_o compiler/stage2/build/RegAlloc/Linear/Stats.dyn_o compiler/stage2/build/RegAlloc/Linear/FreeRegs.dyn_o compiler/stage2/build/RegAlloc/Linear/StackMap.dyn_o compiler/stage2/build/RegAlloc/Linear/Base.dyn_o compiler/stage2/build/RegAlloc/Linear/X86/FreeRegs.dyn_o compiler/stage2/build/RegAlloc/Linear/PPC/FreeRegs.dyn_o compiler/stage2/build/RegAlloc/Linear/SPARC/FreeRegs.dyn_o compiler/stage2/build/DsMeta.dyn_o compiler/stage2/build/TcSplice.dyn_o compiler/stage2/build/Convert.dyn_o compiler/stage2/build/ByteCodeAsm.dyn_o compiler/stage2/build/ByteCodeFFI.dyn_o compiler/stage2/build/ByteCodeGen.dyn_o compiler/stage2/build/ByteCodeInstr.dyn_o compiler/stage2/build/ByteCodeItbls.dyn_o compiler/stage2/build/ByteCodeLink.dyn_o compiler/stage2/build/Debugger.dyn_o compiler/stage2/build/LibFFI.dyn_o compiler/stage2/build/Linker.dyn_o compiler/stage2/build/ObjLink.dyn_o compiler/stage2/build/RtClosureInspect.dyn_o compiler/stage2/build/BasicTypes.dyn_o compiler/stage2/build/DataCon.dyn_o compiler/stage2/build/Demand.dyn_o compiler/stage2/build/Exception.dyn_o compiler/stage2/build/Id.dyn_o compiler/stage2/build/IdInfo.dyn_o compiler/stage2/build/Literal.dyn_o compiler/stage2/build/MkId.dyn_o compiler/stage2/build/Module.dyn_o compiler/stage2/build/Name.dyn_o compiler/stage2/build/NameEnv.dyn_o compiler/stage2/build/NameSet.dyn_o compiler/stage2/build/OccName.dyn_o compiler/stage2/build/RdrName.dyn_o compiler/stage2/build/SrcLoc.dyn_o compiler/stage2/build/UniqSupply.dyn_o compiler/stage2/build/Unique.dyn_o compiler/stage2/build/Var.dyn_o compiler/stage2/build/VarEnv.dyn_o compiler/stage2/build/VarSet.dyn_o compiler/stage2/build/BlockId.dyn_o compiler/stage2/build/CLabel.dyn_o compiler/stage2/build/Cmm.dyn_o compiler/stage2/build/CmmBrokenBlock.dyn_o compiler/stage2/build/CmmBuildInfoTables.dyn_o compiler/stage2/build/CmmCPS.dyn_o compiler/stage2/build/CmmCPSGen.dyn_o compiler/stage2/build/CmmCPSZ.dyn_o compiler/stage2/build/CmmCallConv.dyn_o compiler/stage2/build/CmmCommonBlockElimZ.dyn_o compiler/stage2/build/CmmContFlowOpt.dyn_o compiler/stage2/build/CmmCvt.dyn_o compiler/stage2/build/CmmExpr.dyn_o compiler/stage2/build/CmmInfo.dyn_o compiler/stage2/build/CmmLex.dyn_o compiler/stage2/build/CmmLint.dyn_o compiler/stage2/build/CmmLive.dyn_o compiler/stage2/build/CmmLiveZ.dyn_o compiler/stage2/build/CmmOpt.dyn_o compiler/stage2/build/CmmParse.dyn_o compiler/stage2/build/CmmProcPoint.dyn_o compiler/stage2/build/CmmProcPointZ.dyn_o compiler/stage2/build/CmmSpillReload.dyn_o compiler/stage2/build/CmmStackLayout.dyn_o compiler/stage2/build/CmmTx.dyn_o compiler/stage2/build/CmmUtils.dyn_o compiler/stage2/build/CmmZipUtil.dyn_o compiler/stage2/build/DFMonad.dyn_o compiler/stage2/build/Dataflow.dyn_o compiler/stage2/build/MkZipCfg.dyn_o compiler/stage2/build/MkZipCfgCmm.dyn_o compiler/stage2/build/OptimizationFuel.dyn_o compiler/stage2/build/PprC.dyn_o compiler/stage2/build/PprCmm.dyn_o compiler/stage2/build/PprCmmZ.dyn_o compiler/stage2/build/StackColor.dyn_o compiler/stage2/build/StackPlacements.dyn_o compiler/stage2/build/ZipCfg.dyn_o compiler/stage2/build/ZipCfgCmmRep.dyn_o compiler/stage2/build/ZipCfgExtras.dyn_o compiler/stage2/build/ZipDataflow.dyn_o compiler/stage2/build/Bitmap.dyn_o compiler/stage2/build/CgBindery.dyn_o compiler/stage2/build/CgCallConv.dyn_o compiler/stage2/build/CgCase.dyn_o compiler/stage2/build/CgClosure.dyn_o compiler/stage2/build/CgCon.dyn_o compiler/stage2/build/CgExpr.dyn_o compiler/stage2/build/CgExtCode.dyn_o compiler/stage2/build/CgForeignCall.dyn_o compiler/stage2/build/CgHeapery.dyn_o compiler/stage2/build/CgHpc.dyn_o compiler/stage2/build/CgInfoTbls.dyn_o compiler/stage2/build/CgLetNoEscape.dyn_o compiler/stage2/build/CgMonad.dyn_o compiler/stage2/build/CgParallel.dyn_o compiler/stage2/build/CgPrimOp.dyn_o compiler/stage2/build/CgProf.dyn_o compiler/stage2/build/CgStackery.dyn_o compiler/stage2/build/CgTailCall.dyn_o compiler/stage2/build/CgTicky.dyn_o compiler/stage2/build/CgUtils.dyn_o compiler/stage2/build/StgCmm.dyn_o compiler/stage2/build/StgCmmBind.dyn_o compiler/stage2/build/StgCmmClosure.dyn_o compiler/stage2/build/StgCmmCon.dyn_o compiler/stage2/build/StgCmmEnv.dyn_o compiler/stage2/build/StgCmmExpr.dyn_o compiler/stage2/build/StgCmmForeign.dyn_o compiler/stage2/build/StgCmmGran.dyn_o compiler/stage2/build/StgCmmHeap.dyn_o compiler/stage2/build/StgCmmHpc.dyn_o compiler/stage2/build/StgCmmLayout.dyn_o compiler/stage2/build/StgCmmMonad.dyn_o compiler/stage2/build/StgCmmPrim.dyn_o compiler/stage2/build/StgCmmProf.dyn_o compiler/stage2/build/StgCmmTicky.dyn_o compiler/stage2/build/StgCmmUtils.dyn_o compiler/stage2/build/ClosureInfo.dyn_o compiler/stage2/build/CodeGen.dyn_o compiler/stage2/build/SMRep.dyn_o compiler/stage2/build/CoreArity.dyn_o compiler/stage2/build/CoreFVs.dyn_o compiler/stage2/build/CoreLint.dyn_o compiler/stage2/build/CorePrep.dyn_o compiler/stage2/build/CoreSubst.dyn_o compiler/stage2/build/CoreSyn.dyn_o compiler/stage2/build/CoreTidy.dyn_o compiler/stage2/build/CoreUnfold.dyn_o compiler/stage2/build/CoreUtils.dyn_o compiler/stage2/build/ExternalCore.dyn_o compiler/stage2/build/MkCore.dyn_o compiler/stage2/build/MkExternalCore.dyn_o compiler/stage2/build/PprCore.dyn_o compiler/stage2/build/PprExternalCore.dyn_o compiler/stage2/build/Check.dyn_o compiler/stage2/build/Coverage.dyn_o compiler/stage2/build/Desugar.dyn_o compiler/stage2/build/DsArrows.dyn_o compiler/stage2/build/DsBinds.dyn_o compiler/stage2/build/DsCCall.dyn_o compiler/stage2/build/DsExpr.dyn_o compiler/stage2/build/DsForeign.dyn_o compiler/stage2/build/DsGRHSs.dyn_o compiler/stage2/build/DsListComp.dyn_o compiler/stage2/build/DsMonad.dyn_o compiler/stage2/build/DsUtils.dyn_o compiler/stage2/build/Match.dyn_o compiler/stage2/build/MatchCon.dyn_o compiler/stage2/build/MatchLit.dyn_o compiler/stage2/build/HsBinds.dyn_o compiler/stage2/build/HsDecls.dyn_o compiler/stage2/build/HsDoc.dyn_o compiler/stage2/build/HsExpr.dyn_o compiler/stage2/build/HsImpExp.dyn_o compiler/stage2/build/HsLit.dyn_o compiler/stage2/build/HsPat.dyn_o compiler/stage2/build/HsSyn.dyn_o compiler/stage2/build/HsTypes.dyn_o compiler/stage2/build/HsUtils.dyn_o compiler/stage2/build/BinIface.dyn_o compiler/stage2/build/BuildTyCl.dyn_o compiler/stage2/build/IfaceEnv.dyn_o compiler/stage2/build/IfaceSyn.dyn_o compiler/stage2/build/IfaceType.dyn_o compiler/stage2/build/LoadIface.dyn_o compiler/stage2/build/MkIface.dyn_o compiler/stage2/build/TcIface.dyn_o compiler/stage2/build/Annotations.dyn_o compiler/stage2/build/BreakArray.dyn_o compiler/stage2/build/CmdLineParser.dyn_o compiler/stage2/build/CodeOutput.dyn_o compiler/stage2/build/Config.dyn_o compiler/stage2/build/Constants.dyn_o compiler/stage2/build/DriverMkDepend.dyn_o compiler/stage2/build/DriverPhases.dyn_o compiler/stage2/build/DriverPipeline.dyn_o compiler/stage2/build/DynFlags.dyn_o compiler/stage2/build/ErrUtils.dyn_o compiler/stage2/build/Finder.dyn_o compiler/stage2/build/GHC.dyn_o compiler/stage2/build/HeaderInfo.dyn_o compiler/stage2/build/HscMain.dyn_o compiler/stage2/build/HscStats.dyn_o compiler/stage2/build/HscTypes.dyn_o compiler/stage2/build/InteractiveEval.dyn_o compiler/stage2/build/PackageConfig.dyn_o compiler/stage2/build/Packages.dyn_o compiler/stage2/build/PprTyThing.dyn_o compiler/stage2/build/StaticFlags.dyn_o compiler/stage2/build/StaticFlagParser.dyn_o compiler/stage2/build/SysTools.dyn_o compiler/stage2/build/TidyPgm.dyn_o compiler/stage2/build/Ctype.dyn_o compiler/stage2/build/HaddockUtils.dyn_o compiler/stage2/build/LexCore.dyn_o compiler/stage2/build/Lexer.dyn_o compiler/stage2/build/OptCoercion.dyn_o compiler/stage2/build/Parser.dyn_o compiler/stage2/build/ParserCore.dyn_o compiler/stage2/build/ParserCoreUtils.dyn_o compiler/stage2/build/RdrHsSyn.dyn_o compiler/stage2/build/ForeignCall.dyn_o compiler/stage2/build/PrelInfo.dyn_o compiler/stage2/build/PrelNames.dyn_o compiler/stage2/build/PrelRules.dyn_o compiler/stage2/build/PrimOp.dyn_o compiler/stage2/build/TysPrim.dyn_o compiler/stage2/build/TysWiredIn.dyn_o compiler/stage2/build/CostCentre.dyn_o compiler/stage2/build/SCCfinal.dyn_o compiler/stage2/build/RnBinds.dyn_o compiler/stage2/build/RnEnv.dyn_o compiler/stage2/build/RnExpr.dyn_o compiler/stage2/build/RnHsDoc.dyn_o compiler/stage2/build/RnHsSyn.dyn_o compiler/stage2/build/RnNames.dyn_o compiler/stage2/build/RnPat.dyn_o compiler/stage2/build/RnSource.dyn_o compiler/stage2/build/RnTypes.dyn_o compiler/stage2/build/CoreMonad.dyn_o compiler/stage2/build/CSE.dyn_o compiler/stage2/build/FloatIn.dyn_o compiler/stage2/build/FloatOut.dyn_o compiler/stage2/build/LiberateCase.dyn_o compiler/stage2/build/OccurAnal.dyn_o compiler/stage2/build/SAT.dyn_o compiler/stage2/build/SetLevels.dyn_o compiler/stage2/build/SimplCore.dyn_o compiler/stage2/build/SimplEnv.dyn_o compiler/stage2/build/SimplMonad.dyn_o compiler/stage2/build/SimplUtils.dyn_o compiler/stage2/build/Simplify.dyn_o compiler/stage2/build/SRT.dyn_o compiler/stage2/build/SimplStg.dyn_o compiler/stage2/build/StgStats.dyn_o compiler/stage2/build/Rules.dyn_o compiler/stage2/build/SpecConstr.dyn_o compiler/stage2/build/Specialise.dyn_o compiler/stage2/build/CoreToStg.dyn_o compiler/stage2/build/StgLint.dyn_o compiler/stage2/build/StgSyn.dyn_o compiler/stage2/build/DmdAnal.dyn_o compiler/stage2/build/WorkWrap.dyn_o compiler/stage2/build/WwLib.dyn_o compiler/stage2/build/FamInst.dyn_o compiler/stage2/build/Inst.dyn_o compiler/stage2/build/TcAnnotations.dyn_o compiler/stage2/build/TcArrows.dyn_o compiler/stage2/build/TcBinds.dyn_o compiler/stage2/build/TcClassDcl.dyn_o compiler/stage2/build/TcDefaults.dyn_o compiler/stage2/build/TcDeriv.dyn_o compiler/stage2/build/TcEnv.dyn_o compiler/stage2/build/TcExpr.dyn_o compiler/stage2/build/TcForeign.dyn_o compiler/stage2/build/TcGenDeriv.dyn_o compiler/stage2/build/TcHsSyn.dyn_o compiler/stage2/build/TcHsType.dyn_o compiler/stage2/build/TcInstDcls.dyn_o compiler/stage2/build/TcMType.dyn_o compiler/stage2/build/TcMatches.dyn_o compiler/stage2/build/TcPat.dyn_o compiler/stage2/build/TcRnDriver.dyn_o compiler/stage2/build/TcRnMonad.dyn_o compiler/stage2/build/TcRnTypes.dyn_o compiler/stage2/build/TcRules.dyn_o compiler/stage2/build/TcSimplify.dyn_o compiler/stage2/build/TcTyClsDecls.dyn_o compiler/stage2/build/TcTyDecls.dyn_o compiler/stage2/build/TcTyFuns.dyn_o compiler/stage2/build/TcType.dyn_o compiler/stage2/build/TcUnify.dyn_o compiler/stage2/build/Class.dyn_o compiler/stage2/build/Coercion.dyn_o compiler/stage2/build/FamInstEnv.dyn_o compiler/stage2/build/FunDeps.dyn_o compiler/stage2/build/Generics.dyn_o compiler/stage2/build/InstEnv.dyn_o compiler/stage2/build/TyCon.dyn_o compiler/stage2/build/Type.dyn_o compiler/stage2/build/TypeRep.dyn_o compiler/stage2/build/Unify.dyn_o compiler/stage2/build/Bag.dyn_o compiler/stage2/build/Binary.dyn_o compiler/stage2/build/BufWrite.dyn_o compiler/stage2/build/Digraph.dyn_o compiler/stage2/build/Encoding.dyn_o compiler/stage2/build/FastBool.dyn_o compiler/stage2/build/FastFunctions.dyn_o compiler/stage2/build/FastMutInt.dyn_o compiler/stage2/build/FastString.dyn_o compiler/stage2/build/FastTypes.dyn_o compiler/stage2/build/Fingerprint.dyn_o compiler/stage2/build/FiniteMap.dyn_o compiler/stage2/build/GraphBase.dyn_o compiler/stage2/build/GraphColor.dyn_o compiler/stage2/build/GraphOps.dyn_o compiler/stage2/build/GraphPpr.dyn_o compiler/stage2/build/IOEnv.dyn_o compiler/stage2/build/Interval.dyn_o compiler/stage2/build/LazyUniqFM.dyn_o compiler/stage2/build/ListSetOps.dyn_o compiler/stage2/build/Maybes.dyn_o compiler/stage2/build/MonadUtils.dyn_o compiler/stage2/build/OrdList.dyn_o compiler/stage2/build/Outputable.dyn_o compiler/stage2/build/Panic.dyn_o compiler/stage2/build/Pretty.dyn_o compiler/stage2/build/Serialized.dyn_o compiler/stage2/build/State.dyn_o compiler/stage2/build/StringBuffer.dyn_o compiler/stage2/build/UniqFM.dyn_o compiler/stage2/build/UniqSet.dyn_o compiler/stage2/build/Util.dyn_o compiler/stage2/build/VectBuiltIn.dyn_o compiler/stage2/build/VectCore.dyn_o compiler/stage2/build/VectMonad.dyn_o compiler/stage2/build/VectType.dyn_o compiler/stage2/build/VectUtils.dyn_o compiler/stage2/build/Vectorise.dyn_o compiler/stage2/build/ghci/keepCAFsForGHCi.dyn_o compiler/stage2/build/parser/cutils.dyn_o compiler/stage2/build/utils/md5.dyn_o `/bin/find compiler/stage2/build -name "*_stub.dyn_o" -print` -shared -dynamic -dynload deploy -no-auto- link-packages -packageCabal-1.9.0 -packageWin32-2.2.0.1 -packagearray-0.3.0.0 -packagebase-4.2.0.0 -packagebin-package-db-0.0.0.0 -packagebytestring-0.9.1.5 -packagecontainers-0.3.0.0 -packagedirectory-1.0.1.0 -packagefilepath-1.1.0.4 -packagehpc-0.5.0.5 -packageold-time-1.0.0.4 -packageprocess-1.0.1.2 -packagetemplate- haskell-2.4.0.0 -o compiler/stage2/build/libHSghc-6.13.20100221-ghc6.13.20100221.dll Creating library file: compiler/stage2/build/libHSghc-6.13.20100221-ghc6.13.20100221.dll.a collect2: ld returned 5 exit status make[1]: *** [compiler/stage2/build/libHSghc-6.13.20100221-ghc6.13.20100221.dll] Error 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 22 15:51:29 2010 From: trac at galois.com (GHC) Date: Mon Feb 22 15:22:00 2010 Subject: [GHC] #3895: "Fix" pervasive-but-unnecessary signedness in GHC.Prim Message-ID: <046.89d6c3ac2947a1d102181bfa68b75b22@abbot.galois.com> #3895: "Fix" pervasive-but-unnecessary signedness in GHC.Prim ---------------------------------+------------------------------------------ Reporter: pumpkin | Owner: Type: proposal | Status: new Priority: normal | Component: Compiler Version: | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ I'm talking about the array primitives in particular: {{{ writeFloatArray# :: MutableByteArray# s -> Int# -> Float# -> State# s -> State# s }}} Conceptually, a Word# makes more sense as the index for all the array functions. I'm not even sure what the semantics are if the Int# is negative... is it checked? The three scenarios I can think of are: Negativity is checked, and you get an exception. Negativity is unchecked, and you get to write to memory that comes before your array. Negativity is ignored, and the back-end treats the Int# like a Word# already. I think the switch would be worthwhile in all of those cases, and could be hidden in higher-level APIs that still use Int for indexes with a simple int2Word#. Eventually we might even migrate to Word-based APIs at that level? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 22 17:23:51 2010 From: trac at galois.com (GHC) Date: Mon Feb 22 16:54:28 2010 Subject: [GHC] #3875: DPH QuickHull example crashes on SPARC with -N > 1 In-Reply-To: <043.48127cd9f809a0bcf184a76857f65e8a@abbot.galois.com> References: <043.48127cd9f809a0bcf184a76857f65e8a@abbot.galois.com> Message-ID: <052.ca018a56fd7f59e14c2e5ef1e739e831@abbot.galois.com> #3875: DPH QuickHull example crashes on SPARC with -N > 1 -----------------------------+---------------------------------------------- Reporter: benl | Owner: igloo Type: merge | Status: closed Priority: high | Milestone: 6.12.2 Component: Runtime System | Version: 6.13 Resolution: fixed | Keywords: Difficulty: | Os: Solaris Testcase: | Architecture: sparc Failure: Runtime crash | -----------------------------+---------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 22 17:24:48 2010 From: trac at galois.com (GHC) Date: Mon Feb 22 16:55:19 2010 Subject: [GHC] #3680: Improve docs for 'length' In-Reply-To: <056.32b26bd2c9b5e88047fb0bedd9442617@abbot.galois.com> References: <056.32b26bd2c9b5e88047fb0bedd9442617@abbot.galois.com> Message-ID: <065.2884055095b8d6edbb576cfbc52550f7@abbot.galois.com> #3680: Improve docs for 'length' --------------------------------+------------------------------------------- Reporter: daniel.is.fischer | Owner: igloo Type: feature request | Status: closed Priority: high | Milestone: 6.12.2 Component: libraries/base | Version: 6.10.4 Resolution: fixed | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Documentation bug | --------------------------------+------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Done in HEAD and 6.12. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 23 06:08:25 2010 From: trac at galois.com (GHC) Date: Tue Feb 23 05:39:05 2010 Subject: [GHC] #3676: realToFrac doesn't sanely convert between floating types In-Reply-To: <046.c71a4f69a48e7e64e18a56e29c643e03@abbot.galois.com> References: <046.c71a4f69a48e7e64e18a56e29c643e03@abbot.galois.com> Message-ID: <055.5f68a4b384484a2d88d2a1dd6f9617c0@abbot.galois.com> #3676: realToFrac doesn't sanely convert between floating types ----------------------------------+----------------------------------------- Reporter: draconx | Owner: simonmar Type: bug | Status: assigned Priority: normal | Milestone: _|_ Component: libraries (other) | Version: 6.12.1 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: x86_64 (amd64) | Failure: None/Unknown ----------------------------------+----------------------------------------- Changes (by simonmar): * milestone: 6.12.2 => _|_ Comment: I rolled back the patch to libraries/base: {{{ Tue Feb 23 10:16:03 GMT 2010 Simon Marlow * UNDO: Handle NaN, -Infinity and Infinity in the toRational for Float/Double (#3676) }}} in retrospect it wasn't a good idea to shoehorn these strange values into Rational. The position now is that `toRational (1/0 :: Double)` is undefined. The Haskell standard does not define the result (it should), and GHC gives unpredictable results. Hence, `realToFrac` cannot convert accurately between floating-point types. Someone should: * propose a proer API for conversion between floating-point types, e.g. `FloatConvert` above, but make a full proposal. * decide whether `toRational (1/0::Double)` should be undefined or an exception. If it is an exception, then we cannot optimise `realToFrac` to a direct conversion, e.g. `floatToDouble#`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 23 09:12:20 2010 From: trac at galois.com (GHC) Date: Tue Feb 23 08:43:02 2010 Subject: [GHC] #3676: realToFrac doesn't sanely convert between floating types In-Reply-To: <046.c71a4f69a48e7e64e18a56e29c643e03@abbot.galois.com> References: <046.c71a4f69a48e7e64e18a56e29c643e03@abbot.galois.com> Message-ID: <055.7f222d542418c3c05839daaa9f3284e3@abbot.galois.com> #3676: realToFrac doesn't sanely convert between floating types ----------------------------------+----------------------------------------- Reporter: draconx | Owner: simonmar Type: bug | Status: assigned Priority: normal | Milestone: _|_ Component: libraries (other) | Version: 6.12.1 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: x86_64 (amd64) | Failure: None/Unknown ----------------------------------+----------------------------------------- Comment(by draconx): I agree that the "funny rationals" are a bit too strange a notion, especially when it comes to defining how arithmetic operations should behave. After thinking about it, I'm fond of the toDouble/fromDouble approach as it seems consistent with the themes elsewhere in the library, except that it makes it harder to later add floating types that are wider than Double. I can post this idea to the haskell-prime mailing list for discussion, if that's the right one. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 23 10:22:35 2010 From: trac at galois.com (GHC) Date: Tue Feb 23 09:53:04 2010 Subject: [GHC] #3896: Make the GHC build system accommodate extra packages Message-ID: <046.be57e84e659ed12245bdba6363aab7f5@abbot.galois.com> #3896: Make the GHC build system accommodate extra packages ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: task | Status: new Priority: normal | Milestone: 6.14 branch Component: Build System | Version: Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Simon and I discussed the extra-packages story in GHC's build system. Here's a summary: * Simon added these 'extra-packages' stuff to help automate the process of downloading and building packages - that are not boot packages - but which we want to test regularly * DPH is another such package. It's not really a boot package, in the sense that (a) it's not necessary to build GHC and (b) it can only be built with a stage-2 compiler. The main reason it's treated as a boot package today is so that new patches are validated against it; it is a particularly good stress test. But it seems a bit overkill for it to masquerade as a boot package for that reason alone. * The current extra-packages story is a bit of a mess: - The extra packages are listed in $(TOP)/packages - But they are, quite separately listed in a make variable EXTRA_PACKAGES, and then stuffed into PACKAGES by 'addPackage' in $(TOP)/ghc.mk. - A series of addPackage calls in ghc.mk duplicates the list of boot packages in $(TOP)/packages. - Moreover, the list in EXTRA_PACKAGES must be in dependency order. We propose the following plan * Make the list in $(TOP)/packages the authoritative list. * Make 'sh boot' construct the list $(PACKAGES) from $(TOP)/packages and stuff it somewhere appropriate. ['sh boot' has to iterate over the packages anyhow, to boot them, but doesn't currently consult $(TOP)/packages to do so; it looks a the file system, which is less good.] * Make DPH into an extra package * And/or add a tag 'validated' to mean "this is an extra package, not a boot package, but it should be validated before pushing patches". That doesn't necessarily apply to all extra packages (eg stm). * The list in $(TOP)/packages is really a list of '''repositories''' not a list of '''packages'''. For example, utils/hcs2hs isn't a package. We probably want a tag ("util"?) to distinguish non-packages from packages. * DPH is unusual because it is a '''single repository''' that contains '''several packages'''. We can tell this because it has a file ghc-packages in its root directory, that lists the packages it contains. 'sh boot' must understand this when constructing $(PACKAGES); indeed it already does understand this. * Packages must be built in dependency order, and the build system has no way of figuring out the right order. But it would be easy to stipulate that $(TOP)/packages (and the ghc-packages file, if any, in the repo) should list the packages in dependency order. We don't need to execute this plan right away, but would be a very nice clean-up if anyone felt up to doing something about it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 23 10:48:48 2010 From: trac at galois.com (GHC) Date: Tue Feb 23 10:19:19 2010 Subject: [GHC] #3896: Make the GHC build system accommodate extra packages In-Reply-To: <046.be57e84e659ed12245bdba6363aab7f5@abbot.galois.com> References: <046.be57e84e659ed12245bdba6363aab7f5@abbot.galois.com> Message-ID: <055.b7d5f5769b56ff01a7e48819c4d892b1@abbot.galois.com> #3896: Make the GHC build system accommodate extra packages ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: task | Status: new Priority: normal | Milestone: 6.14 branch Component: Build System | Version: Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Comment(by simonpj): Related to #3882 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 23 14:35:23 2010 From: trac at galois.com (GHC) Date: Tue Feb 23 14:05:54 2010 Subject: [GHC] #3785: Broken link in library docs In-Reply-To: <044.21422e3934fe6a6ad246e695b17185dd@abbot.galois.com> References: <044.21422e3934fe6a6ad246e695b17185dd@abbot.galois.com> Message-ID: <053.85bc6963013dee861e6391e0945aa8a3@abbot.galois.com> #3785: Broken link in library docs ----------------------------+----------------------------------------------- Reporter: igloo | Owner: igloo Type: bug | Status: closed Priority: high | Milestone: 6.12.2 Component: Documentation | Version: 6.12.1 Resolution: fixed | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ----------------------------+----------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed in HEAD and 6.12 by: {{{ Tue Feb 23 15:05:22 GMT 2010 Ian Lynagh * Fix the links to the base docs from the user guide Tue Feb 23 16:45:51 GMT 2010 Ian Lynagh * Fix more library links in the user guide Tue Feb 23 18:16:44 GMT 2010 Ian Lynagh * Fix the link to the ghc docs in libraries/prologue.txt }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 23 17:35:41 2010 From: trac at galois.com (GHC) Date: Tue Feb 23 17:06:10 2010 Subject: [GHC] #3864: Bad error message if $TMP does not exist In-Reply-To: <051.eea869a73bc370d7e77925ccc5070f1d@abbot.galois.com> References: <051.eea869a73bc370d7e77925ccc5070f1d@abbot.galois.com> Message-ID: <060.a5ef17a8be36305e43333298b9afa10c@abbot.galois.com> #3864: Bad error message if $TMP does not exist ---------------------------+------------------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: closed Priority: high | Milestone: 6.12.2 Component: Compiler | Version: 6.10.4 Resolution: fixed | Keywords: Difficulty: | Os: Windows Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Thanks for the report. The good news is that 6.12 already tells you the path in the exception. I'm not sure that we can easily give a better error message. We don't currently know where the path we're trying to create came from, and on Windows it looks like we get it by calling `GetTempPath` so we probably have no way of finding out that it was ultimately from `%TMP%`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 23 20:03:27 2010 From: trac at galois.com (GHC) Date: Tue Feb 23 19:33:57 2010 Subject: [GHC] #3181: Regression in unboxing In-Reply-To: <044.12b8af7c7e17bf83c854d3057fcb12c2@abbot.galois.com> References: <044.12b8af7c7e17bf83c854d3057fcb12c2@abbot.galois.com> Message-ID: <053.c7408d430bb027b1bd188985a0e7171a@abbot.galois.com> #3181: Regression in unboxing --------------------------------+------------------------------------------- Reporter: dolio | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: Compiler | Version: 6.10.2 Keywords: unboxing boxing | Difficulty: Unknown Os: Linux | Testcase: Architecture: x86_64 (amd64) | Failure: Runtime performance bug --------------------------------+------------------------------------------- Comment(by igloo): I can't reproduce this. With 6.8.2: {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.8.2 $ ghc -O -c Vector.hs $ ghc -O -c StrictPair.hs -ddump-simpl }}} I get this: {{{ $w$j_sBq = \ (w2_sAq :: GHC.Prim.State# GHC.Prim.RealWorld) (ww2_sAt :: GHC.Base.Int) (ww3_sAw :: GHC.Prim.Int#) -> case w_sAC of wild11_auu { GHC.Base.I# x#_auw -> case GHC.Prim.<# x#_auw ww3_sAw of wild2_axd { GHC.Base.False -> case GHC.Prim.==# x#_auw ww3_sAw of wild12_axg { GHC.Base.False -> case GHC.Prim.writeIntArray# @ GHC.Prim.RealWorld arr_avS (GHC.Prim.+# ww_sAF 40) x#_auw w2_sAq of s'1_awJ { __DEFAULT -> (# s'1_awJ, GHC.Base.() #) }; GHC.Base.True -> case GHC.Prim.writeIntArray# @ GHC.Prim.RealWorld arr_avS (GHC.Prim.+# ww_sAF 40) x#_auw w2_sAq of s'1_awJ { __DEFAULT -> (# s'1_awJ, GHC.Base.() #) } }; GHC.Base.True -> case GHC.Prim.writeIntArray# @ GHC.Prim.RealWorld arr_avS (GHC.Prim.+# ww_sAF 40) ww3_sAw w2_sAq of s'1_awJ { __DEFAULT -> case ww2_sAt of w3_XAV { GHC.Base.I# ww4_XBA -> $wa_sBo wild11_auu ww4_XBA ww1_sAJ s'1_awJ } } } }}} which seems to have the same boxed `Int`. Can you say exactly how you are compiling it to get the result you want with 6.8.2 please? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 24 07:52:05 2010 From: trac at galois.com (GHC) Date: Wed Feb 24 07:22:39 2010 Subject: [GHC] #3897: reading a large String as Double takes too long Message-ID: <045.1a29b3d8a879db66b86d598db1ac12a4@abbot.galois.com> #3897: reading a large String as Double takes too long -----------------------+---------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Component: Prelude Version: 6.12.1 | Keywords: Os: Linux | Testcase: Architecture: x86 | Failure: Runtime performance bug -----------------------+---------------------------------------------------- {{{ Prelude> :set +s Prelude> read "1e1000000" :: Double Infinity (0.46 secs, 8977756 bytes) Prelude> read "1e1000000000" :: Double }}} The final call takes up all memory and does not terminate -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 24 07:56:58 2010 From: trac at galois.com (GHC) Date: Wed Feb 24 07:27:29 2010 Subject: [GHC] #3866: Constr Eq instance should have better documentation or semantics In-Reply-To: <053.48fcc2bcaa72d91af4e5c6324198c5c7@abbot.galois.com> References: <053.48fcc2bcaa72d91af4e5c6324198c5c7@abbot.galois.com> Message-ID: <062.376b4b957e56b207502897197a0a052e@abbot.galois.com> #3866: Constr Eq instance should have better documentation or semantics ----------------------------------+----------------------------------------- Reporter: batterseapower | Owner: dreixel Type: bug | Status: assigned Priority: normal | Milestone: 6.12.2 Component: libraries (other) | Version: 6.12.1 Keywords: syb | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ----------------------------------+----------------------------------------- Comment(by dreixel): I have attached the new patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 24 12:25:55 2010 From: trac at galois.com (GHC) Date: Wed Feb 24 11:56:26 2010 Subject: [GHC] #3886: Standalone deriving of NFData causes panic In-Reply-To: <046.4d0bac3e7ba9c1023afa62c4cce4ccf2@abbot.galois.com> References: <046.4d0bac3e7ba9c1023afa62c4cce4ccf2@abbot.galois.com> Message-ID: <055.355a57c29c1ecb2960f1b8db4b6d9ecd@abbot.galois.com> #3886: Standalone deriving of NFData causes panic ---------------------------------+------------------------------------------ Reporter: blarsen | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.12.1 Resolution: duplicate | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Compile-time crash | ---------------------------------+------------------------------------------ Changes (by simonpj): * status: new => closed * resolution: => duplicate Comment: A dup of #3833, happily fixed in both HEAD and (separately) on the 6.12 branch (on Jan 21 or so). Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 24 12:31:03 2010 From: trac at galois.com (GHC) Date: Wed Feb 24 12:01:37 2010 Subject: [GHC] #3826: Can't infer type (type family as "element" type) In-Reply-To: <042.84e771ed5687c0b090cc1169d5855922@abbot.galois.com> References: <042.84e771ed5687c0b090cc1169d5855922@abbot.galois.com> Message-ID: <051.a9091951edeeb8f4bd1f554845a5779a@abbot.galois.com> #3826: Can't infer type (type family as "element" type) ----------------------------------------+----------------------------------- Reporter: spl | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler (Type checker) | Version: 6.12.1 Keywords: type families | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: GHC rejects valid program ----------------------------------------+----------------------------------- Comment(by simonpj): Thank you! Yet another example that should start working when the new constraint solver is in place. I'll keep track of it, but it'll be a couple of months at least. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 24 12:36:47 2010 From: trac at galois.com (GHC) Date: Wed Feb 24 12:09:21 2010 Subject: [GHC] #3822: guards in arrow notation (Arrows extension) case statement cause compiler panic In-Reply-To: <056.c7c33f6cdeb1bfb88ba85665acc1134b@abbot.galois.com> References: <056.c7c33f6cdeb1bfb88ba85665acc1134b@abbot.galois.com> Message-ID: <065.37560c119b698358dccd1c266693181f@abbot.galois.com> #3822: guards in arrow notation (Arrows extension) case statement cause compiler panic -----------------------------------------+---------------------------------- Reporter: StephenBlackheath | Owner: ross Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: Compiler | Version: 6.12.1 Keywords: arrows guards case panic | Difficulty: Os: Unknown/Multiple | Testcase: patternGuard.hs Architecture: Unknown/Multiple | Failure: Compile-time crash -----------------------------------------+---------------------------------- Comment(by simonpj): Slightly smaller test case {{{ {-# LANGUAGE Arrows #-} module T3822 where import Control.Arrow test :: Int -> Int test = proc x -> do let neg = x < 0 case x of x | neg -> returnA -< 0 -- GHC panics _ -> returnA -< 10 }}} Ross: can you see what is wrong? Core Lint gives the error below after desugaring: {{{ *** Core Lint errors : in result of Desugar *** : [in body of letrec with binders fail_dnE :: GHC.Prim.State# GHC.Prim.RealWorld -> Data.Either.Either () ()] neg_acJ is out of scope *** Offending Program *** Rec { T3822.test :: GHC.Types.Int -> GHC.Types.Int [LclIdX] T3822.test = >>>_aiG @ GHC.Types.Int @ GHC.Types.Int @ GHC.Types.Int (arr_aix @ GHC.Types.Int @ GHC.Types.Int (\ (x_acI :: GHC.Types.Int) -> x_acI)) (>>>_aiG @ GHC.Types.Int @ GHC.Types.Int @ GHC.Types.Int (arr_aix @ GHC.Types.Int @ GHC.Types.Int (\ (ds_dnJ :: GHC.Types.Int) -> let { x_acI :: GHC.Types.Int [LclId] x_acI = ds_dnJ } in letrec { neg_acJ :: GHC.Bool.Bool [LclId] neg_acJ = <_ai2 x_acI (GHC.Types.I# 0); neg_ai3 :: GHC.Bool.Bool [LclId] neg_ai3 = neg_acJ; } in x_acI)) (>>>_aiG @ GHC.Types.Int @ (Data.Either.Either () ()) @ GHC.Types.Int (arr_aix @ GHC.Types.Int @ (Data.Either.Either () ()) (\ (ds_dnH :: GHC.Types.Int) -> let { x_acI :: GHC.Types.Int [LclId] x_acI = ds_dnH } in let { x_ahI :: GHC.Types.Int [LclId] x_ahI = x_acI } in let { fail_dnE :: GHC.Prim.State# GHC.Prim.RealWorld -> Data.Either.Either () () [LclId] fail_dnE = \ (ds_dnF :: GHC.Prim.State# GHC.Prim.RealWorld) -> Data.Either.Right @ () @ () GHC.Unit.() } in case neg_acJ of wild_B1 { GHC.Bool.False -> fail_dnE GHC.Prim.realWorld#; GHC.Bool.True -> Data.Either.Left @ () @ () GHC.Unit.() })) (|||_aiK @ () @ GHC.Types.Int @ () (>>>_aiG @ () @ GHC.Types.Int @ GHC.Types.Int (arr_aix @ () @ GHC.Types.Int (\ (ds_dnB :: ()) -> case ds_dnB of ds_dnB { () -> GHC.Types.I# 0 })) returnA_aig) (>>>_aiG @ () @ GHC.Types.Int @ GHC.Types.Int (arr_aix @ () @ GHC.Types.Int (\ (ds_dnD :: ()) -> case ds_dnD of ds_dnD { () -> GHC.Types.I# 10 })) returnA_ain)))) |||_aiK :: forall b_ami d_amj c_amk. (b_ami -> d_amj) -> (c_amk -> d_amj) -> Data.Either.Either b_ami c_amk -> d_amj [LclId] |||_aiK = Control.Arrow.||| @ (->) $dArrowChoice_anx $dArrow_anw :: Control.Arrow.Arrow (->) [LclId] $dArrow_anw = $dArrow_anq first_aiH :: forall b_aiN c_aiO d_aiP. (b_aiN -> c_aiO) -> (b_aiN, d_aiP) -> (c_aiO, d_aiP) [LclId] first_aiH = Control.Arrow.first @ (->) $dArrow_anw $dArrow_anv :: Control.Arrow.Arrow (->) [LclId] $dArrow_anv = $dArrow_anq >>>_aiG :: forall a_aiD b_aiE c_aiF. (a_aiD -> b_aiE) -> (b_aiE -> c_aiF) -> a_aiD -> c_aiF [LclId] >>>_aiG = GHC.Desugar.>>> @ (->) $dArrow_anv $dArrow_anu :: Control.Arrow.Arrow (->) [LclId] $dArrow_anu = $dArrow_anq arr_aix :: forall b_aiL c_aiM. (b_aiL -> c_aiM) -> b_aiL -> c_aiM [LclId] arr_aix = Control.Arrow.arr @ (->) $dArrow_anu returnA_ain :: GHC.Types.Int -> GHC.Types.Int [LclId] returnA_ain = returnA_aig $dArrowChoice_anx :: Control.Arrow.ArrowChoice (->) [LclId] $dArrowChoice_anx = Control.Arrow.$fArrowChoice(->) $dArrow_anq :: Control.Arrow.Arrow (->) [LclId] $dArrow_anq = Control.Arrow.$p1ArrowChoice @ (->) $dArrowChoice_anx returnA_aig :: GHC.Types.Int -> GHC.Types.Int [LclId] returnA_aig = Control.Arrow.returnA @ (->) @ GHC.Types.Int $dArrow_anq lit_aip :: GHC.Types.Int [LclId] lit_aip = GHC.Types.I# 10 lit_aii :: GHC.Types.Int [LclId] lit_aii = GHC.Types.I# 0 $dOrd_ano :: GHC.Classes.Ord GHC.Types.Int [LclId] $dOrd_ano = GHC.Base.$fOrdInt <_ai2 :: GHC.Types.Int -> GHC.Types.Int -> GHC.Bool.Bool [LclId] <_ai2 = GHC.Classes.< @ GHC.Types.Int $dOrd_ano test_ahS :: GHC.Types.Int -> GHC.Types.Int [LclId] test_ahS = T3822.test end Rec } *** End of Offense *** }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 24 12:59:02 2010 From: trac at galois.com (GHC) Date: Wed Feb 24 12:29:34 2010 Subject: [GHC] #3822: guards in arrow notation (Arrows extension) case statement cause compiler panic In-Reply-To: <056.c7c33f6cdeb1bfb88ba85665acc1134b@abbot.galois.com> References: <056.c7c33f6cdeb1bfb88ba85665acc1134b@abbot.galois.com> Message-ID: <065.0608618ef2c786d8c7a57c69b852be12@abbot.galois.com> #3822: guards in arrow notation (Arrows extension) case statement cause compiler panic -----------------------------------------+---------------------------------- Reporter: StephenBlackheath | Owner: ross Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: Compiler | Version: 6.12.1 Keywords: arrows guards case panic | Difficulty: Os: Unknown/Multiple | Testcase: patternGuard.hs Architecture: Unknown/Multiple | Failure: Compile-time crash -----------------------------------------+---------------------------------- Comment(by ross): Replying to [comment:7 simonpj]: > Ross: can you see what is wrong? Core Lint gives the error below after desugaring: Yes, variables occurring only in guards are not being recognized as being used, so they're discarded from the pipeline before reaching the case. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 24 14:21:32 2010 From: trac at galois.com (GHC) Date: Wed Feb 24 13:52:04 2010 Subject: [GHC] #3866: Constr Eq instance should have better documentation or semantics In-Reply-To: <053.48fcc2bcaa72d91af4e5c6324198c5c7@abbot.galois.com> References: <053.48fcc2bcaa72d91af4e5c6324198c5c7@abbot.galois.com> Message-ID: <062.06a872181f448878a9301f734f45275b@abbot.galois.com> #3866: Constr Eq instance should have better documentation or semantics --------------------------------+------------------------------------------- Reporter: batterseapower | Owner: dreixel Type: bug | Status: closed Priority: normal | Milestone: 6.12.2 Component: libraries (other) | Version: 6.12.1 Resolution: fixed | Keywords: syb Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | --------------------------------+------------------------------------------- Changes (by igloo): * status: assigned => closed * resolution: => fixed Comment: Thanks, applied in HEAD and 6.12. -- Ticket URL: GHC The Glasgow Haskell Compiler From seth.baldwin at comcast.net Wed Feb 24 21:11:17 2010 From: seth.baldwin at comcast.net (Seth442) Date: Wed Feb 24 20:41:40 2010 Subject: GHC failing during interactive linking with OpenAL Message-ID: <27714337.post@talk.nabble.com> Today I installed OpenAL on my windows machine. I installed both OpenAl-1.4.0.0 and ALUT-2.2.0.0 I am able to load the modules in haskell files and check the types of HOpenAL functions using GCHi, however, whenever I run a main routine in GCHi using HOpenAL functions I get the following error: Loading package OpenAL-1.4.0.0 ... linking ... : C:\Program Files\Haskell\OpenAL-1.4.0.0\ghc-6.10.4\HSOpenAL-1.4.0.0.o: unknown symbol '_alDistanceModel' : unable to load package 'OpenAL-1.4.0.0' I wrote the following program as a test: ---------------------------- import Sound.OpenAL.AL import Sound.ALUT main = do buf <- createBuffer HelloWorld x <- getLine print "done" --------------------------- When I compile it using GHC with the command "ghc --make test.hs" I get a series of errors (about 30-50 of them) such as: Linking test.exe ... C:\Program Files\Haskell\ALUT-2-2.0.0\ghc-6.10.4/libHSALUT-2.2.0.0.a(Config.o):fake:(.text+0x4c1): undefined reference to 'alutInit@8' C:\Program Files\Haskell\OpenAL-1.4.0.0\ghc-6.10.4/libHSOpenAL-1.4.0.0.a(BufferInternal.o):fake:(.text+0x75): undefined reference to 'alIsBuffer' Does anyone know what might be causing this problem? -- View this message in context: http://old.nabble.com/GHC-failing-during-interactive-linking-with-OpenAL-tp27714337p27714337.html Sent from the Haskell - Glasgow-haskell-bugs mailing list archive at Nabble.com. From trac at galois.com Thu Feb 25 11:07:01 2010 From: trac at galois.com (GHC) Date: Thu Feb 25 10:37:24 2010 Subject: [GHC] #3898: Many floating point documentation/behaviour mismatches. Message-ID: <046.a050fb2378999cd0869deccfc5034545@abbot.galois.com> #3898: Many floating point documentation/behaviour mismatches. ---------------------------------+------------------------------------------ Reporter: draconx | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 6.12.1 | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ I was looking at the haddock documentation for the Prelude to find out what the heck isIEEE did (which didn't actually help: what makes a value an "IEEE floating point number"? I'm guessing it is a constant function which indicates conformance of the _type_ to a particular standard), when I found a number of mismatches between the documentation and the behaviour. * The documentation for scaleFloat says "multiplies a floating point number by an integer power of the radix". But it doesn't do this: {{{ floatRadix (1/0) --> 2 1/0 * 2^^(-1) --> Infinity scaleFloat (-1) (1/0) --> 8.98846567431158e307 }}} In this case, I consider the documentation correct and the implementation wrong: scaleFloat should behave similarly to C's scalbln. * The documentation for exponent says "the second component of decodeFloat". {{{ decodeFloat 5 --> (5629499534213120,-50) exponent 5 --> 3 }}} In this case, it is probably just the documentation that is wrong. * The documentation for encodeFloat says "performs the inverse of decodeFloat". {{{ id $ 0/0 --> NaN uncurry encodeFloat . decodeFloat $ 0/0 --> -Infinity }}} In this case, I'm not sure which is wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 25 16:47:30 2010 From: trac at galois.com (GHC) Date: Thu Feb 25 16:17:54 2010 Subject: [GHC] #3899: -ddump-splices missing parentheses in pattern Message-ID: <044.8316d9ba645ce2cdc2eccdf9e5402f33@abbot.galois.com> #3899: -ddump-splices missing parentheses in pattern ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Template Haskell Version: 6.12.1 | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ '''Main.hs''' {{{ {-# LANGUAGE TemplateHaskell #-} import Language.Haskell.TH import Control.Monad data Cons a b = Cons a b data Nil = Nil nestedTuple n = do xs <- replicateM n (newName "x") return $ LamE [foldr (\v prev -> ConP 'Cons [VarP v,prev]) (ConP 'Nil []) xs] (TupE $ map VarE xs) }}} '''Load Main into ghci:''' {{{ *Main> :set -XTemplateHaskell *Main> :set -ddump-splices *Main> :t $(nestedTuple 3) :1:2: :1:2-14: Splicing expression nestedTuple 3 ======> \ Cons x[aYQ] Cons x[aYR] Cons x[aYS] Nil -> (x[aYQ], x[aYR], x[aYS]) In the expression: $(nestedTuple 3) $(nestedTuple 3) :: Cons t (Cons t1 (Cons t2 Nil)) -> (t, t1, t2) }}} However the inferred type and behavior of the function suggests that the Cons constructors are associated to the right. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 26 04:13:05 2010 From: trac at galois.com (GHC) Date: Fri Feb 26 03:43:27 2010 Subject: [GHC] #3878: doesFileExist doesn't work for some /dev files in ghc 6.12 In-Reply-To: <051.66116fcdcc5dbc814d38dc907d308ada@abbot.galois.com> References: <051.66116fcdcc5dbc814d38dc907d308ada@abbot.galois.com> Message-ID: <060.cd56c7d252b9958ebed5e924a2435dfc@abbot.galois.com> #3878: doesFileExist doesn't work for some /dev files in ghc 6.12 -------------------------------+-------------------------------------------- Reporter: marcotmarcot | Owner: simonmar Type: bug | Status: assigned Priority: normal | Milestone: 6.12.2 Component: Compiler | Version: 6.12.1 Keywords: | Difficulty: Os: Linux | Testcase: Architecture: x86_64 (amd64) | Failure: Incorrect result at runtime -------------------------------+-------------------------------------------- Changes (by simonmar): * owner: => simonmar * status: new => assigned -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 26 05:38:10 2010 From: trac at galois.com (GHC) Date: Fri Feb 26 05:08:37 2010 Subject: [GHC] #3900: CAFs used after GC with shared libs Message-ID: <047.248f4a1a0cd59074cc12078833f7e495@abbot.galois.com> #3900: CAFs used after GC with shared libs ---------------------------------+------------------------------------------ Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 6.12.1 | Keywords: Os: Linux | Testcase: Architecture: Unknown/Multiple | Failure: Runtime crash ---------------------------------+------------------------------------------ When using dlopen() it's possible that the loaded library introduces references to CAFs that have already been garbage collected. Chaos follows. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 26 06:14:15 2010 From: trac at galois.com (GHC) Date: Fri Feb 26 05:45:14 2010 Subject: [GHC] #3874: GHC.Exts.traceEvent segfaults In-Reply-To: <042.5001be7fcc4218b1286fd5d57d850c3a@abbot.galois.com> References: <042.5001be7fcc4218b1286fd5d57d850c3a@abbot.galois.com> Message-ID: <051.e7968dd823e5a1eead4164972ff5aee3@abbot.galois.com> #3874: GHC.Exts.traceEvent segfaults --------------------------------+------------------------------------------- Reporter: cjs | Owner: simonmar Type: bug | Status: assigned Priority: high | Milestone: 6.12.2 Component: Runtime System | Version: 6.12.1 Keywords: event, eventlog | Difficulty: Os: Linux | Testcase: Architecture: x86_64 (amd64) | Failure: Runtime crash --------------------------------+------------------------------------------- Comment(by simonmar): Fixed, thanks: {{{ Fri Feb 26 09:32:15 GMT 2010 Simon Marlow * Fix crash when using printf format specifiers in traceEvent (#3874) }}} I have a fix for the crash with `+RTS -ls -v` coming shortly. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 26 08:11:39 2010 From: trac at galois.com (GHC) Date: Fri Feb 26 07:42:11 2010 Subject: [GHC] #3900: CAFs used after GC with shared libs In-Reply-To: <047.248f4a1a0cd59074cc12078833f7e495@abbot.galois.com> References: <047.248f4a1a0cd59074cc12078833f7e495@abbot.galois.com> Message-ID: <056.e6bc89a338f028424a156f2ce5cfc8a9@abbot.galois.com> #3900: CAFs used after GC with shared libs ---------------------------------+------------------------------------------ Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: Runtime System | Version: 6.12.1 Keywords: | Difficulty: Os: Linux | Testcase: Architecture: Unknown/Multiple | Failure: Runtime crash ---------------------------------+------------------------------------------ Changes (by simonmar): * milestone: => 6.12.2 Comment: Ah yes. A program that intends to load Haskell libraries dynamically at runtime will have to identify itself as such somehow, so that the RTS can disable GC'ing of CAFs. Setting `keepCAFs = 1` before `hs_init()` will do it currently, we should decide if that's the right thing or not. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 26 08:14:18 2010 From: trac at galois.com (GHC) Date: Fri Feb 26 07:45:14 2010 Subject: [GHC] #3874: GHC.Exts.traceEvent segfaults In-Reply-To: <042.5001be7fcc4218b1286fd5d57d850c3a@abbot.galois.com> References: <042.5001be7fcc4218b1286fd5d57d850c3a@abbot.galois.com> Message-ID: <051.b66fd46a8633cc690d670113c77947e3@abbot.galois.com> #3874: GHC.Exts.traceEvent segfaults --------------------------------+------------------------------------------- Reporter: cjs | Owner: igloo Type: merge | Status: new Priority: high | Milestone: 6.12.2 Component: Runtime System | Version: 6.12.1 Keywords: event, eventlog | Difficulty: Os: Linux | Testcase: Architecture: x86_64 (amd64) | Failure: Runtime crash --------------------------------+------------------------------------------- Changes (by simonmar): * owner: simonmar => igloo * status: assigned => new * type: bug => merge Comment: Fix for the crash: {{{ Fri Feb 26 11:06:08 GMT 2010 Simon Marlow * Tweak the tracing flags slightly, and clean up error handling and diagnostics }}} I think we could merge this into 6.12.2, since the changes to flags are minor and don't affect the common uses (i.e. `+RTS -ls` still works the same as before). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 26 08:15:35 2010 From: trac at galois.com (GHC) Date: Fri Feb 26 07:45:57 2010 Subject: [GHC] #3878: doesFileExist doesn't work for some /dev files in ghc 6.12 In-Reply-To: <051.66116fcdcc5dbc814d38dc907d308ada@abbot.galois.com> References: <051.66116fcdcc5dbc814d38dc907d308ada@abbot.galois.com> Message-ID: <060.909145e9384cdfa063544c8a5fa873d0@abbot.galois.com> #3878: doesFileExist doesn't work for some /dev files in ghc 6.12 -------------------------------+-------------------------------------------- Reporter: marcotmarcot | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.12.2 Component: Compiler | Version: 6.12.1 Keywords: | Difficulty: Os: Linux | Testcase: Architecture: x86_64 (amd64) | Failure: Incorrect result at runtime -------------------------------+-------------------------------------------- Changes (by simonmar): * owner: simonmar => igloo * status: assigned => new * type: bug => merge Comment: Fixed: {{{ Fri Feb 26 01:31:44 PST 2010 Simon Marlow * Fix #3878: various directory tests were wrong on Unix systems }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 26 11:07:34 2010 From: trac at galois.com (GHC) Date: Fri Feb 26 10:38:04 2010 Subject: [GHC] #3900: CAFs used after GC with shared libs In-Reply-To: <047.248f4a1a0cd59074cc12078833f7e495@abbot.galois.com> References: <047.248f4a1a0cd59074cc12078833f7e495@abbot.galois.com> Message-ID: <056.885c377bb485af6027b0eb7f74740381@abbot.galois.com> #3900: CAFs used after GC with shared libs ---------------------------------+------------------------------------------ Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: Runtime System | Version: 6.12.1 Keywords: | Difficulty: Os: Linux | Testcase: Architecture: Unknown/Multiple | Failure: Runtime crash ---------------------------------+------------------------------------------ Comment(by augustss): But how do I set keepCAFs when the top level is Haskell? There is no explicit call to hs_init(). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 26 15:27:25 2010 From: trac at galois.com (GHC) Date: Fri Feb 26 14:57:48 2010 Subject: [GHC] #3901: Panic from combining generalized list comprehensions and record wildcards Message-ID: <046.38fd4580a8866cc5954faea2f9cb00ec@abbot.galois.com> #3901: Panic from combining generalized list comprehensions and record wildcards -------------------------------+-------------------------------------------- Reporter: amthrax | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.12.1 | Keywords: Os: Linux | Testcase: Architecture: x86_64 (amd64) | Failure: Compile-time crash -------------------------------+-------------------------------------------- Combining record wild cards with generalized list comprehension grouping causes the type-checker to mis-infer the type of the list comprehension, potentially leading to a panic. For example {{{ data Rec = Rec {a :: Int} deriving (Show) recs :: [[Int]] recs = [a | Rec {..} <- [Rec 1], then group by a] }}} results in a type error, because GHC thinks recs has type [Int]. On the other hand, {{{ recs :: [[Int]] recs = [a | Rec {a=a} <- [Rec 1], then group by a] }}} compiles, correctly. If the type annotation is omitted from the first example, GHC panics with {{{ ghc: panic! (the 'impossible' happened) (GHC version 6.12.1 for x86_64-unknown-linux): expectJust rnStmt }}} I've attached a test file that demonstrates the bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 27 10:08:45 2010 From: trac at galois.com (GHC) Date: Sat Feb 27 09:39:32 2010 Subject: [GHC] #2578: "ld: atom sorting error for ..." on OS X In-Reply-To: <044.426e3c7e28718ff62aa1ff6b2d89715c@abbot.galois.com> References: <044.426e3c7e28718ff62aa1ff6b2d89715c@abbot.galois.com> Message-ID: <053.8d9de781d3228ea2cdf61a5308612efe@abbot.galois.com> #2578: "ld: atom sorting error for ..." on OS X ---------------------------------+------------------------------------------ Reporter: igloo | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.12.2 Component: Compiler | Version: 6.10.4 Keywords: | Difficulty: Unknown Os: MacOS X | Testcase: Architecture: Unknown/Multiple | Failure: Incorrect warning at compile-time ---------------------------------+------------------------------------------ Comment(by igloo): Testcase: {{{ module Main (main) where data MyType data MyType2 main :: IO () main = print () }}} {{{ $ ghc-stage2 --make q -XEmptyDataDecls -fforce-recomp [1 of 1] Compiling Main ( q.hs, q.o ) Linking q ... ld: atom sorting error for _Main_MyType_closure_tbl and _Main_MyType2_closure_tbl in q.o ld: atom sorting error for _Main_MyType_closure_tbl and _Main_MyType2_closure_tbl in q.o ld: atom sorting error for _Main_MyType_closure_tbl and _Main_MyType2_closure_tbl in q.o }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 27 14:13:21 2010 From: trac at galois.com (GHC) Date: Sat Feb 27 13:43:38 2010 Subject: [GHC] #3902: Partial application gives type error Message-ID: <053.85f36a112a1210d8399c3bae16a550ad@abbot.galois.com> #3902: Partial application gives type error -------------------------------+-------------------------------------------- Reporter: moleculeColony | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 6.10.4 | Keywords: Os: Linux | Testcase: Architecture: x86_64 (amd64) | Failure: GHC rejects valid program -------------------------------+-------------------------------------------- I've tried to use the following line in my code (just to save some typing): fI = fromIntegral However, in certain cases it gives a type error, whereas the following version works: fI x = fromIntegral x Here a program that doesn't compile (with the error at the end): {{{ import Graphics.UI.Gtk import Graphics.UI.Gtk.Gdk.EventM import Control.Monad.Reader import System.Random import Data.Array.MArray import Data.Array.IO import Data.Word main = do parr <- newArray ((1,1,1),(600,600,3)) 127 :: IO (IOUArray (Int,Int,Int) Word8) initGUI win <- windowNew brush <- pixbufNew ColorspaceRgb False 8 10 10 widgetShowAll win dw <- widgetGetDrawWindow win gc <- gcNew dw timeoutAdd (draw parr dw gc brush) 1 on win deleteEvent $ tryEvent $ liftIO mainQuit mainGUI draw parr dw gc brush = do x <- randomRIO (1,600) y <- randomRIO (1,600) rr <- randomRIO (0,255) :: IO Int gr <- randomRIO (0,255) :: IO Int br <- randomRIO (0,255) :: IO Int rw <- readArray parr (x,y,1) gw <- readArray parr (x,y,2) bw <- readArray parr (x,y,3) let (ro,go,bo) = (fI rw, fI gw, fI bw) let cs = ro+go+bo let rn = div cs 6 + div rr 2 let gn = div cs 6 + div gr 2 let bn = div cs 6 + div br 2 let (ra,ga,ba) = (fI rn,fI gn,fI bn) writeArray parr (x,y,1) ra writeArray parr (x,y,2) ga writeArray parr (x,y,3) ba pixbufFill brush ra ga ba 0 w <- randomRIO (1,10) h <- randomRIO (1,10) drawPixbuf dw gc brush 0 0 x y w h RgbDitherNone 0 0 return True fI = fromIntegral fitest.hs:39:19: Couldn't match expected type `Word8' against inferred type `Int' In the second argument of `pixbufFill', namely `ra' In a stmt of a 'do' expression: pixbufFill brush ra ga ba 0 In the expression: do x <- randomRIO (1, 600) y <- randomRIO (1, 600) rr <- randomRIO (0, 255) :: IO Int gr <- randomRIO (0, 255) :: IO Int .... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 27 14:17:01 2010 From: trac at galois.com (GHC) Date: Sat Feb 27 13:47:48 2010 Subject: [GHC] #2578: "ld: atom sorting error for ..." on OS X In-Reply-To: <044.426e3c7e28718ff62aa1ff6b2d89715c@abbot.galois.com> References: <044.426e3c7e28718ff62aa1ff6b2d89715c@abbot.galois.com> Message-ID: <053.f54eb2f34377a4bc4336ebdb1f2d15c9@abbot.galois.com> #2578: "ld: atom sorting error for ..." on OS X ------------------------------------------------+--------------------------- Reporter: igloo | Owner: igloo Type: bug | Status: closed Priority: high | Milestone: 6.12.2 Component: Compiler | Version: 6.10.4 Resolution: fixed | Keywords: Difficulty: Unknown | Os: MacOS X Testcase: | Architecture: Unknown/Multiple Failure: Incorrect warning at compile-time | ------------------------------------------------+--------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed by {{{ Sat Feb 27 17:39:51 GMT 2010 Ian Lynagh * Fix trac #2578 We define empty datatypes as not being enumerations, which means the empty blocks aren't generated. }}} in HEAD and 6.12. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 27 14:29:19 2010 From: trac at galois.com (GHC) Date: Sat Feb 27 13:59:37 2010 Subject: [GHC] #3902: Partial application gives type error In-Reply-To: <053.85f36a112a1210d8399c3bae16a550ad@abbot.galois.com> References: <053.85f36a112a1210d8399c3bae16a550ad@abbot.galois.com> Message-ID: <062.72ec3b7d10ce2271281344d9c3f9e342@abbot.galois.com> #3902: Partial application gives type error ----------------------------------------+----------------------------------- Reporter: moleculeColony | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.10.4 Resolution: invalid | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86_64 (amd64) Failure: GHC rejects valid program | ----------------------------------------+----------------------------------- Changes (by igloo): * status: new => closed * resolution: => invalid Comment: Thanks for the report. This sounds like the monomorphism restriction. You can turn it off with the `NoMonomorphismRestriction` language extension. There's more information here: http://www.haskell.org/ghc/docs/latest/html/users_guide/monomorphism.html -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 27 17:04:02 2010 From: trac at galois.com (GHC) Date: Sat Feb 27 16:34:19 2010 Subject: [GHC] #3878: doesFileExist doesn't work for some /dev files in ghc 6.12 In-Reply-To: <051.66116fcdcc5dbc814d38dc907d308ada@abbot.galois.com> References: <051.66116fcdcc5dbc814d38dc907d308ada@abbot.galois.com> Message-ID: <060.11312100156dcfed71d74bbc714a6b7d@abbot.galois.com> #3878: doesFileExist doesn't work for some /dev files in ghc 6.12 ------------------------------------------+--------------------------------- Reporter: marcotmarcot | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.12.2 Component: Compiler | Version: 6.12.1 Resolution: fixed | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86_64 (amd64) Failure: Incorrect result at runtime | ------------------------------------------+--------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged: {{{ Sat Feb 27 21:31:47 GMT 2010 Ian Lynagh * Update directory tarball Includes: Wed Feb 3 07:09:57 GMT 2010 benl@cse.unsw.edu.au * On Solaris, _FILE_OFFSET_BITS must be defined before including sys/stat.h Fri Feb 26 01:31:44 PST 2010 Simon Marlow * Fix #3878: various directory tests were wrong on Unix systems }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 28 10:07:29 2010 From: trac at galois.com (GHC) Date: Sun Feb 28 09:37:44 2010 Subject: [GHC] #3852: Building GHC 6.12.1 with Cabal 1.9.0 installed In-Reply-To: <047.f658e84343f0f5a46a74754708d40840@abbot.galois.com> References: <047.f658e84343f0f5a46a74754708d40840@abbot.galois.com> Message-ID: <056.d460545afda3987567b9cc212a8da18d@abbot.galois.com> #3852: Building GHC 6.12.1 with Cabal 1.9.0 installed ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: duncan Type: bug | Status: new Priority: high | Milestone: 6.12.2 Component: Build System | Version: 6.12.1 Keywords: | Difficulty: Easy (less than 1 hour) Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Building GHC failed ---------------------------------+------------------------------------------ Changes (by igloo): * owner: => duncan -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 28 11:57:05 2010 From: trac at galois.com (GHC) Date: Sun Feb 28 11:27:23 2010 Subject: [GHC] #2924: createDirectory: permission denied In-Reply-To: <047.7f5e4787e0730bc3878fcff588107d39@abbot.galois.com> References: <047.7f5e4787e0730bc3878fcff588107d39@abbot.galois.com> Message-ID: <056.cbd18e84ac5216636ea16e94a19e6eb9@abbot.galois.com> #2924: createDirectory: permission denied ------------------------------------+--------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: libraries/directory | Version: 6.10.1 Keywords: | Difficulty: Unknown Os: Windows | Testcase: Architecture: x86 | Failure: None/Unknown ------------------------------------+--------------------------------------- Comment(by igloo): I can't reproduce the problem in the ticket description with the HEAD. I get: {{{ q.exe: RemoveDirectory "foo": permission denied (The process cannot access the file because it is being used by another process.) q.exe: thread blocked indefinitely in an MVar operation }}} which seems reasonable if the other thread is getting a directory listing for doing a recursive remove. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 28 12:42:27 2010 From: trac at galois.com (GHC) Date: Sun Feb 28 12:12:41 2010 Subject: [GHC] #3756: Missing -lz option in testsuite In-Reply-To: <056.ed7c6d1c92de3c6183484ea552e08336@abbot.galois.com> References: <056.ed7c6d1c92de3c6183484ea552e08336@abbot.galois.com> Message-ID: <065.a4ba0bfa550dd3431f5493fa52a0eb0a@abbot.galois.com> #3756: Missing -lz option in testsuite --------------------------------+------------------------------------------- Reporter: daniel.is.fischer | Type: bug Status: new | Priority: normal Milestone: 6.12.2 | Component: Build System Version: 6.12.1 | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86 Failure: Other | --------------------------------+------------------------------------------- Comment(by igloo): It sounds like installing something like a `libbfd-dev` package would work around this, as then we would link to the shared libbfd. For a better fix, it would be useful if someone who can reproduce the problem can tweak the configure test to handle this situation properly. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 28 13:41:34 2010 From: trac at galois.com (GHC) Date: Sun Feb 28 13:11:47 2010 Subject: [GHC] #3756: Missing -lz option in testsuite In-Reply-To: <056.ed7c6d1c92de3c6183484ea552e08336@abbot.galois.com> References: <056.ed7c6d1c92de3c6183484ea552e08336@abbot.galois.com> Message-ID: <065.fdd069c503eb332089645f14da117311@abbot.galois.com> #3756: Missing -lz option in testsuite --------------------------------+------------------------------------------- Reporter: daniel.is.fischer | Type: bug Status: new | Priority: normal Milestone: 6.12.2 | Component: Build System Version: 6.12.1 | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86 Failure: Other | --------------------------------+------------------------------------------- Comment(by daniel.is.fischer): What's the problem with adding '-optl-lz' to the command line of the pertinent tests or to EXTRA_HC_OPTS? Is it that the linker would/could pick the symbols from libz even when libbfd defines them too, and that would break things? So we'd need to determine whether libbfd depends on libz, and if it does, pass -lz. I assume testing whether {{{ ldd `locate libbfd | grep so` | grep libz }}} returns a nonempty string is too naive/nonportable? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 28 14:35:16 2010 From: trac at galois.com (GHC) Date: Sun Feb 28 14:05:30 2010 Subject: [GHC] #3807: Test for correct shared library generation In-Reply-To: <048.928719cb181f5e3e6b547832c856a384@abbot.galois.com> References: <048.928719cb181f5e3e6b547832c856a384@abbot.galois.com> Message-ID: <057.196af819cb2175e2f6911f10a7713641@abbot.galois.com> #3807: Test for correct shared library generation ---------------------------------+------------------------------------------ Reporter: asuffield | Owner: duncan Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: Test Suite | Version: 6.12.1 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Changes (by igloo): * owner: => duncan Comment: Duncan, can you please say how this should be done, and I'll add a testcase for it to the testsuite? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 28 15:11:35 2010 From: trac at galois.com (GHC) Date: Sun Feb 28 14:41:50 2010 Subject: [GHC] #3756: Missing -lz option in testsuite In-Reply-To: <056.ed7c6d1c92de3c6183484ea552e08336@abbot.galois.com> References: <056.ed7c6d1c92de3c6183484ea552e08336@abbot.galois.com> Message-ID: <065.1652f72279bc0a4f9cc6e59b165fa254@abbot.galois.com> #3756: Missing -lz option in testsuite --------------------------------+------------------------------------------- Reporter: daniel.is.fischer | Type: bug Status: new | Priority: normal Milestone: 6.12.2 | Component: Build System Version: 6.12.1 | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86 Failure: Other | --------------------------------+------------------------------------------- Comment(by igloo): Just adding `-optl-lz` would needlessly make that a dependency for everyone. The configure test should be based on trying to compile/run test programs. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 28 22:41:48 2010 From: trac at galois.com (GHC) Date: Sun Feb 28 22:12:06 2010 Subject: [GHC] #3577: Complete support for Data Parallel Haskell In-Reply-To: <041.e54cf544394515fd2960400b723e2495@abbot.galois.com> References: <041.e54cf544394515fd2960400b723e2495@abbot.galois.com> Message-ID: <050.7da74b65e5a6d7c918fed15d48892bbd@abbot.galois.com> #3577: Complete support for Data Parallel Haskell --------------------------------------+------------------------------------- Reporter: rl | Owner: rl Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Data Parallel Haskell | Version: 6.13 Keywords: | Difficulty: Unknown Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Compile-time crash --------------------------------------+------------------------------------- Changes (by benl): * failure: => Compile-time crash Comment: Vectorisation only works for algebraic types. Example: {{{ pow x 0 = 1 pow x n = x * pow (x - 1) }}} This doesn't work because we're pattern matching on `Int`. Rewrite as: {{{ pow x n | n == 0 = 1 | otherwise = x * pow (x - 1) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler