From trac at haskell.org Mon Oct 1 07:02:29 2007 From: trac at haskell.org (GHC) Date: Mon Oct 1 07:01:30 2007 Subject: [GHC] #1750: ghc-pkg stack overflow when mutually dependent packages installed Message-ID: <046.c7f89c65ae4e20e638696f6bfcdd5355@localhost> #1750: ghc-pkg stack overflow when mutually dependent packages installed ----------------------+----------------------------------------------------- Reporter: greenrd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: None | Version: 6.7 Severity: normal | Keywords: Difficulty: Unknown | Os: Linux Testcase: | Architecture: x86_64 (amd64) ----------------------+----------------------------------------------------- I erroneously added mutual dependencies between two packages I was working on. When I installed them both, both Cabal and ghc-pkg started behaving strangely: - Setup.hs configure would run, but very slowly[[BR]] - Setup.hs build would stack overflow[[BR]] - ghc-pkg list would stack overflow[[BR]] I realised that there was a mutual dependency, and manually edited package.conf to unregister one of them. This fixed the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Tue Oct 2 01:07:16 2007 From: trac at haskell.org (GHC) Date: Tue Oct 2 01:06:25 2007 Subject: [GHC] #1751: program with GADTs segfaults when compiled with -prof and -auto-all Message-ID: <044.21a9a16c20606b735255105103060aa6@localhost> #1751: program with GADTs segfaults when compiled with -prof and -auto-all -----------------------+---------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.6.1 Severity: normal | Keywords: Difficulty: Unknown | Os: Unknown Testcase: | Architecture: Unknown -----------------------+---------------------------------------------------- Consider the following modules Main.hs and M.hs: {{{ module Main ( main ) where import M main :: IO () main = do let f = T [undefined, undefined] [a] <- c f (\t -> return [r (UR undefined) t]) a }}} {{{ {-# OPTIONS_GHC -fglasgow-exts -fno-warn-incomplete-patterns #-} module M ( R(..), U, r, T(..), c ) where data T f where T :: [T f] -> T () data R t where UR :: (T f -> ()) -> R (U f) R :: R () data U f c :: T f -> (T () -> a) -> a c p@(T _) f = f p r :: R (U f) -> T f -> IO () r a f = (fu a f) `seq` return () fu :: R (U f) -> T f -> () fu (UR f) = f }}} I get: {{{ $ ghc --make -prof -auto-all Main $ ./Main +RTS -p Segmentation fault $./Main Segmentation fault }}} This is a boiled-down example taken from a large project. A couple of observations: * I haven't been able to reproduce it using only one module * The R constructor from type R is not used, but if removed, the segfault no longer happens * If -auto-all is not used, the segfault does not happen * I've been able to reproduce it both on linux and os x, using ghc 6.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Tue Oct 2 01:37:35 2007 From: trac at haskell.org (GHC) Date: Tue Oct 2 01:36:34 2007 Subject: [GHC] #1751: program with GADTs segfaults when compiled with -prof and -auto-all In-Reply-To: <044.21a9a16c20606b735255105103060aa6@localhost> References: <044.21a9a16c20606b735255105103060aa6@localhost> Message-ID: <053.3514836d0bf26586c097428931e8f278@localhost> #1751: program with GADTs segfaults when compiled with -prof and -auto-all -------------------------+-------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -------------------------+-------------------------------------------------- Comment (by sorear): Thanks for the report. I can reproduce this with 6.6.1 and 6.7.20070223, but not with 6.7.20070323 or any later version (fail with error: Prelude.undefined). I don't see any patches containing the word 'crash' or 'prof' in that span, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Tue Oct 2 08:04:19 2007 From: trac at haskell.org (GHC) Date: Tue Oct 2 08:03:18 2007 Subject: [GHC] #1738: GADT3 test failure In-Reply-To: <047.78308fa2c5c1788773b915e0f82c56e6@localhost> References: <047.78308fa2c5c1788773b915e0f82c56e6@localhost> Message-ID: <056.ae5c95fb10bfc9122d4a003cf285ff1b@localhost> #1738: GADT3 test failure -------------------------+-------------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Os: Unknown | Testcase: GADT3 Architecture: Unknown | -------------------------+-------------------------------------------------- Changes (by chak): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Tue Oct 2 10:52:28 2007 From: trac at haskell.org (GHC) Date: Tue Oct 2 10:51:35 2007 Subject: [GHC] #1717: ghc-6.8 configure does not recognise 32bit userland on ppc64 In-Reply-To: <059.9ba98474c2b63eccc55349ae913ba846@localhost> References: <059.9ba98474c2b63eccc55349ae913ba846@localhost> Message-ID: <068.61240d84551b9141741ff7ce4538b463@localhost> #1717: ghc-6.8 configure does not recognise 32bit userland on ppc64 -------------------------------------+-------------------------------------- Reporter: kahl@cas.mcmaster.ca | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.1 Component: Build System | Version: 6.8 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Linux | Testcase: normal build Architecture: powerpc64 | -------------------------------------+-------------------------------------- Comment (by guest): While the GHC build system identifies this machine (running 32bit userland on ppc64 64-bit kernel) as powerpc64-unknown-linux-gnu, (in config.status: s,@build@,|#_!!_#|powerpc64-unknown-linux-gnu,g in config.log: configure:1856: checking for GHC version date configure:1874: result: given 6.8.20070912 configure:2007: checking build system type configure:2025: result: powerpc64-unknown-linux-gnu configure:2047: checking host system type configure:2062: result: powerpc64-unknown-linux-gnu configure:2084: checking target system type configure:2099: result: powerpc64-unknown-linux-gnu ) everything else (except the kernel) builds on this system for powerpc-unknown-linux-gnu or just powerpc-unknown-linux. Passing --build=powerpc-unknown-linux to GHC's ./configure solves the problem both for 6.6.1 and (as far as I have tried) for 6.8. I am not familiar with the autotools, but even GHC finds, in config.log: Using built-in specs. Target: powerpc-unknown-linux-gnu Perhaps it is just a matter of actually using this to achieve what I achieved manually by passing --build=powerpc-unknown-linux. It may even be an autotools problem: At least readline-5.2, which reports the same target, still has only powerpc64 in config.status. In gentoo, I believe the correct settings are achieved by /usr/portage/profiles/default-linux/ppc/ppc64/2007.0/32bit- userland/make.defaults -- Ticket URL: GHC The Glasgow Haskell Compiler From mechvel at botik.ru Tue Oct 2 13:57:31 2007 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Tue Oct 2 13:55:18 2007 Subject: bug in 6.8.1-candidate Message-ID: <20071002175731.GA31189@scico.botik.ru> Dear GHC developers, this is again on the `panic' bug in ghc-6.8.1-candidate. The archive http://botik.ru/pub/local/Mechveliani/ghcBugs/bug2-6.8.0-sep28.zip presents one more report on this bug. Unzip and see install.txt. The project is built, but the test program Test.hs cannot build, ghc reports of `panic'. Further, return to the project build: in the file GBasFld.hs, comment-out the type declaration for the function b_criterion_ev, and re-build the project. Now, it reports of `panic' when compiling GBasFld. Simply speaking, docon-2.11 works under ghc-6.6.1 and does not work under ghc-6.8.0-sep28.zip. Regards, ----------------- Serge Mechveliani mechvel@botik.ru From trac at haskell.org Tue Oct 2 21:36:06 2007 From: trac at haskell.org (GHC) Date: Tue Oct 2 21:35:02 2007 Subject: [GHC] #1752: space leak caused by $ vs. () with -O2 Message-ID: <044.242b3a9dbfb747650cb39adff39f19dc@localhost> #1752: space leak caused by $ vs. () with -O2 -----------------------+---------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.6.1 Severity: normal | Keywords: Difficulty: Unknown | Os: Windows Testcase: | Architecture: Multiple -----------------------+---------------------------------------------------- The following program exhibits a space leak on GHC6.6.1. "noleak" doesn't exhibit the leak. The only difference is choosing to use $ (leaky) instead of () (non-leaky). No leak happens if optimizations are off. Compiled with {{{c:\haskell> ghc -O2 --make fibsquares.hs}}} {{{ module Main where fibs a b = a : fibs b (a+b) odds (x:xs) = evens xs evens (x:xs) = x : odds xs square x = x*x sumSucc xs = zipWith (+) xs (tail xs) main = spaceleak spaceleak = mapM_ print $ zip [0..] $ takeWhile id $ zipWith (==) (odds $ fibs 0 1) $ sumSucc $ map square $ fibs 0 1 noleak = mapM_ print $ zip [0..] $ takeWhile id $ zipWith (==) (odds $ fibs 0 1) (sumSucc $ map square $ fibs 0 1) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Wed Oct 3 03:24:35 2007 From: trac at haskell.org (GHC) Date: Wed Oct 3 03:23:36 2007 Subject: [GHC] #1753: GHC's file locking mechanism not prepared for close() returning -1 Message-ID: <044.7a21815167b73f8ad627199c744c2378@localhost> #1753: GHC's file locking mechanism not prepared for close() returning -1 -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.6.1 Severity: normal | Keywords: Difficulty: Easy (1 hr) | Os: Multiple Testcase: | Architecture: Unknown -----------------------------+---------------------------------------------- There is a bug in GHC file locking mechanism which manifests itself when close() returns -1. The reasons for the problem, as I see it, are: * asymmetry in the locking mechanism - creating the lock by device/inode, but releasing by fd * not handling exceptions properly in hClose * trying to do the job of the operating system and/or trying to correct the behavior of the operating system - but this one is a criticism of Haskell Report, not of GHC I will demonstrate the scenario on an example program: {{{ main = do try $ do h <- openFile "A" AppendMode -- As part of opening A, GHC adds a lock to the writeLock table -- (libraries/base/cbits/lockFile.c). hClose h -- Assume that close() returned -1 when performing hClose, but released -- the file descriptor anyway (this happened for us). -- In hClose_help (libraries/base/GHC/Handle.hs) an exception is -- raised by (throwErrnoIfMinus1Retry_ "hClose" ...). -- As a result, (unlockFile fd) is not performed, which leaves -- a lock on A's device and inode. Further attempts to open A -- will fail, of course, but let's look at a more interesting scenario. -- Remember that h's underlying file descriptor was released and is -- available. do h1 <- openFile "B" AppendMode -- Assume that "B" is opened under the same file descriptor that was earlier -- assigned to "A". -- OpenFile locks "B", and the lock for it is put at the end of writeLock -- table. hClose h1 -- What happens here is that unlockFile removes the first lock matching h1's -- file descriptor. But this is the lock for A! -- The lock for B is left intact. do h1 <- openFile "B" AppendMode -- openFile fails because of the stray lock for B. hClose h1 }}} A can see the following solutions to this problem: * handle the exception properly. I think this should be straightforward, but there may be some hidden dangers - after all, when close() fails you already have a strange situation. Perhaps we should check if the file descriptor is still in use with fstat()? On the other hand, it shouldn't make much difference as long as the Handle is marked as closed. * remove all locks with matching fd - this would only fix the A/B problem, and it would be a bit awkward - after all, we probably don't want to have duplicated fds in the lock tables If we can agree on the acceptable solution, I could try fixing it myself. This would be a good exercise in working with GHC's darcs repository. BTW, functions lockFile and unlockFile seem to be quite expensive: * they use linear search on the lock tables * when deleting an entry unlockFile moves all subsequent entries up Perhaps it would be a good idea to get rid of locking requirements from haskell-prime? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Wed Oct 3 17:52:27 2007 From: trac at haskell.org (GHC) Date: Wed Oct 3 17:51:30 2007 Subject: [GHC] #1754: Border case type families/type equality coercions cause the impossible to happen Message-ID: <044.5b282880a7fed5b59af173fcab0e822e@localhost> #1754: Border case type families/type equality coercions cause the impossible to happen -----------------------+---------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8 Severity: minor | Keywords: type family equality coercion Difficulty: Unknown | Os: Linux Testcase: | Architecture: Unknown -----------------------+---------------------------------------------------- A few border case problems with type equality coercions with type variables only occurring in the constraints part of the type. The code says it all. {{{ {-# LANGUAGE TypeFamilies #-} module Weird where {- Compiles fine, but in GHCi: Prelude Weird> :t x *** Exception: No match in record selector Var.tcTyVarDetails -} x :: (a ~ b, Num b) => b x = undefined {- Same in GHCi, but when compiling: % /tmp/ghc-6.8/bin/ghc --make Weird.hs [1 of 1] Compiling Weird ( Weird.hs, Weird.o ) ghc-6.8.0.20071002: panic! (the 'impossible' happened) (GHC version 6.8.0.20071002 for i386-unknown-linux): initC: srt_lbl *Weird> plus 0 0 ghc-6.8.0.20071002: panic! (the 'impossible' happened) (GHC version 6.8.0.20071002 for i386-unknown-linux): nameModule $dNum{v arP} -} plus :: (a ~ b, b ~ c, c ~ d, Num b) => b -> c -> d plus x y = x + y {- This one only works when plus is commented out, otherwise: *Weird> y ghc-6.8.0.20071002: panic! (the 'impossible' happened) (GHC version 6.8.0.20071002 for i386-unknown-linux): nameModule $dNum{v arY} -} y :: (a ~ a) => () y = () }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Thu Oct 4 15:36:56 2007 From: trac at haskell.org (GHC) Date: Thu Oct 4 15:36:02 2007 Subject: [GHC] #1754: Border case type families/type equality coercions cause the impossible to happen In-Reply-To: <044.5b282880a7fed5b59af173fcab0e822e@localhost> References: <044.5b282880a7fed5b59af173fcab0e822e@localhost> Message-ID: <053.449554025592d586c49238a5bd2f3c00@localhost> #1754: Border case type families/type equality coercions cause the impossible to happen ----------------------------------------------+----------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8 Severity: normal | Resolution: Keywords: type family equality coercion | Difficulty: Unknown Os: Linux | Testcase: Architecture: Unknown | ----------------------------------------------+----------------------------- Changes (by guest): * cc: g9ks157k@acme.softbase.org (added) * severity: minor => normal Comment: There is a possibly similar problem with GHC?6.8.0.20070926 (i386-unknown- mingw32). The code in the attachment {{{TypeEq.hs}}} causes the impossible to happen with the error message {{{initC: srt_lbl}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Thu Oct 4 22:48:07 2007 From: trac at haskell.org (GHC) Date: Thu Oct 4 22:47:03 2007 Subject: [GHC] #1755: Template Haskell quoting bug Message-ID: <044.67fbf5a6611c354aa89760a29b6b810d@localhost> #1755: Template Haskell quoting bug -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Template Haskell | Version: 6.6.1 Severity: minor | Keywords: Difficulty: Unknown | Os: Unknown Testcase: | Architecture: Multiple -------------------------------+-------------------------------------------- Quoting local variable in a certain situation make GHC panic. This OK: {{{ foo = "foo" expFoo :: Q Exp expFoo = return (VarE 'foo) }}} But this will panic when you use $(expFoo) in another module: {{{ expFoo :: Q Exp expFoo = let foo = "foo" in return (VarE 'foo) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Thu Oct 4 22:59:13 2007 From: trac at haskell.org (GHC) Date: Thu Oct 4 22:58:02 2007 Subject: [GHC] #1755: Template Haskell quoting bug In-Reply-To: <044.67fbf5a6611c354aa89760a29b6b810d@localhost> References: <044.67fbf5a6611c354aa89760a29b6b810d@localhost> Message-ID: <053.905ccf0d42f30be4849d4986bc0c7416@localhost> #1755: Template Haskell quoting bug ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Template Haskell | Version: 6.6.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Multiple | ---------------------------------+------------------------------------------ Comment (by guest): below is what GHC says: {{{ $ ghci ghc_th_bug.hs ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.6, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help. Loading package base ... linking ... done. [1 of 2] Compiling Foo ( Foo.hs, interpreted ) [2 of 2] Compiling Main ( ghc_th_bug.hs, interpreted ) Loading package template-haskell ... linking ... done. ghc-6.6: panic! (the 'impossible' happened) (GHC version 6.6 for i386-apple-darwin): nameModule foo{v a16Q} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} -- This post is from Keigo IMAI (keigo.imai _at_ gmail.com). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Fri Oct 5 10:48:29 2007 From: trac at haskell.org (GHC) Date: Fri Oct 5 10:47:19 2007 Subject: [GHC] #1756: Miscellaneous fixes to validate on PPC Mac OS X Message-ID: <050.2a7d557b3a06f6a1e7ad320b954aede6@localhost> #1756: Miscellaneous fixes to validate on PPC Mac OS X --------------------------+------------------------------------------------- Reporter: thorkilnaur | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Keywords: Difficulty: Unknown | Os: MacOS X Testcase: | Architecture: powerpc --------------------------+------------------------------------------------- The attached patches, (in-?)conveniently separated by affected file, fix the following warnings that have prevented a successful validate on PPC Mac OS X recently: {{{ /Users/thorkilnaur/tn/install/ghc-6.6-for-buildbot-20070221_1000/bin/ghc -Werror -H64m -Onot -fasm -istage1/utils -istage1/basicTypes -istage1/types -istage1/hsSyn -istage1/prelude -istage1/rename -istage1/typecheck -istage1/deSugar -istage1/coreSyn -istage1/vectorise -istage1/specialise -istage1/simplCore -istage1/stranal -istage1/stgSyn -istage1/simplStg -istage1/codeGen -istage1/main -istage1/profiling -istage1/parser -istage1/cprAnalysis -istage1/ndpFlatten -istage1/iface -istage1/cmm -istage1/nativeGen -Wall -fno-warn-name-shadowing -fno-warn- orphans -Istage1 -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -Iparser -package unix -ignore-package lang -recomp -Rghc-timing -O -fasm -H16M '-#include "cutils.h"' -DUSING_COMPAT -i../compat -ignore-package Cabal -c nativeGen/RegCoalesce.hs -o stage1/nativeGen/RegCoalesce.o -ohi stage1/nativeGen/RegCoalesce.hi nativeGen/RegAllocLinear.hs:161:11: Warning: Defined but not used: `x' nativeGen/RegAllocLinear.hs:161:15: Warning: Defined but not used: `i' }}} Fixing this leads to: {{{ /Users/thorkilnaur/tn/install/ghc-6.6-for-buildbot-20070221_1000/bin/ghc -Werror -H64m -Onot -fasm -istage1/utils -istage1/basicTypes -istage1/types -istage1/hsSyn -istage1/prelude -istage1/rename -istage1/typecheck -istage1/deSugar -istage1/coreSyn -istage1/vectorise -istage1/specialise -istage1/simplCore -istage1/stranal -istage1/stgSyn -istage1/simplStg -istage1/codeGen -istage1/main -istage1/profiling -istage1/parser -istage1/cprAnalysis -istage1/ndpFlatten -istage1/iface -istage1/cmm -istage1/nativeGen -Wall -fno-warn-name-shadowing -fno-warn- orphans -Istage1 -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -Iparser -package unix -ignore-package lang -recomp -Rghc-timing -O -fasm -H16M '-#include "cutils.h"' -DUSING_COMPAT -i../compat -ignore-package Cabal -c nativeGen/RegAllocLinear.hs -o stage1/nativeGen/RegAllocLinear.o -ohi stage1/nativeGen/RegAllocLinear.hi nativeGen/RegAllocLinear.hs:157:0: Warning: Pattern match(es) are non-exhaustive In the definition of `getFreeRegs': Patterns not matched: _ (FreeRegs _ _) }}} Then there is: {{{ /Users/thorkilnaur/tn/install/ghc-6.6-for-buildbot-20070221_1000/bin/ghc -Werror -H64m -Onot -fasm -istage1/utils -istage1/basicTypes -istage1/types -istage1/hsSyn -istage1/prelude -istage1/rename -istage1/typecheck -istage1/deSugar -istage1/coreSyn -istage1/vectorise -istage1/specialise -istage1/simplCore -istage1/stranal -istage1/stgSyn -istage1/simplStg -istage1/codeGen -istage1/main -istage1/profiling -istage1/parser -istage1/cprAnalysis -istage1/ndpFlatten -istage1/iface -istage1/cmm -istage1/nativeGen -Wall -fno-warn-name-shadowing -fno-warn- orphans -Istage1 -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -Iparser -package unix -ignore-package lang -recomp -Rghc-timing -O -fasm -H16M '-#include "cutils.h"' -DUSING_COMPAT -i../compat -ignore-package Cabal -c nativeGen/RegAllocStats.hs -o stage1/nativeGen/RegAllocStats.o -ohi stage1/nativeGen/RegAllocStats.hi nativeGen/RegAllocStats.hs:327:3: Warning: Pattern match(es) are non-exhaustive In a case alternative: Patterns not matched: RcDouble }}} There are also warnings compiling C code: {{{ ../compiler/ghc-inplace -optc-Werror -optc-Wall -optc-W -optc-Wstrict- prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc- Winline -optc-Waggregate-return -optc-I../includes -optc-I. -optc- Iparallel -optc-Ism -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -optc-I../gmp/gmpbuild -optc-fno-strict-aliasing -Werror -H64m -Onot -fasm -optc-O2 -I../includes -I. -Iparallel -Ism -DCOMPILING_RTS -package-name rts -static -I../gmp/gmpbuild -I. -#include HCIncludes.h -dcmm-lint -optc-funroll-loops -c sm/Evac.c -o sm/Evac.o cc1: warnings being treated as errors In file included from sm/Evac.c:17:0: sm/Evac.h:21:0: warning: 'regparm' attribute directive ignored sm/Evac.c:315:0: warning: 'regparm' attribute directive ignored }}} As well as: {{{ ../compiler/ghc-inplace -optc-Werror -optc-Wall -optc-W -optc-Wstrict- prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc- Winline -optc-Waggregate-return -optc-I../includes -optc-I. -optc- Iparallel -optc-Ism -optc-DCOMPILING_RTS -optc-g -optc-O0 -optc-I../gmp/gmpbuild -optc-fno-strict-aliasing -Werror -H64m -Onot -fasm -I../includes -I. -Iparallel -Ism -DCOMPILING_RTS -package-name rts -static -I../gmp/gmpbuild -I. -#include HCIncludes.h -dcmm-lint -hisuf debug_hi -hcsuf debug_hc -osuf debug_o -optc-DDEBUG -c Linker.c -o Linker.debug_o cc1: warnings being treated as errors Linker.c: In function 'relocateSection': Linker.c:4252:0: warning: comparison between signed and unsigned }}} All warnings being fixed by patches to the respective files. Thanks to Ben Lippmeier and Ian Lynagh for their generous help. Best regards Thorkil -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Fri Oct 5 15:10:25 2007 From: trac at haskell.org (GHC) Date: Fri Oct 5 15:09:19 2007 Subject: [GHC] #1757: Simple example crashes GHC Message-ID: <044.d7e32d03c1cb4bc47f18c3f97bbb7584@localhost> #1757: Simple example crashes GHC -----------------------+---------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Keywords: Difficulty: Unknown | Os: Unknown Testcase: | Architecture: Unknown -----------------------+---------------------------------------------------- This file: {{{ class Collects ce where type Elem ce empty :: ce insert :: Elem ce -> ce -> ce member :: Elem ce -> ce -> Bool toList :: ce -> [Elem ce] }}} and call GHC as: ghci -fglasgow-exts Abc gives: {{{ GHCi, version 6.9.20070927: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. [1 of 1] Compiling Main ( Abc.hs, interpreted ) ghc-6.9.20070927: panic! (the 'impossible' happened) (GHC version 6.9.20070927 for i386-unknown-linux): check_tau_type main:Main.Elem{tc rlp} ce{tv alz} [tv] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Sat Oct 6 07:44:57 2007 From: trac at haskell.org (GHC) Date: Sat Oct 6 07:43:44 2007 Subject: [GHC] #1758: misleading compiler error message in case of interface file inconsistency Message-ID: <044.54eab5ee0654e3c68ee78e6e3a9d8189@localhost> #1758: misleading compiler error message in case of interface file inconsistency -----------------------+---------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.6.1 Severity: normal | Keywords: Difficulty: Unknown | Os: MacOS X Testcase: | Architecture: powerpc -----------------------+---------------------------------------------------- I hacked on the GHC base, did something wrong (on purpose), and got a very confusing error message while compiling: Interface file inconsistency: home-package module `base:GHC.Base' is mentioned is needed, but is not among the dependencies of interfaces directly imported by the module being compiled I can't even parse the first sentence!?! Maybe the message could be improved? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Sat Oct 6 08:39:41 2007 From: trac at haskell.org (GHC) Date: Sat Oct 6 08:38:26 2007 Subject: [GHC] #1759: HPC interaction with -Wall leading to spurious pattern match warnings Message-ID: <044.afb5b34428b1dacb9dc1d69f3c7f7e5e@localhost> #1759: HPC interaction with -Wall leading to spurious pattern match warnings -----------------------+---------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 6.8 Severity: normal | Keywords: HPC Difficulty: Unknown | Os: Unknown Testcase: | Architecture: Unknown -----------------------+---------------------------------------------------- Without -fhpc, the following program passes the pattern match checker: {{{ f :: String -> Int f x | null x = 1 | otherwise = 2 main :: IO () main = print $ f [] }}} However, with -fhpc on, we get the spurious warning: {{{ A.hs:3:0: Warning: Pattern match(es) are non-exhaustive In the definition of `f': Patterns not matched: _ }}} Causing libraries using -Werror to fail to build when using -fhpc. }}} -- Don -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Sun Oct 7 15:30:50 2007 From: trac at haskell.org (GHC) Date: Sun Oct 7 15:29:31 2007 Subject: [GHC] #1760: ghc 6.6.1: internal error: asyncRead# on threaded RTS Message-ID: <044.bc4433bd0a31f10a9275a1477ea0bb61@localhost> #1760: ghc 6.6.1: internal error: asyncRead# on threaded RTS -----------------------+---------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.6.1 Severity: normal | Keywords: Difficulty: Unknown | Os: Unknown Testcase: | Architecture: Unknown -----------------------+---------------------------------------------------- My email address babu.srinivasan@gmail.com import Control.Monad (liftM) import Data.Char (isAlpha, toLower) import qualified Data.Map as M[[BR]] import qualified Data.ByteString.Lazy.Char8 as B[[BR]] main :: IO ()[[BR]] main = do[[BR]] a <- B.map toLower `liftM` B.readFile "data_capitals"[[BR]] B.putStrLn a[[BR]] :l try1[[BR]] [1 of 1] Compiling Main ( try1.hs, interpreted )[[BR]] Ok, modules loaded: Main.[[BR]] *Main> main[[BR]] : internal error: asyncRead# on threaded RTS[[BR]] (GHC version 6.6.1 for i386_unknown_mingw32)[[BR]] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug[[BR]] This application has requested the Runtime to terminate it in an unusual way.[[BR]] Please contact the application's support team for more information.[[BR]] -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Sun Oct 7 15:50:52 2007 From: trac at haskell.org (GHC) Date: Sun Oct 7 15:49:32 2007 Subject: [GHC] #1760: ghc 6.6.1: internal error: asyncRead# on threaded RTS In-Reply-To: <064.562adeea26bf2e4899029da7f09a7fc6@localhost> References: <064.562adeea26bf2e4899029da7f09a7fc6@localhost> Message-ID: <073.81d0d8cbcd1d16614649269c7d2bdcc0@localhost> #1760: ghc 6.6.1: internal error: asyncRead# on threaded RTS ------------------------------------------+--------------------------------- Reporter: babu.srinivasan@gmail.com | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Windows | Testcase: Architecture: x86 | ------------------------------------------+--------------------------------- Changes (by sorear): * reporter: guest => babu.srinivasan@gmail.com * os: Unknown => Windows * architecture: Unknown => x86 Old description: > My email address babu.srinivasan@gmail.com > > import Control.Monad (liftM) > > import Data.Char (isAlpha, toLower) > > import qualified Data.Map as M[[BR]] > > import qualified Data.ByteString.Lazy.Char8 as B[[BR]] > > main :: IO ()[[BR]] > > main = do[[BR]] > > a <- B.map toLower `liftM` B.readFile "data_capitals"[[BR]] > > B.putStrLn a[[BR]] > > > :l try1[[BR]] > > [1 of 1] Compiling Main ( try1.hs, interpreted )[[BR]] > > Ok, modules loaded: Main.[[BR]] > > *Main> main[[BR]] > > : internal error: asyncRead# on threaded RTS[[BR]] > > (GHC version 6.6.1 for i386_unknown_mingw32)[[BR]] > > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug[[BR]] > > This application has requested the Runtime to terminate it in an unusual > way.[[BR]] > > Please contact the application's support team for more information.[[BR]] New description: {{{ import Control.Monad (liftM) import Data.Char (isAlpha, toLower) import qualified Data.Map as M import qualified Data.ByteString.Lazy.Char8 as B main :: IO () main = do a <- B.map toLower `liftM` B.readFile "data_capitals" B.putStrLn a }}} {{{ :l try1 [1 of 1] Compiling Main ( try1.hs, interpreted ) Ok, modules loaded: Main. *Main> main : internal error: asyncRead# on threaded RTS (GHC version 6.6.1 for i386_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Mon Oct 8 08:41:23 2007 From: trac at haskell.org (GHC) Date: Mon Oct 8 08:40:09 2007 Subject: [GHC] #1739: Can't compile apps with the -fvia-C flag - Can't locate vars.pm In-Reply-To: <044.3a9f751ef9fcbcf0421ddff67c212936@localhost> References: <044.3a9f751ef9fcbcf0421ddff67c212936@localhost> Message-ID: <053.994935292dd9d7c51370251de0a92095@localhost> #1739: Can't compile apps with the -fvia-C flag - Can't locate vars.pm -------------------------+-------------------------------------------------- Reporter: guest | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 6.8.1 Component: Compiler | Version: 6.8 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Os: Windows | Testcase: Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: I believe I've fixed this. {{{ Mon Oct 8 12:57:40 BST 2007 Simon Marlow * comment-out "use vars" in 3 places (see #1739) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Mon Oct 8 09:14:35 2007 From: trac at haskell.org (GHC) Date: Mon Oct 8 09:13:14 2007 Subject: [GHC] #1748: main-is argument cannot be hierarchical module In-Reply-To: <044.a841d628fa90a4a19b945cd103d9b3a1@localhost> References: <044.a841d628fa90a4a19b945cd103d9b3a1@localhost> Message-ID: <053.1ed082768f99fd6627373921924e98ff@localhost> #1748: main-is argument cannot be hierarchical module -------------------------+-------------------------------------------------- Reporter: guest | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -------------------------+-------------------------------------------------- Changes (by simonmar): * owner: => simonmar Comment: validating fix -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Mon Oct 8 09:16:58 2007 From: trac at haskell.org (GHC) Date: Mon Oct 8 09:15:39 2007 Subject: [GHC] #1739: Can't compile apps with the -fvia-C flag - Can't locate vars.pm In-Reply-To: <044.3a9f751ef9fcbcf0421ddff67c212936@localhost> References: <044.3a9f751ef9fcbcf0421ddff67c212936@localhost> Message-ID: <053.95b095ca1ef4eb68d56f24e9d02be751@localhost> #1739: Can't compile apps with the -fvia-C flag - Can't locate vars.pm -------------------------+-------------------------------------------------- Reporter: guest | Owner: simonmar Type: merge | Status: reopened Priority: high | Milestone: 6.8.1 Component: Compiler | Version: 6.8 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Windows | Testcase: Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by simonmar): * status: closed => reopened * type: bug => merge * resolution: fixed => Comment: oops, need to merge this one -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Mon Oct 8 09:17:13 2007 From: trac at haskell.org (GHC) Date: Mon Oct 8 09:15:52 2007 Subject: [GHC] #1739: Can't compile apps with the -fvia-C flag - Can't locate vars.pm In-Reply-To: <044.3a9f751ef9fcbcf0421ddff67c212936@localhost> References: <044.3a9f751ef9fcbcf0421ddff67c212936@localhost> Message-ID: <053.26b776dc222be0c01913ad49b88ea920@localhost> #1739: Can't compile apps with the -fvia-C flag - Can't locate vars.pm -------------------------+-------------------------------------------------- Reporter: guest | Owner: igloo Type: merge | Status: new Priority: high | Milestone: 6.8.1 Component: Compiler | Version: 6.8 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Windows | Testcase: Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by simonmar): * status: reopened => new * owner: simonmar => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Mon Oct 8 09:17:22 2007 From: trac at haskell.org (GHC) Date: Mon Oct 8 09:16:02 2007 Subject: [GHC] #1761: Compiler panics on "phantom family" Message-ID: <044.7a5f83f4c9d4ccaf482c534cace08282@localhost> #1761: Compiler panics on "phantom family" --------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.8 Severity: normal | Keywords: phantom familiy Difficulty: Unknown | Os: Multiple Testcase: | Architecture: Unknown --------------------------------------+------------------------------------- Feeding the following innocent looking (well...) program into GHC causes the compiler to panic: {{{ {-# OPTIONS_GHC -fglasgow-exts #-} type family KUnit a :: * type instance KUnit Int = () unit :: KUnit Int unit = () }}} The cry for help reads: {{{ ghc-6.8.20071007: panic! (the 'impossible' happened) (GHC version 6.9.20070923 for powerpc-apple-darwin): check_tau_type main:Main.KUnit{tc rnu} base:GHC.Base.Int{(w) tc 3J} }}} Unsurprisingly, I've experienced the same behaviour with 6.9.20070923. HTH, Stefan Holdermans -- Ticket URL: GHC The Glasgow Haskell Compiler From simonmarhaskell at gmail.com Mon Oct 8 09:30:10 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Mon Oct 8 09:28:52 2007 Subject: [GHC] #1738: GADT3 test failure In-Reply-To: <056.ae5c95fb10bfc9122d4a003cf285ff1b@localhost> References: <047.78308fa2c5c1788773b915e0f82c56e6@localhost> <056.ae5c95fb10bfc9122d4a003cf285ff1b@localhost> Message-ID: <470A30E2.6070304@gmail.com> GHC wrote: > #1738: GADT3 test failure > -------------------------+-------------------------------------------------- > Reporter: simonmar | Owner: > Type: bug | Status: closed > Priority: normal | Milestone: 6.10 branch > Component: Compiler | Version: 6.9 > Severity: normal | Resolution: fixed > Keywords: | Difficulty: Unknown > Os: Unknown | Testcase: GADT3 > Architecture: Unknown | > -------------------------+-------------------------------------------------- > Changes (by chak): > > * status: new => closed > * resolution: => fixed hunk ./tests/ghc-regress/indexed-types/should_compile/all.T 50 -test('GADT3', expect_broken_for(1738, ['normal','optc']), compile, ['']) +test('GADT3', normal, compile, ['']) this test now fails on the stable branch - I assume the patch isn't going to be merged, right? In that case we want an "expect_broken_if_compiler_lt" in all.T. Cheers, Simon From trac at haskell.org Mon Oct 8 09:35:04 2007 From: trac at haskell.org (GHC) Date: Mon Oct 8 09:33:42 2007 Subject: [GHC] #1756: Miscellaneous fixes to validate on PPC Mac OS X In-Reply-To: <050.2a7d557b3a06f6a1e7ad320b954aede6@localhost> References: <050.2a7d557b3a06f6a1e7ad320b954aede6@localhost> Message-ID: <059.5302a1ad762af9a1a9b8d8ee93e66b81@localhost> #1756: Miscellaneous fixes to validate on PPC Mac OS X ----------------------------+----------------------------------------------- Reporter: thorkilnaur | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: MacOS X | Testcase: Architecture: powerpc | ----------------------------+----------------------------------------------- Changes (by simonmar): * owner: => simonmar Comment: I'll validate and push these -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Mon Oct 8 09:45:35 2007 From: trac at haskell.org (GHC) Date: Mon Oct 8 09:44:17 2007 Subject: [GHC] #1748: main-is argument cannot be hierarchical module In-Reply-To: <044.a841d628fa90a4a19b945cd103d9b3a1@localhost> References: <044.a841d628fa90a4a19b945cd103d9b3a1@localhost> Message-ID: <053.ad17b1b7c072021edd351f2612a58a6f@localhost> #1748: main-is argument cannot be hierarchical module -------------------------+-------------------------------------------------- Reporter: guest | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Os: Unknown | Testcase: driver062.5 Architecture: Unknown | -------------------------+-------------------------------------------------- Changes (by simonmar): * testcase: => driver062.5 * status: new => closed * resolution: => fixed Comment: Fixed: {{{ Mon Oct 8 14:13:05 BST 2007 Simon Marlow * FIX #1748: -main-is wasn't handling the case of a single hierarchical module test case is driver062.5 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Mon Oct 8 09:45:58 2007 From: trac at haskell.org (GHC) Date: Mon Oct 8 09:44:36 2007 Subject: [GHC] #1748: main-is argument cannot be hierarchical module In-Reply-To: <044.a841d628fa90a4a19b945cd103d9b3a1@localhost> References: <044.a841d628fa90a4a19b945cd103d9b3a1@localhost> Message-ID: <053.226d20af6a6b057d705ec4b2f5db069f@localhost> #1748: main-is argument cannot be hierarchical module -------------------------+-------------------------------------------------- Reporter: guest | Owner: simonmar Type: bug | Status: reopened Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: driver062.5 Architecture: Unknown | -------------------------+-------------------------------------------------- Changes (by simonmar): * status: closed => reopened * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Mon Oct 8 09:46:14 2007 From: trac at haskell.org (GHC) Date: Mon Oct 8 09:44:52 2007 Subject: [GHC] #1748: main-is argument cannot be hierarchical module In-Reply-To: <044.a841d628fa90a4a19b945cd103d9b3a1@localhost> References: <044.a841d628fa90a4a19b945cd103d9b3a1@localhost> Message-ID: <053.71a479a7d4faeea65aeed436d838bb3e@localhost> #1748: main-is argument cannot be hierarchical module -------------------------+-------------------------------------------------- Reporter: guest | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: driver062.5 Architecture: Unknown | -------------------------+-------------------------------------------------- Changes (by simonmar): * status: reopened => new * owner: simonmar => igloo * type: bug => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Mon Oct 8 10:24:59 2007 From: trac at haskell.org (GHC) Date: Mon Oct 8 10:23:42 2007 Subject: [GHC] #1762: wrong result of isProperSubsetOf Message-ID: <044.88f42752bdb6a3c83b9b82379152de53@localhost> #1762: wrong result of isProperSubsetOf -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.4.1 Severity: normal | Keywords: IntSet Difficulty: Unknown | Os: Linux Testcase: | Architecture: x86 -----------------------------+---------------------------------------------- {{{IntSet.isProperSubsetOf (IntSet.fromList [2,3]) (IntSet.fromList [1,2,3])}}} is evaluated to {{{False}}}, but should be {{{True}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Tue Oct 9 00:12:03 2007 From: trac at haskell.org (GHC) Date: Tue Oct 9 00:10:53 2007 Subject: [GHC] #1754: Border case type families/type equality coercions cause the impossible to happen In-Reply-To: <044.5b282880a7fed5b59af173fcab0e822e@localhost> References: <044.5b282880a7fed5b59af173fcab0e822e@localhost> Message-ID: <053.a45a21816c4dc8b9fb57baa874caa058@localhost> #1754: Border case type families/type equality coercions cause the impossible to happen ----------------------------------------------+----------------------------- Reporter: guest | Owner: chak Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8 Severity: normal | Resolution: Keywords: type family equality coercion | Difficulty: Unknown Os: Linux | Testcase: Architecture: Unknown | ----------------------------------------------+----------------------------- Changes (by chak): * owner: => chak -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Tue Oct 9 00:17:59 2007 From: trac at haskell.org (GHC) Date: Tue Oct 9 00:16:37 2007 Subject: [GHC] #1757: Simple example crashes GHC In-Reply-To: <044.d7e32d03c1cb4bc47f18c3f97bbb7584@localhost> References: <044.d7e32d03c1cb4bc47f18c3f97bbb7584@localhost> Message-ID: <053.adf767f95a39a928507e28d18520253b@localhost> #1757: Simple example crashes GHC -------------------------+-------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -------------------------+-------------------------------------------------- Changes (by chak): * status: new => closed * resolution: => duplicate Comment: Same as #1729 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Tue Oct 9 00:19:20 2007 From: trac at haskell.org (GHC) Date: Tue Oct 9 00:17:58 2007 Subject: [GHC] #1761: Compiler panics on "phantom family" In-Reply-To: <044.7a5f83f4c9d4ccaf482c534cace08282@localhost> References: <044.7a5f83f4c9d4ccaf482c534cace08282@localhost> Message-ID: <053.3698ed0c0fa2b199f42e9ccaee4a7fe3@localhost> #1761: Compiler panics on "phantom family" ----------------------------------------+----------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.8 Severity: normal | Resolution: duplicate Keywords: phantom familiy | Difficulty: Unknown Os: Multiple | Testcase: Architecture: Unknown | ----------------------------------------+----------------------------------- Changes (by chak): * status: new => closed * resolution: => duplicate Comment: Same as #1729 -- Ticket URL: GHC The Glasgow Haskell Compiler From chak at cse.unsw.edu.au Tue Oct 9 00:59:20 2007 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Tue Oct 9 00:58:06 2007 Subject: [GHC] #1738: GADT3 test failure In-Reply-To: <470A30E2.6070304@gmail.com> References: <047.78308fa2c5c1788773b915e0f82c56e6@localhost> <056.ae5c95fb10bfc9122d4a003cf285ff1b@localhost> <470A30E2.6070304@gmail.com> Message-ID: <470B0AA8.9090504@cse.unsw.edu.au> Simon Marlow wrote, > GHC wrote: >> #1738: GADT3 test failure >> -------------------------+-------------------------------------------------- >> >> Reporter: simonmar | Owner: Type: >> bug | Status: closed Priority: normal | >> Milestone: 6.10 branch >> Component: Compiler | Version: 6.9 Severity: >> normal | Resolution: fixed Keywords: | >> Difficulty: Unknown Os: Unknown | Testcase: >> GADT3 Architecture: Unknown | >> -------------------------+-------------------------------------------------- >> >> Changes (by chak): >> >> * status: new => closed >> * resolution: => fixed > > hunk ./tests/ghc-regress/indexed-types/should_compile/all.T 50 > -test('GADT3', expect_broken_for(1738, ['normal','optc']), compile, > ['']) > +test('GADT3', normal, compile, ['']) > > this test now fails on the stable branch - I assume the patch isn't > going to be merged, right? In that case we want an > "expect_broken_if_compiler_lt" in all.T. The fixing patch was tagged as "MERGE TO STABLE". Manuel From trac at haskell.org Tue Oct 9 08:08:42 2007 From: trac at haskell.org (GHC) Date: Tue Oct 9 08:07:17 2007 Subject: [GHC] #1763: dictionaries in GHC.Float not being inlined Message-ID: <047.aec357aa321756b127570ac256a33629@localhost> #1763: dictionaries in GHC.Float not being inlined -----------------------+---------------------------------------------------- Reporter: simonmar | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.8 branch Component: Compiler | Version: 6.6.1 Severity: normal | Keywords: Difficulty: Unknown | Os: Unknown Testcase: | Architecture: Unknown -----------------------+---------------------------------------------------- Some dictionaries exported by `GHC.Float` are not inlined, because they are being marked as loop breakers, e.g. `GHC.Float.$f4`. This makes `x2n1` in nofib much slower, and possibly others. One reason this happens is that constructor applications are beaten by (a) inline candidates and (b) bindings with RULES in `OccurAnal.score`. Simon & I addressed (a) by changing it so that normal inline candidates are now scored lower than constructor applications, but wrappers are scored much higher. This unfortunately doesn't fix `GHC.Float`. If we also make bindings with RULEs score lower than constructor applications, then the compiler goes into a loop when compiling `Data.Traversable`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Tue Oct 9 09:06:17 2007 From: trac at haskell.org (GHC) Date: Tue Oct 9 09:04:56 2007 Subject: [GHC] #1391: forkProcess() in Schedule.c with -threaded should initialize mutexes in child process (POSIX) In-Reply-To: <050.ab6642c28e13c00c6c4b9df378dcf986@localhost> References: <050.ab6642c28e13c00c6c4b9df378dcf986@localhost> Message-ID: <059.2bad12a0271653993f672eae05cd2ccb@localhost> #1391: forkProcess() in Schedule.c with -threaded should initialize mutexes in child process (POSIX) -------------------------------+-------------------------------------------- Reporter: thorkilnaur | Owner: Type: bug | Status: new Priority: high | Milestone: 6.8 branch Component: Runtime System | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: MacOS X | Testcase: forkprocess01(ghci) Architecture: powerpc | -------------------------------+-------------------------------------------- Comment (by simonmar): Thorkil - following our conversation at ICFP, I've pushed a patch that calls `initMutex` for every Task: {{{ Tue Oct 9 13:24:09 BST 2007 Simon Marlow * also call initMutex on every task->lock, see #1391 }}} could you let me know if that works for you? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Tue Oct 9 09:07:58 2007 From: trac at haskell.org (GHC) Date: Tue Oct 9 09:06:33 2007 Subject: [GHC] #1008: Remove unregisterised way In-Reply-To: <047.5cdc3eb7bc71bfc1aefccc2827fcf08b@localhost> References: <047.5cdc3eb7bc71bfc1aefccc2827fcf08b@localhost> Message-ID: <056.7dcaa5e2093df50100e363a59761a528@localhost> #1008: Remove unregisterised way -------------------------+-------------------------------------------------- Reporter: simonmar | Owner: Type: task | Status: closed Priority: low | Milestone: 6.8 branch Component: Compiler | Version: 6.6 Severity: normal | Resolution: fixed Keywords: | Difficulty: Moderate (1 day) Os: Unknown | Testcase: Architecture: Unknown | -------------------------+-------------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Done: {{{ Tue Oct 9 13:23:38 BST 2007 Simon Marlow * remove the "-unreg" flag and the unregisterised way, see #1008 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Tue Oct 9 09:53:57 2007 From: trac at haskell.org (GHC) Date: Tue Oct 9 09:52:32 2007 Subject: [GHC] #1743: debugger: confusion with shadowed bindings In-Reply-To: <047.de6d754332cdc0a3110e915c78fd199c@localhost> References: <047.de6d754332cdc0a3110e915c78fd199c@localhost> Message-ID: <056.00223f0e9e8f2c51ee7eb64dbd96bb19@localhost> #1743: debugger: confusion with shadowed bindings -------------------------+-------------------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.8 branch Component: GHCi | Version: 6.8 Severity: minor | Resolution: Keywords: | Difficulty: Moderate (1 day) Os: Unknown | Testcase: break026 Architecture: Unknown | -------------------------+-------------------------------------------------- Changes (by simonmar): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Tue Oct 9 10:54:22 2007 From: trac at haskell.org (GHC) Date: Tue Oct 9 10:52:56 2007 Subject: [GHC] #1743: debugger: confusion with shadowed bindings In-Reply-To: <047.de6d754332cdc0a3110e915c78fd199c@localhost> References: <047.de6d754332cdc0a3110e915c78fd199c@localhost> Message-ID: <056.a8ac954de68bb548ba4f05778a47161c@localhost> #1743: debugger: confusion with shadowed bindings -------------------------+-------------------------------------------------- Reporter: simonmar | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.8 branch Component: GHCi | Version: 6.8 Severity: minor | Resolution: Keywords: | Difficulty: Moderate (1 day) Os: Unknown | Testcase: break026 Architecture: Unknown | -------------------------+-------------------------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: Fixed: {{{ Tue Oct 9 15:25:54 BST 2007 Simon Marlow * FIX #1743, create a fresh unique for each Id we bind at a breakpoint }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Tue Oct 9 10:56:02 2007 From: trac at haskell.org (GHC) Date: Tue Oct 9 10:54:42 2007 Subject: [GHC] #1733: RTS option -N not exposed at Haskell level In-Reply-To: <057.7d3296fb0b18661237534421ae609cfa@localhost> References: <057.7d3296fb0b18661237534421ae609cfa@localhost> Message-ID: <066.85fb2abae1531296d015662caf42a57b@localhost> #1733: RTS option -N not exposed at Haskell level -----------------------------------+---------------------------------------- Reporter: bos@serpentine.com | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.8.1 Component: libraries/base | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Os: Unknown | Testcase: Architecture: Unknown | -----------------------------------+---------------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge * milestone: 6.8 branch => 6.8.1 Comment: Fixed. Patch to GHC: {{{ Tue Oct 9 15:27:01 BST 2007 Simon Marlow * export n_capabilities, see #1733 }}} Patch to `libraries\base`: {{{ Tue Oct 9 14:20:42 BST 2007 Simon Marlow * expose the value of +RTS -N as GHC.Conc.numCapabilities (see #1733) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Tue Oct 9 11:09:34 2007 From: trac at haskell.org (GHC) Date: Tue Oct 9 11:08:12 2007 Subject: [GHC] #1764: missing backquotes in documentation for Prelude.elem (and probably other places) Message-ID: <044.71b5f38d1d8a7833865ef531f6b8c4c9@localhost> #1764: missing backquotes in documentation for Prelude.elem (and probably other places) ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 6.6.1 Severity: normal | Keywords: Difficulty: Unknown | Os: Unknown Testcase: | Architecture: Unknown ----------------------------+----------------------------------------------- The 'elem' docs at http://www.haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html say "... usually written in infix form, e.g., x elem xs", missing the backquotes. Haddock seems to eat the backquotes that are in the source file and create a hyperlink of the content. Not sure whether that's a Haddock bug though, its docs only talk of '...' and `...' being hyperlinks. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Tue Oct 9 16:48:20 2007 From: trac at haskell.org (GHC) Date: Tue Oct 9 16:46:55 2007 Subject: [GHC] #1765: :def should redefine too (ghci commands) Message-ID: <044.2e754278928b761a6cbd1903f928cee4@localhost> #1765: :def should redefine too (ghci commands) ------------------------------+--------------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.9 Severity: normal | Keywords: Difficulty: Unknown | Os: Unknown Testcase: | Architecture: Unknown ------------------------------+--------------------------------------------- To redefine a function f, one needs to first undef it. This is not a nice interface(or the error message should be improved to "to redefine a command you first need to use the :undef command. Do you want this? [yes/no]?"). Suggested feature: :def can also redefine commands. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Tue Oct 9 16:54:32 2007 From: trac at haskell.org (GHC) Date: Tue Oct 9 16:53:06 2007 Subject: [GHC] #1766: :undef f f has odd behaviour Message-ID: <044.ba1179c9c9173ec4317cecb44a2d88f3@localhost> #1766: :undef f f has odd behaviour ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.9 Severity: normal | Keywords: Difficulty: Unknown | Os: Unknown Testcase: | Architecture: Unknown ----------------------+----------------------------------------------------- :undef f f tries to undefine "f f". More sensible behaviour would be to undefine both f and f (in this case only f, but in the general case any list of function names.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Tue Oct 9 17:51:44 2007 From: trac at haskell.org (GHC) Date: Tue Oct 9 17:50:20 2007 Subject: [GHC] #1765: :def should redefine too (ghci commands) In-Reply-To: <044.2e754278928b761a6cbd1903f928cee4@localhost> References: <044.2e754278928b761a6cbd1903f928cee4@localhost> Message-ID: <053.badb991e00d92aab84f954986dc3287a@localhost> #1765: :def should redefine too (ghci commands) --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | --------------------------------+------------------------------------------- Changes (by guest): * cc: claus.reinke@talk21.com (added) Comment: going into a dialogue is going to interfere with scripts, so i'd advise against that, but the issue itself is real enough. following on from the vi-like command syntax traditionally used in hugs and ghci, we could have: {{{ -- list all commands, with definition texts :def -- list definition text of commands starting with c, if any :def c -- define c, fail with error message if c exists :def c -- define c, override existing definition, if any :def! c }}} another issue is that of figuring out (in a script) which commands are available. in vim, that'd be exists(":command"), which tells me if there's a full match, a partial match (:b vs :browse), an ambiguous match (multiple possible completions), or no match for the command name. exists can also be used to query for options, eg., does this ghci version have -fno-print-bind-result or not. to make clear that this is a built-in function, i'd suggest introducing a GHCi module, so we'd have {{{ (GHCi.exists ":command") (GHCi.exists "-fprint-bind-result") }}} the same module could also hold other information about ghci, such as version number and available features {{{ (GHCi.version>=[6,6,1]) (GHCi.has "debugger") }}} i've run into all these issues as well, in practice, when trying to define .ghci files that work with recent ghc versions (no :cmd in 6.6.1, no :edit and no -fprint-bind-result in 6.4.1). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Tue Oct 9 18:34:19 2007 From: trac at haskell.org (GHC) Date: Tue Oct 9 18:32:55 2007 Subject: [GHC] #1767: :show does not conform to documented specification Message-ID: <044.e7adae11ca7979e3093e064a998ae30d@localhost> #1767: :show does not conform to documented specification ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.9 Severity: normal | Keywords: Difficulty: Unknown | Os: Unknown Testcase: | Architecture: Unknown ----------------------+----------------------------------------------------- :show show anything that can be set with :set (e.g. args) It's possible to do :set -i/home/foo/something However, doing :show -i or :show args or whatever does not show this information. So, either the documentation is wrong, or the implementation is wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Wed Oct 10 05:26:04 2007 From: trac at haskell.org (GHC) Date: Wed Oct 10 05:24:37 2007 Subject: [GHC] #1620: Bug in debugger 6.7.20070817 In-Reply-To: <044.53d725b3007e15a81cf7af24407f5869@localhost> References: <044.53d725b3007e15a81cf7af24407f5869@localhost> Message-ID: <053.7f85523bdd5f8e105dc183a03c0c3606@localhost> #1620: Bug in debugger 6.7.20070817 ------------------------+--------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.7 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | ------------------------+--------------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: We fixed this, I believe. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Wed Oct 10 05:29:29 2007 From: trac at haskell.org (GHC) Date: Wed Oct 10 05:27:59 2007 Subject: [GHC] #1768: More flexible type signatures for data constructors Message-ID: <046.e80dabea24186dabb3849f7f5dbd4d5b@localhost> #1768: More flexible type signatures for data constructors ------------------------------+--------------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: low | Milestone: _|_ Component: Compiler | Version: 6.6.1 Severity: normal | Keywords: Difficulty: Unknown | Os: Unknown Testcase: | Architecture: Unknown ------------------------------+--------------------------------------------- See [http://article.gmane.org/gmane.comp.lang.haskell.cafe/29409], and the rest of the thread. The idea is to allow data constructor declarations to have things like this: {{{ type Foo = Int -> Bool -> T data T where C :: Foo }}} This is a silly example, but the idea is not to require the arrows to be all visible at top level, and to allow the result type to be something other than visibly `T` itself. I'm recording this as a feature request, since it came up on Haskell Cafe, but I'm not sure that I like it. The type signatures in data type declarations are pretty special: notably, they allow record syntax, and support strictness annotations. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Wed Oct 10 05:35:28 2007 From: trac at haskell.org (GHC) Date: Wed Oct 10 05:34:01 2007 Subject: [GHC] #1377: GHCi debugger tasks In-Reply-To: <047.b3e158073b17fc81d3d320da105cad09@localhost> References: <047.b3e158073b17fc81d3d320da105cad09@localhost> Message-ID: <056.788f993a817bf0bd563e408401c408cd@localhost> #1377: GHCi debugger tasks -------------------------+-------------------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -------------------------+-------------------------------------------------- Old description: > I'm collecting all these together into one ticket for now. Later we > might split off individual tasks. Please update the description if you > complete one of these. > > == easy == > > * Autocompletion for :break only provides names, not modules > > == moderate == > > * for each breakpoint we should retain the declpath constructed by the > coverage pass. This would let us > show the enclosing binding(s) for each breakpoint in the UI (eg. > "Stopped in M.f (M.hs:40:23-28)"). > > * :force should catch exceptions, so [1,2,undefined] would display as > `[1,2,< exception >]` > > * show variables with unboxed types. > > * tabs go wrong with :list (but only for .lhs files, because unlit does > tab expansion... duh) > > == unknown, or require thinking about == > > * Some kind of "step over" or "next" command is needed. > > * `:print` shouldn't ever use show? > > * `:break ` only works if the name is exported > can/should we relax this? > > * sometimes the result types are wrong (see result001 test) > > * perhaps we should have a :watch command, that could be used to save > variables for future inspection (they wouldn't get > thrown away by :continue) > > * We can disable a breakpoint with ":set stop N :continue", but this > still prints out the breakpoint info when we stop. > Should we print the info only if there were no commands? > > * Revert to adding tick information to the BCO directly, and remove the > byte code instructions for breaks. I'm not sure that this is worth it. In > some ways the implementation based on a byte code instruction is a little > cleaner than adding breaks on BCOs directly. Though the bc instruction > method may be a little slower than the other way. > > * Flag to disable breakpoints? > > * When we restore the interactive context on resume, we throw away any > new bindings made since the breakpoint. Can this > be fixed? > > * threads and breakpoints. > > * if a :force results in a breakpoint, we should treat it as we do other > evaluations. (currently we get > "*** Ignoring breakpoint"). > > * It's a bit strange that in "f = e" you don't get a breakpoint covering > the whole binding, but in "f x = e" you do. New description: I'm collecting all these together into one ticket for now. Later we might split off individual tasks. Please update the description if you complete one of these. == easy == * Autocompletion for :break only provides names, not modules == moderate == * for each breakpoint we should retain the declpath constructed by the coverage pass. This would let us show the enclosing binding(s) for each breakpoint in the UI (eg. "Stopped in M.f (M.hs:40:23-28)"). * :force should catch exceptions, so [1,2,undefined] would display as `[1,2,< exception >]` * show variables with unboxed types. * tabs go wrong with :list (but only for .lhs files, because unlit does tab expansion... duh) == unknown, or require thinking about == * Some kind of "step over" or "next" command is needed. * `:break ` only works if the name is exported can/should we relax this? * perhaps we should have a :watch command, that could be used to save variables for future inspection (they wouldn't get thrown away by :continue) * We can disable a breakpoint with ":set stop N :continue", but this still prints out the breakpoint info when we stop. Should we print the info only if there were no commands? * Revert to adding tick information to the BCO directly, and remove the byte code instructions for breaks. I'm not sure that this is worth it. In some ways the implementation based on a byte code instruction is a little cleaner than adding breaks on BCOs directly. Though the bc instruction method may be a little slower than the other way. * Flag to disable breakpoints? * When we restore the interactive context on resume, we throw away any new bindings made since the breakpoint. Can this be fixed? * threads and breakpoints. * if a :force results in a breakpoint, we should treat it as we do other evaluations. (currently we get "*** Ignoring breakpoint"). * It's a bit strange that in "f = e" you don't get a breakpoint covering the whole binding, but in "f x = e" you do. Comment (by simonmar): removing a couple of items that are done or have other tickets. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Wed Oct 10 05:43:06 2007 From: trac at haskell.org (GHC) Date: Wed Oct 10 05:41:38 2007 Subject: [GHC] #1746: GADT bug with -O2 In-Reply-To: <044.8f91bba4a07480b117d876a4589faf2a@localhost> References: <044.8f91bba4a07480b117d876a4589faf2a@localhost> Message-ID: <053.e0321bce1abdf5c031314f372dcba2bb@localhost> #1746: GADT bug with -O2 -------------------------+-------------------------------------------------- Reporter: igloo | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.8.1 Component: Compiler | Version: 6.8 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: simpl019 Architecture: Unknown | -------------------------+-------------------------------------------------- Changes (by simonpj): * owner: => igloo * type: bug => merge Comment: Fixed. Please merge this patch {{{ Sat Sep 29 03:44:06 PDT 2007 simonpj@microsoft.com * Fix Trac #1746: make rule-matching work properly with Cast expressions The Cast case of the rule-matcher was simply wrong. This patch fixes it; see Trac #1746. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Wed Oct 10 05:43:57 2007 From: trac at haskell.org (GHC) Date: Wed Oct 10 05:42:28 2007 Subject: [GHC] #1737: cholewo-eval -dcore-lint failure in 6.8.1 In-Reply-To: <047.7da4639a3abe5850da58184bf767fdbf@localhost> References: <047.7da4639a3abe5850da58184bf767fdbf@localhost> Message-ID: <056.62dffd095674c9768b04c770a13138d6@localhost> #1737: cholewo-eval -dcore-lint failure in 6.8.1 -------------------------+-------------------------------------------------- Reporter: simonmar | Owner: igloo Type: merge | Status: new Priority: high | Milestone: 6.8.1 Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: cholewo-eval Architecture: Unknown | -------------------------+-------------------------------------------------- Changes (by simonpj): * owner: simonpj => igloo * type: bug => merge Comment: Fixed. Please merge this patch {{{ Wed Oct 10 02:33:34 PDT 2007 simonpj@microsoft.com * FIX: tidy up TcSimplify following equality constraints additions }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Wed Oct 10 06:04:22 2007 From: trac at haskell.org (GHC) Date: Wed Oct 10 06:02:54 2007 Subject: [GHC] #1038: selector thunks not working? space leak in standard example In-Reply-To: <057.5a8e52e5271fd3698ce0b00daf983780@localhost> References: <057.5a8e52e5271fd3698ce0b00daf983780@localhost> Message-ID: <066.dbc9538b6603967325bf7e538cc66739@localhost> #1038: selector thunks not working? space leak in standard example -----------------------------------+---------------------------------------- Reporter: tullsen@galois.com | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.8 branch Component: Runtime System | Version: 6.6 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Os: Multiple | Testcase: Architecture: x86 | -----------------------------------+---------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Now pushed, don't merge to the branch. {{{ Mon Sep 17 16:18:34 BST 2007 Simon Marlow * FIX #1038: failure of selector-thunk machinery to do its job }}} and a couple of subsequent fixes. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Wed Oct 10 06:11:52 2007 From: trac at haskell.org (GHC) Date: Wed Oct 10 06:10:24 2007 Subject: [GHC] #1553: Error in "nameModule header{v a1Ax}" In-Reply-To: <059.77b2ab2c53d63fb68b07687847f983cf@localhost> References: <059.77b2ab2c53d63fb68b07687847f983cf@localhost> Message-ID: <068.5e2ddcf2a5c422444c83860f843dfc01@localhost> #1553: Error in "nameModule header{v a1Ax}" -------------------------------------+-------------------------------------- Reporter: fkberthold@gmail.com | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.8 branch Component: GHCi | Version: 6.6.1 Severity: normal | Resolution: worksforme Keywords: | Difficulty: Unknown Os: Linux | Testcase: Architecture: x86 | -------------------------------------+-------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => worksforme Comment: Igloo couldn't reproduce, and no activity in over 2 months. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Wed Oct 10 06:13:44 2007 From: trac at haskell.org (GHC) Date: Wed Oct 10 06:12:16 2007 Subject: [GHC] #1393: Tag source tree with successful bootstraps In-Reply-To: <044.3c4dd632bdfa952e1d795c84e142ba3c@localhost> References: <044.3c4dd632bdfa952e1d795c84e142ba3c@localhost> Message-ID: <053.15536ca628ae53c45a2cab06d5990a23@localhost> #1393: Tag source tree with successful bootstraps ------------------------+--------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: _|_ Component: None | Version: 6.7 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | ------------------------+--------------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => wontfix Comment: validate has superceded these ideas, the tree now bootstraps 99% of the time. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Wed Oct 10 06:19:58 2007 From: trac at haskell.org (GHC) Date: Wed Oct 10 06:18:29 2007 Subject: [GHC] #1141: Add extra completion functionality to readline package In-Reply-To: <045.0212d612796530ca4b511ec8dad3c8ab@localhost> References: <045.0212d612796530ca4b511ec8dad3c8ab@localhost> Message-ID: <054.f31e3de71e5792aa912d7989a3276902@localhost> #1141: Add extra completion functionality to readline package ----------------------------------+----------------------------------------- Reporter: judahj | Owner: simonmar Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | ----------------------------------+----------------------------------------- Changes (by simonmar): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Wed Oct 10 06:20:11 2007 From: trac at haskell.org (GHC) Date: Wed Oct 10 06:18:44 2007 Subject: [GHC] #998: Tab-completion of filenames does not work in GHCi 6.6 In-Reply-To: <061.a0a29a0da74b1264616768b293fe2c41@localhost> References: <061.a0a29a0da74b1264616768b293fe2c41@localhost> Message-ID: <070.6ded111b418149c8733ae7952a7a849a@localhost> #998: Tab-completion of filenames does not work in GHCi 6.6 ---------------------------------------+------------------------------------ Reporter: dm.maillists@gmail.com | Owner: simonmar Type: bug | Status: new Priority: low | Milestone: 6.8 branch Component: GHCi | Version: 6.6 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Os: Linux | Testcase: Architecture: x86_64 (amd64) | ---------------------------------------+------------------------------------ Changes (by simonmar): * owner: judahj => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Wed Oct 10 08:18:09 2007 From: trac at haskell.org (GHC) Date: Wed Oct 10 08:16:41 2007 Subject: [GHC] #1141: Add extra completion functionality to readline package In-Reply-To: <045.0212d612796530ca4b511ec8dad3c8ab@localhost> References: <045.0212d612796530ca4b511ec8dad3c8ab@localhost> Message-ID: <054.d94e0eede4cf9a55c3c3003286291361@localhost> #1141: Add extra completion functionality to readline package ----------------------------------+----------------------------------------- Reporter: judahj | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.8.1 Component: libraries (other) | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | ----------------------------------+----------------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: proposal => merge * milestone: Not GHC => 6.8.1 Comment: Patch pushed; thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Wed Oct 10 08:19:23 2007 From: trac at haskell.org (GHC) Date: Wed Oct 10 08:17:54 2007 Subject: [GHC] #1756: Miscellaneous fixes to validate on PPC Mac OS X In-Reply-To: <050.2a7d557b3a06f6a1e7ad320b954aede6@localhost> References: <050.2a7d557b3a06f6a1e7ad320b954aede6@localhost> Message-ID: <059.6b8fa1a2eebcd2997cd93e72930d0ce9@localhost> #1756: Miscellaneous fixes to validate on PPC Mac OS X ----------------------------+----------------------------------------------- Reporter: thorkilnaur | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: MacOS X | Testcase: Architecture: powerpc | ----------------------------+----------------------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: Patches pushed, thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Wed Oct 10 08:20:47 2007 From: trac at haskell.org (GHC) Date: Wed Oct 10 08:19:18 2007 Subject: [GHC] #431: runInteractiveProcess and closed stdin. In-Reply-To: <045.572dbbd9b6b46d3f7b1e78158be38aba@localhost> References: <045.572dbbd9b6b46d3f7b1e78158be38aba@localhost> Message-ID: <054.c059f2110b7043607ece94be7dc9bfb7@localhost> #431: runInteractiveProcess and closed stdin. -------------------------------+-------------------------------------------- Reporter: nobody | Owner: Type: bug | Status: new Priority: low | Milestone: 6.8 branch Component: libraries/base | Version: 6.4 Severity: normal | Resolution: None Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -------------------------------+-------------------------------------------- Changes (by simonmar): * status: assigned => new * owner: simonmar => -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Wed Oct 10 08:22:39 2007 From: trac at haskell.org (GHC) Date: Wed Oct 10 08:21:13 2007 Subject: [GHC] #1681: :abandon in an exception breakpoint can lead ghci to freeze later In-Reply-To: <047.103fc822a5ce6ceaf0fc171d148e5bbc@localhost> References: <047.103fc822a5ce6ceaf0fc171d148e5bbc@localhost> Message-ID: <056.0a5621c7aba867f6e5ad561e7ee6564d@localhost> #1681: :abandon in an exception breakpoint can lead ghci to freeze later -------------------------+-------------------------------------------------- Reporter: mnislaih | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.8 branch Component: GHCi | Version: 6.8 Severity: normal | Resolution: Keywords: debugger | Difficulty: Unknown Os: Unknown | Testcase: break025 Architecture: Unknown | -------------------------+-------------------------------------------------- Changes (by simonmar): * owner: simonmarhaskell@gmail.com => igloo * type: bug => merge Comment: Fixed: {{{ Wed Oct 10 09:58:20 BST 2007 Simon Marlow * FIX #1681: withBreakAction had too large a scope in runStmt }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Wed Oct 10 09:51:59 2007 From: trac at haskell.org (GHC) Date: Wed Oct 10 09:50:31 2007 Subject: [GHC] #1769: Deriving Typeable for data families Message-ID: <043.a8c50ce2867b0958e6401d0ebd4755e7@localhost> #1769: Deriving Typeable for data families --------------------------------------+------------------------------------- Reporter: chak | Owner: chak Type: task | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Keywords: Difficulty: Unknown | Os: Unknown Testcase: | Architecture: Unknown --------------------------------------+------------------------------------- See Simon's proposal in the attachment. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Wed Oct 10 10:07:36 2007 From: trac at haskell.org (GHC) Date: Wed Oct 10 10:06:23 2007 Subject: [GHC] #1770: GHCi should know about itself, so that .ghci can be portable Message-ID: <044.9c0fae4620143e259ed2262a97a1fb04@localhost> #1770: GHCi should know about itself, so that .ghci can be portable ------------------------------+--------------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.6.1 Severity: normal | Keywords: Difficulty: Unknown | Os: Unknown Testcase: | Architecture: Unknown ------------------------------+--------------------------------------------- i've recently found myself writing .ghci files for ghc head which, with a few changes, can be made to work with 6.6.1 as well. then someone reported that they produce errors on his system (apparently, some people still have to use 6.4.1, for whatever reason). there are now two versions of the .ghci file: one for 6.4.1, one for 6.6.1 and later. it would be useful if ghci could be queried about itself. since the query results need to be processed further, queries should be functions. i propose an implicitly loaded namespace GHCi. for such queries. examples: {{{ GHCi.version :: [Int] -- version number GHCi.info :: [(String,String)] -- the results of +RTS --info on the current ghci GHCi.docdir :: String -- the result of --print-docdir GHCi.libdir :: String -- the result of --print-libdir GHCi.exists :: String -> Bool -- commands defined, flags available GHCi.has :: String -> Bool -- features availabe }}} there are an increasing number of ghc options that provide information not easily available in ghci (calling ":!ghc --version" gives no guarantee of reaching the right version of ghc! using Config.cProjectVersion was not available in 6.4.1, and requires loading -package ghc, which might leave residues/instances for the rest of the session). all of those information flags should have ghci equivalents. functions GHCi.exists and GHCi.has are inspired by established practice in vim: the former gives information about specific items (commands defined, flags accepted), the latter gives information about more general feature sets (debugger available? threads available?). {{{ GHCi.exists "-fno-print-bind-result" -- false in 6.4.1 GHCi.exists ":edit" -- true from 6.6.1 on GHCi.exists ":cmd" -- true from somewhere in 6.7.x onwards GHCi.has "debugger" -- true from somewhere in 6.7.x onwards }}} no, we can't backpatch 6.4.1 or 6.6.1, but 6.8.1 will still be around when 7.x is in standard use, so the sooner the better. (related to #1765, which was not by me;-) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Wed Oct 10 10:52:57 2007 From: trac at haskell.org (GHC) Date: Wed Oct 10 10:51:27 2007 Subject: [GHC] #1768: More flexible type signatures for data constructors In-Reply-To: <046.e80dabea24186dabb3849f7f5dbd4d5b@localhost> References: <046.e80dabea24186dabb3849f7f5dbd4d5b@localhost> Message-ID: <055.a35adf9d8465eed687f5f8b562ab0178@localhost> #1768: More flexible type signatures for data constructors --------------------------------+------------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: low | Milestone: _|_ Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | --------------------------------+------------------------------------------- Comment (by Isaac Dupree): A more limited generalization would be to allow the result type to be a type synonym: {{{ type Foo a = T (Maybe a) [a] data T a b where C :: !Int -> Foo Int D { unD :: !Int } :: Foo Int }}} This is mostly relevant/useful when the GADT has more than one type argument. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Wed Oct 10 10:53:07 2007 From: trac at haskell.org (GHC) Date: Wed Oct 10 10:51:39 2007 Subject: [GHC] #1678: runIO does not catch userErrors, just causes code generation to fail silently In-Reply-To: <046.bc948bd9c2636f4cf17c06da42db4989@localhost> References: <046.bc948bd9c2636f4cf17c06da42db4989@localhost> Message-ID: <055.6967dfc9d882b04b641c3cd71c22e82a@localhost> #1678: runIO does not catch userErrors, just causes code generation to fail silently ---------------------------------+------------------------------------------ Reporter: greenrd | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.1 Component: Template Haskell | Version: 6.7 Severity: normal | Resolution: Keywords: runIO regression | Difficulty: Unknown Os: Linux | Testcase: TH_runIO Architecture: x86_64 (amd64) | ---------------------------------+------------------------------------------ Changes (by simonpj): * testcase: => TH_runIO -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Wed Oct 10 11:00:55 2007 From: trac at haskell.org (GHC) Date: Wed Oct 10 10:59:27 2007 Subject: [GHC] #1678: runIO does not catch userErrors, just causes code generation to fail silently In-Reply-To: <046.bc948bd9c2636f4cf17c06da42db4989@localhost> References: <046.bc948bd9c2636f4cf17c06da42db4989@localhost> Message-ID: <055.16b45fec1414764d1f3ab684e5e10935@localhost> #1678: runIO does not catch userErrors, just causes code generation to fail silently ---------------------------------+------------------------------------------ Reporter: greenrd | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.8.1 Component: Template Haskell | Version: 6.7 Severity: normal | Resolution: Keywords: runIO regression | Difficulty: Unknown Os: Linux | Testcase: TH_runIO Architecture: x86_64 (amd64) | ---------------------------------+------------------------------------------ Changes (by simonpj): * owner: => igloo * type: bug => merge Comment: Fixed. The exception handling in `TcSplice` is a bit tricky, so I've added a comment (`Note [Exceptions in TH]`). Merge this to stable {{{ Wed Oct 10 15:57:05 BST 2007 simonpj@microsoft.com * Fix Trac #1678; be more careful about catching and reporting exceptions in spliced TH monadic computations }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Wed Oct 10 11:20:06 2007 From: trac at haskell.org (GHC) Date: Wed Oct 10 11:18:38 2007 Subject: [GHC] #1755: Template Haskell quoting bug In-Reply-To: <044.67fbf5a6611c354aa89760a29b6b810d@localhost> References: <044.67fbf5a6611c354aa89760a29b6b810d@localhost> Message-ID: <053.61486df4100158c877319205a79ff8d9@localhost> #1755: Template Haskell quoting bug ---------------------------------+------------------------------------------ Reporter: guest | Owner: igloo Type: merge | Status: new Priority: low | Milestone: Component: Template Haskell | Version: 6.6.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: TH_qname Architecture: Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * testcase: => TH_qname * owner: => igloo * type: bug => merge Comment: Excellent point, thank you Keigo. Fixed. Ian, please merge this patch: {{{ Wed Oct 10 16:02:50 GMT Daylight Time 2007 simonpj@microsoft.com * Fix Trac #1755; check for stage errors in TH quoted Names }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Wed Oct 10 11:45:50 2007 From: trac at haskell.org (GHC) Date: Wed Oct 10 11:44:21 2007 Subject: [GHC] #1752: space leak caused by $ vs. () with -O2 In-Reply-To: <044.242b3a9dbfb747650cb39adff39f19dc@localhost> References: <044.242b3a9dbfb747650cb39adff39f19dc@localhost> Message-ID: <053.d81852821f3ec48136a75dde6b9d2224@localhost> #1752: space leak caused by $ vs. () with -O2 -------------------------+-------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: low | Milestone: _|_ Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Windows | Testcase: Architecture: Multiple | -------------------------+-------------------------------------------------- Changes (by simonpj): * priority: normal => low * milestone: => _|_ Comment: I don't think it's anything to do with the "$"; both versions leak in GHC 6.6.1 and 6.8. Heres is a boiled-down version: {{{ module Main(main) where fibs a b = a : fibs b (a+b) odds (x:y:ys) = x : odds ys main = print $ zipWith (==) (odds (fibs 0 1)) (fibs 0 1) }}} Try compiling with -O and running with {{{ ./leak +RTS -Sstderr > /dev/null }}} What happens is that GHC does commmon-subexpression on the `(fibs 0 1)` to give: {{{ fibs01 = fibs 0 1 main = print $ zipWith (==) (odds fibs01) fibs01 }}} Now the left argument of `zipWith` marches down the infinite twice as fast as the right argument, so there's an ever-increasing chunk in between the two. See the chapter on pragmatics in my 1987 book. If you switch off common sub-expression `-fno-cse` then all is happy again. I don't know how to fix this. We also get bug reports about unexpected ''lack'' of commmon sub-expression, so it's a difficult transformation to get right! I'll leave it as low priority for now. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Wed Oct 10 12:52:59 2007 From: trac at haskell.org (GHC) Date: Wed Oct 10 12:51:32 2007 Subject: [GHC] #1759: HPC interaction with -Wall leading to spurious pattern match warnings In-Reply-To: <044.afb5b34428b1dacb9dc1d69f3c7f7e5e@localhost> References: <044.afb5b34428b1dacb9dc1d69f3c7f7e5e@localhost> Message-ID: <053.5a34ac1d324b686b5c4ccf5e27f13b90@localhost> #1759: HPC interaction with -Wall leading to spurious pattern match warnings -------------------------+-------------------------------------------------- Reporter: guest | Owner: igloo Type: merge | Status: new Priority: low | Milestone: Component: Compiler | Version: 6.8 Severity: normal | Resolution: Keywords: HPC | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -------------------------+-------------------------------------------------- Changes (by simonpj): * owner: => igloo * type: bug => merge Comment: Ah yes indeed. Fixed. Merge this patch: {{{ Wed Oct 10 17:47:31 BST 2007 simonpj@microsoft.com * Fix Trac #1759: do not let ticks get in the way of spotting trivially- true guards }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Wed Oct 10 13:12:55 2007 From: trac at haskell.org (GHC) Date: Wed Oct 10 13:11:34 2007 Subject: [GHC] #1226: Add flags --full-flag-help and --print-docdir In-Reply-To: <044.6dc8606b5b04e81a01eca3b1719deb81@localhost> References: <044.6dc8606b5b04e81a01eca3b1719deb81@localhost> Message-ID: <053.59704be57afe92193aaa3684874fa7ce@localhost> #1226: Add flags --full-flag-help and --print-docdir --------------------------------+------------------------------------------- Reporter: igloo | Owner: igloo Type: feature request | Status: new Priority: normal | Milestone: 6.8 branch Component: Driver | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | --------------------------------+------------------------------------------- Comment (by guest): just so that this doesn't get lost: there's a simple xslt file to extract text for a --full-flag-help option here http://www.haskell.org/pipermail/cvs-ghc/2007-September/038560.html it is simpler than the one for man pages, using sed to define the missing ENTITY references, and it brings each flag onto a single line, making it ideal for grep. now, for a first implementation of --full-flag-help, just generate the text file when creating a release/snapshot, install in `ghc --print- docdir`, and make the flag print the file (for bonus points, build in the pattern filter for those who don't have grep/awk at hand, so that --full- flag-help "interactive mode:" gives the ghci flags, and "language:instances" gives the language flags related to instances). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Wed Oct 10 16:59:29 2007 From: trac at haskell.org (GHC) Date: Wed Oct 10 16:57:59 2007 Subject: [GHC] #1771: hFileSize gives negative values Message-ID: <044.de7a3080a07f89d093c4293ba2bb2f42@localhost> #1771: hFileSize gives negative values -----------------------+---------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.6.1 Severity: normal | Keywords: hFileSize Difficulty: Unknown | Os: Windows Testcase: | Architecture: x86 -----------------------+---------------------------------------------------- hFileSize gives negative values for very big files. Tested several times it works properly except in two files. They have[[BR]] - 2.936.134.256 bytes[[BR]] - 3.846.960.665 bytes[[BR]] They are in NTFS in Windows XP SP2. Not able to test in Fat or in other OS. The next biggest file was 1.154.008.883 bytes and it worked fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Thu Oct 11 01:29:58 2007 From: trac at haskell.org (GHC) Date: Thu Oct 11 01:28:30 2007 Subject: [GHC] #1391: forkProcess() in Schedule.c with -threaded should initialize mutexes in child process (POSIX) In-Reply-To: <050.ab6642c28e13c00c6c4b9df378dcf986@localhost> References: <050.ab6642c28e13c00c6c4b9df378dcf986@localhost> Message-ID: <059.650a4d615915b084f4efa314810c7035@localhost> #1391: forkProcess() in Schedule.c with -threaded should initialize mutexes in child process (POSIX) -------------------------------+-------------------------------------------- Reporter: thorkilnaur | Owner: Type: bug | Status: closed Priority: high | Milestone: 6.8 branch Component: Runtime System | Version: 6.7 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Os: MacOS X | Testcase: forkprocess01(ghci) Architecture: powerpc | -------------------------------+-------------------------------------------- Changes (by thorkilnaur): * status: new => closed * resolution: => fixed Comment: That seems to have done it: With your patch, forkprocess01 succeeds every time and I no longer see the segmentation fault. Thanks and best regards Thorkil -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Thu Oct 11 01:36:50 2007 From: trac at haskell.org (GHC) Date: Thu Oct 11 01:35:20 2007 Subject: [GHC] #1391: forkProcess() in Schedule.c with -threaded should initialize mutexes in child process (POSIX) In-Reply-To: <050.ab6642c28e13c00c6c4b9df378dcf986@localhost> References: <050.ab6642c28e13c00c6c4b9df378dcf986@localhost> Message-ID: <059.24b32eaf3f0130c453f359b5fca205e9@localhost> #1391: forkProcess() in Schedule.c with -threaded should initialize mutexes in child process (POSIX) -------------------------------+-------------------------------------------- Reporter: thorkilnaur | Owner: Type: bug | Status: reopened Priority: high | Milestone: 6.8 branch Component: Runtime System | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: MacOS X | Testcase: forkprocess01(ghci) Architecture: powerpc | -------------------------------+-------------------------------------------- Changes (by thorkilnaur): * status: closed => reopened * resolution: fixed => Comment: Oh, I forgot, you mentioned perhaps pushing this to the stable branch, so I'll just reopen. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Thu Oct 11 01:37:55 2007 From: trac at haskell.org (GHC) Date: Thu Oct 11 01:36:25 2007 Subject: [GHC] #1391: forkProcess() in Schedule.c with -threaded should initialize mutexes in child process (POSIX) In-Reply-To: <050.ab6642c28e13c00c6c4b9df378dcf986@localhost> References: <050.ab6642c28e13c00c6c4b9df378dcf986@localhost> Message-ID: <059.88e2274d30755e49952eea9828a48851@localhost> #1391: forkProcess() in Schedule.c with -threaded should initialize mutexes in child process (POSIX) -------------------------------+-------------------------------------------- Reporter: thorkilnaur | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.8 branch Component: Runtime System | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: MacOS X | Testcase: forkprocess01(ghci) Architecture: powerpc | -------------------------------+-------------------------------------------- Changes (by thorkilnaur): * status: reopened => new * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Thu Oct 11 03:43:08 2007 From: trac at haskell.org (GHC) Date: Thu Oct 11 03:41:41 2007 Subject: [GHC] #1391: forkProcess() in Schedule.c with -threaded should initialize mutexes in child process (POSIX) In-Reply-To: <050.ab6642c28e13c00c6c4b9df378dcf986@localhost> References: <050.ab6642c28e13c00c6c4b9df378dcf986@localhost> Message-ID: <059.c8aa92958c372a29c845e46aab9044cd@localhost> #1391: forkProcess() in Schedule.c with -threaded should initialize mutexes in child process (POSIX) -------------------------------+-------------------------------------------- Reporter: thorkilnaur | Owner: igloo Type: merge | Status: new Priority: high | Milestone: 6.8.1 Component: Runtime System | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: MacOS X | Testcase: forkprocess01(ghci) Architecture: powerpc | -------------------------------+-------------------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge * milestone: 6.8 branch => 6.8.1 Comment: Following patches need to be merged: {{{ Tue Oct 9 13:24:09 BST 2007 Simon Marlow * also call initMutex on every task->lock, see #1391 Thu Sep 27 10:13:31 BST 2007 Simon Marlow * also acquire/release task->lock across fork() Fri Sep 14 15:55:19 BST 2007 Simon Marlow * attempt to fix #1391, hold locks across fork() and initialize them in the ch ild }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Thu Oct 11 08:36:26 2007 From: trac at haskell.org (GHC) Date: Thu Oct 11 08:34:53 2007 Subject: [GHC] #1680: Attempting to do foreign import with unboxed tuple return type causes GHC panic In-Reply-To: <045.309d12c5ea614ddc89360f362c200521@localhost> References: <045.309d12c5ea614ddc89360f362c200521@localhost> Message-ID: <054.fb778053cc01d8853177030df12a4802@localhost> #1680: Attempting to do foreign import with unboxed tuple return type causes GHC panic -------------------------------+-------------------------------------------- Reporter: sorear | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.8 branch Component: Compiler (FFI) | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Linux | Testcase: ccfail002 Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by simonpj): * testcase: => ccfail002 * owner: => igloo * type: bug => merge Comment: Thanks, excellent point. Now fixed. (A one line fix in `TcType`.) Ian, please merge {{{ Thu Oct 11 13:34:26 BST 2007 simonpj@microsoft.com * Fix Trac #1680; check for unboxed tuples in TcType.marshalableTyCon }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Thu Oct 11 10:20:42 2007 From: trac at haskell.org (GHC) Date: Thu Oct 11 10:19:11 2007 Subject: [GHC] #1767: :show does not conform to documented specification In-Reply-To: <044.e7adae11ca7979e3093e064a998ae30d@localhost> References: <044.e7adae11ca7979e3093e064a998ae30d@localhost> Message-ID: <053.b35c051d0d3dfcab05fd4beecf579bb3@localhost> #1767: :show does not conform to documented specification ------------------------+--------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | ------------------------+--------------------------------------------------- Changes (by guest): * cc: claus.reinke@talk21.com (added) Comment: first, you might want to add yourself to the cc of all those tickets you create - not only will this earn you an extra copy of each change email .., but ghc hq actually uses the number of cc's to assign ticket priorities. second, the help for :show currently mainly refers to ghci's :set features (args, prog, prompt, editor, ..), and 6.9.20070917 gives me this: {{{ Prelude> :show args [] Prelude> :show prompt "%s> " Prelude> :show editor "c:/vim/vim70/gvim.exe" Prelude> :set args 1 "two" Prelude> :show args ["1","two"] }}} third, it would be nice if all option/flag settings were available. there's a patch pending for head that makes ':set' show dynamic flag settings, with special emphasis on the ghci-specific ones. it also adds ':show languages' (listing active language flags) and ':show packages' (listing active package flags, and currently loaded packages). that still leaves lots of options like -l -i, etc, but it's a small step in the right direction. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Thu Oct 11 10:35:12 2007 From: trac at haskell.org (GHC) Date: Thu Oct 11 10:33:41 2007 Subject: [GHC] #95: GHCi editor binding with ":e" In-Reply-To: <052.52d2f4855a60cbba938e5d2b851635de@localhost> References: <052.52d2f4855a60cbba938e5d2b851635de@localhost> Message-ID: <061.b115fdc8865e8369d3f660faeabe705e@localhost> #95: GHCi editor binding with ":e" --------------------------------+------------------------------------------- Reporter: martijnislief | Owner: nobody Type: feature request | Status: assigned Priority: normal | Milestone: 6.8 branch Component: GHCi | Version: None Severity: minor | Resolution: None Keywords: | Difficulty: Easy (1 hr) Os: Unknown | Testcase: Architecture: Unknown | --------------------------------+------------------------------------------- Comment (by guest): actually, it turns out you can define all this even back in 6.4.1 (had i only known back then!-). you need to define your own :e command (:def is available), and ghci 6.4.1 is somewhat annoying about command names that are prefixes of each other. have a look at http://www.cs.kent.ac.uk/people/staff/cr3/toolbox/haskell/dot- squashed.ghci641 http://www.cs.kent.ac.uk/people/staff/cr3/toolbox/haskell/dot- squashed.ghci since .ghci files are not very readable with definitions squashed into single lines, you might want to check the explanations of the latter file in http://www.haskell.org/pipermail/haskell-cafe/2007-September/032260.html (note: the names in the 6.4.1 version differ from those in the described version) i'm not yet sure whether being able to define :e means that it shouldn't be part of ghci at all (and this ticket be closed), or whether there are still any advantages to having it built in? perhaps ghci releases should have a selection of .ghci files with useful definitions? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Thu Oct 11 17:45:15 2007 From: trac at haskell.org (GHC) Date: Thu Oct 11 17:43:42 2007 Subject: [GHC] #1772: GHC doesn't like 'inline' type function applications Message-ID: <049.17d3971582a0f9ef03fef648f597cd91@localhost> #1772: GHC doesn't like 'inline' type function applications --------------------------------------+------------------------------------- Reporter: jpbernardy | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.1 Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Keywords: Difficulty: Unknown | Os: Unknown Testcase: | Architecture: Unknown --------------------------------------+------------------------------------- {{{ {-# LANGUAGE TypeFamilies #-} import Prelude hiding (foldl, foldr, foldl1, foldr1, mapM_, sequence_, elem, notElem, concat, concatMap, and, or, any, all, sum, product, maximum, minimum) import Data.Monoid type family Element t class Foldable t where foldMap :: Monoid m => (Element t -> m) -> t -> m foldr :: (Element t -> b -> b) -> b -> t -> b -- foldr :: Element t ~ a => (a -> b -> b) -> b -> t -> b foldr f z t = appEndo (foldMap (Endo . f) t) z }}} GHC chokes on the above module. If the signature of foldr is replaced by the commented one, GHC is happy. It seems to me that the two expressions should be equivalent. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Fri Oct 12 10:44:02 2007 From: trac at haskell.org (GHC) Date: Fri Oct 12 10:42:31 2007 Subject: [GHC] #1758: misleading compiler error message in case of interface file inconsistency In-Reply-To: <044.54eab5ee0654e3c68ee78e6e3a9d8189@localhost> References: <044.54eab5ee0654e3c68ee78e6e3a9d8189@localhost> Message-ID: <053.472c257795075d6cbd04ac0420b2db7f@localhost> #1758: misleading compiler error message in case of interface file inconsistency -------------------------+-------------------------------------------------- Reporter: guest | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: MacOS X | Testcase: Architecture: powerpc | -------------------------+-------------------------------------------------- Changes (by igloo): * owner: => igloo * type: bug => merge Comment: {{{ Mon Oct 8 14:49:58 BST 2007 Simon Marlow * error message fix (#1758) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Fri Oct 12 17:37:17 2007 From: trac at haskell.org (GHC) Date: Fri Oct 12 17:35:43 2007 Subject: [GHC] #1680: Attempting to do foreign import with unboxed tuple return type causes GHC panic In-Reply-To: <045.309d12c5ea614ddc89360f362c200521@localhost> References: <045.309d12c5ea614ddc89360f362c200521@localhost> Message-ID: <054.45838bc6e7a4b2380d1a7ccc395d7828@localhost> #1680: Attempting to do foreign import with unboxed tuple return type causes GHC panic -------------------------------+-------------------------------------------- Reporter: sorear | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.8 branch Component: Compiler (FFI) | Version: 6.7 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Os: Linux | Testcase: ccfail002 Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at haskell.org Fri Oct 12 17:38:57 2007 From: trac at haskell.org (GHC) Date: Fri Oct 12 17:37:26 2007 Subject: [GHC] #1681: :abandon in an exception