From trac at galois.com Sun Mar 1 08:48:01 2009 From: trac at galois.com (GHC) Date: Sun Mar 1 08:36:49 2009 Subject: [GHC] #3055: Int / Word / IntN / WordN are unequally optimized Message-ID: <044.1c39597802e7cddf9bd2ebc2460d51ee@localhost> #3055: Int / Word / IntN / WordN are unequally optimized -------------------------------------+-------------------------------------- Reporter: claus | Owner: Type: run-time performance bug | Status: new Priority: normal | Component: Compiler Version: 6.11 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------------+-------------------------------------- A lot of thought has been put into optimizing usage of `Int`, but not all of these tweaks have been copied for usage of `Word`, and the specific- size versions of both have even fewer optimizations. The consequence is that switching from signed to unsigned, or from unspecified to specified size, can result in dramatic performance loss. - builtin rules (`prelude/PrelRules`) cover `Int` and `Word`, but not sized alternatives - `SPECIALI[SZ]E` pragmas cover `Int`, but little of the others. Try {{{ find libraries/ -name _darcs -prune -o -name *hs | xargs grep SPECIAL | grep '\ GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 1 17:22:08 2009 From: trac at galois.com (GHC) Date: Sun Mar 1 17:10:55 2009 Subject: [GHC] #3056: StrictAnal module naming issue Message-ID: <046.bf14dee7e90b3354e0823f5b9890979f@localhost> #3056: StrictAnal module naming issue -----------------------------+---------------------------------------------- Reporter: pumpkin | Owner: Type: proposal | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: trivial Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- I've been debating submitting this ticket for a couple of days because it may just make me look immature, but it seems like a strange way to abbreviate Strictness Analysis. The file I'm talking about is: compiler/stranal/StrictAnal.lhs Maybe this could/should be changed just for aesthetic reasons? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 1 17:55:38 2009 From: trac at galois.com (GHC) Date: Sun Mar 1 17:44:25 2009 Subject: [GHC] #3057: Standalone deriving of Functor does not work for HsDoc Message-ID: <044.a238214f97be82789d77ffa26a6dd377@localhost> #3057: Standalone deriving of Functor does not work for HsDoc -----------------------------+---------------------------------------------- Reporter: waern | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.11 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- I tried to use the new `DerivingFunctor` extension to derive `Functor` for the `HsDoc` type from the ghc package: {{{ {-# StandaloneDeriving, DerivingFunctor #-} import HsDoc deriving instance Functor HsDoc }}} But I got this error message: {{{ david@david-laptop:~/dev/test$ /home/david/ghc-head/bin/ghc --make Test.hs -package ghc [1 of 1] Compiling Test ( Test.hs, Test.o ) Test.hs:9:0: Couldn't match expected type `b' against inferred type `a' `b' is a rigid type variable bound by the type signature for `fmap' at `a' is a rigid type variable bound by the type signature for `fmap' at Expected type: HsDoc b Inferred type: HsDoc a In the first argument of `DocAppend', namely `a1' In the expression: DocAppend a1 a2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 2 00:49:43 2009 From: trac at galois.com (GHC) Date: Mon Mar 2 00:38:28 2009 Subject: [GHC] #3058: Add a 'hex' function to the pretty printing Message-ID: <044.e74c5c1ad7fed84ea73220aeb11ff713@localhost> #3058: Add a 'hex' function to the pretty printing -----------------------------------------+---------------------------------- Reporter: TomMD | Owner: Type: proposal | Status: new Priority: normal | Component: libraries/base Version: | Severity: normal Keywords: pretty, prettyprint, library | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------------------+---------------------------------- Attached is a patch for Text.PrettyPrint.HughesPJ that adds a 'hex' function to print hexidecimal numbers. The only point that I exepect to be contended is it varies slightly from the surrounding functions in that it allows one to control the number of characters printed (see below). > hex 5 31 0001f > hex 2 8 08 > hex 3 7495 d47 While we can argue about the consistancy issues, I almost always want to control the number of digits when I'm dealing with hex. Hence I feel this is a reasonable special case. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 2 05:13:34 2009 From: trac at galois.com (GHC) Date: Mon Mar 2 05:02:20 2009 Subject: [GHC] #3059: 3 different behaviours depending on profiling settings and on a used-only-once form being top-level Message-ID: <043.65beacb4ac206762f56576480f564413@localhost> #3059: 3 different behaviours depending on profiling settings and on a used-only- once form being top-level --------------------+------------------------------------------------------- Reporter: jkff | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Windows | Architecture: x86 --------------------+------------------------------------------------------- Below are two versions of a program using regex-tdfa-1.0. The versions differ in whether a form that is used exactly once in 'main' is top-level or declared inside 'where' in main. Both versions are compiled with/without profiling and the profiled version is called with/without +RTS -p. I obtain three drastically different performance results and, in the case where the form is top-level and profiling is turned on, a compilation bug is clearly seen. {{{ module Main where import Text.Regex.TDFA import qualified Data.ByteString.Lazy.Char8 as L import qualified Data.ByteString.Char8 as S main = putStrLn . show . length . filter (pat . S.concat . L.toChunks) . replicate 100000 $ L.pack "Hello world foo=123 whereas bar=456 Goodbye" pat = (=~ ".*foo=([0-9]+).*bar=([0-9]+).*") ghc -O2 --make regex-test.hs ./regex-test +RTS -s 0.00s ghc -O2 --make -prof -auto-all regex-test.hs ./regex-test +RTS -s 265.31s ./regex-test +RTS -p 276.84s 'compile' is called 100000 times. module Main where import Text.Regex.TDFA import qualified Data.ByteString.Lazy.Char8 as L import qualified Data.ByteString.Char8 as S main = putStrLn . show . length . filter (pat . S.concat . L.toChunks) . replicate 100000 $ L.pack "Hello world foo=123 whereas bar=456 Goodbye" where pat = (=~ ".*foo=([0-9]+).*bar=([0-9]+).*") ghc -O2 --make regex-test.hs ./regex-test +RTS -s 8.86s (I don't know how this result appeared: it is too small to result from 1mln regex compilations, but too big to be 'normal') ghc -O2 --make -prof -auto-all regex-test.hs ./regex-test +RTS -s 0.00s ./regex-test +RTS -p 0.00s 'compile' is called 2 times. }}} Core for the first program with/without profiling differs in the aspect that with profiling, the partial application (=~) does not get memoized. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 2 06:08:53 2009 From: trac at galois.com (GHC) Date: Mon Mar 2 05:57:37 2009 Subject: [GHC] #2923: Documentation contains (broken) links to /home/ian In-Reply-To: <047.8599083b3310893fae769d528dbb6224@localhost> References: <047.8599083b3310893fae769d528dbb6224@localhost> Message-ID: <056.03922e75510557c5022ddbf49b9558c7@localhost> #2923: Documentation contains (broken) links to /home/ian ---------------------------------+------------------------------------------ Reporter: matthijs | Owner: igloo Type: bug | Status: closed Priority: high | Milestone: 6.10.2 Component: Documentation | Version: Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by matthijs): The links are still wrong on the latest documentation online. I guess that your comment means that this will be fixed in the next release, then. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 2 06:38:40 2009 From: trac at galois.com (GHC) Date: Mon Mar 2 06:27:28 2009 Subject: [GHC] #2619: Can't build older compiler In-Reply-To: <044.186108a575a6c194091f1f6cfd66d1a5@localhost> References: <044.186108a575a6c194091f1f6cfd66d1a5@localhost> Message-ID: <053.2d7f13f8f1be40c8a37af8307a823c7e@localhost> #2619: Can't build older compiler ---------------------------------+------------------------------------------ Reporter: judah | Owner: Type: bug | Status: reopened Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by chak): * status: closed => reopened * resolution: fixed => * summary: Can't build HEAD with ghc-6.10 => Can't build older compiler * version: 6.9 => 6.11 * architecture: x86 => Unknown/Multiple * os: MacOS X => Unknown/Multiple Comment: Roman and I just wasted a day on this bug. The problem appears when you try to build a compiler with a version number lower than that of the bootstrapping compiler. (In the above report, ghc-6.9.20080920 built with 6.10.0.20080921.) And the culprit is to nobody's surprise Cabal and/or it's (ab)use in GHC's build system. The exact cause is that after the stage1 ghc package has been built, cabal-bin is invoked to compile and link `ghc/Main.hs`. The '''version''' of the ghc package against which the compiler Main.hs is to be compiled and linked is, however, not explicitly specified and cabal in it's infinite wisdom decides to pick the one with the higher version number. This happens to be the ghc package of the bootstrap compiler (if it's version number is higher), instead of the package just built. After that the build fails in one of a number of ways depending on how much the two compilers differ in the paths that they have been configured with etc. The error message reported above is one of possible failures, but Roman and I had at least two others (picking the wrong version of GCC depending on what is in `compiler/main/Config.hs` and dying because the versions of the stage1 ghc -which really is just another version of the bootstrap compiler- and ghc-pkg don't match up). People usually don't compile older with newer compilers, but it is sometimes useful; for example, if you try to bootstrap a Haskell environment on an exotic architecture - that was our use case. So, the build system should handle this properly. When can we finally get rid of Cabal and use the new build system? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 2 07:03:07 2009 From: trac at galois.com (GHC) Date: Mon Mar 2 06:51:56 2009 Subject: [GHC] #3059: 3 different behaviours depending on profiling settings and on a used-only-once form being top-level In-Reply-To: <043.65beacb4ac206762f56576480f564413@localhost> References: <043.65beacb4ac206762f56576480f564413@localhost> Message-ID: <052.eb59de844f723e5604be2e0e1e92c187@localhost> #3059: 3 different behaviours depending on profiling settings and on a used-only- once form being top-level ----------------------+----------------------------------------------------- Reporter: jkff | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Windows | Architecture: x86 ----------------------+----------------------------------------------------- Comment (by ChrisKuklewicz): {{{ module Text.Regex.TDFA.Wrap... (=~) :: (RegexMaker Regex CompOption ExecOption source,RegexContext Regex source1 target) => source1 -> source -> target (=~) x r = let make :: RegexMaker Regex CompOption ExecOption a => a -> Regex make = makeRegex in match (make r) x }}} The =~ API is very high level ??if you need to cache the compiled regular expression then you should not depend on the compiler, but rather use "makeRegex" explicitly. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 2 07:07:27 2009 From: trac at galois.com (GHC) Date: Mon Mar 2 06:56:13 2009 Subject: [GHC] #3059: 3 different behaviours depending on profiling settings and on a used-only-once form being top-level In-Reply-To: <043.65beacb4ac206762f56576480f564413@localhost> References: <043.65beacb4ac206762f56576480f564413@localhost> Message-ID: <052.2d01d9ce52e0de13dc90d5349cb28781@localhost> #3059: 3 different behaviours depending on profiling settings and on a used-only- once form being top-level ----------------------+----------------------------------------------------- Reporter: jkff | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Windows | Architecture: x86 ----------------------+----------------------------------------------------- Comment (by jkff): Thanks; however, the question of why addition of profiling changes the behaviour so much remains. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 2 07:10:46 2009 From: trac at galois.com (GHC) Date: Mon Mar 2 06:59:34 2009 Subject: [GHC] #2619: Can't build older compiler In-Reply-To: <044.186108a575a6c194091f1f6cfd66d1a5@localhost> References: <044.186108a575a6c194091f1f6cfd66d1a5@localhost> Message-ID: <053.b9e2d00c38cb70cb31fc2df82a1333ba@localhost> #2619: Can't build older compiler ---------------------------------+------------------------------------------ Reporter: judah | Owner: Type: bug | Status: reopened Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by duncan): Whatever system is used, the version of the package that is intended should be specified explicitly or the same thing will happen. ghc also picks the highest version when you do not tell it otherwise. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 2 10:33:06 2009 From: trac at galois.com (GHC) Date: Mon Mar 2 10:21:54 2009 Subject: [GHC] #2619: Can't build older compiler In-Reply-To: <044.186108a575a6c194091f1f6cfd66d1a5@localhost> References: <044.186108a575a6c194091f1f6cfd66d1a5@localhost> Message-ID: <053.c5f8bb7fd6211ddb9c7b826bd02aafd6@localhost> #2619: Can't build older compiler ---------------------------------+------------------------------------------ Reporter: judah | Owner: Type: bug | Status: reopened Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by igloo): Like Duncan says, this is not related to whether Cabal is used for building or not. In either case you need to tell Cabal or GHC which version to use. As it happens, it looks like this is already done in the new build system. While we will fix problems where it is not too burdensome to do so, building an older compiler with a newer compiler is not supported; from http://hackage.haskell.org/trac/ghc/wiki/Building/Prerequisites: {{{ GHC can be built using either an earlier released version of GHC (currently 6.6 and later are supported), or bootstrapped using a GHC built from exactly the same sources. Note that this means you cannot in general build GHC using an arbitrary development snapshot, or a build from say last week. It might work, it might not - we don't guarantee anything. To be on the safe side, start your build using the most recently released stable version of GHC. In general, we support building with the previous 2 major releases, so: * To build 6.8.* you need GHC >= 6.4 * To build 6.10.* you need GHC >= 6.6 }}} There are good reasons we don't support it: New compilers may need different flags, provide libraries with different interfaces, etc, and the old version's build system can't anticipate that. It's also not something that we can really test. As far as I know, configure doesn't enforce this policy at all. We could make it fail if the bootstrapping compiler is: * too old (more than 2 major releases older than the version we are compiling. We couldn't do this properly for the change from 6.x to 7.x) * too new (newer than the version we are compiling) * a snapshot and not the same version as we are building unless a `--force` flag is given. As it's easier for buildbot clients to use the same version for both STABLE and HEAD, this would probably mean that we'd keep supporting 6.6 in 6.11, and only drop support once it becomes 6.12 and we stop building 6.10. We already do that in practice anyway. What do people think? > When can we finally get rid of Cabal and use the new build system? At the top of `ghc.mk`, there's a list of things that need to be done in the new build system before it can be merged into the HEAD: http://darcs.haskell.org/ghc-new-build-system/ghc.mk -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 2 10:57:57 2009 From: trac at galois.com (GHC) Date: Mon Mar 2 10:46:46 2009 Subject: [GHC] #2619: Can't build older compiler In-Reply-To: <044.186108a575a6c194091f1f6cfd66d1a5@localhost> References: <044.186108a575a6c194091f1f6cfd66d1a5@localhost> Message-ID: <053.a2d031a9a604a1c9e134fffcf4767bb4@localhost> #2619: Can't build older compiler ---------------------------------+------------------------------------------ Reporter: judah | Owner: Type: bug | Status: reopened Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by rl): FWIW, we don't have an earlier released version which we could use since GHC without a functioning NCG is practically unusable on Sparc T2. We can compile a bare-bones GHC with 6.8.2 but that takes about a day and is something we can only really do once. This means that we will be using a 6.11 snapshot as our compiler until 6.12 is released. A similar situation will occur whenever someone ports GHC to a new architecture. Not supporting this doesn't sound like a good idea to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 2 11:53:06 2009 From: trac at galois.com (GHC) Date: Mon Mar 2 11:41:49 2009 Subject: [GHC] #2942: witten/ghc-6.10.1-powerpc-apple-darwin.tar.bz2: make install fails on case-sensitive file system In-Reply-To: <050.2d88d56a844b36381f7e789271b08f2d@localhost> References: <050.2d88d56a844b36381f7e789271b08f2d@localhost> Message-ID: <059.339b4fe51f91c7048f1fb28a90eb0433@localhost> #2942: witten/ghc-6.10.1-powerpc-apple-darwin.tar.bz2: make install fails on case- sensitive file system ----------------------------+----------------------------------------------- Reporter: thorkilnaur | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.10.2 Component: None | Version: 6.10.1 Severity: normal | Resolution: worksforme Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: powerpc | ----------------------------+----------------------------------------------- Comment (by thorkilnaur): Thanks a lot. Note that it is {{{dist-install/build/haddock/haddock}}} that is reported as missing, not {{{dist-install/build/Haddock/haddock}}}. And the fix is to create {{{utils/haddock/dist-install/build/haddock -> Haddock}}}. I can reproduce the problem as follows: {{{ $ tar xjf /Volumes/tn18_HD_1/Users/thorkilnaur/tn/download/GHC/www.haskell.org/ghc/dist/6.10.1/witten/ghc-6.10.1 -powerpc-apple-darwin.tar.bz2 $ cd ghc-6.10.1/dist/ $ ./configure --prefix=/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B checking build system type... powerpc-apple-darwin9.6.0 checking host system type... powerpc-apple-darwin9.6.0 checking target system type... powerpc-apple-darwin9.6.0 Which we'll further canonicalise into: powerpc-apple-darwin checking for path to top of build tree... /Users/thorkilnaur/tn/test/GHC/trac/2942/work/unpack/ghc-6.10.1/dist checking for perl... /usr/bin/perl checking if your perl works in shell scripts... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether ln -s works... yes checking for ar... /usr/bin/ar checking whether /usr/bin/ar is GNU ar... no checking for ar arguments... clqs checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking whether ranlib is needed... yes checking for ranlib... ranlib checking for sed... /usr/bin/sed checking version of gcc... 4.0.1 checking how to run the C preprocessor... gcc -E checking for extra options to pass gcc when compiling via C... -fwrapv configure: creating ./config.status config.status: creating Makefile-vars config.status: creating extra-gcc-opts **************************************************** Configuration done, ready to 'make install' (see README and INSTALL files for more info.) **************************************************** $ make install /Users/thorkilnaur/tn/test/GHC/trac/2942/work/unpack/ghc-6.10.1/dist/utils/mkdirhier/mkdirhier /Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B/bin mkdir /Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B mkdir /Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B/bin make -C includes install DOING_BIN_DIST=YES /Users/thorkilnaur/tn/test/GHC/trac/2942/work/unpack/ghc-6.10.1/dist/utils/mkdirhier/mkdirhier /Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B/lib/ghc-6.10.1/include mkdir /Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B/lib mkdir /Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B/lib/ghc-6.10.1 mkdir /Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B/lib/ghc-6.10.1/include for i in Block.h Bytecodes.h ClosureMacros.h ClosureTypes.h Closures.h Cmm.h Constants.h DNInvoke.h DerivedConstants.h Dotnet.h FileLock.h GHCConstants.h GranSim.h Hooks.h HsFFI.h InfoTables.h Linker.h Liveness.h MachDeps.h MachRegs.h OSThreads.h Parallel.h Regs.h Rts.h RtsAPI.h RtsConfig.h RtsExternal.h RtsFlags.h RtsMessages.h RtsTypeable.h RtsTypes.h SMP.h SMPClosureOps.h STM.h SchedAPI.h Signals.h SpinLock.h Stable.h Stg.h StgDLL.h StgFun.h StgLdvProf.h StgMiscClosures.h StgProf.h StgTypes.h Storage.h TSO.h TailCalls.h TickyCounters.h config.h ghcconfig.h ieee-flpt.h ghcautoconf.h ghcplatform.h; do \ /usr/bin/install -c -m 644 $i /Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B/lib/ghc-6.10.1/include; \ done make -C utils install DOING_BIN_DIST=YES ------------------------------------------------------------------------ == Recursively making `install' in mkdirhier hp2ps parallel unlit ... PWD = /Users/thorkilnaur/tn/test/GHC/trac/2942/work/unpack/ghc-6.10.1/dist/utils ------------------------------------------------------------------------ ------------------------------------------------------------------------ == make install ; in /Users/thorkilnaur/tn/test/GHC/trac/2942/work/unpack/ghc-6.10.1/dist/utils/mkdirhier ------------------------------------------------------------------------ make[2]: Nothing to be done for `install'. Finished making install in mkdirhier: 0 ------------------------------------------------------------------------ == make install ; in /Users/thorkilnaur/tn/test/GHC/trac/2942/work/unpack/ghc-6.10.1/dist/utils/hp2ps ------------------------------------------------------------------------ /Users/thorkilnaur/tn/test/GHC/trac/2942/work/unpack/ghc-6.10.1/dist/utils/mkdirhier/mkdirhier /Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B/bin for i in hp2ps; do \ /usr/bin/install -c -m 755 -m 755 $i /Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B/bin ; \ if test "" = "1"; then \ sh /mk/fix_install_names.sh /Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B/lib/ghc-6.10.1 /Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B/bin/$i ; \ fi ; \ done Finished making install in hp2ps: 0 ------------------------------------------------------------------------ == make install ; in /Users/thorkilnaur/tn/test/GHC/trac/2942/work/unpack/ghc-6.10.1/dist/utils/parallel ------------------------------------------------------------------------ make[2]: Nothing to be done for `install'. Finished making install in parallel: 0 ------------------------------------------------------------------------ == make install ; in /Users/thorkilnaur/tn/test/GHC/trac/2942/work/unpack/ghc-6.10.1/dist/utils/unlit ------------------------------------------------------------------------ /Users/thorkilnaur/tn/test/GHC/trac/2942/work/unpack/ghc-6.10.1/dist/utils/mkdirhier/mkdirhier /Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B/lib/ghc-6.10.1 for i in unlit; do \ /usr/bin/install -c -m 755 -m 755 $i /Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B/lib/ghc-6.10.1; \ if test "" = "1"; then \ sh /mk/fix_install_names.sh /Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B/lib/ghc-6.10.1 /Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B/lib/ghc-6.10.1/`basename $i` ; \ fi ; \ done Finished making install in unlit: 0 ------------------------------------------------------------------------ == Finished making `install' in mkdirhier hp2ps parallel unlit ... PWD = /Users/thorkilnaur/tn/test/GHC/trac/2942/work/unpack/ghc-6.10.1/dist/utils ------------------------------------------------------------------------ make -C ghc-pkg install /Users/thorkilnaur/tn/test/GHC/trac/2942/work/unpack/ghc-6.10.1/dist/utils/installPackage /install-inplace/bin/installPackage install \ '/Users/thorkilnaur/tn/test/GHC/trac/2942/work/unpack/ghc-6.10.1/dist/utils /ghc-pkg/dist-install/build/ghc-pkg/ghc-pkg' \ '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B/lib/ghc-6.10.1/package.conf' \ '' '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B' \ '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B' '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B/bin' '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B/lib/ghc-6.10.1' \ '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B/lib/ghc-6.10.1' '' '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B/lib/ghc-6.10.1' \ '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B/share/doc/ghc' '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B/share/doc/ghc' '' \ --distpref dist-install \ --enable-shell-wrappers Installing executable(s) in /Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B/bin make -C hasktags install /Users/thorkilnaur/tn/test/GHC/trac/2942/work/unpack/ghc-6.10.1/dist/utils/installPackage /install-inplace/bin/installPackage install \ '/Users/thorkilnaur/tn/test/GHC/trac/2942/work/unpack/ghc-6.10.1/dist/utils /ghc-pkg/dist-install/build/ghc-pkg/ghc-pkg' \ '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B/lib/ghc-6.10.1/package.conf' \ '' '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B' \ '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B' '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B/bin' '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B/lib/ghc-6.10.1' \ '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B/lib/ghc-6.10.1' '' '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B/lib/ghc-6.10.1' \ '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B/share/doc/ghc' '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B/share/doc/ghc' '' \ --distpref dist-install \ Installing executable(s) in /Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B/bin make -C runghc install /Users/thorkilnaur/tn/test/GHC/trac/2942/work/unpack/ghc-6.10.1/dist/utils/installPackage /install-inplace/bin/installPackage install \ '/Users/thorkilnaur/tn/test/GHC/trac/2942/work/unpack/ghc-6.10.1/dist/utils /ghc-pkg/dist-install/build/ghc-pkg/ghc-pkg' \ '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B/lib/ghc-6.10.1/package.conf' \ '' '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B' \ '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B' '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B/bin' '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B/lib/ghc-6.10.1' \ '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B/lib/ghc-6.10.1' '' '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B/lib/ghc-6.10.1' \ '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B/share/doc/ghc' '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B/share/doc/ghc' '' \ --distpref dist-install \ --enable-shell-wrappers Installing executable(s) in /Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B/bin make -C hpc install /Users/thorkilnaur/tn/test/GHC/trac/2942/work/unpack/ghc-6.10.1/dist/utils/installPackage /install-inplace/bin/installPackage install \ '/Users/thorkilnaur/tn/test/GHC/trac/2942/work/unpack/ghc-6.10.1/dist/utils /ghc-pkg/dist-install/build/ghc-pkg/ghc-pkg' \ '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B/lib/ghc-6.10.1/package.conf' \ '' '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B' \ '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B' '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B/bin' '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B/lib/ghc-6.10.1' \ '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B/lib/ghc-6.10.1' '' '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B/lib/ghc-6.10.1' \ '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B/share/doc/ghc' '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B/share/doc/ghc' '' \ --distpref dist-install \ Installing executable(s) in /Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B/bin make -C haddock install /Users/thorkilnaur/tn/test/GHC/trac/2942/work/unpack/ghc-6.10.1/dist/utils/installPackage /install-inplace/bin/installPackage install \ '/Users/thorkilnaur/tn/test/GHC/trac/2942/work/unpack/ghc-6.10.1/dist/utils /ghc-pkg/dist-install/build/ghc-pkg/ghc-pkg' \ '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B/lib/ghc-6.10.1/package.conf' \ '' '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B' \ '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B' '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B/bin' '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B/lib/ghc-6.10.1' \ '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B/lib/ghc-6.10.1' '' '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B/lib/ghc-6.10.1' \ '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B/share/doc/ghc' '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B/share/doc/ghc' '' \ --distpref dist-install \ --enable-shell-wrappers Installing library in /Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B/lib/ghc-6.10.1/haddock-2.3.0 Installing executable(s) in /Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1_B/bin installPackage: dist-install/build/haddock/haddock: copyFile: does not exist (No such file or directory) make[2]: *** [install] Error 1 make[1]: *** [install.haddock] Error 2 make: *** [install] Error 2 $ }}} I have left the ticket closed. As mentioned, I have a work-around for this problem and I have no need for further activities related to this ticket. Thanks again and best regards Thorkil -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 2 11:56:12 2009 From: trac at galois.com (GHC) Date: Mon Mar 2 11:45:01 2009 Subject: [GHC] #2619: Can't build older compiler In-Reply-To: <044.186108a575a6c194091f1f6cfd66d1a5@localhost> References: <044.186108a575a6c194091f1f6cfd66d1a5@localhost> Message-ID: <053.6d5926e6f0cc1e6553240045e95bb327@localhost> #2619: Can't build older compiler ---------------------------------+------------------------------------------ Reporter: judah | Owner: Type: bug | Status: reopened Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by duncan): Replying to [comment:9 rl]: > FWIW, we don't have an earlier released version which we could use since GHC without a functioning NCG is practically unusable on Sparc T2. We can compile a bare-bones GHC with 6.8.2 but that takes about a day and is something we can only really do once. You should have asked! :-) We've got a working 6.8.3 and 6.10.x with -fvia-C and also HEAD with -fasm on the sparky T2. I expect we can make bindists using the sparky buildbot. It only takes ages to compile if you're using gcc-4.2.x or later. Using 4.1.x is fine. See [wiki:Building/Solaris#SelectingagoodGCCversion]. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 2 12:20:33 2009 From: trac at galois.com (GHC) Date: Mon Mar 2 12:09:16 2009 Subject: [GHC] #2942: witten/ghc-6.10.1-powerpc-apple-darwin.tar.bz2: make install fails on case-sensitive file system In-Reply-To: <050.2d88d56a844b36381f7e789271b08f2d@localhost> References: <050.2d88d56a844b36381f7e789271b08f2d@localhost> Message-ID: <059.a68817360f2168992cbb459af3aecc40@localhost> #2942: witten/ghc-6.10.1-powerpc-apple-darwin.tar.bz2: make install fails on case- sensitive file system ----------------------------+----------------------------------------------- Reporter: thorkilnaur | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.10.2 Component: None | Version: 6.10.1 Severity: normal | Resolution: worksforme Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: powerpc | ----------------------------+----------------------------------------------- Comment (by igloo): Just to clarify: I can reproduce the problem with this tarball, but I can't work out how such a tarball can be created. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 2 15:37:56 2009 From: trac at galois.com (GHC) Date: Mon Mar 2 15:26:40 2009 Subject: [GHC] #3060: impossible internal bug while building darcs Message-ID: <044.8b050eb370b3a248f628f79a0a5b8c10@localhost> #3060: impossible internal bug while building darcs -------------------+-------------------------------------------------------- Reporter: quick | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: major Keywords: | Testcase: Os: Linux | Architecture: x86 -------------------+-------------------------------------------------------- [ghc] src/Exec.o ghc: panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-unknown-linux): applyTypeToArgs unix-2.3.1.0:System.Posix.Signals.a38{v r8P} [gid] (unix-2.3.1.0:System.Posix.Signals.a5{v r8O} [gid] `cast` (ghc-prim:GHC.Prim.sym{(w) tc 34v} base:Foreign.C.Types.:CoCInt{tc r4P} :: base:GHC.Int.Int32{tc 3V} ~ base:Foreign.C.Types.CInt{tc r4S})) unix-2.3.1.0:System.Posix.Signals.Ignore{v r8N} [gid] (base:Data.Maybe.Nothing{v r4K} [gid] @ unix-2.3.1.0:System.Posix.Signals.SignalSet{tc r8M}) eta{v a1Vy} [lid] (# ghc-prim:GHC.Prim.State#{(w) tc 32q} ghc-prim:GHC.Prim.RealWorld{(w) tc 31E}, unix-2.3.1.0:System.Posix.Signals.SignalSet{tc r8M} #) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug While building darcs 2.2.0. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 2 17:12:43 2009 From: trac at galois.com (GHC) Date: Mon Mar 2 17:01:28 2009 Subject: [GHC] #427: Random.StdGen slowness In-Reply-To: <044.910d2f7eb299e5f5b612cc8fccf049ef@localhost> References: <044.910d2f7eb299e5f5b612cc8fccf049ef@localhost> Message-ID: <053.9b15f9cdf2b358e450fe9542c01a2de5@localhost> #427: Random.StdGen slowness ---------------------------------+------------------------------------------ Reporter: remit | Owner: Type: bug | Status: new Priority: low | Milestone: _|_ Component: libraries/random | Version: 6.4.1 Severity: normal | Resolution: None Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by Remi): * cc: rturk@science.uva.nl (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 2 17:31:33 2009 From: trac at galois.com (GHC) Date: Mon Mar 2 17:20:16 2009 Subject: [GHC] #427: Random.StdGen slowness In-Reply-To: <044.910d2f7eb299e5f5b612cc8fccf049ef@localhost> References: <044.910d2f7eb299e5f5b612cc8fccf049ef@localhost> Message-ID: <053.64d343cfe3f2604b58ef50059a7cab78@localhost> #427: Random.StdGen slowness ---------------------------------+------------------------------------------ Reporter: remit | Owner: Type: bug | Status: new Priority: low | Milestone: _|_ Component: libraries/random | Version: 6.4.1 Severity: normal | Resolution: None Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by duncan): See also http://haskell.org/pipermail/libraries/2009-March/011390.html It looks like just adding a bit of strictness to the `StdGen` constructor and to `getStdRandom` would improve things without much fuss. Probably needs 10 min to investigate the performance difference. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 2 17:31:35 2009 From: trac at galois.com (GHC) Date: Mon Mar 2 17:20:21 2009 Subject: [GHC] #2619: Can't build older compiler In-Reply-To: <044.186108a575a6c194091f1f6cfd66d1a5@localhost> References: <044.186108a575a6c194091f1f6cfd66d1a5@localhost> Message-ID: <053.b84e7267457831a4ceb6e83c1b989750@localhost> #2619: Can't build older compiler ---------------------------------+------------------------------------------ Reporter: judah | Owner: Type: bug | Status: reopened Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by chak): Replying to [comment:10 duncan]: > Replying to [comment:9 rl]: > > FWIW, we don't have an earlier released version which we could use since GHC without a functioning NCG is practically unusable on Sparc T2. We can compile a bare-bones GHC with 6.8.2 but that takes about a day and is something we can only really do once. > > You should have asked! :-) > > We've got a working 6.8.3 and 6.10.x with -fvia-C and also HEAD with -fasm on the sparky T2. I expect we can make bindists using the sparky buildbot. > > It only takes ages to compile if you're using gcc-4.2.x or later. Using 4.1.x is fine. See [wiki:Building/Solaris#SelectingagoodGCCversion]. We were going by what Ben reported on his blog and he seemed to use 4.2.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 2 17:44:09 2009 From: trac at galois.com (GHC) Date: Mon Mar 2 17:32:55 2009 Subject: [GHC] #2619: Can't build older compiler In-Reply-To: <044.186108a575a6c194091f1f6cfd66d1a5@localhost> References: <044.186108a575a6c194091f1f6cfd66d1a5@localhost> Message-ID: <053.54dab0bb8ee4c6dd35faf7d4d04c5074@localhost> #2619: Can't build older compiler ---------------------------------+------------------------------------------ Reporter: judah | Owner: Type: bug | Status: reopened Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by chak): Replying to [comment:8 igloo]: > While we will fix problems where it is not too burdensome to do so, building an older compiler with a newer compiler is not supported; from http://hackage.haskell.org/trac/ghc/wiki/Building/Prerequisites: [..] > There are good reasons we don't support it: New compilers may need different flags, provide libraries with different interfaces, etc, and the old version's build system can't anticipate that. It's also not something that we can really test. We were not trying to build a compiler one release back or something. It was a snapshot of HEAD built with a snapshot of HEAD from a few days earlier. Modulo the caveats of using the HEAD in the first place, there is no good reason why that should not work. At the time, we also didn't have darcs on the machine as that wouldn't build with an old Solaris snapshot we originally bootstrapped from and, the HEAD compile we had, didn't have the extralibs needed by darcs. Sure that's a situation where you are not surprised when things don't work out right away, but stage1 just morphing into a clone of the bootstrap compiler isn't quite what you expect either. > As far as I know, configure doesn't enforce this policy at all. We could make it fail if the bootstrapping compiler is: > * too old (more than 2 major releases older than the version we are compiling. We couldn't do this properly for the change from 6.x to 7.x) > * too new (newer than the version we are compiling) > * a snapshot and not the same version as we are building > unless a `--force` flag is given. As it's easier for buildbot clients to use the same version for both STABLE and HEAD, this would probably mean that we'd keep supporting 6.6 in 6.11, and only drop support once it becomes 6.12 and we stop building 6.10. We already do that in practice anyway. Sure, it might be a good idea to have configure check, but we knew what we where doing and didn't just compile an old version by accident. So, it wouldn't have helped anything in this case. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 2 18:22:46 2009 From: trac at galois.com (GHC) Date: Mon Mar 2 18:11:32 2009 Subject: [GHC] #427: Random.StdGen slowness In-Reply-To: <044.910d2f7eb299e5f5b612cc8fccf049ef@localhost> References: <044.910d2f7eb299e5f5b612cc8fccf049ef@localhost> Message-ID: <053.5290ee3cac5642ec2ba3a3e979edd4d5@localhost> #427: Random.StdGen slowness ---------------------------------+------------------------------------------ Reporter: remit | Owner: Type: bug | Status: new Priority: low | Milestone: _|_ Component: libraries/random | Version: 6.4.1 Severity: normal | Resolution: None Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by dons): Replying to [comment:11 duncan]: > See also http://haskell.org/pipermail/libraries/2009-March/011390.html > > It looks like just adding a bit of strictness to the `StdGen` constructor and to `getStdRandom` would improve things without much fuss. Probably needs 10 min to investigate the performance difference. Adding {-#UNPACK #-}!Int32 didn't help much. I think the problem may still be all the conversions via Integer. Here, for example, compared against mersenne-random: {{{ Generating 26452582 Ints with System.Random: Computation time: 47.850 sec Generating 26452582 Ints with System.Random.Mersenne: Computation time: 0.267 sec Generaating 26452582 Double's with System.Random: Computation time: 20.632 sec And with System.Random.Mersenne: Computation time: 0.563 sec }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 2 18:31:17 2009 From: trac at galois.com (GHC) Date: Mon Mar 2 18:20:02 2009 Subject: [GHC] #427: Random.StdGen slowness In-Reply-To: <044.910d2f7eb299e5f5b612cc8fccf049ef@localhost> References: <044.910d2f7eb299e5f5b612cc8fccf049ef@localhost> Message-ID: <053.0895dd3a7c643b8f021c41e820634931@localhost> #427: Random.StdGen slowness ---------------------------------+------------------------------------------ Reporter: remit | Owner: Type: bug | Status: new Priority: low | Milestone: _|_ Component: libraries/random | Version: 6.4.1 Severity: normal | Resolution: None Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by Remi): The slowness is most probably due to all the Integer conversions or perhaps also the algorithm used. (It's been years ago and I'm definitely not an expert on PRNGs.) However, IIRC making getStdRandom more strict does solve the thunk-bomb problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 2 18:33:41 2009 From: trac at galois.com (GHC) Date: Mon Mar 2 18:22:26 2009 Subject: [GHC] #427: Random.StdGen slowness In-Reply-To: <044.910d2f7eb299e5f5b612cc8fccf049ef@localhost> References: <044.910d2f7eb299e5f5b612cc8fccf049ef@localhost> Message-ID: <053.22ccfb13b6a7aac8815b950ea8e26225@localhost> #427: Random.StdGen slowness ---------------------------------+------------------------------------------ Reporter: remit | Owner: Type: bug | Status: new Priority: low | Milestone: _|_ Component: libraries/random | Version: Severity: normal | Resolution: None Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by dons): * version: 6.4.1 => Comment: Patch attached. Someone should validate it. http://galois.com/~dons/tmp/strict-state.dpatch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 2 19:16:30 2009 From: trac at galois.com (GHC) Date: Mon Mar 2 19:05:15 2009 Subject: [GHC] #427: Random.StdGen slowness In-Reply-To: <044.910d2f7eb299e5f5b612cc8fccf049ef@localhost> References: <044.910d2f7eb299e5f5b612cc8fccf049ef@localhost> Message-ID: <053.f9ca8a5b49527dad6bd2e7e79fea3ca6@localhost> #427: Random.StdGen slowness ---------------------------------+------------------------------------------ Reporter: remit | Owner: Type: bug | Status: new Priority: low | Milestone: _|_ Component: libraries/random | Version: Severity: normal | Resolution: None Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by duncan): I don't think that patch is enough to fix the "thunk-bomb" problem (though I think it is also necessary). It also needs `getStdRandom` to seq the gen state when updating the `IORef`. Mind you, I've not actually tested it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 2 19:27:24 2009 From: trac at galois.com (GHC) Date: Mon Mar 2 19:16:10 2009 Subject: [GHC] #2619: Can't build older compiler In-Reply-To: <044.186108a575a6c194091f1f6cfd66d1a5@localhost> References: <044.186108a575a6c194091f1f6cfd66d1a5@localhost> Message-ID: <053.97389b53c1b5568d20118d9bfdcf0f60@localhost> #2619: Can't build older compiler ---------------------------------+------------------------------------------ Reporter: judah | Owner: Type: bug | Status: reopened Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by duncan): Replying to [comment:11 chak]: > > It only takes ages to compile if you're using gcc-4.2.x or later. Using 4.1.x is fine. See [wiki:Building/Solaris#SelectingagoodGCCversion]. > > We were going by what Ben reported on his blog and he seemed to use 4.2.1. He did initially. I reported my findings to the ghc users list in January: http://haskell.org/pipermail/glasgow-haskell- users/2009-January/016454.html The summary is, use gcc 4.0.x or 4.1.x, not 4.2.x (4.3.x doesn't work). The sparky build bot is currently using gcc-4.1.2 and ghc-6.8.3 as the bootstrapping compiler for ghc stable and head branches. Both build in a reasonable amount of time (with gmake -j8). http://darcs.haskell.org/buildbot/all/builders/sparky%20head/ -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 2 19:34:28 2009 From: trac at galois.com (GHC) Date: Mon Mar 2 19:23:13 2009 Subject: [GHC] #427: Random.StdGen slowness In-Reply-To: <044.910d2f7eb299e5f5b612cc8fccf049ef@localhost> References: <044.910d2f7eb299e5f5b612cc8fccf049ef@localhost> Message-ID: <053.c6cb9994c33e0036f3588d4ea22d0a3d@localhost> #427: Random.StdGen slowness ---------------------------------+------------------------------------------ Reporter: remit | Owner: Type: bug | Status: new Priority: low | Milestone: _|_ Component: libraries/random | Version: Severity: normal | Resolution: None Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by dons): Replying to [comment:15 duncan]: > I don't think that patch is enough to fix the "thunk-bomb" problem (though I think it is also necessary). It also needs `getStdRandom` to seq the gen state when updating the `IORef`. Mind you, I've not actually tested it. http://galois.com/~dons/tmp/seq-strict-random.dpatch Needs someone to test it now :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 2 21:07:37 2009 From: trac at galois.com (GHC) Date: Mon Mar 2 20:56:19 2009 Subject: [GHC] #3061: GHC's GC default heap growth strategy is not as good as other runtimes Message-ID: <043.619b1558281745ecd214227681115d78@localhost> #3061: GHC's GC default heap growth strategy is not as good as other runtimes -----------------------------+---------------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 6.10.1 | Severity: normal Keywords: performance, GC | Testcase: yes Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- This is a GC performance ticket. The benchmark is the binary-trees benchmark, and the issue is whether or not GHC's ability to grow the heap without a heap check is comparably worse than other similar language runtimes. Looking at the binary-trees benchmark, we see that GHC does very well on a parallel system, when we give a GC hint to the size. E.g. the attached binary-trees program is very very competitive: Compile with: {{{ ghc -O2 -fasm --make -threaded A.hs }}} Run with: {{{ $ /A 20 +RTS -N4 -H340M }}} And we get: {{{ $ time ./A +RTS -N4 -H340M -RTS 20 stretch tree of depth 21 check: -1 2097152 trees of depth 4 check: -2097152 524288 trees of depth 6 check: -524288 131072 trees of depth 8 check: -131072 32768 trees of depth 10 check: -32768 8192 trees of depth 12 check: -8192 2048 trees of depth 14 check: -2048 512 trees of depth 16 check: -512 128 trees of depth 18 check: -128 32 trees of depth 20 check: -32 long lived tree of depth 20 check: -1 ./A +RTS -N4 -H340M -RTS 20 17.08s user 0.30s system 315% cpu 5.511 total }}} However, without that GC hint performance deteriorates dramatically, {{{ $ time ./A +RTS -N4 -RTS 20 stretch tree of depth 21 check: -1 2097152 trees of depth 4 check: -2097152 524288 trees of depth 6 check: -524288 131072 trees of depth 8 check: -131072 32768 trees of depth 10 check: -32768 8192 trees of depth 12 check: -8192 2048 trees of depth 14 check: -2048 512 trees of depth 16 check: -512 128 trees of depth 18 check: -128 32 trees of depth 20 check: -32 long lived tree of depth 20 check: -1 ./A +RTS -N4 -RTS 20 33.83s user 0.42s system 136% cpu 25.033 total }}} So 5x slow down. Could the GC heap growth algorithm be tuned? Other language runtimes, that are slower than Haskell's on this benchmark when our GC hint is in play, don't seem to suffer as badly without the hint: http://shootout.alioth.debian.org/u64q/benchmark.php?test=binarytrees&lang=all See e.g. Erlang. So: is there a better growth algorithm? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 2 21:57:59 2009 From: trac at galois.com (GHC) Date: Mon Mar 2 21:46:42 2009 Subject: [GHC] #3062: Adding a ":clear" clear-screen command to GHCi Message-ID: <045.476dc977664d91167a93dd5781d1d04c@localhost> #3062: Adding a ":clear" clear-screen command to GHCi -----------------------------+---------------------------------------------- Reporter: porges | Owner: Type: feature request | Status: new Priority: normal | Component: GHCi Version: 6.11 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- I have written a (hopeful) patch for this. I say hopeful because I'm not sure if it even compiles (I don't have the space to compile GHC at the moment...). Anyway if this could be confirmed to work and then incorporated that would be nice :) {{{ @@ -119,6 +119,7 @@ ("browse!", keepGoing (browseCmd True), Nothing, completeModule), ("cd", keepGoing changeDirectory, Just filenameWordBreakChars, completeFilename), ("check", keepGoing checkModule, Nothing, completeHomeModule), + ("clear", keepGoing clearScreen, Nothing, completeNone), ("continue", keepGoing continueCmd, Nothing, completeNone), ("cmd", keepGoing cmdCmd, Nothing, completeIdentifier), ("ctags", keepGoing createCTagsFileCmd, Just filenameWordBreakChars, completeFilename), @@ -200,6 +201,7 @@ " :browse[!] [[*]] display the names defined by module \n" ++ " (!: more details; *: all top-level names)\n" ++ " :cd change directory to \n" ++ + " :clear clear the screen\n" ++ " :cmd run the commands returned by ::IO String\n" ++ " :ctags [] create tags file for Vi (default: \"tags\")\n" ++ " :def define a command :\n" ++ @@ -936,6 +938,15 @@ prev_context <- GHC.getContext ok <- trySuccess $ GHC.load LoadAllTargets afterLoad ok False prev_context + +clearScreen :: String -> GHCi () +clearScreen _ = do + let cmd = case os of + "windows" -> Just "cls" + "linux" -> Just "clear" + _ -> Nothing + didnt_work <- maybe (return True) shellEscape cmd + when didnt_work (io (putStrLn ("Error: unsupported operating system for command 'clear'. Please report a bug."))) changeDirectory :: String -> GHCi () changeDirectory "" = do }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 2 22:10:59 2009 From: trac at galois.com (GHC) Date: Mon Mar 2 21:59:40 2009 Subject: [GHC] #3062: Adding a ":clear" clear-screen command to GHCi In-Reply-To: <045.476dc977664d91167a93dd5781d1d04c@localhost> References: <045.476dc977664d91167a93dd5781d1d04c@localhost> Message-ID: <054.7c6a56d6a0277fa9d268408bfbdfa62c@localhost> #3062: Adding a ":clear" clear-screen command to GHCi ------------------------------+--------------------------------------------- Reporter: porges | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.11 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by judah): You can use ghci macros to do this: http://haskell.org/haskellwiki/GHC/GHCi Add the following line to your `~/.ghci` file: {{{ :def clear \_ -> return $ ":!clear" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 3 05:16:27 2009 From: trac at galois.com (GHC) Date: Tue Mar 3 05:05:08 2009 Subject: [GHC] #3063: Only at separate compilation: Conflicting family instance declarations Message-ID: <046.a6428564d063655df13aa78fe52dab20@localhost> #3063: Only at separate compilation: Conflicting family instance declarations -----------------------------+---------------------------------------------- Reporter: dorinho | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Take the following class: class C a where type B a Then the following instances only throw ?Conflicting family instance declarations?, if compiled separately: instance C a where type B a = X a instance C (Int,a) where type B (Int,a) = X a Cheers, Dorinho -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 3 05:32:38 2009 From: trac at galois.com (GHC) Date: Tue Mar 3 05:21:44 2009 Subject: [GHC] #2619: Can't build older compiler In-Reply-To: <044.186108a575a6c194091f1f6cfd66d1a5@localhost> References: <044.186108a575a6c194091f1f6cfd66d1a5@localhost> Message-ID: <053.1a3b6f86f1463ea6c0386870348c790a@localhost> #2619: Can't build older compiler ---------------------------------+------------------------------------------ Reporter: judah | Owner: Type: bug | Status: reopened Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonpj): Following my weekly phone call with Manuel and Roman, here's my understanding of what the problem is, mainly just rephrasing Manuel's comments above in my own words: * Goal: allow people to specify GHC-X as the bootstrap compiler. * The time to do this is in the configure step: `configure --with- ghc=GHC-X` * Maybe there should be warnings if the version of GHC-X is out of the guaranteed range, but configure should still obey And it does obey. As I understand it what happens is this * The stage1 package `ghc` is built with GHC-X, and somehow installed where GHC-X can find it * But when we build the stage1 ''executable'', by using GHC-X to compile a small `Main.hs` against package `ghc`, we get the package `ghc` that came with GHC-X rather than the newly-built package `ghc`. Of course that's pretty confusing. * What's wanted is to ''guarantee'' that GHC-X will expose and use the newly-built package (not any existing one) when compiling `Main.hs`. Any other behaviour must be wrong. I can see that it may not be worth fixing the old build system, and Ian says it's already done in the new system; so the short-term question is how Manuel and Roman can make progress. Manuel, Roman, do you have a workaround? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 3 06:34:35 2009 From: trac at galois.com (GHC) Date: Tue Mar 3 06:23:18 2009 Subject: [GHC] #3063: Only at separate compilation: Conflicting family instance declarations In-Reply-To: <046.a6428564d063655df13aa78fe52dab20@localhost> References: <046.a6428564d063655df13aa78fe52dab20@localhost> Message-ID: <055.b429cf06026196a5fc5a99b34d4e11ba@localhost> #3063: Only at separate compilation: Conflicting family instance declarations ------------------------------+--------------------------------------------- Reporter: dorinho | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: invalid Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by dorinho): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 3 06:51:01 2009 From: trac at galois.com (GHC) Date: Tue Mar 3 06:39:52 2009 Subject: [GHC] #2917: alloca and allocaArray do not respect alignment In-Reply-To: <044.ae4012da6404813e981e2064d26c5c85@localhost> References: <044.ae4012da6404813e981e2064d26c5c85@localhost> Message-ID: <053.f7f6227361f2ee1cd633707e13554410@localhost> #2917: alloca and allocaArray do not respect alignment ---------------------------------+------------------------------------------ Reporter: guest | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler (FFI) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * owner: igloo => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 3 06:52:09 2009 From: trac at galois.com (GHC) Date: Tue Mar 3 06:40:50 2009 Subject: [GHC] #3025: Possible PiDigits memory explosion regression In-Reply-To: <045.83a907a9b608fda1ad14968d66d95fe2@localhost> References: <045.83a907a9b608fda1ad14968d66d95fe2@localhost> Message-ID: <054.ba25e792de49a6c6497c501af3ddfdc9@localhost> #3025: Possible PiDigits memory explosion regression ---------------------------------+------------------------------------------ Reporter: japple | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * owner: => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 3 07:02:33 2009 From: trac at galois.com (GHC) Date: Tue Mar 3 06:51:20 2009 Subject: [GHC] #2189: hSetBuffering stdin NoBuffering doesn't work on Windows In-Reply-To: <047.b31f95b84e60784da45a33105d44ed84@localhost> References: <047.b31f95b84e60784da45a33105d44ed84@localhost> Message-ID: <056.747fcd28af8bb8d5be6f0597e90b1d4b@localhost> #2189: hSetBuffering stdin NoBuffering doesn't work on Windows -----------------------------------------------+---------------------------- Reporter: FalconNL | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: Keywords: hsetbuffering buffering buffer | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -----------------------------------------------+---------------------------- Changes (by simonmar): * priority: normal => high * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 3 06:58:35 2009 From: trac at galois.com (GHC) Date: Tue Mar 3 06:51:39 2009 Subject: [GHC] #2615: ghci doesn't play nice with linker scripts In-Reply-To: <051.bfa2cefd2ab537021a429fbc1fccdb5e@localhost> References: <051.bfa2cefd2ab537021a429fbc1fccdb5e@localhost> Message-ID: <060.98adbc091614cdb3fbffa416c219e4ac@localhost> #2615: ghci doesn't play nice with linker scripts ---------------------------------+------------------------------------------ Reporter: AlecBerryman | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * owner: => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 3 07:07:04 2009 From: trac at galois.com (GHC) Date: Tue Mar 3 06:55:44 2009 Subject: [GHC] #2983: Segmentation fault in ray tracer with certain options In-Reply-To: <052.ab008e7a26a83a06094f6364ea685223@localhost> References: <052.ab008e7a26a83a06094f6364ea685223@localhost> Message-ID: <061.8d836d36b8ebec32658b64fa1c1fd02b@localhost> #2983: Segmentation fault in ray tracer with certain options --------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: seg fault, ray tracer | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | --------------------------------------+------------------------------------- Changes (by igloo): * priority: normal => high -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 3 08:00:51 2009 From: trac at galois.com (GHC) Date: Tue Mar 3 07:49:35 2009 Subject: [GHC] #3064: Very long compile times with type functions Message-ID: <046.2a7b2611764311f7357001c522d303b9@localhost> #3064: Very long compile times with type functions -------------------------------------------+-------------------------------- Reporter: simonpj | Owner: chak Type: compile-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.10.1 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------------------+-------------------------------- the attached module is a much reduced version of some type-level assurance stuff (inspired by the Lightweight Monadic Regions paper) I am trying to do. I am almost certain that it could be reduced further but it is late and I want to get this off my desk. Note the 4 test functions, test11 .. test14. The following are timings for compiling the module only with all test functions commented out, except respectively, test11, test12, test13, and test14: {{{ ben@sarun[1] > time ghc -c Bug2.hs ghc -c Bug2.hs 1,79s user 0,04s system 99% cpu 1,836 total ben@sarun[1] > time ghc -c Bug2.hs ghc -c Bug2.hs 5,87s user 0,14s system 99% cpu 6,028 total ben@sarun[1] > time ghc -c Bug2.hs ghc -c Bug2.hs 23,52s user 0,36s system 99% cpu 23,899 total ben@sarun[1] > time ghc -c Bug2.hs ghc -c Bug2.hs 102,20s user 1,32s system 97% cpu 1:45,89 total }}} It seems something is scaling very badly. You really don't want to wait for a version with 20 levels of nesting to compile... If anyone has a good explanation for this, I'd be grateful. BTW, I am not at all certain that this is ghc's fault, it may well be my program, i.e. the constraints are too complex, whatever. I have no idea how hard it is for the compiler to do all the unification. Also, the problem is not of much practical relevance, as no sensible program will use more than a handful levels of nesting. SLPJ says: let's investigate this once the new solver is done. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 3 08:14:00 2009 From: trac at galois.com (GHC) Date: Tue Mar 3 08:02:45 2009 Subject: [GHC] #2615: ghci doesn't play nice with linker scripts In-Reply-To: <051.bfa2cefd2ab537021a429fbc1fccdb5e@localhost> References: <051.bfa2cefd2ab537021a429fbc1fccdb5e@localhost> Message-ID: <060.e0f2ae02e4242cac7379d964a7da6246@localhost> #2615: ghci doesn't play nice with linker scripts ---------------------------------+------------------------------------------ Reporter: AlecBerryman | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): As Duncan says, this won't be a problem when we're using shared libraries: It means that ghci will not need to link to system shared libs except when someone uses `-lblah` on the ghci command line. That's because when we link a Haskell package as a shared lib the system linker interprets any linker scripts and embeds the list of dependencies on other shared libs (other Haskell packages and system libs). Then ghci just dlopens the shared libs for the directly used Haskell packages that that automatically resolves all their deps on other Haskell and system shared libs. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 3 09:57:32 2009 From: trac at galois.com (GHC) Date: Tue Mar 3 09:46:15 2009 Subject: [GHC] #3065: Reorder tests in quot to improve code Message-ID: <046.819ea32d4c70bd7d14e7ef168534bbea@localhost> #3065: Reorder tests in quot to improve code ---------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.12 branch Component: libraries/base | Version: 6.10.1 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ---------------------------------------+------------------------------------ [SLPJ: capturing an email thread in a ticket] Krasimir Angelov found that this function: {{{ a `quot` b | b == 0 = divZeroError | a == minBound && b == (-1) = overflowError | otherwise = a `quotInt` b }}} is expanded to: {{{ a `quot` b = if b == 0 then divZeroError else if a == minBound then if b == (-1) then overflowError else a `quotInt` b else a `quotInt` b }}} Then the compiler sees that b is a constant and computes that b == 0 is False and b == (-1) is also False so it could eliminate two If statements. The result is: {{{ a `quot` b = if a == minBound then a `quotInt` b else a `quotInt` b }}} and this is exactly what we get. I bet that if the original function was: {{{ a `quot` b | b == 0 = divZeroError | b == (-1) && a == minBound = overflowError -- Note the changed order here | otherwise = a `quotInt` b }}} then we would get what we want. I think that it is much more often to have division where the divisor is known so we will get the best code in this case. Shortly afterwards, Bertram Felgenhauer tried it out. It works, and it has the desired effect. It's not always a win though; the nofib prime sieve benchmark suffers. For a patch, see http://int-e.home.tlink.de/haskell/ghc-libraries-base-tune- division.patch (SLPJ: I've attached it to the ticket too) Nofib results extract: {{{ ------------------------------------------------------------------------ Program Size Allocs Runtime Elapsed ------------------------------------------------------------------------ fish -0.7% -5.3% 0.05 0.04 primes -0.0% +28.5% +25.6% +25.5% wheel-sieve2 -0.0% -0.3% -17.9% -18.6% ------------------------------------------------------------------------ Min -0.9% -5.3% -17.9% -18.6% Max +0.1% +28.5% +25.6% +25.5% Geometric Mean -0.2% +0.2% -0.0% +0.2% }}} 'primes' is an outlier - the other slowdowns are below 3% What happens in 'primes' is that 'mod' no longer gets inlined; apparently it now looks bigger to the compiler than before. Using -funfolding-use-threshold=10 brings the benchmark back to its original speed, despite the extra comparison before doing the division. In 'wheel-sieve2', the first different optimization choice I see is again a 'mod' that is no longer inlined; this leads to a change in other inlining choices that result in a speedup for reasons that I have not investigated. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 3 10:00:23 2009 From: trac at galois.com (GHC) Date: Tue Mar 3 09:49:04 2009 Subject: [GHC] #3065: Reorder tests in quot to improve code In-Reply-To: <046.819ea32d4c70bd7d14e7ef168534bbea@localhost> References: <046.819ea32d4c70bd7d14e7ef168534bbea@localhost> Message-ID: <055.5ca07a0cf2d03faa11d4cc4bce5ab116@localhost> #3065: Reorder tests in quot to improve code -----------------------------------------+---------------------------------- Reporter: simonpj | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.12 branch Component: libraries/base | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Comment (by simonpj): PS the original thread is here http://www.haskell.org/pipermail/glasgow- haskell-users/2009-February/thread.html -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 3 10:44:29 2009 From: trac at galois.com (GHC) Date: Tue Mar 3 10:33:10 2009 Subject: [GHC] #3060: impossible internal bug while building darcs In-Reply-To: <044.8b050eb370b3a248f628f79a0a5b8c10@localhost> References: <044.8b050eb370b3a248f628f79a0a5b8c10@localhost> Message-ID: <053.5f897e9f824eab07d20c9a62d56d5301@localhost> #3060: impossible internal bug while building darcs -------------------------+-------------------------------------------------- Reporter: quick | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by simonmar): * difficulty: => Unknown Old description: > [ghc] src/Exec.o > ghc: panic! (the 'impossible' happened) > (GHC version 6.10.1 for i386-unknown-linux): > applyTypeToArgs > unix-2.3.1.0:System.Posix.Signals.a38{v r8P} [gid] > (unix-2.3.1.0:System.Posix.Signals.a5{v r8O} [gid] > `cast` (ghc-prim:GHC.Prim.sym{(w) tc 34v} > base:Foreign.C.Types.:CoCInt{tc r4P} > :: base:GHC.Int.Int32{tc 3V} > ~ > base:Foreign.C.Types.CInt{tc r4S})) > unix-2.3.1.0:System.Posix.Signals.Ignore{v r8N} [gid] > (base:Data.Maybe.Nothing{v r4K} [gid] > @ unix-2.3.1.0:System.Posix.Signals.SignalSet{tc r8M}) > eta{v a1Vy} [lid] > (# ghc-prim:GHC.Prim.State#{(w) tc 32q} > ghc-prim:GHC.Prim.RealWorld{(w) tc 31E}, > unix-2.3.1.0:System.Posix.Signals.SignalSet{tc r8M} #) > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > While building darcs 2.2.0. New description: {{{ [ghc] src/Exec.o ghc: panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-unknown-linux): applyTypeToArgs unix-2.3.1.0:System.Posix.Signals.a38{v r8P} [gid] (unix-2.3.1.0:System.Posix.Signals.a5{v r8O} [gid] `cast` (ghc-prim:GHC.Prim.sym{(w) tc 34v} base:Foreign.C.Types.:CoCInt{tc r4P} :: base:GHC.Int.Int32{tc 3V} ~ base:Foreign.C.Types.CInt{tc r4S})) unix-2.3.1.0:System.Posix.Signals.Ignore{v r8N} [gid] (base:Data.Maybe.Nothing{v r4K} [gid] @ unix-2.3.1.0:System.Posix.Signals.SignalSet{tc r8M}) eta{v a1Vy} [lid] (# ghc-prim:GHC.Prim.State#{(w) tc 32q} ghc-prim:GHC.Prim.RealWorld{(w) tc 31E}, unix-2.3.1.0:System.Posix.Signals.SignalSet{tc r8M} #) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} While building darcs 2.2.0. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 3 10:53:06 2009 From: trac at galois.com (GHC) Date: Tue Mar 3 10:41:47 2009 Subject: [GHC] #3060: impossible internal bug while building darcs In-Reply-To: <044.8b050eb370b3a248f628f79a0a5b8c10@localhost> References: <044.8b050eb370b3a248f628f79a0a5b8c10@localhost> Message-ID: <053.6abbda079d9ed49f849ea91ded80f728@localhost> #3060: impossible internal bug while building darcs -------------------------+-------------------------------------------------- Reporter: quick | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------+-------------------------------------------------- Comment (by simonpj): This looks very similar to #2763 and #2878. But we closed #2878 because we couldn't reproduce it; and we've just compiled Darcs 2.2.0 (using configure/make, not cabal) with GHC 6.10.1 without a problem. So we can't reproduce your problem. Suggestion: start with a fresh tree. And add `-dcore-lint`. Let us know. Perhaps it's due to some leftover droppings from a previous compilation (although that would still be a bug). Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 3 10:53:55 2009 From: trac at galois.com (GHC) Date: Tue Mar 3 10:42:34 2009 Subject: [GHC] #2763: while installing cabal from darcs, 1.6.0.1 and 1.4.0.2 In-Reply-To: <044.967654beccd358d1d0ac92f7259473da@localhost> References: <044.967654beccd358d1d0ac92f7259473da@localhost> Message-ID: <053.74e4c7a44f90731005394d2a84c78208@localhost> #2763: while installing cabal from darcs, 1.6.0.1 and 1.4.0.2 ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: cabal ghc ubuntu | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | ---------------------------------+------------------------------------------ Comment (by simonpj): cf #3060, which has similar symptoms (and lack of them). S -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 3 11:09:41 2009 From: trac at galois.com (GHC) Date: Tue Mar 3 10:58:22 2009 Subject: [GHC] #3040: make clean fails (in utils/hsc2hs?) on 6.10 In-Reply-To: <041.44349b023a81934d09f5b52fb3674ea2@localhost> References: <041.44349b023a81934d09f5b52fb3674ea2@localhost> Message-ID: <050.b18643038cc025bc46e4e965cf43f20b@localhost> #3040: make clean fails (in utils/hsc2hs?) on 6.10 ---------------------------------+------------------------------------------ Reporter: nr | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 6.11 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: Fixed in the new build system: {{{ Tue Mar 3 16:07:59 GMT 2009 Simon Marlow * FIX #3040: test for $dir/ghc.mk instead of just $dir catches cases where darcs has failed and left an empty directory }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 3 11:14:15 2009 From: trac at galois.com (GHC) Date: Tue Mar 3 11:02:54 2009 Subject: [GHC] #3042: rts defines "real_main" which can clash with user C code In-Reply-To: <045.2ba5f7fc867f0e9727cddd2b5dbaa661@localhost> References: <045.2ba5f7fc867f0e9727cddd2b5dbaa661@localhost> Message-ID: <054.ebc8f3aef3e1ebff3a436ff59fb0f33c@localhost> #3042: rts defines "real_main" which can clash with user C code ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * difficulty: => Unknown Comment: `real_main` is declared to be `static` - I don't understand how it could clash? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 3 11:16:34 2009 From: trac at galois.com (GHC) Date: Tue Mar 3 11:05:18 2009 Subject: [GHC] #3022: ghc: panic! (the 'impossible' happened) linkBCO: >= 64k insns in BCO In-Reply-To: <044.30ac4f6e3902a654e6966b395559b244@localhost> References: <044.30ac4f6e3902a654e6966b395559b244@localhost> Message-ID: <053.b7f284aa5b4510388cadb929fa365676@localhost> #3022: ghc: panic! (the 'impossible' happened) linkBCO: >= 64k insns in BCO ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: dup of #789, but thanks for the test case! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 3 11:16:57 2009 From: trac at galois.com (GHC) Date: Tue Mar 3 11:05:38 2009 Subject: [GHC] #789: BCOs can only have 64k instructions: linkBCO: >= 64k insns in BCO In-Reply-To: <046.dd5b1d4a62c636e51e886c3d53bcf8d3@localhost> References: <046.dd5b1d4a62c636e51e886c3d53bcf8d3@localhost> Message-ID: <055.488da617ca62c5b5c581d7d699bdbf42@localhost> #789: BCOs can only have 64k instructions: linkBCO: >= 64k insns in BCO ------------------------+--------------------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: BCO | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ------------------------+--------------------------------------------------- Comment (by simonmar): See also #3022, #3047 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 3 11:17:22 2009 From: trac at galois.com (GHC) Date: Tue Mar 3 11:06:06 2009 Subject: [GHC] #3047: Panic! (the 'impossible' happened) :) In-Reply-To: <049.1afc8a34b373d8cc459a64a5eb511c3e@localhost> References: <049.1afc8a34b373d8cc459a64a5eb511c3e@localhost> Message-ID: <058.7c9fa1860a1b995ee9c4c8fd5bf68ff3@localhost> #3047: Panic! (the 'impossible' happened) :) ---------------------------+------------------------------------------------ Reporter: bchallenor | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | ---------------------------+------------------------------------------------ Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: dup of #789 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 3 11:22:34 2009 From: trac at galois.com (GHC) Date: Tue Mar 3 11:11:22 2009 Subject: [GHC] #3048: Heap size suggestion gets ignored when -G1 flag is passed In-Reply-To: <042.4a4de14d2a27edaf21ce0d0005e7a315@localhost> References: <042.4a4de14d2a27edaf21ce0d0005e7a315@localhost> Message-ID: <051.4556ce80db58f0a3541064247b99673c@localhost> #3048: Heap size suggestion gets ignored when -G1 flag is passed ---------------------------------+------------------------------------------ Reporter: tim | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Runtime System | Version: 6.10.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * difficulty: => Unknown * milestone: => _|_ Comment: True, though I find myself not terribly motivated to fix it :-) Do you have a strong need for `-G1`? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 3 11:41:48 2009 From: trac at galois.com (GHC) Date: Tue Mar 3 11:30:32 2009 Subject: [GHC] #3041: Arch independent binary representations In-Reply-To: <046.ec9add4015adc692796a9426b46aeec0@localhost> References: <046.ec9add4015adc692796a9426b46aeec0@localhost> Message-ID: <055.bef496eee645e54c3ebf0d13e44ce21a@localhost> #3041: Arch independent binary representations ---------------------------------+------------------------------------------ Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * difficulty: => Unknown Comment: The problem here is not that GHC's Binary library has an instance for `Int`, it is that Haddock uses GHC's `Binary` library at all. GHC's `Binary` library is for serialising interface files, and since interface files can be platform-specific it doesn't matter that we have a platform- specific instance for `Int`. I think Haddock should either use a local copy of Binary with a platform- independent serialisation format (like it used to! :-) or it should use `Data.Binary`. The latter adds a new dependency to GHC, but in the long run that's not a disaster. For a quick fix, the former solution will do fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 3 11:43:25 2009 From: trac at galois.com (GHC) Date: Tue Mar 3 11:32:15 2009 Subject: [GHC] #3052: ghc FFI doesn't support thiscall In-Reply-To: <047.ea34806f73921c57cbc395f3f5a9a535@localhost> References: <047.ea34806f73921c57cbc395f3f5a9a535@localhost> Message-ID: <056.d0e3cfceaea5493f1b758c976abe6ae5@localhost> #3052: ghc FFI doesn't support thiscall --------------------------------+------------------------------------------- Reporter: augustss | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler (FFI) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Os: Windows Architecture: x86 | --------------------------------+------------------------------------------- Changes (by simonmar): * difficulty: => Moderate (1 day) * type: bug => feature request * milestone: => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 3 11:50:52 2009 From: trac at galois.com (GHC) Date: Tue Mar 3 11:39:32 2009 Subject: [GHC] #3056: StrictAnal module naming issue In-Reply-To: <046.bf14dee7e90b3354e0823f5b9890979f@localhost> References: <046.bf14dee7e90b3354e0823f5b9890979f@localhost> Message-ID: <055.3872512262997386e4ce007b116e5672@localhost> #3056: StrictAnal module naming issue ---------------------------------+------------------------------------------ Reporter: pumpkin | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: trivial | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * difficulty: => Unknown Comment: I'm not sure we should change it. It's rather amusing, albeit entirely accidental (I believe). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 3 12:11:02 2009 From: trac at galois.com (GHC) Date: Tue Mar 3 11:59:43 2009 Subject: [GHC] #3057: Standalone deriving of Functor does not work for HsDoc In-Reply-To: <044.a238214f97be82789d77ffa26a6dd377@localhost> References: <044.a238214f97be82789d77ffa26a6dd377@localhost> Message-ID: <053.55482c6b7391f3761e415d855bf331ce@localhost> #3057: Standalone deriving of Functor does not work for HsDoc ----------------------------------------------+----------------------------- Reporter: waern | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: deriving/should_compile/T3057 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------------+----------------------------- Changes (by simonpj): * testcase: => deriving/should_compile/T3057 * difficulty: => Unknown * status: new => closed * resolution: => fixed Comment: Good bug thanks. Fixed by {{{ Tue Mar 3 09:06:12 PST 2009 simonpj@microsoft.com * Fix Trac #3057 in deriving Functor Ignore-this: 7d7783868e4684930f75c3b35c18c586 The universal type variables of a data constructor are not necessarily identical to those of its parent type constructor, especially if the data type is imported. While I was at it, I did a significant refactoring to make all this traversal of types more comprehensible, by adding the data type FFoldType. }}} I added a test too. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 3 12:15:15 2009 From: trac at galois.com (GHC) Date: Tue Mar 3 12:03:54 2009 Subject: [GHC] #3066: Crash with bogus FFI declaration Message-ID: <046.a0d023407aaea2d72ef0e4c64d1c0cea@localhost> #3066: Crash with bogus FFI declaration -------------------------------+-------------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- Ben Franksen finds this: {{{ {-# LANGUAGE ForeignFunctionInterface, RankNTypes #-} import Foreign type X u = Ptr () foreign import ccall bla :: (forall u. X u) -> IO () }}} I know of course that I must not use fancy types in foreign imports. I forgot for a moment and instead of an error message got: {{{ ben@sarun> ghci Bug3 GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Main ( Bug3.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-unknown-linux): unboxArg: Bug3.hs:4:0-51 forall u{tv aht} [tv]. main:Main.X{tc rhp} u{tv aht} [tv] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 3 12:22:39 2009 From: trac at galois.com (GHC) Date: Tue Mar 3 12:11:17 2009 Subject: [GHC] #3066: Crash with bogus FFI declaration In-Reply-To: <046.a0d023407aaea2d72ef0e4c64d1c0cea@localhost> References: <046.a0d023407aaea2d72ef0e4c64d1c0cea@localhost> Message-ID: <055.5b58b3e49c9280df0f5916292b0c0c92@localhost> #3066: Crash with bogus FFI declaration ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * cc: ben.franksen@online.de (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 3 12:33:41 2009 From: trac at galois.com (GHC) Date: Tue Mar 3 12:22:22 2009 Subject: [GHC] #3041: Arch independent binary representations In-Reply-To: <046.ec9add4015adc692796a9426b46aeec0@localhost> References: <046.ec9add4015adc692796a9426b46aeec0@localhost> Message-ID: <055.48bd5a9b18879fee3fff68fc2dc6f8d5@localhost> #3041: Arch independent binary representations ---------------------------------+------------------------------------------ Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by igloo): Replying to [comment:6 simonmar]: > The problem here is not that GHC's Binary library has an instance for `Int`, it is that Haddock uses GHC's `Binary` library at all. GHC's `Binary` library is for serialising interface files, and since interface files can be platform-specific it doesn't matter that we have a platform- specific instance for `Int`. > > I think Haddock should either use a local copy of Binary with a platform-independent serialisation format (like it used to! :-) or it should use `Data.Binary`. The latter adds a new dependency to GHC, but in the long run that's not a disaster. For a quick fix, the former solution will do fine. Is there a reason for GHC not to use `Data.Binary` too? The only reason I can think of would be to avoid the extra dependency, but if haddock uses it then the GHC build depends on it anyway. Personally, I don't think it's a strong enough reason to maintain our own Binary anyway. So if GHC switches to `Data.Binary`, then all haddock needs to do is wait. In the mean time (i.e. for 6.10.2), we can fix the immediate problem by changing the `Int` instance to to serialise as `Int32` or `Int64` consistently. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 3 12:38:59 2009 From: trac at galois.com (GHC) Date: Tue Mar 3 12:27:47 2009 Subject: [GHC] #3048: Heap size suggestion gets ignored when -G1 flag is passed In-Reply-To: <042.4a4de14d2a27edaf21ce0d0005e7a315@localhost> References: <042.4a4de14d2a27edaf21ce0d0005e7a315@localhost> Message-ID: <051.e29b29414643318bedf5363c796fbe87@localhost> #3048: Heap size suggestion gets ignored when -G1 flag is passed ---------------------------------+------------------------------------------ Reporter: tim | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Runtime System | Version: 6.10.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by tim): I wouldn't say it's a strong need, but I'm trying to do some performance experiments where I compare my compiler (which uses a non-generational GC) to GHC, with a given heap size, so it would be nice to have. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 3 12:44:50 2009 From: trac at galois.com (GHC) Date: Tue Mar 3 12:33:30 2009 Subject: [GHC] #3066: Crash with bogus FFI declaration In-Reply-To: <046.a0d023407aaea2d72ef0e4c64d1c0cea@localhost> References: <046.a0d023407aaea2d72ef0e4c64d1c0cea@localhost> Message-ID: <055.8eae794bcb0ed384fe53462a13542f24@localhost> #3066: Crash with bogus FFI declaration --------------------------------------+------------------------------------- Reporter: simonpj | Owner: igloo Type: merge | Status: new Priority: high | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: ffi/should_fail/T3066 | Os: Unknown/Multiple Architecture: Unknown/Multiple | --------------------------------------+------------------------------------- Changes (by simonpj): * priority: normal => high * testcase: => ffi/should_fail/T3066 * type: bug => merge * owner: simonpj => igloo Comment: Thanks for reporting this. Fixed by {{{ Tue Mar 3 17:42:58 GMT 2009 simonpj@microsoft.com * Fix Trac #3066: checking argument types in foreign calls When checking argument types in a foreign call we were stupidly looking through foralls. The fix is easy. }}} Please merge to the 6.10 branch. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 3 13:12:26 2009 From: trac at galois.com (GHC) Date: Tue Mar 3 13:01:15 2009 Subject: [GHC] #2615: ghci doesn't play nice with linker scripts In-Reply-To: <051.bfa2cefd2ab537021a429fbc1fccdb5e@localhost> References: <051.bfa2cefd2ab537021a429fbc1fccdb5e@localhost> Message-ID: <060.7d49488124be55af278a582933b63a85@localhost> #2615: ghci doesn't play nice with linker scripts ---------------------------------+------------------------------------------ Reporter: AlecBerryman | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * priority: high => normal Comment: The problem is illustrated by this C program: {{{ #include #include int main(void) { void *p; p = dlopen("/usr/lib/libgmp.so", RTLD_LAZY | RTLD_GLOBAL); if (p) printf("OK\n"); else printf("%s\n", dlerror()); p = dlopen("/usr/lib/libpthread.so", RTLD_LAZY | RTLD_GLOBAL); if (p) printf("OK\n"); else printf("%s\n", dlerror()); return 0; } }}} which fails to `dlopen` `/usr/lib/pthread.so` because it's a linker script: {{{ $ gcc -ldl c.c -o c $ ./c OK /usr/lib/libpthread.so: invalid ELF header $ cat /usr/lib/libpthread.so /* GNU ld script Use the shared library, but some functions are only in the static library, so try that secondarily. */ OUTPUT_FORMAT(elf64-x86-64) GROUP ( /lib/libpthread.so.0 /usr/lib/libpthread_nonshared.a ) }}} This most commonly crops up with `-lpthread` and `-lc`, and in both these cases you can work around it by just not passing the flag. I've done some digging, but haven't been able to find a replacement for `dlopen` that can handle linker scripts. There are two things we could do: * Special case `-lpthread` and `-lc`. This wouldn't solve the problem in general, but would fix the most common instances of it. * Make an empty library linked with `-lpthread` (or whatever other `-l` flags we're given) and `dlopen` that library. Then the system linker takes care of it for us. This is ugly, but if we have code to generate `.so` libraries anyway (for making dynamic Haskell libraries) then at least it's not too much work to implement. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 3 14:25:50 2009 From: trac at galois.com (GHC) Date: Tue Mar 3 14:14:31 2009 Subject: [GHC] #3067: GHCi panics with 'initTc:LIE' while :stepping on code with funny types Message-ID: <047.801133442d7e8310cd95466844b00db5@localhost> #3067: GHCi panics with 'initTc:LIE' while :stepping on code with funny types -----------------------------+---------------------------------------------- Reporter: mnislaih | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- This is due to runtime type reconstruction not dealing correctly with type functions. I managed to come up a minimal example. {{{ {-# LANGUAGE TypeFamilies #-} type family Id x type instance Id Int = Int type instance Id Bool = Bool class Convert x y where convert :: x -> y instance Convert x x where convert = id f :: Convert a (Id a) => a -> Id a f x = convert x g :: Convert a (Id a) => a -> Id a g x = let x' = f x in x' } {{{ [1 of 1] Compiling Main ( ../code/debuggerExamples/lie.hs, interpreted ) Ok, modules loaded: Main. *Main GOA> :step g False :step g False Stopped at ../code/debuggerExamples/lie.hs:15:0-23 _result :: Id a = _ 14 g :: Convert a (Id a) => a -> Id a 15 g x = let x' = f x in x' ^^^^^^^^^^^^^^^^^^^^^^^^ [../code/debuggerExamples/lie.hs:15:0-23] *Main GOA> :step :step ghc: panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-apple-darwin): initTc:LIE Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 3 14:46:45 2009 From: trac at galois.com (GHC) Date: Tue Mar 3 14:35:28 2009 Subject: [GHC] #3067: GHCi panics with 'initTc:LIE' while :stepping on code with funny types In-Reply-To: <047.801133442d7e8310cd95466844b00db5@localhost> References: <047.801133442d7e8310cd95466844b00db5@localhost> Message-ID: <056.d6cba9c2f1da963e0aef943cf70d1a9f@localhost> #3067: GHCi panics with 'initTc:LIE' while :stepping on code with funny types ------------------------------+--------------------------------------------- Reporter: mnislaih | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: break028 Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by mnislaih): * testcase: => break028 * owner: => igloo * type: bug => merge Comment: Fixed, please merge {{{ Tue Mar 3 11:37:06 PST 2009 pepe iborra * Fix #3067: GHCi panics with 'initTc:LIE' while :stepping on code with funny types The problem is that calls to boxyUnify would panic if the types involved contained type functions. It looks like one should wrap these calls with getLIE, although I don't really know what I am doing here M ./compiler/ghci/RtClosureInspect.hs -2 +2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 3 17:15:19 2009 From: trac at galois.com (GHC) Date: Tue Mar 3 17:03:59 2009 Subject: [GHC] #3067: GHCi panics with 'initTc:LIE' while :stepping on code with funny types In-Reply-To: <047.801133442d7e8310cd95466844b00db5@localhost> References: <047.801133442d7e8310cd95466844b00db5@localhost> Message-ID: <056.95bb947dee16acd2fa1ac7711d11feb8@localhost> #3067: GHCi panics with 'initTc:LIE' while :stepping on code with funny types ---------------------------------+------------------------------------------ Reporter: mnislaih | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: break028 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 3 17:22:56 2009 From: trac at galois.com (GHC) Date: Tue Mar 3 17:11:35 2009 Subject: [GHC] #3066: Crash with bogus FFI declaration In-Reply-To: <046.a0d023407aaea2d72ef0e4c64d1c0cea@localhost> References: <046.a0d023407aaea2d72ef0e4c64d1c0cea@localhost> Message-ID: <055.aea628cf4191d8ebd6f862e8b020428d@localhost> #3066: Crash with bogus FFI declaration --------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: ffi/should_fail/T3066 | Os: Unknown/Multiple Architecture: Unknown/Multiple | --------------------------------------+------------------------------------- Changes (by igloo): * owner: igloo => simonpj * type: merge => bug Comment: This breaks the build: {{{ /home/ian/ghc/darcs/ghc/ghc/stage1-inplace/ghc -package-name base-4.0.0.0 -hide-all-packages -no-user-package-conf -i -idist/build -i. -idist/build/autogen -Idist/build/autogen -Idist/build -Iinclude -optP- include -optPdist/build/autogen/cabal_macros.h -#include "HsBase.h" -odir dist/build -hidir dist/build -stubdir dist/build -package ghc-prim-0.1.0.0 -package integer-0.1.0.0 -package rts-1.0 -O -package-name base -XMagicHash -XExistentialQuantification -XRank2Types -XScopedTypeVariables -XUnboxedTuples -XForeignFunctionInterface -XUnliftedFFITypes -XDeriveDataTypeable -XGeneralizedNewtypeDeriving -XFlexibleInstances -XStandaloneDeriving -XPatternGuards -XEmptyDataDecls -XNoImplicitPrelude -XCPP -idist/build -Werror -H64m -O0 -fasm -O -fasm -dcore-lint -Wall -fno-warn-deprecated-flags -c Foreign/Marshal/Alloc.hs -o dist/build/Foreign/Marshal/Alloc.o -ohi dist/build/Foreign/Marshal/Alloc.hi Foreign/Marshal/Alloc.hs:201:0: Unacceptable type in foreign declaration: forall a. FinalizerPtr a When checking declaration: foreign import ccall unsafe "static stdlib.h &free" finalizerFree :: FinalizerPtr a make[2]: *** [dist/build/Foreign/Marshal/Alloc.o] Error 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 3 18:43:59 2009 From: trac at galois.com (GHC) Date: Tue Mar 3 18:33:02 2009 Subject: [GHC] #2619: Can't build older compiler In-Reply-To: <044.186108a575a6c194091f1f6cfd66d1a5@localhost> References: <044.186108a575a6c194091f1f6cfd66d1a5@localhost> Message-ID: <053.6ca5417b3b504c4892ef40551cea55f3@localhost> #2619: Can't build older compiler ---------------------------------+------------------------------------------ Reporter: judah | Owner: Type: bug | Status: reopened Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by chak): Replying to [comment:14 simonpj]: > I can see that it may not be worth fixing the old build system, and Ian says it's already done in the new system; so the short-term question is how Manuel and Roman can make progress. Manuel, Roman, do you have a workaround? This is not holding us up anymore. What initially did hold us up was understanding why the build failed. We are currently using Ben's version of the native code generator to do all Haskell compiling on the T2. So far, that works fine. Thanks, Ben. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 3 20:06:33 2009 From: trac at galois.com (GHC) Date: Tue Mar 3 19:55:14 2009 Subject: [GHC] #3068: broken link in http://www.haskell.org/ghc/docs/latest/html/users_guide/special-ids.html Message-ID: <041.a6c5744a059da97d330e77774471e867@localhost> #3068: broken link in http://www.haskell.org/ghc/docs/latest/html/users_guide /special-ids.html -----------------------------+---------------------------------------------- Reporter: nr | Owner: Type: bug | Status: new Priority: normal | Component: Documentation Version: 6.11 | Severity: minor Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- The GHC documentatation at http://www.haskell.org/ghc/docs/latest/html/users_guide/special-ids.html contains a broken link to the documentation for the GHC.Prim module. The link is to http://www.haskell.org/ghc/docs/latest/html/libraries/base /GHC-Prim.html, which is a dangling reference. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 3 20:16:14 2009 From: trac at galois.com (GHC) Date: Tue Mar 3 20:04:53 2009 Subject: [GHC] #2626: In ISO8601 the date and time should be separated by a 'T', not a space In-Reply-To: <053.3c40599d333cc0ff87ad32082ee97987@localhost> References: <053.3c40599d333cc0ff87ad32082ee97987@localhost> Message-ID: <062.501400212d7933e7ec2dbb8ef5473ea9@localhost> #2626: In ISO8601 the date and time should be separated by a 'T', not a space -----------------------------------+---------------------------------------- Reporter: MagnusTherning | Owner: igloo Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/old-time | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------+---------------------------------------- Changes (by igloo): * owner: => igloo Comment: http://www.haskell.org/pipermail/libraries/2008-September/010709.html -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 3 20:16:50 2009 From: trac at galois.com (GHC) Date: Tue Mar 3 20:05:30 2009 Subject: [GHC] #2626: In ISO8601 the date and time should be separated by a 'T', not a space In-Reply-To: <053.3c40599d333cc0ff87ad32082ee97987@localhost> References: <053.3c40599d333cc0ff87ad32082ee97987@localhost> Message-ID: <062.ab1985ed762bdcde9b4ec5567e7c7f10@localhost> #2626: In ISO8601 the date and time should be separated by a 'T', not a space -----------------------------------+---------------------------------------- Reporter: MagnusTherning | Owner: igloo Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/old-time | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------+---------------------------------------- Comment (by igloo): No discussion in the thread (link above), so will apply. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 3 21:35:21 2009 From: trac at galois.com (GHC) Date: Tue Mar 3 21:24:01 2009 Subject: [GHC] #3069: misspelled word in description of syntax extensions: s/enerated/enumerated/ Message-ID: <041.1485ad2be6ed6a3458a5a548738e6d17@localhost> #3069: misspelled word in description of syntax extensions: s/enerated/enumerated/ -----------------------------+---------------------------------------------- Reporter: nr | Owner: Type: bug | Status: new Priority: normal | Component: Documentation Version: 6.11 | Severity: trivial Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- In http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax- extns.html there is a misspelling. s/enerated/enumerated/ as in {{{the enumerated sequence [Monday..]}}} A quick wander about the Wiki didn't lead me to the place where the master source for GHC doco is stored. If someone can tell me I can fix this sort of thing myself. (And in fact if someone wants to email me now, I can retire this ticket myself.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 4 04:26:31 2009 From: trac at galois.com (GHC) Date: Wed Mar 4 04:15:08 2009 Subject: [GHC] #3066: Crash with bogus FFI declaration In-Reply-To: <046.a0d023407aaea2d72ef0e4c64d1c0cea@localhost> References: <046.a0d023407aaea2d72ef0e4c64d1c0cea@localhost> Message-ID: <055.e68f4740bd39104784a9e63790579717@localhost> #3066: Crash with bogus FFI declaration --------------------------------------+------------------------------------- Reporter: simonpj | Owner: igloo Type: merge | Status: new Priority: high | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: ffi/should_fail/T3066 | Os: Unknown/Multiple Architecture: Unknown/Multiple | --------------------------------------+------------------------------------- Changes (by simonpj): * owner: simonpj => igloo * type: bug => merge Comment: Sorry, my fault. My fix exposed a second bug which has been there for ages. Fixed by {{{ Wed Mar 4 09:19:13 GMT 2009 simonpj@microsoft.com * Fix a long-standing latent bug (and the build): check res_ty not sig_ty }}} Pls merge Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 4 04:27:14 2009 From: trac at galois.com (GHC) Date: Wed Mar 4 04:15:54 2009 Subject: [GHC] #3069: misspelled word in description of syntax extensions: s/enerated/enumerated/ In-Reply-To: <041.1485ad2be6ed6a3458a5a548738e6d17@localhost> References: <041.1485ad2be6ed6a3458a5a548738e6d17@localhost> Message-ID: <050.9a42447450da1cc7b2d09d05ecde6a4f@localhost> #3069: misspelled word in description of syntax extensions: s/enerated/enumerated/ ---------------------------------+------------------------------------------ Reporter: nr | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: Component: Documentation | Version: 6.11 Severity: trivial | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * owner: => igloo * difficulty: => Unknown * type: bug => merge Comment: Thanks, fixed by {{{ Wed Mar 4 09:22:32 GMT 2009 simonpj@microsoft.com * Fix spelling (Trac#3069) }}} The docs are in the main GHC repo, in docs/users_guide let's merge this Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 4 10:11:49 2009 From: trac at galois.com (GHC) Date: Wed Mar 4 10:00:30 2009 Subject: [GHC] #3018: Constraints of function in record appears to nullifiy instance constraints. In-Reply-To: <051.6f48ec69104cf641686fab51096e5186@localhost> References: <051.6f48ec69104cf641686fab51096e5186@localhost> Message-ID: <060.cd690e786bb8491abcd4c8976b158ccc@localhost> #3018: Constraints of function in record appears to nullifiy instance constraints. ---------------------------------+------------------------------------------ Reporter: ben.kavanagh | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * owner: => simonpj * difficulty: => Unknown * milestone: => _|_ Comment: Here are the key lines of code: {{{ class Subst a t t' where subst :: (Monad m) => a -> t -> t' -> m t' data SubstD a t t' = SubstD (forall m. Monad m => a -> t -> t' -> m t') instance Data (SubstD a t) t' => Subst a t t' -- (1) instance Subst a t t' => Sat (SubstD a t t') where -- (2) dict = SubstD subst }}} The call to 'subst' on the last line gives rise to a constraint `(Subst a t t')`. But that constraint can be satisfied in '''two different ways''': 1. Using the instance declaration for `Subst` (which matches ''anything''!) 2. Using the context of the `Sat (SubstD ..)` instance declaration itself If GHC uses (1) it gets into a corner it can't get out of, because now it needs `(Data (SubstD a t) t')`, and that it can't get. The error message is a bit misleading: {{{ T3018.hs:29:28: Could not deduce (Data (SubstD a t) t') from the context (Monad m) arising from a use of `subst' at T3018.hs:29:28-32 }}} it should really say {{{ ...from the context (Subst a t t', Monad m) }}} but that's a bit of a separate matter. Now, you are hoping that (2) will happen, but I hope you can see that it's delicate. Adding the `(Monad m)` context just tips things over the edge so that GHC doesn't "see" the `(Subst a t t')` in the context until too late. But the real problem is that you are asking too much. Here is a simpler example: {{{ f :: Eq [a] => a -> blah f x = let g :: Int -> Int g = ....([x]==[x])... in ... }}} The use of `==` requires `Eq [a]`, but GHC will probably use the list equality instance to simplify this to `Eq a`; and then it can't deduce `Eq a` from `Eq [a]`. Local constraints that shadow or override global instance declarations are extremely delicate. All this is perhaps soluble if GHC were to be lazier about solving constraints, and only makes the attempt when it has all the evidence in hand. I'm thinking quite a bit about constraint solving at the moment and will bear that in mind. But I can't offer you an immediate solution. At least I hope I've explained the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 4 10:32:12 2009 From: trac at galois.com (GHC) Date: Wed Mar 4 10:20:54 2009 Subject: [GHC] #2953: deriving Functor, Foldable, Traversable In-Reply-To: <045.1ed3b38adbe9ad6aceca4244fe75f3c0@localhost> References: <045.1ed3b38adbe9ad6aceca4244fe75f3c0@localhost> Message-ID: <054.dbb8d8d8f33e9726161f8766af71c317@localhost> #2953: deriving Functor, Foldable, Traversable ---------------------------------+------------------------------------------ Reporter: twanvl | Owner: twanvl Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by igloo): If we did that then it wouldn't be clear what a Cabal file saying it needs the `DeriveExtraClasses` extension actually meant. Would using ghc 6.10.1 be OK (only derives `Data`), would you need 6.12.1 (also derives `Functor`), or even 6.14.1 (derives something that isn't implemented yet). I don't know if cabal-install does this yet, but part of the plan was that if you told it to install a package `foo`, and `foo` needed an extension that your compiler doesn't support, then cabal-install would fail immediately, rather than downloading and building all of `foo`'s dependencies first. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 4 10:33:26 2009 From: trac at galois.com (GHC) Date: Wed Mar 4 10:22:14 2009 Subject: [GHC] #3070: floor(0/0) should not be defined Message-ID: <046.e7310ec88130e4aef68644b0cf077a3b@localhost> #3070: floor(0/0) should not be defined -----------------------------+---------------------------------------------- Reporter: carette | Owner: Type: bug | Status: new Priority: normal | Component: Prelude Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- floor(0/0) returns some giant negative integer - it should return NaN or undefined. The bug appears to be in some implementation of 'properFraction' in the standard library. [from Andrej Bauer, from Barak Pearlmutter (from ???)] -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 4 10:45:24 2009 From: trac at galois.com (GHC) Date: Wed Mar 4 10:34:01 2009 Subject: [GHC] #3061: GHC's GC default heap growth strategy is not as good as other runtimes In-Reply-To: <043.619b1558281745ecd214227681115d78@localhost> References: <043.619b1558281745ecd214227681115d78@localhost> Message-ID: <052.07a58427560651d9d5c5d1529b7d2667@localhost> #3061: GHC's GC default heap growth strategy is not as good as other runtimes ---------------------------------+------------------------------------------ Reporter: dons | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: Keywords: performance, GC | Difficulty: Unknown Testcase: yes | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * difficulty: => Unknown * milestone: => 6.12 branch Comment: So you're not allowed to use GC settings in the shootout? I think this benchmark is pathological for our default GC settings. The reason is that we use a small fixed-size allocation area, which is usually good for cache behaviour, but in this benchmark when we get to the larger tree sizes, we always GC before the tree has been constructed, and the GC therefore has to copy the tree, possibly multiple times. In fact this is very similar to a standard GC benchmark that we use. I'd be quite interested to know what other runtimes do here. I played a little with scaling up the size of the allocation area if we find we're copying a lot, but didn't see a dramatic improvement. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 4 10:46:05 2009 From: trac at galois.com (GHC) Date: Wed Mar 4 10:34:42 2009 Subject: [GHC] #3061: GHC's GC default heap growth strategy is not as good as other runtimes In-Reply-To: <043.619b1558281745ecd214227681115d78@localhost> References: <043.619b1558281745ecd214227681115d78@localhost> Message-ID: <052.591eb7c5cf7b16020b82fa7dfc994772@localhost> #3061: GHC's GC default heap growth strategy is not as good as other runtimes -----------------------------------------+---------------------------------- Reporter: dons | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: Keywords: performance, GC | Difficulty: Unknown Testcase: yes | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Changes (by simonmar): * type: bug => run-time performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 4 10:47:49 2009 From: trac at galois.com (GHC) Date: Wed Mar 4 10:36:26 2009 Subject: [GHC] #3062: Adding a ":clear" clear-screen command to GHCi In-Reply-To: <045.476dc977664d91167a93dd5781d1d04c@localhost> References: <045.476dc977664d91167a93dd5781d1d04c@localhost> Message-ID: <054.1408699ad92a1957ee521ff7aacb7844@localhost> #3062: Adding a ":clear" clear-screen command to GHCi ---------------------------------+------------------------------------------ Reporter: porges | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.11 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => wontfix Comment: I don't think this is something we need to add to GHCi. e.g. just hitting Ctrl-L does it for me. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 4 10:49:11 2009 From: trac at galois.com (GHC) Date: Wed Mar 4 10:37:48 2009 Subject: [GHC] #3029: ghc panic while installing hs-Crypto package (via macport) In-Reply-To: <047.aa9d2c38601915c3bc099893d3c1ddef@localhost> References: <047.aa9d2c38601915c3bc099893d3c1ddef@localhost> Message-ID: <056.7512adf55a0ff97e202429b6b02f4897@localhost> #3029: ghc panic while installing hs-Crypto package (via macport) -------------------------+-------------------------------------------------- Reporter: mreza101 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: duplicate Keywords: Crypto | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: Thanks for the report. This is a duplicate of #2753. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 4 10:52:54 2009 From: trac at galois.com (GHC) Date: Wed Mar 4 10:41:32 2009 Subject: [GHC] #3042: rts defines "real_main" which can clash with user C code In-Reply-To: <045.2ba5f7fc867f0e9727cddd2b5dbaa661@localhost> References: <045.2ba5f7fc867f0e9727cddd2b5dbaa661@localhost> Message-ID: <054.71c871a83aa57fd9f11e079511d03155@localhost> #3042: rts defines "real_main" which can clash with user C code ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: worksforme Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => worksforme Comment: Indeed I tried a little example, and didn't see any problems: {{{ #include #include void real_main(void) { exit(42); } void main(int argc, char *argv[]) { printf("main\n"); real_main(); } }}} {{{ > ./a.out main [3] 25611 exit 42 ./a.out }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 4 10:58:37 2009 From: trac at galois.com (GHC) Date: Wed Mar 4 10:47:15 2009 Subject: [GHC] #3068: broken link in http://www.haskell.org/ghc/docs/latest/html/users_guide/special-ids.html In-Reply-To: <041.a6c5744a059da97d330e77774471e867@localhost> References: <041.a6c5744a059da97d330e77774471e867@localhost> Message-ID: <050.f12a1dcd7a99e407c82e5d9f27fa6afc@localhost> #3068: broken link in http://www.haskell.org/ghc/docs/latest/html/users_guide /special-ids.html ---------------------------------+------------------------------------------ Reporter: nr | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 6.11 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * owner: => igloo * difficulty: => Unknown Comment: Thanks for the report. I'll fix it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 4 11:04:22 2009 From: trac at galois.com (GHC) Date: Wed Mar 4 10:53:04 2009 Subject: [GHC] #2619: Can't build older compiler In-Reply-To: <044.186108a575a6c194091f1f6cfd66d1a5@localhost> References: <044.186108a575a6c194091f1f6cfd66d1a5@localhost> Message-ID: <053.25d4dcbc3239ad39e3c7026311b9bf19@localhost> #2619: Can't build older compiler ---------------------------------+------------------------------------------ Reporter: judah | Owner: Type: bug | Status: reopened Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): Replying to [comment:14 simonpj]: > I can see that it may not be worth fixing the old build system, and Ian says it's already done in the new system; so the short-term question is how Manuel and Roman can make progress. Manuel, Roman, do you have a workaround? I think there was another issue raised by this thread, namely that building GHC using either * a HEAD snapshot, or * a newer GHC than the one we're building is not guaranteed to work. configure should test for these, and fail (perhaps with a `--force` option to ignore the error if you know what you're doing). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 4 11:21:23 2009 From: trac at galois.com (GHC) Date: Wed Mar 4 11:10:04 2009 Subject: [GHC] #2360: More information in occurs check message In-Reply-To: <042.d2d1b5c4c3c7a52b18a6186683534f09@localhost> References: <042.d2d1b5c4c3c7a52b18a6186683534f09@localhost> Message-ID: <051.53a59122d6fb48b764f90ef66cdb2bfe@localhost> #2360: More information in occurs check message ---------------------------------+------------------------------------------ Reporter: ajd | Owner: chak Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * owner: => chak * milestone: 6.10 branch => 6.12 branch Comment: Quite right. We can definitely improve this. Older versions of GHC did better: {{{ T2360.hs:4:10: Couldn't match expected type `[a]' against inferred type `a' (a rigid variable) `a' is bound by the type signature for `m' at T2360.hs:3:5 }}} Note to Manuel: the equality `a ~ [a]` is deferred, and then bleated about in `TcTyFuns.checkOrientation`. The latter is giving the wrong error. Let's fix this when the new solver is in place. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 4 11:23:29 2009 From: trac at galois.com (GHC) Date: Wed Mar 4 11:12:06 2009 Subject: [GHC] #2451: New signal-handling API In-Reply-To: <047.5b7641d67bfb4c219c1a85428fd85097@localhost> References: <047.5b7641d67bfb4c219c1a85428fd85097@localhost> Message-ID: <056.781ed80dfa2772d01fc02eda39762db4@localhost> #2451: New signal-handling API ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: proposal | Status: new Priority: high | Milestone: 6.12 branch Component: libraries/unix | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * priority: normal => high * milestone: Not GHC => 6.12 branch Comment: We should fix this, although it's not immediately clear to me how at first glance. Perhaps move `Signal` to a portable module? Perhaps even `System.Posix.Process.Internals`? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 4 11:52:47 2009 From: trac at galois.com (GHC) Date: Wed Mar 4 11:41:23 2009 Subject: [GHC] #3071: Network.Socket.recv throws IOException on reading 0 bytes Message-ID: <044.f28ebb983d23da6b0b734e05a1832f39@localhost> #3071: Network.Socket.recv throws IOException on reading 0 bytes -----------------------------+---------------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Component: libraries/network Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- My man pages has the following to say about the return value of `recv`: These calls return the number of bytes received, or -1 if an error occurred. For TCP sockets, the return value 0 means the peer has closed its half side of the connection. This means that it's absolutely fine to read 0 bytes when using e.g. UDP socket. However, the `Network.Socket.recv` function always throws an exception upon reading 0 bytes regardless of the protocol family. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 4 12:01:47 2009 From: trac at galois.com (GHC) Date: Wed Mar 4 11:50:32 2009 Subject: [GHC] #3027: Specialisation rules fail because dictionary projections do not match In-Reply-To: <068.47a834cf6bc8524dc890365958a3f55d@localhost> References: <068.47a834cf6bc8524dc890365958a3f55d@localhost> Message-ID: <077.7bc970ef42026bc578ac7c1d24005969@localhost> #3027: Specialisation rules fail because dictionary projections do not match ----------------------------------------------+----------------------------- Reporter: malcolm.wallace@cs.york.ac.uk | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------------+----------------------------- Comment (by simonpj): How do I run it to show the performance differences? I found 'main' in `Viewer`, but could not run: {{{ time ./viewer-6.10 Geometry [] viewer-6.10: Viewer.hs:(128,0)-(129,29): Non-exhaustive patterns in function cell_size_2D real 0m0.086s user 0m0.068s sys 0m0.018s bash-3.2$ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 4 12:03:37 2009 From: trac at galois.com (GHC) Date: Wed Mar 4 11:52:14 2009 Subject: [GHC] #3061: GHC's GC default heap growth strategy is not as good as other runtimes In-Reply-To: <043.619b1558281745ecd214227681115d78@localhost> References: <043.619b1558281745ecd214227681115d78@localhost> Message-ID: <052.8e730703d1c05c4f697ba75b34d41418@localhost> #3061: GHC's GC default heap growth strategy is not as good as other runtimes -----------------------------------------+---------------------------------- Reporter: dons | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: Keywords: performance, GC | Difficulty: Unknown Testcase: yes | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Comment (by dons): Replying to [comment:1 simonmar]: > So you're not allowed to use GC settings in the shootout? I think this benchmark is pathological for our default GC settings. The reason is that we use a small fixed-size allocation area, which is usually good for cache behaviour, but in this benchmark when we get to the larger tree sizes, we always GC before the tree has been constructed, and the GC therefore has to copy the tree, possibly multiple times. In fact this is very similar to a standard GC benchmark that we use. > Currently you can't, no. But the question is why can the other languages do better without the hint (e.g. Java is twice as fast, though on single core we're much better)? I wrote more about this benchmark in a blog post: http://donsbot.wordpress.com/2009/03/04/playing-with-ghcs-parallel- runtime/ -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 4 12:03:38 2009 From: trac at galois.com (GHC) Date: Wed Mar 4 11:52:17 2009 Subject: [GHC] #3059: 3 different behaviours depending on profiling settings and on a used-only-once form being top-level In-Reply-To: <043.65beacb4ac206762f56576480f564413@localhost> References: <043.65beacb4ac206762f56576480f564413@localhost> Message-ID: <052.8360f5b2323912bd5a42cc5f4fa66a60@localhost> #3059: 3 different behaviours depending on profiling settings and on a used-only- once form being top-level ----------------------+----------------------------------------------------- Reporter: jkff | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Windows | Architecture: x86 ----------------------+----------------------------------------------------- Comment (by ChrisKuklewicz): I have investigated further. The problem is that the regex-tdfa-1.0.0 code is just too generic. For example: the test above will take the Lazy ByteString and convert it to a String for searching. The text just needs to be tested, and yet the engine will try and find the best Posix match including captures. An optimized Strict Bytestring version (will be in regex-tdfa after 1.0.0), using the test like http://haskell.org/haskellwiki/?title=Regular_expressions#Sample_benchmark gives: Old: pamac-cek10:compare-tdfa chrisk$ time ./wiki-1.0.1-sbs wiki 1000000 Test for Data.ByteString.Internal.ByteString Right 1000000 real 0m22.692s user 0m5.352s sys 0m0.195s New: pamac-cek10:compare-tdfa chrisk$ time ./wiki-1.0.1-sbs-v2 wiki 1000000 Test for Data.ByteString.Internal.ByteString Right 1000000 real 0m0.714s user 0m0.159s sys 0m0.017s So that is at least a thirty-fold improvement. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 4 12:13:17 2009 From: trac at galois.com (GHC) Date: Wed Mar 4 12:02:03 2009 Subject: [GHC] #3041: Arch independent binary representations In-Reply-To: <046.ec9add4015adc692796a9426b46aeec0@localhost> References: <046.ec9add4015adc692796a9426b46aeec0@localhost> Message-ID: <055.f79c23c90241e629f83debdc60c8b701@localhost> #3041: Arch independent binary representations ---------------------------------+------------------------------------------ Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by waern): I added a Haddock ticket for this: http://trac.haskell.org/haddock/ticket/96 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 4 12:18:39 2009 From: trac at galois.com (GHC) Date: Wed Mar 4 12:07:18 2009 Subject: [GHC] #3060: impossible internal bug while building darcs In-Reply-To: <044.8b050eb370b3a248f628f79a0a5b8c10@localhost> References: <044.8b050eb370b3a248f628f79a0a5b8c10@localhost> Message-ID: <053.12a5ca3a5fa3b6c632ebf7c46632ca51@localhost> #3060: impossible internal bug while building darcs -------------------------+-------------------------------------------------- Reporter: quick | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------+-------------------------------------------------- Comment (by quick): This is a clean directory using the config/make build. It appears to be related to optimization: $ rm src/Exec.o $ ghc -dcore-lint -I. -I./src -I./src -i./src -c src/Exec.hs $ rm src/Exec.o $ ghc -dcore-lint -I. -I./src -I./src -i./src -c -O2 src/Exec.hs ghc: panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-unknown-linux): applyTypeToArgs unix-2.3.1.0:System.Posix.Signals.a38{v reS} [gid] (unix-2.3.1.0:System.Posix.Signals.a5{v reR} [gid] `cast` (ghc-prim:GHC.Prim.sym{(w) tc 34v} base:Foreign.C.Types.:CoCInt{tc ra3} :: base:GHC.Int.Int32{tc 3V} ~ base:Foreign.C.Types.CInt{tc ra6})) unix-2.3.1.0:System.Posix.Signals.Ignore{v reQ} [gid] (base:Data.Maybe.Nothing{v r5F} [gid] @ unix-2.3.1.0:System.Posix.Signals.SignalSet{tc reP}) eta{v a1UC} [lid] (# ghc-prim:GHC.Prim.State#{(w) tc 32q} ghc-prim:GHC.Prim.RealWorld{(w) tc 31E}, unix-2.3.1.0:System.Posix.Signals.SignalSet{tc reP} #) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug The actual full make-generated line (from $ make VERBOSE=true): $ ghc -hide-all-packages -package haskell98 -package base-3.0.3.0 -threaded -package regex-compat -package network -package HTTP -package filepath -package bytestring -package random -package directory -package old-time -package process -package array -package old-locale -package mtl -package parsec -package html -package containers -package unix -O2 -funbox-strict-fields -D_REENTRANT -DHAVE_CURL -DCURL_MULTI_TIMEOUT -DHAVE_CURSES -DPACKAGE_NAME=\"darcs\" -DPACKAGE_TARNAME=\"darcs\" -DPACKAGE_VERSION=\"2.2.0\" -DPACKAGE_STRING=\"darcs\ 2.2.0\" -DPACKAGE_BUGREPORT=\"bugs@darcs.net\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_HTTP=1 -DHAVE_SIGNALS=1 -DHAVE_LIBCURL=1 -Wall -I. -I./src -i./src -dcore-lint -c src/Exec.hs Also note that the -dcore-lint doesn't seem to have any effect. Let me know if there's anything else I can provide. -Kevin -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 4 12:33:55 2009 From: trac at galois.com (GHC) Date: Wed Mar 4 12:22:36 2009 Subject: [GHC] #3060: impossible internal bug while building darcs In-Reply-To: <044.8b050eb370b3a248f628f79a0a5b8c10@localhost> References: <044.8b050eb370b3a248f628f79a0a5b8c10@localhost> Message-ID: <053.9211ce72da21553e4c04ad5d2da1defa@localhost> #3060: impossible internal bug while building darcs -------------------------+-------------------------------------------------- Reporter: quick | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------+-------------------------------------------------- Comment (by quick): Also note that the same error is reported for src/Darcs/External.hs and-- as above--dropping the -O2 flag allows it to compile successfully. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 4 12:50:44 2009 From: trac at galois.com (GHC) Date: Wed Mar 4 12:39:24 2009 Subject: [GHC] #3060: impossible internal bug while building darcs In-Reply-To: <044.8b050eb370b3a248f628f79a0a5b8c10@localhost> References: <044.8b050eb370b3a248f628f79a0a5b8c10@localhost> Message-ID: <053.59090bb15d05792e31f21dd89fa0f462@localhost> #3060: impossible internal bug while building darcs -------------------------+-------------------------------------------------- Reporter: quick | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------+-------------------------------------------------- Comment (by simonpj): I downloaded http://darcs.net/darcs-2.2.0.tar.gz, and ran your command line. Complained about lack of HTTP library. So I installed HTTP-4000.0.4. Tried again, with `--make -O2`: {{{ bash-3.2$ ghc -hide-all-packages -package haskell98 -package base-3.0.3.0 -threaded -package regex-compat -package network -package HTTP -package filepath -package bytestring -package random -package directory -package old-time -package process -package array -package old-locale -package mtl -package parsec -package html -package containers -package unix -O2 -funbox-strict-fields -D_REENTRANT -DHAVE_CURL -DCURL_MULTI_TIMEOUT -DHAVE_CURSES -DPACKAGE_NAME=\"darcs\" -DPACKAGE_TARNAME=\"darcs\" -DPACKAGE_VERSION=\"2.2.0\" -DPACKAGE_STRING=\"darcs\ 2.2.0\" -DPACKAGE_BUGREPORT=\"bugs@darcs.net\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_HTTP=1 -DHAVE_SIGNALS=1 -DHAVE_LIBCURL=1 -Wall -I. -I./src -i./src -dcore-lint --make src/Exec.hs -O2 [1 of 3] Compiling Darcs.Global ( src/Darcs/Global.hs, src/Darcs/Global.o ) [2 of 3] Compiling Progress ( src/Progress.hs, src/Progress.o ) [3 of 3] Compiling Exec ( src/Exec.hs, src/Exec.o ) bash-3.2$ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.10.1 }}} Worked fine. So I still can't reproduce your problem. Can you start from scratch and show a log of every single step? BTW, don't forget the `{{{` ... `}}}` brackets, else your code gets "typeset" by the wiki. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 4 12:57:14 2009 From: trac at galois.com (GHC) Date: Wed Mar 4 12:45:58 2009 Subject: [GHC] #3027: Specialisation rules fail because dictionary projections do not match In-Reply-To: <068.47a834cf6bc8524dc890365958a3f55d@localhost> References: <068.47a834cf6bc8524dc890365958a3f55d@localhost> Message-ID: <077.e9e3148a80a1563340c4b1e9603b1acd@localhost> #3027: Specialisation rules fail because dictionary projections do not match ----------------------------------------------+----------------------------- Reporter: malcolm.wallace@cs.york.ac.uk | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------------+----------------------------- Comment (by malcolm.wallace@cs.york.ac.uk): The currently-attached archive is a cut-down version of the real code, intended only to show the bug in the core output. The full code that can be used to illustrate the performance differences requires several extra packages (OpenGL, smallcheck, polyparse), plus some large datasets. Sorry I have not recently had the time to collect all these materials together so that you can reproduce it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 4 13:01:17 2009 From: trac at galois.com (GHC) Date: Wed Mar 4 12:50:00 2009 Subject: [GHC] #3027: Specialisation rules fail because dictionary projections do not match In-Reply-To: <068.47a834cf6bc8524dc890365958a3f55d@localhost> References: <068.47a834cf6bc8524dc890365958a3f55d@localhost> Message-ID: <077.919d6a77fcb253a010bf1807face9d96@localhost> #3027: Specialisation rules fail because dictionary projections do not match ----------------------------------------------+----------------------------- Reporter: malcolm.wallace@cs.york.ac.uk | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------------+----------------------------- Comment (by simonpj): OK, but '''what''' bug in the core output?!! Can you give instructions to reproduce? Is this the bug that no longer exists in 6.10? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 4 13:12:35 2009 From: trac at galois.com (GHC) Date: Wed Mar 4 13:01:12 2009 Subject: [GHC] #3072: considerations for management of shared libs Message-ID: <045.6f777a46b5d4eb212ac94c917f9f3ef8@localhost> #3072: considerations for management of shared libs ---------------------+------------------------------------------------------ Reporter: duncan | Owner: Type: proposal | Status: new Priority: normal | Component: None Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: Unknown/Multiple ---------------------+------------------------------------------------------ Some thought needs to be put into how to manage shared libs on the various platforms we support. Sadly the solution is likely to be different on Windows vs OSX vs ELF-format platforms. For ELF platforms our current idea is to put all shared libs in `/usr{/local}/lib` with names like `libHSfoo-x.y.z-ghc-a.b.c.so`. Having them all in the system dir like that has it's downsides and it does not work for per-user installs. If we want to have multiple instances of the same version of a lib then it's even more problematic. All ELF linkers support the RPATH/RUNPATH mechanism for executables and shared libs to locate each other without them having to be on the standard linker path. This basically involves embedding the path in them at link time. It must be acknowledged that some linux distributions eschew the use of rpath for various reasons. We must take that into consideration. Also we must consider relocatable/redistributable binaries... The GNU and Solaris linkers support an extension which allows the above mechanism to work, even for relocatable binaries (so long as the libs are kept relative to the executable). Basically one can set an rpath that uses `$ORIGIN` and at runtime the `$ORIGIN` is substituted for the file system location of the executable or shared lib in question. Note that on Linux at least the `$ORIGIN` is always passed by the kernel so that the dynamic linker can resolve it. See the attached program which demonstrates this. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 4 13:16:20 2009 From: trac at galois.com (GHC) Date: Wed Mar 4 13:04:58 2009 Subject: [GHC] #3072: considerations for management of shared libs In-Reply-To: <045.6f777a46b5d4eb212ac94c917f9f3ef8@localhost> References: <045.6f777a46b5d4eb212ac94c917f9f3ef8@localhost> Message-ID: <054.4bd54f0167e598b53c223664a7a01344@localhost> #3072: considerations for management of shared libs ----------------------+----------------------------------------------------- Reporter: duncan | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: None | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Linux | Architecture: Unknown/Multiple ----------------------+----------------------------------------------------- Comment (by duncan): Should have linked to the docs for `$ORIGIN`: Solaris: http://docs.sun.com/app/docs/doc/805-3050/6j2tng0mg?l=ko&a=view Solaris and Linux: http://www.scons.org/wiki/UsingOrigin GNU man ld.so {{{ $ORIGIN and rpath ld.so understands the string $ORIGIN (or equivalently ${ORIGIN}) in an rpath specification (DT_RPATH or DT_RUNPATH) to mean the directory con? taining the application executable. Thus, an application located in somedir/app could be compiled with gcc -Wl,-rpath,'$ORIGIN/../lib' so that it finds an associated shared library in somedir/lib no matter where somedir is located in the directory hierarchy. This facilitates the creation of "turn-key" applications that do not need to be installed into special directories, but can instead be unpacked into any directory and still find their own shared libraries. }}} This may also be useful for binary distributions of ghc that use shared libs. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 4 13:30:39 2009 From: trac at galois.com (GHC) Date: Wed Mar 4 13:19:16 2009 Subject: [GHC] #3066: Crash with bogus FFI declaration In-Reply-To: <046.a0d023407aaea2d72ef0e4c64d1c0cea@localhost> References: <046.a0d023407aaea2d72ef0e4c64d1c0cea@localhost> Message-ID: <055.b35c22ecc7b982fcce22853d4a5a709f@localhost> #3066: Crash with bogus FFI declaration --------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: ffi/should_fail/T3066 | Os: Unknown/Multiple Architecture: Unknown/Multiple | --------------------------------------+------------------------------------- Changes (by igloo): * owner: igloo => simonpj * type: merge => bug Comment: These patches make haddock apparently go into an infinite loop (when haddocking the unix package). I'm not sure if this is a bug in haddock or GHC. Do you know what's going on? With this `Q.hs`: {{{ module Q () where newtype Foo = Foo Foo }}} {{{ $ /home/ian/ghc/6.10-branch/ghc/utils/haddock/install-inplace/bin/haddock --html -B/home/ian/ghc/6.10-branch/ghc/inplace-datadir Q --optghc=-v Using package config file: /home/ian/ghc/6.10-branch/ghc/inplace-datadir /../inplace-datadir/package.conf hiding package base-3.0.3.0 to avoid conflict with later version base-4.0.0.0 wired-in package ghc-prim mapped to ghc-prim-0.1.0.0 wired-in package integer mapped to integer-0.1.0.0 wired-in package base mapped to base-4.0.0.0 wired-in package rts mapped to rts-1.0 wired-in package haskell98 mapped to haskell98-1.0.1.0 wired-in package syb mapped to syb-0.1.0.0 wired-in package template-haskell mapped to template-haskell-2.3.0.0 wired-in package dph-seq[""] not found. wired-in package dph-par[""] not found. *** Chasing dependencies: Chasing modules from: *Q.hs *** Parser: *** Renamer/typechecker: *** Tidy [hoot] type env: compile: input file Q.hs *** Tidy [hoot] type env: }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 4 14:07:21 2009 From: trac at galois.com (GHC) Date: Wed Mar 4 13:55:58 2009 Subject: [GHC] #3066: Crash with bogus FFI declaration In-Reply-To: <046.a0d023407aaea2d72ef0e4c64d1c0cea@localhost> References: <046.a0d023407aaea2d72ef0e4c64d1c0cea@localhost> Message-ID: <055.56936cdb2470f08384232e5562f1ca48@localhost> #3066: Crash with bogus FFI declaration --------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: ffi/should_fail/T3066 | Os: Unknown/Multiple Architecture: Unknown/Multiple | --------------------------------------+------------------------------------- Comment (by igloo): ghci also seems to go into an infinite loop on `Q.hs`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 4 14:08:26 2009 From: trac at galois.com (GHC) Date: Wed Mar 4 13:57:02 2009 Subject: [GHC] #2626: In ISO8601 the date and time should be separated by a 'T', not a space In-Reply-To: <053.3c40599d333cc0ff87ad32082ee97987@localhost> References: <053.3c40599d333cc0ff87ad32082ee97987@localhost> Message-ID: <062.46526e1c7a46ce215988d909e000ffef@localhost> #2626: In ISO8601 the date and time should be separated by a 'T', not a space -----------------------------------+---------------------------------------- Reporter: MagnusTherning | Owner: igloo Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/old-time | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------+---------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Applied. Thanks, Magnus! -- Ticket URL: GHC The Glasgow Haskell Compiler From conal at conal.net Wed Mar 4 14:55:00 2009 From: conal at conal.net (Conal Elliott) Date: Wed Mar 4 14:43:35 2009 Subject: mkCase: null alts wild_Xs{v} [lid] a{v ace2} [lid] Message-ID: I'm getting this message from ghc 6.11.20090115: mkCase: null alts wild_Xs{v} [lid] a{v ace2} [lid] My code compiles and seems to run okay. Is it anything to worry about? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-bugs/attachments/20090304/e6b3c61c/attachment-0001.htm From trac at galois.com Wed Mar 4 14:57:16 2009 From: trac at galois.com (GHC) Date: Wed Mar 4 14:46:04 2009 Subject: [GHC] #3027: Specialisation rules fail because dictionary projections do not match In-Reply-To: <068.47a834cf6bc8524dc890365958a3f55d@localhost> References: <068.47a834cf6bc8524dc890365958a3f55d@localhost> Message-ID: <077.7f8212f803badb75f251b5a47d0bc69f@localhost> #3027: Specialisation rules fail because dictionary projections do not match ----------------------------------------------+----------------------------- Reporter: malcolm.wallace@cs.york.ac.uk | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------------+----------------------------- Comment (by malcolm.wallace@cs.york.ac.uk): Yes, the code in the attached archive "specialisation-bug.tar.gz" is for the originally stated bug, which has been fixed in 6.10.1. To reproduce it, first compile everything with ghc Viewer.hs --make -O2, then recompile just the module containing the usage site (Viewer.hs), with -O2 -ddump-simpl or -dverbose-core2core, to see the lack of specialisation (in ghc-6.8.2) or the presence of the desired specialisation (in ghc-6.10.1). However, you asked for more information, because the code produced by 6.10.1 is often significantly slower, despite the better job of specialisation. I have not yet gathered all the pieces you would require to reproduce this performance regression, which is likely to be a separate bug/issue altogether. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 4 15:17:55 2009 From: trac at galois.com (GHC) Date: Wed Mar 4 15:06:32 2009 Subject: [GHC] #3059: 3 different behaviours depending on profiling settings and on a used-only-once form being top-level In-Reply-To: <043.65beacb4ac206762f56576480f564413@localhost> References: <043.65beacb4ac206762f56576480f564413@localhost> Message-ID: <052.750861f1e589dd6710f5ec57383d3edf@localhost> #3059: 3 different behaviours depending on profiling settings and on a used-only- once form being top-level ----------------------+----------------------------------------------------- Reporter: jkff | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Windows | Architecture: x86 ----------------------+----------------------------------------------------- Comment (by ChrisKuklewicz): In specializing regex-tdfa (post 1.0.0) for "matchTest" with strict bytestrings, I wrote code that worked great as I posted above. I am always compiling with -O2 on PPC G4. But only with -prof. Without -prof it took 4.0 seconds instead of 0.3 seconds (and half of that is overhead). I used "ghc-core" to look at the core and saw nothing wrong. I commented out everything and made tiny modifications. I have over 12 test versions before I narrowed it down to using mplus. Note: mplus is not in the core output by name. {{{ case (IntMap.lookup ...) `mplus` maybeDefault of Nothing -> False Just -> ....iterate the loop... }}} And replacing mplus with my own two-stage case or the new "mm" combinator fixed it. {{{ {-# INLINE mm #-} mm :: Maybe Transition -> Maybe Transition -> (DT -> Bool) -> Bool mm (Just (Transition {trans_many=DFA {d_dt=dfa'}})) _ f = f dfa' mm Nothing (Just (Transition {trans_many=DFA {d_dt=dfa'}})) f = f dfa' mm Nothing Nothing _ = False }}} So GHC really did not do the right thing with my code. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 4 16:54:43 2009 From: trac at galois.com (GHC) Date: Wed Mar 4 16:43:22 2009 Subject: [GHC] #3039: strange space usage In-Reply-To: <044.6222a2241621a8a36e8604831e185979@localhost> References: <044.6222a2241621a8a36e8604831e185979@localhost> Message-ID: <053.fb6c17d650c40b691848447b467c8911@localhost> #3039: strange space usage -----------------------------------------+---------------------------------- Reporter: igloo | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Changes (by igloo): * milestone: => 6.12 branch Comment: One thing here that I think is a profiling bug is the biographical profile output. One odd thing is that the amount of memory shown on the graph is only half that shown on the `-hy` graph. The other thing is that it is shown as all VOID, but if this is the filename then surely it should all be DRAG? Memory use drops by a factor of 10 when using `-C0`, and runtime drops a little too: {{{ ./base +RTS -t 'z' <> ./base +RTS -t 17.37s user 3.46s system 100% cpu 20.821 total ./base +RTS -t -C0 'z' <> ./base +RTS -t -C0 15.78s user 3.28s system 99% cpu 19.062 total }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 4 17:47:05 2009 From: trac at galois.com (GHC) Date: Wed Mar 4 17:35:42 2009 Subject: [GHC] #2962: Reduce space usage of genericLength for common Num instances In-Reply-To: <050.56d33139a9874005c965ed3f7cb60dae@localhost> References: <050.56d33139a9874005c965ed3f7cb60dae@localhost> Message-ID: <059.f4e3ba65737cd49a7e5886ff4aebfe06@localhost> #2962: Reduce space usage of genericLength for common Num instances --------------------------------------+------------------------------------- Reporter: thorkilnaur | Owner: thorkilnaur Type: bug | Status: closed Priority: normal | Milestone: 6.12 branch Component: libraries/base | Version: 6.11 Severity: normal | Resolution: fixed Keywords: rules, specialisation | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | --------------------------------------+------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Applied, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 4 18:05:46 2009 From: trac at galois.com (GHC) Date: Wed Mar 4 17:54:24 2009 Subject: [GHC] #3060: impossible internal bug while building darcs In-Reply-To: <044.8b050eb370b3a248f628f79a0a5b8c10@localhost> References: <044.8b050eb370b3a248f628f79a0a5b8c10@localhost> Message-ID: <053.fb11ef63b7b5a58a631e51ebb8258ae4@localhost> #3060: impossible internal bug while building darcs -------------------------+-------------------------------------------------- Reporter: quick | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: major | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by quick): * status: new => closed * resolution: => invalid Comment: I have a tentative solution. Tentative because it did resolve the problem for me, but I don't know if this would help the similar reported errors. When I started, I was upgrading from GHC 6.8.3 to GHC 6.10.1, which created a new ghc-pkg database, so I had then attempted to re-install all the library packages I had previously installed. It seems that the problems start occurring when I installed the unix-2.3.1.0 package. This package is (no longer) necessary for my environment because the functionality is now builtin to GHC 6.10.1; actually installing and registring unix-2.3.1.0 introduced the failures described here. Another clue was that directory started causing problems: {{{ [ghc] src/Darcs/Commands/Apply.o /Programs/GHC/6.10.1/lib/ghc-6.10.1/directory-1.0.0.2/System/Directory.hi Declaration for removeFile Unfolding of System.Directory.removeFile: Can't find interface-file declaration for variable System.Posix.Files.a52 Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error }}} and {{{ [ghc] darcs /Programs/GHC/6.10.1/lib/ghc-6.10.1/directory-1.0.0.2/libHSdirectory-1.0.0.2.a(Directory__71.o):(.text+0x29): undefined reference to `unixzm2zi3zi1zi0_SystemziPosixziDirectory_a12_info' /Programs/GHC/6.10.1/lib/ghc-6.10.1/directory-1.0.0.2/libHSdirectory-1.0.0.2.a(Directory__71.o): In function `directoryzm1zi0zi0zi2_SystemziDirectory_a27_srt': (.data+0x0): undefined reference to `unixzm2zi3zi1zi0_SystemziPosixziDirectory_a12_closure' /Programs/GHC/6.10.1/lib/ghc-6.10.1/directory-1.0.0.2/libHSdirectory-1.0.0.2.a(Directory__73.o): In function `s6CP_info': (.text+0x19d): undefined reference to `unixzm2zi3zi1zi0_SystemziPosixziFiles_a55_info' /Programs/GHC/6.10.1/lib/ghc-6.10.1/directory-1.0.0.2/libHSdirectory-1.0.0.2.a(Directory__73.o): In function `directoryzm1zi0zi0zi2_SystemziDirectory_a28_srt': (.data+0x4): undefined reference to `unixzm2zi3zi1zi0_SystemziPosixziFiles_a55_closure' /Programs/GHC/6.10.1/lib/ghc-6.10.1/directory-1.0.0.2/libHSdirectory-1.0.0.2.a(Directory__77.o): In function `s6PY_info': (.text+0x40): undefined reference to `unixzm2zi3zi1zi0_SystemziPosixziFiles_a55_info' /Programs/GHC/6.10.1/lib/ghc-6.10.1/directory-1.0.0.2/libHSdirectory-1.0.0.2.a(Directory__77.o): In function `directoryzm1zi0zi0zi2_SystemziDirectory_a32_srt': (.data+0x4): undefined reference to `unixzm2zi3zi1zi0_SystemziPosixziFiles_a55_closure' ... }}} I rebuilt and re-installed GHC 6.10.1 and did *not* install unix-2.3.1.0. I am now successfully able to build darcs. As a side note, I cannot build QuickCheck-2.1.0.1 with GHC 6.10.1; I don't know if this is a known issue or not: {{{ Building QuickCheck-2.1.0.1... [ 1 of 11] Compiling Test.QuickCheck.Exception ( Test/QuickCheck/Exception.hs, dist/build/Test/QuickCheck/Exception.o ) Test/QuickCheck/Exception.hs:12:31: Class `Exception' used as a type In the type `Exception' In the type `Either Exception a' In the type `IO (Either Exception a)' Test/QuickCheck/Exception.hs:15:36: Class `Exception' used as a type In the type `Exception' In the type `Either Exception a' In the type `IO (Either Exception a)' }}} Anyhow, root cause was PEBKAC... sorry to have wasted your time. -Kevin -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 5 02:09:10 2009 From: trac at galois.com (GHC) Date: Thu Mar 5 01:58:29 2009 Subject: [GHC] #1876: Complete shared library support In-Reply-To: <047.2ab772cd4150dcd51ba47e309570e649@localhost> References: <047.2ab772cd4150dcd51ba47e309570e649@localhost> Message-ID: <056.e1839df43d924b981afb5e71b53a2050@localhost> #1876: Complete shared library support ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: task | Status: new Priority: high | Milestone: 6.10 branch Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Difficult (1 week) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by juhpetersen): Replying to [comment:15 simonmar]: > Grab the GHC sources, configure with `--enable-shared`, build as normal and report problems that you encounter. Ok, sorry for the delay. I installed libffi-devel on Fedora rawhide and got quite far this time with stable: : : /home/petersen/ghc-6.10.1.20090303/utils/installPackage/install- inplace/bin/installPackage install '/home/petersen/ghc-6.10.1.20090303/utils/ghc-pkg/install-inplace/bin/ghc- pkg' 'XXX/package.conf' "" \ /home/petersen/ghc-6.10.1.20090303/ghc/stage2-inplace \ /home/petersen/ghc-6.10.1.20090303/ghc/stage2-inplace \ '$prefix' \ '/home/petersen/ghc-6.10.1.20090303/inplace- datadir' \ '$prefix/libexec' \ '$prefix/dynlib' \ '/home/petersen/ghc-6.10.1.20090303/inplace- datadir' \ '$prefix/doc' \ '$prefix/html' \ '$prefix/haddock' \ --distpref dist-stage2 \ --disable-executable-stripping \ --enable-shell-wrappers Installing executable(s) in /home/petersen/ghc-6.10.1.20090303/ghc/stage2-inplace make[3]: Leaving directory `/home/petersen/ghc-6.10.1.20090303/ghc' make[2]: Leaving directory `/home/petersen/ghc-6.10.1.20090303/compiler' make -C utils with-stage-2 make[2]: Entering directory `/home/petersen/ghc-6.10.1.20090303/utils' make -C installPackage with-stage-2 make[3]: Entering directory `/home/petersen/ghc-6.10.1.20090303/utils/installPackage' /home/petersen/ghc-6.10.1.20090303/libraries/cabal-bin /usr/bin/ghc /home/petersen/ghc-6.10.1.20090303/libraries/bootstrapping.conf 1.6.0.2 configure --distpref dist-install \ --prefix=/NONEXISTENT --bindir=/NONEXISTENT --libdir=/NONEXISTENT --libexecdir=/NONEXISTENT --datadir=/NONEXISTENT --docdir=/NONEXISTENT --haddockdir=/NONEXISTENT --htmldir=/NONEXISTENT \ --with- compiler=/home/petersen/ghc-6.10.1.20090303/ghc/stage2-inplace/ghc --with- hc-pkg=/home/petersen/ghc-6.10.1.20090303/utils/ghc-pkg/install- inplace/bin/ghc-pkg --package-db /home/petersen/ghc-6.10.1.20090303/stage3.package.conf \ --libsubdir='$pkgid' --with-gcc=gcc --with- ld=/usr/bin/ld --with-happy="/usr/bin/happy" --configure-option ='--enable-shared' --configure-option=--with-cc="gcc" --with- hsc2hs=/home/petersen/ghc-6.10.1.20090303/utils/hsc2hs/install- inplace/bin/hsc2hs \ --constraint="Cabal == 1.6.0.2" Configuring installPackage-1.0... cabal-bin: ghc version >=6.4 is required but the version of /home/petersen/ghc-6.10.1.20090303/ghc/stage2-inplace/ghc could not be determined. make[3]: *** [with-stage-2] Error 1 make[3]: Leaving directory `/home/petersen/ghc-6.10.1.20090303/utils/installPackage' make[2]: *** [with-stage-2.installPackage] Error 2 make[2]: Leaving directory `/home/petersen/ghc-6.10.1.20090303/utils' make[1]: *** [stage2] Error 2 make[1]: Leaving directory `/home/petersen/ghc-6.10.1.20090303' make: *** [bootstrap2] Error 2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 5 03:58:36 2009 From: trac at galois.com (GHC) Date: Thu Mar 5 03:47:12 2009 Subject: [GHC] #3060: impossible internal bug while building darcs In-Reply-To: <044.8b050eb370b3a248f628f79a0a5b8c10@localhost> References: <044.8b050eb370b3a248f628f79a0a5b8c10@localhost> Message-ID: <053.4eff4aa6b23fb1061f1087ae645c1b46@localhost> #3060: impossible internal bug while building darcs -------------------------+-------------------------------------------------- Reporter: quick | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: major | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------+-------------------------------------------------- Comment (by simonpj): I'm glad you're rolling again, but I'm still mystified. That "Can't find interface-file declaration" message sounds just like a stale interface file, which can give all sorts of trouble. What happens if you now install unix-2.3.1.0 in your fresh GHC 6.10? (When I say "install" I mean "using Cabal or something" so that you compile it from scratch; a binary download won't do.) If installing the unix package breaks the build, something is still wrong. Re Quickcheck, GHC 6.10 has a new implementation of exceptions. I think you can get the old one back with some package incantation like -package base-3, but I'm not certain. Ask the libraries list. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From simonpj at microsoft.com Thu Mar 5 04:31:01 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Mar 5 04:19:38 2009 Subject: mkCase: null alts wild_Xs{v} [lid] a{v ace2} [lid] In-Reply-To: References: Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C334CB31594D@EA-EXMSG-C334.europe.corp.microsoft.com> It's a bit unusual, but it shows up in a situation like this data T a where T1 :: T Int T2 :: T Bool x :: T Char ...case x of { ... }.... In this case no patterns can match, so the entire case should be unreachable. In this situation the entire case is replaced by (error "Impossible alternative"). (Should really say "Unreachable case expression".) It's quite difficult to make this happen without the enclosing code also being unreachable and discarded, which is why I flagged it. You could do some -dverbose-core2core stuff to see it happening if you liked, but no, it should not be harmful. Simon From: glasgow-haskell-bugs-bounces@haskell.org [mailto:glasgow-haskell-bugs-bounces@haskell.org] On Behalf Of Conal Elliott Sent: 04 March 2009 19:55 To: glasgow-haskell-bugs@haskell.org Subject: mkCase: null alts wild_Xs{v} [lid] a{v ace2} [lid] I'm getting this message from ghc 6.11.20090115: mkCase: null alts wild_Xs{v} [lid] a{v ace2} [lid] My code compiles and seems to run okay. Is it anything to worry about? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-bugs/attachments/20090305/b48fd345/attachment.htm From trac at galois.com Thu Mar 5 04:33:16 2009 From: trac at galois.com (GHC) Date: Thu Mar 5 04:22:00 2009 Subject: [GHC] #3027: Specialisation rules fail because dictionary projections do not match In-Reply-To: <068.47a834cf6bc8524dc890365958a3f55d@localhost> References: <068.47a834cf6bc8524dc890365958a3f55d@localhost> Message-ID: <077.884563298813fba9b425882b3242b31e@localhost> #3027: Specialisation rules fail because dictionary projections do not match ----------------------------------------------+----------------------------- Reporter: malcolm.wallace@cs.york.ac.uk | Owner: Type: bug | Status: closed Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------------+----------------------------- Changes (by simonpj): * milestone: => _|_ Comment: Oh I see. I'm not going to investigate 6.8.2, because we won't make a new release on that branch. If and when you have time to characterise the performance lossage wrt 6.8.2 I'd be v happy to investigate. I hate things going slower. But no rush. I'll leave the ticket open (although you might want to close it and open a new one when you get to this). Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 5 04:35:27 2009 From: trac at galois.com (GHC) Date: Thu Mar 5 04:24:02 2009 Subject: [GHC] #3061: GHC's GC default heap growth strategy is not as good as other runtimes In-Reply-To: <043.619b1558281745ecd214227681115d78@localhost> References: <043.619b1558281745ecd214227681115d78@localhost> Message-ID: <052.ea1dbb63b8d0a48ad902d0fe666231c0@localhost> #3061: GHC's GC default heap growth strategy is not as good as other runtimes -----------------------------------------+---------------------------------- Reporter: dons | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: Keywords: performance, GC | Difficulty: Unknown Testcase: yes | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Comment (by simonmar): I'm guessing Java -server, and Scala, which also uses Java -server, uses quite aggressive heap settings, using more memory (they both use over 500M). Whereas we opt for more a conservative policy by default, to use less memory. You could probably argue that `-server` is a GC setting :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 5 05:46:45 2009 From: trac at galois.com (GHC) Date: Thu Mar 5 05:35:23 2009 Subject: [GHC] #3073: Avoid reconstructing dictionaries in recursive instance methods Message-ID: <046.cb32dbba432b9228a1ce1c087df10ff6@localhost> #3073: Avoid reconstructing dictionaries in recursive instance methods ---------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ---------------------------------------+------------------------------------ Ganesh writes: I have a problem in GHC 6.10 with functions in a class instance calling other functions in the same class instance. It seems that the dictionary is freshly constructed for this call, despite being already available. The reason I care is that I want to memoise some expensive computations inside the dictionary for each instance. [Obviously I also have to make sure that the dictionary isn't constructed multiple times by external callers, but I can make other arrangements to ensure that.] To see the problem in action, run main from the attached code. In GHC 6.8 and before, this only executes the trace statement once. In GHC 6.10, the trace statement executes twice, at all optimisation levels. This seems related to #2902, but I'm a little unclear on whether it's the same problem or not. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 5 05:54:49 2009 From: trac at galois.com (GHC) Date: Thu Mar 5 05:43:25 2009 Subject: [GHC] #3074: Template Haskell does not support type families. Message-ID: <054.532c25252b9d3cc0cd067701cce4d187@localhost> #3074: Template Haskell does not support type families. --------------------------------------------+------------------------------- Reporter: Serguey Zefirov | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: minor Keywords: template haskell, type families | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple --------------------------------------------+------------------------------- {{{ {-# LANGUAGE TemplateHaskell, TypeFamilies #-} import Language.Haskell.TH type family A a $((\x -> x >>= (runIO . (print . ppr)) >> return []) $ [d|type instance A (Maybe Int) = Int|]) }}} GHCi load result: {{{ [1 of 1] Compiling Main ( a.hs, interpreted ) type A = GHC.Types.Int Ok, modules loaded: Main. }}} TySynD has list of Names as an argument list whereas type families header should have a list of Types. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 5 06:00:16 2009 From: trac at galois.com (GHC) Date: Thu Mar 5 05:48:54 2009 Subject: [GHC] #3041: Arch independent binary representations In-Reply-To: <046.ec9add4015adc692796a9426b46aeec0@localhost> References: <046.ec9add4015adc692796a9426b46aeec0@localhost> Message-ID: <055.e238f588b35a571b1f4a3d026f1d4059@localhost> #3041: Arch independent binary representations ---------------------------------+------------------------------------------ Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): Replying to [comment:7 igloo]: > Is there a reason for GHC not to use `Data.Binary` too? The only reason I can think of would be to avoid the extra dependency, but if haddock uses it then the GHC build depends on it anyway. Personally, I don't think it's a strong enough reason to maintain our own Binary anyway. I've been lead to believe that the performance of `Data.Binary` isn't as good as our `Binary` library. I don't have figures to back that up, but performance of reading interface files is pretty important to us. So I've been holding off on switching until `Data.Binary` has had some tuning. > So if GHC switches to `Data.Binary`, then all haddock needs to do is wait. Haddock just needs a binary serialisation library, there's no reason it has to use the same one as GHC. And even if GHC switched, Haddock would have to be updated to use `Data.Binary` too. > In the mean time (i.e. for 6.10.2), we can fix the immediate problem by changing the `Int` instance to to serialise as `Int32` or `Int64` consistently. I think that's a bad idea. If we use `Int64` then interface files get bigger on 32-bit machines; if we use `Int32` then we introduce new failure modes. We could use some hybrid encoding I suppose, but I'd rather Haddock was just decoupled from GHC's binary library altogether. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 5 07:01:56 2009 From: trac at galois.com (GHC) Date: Thu Mar 5 06:51:24 2009 Subject: [GHC] #1876: Complete shared library support In-Reply-To: <047.2ab772cd4150dcd51ba47e309570e649@localhost> References: <047.2ab772cd4150dcd51ba47e309570e649@localhost> Message-ID: <056.6d45df59d4e58d08f98afd1170294ff5@localhost> #1876: Complete shared library support ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: task | Status: new Priority: high | Milestone: 6.10 branch Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Difficult (1 week) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): see also #3072 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 5 07:43:51 2009 From: trac at galois.com (GHC) Date: Thu Mar 5 07:32:26 2009 Subject: [GHC] #3041: Arch independent binary representations In-Reply-To: <046.ec9add4015adc692796a9426b46aeec0@localhost> References: <046.ec9add4015adc692796a9426b46aeec0@localhost> Message-ID: <055.914df771bb6da7410b4378f3df4e000c@localhost> #3041: Arch independent binary representations ---------------------------------+------------------------------------------ Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by duncan): Replying to [comment:9 simonmar]: > Replying to [comment:7 igloo]: > > > Is there a reason for GHC not to use `Data.Binary` too? The only reason I can think of would be to avoid the extra dependency, but if haddock uses it then the GHC build depends on it anyway. Personally, I don't think it's a strong enough reason to maintain our own Binary anyway. > > I've been lead to believe that the performance of `Data.Binary` isn't as good as our `Binary` library. I don't have figures to back that up, but performance of reading interface files is pretty important to us. So I've been holding off on switching until `Data.Binary` has had some tuning. There was a regression in the performance of `Data.Binary` from ghc-6.8 to 6.10 which is perhaps what you're thinking of. Prior to that it was several times faster (10x at the time of the binary-0.4 release) than `NewBinary` which I believe was basically ghc's binary implementation extracted into a standalone library. Don looked at the performance regression so is best placed to say if the latest release brings performance back up to what it was with 6.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 5 08:13:33 2009 From: trac at galois.com (GHC) Date: Thu Mar 5 08:02:08 2009 Subject: [GHC] #3041: Arch independent binary representations In-Reply-To: <046.ec9add4015adc692796a9426b46aeec0@localhost> References: <046.ec9add4015adc692796a9426b46aeec0@localhost> Message-ID: <055.7562f2c11e9150383d89c5744a344b14@localhost> #3041: Arch independent binary representations ---------------------------------+------------------------------------------ Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): Replying to [comment:10 duncan]: > Replying to [comment:9 simonmar]: > > I've been lead to believe that the performance of `Data.Binary` isn't as good as our `Binary` library. I don't have figures to back that up, but performance of reading interface files is pretty important to us. So I've been holding off on switching until `Data.Binary` has had some tuning. > > There was a regression in the performance of `Data.Binary` from ghc-6.8 to 6.10 which is perhaps what you're thinking of. Prior to that it was several times faster (10x at the time of the binary-0.4 release) than `NewBinary` which I believe was basically ghc's binary implementation extracted into a standalone library. Don looked at the performance regression so is best placed to say if the latest release brings performance back up to what it was with 6.8. `NewBinary` is somewhat slower than GHC's binary library, IIRC, because it added support for using a more compact serialisation format based on bits rather than bytes. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 5 08:43:32 2009 From: trac at galois.com (GHC) Date: Thu Mar 5 08:32:08 2009 Subject: [GHC] #3069: misspelled word in description of syntax extensions: s/enerated/enumerated/ In-Reply-To: <041.1485ad2be6ed6a3458a5a548738e6d17@localhost> References: <041.1485ad2be6ed6a3458a5a548738e6d17@localhost> Message-ID: <050.e05960832addefd15e509dc46ad48f91@localhost> #3069: misspelled word in description of syntax extensions: s/enerated/enumerated/ ---------------------------------+------------------------------------------ Reporter: nr | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 6.11 Severity: trivial | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 5 08:45:06 2009 From: trac at galois.com (GHC) Date: Thu Mar 5 08:33:41 2009 Subject: [GHC] #3068: broken link in http://www.haskell.org/ghc/docs/latest/html/users_guide/special-ids.html In-Reply-To: <041.a6c5744a059da97d330e77774471e867@localhost> References: <041.a6c5744a059da97d330e77774471e867@localhost> Message-ID: <050.1d655cc5534ff6b89b28e2c7379bba67@localhost> #3068: broken link in http://www.haskell.org/ghc/docs/latest/html/users_guide /special-ids.html ---------------------------------+------------------------------------------ Reporter: nr | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 6.11 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed in HEAD and 6.10. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 5 08:47:13 2009 From: trac at galois.com (GHC) Date: Thu Mar 5 08:35:47 2009 Subject: [GHC] #3066: Crash with bogus FFI declaration In-Reply-To: <046.a0d023407aaea2d72ef0e4c64d1c0cea@localhost> References: <046.a0d023407aaea2d72ef0e4c64d1c0cea@localhost> Message-ID: <055.df786170935d6543748db79d2a996e82@localhost> #3066: Crash with bogus FFI declaration --------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: closed Priority: high | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: ffi/should_fail/T3066 | Os: Unknown/Multiple Architecture: Unknown/Multiple | --------------------------------------+------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Both merged, as well as {{{ Thu Mar 5 01:09:35 PST 2009 simonpj@microsoft.com * Finally fix Trac #3066 Ignore-this: 8734c1799f854d9da6be76a9c134335e This is a fix to Tue Mar 3 17:42:58 GMT 2009 simonpj@microsoft.com * Fix Trac #3066: checking argument types in foreign calls which I embarassingly got wrong. Have to be careful when expanding recursive newtypes. Pls merge. }}} Oh, the perils of putting "The fix is easy." in a commit message! :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 5 09:00:34 2009 From: trac at galois.com (GHC) Date: Thu Mar 5 08:49:18 2009 Subject: [GHC] #1074: -fwarn-unused-imports complains about wrong import In-Reply-To: <044.4c9395b3e6188ac7c118df9e58cf802d@localhost> References: <044.4c9395b3e6188ac7c118df9e58cf802d@localhost> Message-ID: <053.99933124afa56d44c5206408745139cf@localhost> #1074: -fwarn-unused-imports complains about wrong import ---------------------------------+------------------------------------------ Reporter: guest | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.6 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * priority: high => normal -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 5 09:04:29 2009 From: trac at galois.com (GHC) Date: Thu Mar 5 08:53:03 2009 Subject: [GHC] #3059: 3 different behaviours depending on profiling settings and on a used-only-once form being top-level In-Reply-To: <043.65beacb4ac206762f56576480f564413@localhost> References: <043.65beacb4ac206762f56576480f564413@localhost> Message-ID: <052.58faef4e6475a207a4e45a956dd68b0f@localhost> #3059: 3 different behaviours depending on profiling settings and on a used-only- once form being top-level -------------------------+-------------------------------------------------- Reporter: jkff | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by simonmar): * difficulty: => Unknown Comment: I'm not completely following all the various versions of things here. Could one of you attach a small example that illustrates the bad behaviour? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 5 09:04:48 2009 From: trac at galois.com (GHC) Date: Thu Mar 5 08:53:22 2009 Subject: [GHC] #3025: Possible PiDigits memory explosion regression In-Reply-To: <045.83a907a9b608fda1ad14968d66d95fe2@localhost> References: <045.83a907a9b608fda1ad14968d66d95fe2@localhost> Message-ID: <054.abca7ec7bca302790ce1198a1fed82f1@localhost> #3025: Possible PiDigits memory explosion regression ---------------------------------+------------------------------------------ Reporter: japple | Owner: igloo Type: bug | Status: closed Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Looks fixed in the 6.10 branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 5 10:23:34 2009 From: trac at galois.com (GHC) Date: Thu Mar 5 10:12:46 2009 Subject: [GHC] #3004: Makefile needs to improve treatment of HsColour In-Reply-To: <041.599d5d545611d75bbe675a894a5ae12b@localhost> References: <041.599d5d545611d75bbe675a894a5ae12b@localhost> Message-ID: <050.a61e770aa4d92850f30325d8137844e9@localhost> #3004: Makefile needs to improve treatment of HsColour ---------------------------------+------------------------------------------ Reporter: nr | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 6.11 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: OK, HsColour should now be required by the buildbots, and when validating, but not for normal builds: {{{ Thu Mar 5 13:27:23 GMT 2009 Ian Lynagh * By default, only HsColour the docs if we find HsColour. Fixes trac #3004. If you manually set HSCOLOUR_SRCS=YES then the build will fail if HsColour wasn't found. }}} (in HEAD and 6.10) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 5 10:24:51 2009 From: trac at galois.com (GHC) Date: Thu Mar 5 10:13:25 2009 Subject: [GHC] #3031: -fwarn-unrecognised-pragmas is not documented In-Reply-To: <047.a1fe7ee61556353e5838fab50b24eb4f@localhost> References: <047.a1fe7ee61556353e5838fab50b24eb4f@localhost> Message-ID: <056.d3d30695e743aa8d8c69128c34e2d0bb@localhost> #3031: -fwarn-unrecognised-pragmas is not documented ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: igloo Type: bug | Status: closed Priority: high | Milestone: 6.10.2 Component: Documentation | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Easy (1 hr) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Now documented in HEAD and 6.10: {{{ Thu Mar 5 06:31:28 PST 2009 Ian Lynagh * Document -fwarn-unrecognised-pragmas; fixes trac #3031 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 5 10:26:32 2009 From: trac at galois.com (GHC) Date: Thu Mar 5 10:15:06 2009 Subject: [GHC] #2983: Segmentation fault in ray tracer with certain options In-Reply-To: <052.ab008e7a26a83a06094f6364ea685223@localhost> References: <052.ab008e7a26a83a06094f6364ea685223@localhost> Message-ID: <061.66cb0d8fa5c31714d4005718b1795d39@localhost> #2983: Segmentation fault in ray tracer with certain options --------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: igloo Type: bug | Status: closed Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: seg fault, ray tracer | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | --------------------------------------+------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: As Simon M pointed out, the #2917 fix won't fix this after all. I've now made gcc not generate SSE instructions in both HEAD and 6.10, which fixes the bug: {{{ Thu Mar 5 14:20:50 GMT 2009 Ian Lynagh * On OS X/x86, tell gcc to generate instructions for i686. Fixes trac #2983. By default, gcc on OS X will generate SSE instructions, which need things 16-byte aligned, but we don't 16-byte align things. Thus drop back to generic i686 compatibility. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 5 10:27:42 2009 From: trac at galois.com (GHC) Date: Thu Mar 5 10:16:23 2009 Subject: [GHC] #2615: ghci doesn't play nice with linker scripts In-Reply-To: <051.bfa2cefd2ab537021a429fbc1fccdb5e@localhost> References: <051.bfa2cefd2ab537021a429fbc1fccdb5e@localhost> Message-ID: <060.e0ae3c8f805636c79c070765416d033a@localhost> #2615: ghci doesn't play nice with linker scripts ---------------------------------+------------------------------------------ Reporter: AlecBerryman | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * owner: igloo => -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 5 10:46:01 2009 From: trac at galois.com (GHC) Date: Thu Mar 5 10:34:34 2009 Subject: [GHC] #2670: Record selectors behaving badly wrt optimisation In-Reply-To: <047.05629016d0e3be252c46b232dd152edc@localhost> References: <047.05629016d0e3be252c46b232dd152edc@localhost> Message-ID: <056.ca0ce157206f0600a59355dde4d77199@localhost> #2670: Record selectors behaving badly wrt optimisation ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: We decided that a test is too hard, so closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 5 12:14:56 2009 From: trac at galois.com (GHC) Date: Thu Mar 5 12:03:30 2009 Subject: [GHC] #2757: runghc doesn't respond to --help / --version In-Reply-To: <047.8ea527abd27e35ccd572a6a7f32be73f@localhost> References: <047.8ea527abd27e35ccd572a6a7f32be73f@localhost> Message-ID: <056.283ba8796108e7c2a3425d302b8e6d9d@localhost> #2757: runghc doesn't respond to --help / --version ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Easy (1 hr) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: reopened => closed * resolution: => fixed Comment: Fixed in HEAD and 6.10: {{{ Thu Mar 5 16:20:45 GMT 2009 Ian Lynagh * Add --version to runghc. Trac #2757. We use the GHC version number, as the old runghc one doesn't seem very useful. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 5 23:45:15 2009 From: trac at galois.com (GHC) Date: Thu Mar 5 23:33:48 2009 Subject: [GHC] #3075: validation requires a tool that is not included in utils Message-ID: <041.78af24730978f9a81c62b2ad028cec21@localhost> #3075: validation requires a tool that is not included in utils -------------------+-------------------------------------------------------- Reporter: nr | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.11 | Severity: major Keywords: | Testcase: Os: Linux | Architecture: x86 -------------------+-------------------------------------------------------- At present it is not possible to validate without HsColour, but HsColour is not included in utils. To make matters worse, HsColour is not available through Debian, and even cabal, which could be used to install HsColour, is not available through Debian. To require me to install Cabal to install HsColour to validate changes made to GHC's back end is at least one too many levels of indirection. (I routinely build GHC on three different computers, and a fourth is not unheard of, so if the installation isn't easily supported by my existing Linux distros, I want no part of it.) I'd like the validate/build process changed to reach one of two outcomes: 1. It becomes permissible to validate without HsColour, and this happens by default and automatically on systems where HsColour is not present. 1. HsColour is included in utils, and the validate script automatically finds it there and builds it at need. P.S. I am quite grateful for the earlier work that enables me to build the compiler without HsColour. But I also want to be able to contribute changes. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 6 04:42:52 2009 From: trac at galois.com (GHC) Date: Fri Mar 6 04:31:26 2009 Subject: [GHC] #2189: hSetBuffering stdin NoBuffering doesn't work on Windows In-Reply-To: <047.b31f95b84e60784da45a33105d44ed84@localhost> References: <047.b31f95b84e60784da45a33105d44ed84@localhost> Message-ID: <056.de0efa7cd8d29e994d61a27f9f7639ef@localhost> #2189: hSetBuffering stdin NoBuffering doesn't work on Windows -----------------------------------------------+---------------------------- Reporter: FalconNL | Owner: igloo Type: merge | Status: new Priority: high | Milestone: 6.10.2 Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: Keywords: hsetbuffering buffering buffer | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -----------------------------------------------+---------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: Patch applied: {{{ Thu Mar 5 03:33:23 PST 2009 Simon Marlow * FIX #2189: re-enabled cooked mode for Console-connected Handles on Windows }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 6 07:01:45 2009 From: trac at galois.com (GHC) Date: Fri Mar 6 06:50:23 2009 Subject: [GHC] #3076: Make genericLength tail-recursive so it doesn't overflow stack Message-ID: <047.09c3cc32fe230c7b5b0bb571eadca7cb@localhost> #3076: Make genericLength tail-recursive so it doesn't overflow stack -------------------------------------+-------------------------------------- Reporter: Syzygies | Owner: Type: run-time performance bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------------+-------------------------------------- A likely use for genericLength is to count lists of more than Int elements. However, the source code is not tail-recursive, making a poor "consumer", so genericLength easily overflows stack. Here is the source code from 6.10.1: {{{ genericLength :: (Num i) => [b] -> i genericLength [] = 0 genericLength (_:l) = 1 + genericLength l }}} Here is a proposed alternative: {{{ genericLength ? (Num i) ? [b] ? i genericLength = len 0 where len n [] = n len n (_:xt) = len (n+1) xt }}} In my test application (enumerating the 66,960,965,307 atomic lattices on six atoms) this alternative avoids overflowing the stack. [This is not the same issue as http://hackage.haskell.org/trac/ghc/ticket/2962] -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 6 09:51:57 2009 From: trac at galois.com (GHC) Date: Fri Mar 6 09:40:35 2009 Subject: [GHC] #3076: Make genericLength tail-recursive so it doesn't overflow stack In-Reply-To: <047.09c3cc32fe230c7b5b0bb571eadca7cb@localhost> References: <047.09c3cc32fe230c7b5b0bb571eadca7cb@localhost> Message-ID: <056.4761c171bccce9b302e047fc0f7d9b63@localhost> #3076: Make genericLength tail-recursive so it doesn't overflow stack -----------------------------------------+---------------------------------- Reporter: Syzygies | Owner: Type: run-time performance bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: That isn't an equivalent definition, e.g.: {{{ data Nat = Zero | Succ Nat deriving (Show, Eq) works :: Bool works = genericLength1 (cycle "foo") > (5 :: Nat) fails :: Bool fails = genericLength2 (cycle "foo") > (5 :: Nat) instance Num Nat where fromInteger 0 = Zero fromInteger (n + 1) = Succ (fromInteger n) Zero + n = n Succ m + n = Succ (m + n) instance Ord Nat where compare Zero Zero = EQ compare Zero _ = LT compare _ Zero = GT compare (Succ m) (Succ n) = compare m n genericLength1 :: (Num i) => [b] -> i genericLength1 [] = 0 genericLength1 (_:l) = 1 + genericLength1 l genericLength2 :: (Num i) => [b] -> i genericLength2 = len 0 where len n [] = n len n (_:xt) = len (n+1) xt }}} `works` works, but `fails` doesn't terminate: {{{ *Main> works True *Main> fails ^CInterrupted. }}} If you restrict the type to `Int` or `Integer`, then it will work thanks to #2962, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 6 14:12:49 2009 From: trac at galois.com (GHC) Date: Fri Mar 6 14:01:22 2009 Subject: [GHC] #3075: validation requires a tool that is not included in utils In-Reply-To: <041.78af24730978f9a81c62b2ad028cec21@localhost> References: <041.78af24730978f9a81c62b2ad028cec21@localhost> Message-ID: <050.2c1d4aa4289524c6dab7a1b6b9893829@localhost> #3075: validation requires a tool that is not included in utils -----------------------------+---------------------------------------------- Reporter: nr | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.11 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -----------------------------+---------------------------------------------- Changes (by igloo): * owner: => igloo * difficulty: => Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 6 16:29:00 2009 From: trac at galois.com (GHC) Date: Fri Mar 6 16:17:33 2009 Subject: [GHC] #3077: 'make' fails in utils (6.11) Message-ID: <041.aaa82bb4ec2c0a818ded70efdaec6b99@localhost> #3077: 'make' fails in utils (6.11) -------------------+-------------------------------------------------------- Reporter: nr | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.11 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86 -------------------+-------------------------------------------------------- In order to get 'make boot' to work in compiler, I tried running 'make' in utils. Something's off with configuration it appears. I'm attaching full output. Sorry to keep submitting these things with no patches. I don't have a strong enough picture of what's ''supposed'' to happen during build to be confident of making things better not worse. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 6 17:23:29 2009 From: trac at galois.com (GHC) Date: Fri Mar 6 17:12:05 2009 Subject: [GHC] #2189: hSetBuffering stdin NoBuffering doesn't work on Windows In-Reply-To: <047.b31f95b84e60784da45a33105d44ed84@localhost> References: <047.b31f95b84e60784da45a33105d44ed84@localhost> Message-ID: <056.b96c9734cfb079fb4b32a86aab2458a9@localhost> #2189: hSetBuffering stdin NoBuffering doesn't work on Windows -----------------------------------------------+---------------------------- Reporter: FalconNL | Owner: igloo Type: merge | Status: closed Priority: high | Milestone: 6.10.2 Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: hsetbuffering buffering buffer | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -----------------------------------------------+---------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 6 23:11:06 2009 From: trac at galois.com (GHC) Date: Fri Mar 6 22:59:35 2009 Subject: [GHC] #3078: Erroneous warnings for -XPatternGuards Message-ID: <044.c8833b905baf8d82852a2d8c84929df0@localhost> #3078: Erroneous warnings for -XPatternGuards -------------------+-------------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86_64 (amd64) -------------------+-------------------------------------------------------- As nonstandard PatternGuards I get a meaningless warning: {{{ walltest.hs:8:10: Warning: Pattern match(es) are non-exhaustive In the definition of `n': Patterns not matched: Ok, modules loaded: Main. }}} {{{ {-# LANGUAGE PatternGuards #-} {-# OPTIONS -Wall #-} data T = A Int | B Int funny :: T -> Int funny t = n where n | A x <- t = x | B x <- t = x }}} But none of that happens when using a case expression for the same thing: {{{ {-# OPTIONS -Wall #-} data T = A Int | B Int funny :: T -> Int funny t = n where n = case t of (A x) -> x (B x) -> x }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Mar 7 07:05:20 2009 From: trac at galois.com (GHC) Date: Sat Mar 7 06:53:49 2009 Subject: [GHC] #3079: LANGUAGE pragma fails if preceded by too many comments Message-ID: <047.db20015538347ea9ecfd34557e791f17@localhost> #3079: LANGUAGE pragma fails if preceded by too many comments -----------------------------+---------------------------------------------- Reporter: Deewiant | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Parser) Version: 6.10.1 | Severity: critical Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Putting too much whitespace and/or comment text before a LANGUAGE pragma seems to cause parsing it to fail. In the following, the closing `}` of the comment is byte 1025. Perhaps the whole thing is expected to fit into the first 1024 bytes or be wholly inside an aligned 1024-byte range? {{{ -- xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx -- xxxxxxxxxxxxxxxxxxxxxxxx -- xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx -- xxxxxxxxxxxxxxxxxxxxxxx -- xxxxxxxxxxxxxxxxxxxxxxxxxxxxx -- --xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx --xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx -- --xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx --xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx --xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx --xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx --xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx --xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx --xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx --xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx -- --xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx {-# LANGUAGE ScopedTypeVariables #-} main = return () }}} Removing absolutely anything prior to the start of the LANGUAGE pragma will make it work: one of the exes, an entire line, any whitespace, whatever. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Mar 7 07:47:14 2009 From: trac at galois.com (GHC) Date: Sat Mar 7 07:35:42 2009 Subject: [GHC] #3079: LANGUAGE pragma fails if it falls on a 1024-byte boundary In-Reply-To: <047.db20015538347ea9ecfd34557e791f17@localhost> References: <047.db20015538347ea9ecfd34557e791f17@localhost> Message-ID: <056.7fa503efbfc765d55a786ffd133c6636@localhost> #3079: LANGUAGE pragma fails if it falls on a 1024-byte boundary -------------------------------+-------------------------------------------- Reporter: Deewiant | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 6.10.1 Severity: critical | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- Changes (by Deewiant): * summary: LANGUAGE pragma fails if preceded by too many comments => LANGUAGE pragma fails if it falls on a 1024-byte boundary Comment: I tried adding more comments before it and that also made it work. Adding still more breaks it again as soon as the 2048th byte is among the contents of the `{-# #-}`, so this is indeed an alignment issue. The error message which I managed to forget putting into the report: {{{ arst.hs:21:13: cannot parse LANGUAGE pragma: comma-separated list expected }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Mar 7 12:36:53 2009 From: trac at galois.com (GHC) Date: Sat Mar 7 12:25:20 2009 Subject: [GHC] #3079: LANGUAGE pragma fails if it falls on a 1024-byte boundary In-Reply-To: <047.db20015538347ea9ecfd34557e791f17@localhost> References: <047.db20015538347ea9ecfd34557e791f17@localhost> Message-ID: <056.e48d0039c47f98e0c6cd83588cf70d4a@localhost> #3079: LANGUAGE pragma fails if it falls on a 1024-byte boundary -------------------------------+-------------------------------------------- Reporter: Deewiant | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 6.10.1 Severity: critical | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- Comment (by Deewiant): The culprit is `getOptions'` in `compiler/main/HeaderInfo.hs`. The function has a mechanism of indicating that it wants more input but it isn't doing it properly in this case. I'm not familiar enough with the system to be able to fix it, but it seems to me that modifying the definition of `parseLanguage` (in the `where` clause) somehow should suffice. Note that the same function parses `OPTION` pragmas, which do work correctly even if they fall on a 1024-byte boundary. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Mar 7 12:51:51 2009 From: trac at galois.com (GHC) Date: Sat Mar 7 12:40:23 2009 Subject: [GHC] #3076: Make genericLength tail-recursive so it doesn't overflow stack In-Reply-To: <047.09c3cc32fe230c7b5b0bb571eadca7cb@localhost> References: <047.09c3cc32fe230c7b5b0bb571eadca7cb@localhost> Message-ID: <056.ea2863da3092f8f4949afd60d89bae13@localhost> #3076: Make genericLength tail-recursive so it doesn't overflow stack -----------------------------------------+---------------------------------- Reporter: Syzygies | Owner: Type: run-time performance bug | Status: reopened Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: genericLength | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Changes (by Syzygies): * keywords: => genericLength * status: closed => reopened * resolution: invalid => Comment: That was enlightening. Thanks. The library genericLength blows stack on very short lists. My first proposal fails on infinite lists, using Peano arithmetic. So they both fail reasonable tests. However, one can make a logarithmic improvement in the stack usage of the library function, and pass both tests: {{{ module Main where import Data.Int data Nat = Zero | Succ Nat deriving (Show, Eq) instance Num Nat where fromInteger 0 = Zero fromInteger n = Succ $ fromInteger $ n - 1 Zero + n = n Succ m + n = Succ (m + n) Zero * _ = Zero Succ m * n = n + m * n abs n = n signum Zero = Zero signum (Succ _) = Succ Zero instance Ord Nat where compare Zero Zero = EQ compare Zero _ = LT compare _ Zero = GT compare (Succ m) (Succ n) = compare m n genericLength1 ? (Num i) ? [b] ? i genericLength1 [] = 0 genericLength1 (_:l) = 1 + genericLength1 l genericLength2 ? (Num i) ? [b] ? i genericLength2 = len 0 where len n [] = n len n (_:xt) = len (n+1) xt genericLength3 ? (Num i) ? [b] ? i genericLength3 = len 1 0 where len _ n [] = n len m n (_:xt) | m == n = n + len (n+n) 1 xt | otherwise = len m (n+1) xt intLength1, intLength2, intLength3 ? [a] ? Int64 intLength1 = genericLength1 intLength2 = genericLength2 intLength3 = genericLength3 natLength1, natLength2, natLength3 ? [a] ? Nat natLength1 = genericLength1 natLength2 = genericLength2 natLength3 = genericLength3 list :: Int64 -> [Bool] list 0 = [] list n = True : list (n-1) main ? IO () main = do -- print $ intLength1 $ list $ 2^19 -- fails w/ 8388608 byte stack print $ intLength2 $ list $ 2^32 print $ intLength3 $ list $ 2^32 print $ natLength1 (repeat 1) > 5 -- print $ natLength2 (repeat 1) > 5 -- fails print $ natLength3 (repeat 1) > 5 }}} Getting this to work requires specializing genericLength, to avoid class overhead. This is nevertheless preferable to writing a length function from scratch, which might fall into either of these traps. Getting this to work also requires a "good producer". I was surprised to discover that in this context, [1..n] isn't a "good producer". -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Mar 7 12:53:08 2009 From: trac at galois.com (GHC) Date: Sat Mar 7 12:41:35 2009 Subject: [GHC] #3061: GHC's GC default heap growth strategy is not as good as other runtimes In-Reply-To: <043.619b1558281745ecd214227681115d78@localhost> References: <043.619b1558281745ecd214227681115d78@localhost> Message-ID: <052.8346ed738ecaa6c95b1d77a7a97a524d@localhost> #3061: GHC's GC default heap growth strategy is not as good as other runtimes -----------------------------------------+---------------------------------- Reporter: dons | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: Keywords: performance, GC | Difficulty: Unknown Testcase: yes | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Comment (by dons): BTW, here's the ruling for the shootout: http://alioth.debian.org/tracker/index.php?func=detail&aid=311528&group_id=30402&atid=411005 {{{ "For many language implementations the binary-trees programs are all about GC and GC work can be evaded by setting a larger initial heap, hinting that the heap will be in some size range, controlling when GC happens etc We've taken an arbitrary approach - just default settings for all language implementations. Maybe there's a better (rather than different arbitrary) approach? Nothing persuasive has been suggested yet." }}} I'm out of ideas for making binary-trees parallelise better then :) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Mar 7 19:32:46 2009 From: trac at galois.com (GHC) Date: Sat Mar 7 19:21:51 2009 Subject: [GHC] #1968: data family + GADT: not implemented yet In-Reply-To: <043.23a4d08c9eaa4d1c4c93b9abe9a12e10@localhost> References: <043.23a4d08c9eaa4d1c4c93b9abe9a12e10@localhost> Message-ID: <052.b970c2bcbc942492677945a4e471b0d2@localhost> #1968: data family + GADT: not implemented yet ---------------------------------------------------+------------------------ Reporter: Remi | Owner: chak Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: fixed Keywords: data type family GADT choose_univs | Difficulty: Moderate (1 day) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------------------------+------------------------ Comment (by jeltsch): Will this bug be fixed in GHC?6.10.2? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 8 13:10:32 2009 From: trac at galois.com (GHC) Date: Sun Mar 8 12:59:38 2009 Subject: [GHC] #1968: data family + GADT: not implemented yet In-Reply-To: <043.23a4d08c9eaa4d1c4c93b9abe9a12e10@localhost> References: <043.23a4d08c9eaa4d1c4c93b9abe9a12e10@localhost> Message-ID: <052.7de8a54c27035a482e639b275676f769@localhost> #1968: data family + GADT: not implemented yet ---------------------------------------------------+------------------------ Reporter: Remi | Owner: chak Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: fixed Keywords: data type family GADT choose_univs | Difficulty: Moderate (1 day) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------------------------+------------------------ Comment (by igloo): The example in the original report works in the HEAD, but not the 6.10 branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 8 14:53:45 2009 From: trac at galois.com (GHC) Date: Sun Mar 8 14:42:12 2009 Subject: [GHC] #3075: validation requires a tool that is not included in utils In-Reply-To: <041.78af24730978f9a81c62b2ad028cec21@localhost> References: <041.78af24730978f9a81c62b2ad028cec21@localhost> Message-ID: <050.8a269e9662834904075843f3400ee49e@localhost> #3075: validation requires a tool that is not included in utils -----------------------------+---------------------------------------------- Reporter: nr | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 6.11 Severity: major | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -----------------------------+---------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: OK, I've stopped validate requiring HsColour too, in HEAD and the 6.10 branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 8 19:09:21 2009 From: trac at galois.com (GHC) Date: Sun Mar 8 18:57:46 2009 Subject: [GHC] #3080: Show more instances with :info Message-ID: <044.6dbc83806a42f26420040b9e0eccdfe5@localhost> #3080: Show more instances with :info -----------------------------+---------------------------------------------- Reporter: josef | Owner: Type: feature request | Status: new Priority: normal | Component: GHCi Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Today I was really stumped by the rule used to select which instances are shown with the :info command. I did the following: {{{ newtype Control.Monad.Writer.Lazy.Writer w a = Control.Monad.Writer.Lazy.Writer {Control.Monad.Writer.Lazy.runWriter :: (a, w)} -- Defined in Control.Monad.Writer.Lazy instance Functor (Control.Monad.Writer.Lazy.Writer w) -- Defined in Control.Monad.Writer.Lazy }}} I was really surprised not to see a Monad instance which, after all, is the raison d'entre of the Writer type. After some investigation I found out that this behavior is a combination of ghci's rule not to show instances which involves stuff not in scope and the fact that Monoid wasn't in scope. Now, personally I tend to want to see everything when I use the :info command so my preference would be to see all instances. But I realize that you came up with the current rule for a reason and so here are some alternative ways how to please me. The first one is to have some kind of flag to give to :info so that it shows all instances. One might of course make it so that a flag is needed to suppress extraneous instances and get the current behavior. That would actually be my personal preference. Another way, which I'm not sure I like but would at least help in the example above, is to note that the type I'm asking about is not in scope in the first place. So I'm not interested in 'in scope stuff' at all and so showing me all instances, even those including things not in scope, isn't very likely to confuse me. This rule would have the rather confusing effect of potentially showing less information about stuff that is in scope compared to things that are not in scope. But despite this confusing consequence I find the rule very sensible, so I'm in two minds about it. Anyway, having some way to see all instances would be nice. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 8 22:07:36 2009 From: trac at galois.com (GHC) Date: Sun Mar 8 21:56:13 2009 Subject: [GHC] #3076: Make genericLength tail-recursive so it doesn't overflow stack In-Reply-To: <047.09c3cc32fe230c7b5b0bb571eadca7cb@localhost> References: <047.09c3cc32fe230c7b5b0bb571eadca7cb@localhost> Message-ID: <056.60b02febe8d3f36c740cfabf00d11f67@localhost> #3076: Make genericLength tail-recursive so it doesn't overflow stack -----------------------------------------+---------------------------------- Reporter: Syzygies | Owner: Type: run-time performance bug | Status: reopened Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: genericLength | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Comment (by Syzygies): I ran a timing test, to compare intLengthN for N=1,2,3 on an example that N=1 (the existing library code) could handle: {{{ print $ sum $ map intLength1 $ take 1000 $ iterate tail $ list $ 2^18 }}} intLength3 runs slower (of course) than the invalid intLength2, but 5.5x faster than the current library code intlength1. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 9 04:59:18 2009 From: trac at galois.com (GHC) Date: Mon Mar 9 04:47:40 2009 Subject: [GHC] #2954: System.Process.terminateProcess sends SIGTERM rather than SIGKILL on unix In-Reply-To: <044.33b296bee16ac04eb53e73148864ea5b@localhost> References: <044.33b296bee16ac04eb53e73148864ea5b@localhost> Message-ID: <053.a073193116c9db59e806848aebda854e@localhost> #2954: System.Process.terminateProcess sends SIGTERM rather than SIGKILL on unix ----------------------------------+----------------------------------------- Reporter: guest | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.2 Component: libraries/process | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: Docs fixed: {{{ Thu Mar 5 06:57:45 PST 2009 Simon Marlow * fix documentation for termianteProcess (#2954) }}} Ian, please merge then change to a feature-request for 6.12. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 9 05:02:10 2009 From: trac at galois.com (GHC) Date: Mon Mar 9 04:50:42 2009 Subject: [GHC] #2917: alloca and allocaArray do not respect alignment In-Reply-To: <044.ae4012da6404813e981e2064d26c5c85@localhost> References: <044.ae4012da6404813e981e2064d26c5c85@localhost> Message-ID: <053.6ef471e118e7d431360e71da6cb386b0@localhost> #2917: alloca and allocaArray do not respect alignment ---------------------------------+------------------------------------------ Reporter: guest | Owner: igloo Type: merge | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler (FFI) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: `alloca` now aligns correctly according to the `Storable` instance, and `allocaBytes` now aligns to 16 bytes. `malloc` and `mallocBytes` haven't changed (yet). Perhaps we should use `posix_memalign` where possible. Ian: please merge then bump to 6.12. {{{ Thu Mar 5 07:41:53 PST 2009 Simon Marlow * Partial fix for #2917 Ignore-this: 3a06cd3ea09f1d6454d52031802a93fd - add newAlignedPinnedByteArray# for allocating pinned BAs with arbitrary alignment - the old newPinnedByteArray# now aligns to 16 bytes Foreign.alloca will use newAlignedPinnedByteArray#, and so might end up wasting less space than before (we used to align to 8 by default). Foreign.allocaBytes and Foreign.mallocForeignPtrBytes will get 16-byte aligned memory, which is enough to avoid problems with SSE instructions on x86, for example. There was a bug in the old newPinnedByteArray#: it aligned to 8 bytes, but would have failed if the header was not a multiple of 8 (fortunately it always was, even with profiling). Also we occasionally wasted some space unnecessarily due to alignment in allocatePinned(). I haven't done anything about Foreign.malloc/mallocBytes, which will give you the same alignment guarantees as malloc() (8 bytes on Linux/x86 here). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 9 05:52:21 2009 From: trac at galois.com (GHC) Date: Mon Mar 9 05:40:43 2009 Subject: [GHC] #3081: Finally run twice on Ctrl+C Message-ID: <051.84cd0947da97d4cf55fa6f13b11c0732@localhost> #3081: Finally run twice on Ctrl+C -------------------------+-------------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Windows | Architecture: x86 -------------------------+-------------------------------------------------- {{{ C:\Temp>type Test.hs import Control.Exception import System.Cmd main = system "sleep 1m" `finally` putStrLn "goodbye" C:\Temp>ghc --version The Glorious Glasgow Haskell Compilation System, version 6.10.1 C:\Temp>ghc --make Test.hs [1 of 1] Compiling Main ( Test.hs, Test.o ) Linking Test.exe ... C:\Temp>test.exe ^Cgoodbye goodbye C:\Temp> }}} The {{{^C}}} is the consoles way of saying that Ctrl+C was pressed - i.e. I ran the program and hit Ctrl+C while the sleep was still ongoing. I can replicate this issue from the DOS prompt and from the Cygwin prompt. It does not occur from GHCi. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 9 05:54:00 2009 From: trac at galois.com (GHC) Date: Mon Mar 9 05:42:22 2009 Subject: [GHC] #3081: Finally run twice on Ctrl+C In-Reply-To: <051.84cd0947da97d4cf55fa6f13b11c0732@localhost> References: <051.84cd0947da97d4cf55fa6f13b11c0732@localhost> Message-ID: <060.e0fb89ff989f234b24ba142e8c16c6db@localhost> #3081: Finally run twice on Ctrl+C ----------------------------+----------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Windows | Architecture: x86 ----------------------------+----------------------------------------------- Comment (by NeilMitchell): Philip K.F. H?lzenspies reports that the above test works fine on Linux, giving the correct behaviour. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 9 07:19:10 2009 From: trac at galois.com (GHC) Date: Mon Mar 9 07:08:13 2009 Subject: [GHC] #1895: Allow aliases in GHCi module imports In-Reply-To: <044.6ecaa12d10d2acbb79232cbf02108989@localhost> References: <044.6ecaa12d10d2acbb79232cbf02108989@localhost> Message-ID: <053.174f1355492f8de2483fbb4ea54acc82@localhost> #1895: Allow aliases in GHCi module imports ---------------------------------+------------------------------------------ Reporter: tibbe | Owner: Type: feature request | Status: new Priority: high | Milestone: 6.10 branch Component: GHCi | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * priority: normal => high Comment: Many CCed, so making high priority -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 9 08:21:33 2009 From: trac at galois.com (GHC) Date: Mon Mar 9 08:09:56 2009 Subject: [GHC] #3081: Finally run twice on Ctrl+C In-Reply-To: <051.84cd0947da97d4cf55fa6f13b11c0732@localhost> References: <051.84cd0947da97d4cf55fa6f13b11c0732@localhost> Message-ID: <060.0918e971925a18e2e090d569ff2385d4@localhost> #3081: Finally run twice on Ctrl+C -------------------------------+-------------------------------------------- Reporter: NeilMitchell | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by simonmar): * owner: => simonmar * difficulty: => Unknown * milestone: => 6.10.2 Comment: This is slightly worrying, I'll try to look into it before 6.10.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 9 10:07:54 2009 From: trac at galois.com (GHC) Date: Mon Mar 9 09:56:17 2009 Subject: [GHC] #2934: HEAP_ALLOCED() is not thread-safe In-Reply-To: <044.6991112bf5bb5ad525a492692eb31d8d@localhost> References: <044.6991112bf5bb5ad525a492692eb31d8d@localhost> Message-ID: <053.e0c8ec259ce95e017bd6178bce511855@localhost> #2934: HEAP_ALLOCED() is not thread-safe ----------------------------------+----------------------------------------- Reporter: anish | Owner: igloo Type: merge | Status: new Priority: high | Milestone: 6.10.2 Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: Keywords: garbage collector | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86_64 (amd64) | ----------------------------------+----------------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: Fixed: {{{ Mon Mar 9 12:13:00 GMT 2009 Simon Marlow * Redesign 64-bit HEAP_ALLOCED (FIX #2934 at the same time) After much experimentation, I've found a formulation for HEAP_ALLOCED that (a) improves performance, and (b) doesn't have any race conditions when used concurrently. GC performance on x86_64 should be improved slightly. See extensive comments in MBlock.h for the details. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 9 10:28:33 2009 From: trac at galois.com (GHC) Date: Mon Mar 9 10:24:16 2009 Subject: [GHC] #1346: bootstrap from HC files In-Reply-To: <047.353746f1d61af31dcc9643e79add3cec@localhost> References: <047.353746f1d61af31dcc9643e79add3cec@localhost> Message-ID: <056.a6c7ff892f948b3b4c1d61a87c67abf5@localhost> #1346: bootstrap from HC files ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12 branch Component: Build System | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by emil): * cc: emil@math.su.se (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 9 10:38:54 2009 From: trac at galois.com (GHC) Date: Mon Mar 9 10:27:28 2009 Subject: [GHC] #2063: x86_64: RTS linker depends on working MAP_32BIT In-Reply-To: <043.15abf9ca319b437728a2421245ad0407@localhost> References: <043.15abf9ca319b437728a2421245ad0407@localhost> Message-ID: <052.582dd303731985f08c0e7727c8adac37@localhost> #2063: x86_64: RTS linker depends on working MAP_32BIT -------------------------------+-------------------------------------------- Reporter: dons | Owner: Type: task | Status: new Priority: high | Milestone: 6.10.2 Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: OpenBSD, Xen | Difficulty: Moderate (1 day) Testcase: | Os: Unknown/Multiple Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by simonmar): * priority: normal => high Comment: I believe this one is fixed. Let's make sure we get testers on Xen and OpenBSD in the release-candidate phase, so we can close it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 9 10:44:21 2009 From: trac at galois.com (GHC) Date: Mon Mar 9 10:32:43 2009 Subject: [GHC] #595: Overhaul GHC's overlapping/non-exhaustive pattern checking In-Reply-To: <047.bea78f01cbb904765ad77c751bc8d3af@localhost> References: <047.bea78f01cbb904765ad77c751bc8d3af@localhost> Message-ID: <056.eabd8d4043baf683a29b992cd5109c1e@localhost> #595: Overhaul GHC's overlapping/non-exhaustive pattern checking ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: None Severity: normal | Resolution: None Keywords: warnings | Difficulty: Difficult (1 week) Testcase: N/A | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonpj): Also look at #3078: pattern guards. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 9 10:44:34 2009 From: trac at galois.com (GHC) Date: Mon Mar 9 10:32:55 2009 Subject: [GHC] #3078: Erroneous warnings for -XPatternGuards In-Reply-To: <044.c8833b905baf8d82852a2d8c84929df0@localhost> References: <044.c8833b905baf8d82852a2d8c84929df0@localhost> Message-ID: <053.be6b92cec7d3457e7ea2c94a5f606a3b@localhost> #3078: Erroneous warnings for -XPatternGuards -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by simonpj): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: It's a very special case. For example you might have {{{ ... where n | A x <- f t = x | B x <- t = x }}} or {{{ ... where n | A x <- t, x>0 = x | B x <- t = x }}} etc. In principle a better exhaustiveness checker could catch some of these cases, and that'd be great. Good suggestion, but it's definitely not simple. I'm going to close this ticket as a kind-of duplicate, and attach it to the main exhaustiveness checking ticket, namely #595 Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 9 20:33:42 2009 From: trac at galois.com (GHC) Date: Mon Mar 9 20:22:04 2009 Subject: [GHC] #3060: impossible internal bug while building darcs In-Reply-To: <044.8b050eb370b3a248f628f79a0a5b8c10@localhost> References: <044.8b050eb370b3a248f628f79a0a5b8c10@localhost> Message-ID: <053.72dc6852db66c5a047f7737d65cc3c9d@localhost> #3060: impossible internal bug while building darcs -------------------------+-------------------------------------------------- Reporter: quick | Owner: Type: bug | Status: reopened Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by quick): * status: closed => reopened * resolution: invalid => * severity: major => minor Comment: Sorry for the delay... I can confirm that a cabal-based installation of unix-2.3.1.0 causes the darcs-build error to re-occur. The build of unix-2.3.1.0 proceeded without problems, but the result is fatal. A {{{ghc-pkg hide unix-2.3.1.0}}} is successful and a list confirms that unix is hidden (surrounded by parentheses) but the error persists. I cannot {{{ghc-pkg unregister unix}}} because: {{{ ghc-pkg: unregistering unix would break the following packages: haddock-2.3.0 ghc-6.10.1 directory-1.0.0.2 process-1.0.1.0 hpc-0.5.0.2 Cabal-1.6.0.1 haskell98-1.0.1.0 (use --force to override) }}} The only solution apparent at this point is to remove GHC-6.10.1 and fallback to GHC-6.8.3, then use GHC-6.8.3 to rebuild and re-install GHC-6.10.1. I cannot simply rebuild GHC-6.10.1 because it has a similar failure attempting to build itself. So... I'm going to re-open this bug, but with lower severity (because there are workarounds). The unix package is definitely problematic post- install. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 10 05:21:57 2009 From: trac at galois.com (GHC) Date: Tue Mar 10 05:10:17 2009 Subject: [GHC] #3060: impossible internal bug while building darcs In-Reply-To: <044.8b050eb370b3a248f628f79a0a5b8c10@localhost> References: <044.8b050eb370b3a248f628f79a0a5b8c10@localhost> Message-ID: <053.f1c80d6c07a2473095b6a91ae5a0c02b@localhost> #3060: impossible internal bug while building darcs -------------------------+-------------------------------------------------- Reporter: quick | Owner: Type: bug | Status: reopened Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------+-------------------------------------------------- Comment (by duncan): GHC-6.10.1 bundles unix-2.3.1.0. There are several other installed packages that come with ghc-6.10.1 that depend on unix-2.3.1.0. You cannot in general substitute an installed package without also rebuilding all the other packages that depend on it. There is no guarantee that you can rebuild the package and get the same ABI as previously. In this case you are fortunate that you get errors at compile time due to mismatches in .hi files rather than linker errors or segfaults. At the moment we do not track ABIs so Cabal and ghc-pkg do not prevent you from doing unwise things. The short term solution is to "not do that". The medium term solution is to track the ABI and use it as a check. The longer term solution is to allow installing multiple instances based on their ABI. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 10 06:37:46 2009 From: trac at galois.com (GHC) Date: Tue Mar 10 06:26:07 2009 Subject: [GHC] #2953: deriving Functor, Foldable, Traversable In-Reply-To: <045.1ed3b38adbe9ad6aceca4244fe75f3c0@localhost> References: <045.1ed3b38adbe9ad6aceca4244fe75f3c0@localhost> Message-ID: <054.3e88a0592a628f61a31878ae86221f9a@localhost> #2953: deriving Functor, Foldable, Traversable ---------------------------------+------------------------------------------ Reporter: twanvl | Owner: twanvl Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by duncan): Replying to [comment:11 igloo]: > I don't know if cabal-install does this yet, but part of the plan was that if you told it to install a package `foo`, and `foo` needed an extension that your compiler doesn't support, then cabal-install would fail immediately, rather than downloading and building all of `foo`'s dependencies first. Currently it only fails at configure time, but certainly it is the plan to check these kinds of dependencies up front (along with build tools, C libs, etc). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 10 12:47:13 2009 From: trac at galois.com (GHC) Date: Tue Mar 10 12:35:33 2009 Subject: [GHC] #2934: HEAP_ALLOCED() is not thread-safe In-Reply-To: <044.6991112bf5bb5ad525a492692eb31d8d@localhost> References: <044.6991112bf5bb5ad525a492692eb31d8d@localhost> Message-ID: <053.80dd862ae604f867bd8117e26c9022ca@localhost> #2934: HEAP_ALLOCED() is not thread-safe ----------------------------------+----------------------------------------- Reporter: anish | Owner: igloo Type: merge | Status: closed Priority: high | Milestone: 6.10.2 Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: garbage collector | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86_64 (amd64) | ----------------------------------+----------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 10 12:58:59 2009 From: trac at galois.com (GHC) Date: Tue Mar 10 12:47:17 2009 Subject: [GHC] #2954: System.Process.terminateProcess sends SIGTERM rather than SIGKILL on unix In-Reply-To: <044.33b296bee16ac04eb53e73148864ea5b@localhost> References: <044.33b296bee16ac04eb53e73148864ea5b@localhost> Message-ID: <053.c6fff1b2b496689fc214818a547d15bd@localhost> #2954: System.Process.terminateProcess sends SIGTERM rather than SIGKILL on unix ----------------------------------+----------------------------------------- Reporter: guest | Owner: igloo Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: libraries/process | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by igloo): * type: merge => feature request * milestone: 6.10.2 => 6.12 branch Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From conal at conal.net Tue Mar 10 15:50:13 2009 From: conal at conal.net (Conal Elliott) Date: Tue Mar 10 15:38:31 2009 Subject: Repeated #include in ghci broken? Message-ID: Do ghc and ghci handle CPP differently? In ghci, I'm getting "phase `C pre-processor' failed (exitcode = 1)" when I #include the same .h file more than once in a module. I also get warnings about a symbol being redefined, although I'm careful to #undef them it the end of the include file. All works fine with ghc. Here's my code: #define APPLICATIVE Vec1 #include "ApplicativeNumeric-inc.hs" #define APPLICATIVE Vec2 #include "ApplicativeNumeric-inc.hs" #define APPLICATIVE Vec3 #include "ApplicativeNumeric-inc.hs" #define APPLICATIVE Vec4 #include "ApplicativeNumeric-inc.hs" And here are the error messages in ghci: Graphics/Shady/Vec.hs:134:0: error: ApplicativeNumeric-inc.hs: No such file or directory Graphics/Shady/Vec.hs:136:0: warning: "APPLICATIVE" redefined Graphics/Shady/Vec.hs:133:0: warning: this is the location of the previous definition Graphics/Shady/Vec.hs:139:0: warning: "APPLICATIVE" redefined Graphics/Shady/Vec.hs:136:0: warning: this is the location of the previous definition Graphics/Shady/Vec.hs:142:0: warning: "APPLICATIVE" redefined Graphics/Shady/Vec.hs:139:0: warning: this is the location of the previous definition phase `C pre-processor' failed (exitcode = 1) Any ideas? Suggestions? - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-bugs/attachments/20090310/451c52fc/attachment-0001.htm From trac at galois.com Tue Mar 10 21:32:06 2009 From: trac at galois.com (GHC) Date: Tue Mar 10 21:20:56 2009 Subject: [GHC] #2724: foreign functions called from optimized Haskell code receive non-empty fpu stack In-Reply-To: <044.2d874f0fab562627c6bb887ff848f8fd@localhost> References: <044.2d874f0fab562627c6bb887ff848f8fd@localhost> Message-ID: <053.eae7f42e5a31f59142b2fbed8b4ca1a5@localhost> #2724: foreign functions called from optimized Haskell code receive non-empty fpu stack -------------------------------+-------------------------------------------- Reporter: aruiz | Owner: Type: task | Status: closed Priority: normal | Milestone: 6.10.2 Component: Compiler (NCG) | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: No action for 4 months, so closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 10 21:37:47 2009 From: trac at galois.com (GHC) Date: Tue Mar 10 21:26:11 2009 Subject: [GHC] #2826: Panic compiling lhc-0.6.20081127 In-Reply-To: <043.1a89b950dd25b1bbdfca8fd6e9acbc4c@localhost> References: <043.1a89b950dd25b1bbdfca8fd6e9acbc4c@localhost> Message-ID: <052.508b939c9b2f82e473d087c7ee70712c@localhost> #2826: Panic compiling lhc-0.6.20081127 ---------------------------------+------------------------------------------ Reporter: dons | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: No action for 3 months, so closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 10 21:47:03 2009 From: trac at galois.com (GHC) Date: Tue Mar 10 21:35:22 2009 Subject: [GHC] #2635: ghc panic In-Reply-To: <044.5ed00131488dc69dfc402e9550007157@localhost> References: <044.5ed00131488dc69dfc402e9550007157@localhost> Message-ID: <053.db088526e14476fce3f1d85b29a895ae@localhost> #2635: ghc panic -------------------------+-------------------------------------------------- Reporter: jorzo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: powerpc | -------------------------+-------------------------------------------------- Comment (by mokeefe): On Mac OS 10.5.6 using XCode 3.1.2, when trying to compile the GHC 6.10.1 sources, I get the below error. Note that what prompted me to try to compile the GHC 6.10.1 sources is an error I received when trying to install cabal-install with the GHC 6.10.1 binaries available as a community build. I will report that as a separate issue. ghc-6.10.1 $ make grep: packages: No such file or directory make -C libraries boot rm -f -rf ifBuildable mkdir ifBuildable cp ifBuildable.hs ifBuildable/ cd ifBuildable && /usr/local/bin/ghc -Wall --make ifBuildable -o ifBuildable [1 of 1] Compiling Main ( ifBuildable.hs, ifBuildable.o ) Linking ifBuildable ... mkdir bootstrapping /usr/local/bin/ghc -Wall -DCABAL_VERSION=1,6,0,1 -odir /Users/michaelokeefe/Downloads/ghc-6.10.1/libraries/bootstrapping -hidir /Users/michaelokeefe/Downloads/ghc-6.10.1/libraries/bootstrapping -i/Users/michaelokeefe/Downloads/ghc-6.10.1/libraries/Cabal -i/Users/michaelokeefe/Downloads/ghc-6.10.1/libraries/filepath -i/Users/michaelokeefe/Downloads/ghc-6.10.1/libraries/hpc --make cabal-bin -o cabal-bin [ 1 of 54] Compiling Distribution.Compat.Permissions ( /Users/michaelokeefe/Downloads/ghc-6.10.1/libraries/Cabal/Distribution/Compat/Permissions.hs, /Users/michaelokeefe/Downloads/ghc-6.10.1/libraries/bootstrapping/Distribution/Compat/Permissions.o ) [ 2 of 54] Compiling System.FilePath.Windows ( /Users/michaelokeefe/Downloads/ghc-6.10.1/libraries/filepath/System/FilePath/Windows.hs, /Users/michaelokeefe/Downloads/ghc-6.10.1/libraries/bootstrapping/System/FilePath/Windows.o ) [ 3 of 54] Compiling System.FilePath.Posix ( /Users/michaelokeefe/Downloads/ghc-6.10.1/libraries/filepath/System/FilePath/Posix.hs, /Users/michaelokeefe/Downloads/ghc-6.10.1/libraries/bootstrapping/System/FilePath/Posix.o ) [ 4 of 54] Compiling Distribution.Compat.Exception ( /Users/michaelokeefe/Downloads/ghc-6.10.1/libraries/Cabal/Distribution/Compat/Exception.hs, /Users/michaelokeefe/Downloads/ghc-6.10.1/libraries/bootstrapping/Distribution/Compat/Exception.o ) [ 5 of 54] Compiling Distribution.Compat.TempFile ( /Users/michaelokeefe/Downloads/ghc-6.10.1/libraries/Cabal/Distribution/Compat/TempFile.hs, /Users/michaelokeefe/Downloads/ghc-6.10.1/libraries/bootstrapping/Distribution/Compat/TempFile.o ) [ 6 of 54] Compiling Distribution.GetOpt ( /Users/michaelokeefe/Downloads/ghc-6.10.1/libraries/Cabal/Distribution/GetOpt.hs, /Users/michaelokeefe/Downloads/ghc-6.10.1/libraries/bootstrapping/Distribution/GetOpt.o ) [ 7 of 54] Compiling Distribution.Compat.ReadP ( /Users/michaelokeefe/Downloads/ghc-6.10.1/libraries/Cabal/Distribution/Compat/ReadP.hs, /Users/michaelokeefe/Downloads/ghc-6.10.1/libraries/bootstrapping/Distribution/Compat/ReadP.o ) [ 8 of 54] Compiling Distribution.ReadE ( /Users/michaelokeefe/Downloads/ghc-6.10.1/libraries/Cabal/Distribution/ReadE.hs, /Users/michaelokeefe/Downloads/ghc-6.10.1/libraries/bootstrapping/Distribution/ReadE.o ) [ 9 of 54] Compiling Distribution.Simple.PreProcess.Unlit ( /Users/michaelokeefe/Downloads/ghc-6.10.1/libraries/Cabal/Distribution/Simple/PreProcess/Unlit.hs, /Users/michaelokeefe/Downloads/ghc-6.10.1/libraries/bootstrapping/Distribution/Simple/PreProcess/Unlit.o ) [10 of 54] Compiling Distribution.Simple.GHC.Makefile ( /Users/michaelokeefe/Downloads/ghc-6.10.1/libraries/Cabal/Distribution/Simple/GHC/Makefile.hs, /Users/michaelokeefe/Downloads/ghc-6.10.1/libraries/bootstrapping/Distribution/Simple/GHC/Makefile.o ) [11 of 54] Compiling Distribution.Text ( /Users/michaelokeefe/Downloads/ghc-6.10.1/libraries/Cabal/Distribution/Text.hs, /Users/michaelokeefe/Downloads/ghc-6.10.1/libraries/bootstrapping/Distribution/Text.o ) ghc-6.8.3: panic! (the 'impossible' happened) (GHC version 6.8.3 for powerpc-apple-darwin): divide by zero Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 10 21:56:51 2009 From: trac at galois.com (GHC) Date: Tue Mar 10 21:45:08 2009 Subject: [GHC] #2797: ghci stack overflows when ghc does not In-Reply-To: <053.b5bed6c883dfb7d157e5092dcf2242ee@localhost> References: <053.b5bed6c883dfb7d157e5092dcf2242ee@localhost> Message-ID: <062.1fb7be7b005a9930c89f29833d2340d4@localhost> #2797: ghci stack overflows when ghc does not -----------------------------------------+---------------------------------- Reporter: TristanAllwood | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.10.2 Component: GHCi | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Comment (by igloo): In my profiling HEAD, I'm seeing {{{ (gdb) r [...] -e main z.hs +RTS -DS [Thread debugging using libthread_db enabled] [New process 4968] : internal error: ASSERTION FAILED: file (null), line 698 (GHC version 6.11.20090308 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug [New Thread 139638659299040 (LWP 4968)] Program received signal SIGABRT, Aborted. [Switching to Thread 139638659299040 (LWP 4968)] 0x00007f0027811ef5 in raise () from /lib/libc.so.6 (gdb) bt #0 0x00007f0027811ef5 in raise () from /lib/libc.so.6 #1 0x00007f0027813413 in abort () from /lib/libc.so.6 #2 0x00000000049a1278 in rtsFatalInternalErrorFn ( s=0x51b3520 "ASSERTION FAILED: file %s, line %u\n", ap=0x7fff30c30cd0) at RtsMessages.c:164 #3 0x00000000049a0e3c in barf ( s=0x51b3520 "ASSERTION FAILED: file %s, line %u\n") at RtsMessages.c:40 #4 0x00000000049a0e96 in _assertFail (filename=0x0, linenum=698) at RtsMessages.c:55 #5 0x00000000049c66c6 in stg_ap_pp_info () #6 0x0000000000000000 in ?? () }}} Looks like this is the assertion in `AutoApply_debug_p.cmm` here: {{{ case FUN, FUN_1_0, FUN_0_1, FUN_2_0, FUN_1_1, FUN_0_2, FUN_STATIC: { arity = TO_W_(StgFunInfoExtra_arity(%FUN_INFO(info))); ASSERT(arity > 0); if (arity == 1) { R2 = W_[Sp+WDS(1)]; W_[Sp+WDS(1)] = stg_ap_p_info; Sp_adj(1); R1 = R1 + 1; jump %GET_ENTRY(UNTAG(R1)); } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From lennart at augustsson.net Tue Mar 10 22:02:18 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Tue Mar 10 21:50:35 2009 Subject: Repeated #include in ghci broken? In-Reply-To: References: Message-ID: Perhaps the warnings are bad? (You can use #undef to avoid them.) -- Lennart 2009/3/10 Conal Elliott : > Do ghc and ghci handle CPP differently?? In ghci, I'm getting "phase `C > pre-processor' failed (exitcode = 1)" when I #include the same .h file more > than once in a module.? I also get warnings about a symbol being redefined, > although I'm careful to #undef them it the end of the include file.? All > works fine with ghc. > > Here's my code: > > ??? #define APPLICATIVE Vec1 > ??? #include "ApplicativeNumeric-inc.hs" > > ??? #define APPLICATIVE Vec2 > ??? #include "ApplicativeNumeric-inc.hs" > > ??? #define APPLICATIVE Vec3 > ??? #include "ApplicativeNumeric-inc.hs" > > ??? #define APPLICATIVE Vec4 > ??? #include "ApplicativeNumeric-inc.hs" > > And here are the error messages in ghci: > > ??? Graphics/Shady/Vec.hs:134:0: > ??? ?error: ApplicativeNumeric-inc.hs: No such file or directory > > ??? Graphics/Shady/Vec.hs:136:0:? warning: "APPLICATIVE" redefined > > ??? Graphics/Shady/Vec.hs:133:0: > ??? ?warning: this is the location of the previous definition > > ??? Graphics/Shady/Vec.hs:139:0:? warning: "APPLICATIVE" redefined > > ??? Graphics/Shady/Vec.hs:136:0: > ??? ?warning: this is the location of the previous definition > > ??? Graphics/Shady/Vec.hs:142:0:? warning: "APPLICATIVE" redefined > > ??? Graphics/Shady/Vec.hs:139:0: > ??? ?warning: this is the location of the previous definition > ??? phase `C pre-processor' failed (exitcode = 1) > > Any ideas?? Suggestions? > > ? - Conal > > _______________________________________________ > Glasgow-haskell-bugs mailing list > Glasgow-haskell-bugs@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs > > From igloo at earth.li Tue Mar 10 22:15:35 2009 From: igloo at earth.li (Ian Lynagh) Date: Tue Mar 10 22:03:51 2009 Subject: Repeated #include in ghci broken? In-Reply-To: References: Message-ID: <20090311021535.GA5291@matrix.chaos.earth.li> Hi Conal, On Tue, Mar 10, 2009 at 12:50:13PM -0700, Conal Elliott wrote: > Do ghc and ghci handle CPP differently? In ghci, I'm getting "phase `C > pre-processor' failed (exitcode = 1)" when I #include the same .h file more > than once in a module. I also get warnings about a symbol being redefined, > although I'm careful to #undef them it the end of the include file. All > works fine with ghc. Your problem seems to be that cpp can't find ApplicativeNumeric-inc.hs when run by ghci: > Graphics/Shady/Vec.hs:134:0: > error: ApplicativeNumeric-inc.hs: No such file or directory It looks to me like ghc and ghci are calling cpp in the same way, so if you can't see what the problem is then can you please let us know what version of GHC you are using, exactly what commands you are running, and give us a complete reproducible testcase? Thanks Ian From trac at galois.com Tue Mar 10 23:02:06 2009 From: trac at galois.com (GHC) Date: Tue Mar 10 22:50:22 2009 Subject: [GHC] #2781: Install permissions broken In-Reply-To: <044.61bd22c82633a255fd3e3d2cc7138fa8@localhost> References: <044.61bd22c82633a255fd3e3d2cc7138fa8@localhost> Message-ID: <053.72e12c6b492f24842a51f94103bbb146@localhost> #2781: Install permissions broken ------------------------------------+--------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.2 Component: Build System | Version: 6.10.1 Severity: normal | Resolution: worksforme Keywords: install permissions | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ------------------------------------+--------------------------------------- Changes (by igloo): * status: new => closed * resolution: => worksforme Comment: No reply in 4 months, so closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From conal at conal.net Tue Mar 10 23:11:28 2009 From: conal at conal.net (Conal Elliott) Date: Tue Mar 10 22:59:45 2009 Subject: Repeated #include in ghci broken? In-Reply-To: <20090311021535.GA5291@matrix.chaos.earth.li> References: <20090311021535.GA5291@matrix.chaos.earth.li> Message-ID: Oh! I missed the crucial error message and got distracted by the secondary ones. Thanks, Ian. When I use ghc, it's via cabal, which is then finding up the necessary include file (from applicative-numbers). I guess I have to somehow direct ghci to the include directory. Is that possible? - Conal On Tue, Mar 10, 2009 at 7:15 PM, Ian Lynagh wrote: > > Hi Conal, > > On Tue, Mar 10, 2009 at 12:50:13PM -0700, Conal Elliott wrote: > > Do ghc and ghci handle CPP differently? In ghci, I'm getting "phase `C > > pre-processor' failed (exitcode = 1)" when I #include the same .h file > more > > than once in a module. I also get warnings about a symbol being > redefined, > > although I'm careful to #undef them it the end of the include file. All > > works fine with ghc. > > Your problem seems to be that cpp can't find ApplicativeNumeric-inc.hs > when run by ghci: > > > Graphics/Shady/Vec.hs:134:0: > > error: ApplicativeNumeric-inc.hs: No such file or directory > > It looks to me like ghc and ghci are calling cpp in the same way, so if > you can't see what the problem is then can you please let us know what > version of GHC you are using, exactly what commands you are running, and > give us a complete reproducible testcase? > > > Thanks > Ian > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-bugs/attachments/20090310/536cab28/attachment.htm From trac at galois.com Wed Mar 11 06:03:11 2009 From: trac at galois.com (GHC) Date: Wed Mar 11 05:51:28 2009 Subject: [GHC] #2991: .mix files generation broken with -fhpc and --make flags with lhs modules In-Reply-To: <045.fbdf830be4083dc434ba708ecd719a55@localhost> References: <045.fbdf830be4083dc434ba708ecd719a55@localhost> Message-ID: <054.118c026525bdf9b27453a51eebd94601@localhost> #2991: .mix files generation broken with -fhpc and --make flags with lhs modules ---------------------------------+------------------------------------------ Reporter: ppavel | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: hpc make lhs | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * cc: andygill@ku.edu (added) Comment: Andy, any chance you could look at this? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 11 06:20:44 2009 From: trac at galois.com (GHC) Date: Wed Mar 11 06:09:03 2009 Subject: [GHC] #2976: :show bindings give wrong results when a variable was redefined In-Reply-To: <046.67cbe4a77482922fe0ecb159593d1d6b@localhost> References: <046.67cbe4a77482922fe0ecb159593d1d6b@localhost> Message-ID: <055.958f5596a0d7707f0085148d42647504@localhost> #2976: :show bindings give wrong results when a variable was redefined ---------------------------------+------------------------------------------ Reporter: phercek | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 11 06:22:58 2009 From: trac at galois.com (GHC) Date: Wed Mar 11 06:11:14 2009 Subject: [GHC] #2963: Exception if current path has national symbols In-Reply-To: <044.20cd1d7dd4607528a617f9d3d52f59f8@localhost> References: <044.20cd1d7dd4607528a617f9d3d52f59f8@localhost> Message-ID: <053.c13c5e0518698555d9b147c8250e520c@localhost> #2963: Exception if current path has national symbols ------------------------------------+--------------------------------------- Reporter: Tonal | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: libraries/directory | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | ------------------------------------+--------------------------------------- Changes (by simonmar): * owner: => simonmar Comment: I'll look at this. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 11 06:31:16 2009 From: trac at galois.com (GHC) Date: Wed Mar 11 06:19:33 2009 Subject: [GHC] #2930: System.Time.formatCalendarTime: %s isn't the number of seconds since the Epoch In-Reply-To: <044.0a1fdac704adf497121070f9c08f89a0@localhost> References: <044.0a1fdac704adf497121070f9c08f89a0@localhost> Message-ID: <053.c5ce232fa75d6e463c4097c8f24f41fd@localhost> #2930: System.Time.formatCalendarTime: %s isn't the number of seconds since the Epoch -----------------------------------+---------------------------------------- Reporter: wferi | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: libraries/old-time | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -----------------------------------+---------------------------------------- Changes (by simonmar): * owner: => simonmar Comment: I'll do this. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 11 06:35:51 2009 From: trac at galois.com (GHC) Date: Wed Mar 11 06:24:07 2009 Subject: [GHC] #2925: Linker mmap failure on FreeBSD/x86_64 In-Reply-To: <047.eaff3ca4aa8bcea6096eb0e3b35eda7f@localhost> References: <047.eaff3ca4aa8bcea6096eb0e3b35eda7f@localhost> Message-ID: <056.288908b79be09f12d91a0f6c5058acbd@localhost> #2925: Linker mmap failure on FreeBSD/x86_64 -------------------------------+-------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: FreeBSD Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by simonmar): * priority: normal => high Comment: I believe this is now fixed (see also #2063). Let's make sure we test the 6.10.2 RC. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 11 06:42:32 2009 From: trac at galois.com (GHC) Date: Wed Mar 11 06:30:48 2009 Subject: [GHC] #3082: Unclear warning message: Attempting to re-export hidden constructors Message-ID: <042.a5c4cd3afa0abc022930d0824ba94bfa@localhost> #3082: Unclear warning message: Attempting to re-export hidden constructors -----------------------------+---------------------------------------------- Reporter: ksf | Owner: Type: proposal | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: minor Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Just stumbled upon this after changing a type def to a data def: Foo.hs: {{{ module Foo (Foo) where data Foo = Bar | Baz }}} Bar.hs: {{{ module Bar (Foo.Foo(..)) where import Foo }}} {{{ Bar.hs:1:12: Warning: The export item `Foo(..)' suggests that `Foo' has constructors or class methods, but it has none }}} ...while it actually has constructors. I think it should say "The export item 'Foo(..)' suggests that 'Foo' has visible constructors or class methods, but it has none", or something even more specific to the re-export case. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 11 07:01:24 2009 From: trac at galois.com (GHC) Date: Wed Mar 11 06:49:40 2009 Subject: [GHC] #2832: GHC -split-objs, Doesn't Print Error If GHC Built With SplitObjs = NO. In-Reply-To: <046.70ce203c528d9187aa1e90914e4360f2@localhost> References: <046.70ce203c528d9187aa1e90914e4360f2@localhost> Message-ID: <055.b553e691f07033eba7e74c7a614d03ac@localhost> #2832: GHC -split-objs, Doesn't Print Error If GHC Built With SplitObjs = NO. ---------------------------------+------------------------------------------ Reporter: dejones | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: split-objs, ghc | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 11 07:23:22 2009 From: trac at galois.com (GHC) Date: Wed Mar 11 07:11:43 2009 Subject: [GHC] #2816: ghci type messages mangle unicode In-Reply-To: <042.cda3d53c33f3e686ec1551e0d8688ddf@localhost> References: <042.cda3d53c33f3e686ec1551e0d8688ddf@localhost> Message-ID: <051.366973f912e3df662ed5aa7e6c233e0f@localhost> #2816: ghci type messages mangle unicode ------------------------------+--------------------------------------------- Reporter: rog | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: unicode utf-8 | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | ------------------------------+--------------------------------------------- Changes (by simonmar): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 11 07:45:14 2009 From: trac at galois.com (GHC) Date: Wed Mar 11 07:33:30 2009 Subject: [GHC] #2785: Memory leakage with socket benchmark program In-Reply-To: <047.470588859e52453dab1b67a6015374ad@localhost> References: <047.470588859e52453dab1b67a6015374ad@localhost> Message-ID: <056.9d44eb198786f509f9e9daf6656c7791@localhost> #2785: Memory leakage with socket benchmark program -----------------------------------------+---------------------------------- Reporter: felixmar | Owner: simonmar Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Runtime System | Version: 6.10.1 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -----------------------------------------+---------------------------------- Changes (by simonmar): * owner: => simonmar Comment: I think I may have fixed this, will check. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 11 07:49:34 2009 From: trac at galois.com (GHC) Date: Wed Mar 11 07:37:55 2009 Subject: [GHC] #2744: Missing requirement check for hsc2hs In-Reply-To: <045.22de1b93d87ec567af1e55ce56c09fd8@localhost> References: <045.22de1b93d87ec567af1e55ce56c09fd8@localhost> Message-ID: <054.9fdcc12b8e7fa6ef908c3a3329e4f50d@localhost> #2744: Missing requirement check for hsc2hs -----------------------------+---------------------------------------------- Reporter: jputcu | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Build System | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -----------------------------+---------------------------------------------- Changes (by simonmar): * milestone: 6.10.2 => 6.12 branch Comment: Non-essential; I've made a note to do this in the new build system. Bumping to 6.12. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 11 07:50:27 2009 From: trac at galois.com (GHC) Date: Wed Mar 11 07:38:45 2009 Subject: [GHC] #2689: make maintainer-clean leaves generated files and directories In-Reply-To: <044.d82e9d076aeb3a76dac009bdaa86249d@localhost> References: <044.d82e9d076aeb3a76dac009bdaa86249d@localhost> Message-ID: <053.7445a9eee069128df28c5dc25d7eee2c@localhost> #2689: make maintainer-clean leaves generated files and directories ---------------------------------+------------------------------------------ Reporter: claus | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Build System | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * milestone: 6.10.2 => 6.12 branch Comment: We'll fix maintainer-clean and distclean properly in the new build system. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 11 07:55:10 2009 From: trac at galois.com (GHC) Date: Wed Mar 11 07:43:29 2009 Subject: [GHC] #2673: FreeBSD built-in libedit is not compatible with GHC In-Reply-To: <048.a7a8b8cd246f16f4f13f2f8936382c3e@localhost> References: <048.a7a8b8cd246f16f4f13f2f8936382c3e@localhost> Message-ID: <057.d65d3519da2846cf432c95f73ef8daa7@localhost> #2673: FreeBSD built-in libedit is not compatible with GHC --------------------------+------------------------------------------------- Reporter: gmainland | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: FreeBSD Architecture: x86 | --------------------------+------------------------------------------------- Comment (by simonmar): Anyone want to supply a proper fix for this? The FreeBSD folks have traditionally added their own patches to GHC via the ports system anyway, so it's not a disaster if we don't get a fix into 6.10.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 11 08:04:59 2009 From: trac at galois.com (GHC) Date: Wed Mar 11 07:53:14 2009 Subject: [GHC] #3083: Win32 package should bind SHGetFolderPath Message-ID: <045.07ec9167505060698bef96705be4add8@localhost> #3083: Win32 package should bind SHGetFolderPath ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: feature request | Status: new Priority: normal | Component: libraries (other) Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Windows | Architecture: x86 ----------------------------+----------------------------------------------- Currently Cabal binds this function so that we can find the "Program Files" directory on Windows: {{{ foreign import stdcall unsafe "shlobj.h SHGetFolderPathA" c_SHGetFolderPath :: Ptr () -> CInt -> Ptr () -> CInt -> CString -> IO CInt }}} This is fine except that it does not work in ghci because we have no way to tell ghci that it would need to link to `shell32.dll`. As it happens we do not have to tell the static linker to use `shell32.dll` because it appears to link to it by default. This of course means that `runghc Setup` does not work on Windows for Cabal itself which trips up many users. The fact that the `README` tells people to use `ghc --make Setup` instead doesn't help a great deal. See [http://hackage.haskell.org/trac/hackage/ticket/325 Cabal ticket #325] What would be nice is if the Win32 package would bind [http://msdn.microsoft.com/en-us/library/bb762181(VS.85).aspx SHGetFolderPath]. Then we just import it from the Win32 package and it'll work in ghci. Apparently, according to MSDN, this function is technically deprecated, however the replacement [http://msdn.microsoft.com/en- us/library/bb762188(VS.85).aspx SHGetKnownFolderPath] is only available in Vista and later so we probably need to bind it anyway. Note that `SHGetFolderPath` is in `shell32.dll` except on Windows 2000 which include it in `SHFolder.dll` which come with IE4 and later. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 11 08:59:39 2009 From: trac at galois.com (GHC) Date: Wed Mar 11 08:47:55 2009 Subject: [GHC] #3084: alow macros to redefine builtin GHCi commands Message-ID: <046.7f055f7e30420d89efe3f2db433a2d00@localhost> #3084: alow macros to redefine builtin GHCi commands -----------------------------+---------------------------------------------- Reporter: phercek | Owner: Type: feature request | Status: new Priority: normal | Component: GHCi Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- I would like to be able to redefine the builtin GHCi commands. The idea is that when searching for a command the user defined macros would be searched first and only then the built-in commands would be searched. If user wants to invoke a built-in command regardless of user defined commands he/she would need to start it with two colons (instead of one). It is an user interface change which may break some scripts, but it would allow to provide different default behavior.[[BR]] For example: * when I use my GHCi extensions I want all my ":continue" commands to be actually something like ":x :continue" * it would allow to specify different order of searching for abbreviated commands as the default one * it would allow to specify different default switches for builtin commands (when they have any) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 11 09:14:58 2009 From: trac at galois.com (GHC) Date: Wed Mar 11 09:03:16 2009 Subject: [GHC] #3084: alow macros to redefine builtin GHCi commands In-Reply-To: <046.7f055f7e30420d89efe3f2db433a2d00@localhost> References: <046.7f055f7e30420d89efe3f2db433a2d00@localhost> Message-ID: <055.9252b73f60fef217a536c2422c144523@localhost> #3084: alow macros to redefine builtin GHCi commands ------------------------------+--------------------------------------------- Reporter: phercek | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by phercek): I ran verify and the patch did not result in any new faiures. There were two old failures though: ffi014(threaded1), and testwsdeque(threaded1).[[BR]] It would be cool if this could get to 6.10.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 11 09:19:29 2009 From: trac at galois.com (GHC) Date: Wed Mar 11 09:07:45 2009 Subject: [GHC] #2976: :show bindings give wrong results when a variable was redefined In-Reply-To: <046.67cbe4a77482922fe0ecb159593d1d6b@localhost> References: <046.67cbe4a77482922fe0ecb159593d1d6b@localhost> Message-ID: <055.28f7e64f28a4bcaa5a5a10a4e325ee47@localhost> #2976: :show bindings give wrong results when a variable was redefined ---------------------------------+------------------------------------------ Reporter: phercek | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.2 Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: Fixed: {{{ Wed Mar 11 10:20:07 GMT 2009 Simon Marlow * FIX #2976: fix buggy implementation of shadowing in GHC.getBindings }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 11 09:20:33 2009 From: trac at galois.com (GHC) Date: Wed Mar 11 09:08:51 2009 Subject: [GHC] #2832: GHC -split-objs, Doesn't Print Error If GHC Built With SplitObjs = NO. In-Reply-To: <046.70ce203c528d9187aa1e90914e4360f2@localhost> References: <046.70ce203c528d9187aa1e90914e4360f2@localhost> Message-ID: <055.18113ffca5ed6b5077ad983b20d693ae@localhost> #2832: GHC -split-objs, Doesn't Print Error If GHC Built With SplitObjs = NO. ---------------------------------+------------------------------------------ Reporter: dejones | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: split-objs, ghc | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: Fixed: {{{ Wed Mar 11 11:00:58 GMT 2009 Simon Marlow * FIX #2832: Setting SplitObjs=NO doesn't disable -split-objs in GHC Now ghc --info reports whether-split-objs is supported, rather than whether the libraries were built using -split-objs. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 11 09:22:33 2009 From: trac at galois.com (GHC) Date: Wed Mar 11 09:10:55 2009 Subject: [GHC] #2816: ghci type messages mangle unicode In-Reply-To: <042.cda3d53c33f3e686ec1551e0d8688ddf@localhost> References: <042.cda3d53c33f3e686ec1551e0d8688ddf@localhost> Message-ID: <051.61a4443429d6811fa1ab6c2671010ad3@localhost> #2816: ghci type messages mangle unicode ------------------------------+--------------------------------------------- Reporter: rog | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.2 Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: unicode utf-8 | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | ------------------------------+--------------------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: Fixed: {{{ Wed Mar 11 11:23:11 GMT 2009 Simon Marlow * FIX #2816 (correct unicode output for :type/:kind) This is just a hack, since we don't have correct unicode output for Handles in general, I just fixed a couple of places where we were not converting to UTF-8 for output. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 11 09:23:41 2009 From: trac at galois.com (GHC) Date: Wed Mar 11 09:11:58 2009 Subject: [GHC] #2930: System.Time.formatCalendarTime: %s isn't the number of seconds since the Epoch In-Reply-To: <044.0a1fdac704adf497121070f9c08f89a0@localhost> References: <044.0a1fdac704adf497121070f9c08f89a0@localhost> Message-ID: <053.1de5dc3a7906040fd9825c679abdec7d@localhost> #2930: System.Time.formatCalendarTime: %s isn't the number of seconds since the Epoch -----------------------------------+---------------------------------------- Reporter: wferi | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.2 Component: libraries/old-time | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -----------------------------------+---------------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: Fixed: {{{ Wed Mar 11 10:30:48 GMT 2009 Simon Marlow * FIX #2930 (formatCalaendarTime's %s wasn't working properly) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 11 09:21:26 2009 From: trac at galois.com (GHC) Date: Wed Mar 11 09:16:00 2009 Subject: [GHC] #2992: GHCi Memory Leak in Windows Vista In-Reply-To: <044.bbcf8b8aa5f153518193d9089d558ebe@localhost> References: <044.bbcf8b8aa5f153518193d9089d558ebe@localhost> Message-ID: <053.d18243da4022d553c30e81f10290e325@localhost> #2992: GHCi Memory Leak in Windows Vista -----------------------+---------------------------------------------------- Reporter: Andir | Owner: igloo Type: merge | Status: new Priority: high | Milestone: 6.10.2 Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -----------------------+---------------------------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: Fixed: {{{ Wed Mar 11 09:42:08 GMT 2009 Simon Marlow * Fix #2992: don't create a named event Evidently I misread the docs for CreateEvent: if you pass a name to CreateEvent, then it creates a single shared system-wide Event with that name. So all Haskell processes on the machine were sharing the same Event object. duh. }}} and in libraries/base: {{{ Wed Mar 11 09:39:38 GMT 2009 Simon Marlow * avoid a space leak building up in the "prodding" IORef (part of #2992) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 11 09:28:07 2009 From: trac at galois.com (GHC) Date: Wed Mar 11 09:16:23 2009 Subject: [GHC] #2963: Exception if current path has national symbols In-Reply-To: <044.20cd1d7dd4607528a617f9d3d52f59f8@localhost> References: <044.20cd1d7dd4607528a617f9d3d52f59f8@localhost> Message-ID: <053.6560a5dc40fea8ba971c517f99f6459c@localhost> #2963: Exception if current path has national symbols ------------------------------------+--------------------------------------- Reporter: Tonal | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.2 Component: libraries/directory | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | ------------------------------------+--------------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: Fixed. Note the patch above was bogus: the arguments to `GetCurrentDirectoryW` are the other way around. Ian: as we discussed, you might want to avoid changing the Win32 API when merging this one by pulling `getCurrentDirectory` into `System.Directory`. It's defined in terms of `System.Win32.Info.try`, but that is exported (perhaps it shouldn't be!). libraries/Win32: {{{ Wed Mar 11 12:17:25 GMT 2009 Simon Marlow * Add getCurrentDirectory (code from #2963) }}} libraries/directory: {{{ Wed Mar 11 11:37:37 GMT 2009 Simon Marlow * FIX #2963: Use System.Win32.getCurrentDirectory }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 11 12:35:38 2009 From: trac at galois.com (GHC) Date: Wed Mar 11 12:23:59 2009 Subject: [GHC] #2395: "Pattern match(es) are overlapped" warning with a single view pattern (ghc 6.9.20080606) In-Reply-To: <047.ecbd48e54b1bf1fee3a4558a1775b513@localhost> References: <047.ecbd48e54b1bf1fee3a4558a1775b513@localhost> Message-ID: <056.2e82a005e3c9eb518757ec3b6c65f942@localhost> #2395: "Pattern match(es) are overlapped" warning with a single view pattern (ghc 6.9.20080606) ---------------------------------+------------------------------------------ Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by ganesh): * cc: ganesh@earth.li (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 11 12:38:02 2009 From: trac at galois.com (GHC) Date: Wed Mar 11 12:26:20 2009 Subject: [GHC] #2395: "Pattern match(es) are overlapped" warning with a single view pattern (ghc 6.9.20080606) In-Reply-To: <047.ecbd48e54b1bf1fee3a4558a1775b513@localhost> References: <047.ecbd48e54b1bf1fee3a4558a1775b513@localhost> Message-ID: <056.470e9bed1226f64d4e354840026fbd96@localhost> #2395: "Pattern match(es) are overlapped" warning with a single view pattern (ghc 6.9.20080606) ---------------------------------+------------------------------------------ Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igel): * cc: deduktionstheorem@web.de (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 11 14:03:32 2009 From: trac at galois.com (GHC) Date: Wed Mar 11 13:51:48 2009 Subject: [GHC] #3085: warn about language extensions that are not used Message-ID: <051.bedfbd02c24cc787d0bf163c67d17d1e@localhost> #3085: warn about language extensions that are not used -----------------------------------------+---------------------------------- Reporter: PVerswyvelen | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: warnings extensions language | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------------------+---------------------------------- When I put `{-# OPTIONS_GHC -Wall -Werror #-}` in my source file, I don't get compiler warnings about redundant language extensions that I enabled in that file. For example if I write `{-# LANGUAGE GeneralizedNewtypeDeriving #-}` in the file, but I never do newtype deriving, the compiler could give me a warning. It would be nice if the compiler gave warnings about this, since after refactoring, some language extensions might not be needed anymore, and hence should be removed since fewer language extensions mean more stable and portable code no? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 11 14:11:51 2009 From: trac at galois.com (GHC) Date: Wed Mar 11 14:04:27 2009 Subject: [GHC] #2992: GHCi Memory Leak in Windows Vista In-Reply-To: <044.bbcf8b8aa5f153518193d9089d558ebe@localhost> References: <044.bbcf8b8aa5f153518193d9089d558ebe@localhost> Message-ID: <053.99c20a45ddf800d2664c6749d8150354@localhost> #2992: GHCi Memory Leak in Windows Vista -----------------------+---------------------------------------------------- Reporter: Andir | Owner: igloo Type: merge | Status: closed Priority: high | Milestone: 6.10.2 Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -----------------------+---------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Both merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 11 14:25:04 2009 From: trac at galois.com (GHC) Date: Wed Mar 11 14:13:37 2009 Subject: [GHC] #2816: ghci type messages mangle unicode In-Reply-To: <042.cda3d53c33f3e686ec1551e0d8688ddf@localhost> References: <042.cda3d53c33f3e686ec1551e0d8688ddf@localhost> Message-ID: <051.50c2c48c8a45d15be82683a821d8d72a@localhost> #2816: ghci type messages mangle unicode ------------------------------+--------------------------------------------- Reporter: rog | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10.2 Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: unicode utf-8 | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | ------------------------------+--------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 11 14:25:21 2009 From: trac at galois.com (GHC) Date: Wed Mar 11 14:13:48 2009 Subject: [GHC] #2832: GHC -split-objs, Doesn't Print Error If GHC Built With SplitObjs = NO. In-Reply-To: <046.70ce203c528d9187aa1e90914e4360f2@localhost> References: <046.70ce203c528d9187aa1e90914e4360f2@localhost> Message-ID: <055.729b98ea76c23a7f4a4bd3af6124658d@localhost> #2832: GHC -split-objs, Doesn't Print Error If GHC Built With SplitObjs = NO. ---------------------------------+------------------------------------------ Reporter: dejones | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.11 Severity: normal | Resolution: fixed Keywords: split-objs, ghc | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 11 14:25:43 2009 From: trac at galois.com (GHC) Date: Wed Mar 11 14:14:00 2009 Subject: [GHC] #2976: :show bindings give wrong results when a variable was redefined In-Reply-To: <046.67cbe4a77482922fe0ecb159593d1d6b@localhost> References: <046.67cbe4a77482922fe0ecb159593d1d6b@localhost> Message-ID: <055.b7089560d8b48c45da5ed1a563caa581@localhost> #2976: :show bindings give wrong results when a variable was redefined ---------------------------------+------------------------------------------ Reporter: phercek | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10.2 Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 11 14:25:58 2009 From: trac at galois.com (GHC) Date: Wed Mar 11 14:14:15 2009 Subject: [GHC] #2930: System.Time.formatCalendarTime: %s isn't the number of seconds since the Epoch In-Reply-To: <044.0a1fdac704adf497121070f9c08f89a0@localhost> References: <044.0a1fdac704adf497121070f9c08f89a0@localhost> Message-ID: <053.4e1dcf23680bc1f783978764d384b020@localhost> #2930: System.Time.formatCalendarTime: %s isn't the number of seconds since the Epoch -----------------------------------+---------------------------------------- Reporter: wferi | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10.2 Component: libraries/old-time | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -----------------------------------+---------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 11 14:25:12 2009 From: trac at galois.com (GHC) Date: Wed Mar 11 14:19:49 2009 Subject: [GHC] #2992: GHCi Memory Leak in Windows Vista In-Reply-To: <044.bbcf8b8aa5f153518193d9089d558ebe@localhost> References: <044.bbcf8b8aa5f153518193d9089d558ebe@localhost> Message-ID: <053.f593189587ccffa20899ca9dd91f2c0e@localhost> #2992: GHCi Memory Leak in Windows Vista -----------------------+---------------------------------------------------- Reporter: Andir | Owner: igloo Type: merge | Status: closed Priority: high | Milestone: 6.10.2 Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -----------------------+---------------------------------------------------- Comment (by sof): Nice piece of debugging, but how did you pin it down to an overly-shared Event being the cause? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 11 15:34:16 2009 From: trac at galois.com (GHC) Date: Wed Mar 11 15:29:13 2009 Subject: [GHC] #2992: GHCi Memory Leak in Windows Vista In-Reply-To: <044.bbcf8b8aa5f153518193d9089d558ebe@localhost> References: <044.bbcf8b8aa5f153518193d9089d558ebe@localhost> Message-ID: <053.c1b75e00ee0d3f90cc1a99e49d598122@localhost> #2992: GHCi Memory Leak in Windows Vista -----------------------+---------------------------------------------------- Reporter: Andir | Owner: igloo Type: merge | Status: closed Priority: high | Milestone: 6.10.2 Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -----------------------+---------------------------------------------------- Comment (by simonmar): Compiling a stage 2 with `-debug` and then running it with `--interactive +RTS -Ds` gave enough clues: every time I ran `ghc` in another window the first `ghc` process would start running thread 2, which I happened to know was the IO manager thread. The IO manager normally just sits in `WaitForSingleObject` on the `Event` object, so I went looking for ways that `WaitForSingleObject` could wake up, and then on a hunch I went to look at the way the `Event` was created... and there it was. I verified that after the fix I don't see the odd interaction between the two `ghc` processes any more. So I'm still not sure why it is that sometimes `WaitForSingleObject` would get woken up many times in quick succession. I'm only guessing that it was the `prodding` `IORef` that was leaking, but it certainly looks suspicious, and there aren't any other obvious candidates. Anyway, I can't repeat the problem any more. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 11 18:31:00 2009 From: trac at galois.com (GHC) Date: Wed Mar 11 18:19:21 2009 Subject: [GHC] #2395: "Pattern match(es) are overlapped" warning with a single view pattern (ghc 6.9.20080606) In-Reply-To: <047.ecbd48e54b1bf1fee3a4558a1775b513@localhost> References: <047.ecbd48e54b1bf1fee3a4558a1775b513@localhost> Message-ID: <056.41e48d5015228c63f01c8c21db345fb5@localhost> #2395: "Pattern match(es) are overlapped" warning with a single view pattern (ghc 6.9.20080606) ---------------------------------+------------------------------------------ Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by BenMoseley): * cc: ben@moseley.name (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 11 22:08:21 2009 From: trac at galois.com (GHC) Date: Wed Mar 11 21:56:45 2009 Subject: [GHC] #2917: alloca and allocaArray do not respect alignment In-Reply-To: <044.ae4012da6404813e981e2064d26c5c85@localhost> References: <044.ae4012da6404813e981e2064d26c5c85@localhost> Message-ID: <053.080a90d73da1dce9602fe8f2eb675ffc@localhost> #2917: alloca and allocaArray do not respect alignment ---------------------------------+------------------------------------------ Reporter: guest | Owner: igloo Type: merge | Status: closed Priority: high | Milestone: 6.10.2 Component: Compiler (FFI) | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged: {{{ Wed Mar 11 13:26:17 PDT 2009 Ian Lynagh * Merge the #2917 fixes for the 6.10 branch }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 11 22:08:37 2009 From: trac at galois.com (GHC) Date: Wed Mar 11 21:57:06 2009 Subject: [GHC] #2917: alloca and allocaArray do not respect alignment In-Reply-To: <044.ae4012da6404813e981e2064d26c5c85@localhost> References: <044.ae4012da6404813e981e2064d26c5c85@localhost> Message-ID: <053.f4cf912ef12d99aeda0a88527fb2cd1d@localhost> #2917: alloca and allocaArray do not respect alignment ---------------------------------+------------------------------------------ Reporter: guest | Owner: igloo Type: merge | Status: reopened Priority: high | Milestone: 6.12 branch Component: Compiler (FFI) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: closed => reopened * resolution: fixed => * milestone: 6.10.2 => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 11 22:11:24 2009 From: trac at galois.com (GHC) Date: Wed Mar 11 21:59:38 2009 Subject: [GHC] #2963: Exception if current path has national symbols In-Reply-To: <044.20cd1d7dd4607528a617f9d3d52f59f8@localhost> References: <044.20cd1d7dd4607528a617f9d3d52f59f8@localhost> Message-ID: <053.e425bc389679101ef0b6d8dfb71a3718@localhost> #2963: Exception if current path has national symbols ------------------------------------+--------------------------------------- Reporter: Tonal | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10.2 Component: libraries/directory | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | ------------------------------------+--------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed in 6.10 branch by: {{{ Wed Mar 11 11:37:37 GMT 2009 Simon Marlow * FIX #2963: Use System.Win32.getCurrentDirectory Wed Mar 11 17:56:59 PDT 2009 Ian Lynagh * Define and use c_getCurrentDirectory on Windows This means that we don't have to change the interface of Win32 in the 6.10 branch. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 11 23:09:40 2009 From: trac at galois.com (GHC) Date: Wed Mar 11 22:57:58 2009 Subject: [GHC] #2267: Bogus "unused import" warning In-Reply-To: <046.30ab0572d75eae6eab884580b0a1c4cf@localhost> References: <046.30ab0572d75eae6eab884580b0a1c4cf@localhost> Message-ID: <055.d4fa3522e7555b98e7c563c71f89342b@localhost> #2267: Bogus "unused import" warning ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by seliopou): The problem is that the {{{GlobalRdrElt}}} for {{{B.ByteString}}} has two {{{ImportSpec}}}s for its {{{Provenance}}}, only the first of which (the "wrong" one, i.e., {{{Data.ByteString.UTF8}}}) is being added to {{{minimal_imports1}}}, which is then used to construct {{{unused_imp_mods}}} in {{{reportUnusedNames}}} (rename/RnNames.lhs:1084). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 12 01:34:51 2009 From: trac at galois.com (GHC) Date: Thu Mar 12 01:23:05 2009 Subject: [GHC] #3086: Exception if temp path has national symbols Message-ID: <044.d10bb921365c2c3094ff1b6db5c35fff@localhost> #3086: Exception if temp path has national symbols -----------------------------+---------------------------------------------- Reporter: Tonal | Owner: Type: bug | Status: new Priority: normal | Component: libraries/directory Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Environment: Windows Vista Home Ru + sp1 ghc 6.10.1 Code for reproduced (file tst.hs): {{{ #!text/x-haskell import System.Directory main = do cwd <- getTemporaryDirectory putStrLn cwd setCurrentDirectory cwd }}} Console session: {{{ C:\Lang\test\haskell\????>ghc --make tst.hs [1 of 1] Compiling Main ( tst.hs, tst.o ) Linking tst.exe ... C:\Lang\test\haskell\????>set TMP=C:\Lang\test\haskell\???? C:\Lang\test\haskell\????>tst.exe C:\Lang\test\haskell\????\ tst.exe: SetCurrentDirectory: does not exist ( 5 C405BAO =09B8 C:070==K9 D09;.) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 12 01:46:01 2009 From: trac at galois.com (GHC) Date: Thu Mar 12 01:34:14 2009 Subject: [GHC] #3086: Exception if temp path has national symbols In-Reply-To: <044.d10bb921365c2c3094ff1b6db5c35fff@localhost> References: <044.d10bb921365c2c3094ff1b6db5c35fff@localhost> Message-ID: <053.ef08fdf2c30d3ad3de1efbe1b0630fd9@localhost> #3086: Exception if temp path has national symbols ---------------------------------+------------------------------------------ Reporter: Tonal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/directory | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ---------------------------------+------------------------------------------ Comment (by Tonal): see also #2963 For fixed need add getTemporaryDirectory to System/Win32/Info.hsc: {{{ diff -rN old-Win32/System/Win32/Info.hsc new-Win32/System/Win32/Info.hsc 98a99,101 > getTempPath :: IO String > getTempPath = try "GetTempPath" (flip c_getTempPath) 512 > 118a122,124 > foreign import stdcall unsafe "GetTempPathW" > c_getTempPath :: DWORD -> LPTSTR -> IO UINT > }}} And use it in System.Directories.getCurrentDirectory: {{{ diff -rN old-directory/System/Directory.hs new- directory/System/Directory.hs 1076,1078c1076 < allocaBytes long_path_size $ \pPath -> do < _r <- c_GetTempPath (fromIntegral long_path_size) pPath < peekCString pPath --- > System.Win32.getTempPath }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 12 05:29:21 2009 From: trac at galois.com (GHC) Date: Thu Mar 12 05:17:36 2009 Subject: [GHC] #3060: impossible internal bug while building darcs In-Reply-To: <044.8b050eb370b3a248f628f79a0a5b8c10@localhost> References: <044.8b050eb370b3a248f628f79a0a5b8c10@localhost> Message-ID: <053.23ed9d3a7dc0f53186e3bc07b07c4cab@localhost> #3060: impossible internal bug while building darcs -------------------------+-------------------------------------------------- Reporter: quick | Owner: Type: bug | Status: reopened Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------+-------------------------------------------------- Comment (by simonpj): Simon and I have just discussed this, and agreed that we'll change `ghc- pkg` so that it won't let you update (overwrite) a package on which other installed packages depend. That's the inconsistency that led to this bug. I'm leaving this ticket open just to remind us to complete this change. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 12 05:53:02 2009 From: trac at galois.com (GHC) Date: Thu Mar 12 05:41:21 2009 Subject: [GHC] #2785: Memory leakage with socket benchmark program In-Reply-To: <047.470588859e52453dab1b67a6015374ad@localhost> References: <047.470588859e52453dab1b67a6015374ad@localhost> Message-ID: <056.ca57627e087a680b17b2abbd295257d5@localhost> #2785: Memory leakage with socket benchmark program -----------------------------------------+---------------------------------- Reporter: felixmar | Owner: simonmar Type: run-time performance bug | Status: closed Priority: normal | Milestone: 6.10.2 Component: Runtime System | Version: 6.10.1 Severity: major | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -----------------------------------------+---------------------------------- Changes (by simonmar): * status: new => closed * resolution: => invalid Comment: I do see the process size growing in Windows, but not Linux. It still happens with the HEAD. However, I've verified that the leak is not in GHC's heap (the heap size is a constant 1MB), nor is it from calls to `malloc()`. So as far as I can tell, this must be happening in the Windows networking layer somewhere, hence I don't think there's anything we can do. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 12 06:16:20 2009 From: trac at galois.com (GHC) Date: Thu Mar 12 06:04:33 2009 Subject: [GHC] #3081: Double output after Ctrl+C on Windows In-Reply-To: <051.84cd0947da97d4cf55fa6f13b11c0732@localhost> References: <051.84cd0947da97d4cf55fa6f13b11c0732@localhost> Message-ID: <060.c7c1f528dcb4ade7c34470d340a3df43@localhost> #3081: Double output after Ctrl+C on Windows -------------------------------+-------------------------------------------- Reporter: NeilMitchell | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by simonmar): * summary: Finally run twice on Ctrl+C => Double output after Ctrl+C on Windows * milestone: 6.10.2 => _|_ Comment: Ok, this was an interesting one. In fact it has nothing to do with `finally`; the following program has the same behaviour: {{{ import System.Cmd main = system "sleep 1m" >> putStrLn "goodbye" }}} In fact it even crashed with the HEAD, but the crash was particularly fragile and most attempts to investigate it made it go away. This patch fixes the crash: {{{ Wed Mar 11 08:45:59 PDT 2009 Simon Marlow * avoid a crash: don't return unless the run queue has some threads in it }}} which Ian has already merged. However, the double-output problem still happens. It doesn't happen if you use `-threaded`. Here's what's going on: * When the user hits `^C`, the `system` call immediately returns. * The RTS spins up a thread to throw the `^C` exception to the main thread * The main thread calls `putStrLn "goodbye"` * The async IO system in the non-threaded RTS creates an OS thread to do `write(1,"goodbye\n")`, and the main thread is blocked waiting for it to complete * the write completes * The main thread receives the `Interrupted` exception. We try to abort the IO, but it has already happened. * The top-level exception handler in the main thread flushes stdout. The stdout buffer still contains "goodbye", because the first IO was interrupted, so it writes that to stdout. I don't think there's a way to fix this without serious surgery - we'd need a way to synchronously abandon an async IO request, and I don't even know if that's possible. I'll leave the bug at _|_ since it still exists, but I doubt I'll fix it. If anyone else wants to try you're more than welcome! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 12 06:18:04 2009 From: trac at galois.com (GHC) Date: Thu Mar 12 06:06:17 2009 Subject: [GHC] #3081: Double output after Ctrl+C on Windows In-Reply-To: <051.84cd0947da97d4cf55fa6f13b11c0732@localhost> References: <051.84cd0947da97d4cf55fa6f13b11c0732@localhost> Message-ID: <060.6884b6cf1795faf5d384fed7d60a6b83@localhost> #3081: Double output after Ctrl+C on Windows -------------------------------+-------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by simonmar): * owner: simonmar => -- Ticket URL: GHC The Glasgow Haskell Compiler From ndmitchell at gmail.com Thu Mar 12 06:30:04 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu Mar 12 06:18:16 2009 Subject: [GHC] #3081: Double output after Ctrl+C on Windows In-Reply-To: <060.6884b6cf1795faf5d384fed7d60a6b83@localhost> References: <051.84cd0947da97d4cf55fa6f13b11c0732@localhost> <060.6884b6cf1795faf5d384fed7d60a6b83@localhost> Message-ID: <404396ef0903120330w52e3edd6k47a3ca7b867894f2@mail.gmail.com> Hi I think I'm confused. I thought Ctrl+C was "abort the program now", so figured that foo >> bar, where foo get's a Ctrl+C means bar is never executed? The double buffering thing I can understand, but the fact that bar gets executed at all is a little confusing. What if I did: system "cp foo foo.bup" >> deleteFile "foo" If I Ctrl+C during the cp did I just delete my one copy of foo? Thanks Neil On Thu, Mar 12, 2009 at 10:18 AM, GHC wrote: > #3081: Double output after Ctrl+C on Windows > -------------------------------+-------------------------------------------- > ? ?Reporter: ?NeilMitchell ? ?| ? ? ? ?Owner: > ? ? ? ?Type: ?bug ? ? ? ? ? ? | ? ? ? Status: ?new > ? ?Priority: ?normal ? ? ? ? ?| ? ?Milestone: ?_|_ > ? Component: ?Runtime System ?| ? ? ?Version: ?6.10.1 > ? ?Severity: ?normal ? ? ? ? ?| ? Resolution: > ? ?Keywords: ? ? ? ? ? ? ? ? ?| ? Difficulty: ?Unknown > ? ?Testcase: ? ? ? ? ? ? ? ? ?| ? ? ? ? ? Os: ?Windows > Architecture: ?x86 ? ? ? ? ? ? | > -------------------------------+-------------------------------------------- > Changes (by simonmar): > > ?* owner: ?simonmar => > > -- > Ticket URL: > GHC > The Glasgow Haskell Compiler From trac at galois.com Thu Mar 12 06:34:28 2009 From: trac at galois.com (GHC) Date: Thu Mar 12 06:22:47 2009 Subject: [GHC] #2638: runInteractiveCommand on Win32 leaks, produces inconsistent behavior In-Reply-To: <043.7879ff2ec970e5670b4c9255c0e07b58@localhost> References: <043.7879ff2ec970e5670b4c9255c0e07b58@localhost> Message-ID: <052.fd08722f1df3e0980c38119426617859@localhost> #2638: runInteractiveCommand on Win32 leaks, produces inconsistent behavior ----------------------------------+----------------------------------------- Reporter: sclv | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.2 Component: libraries/process | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: vax | ----------------------------------+----------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: I believe the fix for #2992 has also fixed the leak here. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 12 07:22:30 2009 From: trac at galois.com (GHC) Date: Thu Mar 12 07:10:43 2009 Subject: [GHC] #2193: Monomorphic Pattern Bindings and Error Messages In-Reply-To: <043.34ccdeb27bebe4aa866d2df9503f28c8@localhost> References: <043.34ccdeb27bebe4aa866d2df9503f28c8@localhost> Message-ID: <052.80dbbcc18a8adf925eee395b87d93c3b@localhost> #2193: Monomorphic Pattern Bindings and Error Messages ---------------------------------+------------------------------------------ Reporter: sclv | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * owner: => igloo Comment: The HEAD now correctly says {{{ T2193.hs:9:0: Illegal polymorphic or qualified type: forall s. s Perhaps you intended to use -XImpredicativeTypes In the type signature for `bar': bar :: a -> Foo (forall s. s) a }}} If you add `-XImpredicativeTypes` then we indeed get the (silly) error message described in the original bug report, but I'm not going to fiddle with that now, because Dimitrios and I are (still) planning to rejig the entire implementation of impredicative types. So let's leave this open for that reason. IAN: I hope 6.10.2 also reports the above `Illegal polymorphic...` error. Can you check, and then bump the milestone to 6.12 and assign it to me? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 12 08:32:29 2009 From: trac at galois.com (GHC) Date: Thu Mar 12 08:20:43 2009 Subject: [GHC] #3085: warn about language extensions that are not used In-Reply-To: <051.bedfbd02c24cc787d0bf163c67d17d1e@localhost> References: <051.bedfbd02c24cc787d0bf163c67d17d1e@localhost> Message-ID: <060.2fb405b1b5dfe7778e668765133aa0d3@localhost> #3085: warn about language extensions that are not used ------------------------------------------+--------------------------------- Reporter: PVerswyvelen | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: warnings extensions language | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------------------+--------------------------------- Comment (by MartijnVanSteenbergen): No idea how to vote here, so I'll just leave a comment: +1 :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 12 08:34:53 2009 From: trac at galois.com (GHC) Date: Thu Mar 12 08:23:05 2009 Subject: [GHC] #3082: Unclear warning message: Attempting to re-export hidden constructors In-Reply-To: <042.a5c4cd3afa0abc022930d0824ba94bfa@localhost> References: <042.a5c4cd3afa0abc022930d0824ba94bfa@localhost> Message-ID: <051.84b740e12e0bce0f32b3867b10b480bc@localhost> #3082: Unclear warning message: Attempting to re-export hidden constructors ---------------------------------+------------------------------------------ Reporter: ksf | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * difficulty: => Unknown Comment: Good point. How about this? {{{ Warning: The export item `Foo(..)' suggests that `Foo' has (in-scope) constructors or class methods, but it has none }}} Note the extra `(in-scope)`. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 12 08:41:46 2009 From: trac at galois.com (GHC) Date: Thu Mar 12 08:30:08 2009 Subject: [GHC] #2395: "Pattern match(es) are overlapped" warning with a single view pattern (ghc 6.9.20080606) In-Reply-To: <047.ecbd48e54b1bf1fee3a4558a1775b513@localhost> References: <047.ecbd48e54b1bf1fee3a4558a1775b513@localhost> Message-ID: <056.a15b854de5743fde01be56b8ea531db8@localhost> #2395: "Pattern match(es) are overlapped" warning with a single view pattern (ghc 6.9.20080606) ---------------------------------+------------------------------------------ Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by mafo): * cc: fontaine@cs.uni-duesseldorf.de (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 12 08:54:17 2009 From: trac at galois.com (GHC) Date: Thu Mar 12 08:42:40 2009 Subject: [GHC] #2917: alloca and allocaArray do not respect alignment In-Reply-To: <044.ae4012da6404813e981e2064d26c5c85@localhost> References: <044.ae4012da6404813e981e2064d26c5c85@localhost> Message-ID: <053.fe7db201c1632be9c6b397615424a6d8@localhost> #2917: alloca and allocaArray do not respect alignment ---------------------------------+------------------------------------------ Reporter: guest | Owner: igloo Type: bug | Status: reopened Priority: high | Milestone: 6.12 branch Component: Compiler (FFI) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * type: merge => bug -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 12 10:07:15 2009 From: trac at galois.com (GHC) Date: Thu Mar 12 09:55:30 2009 Subject: [GHC] #3079: LANGUAGE pragma fails if it falls on a 1024-byte boundary In-Reply-To: <047.db20015538347ea9ecfd34557e791f17@localhost> References: <047.db20015538347ea9ecfd34557e791f17@localhost> Message-ID: <056.0f02862b052e0ccbff53739f036e0fe2@localhost> #3079: LANGUAGE pragma fails if it falls on a 1024-byte boundary ----------------------------------+----------------------------------------- Reporter: Deewiant | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler (Parser) | Version: 6.10.1 Severity: critical | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by simonmar): * owner: => simonmar * difficulty: => Unknown * milestone: => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 12 10:19:18 2009 From: trac at galois.com (GHC) Date: Thu Mar 12 10:07:30 2009 Subject: [GHC] #3084: alow macros to redefine builtin GHCi commands In-Reply-To: <046.7f055f7e30420d89efe3f2db433a2d00@localhost> References: <046.7f055f7e30420d89efe3f2db433a2d00@localhost> Message-ID: <055.b385c56a2250606d0dee1f14a04bfb88@localhost> #3084: alow macros to redefine builtin GHCi commands ---------------------------------+------------------------------------------ Reporter: phercek | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * difficulty: => Unknown * milestone: => 6.12 branch Comment: This is not a bugfix, so it's not suitable for 6.10.2. However we'll try to get it into 6.12. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 12 10:28:12 2009 From: trac at galois.com (GHC) Date: Thu Mar 12 10:16:28 2009 Subject: [GHC] #3086: Exception if temp path has national symbols In-Reply-To: <044.d10bb921365c2c3094ff1b6db5c35fff@localhost> References: <044.d10bb921365c2c3094ff1b6db5c35fff@localhost> Message-ID: <053.e6e98d0db57918b87a5ea8a6ddd105c6@localhost> #3086: Exception if temp path has national symbols ------------------------------------+--------------------------------------- Reporter: Tonal | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: libraries/directory | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ------------------------------------+--------------------------------------- Changes (by simonmar): * owner: => simonmar * difficulty: => Unknown * milestone: => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 12 10:33:12 2009 From: trac at galois.com (GHC) Date: Thu Mar 12 10:21:25 2009 Subject: [GHC] #3085: warn about language extensions that are not used In-Reply-To: <051.bedfbd02c24cc787d0bf163c67d17d1e@localhost> References: <051.bedfbd02c24cc787d0bf163c67d17d1e@localhost> Message-ID: <060.8e0fd544366736798c5d8b4f06651829@localhost> #3085: warn about language extensions that are not used ------------------------------------------+--------------------------------- Reporter: PVerswyvelen | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: warnings extensions language | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------------------+--------------------------------- Changes (by NeilMitchell): * cc: ndmitchell@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From marlowsd at gmail.com Thu Mar 12 10:35:50 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Mar 12 10:24:10 2009 Subject: [GHC] #3081: Double output after Ctrl+C on Windows In-Reply-To: <404396ef0903120330w52e3edd6k47a3ca7b867894f2@mail.gmail.com> References: <051.84cd0947da97d4cf55fa6f13b11c0732@localhost> <060.6884b6cf1795faf5d384fed7d60a6b83@localhost> <404396ef0903120330w52e3edd6k47a3ca7b867894f2@mail.gmail.com> Message-ID: <49B91DC6.8060803@gmail.com> Neil Mitchell wrote: > I think I'm confused. I thought Ctrl+C was "abort the program now", so > figured that foo >> bar, where foo get's a Ctrl+C means bar is never > executed? The double buffering thing I can understand, but the fact > that bar gets executed at all is a little confusing. > > What if I did: > > system "cp foo foo.bup" >> deleteFile "foo" > > If I Ctrl+C during the cp did I just delete my one copy of foo? On Windows, Ctrl-C will unblock a blocked system call. e.g. read() returns with zero. Apparently system "foo" also returns as soon as you press Ctrl-C, I'm not entirely sure why. Perhaps because the program has been killed? Cheers, Simon > Thanks > > Neil > > On Thu, Mar 12, 2009 at 10:18 AM, GHC wrote: >> #3081: Double output after Ctrl+C on Windows >> -------------------------------+-------------------------------------------- >> Reporter: NeilMitchell | Owner: >> Type: bug | Status: new >> Priority: normal | Milestone: _|_ >> Component: Runtime System | Version: 6.10.1 >> Severity: normal | Resolution: >> Keywords: | Difficulty: Unknown >> Testcase: | Os: Windows >> Architecture: x86 | >> -------------------------------+-------------------------------------------- >> Changes (by simonmar): >> >> * owner: simonmar => >> >> -- >> Ticket URL: >> GHC >> The Glasgow Haskell Compiler > _______________________________________________ > Glasgow-haskell-bugs mailing list > Glasgow-haskell-bugs@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Thu Mar 12 10:37:35 2009 From: trac at galois.com (GHC) Date: Thu Mar 12 10:25:51 2009 Subject: [GHC] #3085: warn about language extensions that are not used In-Reply-To: <051.bedfbd02c24cc787d0bf163c67d17d1e@localhost> References: <051.bedfbd02c24cc787d0bf163c67d17d1e@localhost> Message-ID: <060.139a26c250f2ea8a58ff66dde92922a4@localhost> #3085: warn about language extensions that are not used ------------------------------------------+--------------------------------- Reporter: PVerswyvelen | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: warnings extensions language | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------------------+--------------------------------- Changes (by igel): * cc: deduktionstheorem@web.de (added) Comment: dito, +1 :) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 12 10:55:37 2009 From: trac at galois.com (GHC) Date: Thu Mar 12 10:43:51 2009 Subject: [GHC] #3085: warn about language extensions that are not used In-Reply-To: <051.bedfbd02c24cc787d0bf163c67d17d1e@localhost> References: <051.bedfbd02c24cc787d0bf163c67d17d1e@localhost> Message-ID: <060.64b5f5c60e83ffda9de7af66506fc689@localhost> #3085: warn about language extensions that are not used ---------------------------------------------+------------------------------ Reporter: PVerswyvelen | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: warnings extensions language | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------------------+------------------------------ Changes (by simonmar): * difficulty: => Unknown Comment: While I agree this would be very cool, it's very difficult to implement and get right. In fact the only reasonable implementation I can think of is to remove extensions one at a time and check whether the compilation output was the same, but that ignores relationships between extensions (e.g. it might be ok to remove both A and B, but not either A or B. I'm not sure if we have any of those.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 12 11:05:29 2009 From: trac at galois.com (GHC) Date: Thu Mar 12 10:53:41 2009 Subject: [GHC] #3085: warn about language extensions that are not used In-Reply-To: <051.bedfbd02c24cc787d0bf163c67d17d1e@localhost> References: <051.bedfbd02c24cc787d0bf163c67d17d1e@localhost> Message-ID: <060.70488ecd7e3f77b9359956875bf453a3@localhost> #3085: warn about language extensions that are not used ---------------------------------------------+------------------------------ Reporter: PVerswyvelen | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: warnings extensions language | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------------------+------------------------------ Comment (by simonpj): For the most part, the fact that GHC ''consults'' a flag is enough to indicate that changing its state would affect compilation. (That's not quite true -- in some places we read flags and pass on a couple of booleans that may or may not be needed -- but it is largely true.) So while it's not entirely trivial, I suspect we could get close to what you want, at least for the language extensions. If someone wants to volunteer to do this, I can advise. Unless I'm missing something. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 12 11:06:00 2009 From: trac at galois.com (GHC) Date: Thu Mar 12 10:54:12 2009 Subject: [GHC] #2763: while installing cabal from darcs, 1.6.0.1 and 1.4.0.2 In-Reply-To: <044.967654beccd358d1d0ac92f7259473da@localhost> References: <044.967654beccd358d1d0ac92f7259473da@localhost> Message-ID: <053.6cd48b51319c3af306f4b20e3387be3a@localhost> #2763: while installing cabal from darcs, 1.6.0.1 and 1.4.0.2 ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: duplicate Keywords: cabal ghc ubuntu | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => duplicate Comment: Probably the same as #3060, which has more background. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 12 11:09:41 2009 From: trac at galois.com (GHC) Date: Thu Mar 12 10:57:54 2009 Subject: [GHC] #3085: warn about language extensions that are not used In-Reply-To: <051.bedfbd02c24cc787d0bf163c67d17d1e@localhost> References: <051.bedfbd02c24cc787d0bf163c67d17d1e@localhost> Message-ID: <060.f4a3b0a8d9326d0ae8a19e9cd6bb81d2@localhost> #3085: warn about language extensions that are not used ---------------------------------------------+------------------------------ Reporter: PVerswyvelen | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: warnings extensions language | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------------------+------------------------------ Comment (by MartijnVanSteenbergen): I can imagine it depends entirely on the specific flag. GeneralizedNewtypeDeriving seems easy enough. RelaxedPolyRec on the other hand... I think warnings for the easier ones is already awesome. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 12 11:15:12 2009 From: trac at galois.com (GHC) Date: Thu Mar 12 11:03:25 2009 Subject: [GHC] #3079: LANGUAGE pragma fails if it falls on a 1024-byte boundary In-Reply-To: <047.db20015538347ea9ecfd34557e791f17@localhost> References: <047.db20015538347ea9ecfd34557e791f17@localhost> Message-ID: <056.9bb72a87dccace27dd7b8789b380f2e4@localhost> #3079: LANGUAGE pragma fails if it falls on a 1024-byte boundary ----------------------------------+----------------------------------------- Reporter: Deewiant | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler (Parser) | Version: 6.10.1 Severity: critical | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: Fixed: {{{ Thu Mar 12 14:11:03 GMT 2009 Simon Marlow * FIX #3079, dodgy parsing of LANGUAGE pragmas I ended up rewriting this horrible bit of code, using (yikes) lazy I/O to slurp in the source file a chunk at a time. The old code tried to read the file a chunk at a time, but failed with LANGUAGE pragmas because the parser for LANGUAGE has state and the state wasn't being saved between chunks. We're still closing the Handle eagerly, so there shouldn't be any problems here. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 12 12:05:55 2009 From: trac at galois.com (GHC) Date: Thu Mar 12 11:54:18 2009 Subject: [GHC] #3085: warn about language extensions that are not used In-Reply-To: <051.bedfbd02c24cc787d0bf163c67d17d1e@localhost> References: <051.bedfbd02c24cc787d0bf163c67d17d1e@localhost> Message-ID: <060.b1edd743eaef82e68faade6424ee5ea4@localhost> #3085: warn about language extensions that are not used ---------------------------------------------+------------------------------ Reporter: PVerswyvelen | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: warnings extensions language | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------------------+------------------------------ Changes (by conal): * cc: conal@conal.net (added) Comment: I'd love to have this warning also. I go back every so often and try removing each of the extensions listed in my LANGUAGE pragma. It hadn't occurred to me that the compiler could be doing this job. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 12 12:32:43 2009 From: trac at galois.com (GHC) Date: Thu Mar 12 12:21:01 2009 Subject: [GHC] #3085: warn about language extensions that are not used In-Reply-To: <051.bedfbd02c24cc787d0bf163c67d17d1e@localhost> References: <051.bedfbd02c24cc787d0bf163c67d17d1e@localhost> Message-ID: <060.5e9ca68c5b30cb3e39179adde9eac40c@localhost> #3085: warn about language extensions that are not used ---------------------------------------------+------------------------------ Reporter: PVerswyvelen | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: warnings extensions language | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------------------+------------------------------ Comment (by dons): Seems better suited to a separate 'lint' tool to sanitize .cabal files / pragma use and other common issues. No need to bake it into the compiler, given the implementation problems. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 12 12:39:22 2009 From: trac at galois.com (GHC) Date: Thu Mar 12 12:27:38 2009 Subject: [GHC] #3085: warn about language extensions that are not used In-Reply-To: <051.bedfbd02c24cc787d0bf163c67d17d1e@localhost> References: <051.bedfbd02c24cc787d0bf163c67d17d1e@localhost> Message-ID: <060.d8343cfaa9ed4e3abeb4749d1aa1e9e0@localhost> #3085: warn about language extensions that are not used ---------------------------------------------+------------------------------ Reporter: PVerswyvelen | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: warnings extensions language | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------------------+------------------------------ Comment (by simonmar): Replying to [comment:5 simonpj]: > For the most part, the fact that GHC ''consults'' a flag is enough to indicate that changing its state would affect compilation. (That's not quite true -- in some places we read flags and pass on a couple of booleans that may or may not be needed -- but it is largely true.) > > So while it's not entirely trivial, I suspect we could get close to what you want, at least for the language extensions. If someone wants to volunteer to do this, I can advise. Unless I'm missing something. Perhaps I'm being pessimistic, but I have a bad feeling about this if we have to implement it for every language extension, everywhere that language extension is used. It'll give rise to a slew of bug reports for the places we don't quite get it right. This is a feature that requires changes all over the compiler, and introduces a new tax on language extensions. In contrast, the "try removing the extension and see if it still works" method is foolproof and doesn't require any changes to the compiler. Someone could implement that using the GHC API... -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 12 12:45:35 2009 From: trac at galois.com (GHC) Date: Thu Mar 12 12:33:47 2009 Subject: [GHC] #3086: Exception if temp path has national symbols In-Reply-To: <044.d10bb921365c2c3094ff1b6db5c35fff@localhost> References: <044.d10bb921365c2c3094ff1b6db5c35fff@localhost> Message-ID: <053.914e20ff36bdef353f54b7929fe50214@localhost> #3086: Exception if temp path has national symbols ------------------------------------+--------------------------------------- Reporter: Tonal | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.2 Component: libraries/directory | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ------------------------------------+--------------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: Fixed; thanks. libraries/Win32: {{{ Thu Mar 12 16:14:27 GMT 2009 Simon Marlow * provide getTemporaryDirectory }}} libraries/directory: {{{ Thu Mar 12 16:14:08 GMT 2009 Simon Marlow * FIX #3086: use System.Win32.getTemporaryDirectory }}} Ian, if we want to merge this, it's the same deal as before - add the Win32 bits to `System.Directory`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 12 12:56:49 2009 From: trac at galois.com (GHC) Date: Thu Mar 12 12:45:03 2009 Subject: [GHC] #3085: warn about language extensions that are not used In-Reply-To: <051.bedfbd02c24cc787d0bf163c67d17d1e@localhost> References: <051.bedfbd02c24cc787d0bf163c67d17d1e@localhost> Message-ID: <060.b16663145585756cf710b97888cf200b@localhost> #3085: warn about language extensions that are not used ---------------------------------------------+------------------------------ Reporter: PVerswyvelen | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: warnings extensions language | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------------------+------------------------------ Comment (by simonpj): The most common way to consult the flags is thus: {{{ dopt :: DynFlag -> Tc Bool }}} What I was suggesting is that `dopt` could record on the side that the flag was consulted. The tax is in `dopt` only. Not all flags are consulted in this way, but most are. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 12 13:55:20 2009 From: trac at galois.com (GHC) Date: Thu Mar 12 13:43:54 2009 Subject: [GHC] #3085: warn about language extensions that are not used In-Reply-To: <051.bedfbd02c24cc787d0bf163c67d17d1e@localhost> References: <051.bedfbd02c24cc787d0bf163c67d17d1e@localhost> Message-ID: <060.278b3b05734f851308c0b8d9b6d14648@localhost> #3085: warn about language extensions that are not used ---------------------------------------------+------------------------------ Reporter: PVerswyvelen | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: warnings extensions language | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------------------+------------------------------ Changes (by guest): * cc: id@isaac.cedarswampstudios.org (added) Comment: Replying to [comment:9 simonmar]: > In contrast, the "try removing the extension and see if it still works" method is foolproof and doesn't require any changes to the compiler. Someone could implement that using the GHC API... I'm not so sure that it's foolproof. For example Template-Haskell can change the meaning of programs {{{ foo = bar $(baz) -- ($) or TH? }}} but they still may compile; and there are probably more subtle extensions with meaning-changes. Perhaps you can avoid that issue by comparing the output to make sure it's exactly the same. But I've heard that GHC is not designed to be deterministic (that it sometimes produces different ABIs from the same source-code and options), so I guess that wouldn't even work. However we know, as a conservative estimate, that if an extension flag is not even consulted, then the extension must not have been used; so GHC could warn sometimes. (Although the merits of having an "unreliable" warning like this may be in question.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 12 14:39:45 2009 From: trac at galois.com (GHC) Date: Thu Mar 12 14:28:23 2009 Subject: [GHC] #3085: warn about language extensions that are not used In-Reply-To: <051.bedfbd02c24cc787d0bf163c67d17d1e@localhost> References: <051.bedfbd02c24cc787d0bf163c67d17d1e@localhost> Message-ID: <060.ba6cd6297f0209cbb70c071efd058ae4@localhost> #3085: warn about language extensions that are not used ---------------------------------------------+------------------------------ Reporter: PVerswyvelen | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: warnings extensions language | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------------------+------------------------------ Comment (by augustss): What I usually do by hand is to remove the extensions one by one and see if it still compiles. As Simon M says, this is a way to implement it. And I think it's a perfectly fine way. It would save me doing it by hand. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 12 14:46:14 2009 From: trac at galois.com (GHC) Date: Thu Mar 12 14:34:35 2009 Subject: [GHC] #2673: FreeBSD built-in libedit is not compatible with GHC In-Reply-To: <048.a7a8b8cd246f16f4f13f2f8936382c3e@localhost> References: <048.a7a8b8cd246f16f4f13f2f8936382c3e@localhost> Message-ID: <057.0df0b0af09ec02b33ca62b48b565564c@localhost> #2673: FreeBSD built-in libedit is not compatible with GHC --------------------------+------------------------------------------------- Reporter: gmainland | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: FreeBSD Architecture: x86 | --------------------------+------------------------------------------------- Comment (by gmainland): This worked for me, and I think it's the proper solution: {{{ # ./configure EDITLINE_LDFLAGS=-Wl,-rpath,/usr/local/lib \ --with-editline-includes=/usr/local/include \ --with-editline-libraries=/usr/local/lib }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 12 17:35:58 2009 From: trac at galois.com (GHC) Date: Thu Mar 12 17:24:14 2009 Subject: [GHC] #2316: Add Applicative instances for all MTL Monads In-Reply-To: <047.6c77bc0cfe5b195806e995b0a81d8474@localhost> References: <047.6c77bc0cfe5b195806e995b0a81d8474@localhost> Message-ID: <056.6c812486de79f06ef279221564cfe1df@localhost> #2316: Add Applicative instances for all MTL Monads ----------------------------------+----------------------------------------- Reporter: sjanssen | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by PVerswyvelen): * cc: bugfact@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 12 18:13:08 2009 From: trac at galois.com (GHC) Date: Thu Mar 12 18:01:32 2009 Subject: [GHC] #3085: warn about language extensions that are not used In-Reply-To: <051.bedfbd02c24cc787d0bf163c67d17d1e@localhost> References: <051.bedfbd02c24cc787d0bf163c67d17d1e@localhost> Message-ID: <060.e05391105ab30188f624ba40460225f2@localhost> #3085: warn about language extensions that are not used ---------------------------------------------+------------------------------ Reporter: PVerswyvelen | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: warnings extensions language | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------------------+------------------------------ Comment (by simonmar): Replying to [comment:10 simonpj]: > The most common way to consult the flags is thus: > {{{ > dopt :: DynFlag -> Tc Bool > }}} > What I was suggesting is that `dopt` could record on the side that the flag was consulted. The tax is in `dopt` only. > > Not all flags are consulted in this way, but most are. Yes, for some flags it's easy. But there are some that aren't at all easy - just looking down the list I see NoMonomorphismRestriction, NoImplicitPrelude, NoMonoPatBinds, ExtendedDefaultRules, RelaxedPolyRec, CPP, OverloadedStringLiterals, and the ones that affect the lexer are not so straightforward. So the question is whether it's worthwhile to just do the easy ones. We'd have to clearly document the flags to which the warning doesn't apply. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 12 18:14:02 2009 From: trac at galois.com (GHC) Date: Thu Mar 12 18:02:28 2009 Subject: [GHC] #2063: x86_64: RTS linker depends on working MAP_32BIT In-Reply-To: <043.15abf9ca319b437728a2421245ad0407@localhost> References: <043.15abf9ca319b437728a2421245ad0407@localhost> Message-ID: <052.c24b1476d726565f9d53e0d9e005aabe@localhost> #2063: x86_64: RTS linker depends on working MAP_32BIT -------------------------------+-------------------------------------------- Reporter: dons | Owner: Type: task | Status: new Priority: high | Milestone: 6.10.2 Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: OpenBSD, Xen | Difficulty: Moderate (1 day) Testcase: | Os: Unknown/Multiple Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Comment (by tbh): I can confirm that this is fixed for me on Linux x86_64 under Xen as of 6.11.20090312. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 12 18:24:47 2009 From: trac at galois.com (GHC) Date: Thu Mar 12 18:13:04 2009 Subject: [GHC] #3060: impossible internal bug while building darcs In-Reply-To: <044.8b050eb370b3a248f628f79a0a5b8c10@localhost> References: <044.8b050eb370b3a248f628f79a0a5b8c10@localhost> Message-ID: <053.737bdfac816bf04175ce8684972c65da@localhost> #3060: impossible internal bug while building darcs -------------------------+-------------------------------------------------- Reporter: quick | Owner: Type: bug | Status: reopened Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------+-------------------------------------------------- Comment (by quick): Thanks, that third-rail protection will be useful. [As background, I had done the GHC upgrade and was just iterating through the list of packages I'd previously installed to re-install for the upgrade. I suspect this isn't an uncommon practice.] Just a few small concerns about your intended fix (probably mostly based on my ghc-pkg ignorance): - If a new version of a valid package comes out, how can I upgrade if the old version has dependencies? Will ghc-pkg allow multiple installations with separate versions? Do I have to uninstall all the dependent versions before upgrading? - Is there a differentiation between user-added packages and packages that are part of the GHC distribution? For example, if I had "uninstalled" the unix package (and its deps?) before trying to install my own-built version, would I have had the same problem? Should it be that ghc-pkg never allows one to uninstall or otherwise modify a package that is part of the distribution? Thanks again, Kevin -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 13 04:42:09 2009 From: trac at galois.com (GHC) Date: Fri Mar 13 04:30:22 2009 Subject: [GHC] #3087: Derived instances of Data lack dataCast1 and dataCast2 Message-ID: <046.252744cf7f23842ae74b0d5859123a2a@localhost> #3087: Derived instances of Data lack dataCast1 and dataCast2 -----------------------------+---------------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- In the following code snippet: {{{ data MyMaybe a = MyNothing | MyJust a deriving (Data, Typeable) test1 :: () test1 = undefined `ext1Q` (\ (Just _) -> ()) $ Just () test1' :: () test1' = undefined `ext1Q` (\ (MyJust _) -> ()) $ MyJust () }}} test1 evaluates to () as expected, but test1' evaluates to bottom. The same happens for dataypes of kind * -> * -> *: {{{ newtype Q r a = Q { unQ :: a -> r } ext2Q :: (Data d, Typeable2 t) => (d -> q) -> (forall d1 d2. (Data d1, Data d2) => t d1 d2 -> q) -> d -> q ext2Q def ext arg = case dataCast2 (Q ext) of Just (Q ext') -> ext' arg Nothing -> def arg data MyPair a b = MyPair a b deriving (Data, Typeable) test2 :: () test2 = undefined `ext2Q` (\(_,_) -> ()) $ ((),()) test2' :: () test2' = undefined `ext2Q` (\(MyPair _ _) -> ()) $ MyPair () () }}} test2 evaluates to () as expected, but test2' evaluates to bottom. Note that we need to define ext2Q, which uses dataCast2. ext1Q, which is defined in the library, uses dataCast1. This happens because the derived Data instances for !MyMaybe and !MyPair are missing a definition for dataCast1 and dataCast2, respectively. The Data instances for Maybe and (,) are: {{{ instance Data a => Data (Maybe a) where ... dataCast1 f = gcast1 f instance (Data a, Data b) => Data (a,b) where ... dataCast2 f = gcast2 f }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 13 04:49:53 2009 From: trac at galois.com (GHC) Date: Fri Mar 13 04:38:15 2009 Subject: [GHC] #2063: x86_64: RTS linker depends on working MAP_32BIT In-Reply-To: <043.15abf9ca319b437728a2421245ad0407@localhost> References: <043.15abf9ca319b437728a2421245ad0407@localhost> Message-ID: <052.62cf40c22ef6f137bf7032b3128a88b7@localhost> #2063: x86_64: RTS linker depends on working MAP_32BIT -------------------------------+-------------------------------------------- Reporter: dons | Owner: Type: task | Status: new Priority: high | Milestone: 6.10.2 Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: OpenBSD, Xen | Difficulty: Moderate (1 day) Testcase: | Os: Unknown/Multiple Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Comment (by simonmar): Replying to [comment:23 tbh]: > I can confirm that this is fixed for me on Linux x86_64 under Xen as of 6.11.20090312. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 13 07:29:44 2009 From: trac at galois.com (GHC) Date: Fri Mar 13 07:17:54 2009 Subject: [GHC] #1887: internal error while running parallel program In-Reply-To: <042.6e0c34c36411842a56980d14ccd17967@localhost> References: <042.6e0c34c36411842a56980d14ccd17967@localhost> Message-ID: <051.a06030e3387731de212828c5550de03a@localhost> #1887: internal error while running parallel program -------------------------------------+-------------------------------------- Reporter: mrd | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Runtime System | Version: 6.9 Severity: normal | Resolution: worksforme Keywords: sanity error threads | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------------+-------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => worksforme Comment: Manuel Chakravarty says: The program isn't really NDP program. It uses unboxed arrays from the old ndp package, but I don't see why it wouldn't just use unboxed arrays or the uvector/vector package. In fact, the combination of distributed arrays from the old NDP package together with strategies makes no sense whatsoever. mrd, could you update the program and try again? As I reported above, I wasn't able to reproduce the problem here. (closing as worksforme for now, re-open if you can reproduce the problem using up-to-date libraries and GHC). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 13 08:32:51 2009 From: trac at galois.com (GHC) Date: Fri Mar 13 08:21:02 2009 Subject: [GHC] #592: signal handlers should be able to access siginfo_t information In-Reply-To: <047.44a80ef10278cacddbca83ff583da267@localhost> References: <047.44a80ef10278cacddbca83ff583da267@localhost> Message-ID: <056.4f821d302912f735bbe4c1f2508933fa@localhost> #592: signal handlers should be able to access siginfo_t information ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: libraries/unix | Version: 6.4.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: N/A | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 13 08:41:50 2009 From: trac at galois.com (GHC) Date: Fri Mar 13 08:30:04 2009 Subject: [GHC] #1986: runhaskell doesn't have a --version option In-Reply-To: <042.44d90b1d57525d17b12ffab59d5bba78@localhost> References: <042.44d90b1d57525d17b12ffab59d5bba78@localhost> Message-ID: <051.3e8b7611cee438bfdfe910d9e8bed3f1@localhost> #1986: runhaskell doesn't have a --version option ---------------------------------+------------------------------------------ Reporter: tim | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: minor | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => duplicate Comment: See #2757 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 13 08:44:49 2009 From: trac at galois.com (GHC) Date: Fri Mar 13 08:33:01 2009 Subject: [GHC] #2116: ghci should try to read erroneous modules partially In-Reply-To: <049.057d3d778b5cc727821ad8871b5a5e34@localhost> References: <049.057d3d778b5cc727821ad8871b5a5e34@localhost> Message-ID: <058.bfb182563608d8482c025a47436627f5@localhost> #2116: ghci should try to read erroneous modules partially ---------------------------------+------------------------------------------ Reporter: j.waldmann | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: reopened => closed * resolution: => duplicate Comment: See #1341 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 13 08:47:51 2009 From: trac at galois.com (GHC) Date: Fri Mar 13 08:36:41 2009 Subject: [GHC] #1895: Allow aliases in GHCi module imports In-Reply-To: <044.6ecaa12d10d2acbb79232cbf02108989@localhost> References: <044.6ecaa12d10d2acbb79232cbf02108989@localhost> Message-ID: <053.04c8f28fdb892be9ec7e7cfc350d25dd@localhost> #1895: Allow aliases in GHCi module imports ---------------------------------+------------------------------------------ Reporter: tibbe | Owner: Type: feature request | Status: new Priority: high | Milestone: 6.10 branch Component: GHCi | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): This would be subsumed by [[TicketQuery(id=2362|0)]]. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 13 09:05:03 2009 From: trac at galois.com (GHC) Date: Fri Mar 13 08:53:14 2009 Subject: [GHC] #907: Case sensitive ghci commands In-Reply-To: <058.4e67421e94a7459b62b3dc5e5c82730f@localhost> References: <058.4e67421e94a7459b62b3dc5e5c82730f@localhost> Message-ID: <067.f6c0adaae778fe5fdbf08485f9fe32b2@localhost> #907: Case sensitive ghci commands ------------------------------------+--------------------------------------- Reporter: br1@internet.com.uy | Owner: Type: feature request | Status: closed Priority: lowest | Milestone: _|_ Component: GHCi | Version: 6.4.1 Severity: trivial | Resolution: wontfix Keywords: case command colon | Difficulty: Easy (1 hr) Testcase: N/A | Os: Unknown/Multiple Architecture: Unknown/Multiple | ------------------------------------+--------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => wontfix Comment: Making an executive decision here. If you want this, then use `:def R`, for example. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 13 09:19:59 2009 From: trac at galois.com (GHC) Date: Fri Mar 13 09:08:11 2009 Subject: [GHC] #3087: Derived instances of Data lack dataCast1 and dataCast2 In-Reply-To: <046.252744cf7f23842ae74b0d5859123a2a@localhost> References: <046.252744cf7f23842ae74b0d5859123a2a@localhost> Message-ID: <055.00a56514be476655efb7305a8e3ea7f3@localhost> #3087: Derived instances of Data lack dataCast1 and dataCast2 ---------------------------------+------------------------------------------ Reporter: dreixel | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * owner: => simonpj * difficulty: => Unknown Comment: I'm fixing this (easy). Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 13 09:30:39 2009 From: trac at galois.com (GHC) Date: Fri Mar 13 09:18:51 2009 Subject: [GHC] #2673: FreeBSD built-in libedit is not compatible with GHC In-Reply-To: <048.a7a8b8cd246f16f4f13f2f8936382c3e@localhost> References: <048.a7a8b8cd246f16f4f13f2f8936382c3e@localhost> Message-ID: <057.56a5fc4b06321aa4fdf5d3bd6ec6f7ac@localhost> #2673: FreeBSD built-in libedit is not compatible with GHC --------------------------+------------------------------------------------- Reporter: gmainland | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.9 Severity: normal | Resolution: worksforme Keywords: | Difficulty: Unknown Testcase: | Os: FreeBSD Architecture: x86 | --------------------------+------------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => worksforme Comment: Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 13 09:56:18 2009 From: trac at galois.com (GHC) Date: Fri Mar 13 09:44:29 2009 Subject: [GHC] #3087: Derived instances of Data lack dataCast1 and dataCast2 In-Reply-To: <046.252744cf7f23842ae74b0d5859123a2a@localhost> References: <046.252744cf7f23842ae74b0d5859123a2a@localhost> Message-ID: <055.c92ddd2abd8670fee8855563af0972db@localhost> #3087: Derived instances of Data lack dataCast1 and dataCast2 ---------------------------------+------------------------------------------ Reporter: dreixel | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: Fixed by {{{ Fri Mar 13 13:44:36 GMT 2009 simonpj@microsoft.com * Fix Trac #3087: derived Data now defines dataCast1/2 This patch generates code in deriving(Data) for dataCast1 or 2 as appropriate. While I was there I did some refactoring (of course), pulling out the TcDeriv.inferConstraints as a separate function. }}} I don't think it's worth merging this to 6.10.2, even though it's a bugfix, because it modifies code that I added in the HEAD only (for deriving Functor) so the merge will be sligtly awkward. And there's an easy workaround. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 13 09:56:32 2009 From: trac at galois.com (GHC) Date: Fri Mar 13 09:44:41 2009 Subject: [GHC] #3087: Derived instances of Data lack dataCast1 and dataCast2 In-Reply-To: <046.252744cf7f23842ae74b0d5859123a2a@localhost> References: <046.252744cf7f23842ae74b0d5859123a2a@localhost> Message-ID: <055.d8b9c571b2721b63def590de1158cb06@localhost> #3087: Derived instances of Data lack dataCast1 and dataCast2 ------------------------------------------+--------------------------------- Reporter: dreixel | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: deriving/should_run/T3087 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ------------------------------------------+--------------------------------- Changes (by simonpj): * testcase: => deriving/should_run/T3087 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 13 09:57:49 2009 From: trac at galois.com (GHC) Date: Fri Mar 13 09:45:59 2009 Subject: [GHC] #3045: GHCI Crashes Under Windows when loading compiled code In-Reply-To: <045.753f237853c90b31fef839a556ac402c@localhost> References: <045.753f237853c90b31fef839a556ac402c@localhost> Message-ID: <054.21410a021aa424f32a7d37653b28f4fc@localhost> #3045: GHCI Crashes Under Windows when loading compiled code -------------------------+-------------------------------------------------- Reporter: jburck | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by simonmar): * difficulty: => Unknown Comment: Is this possibly the same as this? [[TicketQuery(id=2973|0)]] If not, could you give more details? Provide the source file(s) that you used, and the exact sequence of commands required to reproduce the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 13 10:34:20 2009 From: trac at galois.com (GHC) Date: Fri Mar 13 10:22:28 2009 Subject: [GHC] #3088: have ghc-pkg print less useless info when registering Message-ID: <045.a08b0a44980955bc3fea79b4658f5193@localhost> #3088: have ghc-pkg print less useless info when registering -----------------------------+---------------------------------------------- Reporter: duncan | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- This is just the ghc part of [http://hackage.haskell.org/trac/hackage/ticket/487 Cabal ticket #487], "print less useless info during builds". {{{ Useless: Reading package info from "dist/installed-pkg-config" ... done. Writing new package config file... done. This message is generated by ghc-pkg. We should patch ghc-pkg to not be so verbose by default. That message is only needed at a higher verbosity level. }}} Actually what's missing is any notion of verbosity in ghc-pkg. It doesn't matter so much what the default verbosity level is as long as Cabal can tell ghc-pkg to be quiet by default. Of course we still want to know about errors, warnings etc. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 13 10:39:24 2009 From: trac at galois.com (GHC) Date: Fri Mar 13 10:27:32 2009 Subject: [GHC] #3089: Sanity checker false positive (presumably) Message-ID: <044.7c0b171724271f62443ee855d47aa195@localhost> #3089: Sanity checker false positive (presumably) -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- When trying to debug an unrelated problem, I found a Sanity Checker failure. Initially I though this was my bug, but it remained after I left the bug. I stripped the program right down to a minimal example which still causes sanity check failures. {{{ import Graphics.Rendering.OpenGL import Graphics.UI.GLUT main = do (progName,args) <- getArgsAndInitialize createWindow progName displayCallback $= display display display = color $ Color4 1 0 0 (1::GLfloat) {- On my machine this reliably trips the sanity checker: jules$ ghc -debug -fforce-recomp --make sanityminimal.hs && ./sanityminimal +RTS -DS [1 of 1] Compiling Main ( sanityminimal.hs, sanityminimal.o ) Linking sanityminimal ... sanityminimal: internal error: ASSERTION FAILED: file Sanity.c, line 241 (GHC version 6.8.3 for i386_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Abort trap -} }}} I am running 6.8.3 here but I got someone to test 6.10.1 with the same result. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 13 10:41:24 2009 From: trac at galois.com (GHC) Date: Fri Mar 13 10:29:34 2009 Subject: [GHC] #1467: GHC API: expose separate compilation stages In-Reply-To: <047.d7c1a2808de3a4b26cf0a0e5a5797905@localhost> References: <047.d7c1a2808de3a4b26cf0a0e5a5797905@localhost> Message-ID: <056.ce2785b437d0af20696078c119e02e14@localhost> #1467: GHC API: expose separate compilation stages ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: nominolo Type: task | Status: closed Priority: normal | Milestone: 6.10 branch Component: GHC API | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Moderate (1 day) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by nominolo): * status: new => closed * resolution: => fixed Comment: We do have separate access to the front-end passes, now. It would be better to have a separate ticket for further access to compiler phases, or requests for improvements in the current implementation. Closing ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 13 10:51:13 2009 From: trac at galois.com (GHC) Date: Fri Mar 13 10:39:22 2009 Subject: [GHC] #3089: Sanity checker false positive (presumably) In-Reply-To: <044.7c0b171724271f62443ee855d47aa195@localhost> References: <044.7c0b171724271f62443ee855d47aa195@localhost> Message-ID: <053.988d3530003ed986d062bd4958b82271@localhost> #3089: Sanity checker false positive (presumably) ------------------------------+--------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by JulesBean): * cc: JulesBean (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 13 11:03:31 2009 From: trac at galois.com (GHC) Date: Fri Mar 13 10:51:42 2009 Subject: [GHC] #3090: ghc-pkg update should fail if dependent packages might break Message-ID: <047.bbfd47d98ad2aecd41c60e5c078d3f61@localhost> #3090: ghc-pkg update should fail if dependent packages might break -------------------------------+-------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- If a package is recompiled and re-installed, and other packages depend on it, those packages might be broken; e.g. see #3060. Hence `ghc-pkg update` should refuse to perform the update, unless explicitly overridden with `--force`. However, it's not quite as simple as that: * The package might already have been installed over the top of the old one, and it's too late to reverse that. * `cabal-install` likes to build and install a bunch of packages at the same time, using `ghc-pkg update` on each one. This will fail. * The GHC build system uses `ghc-pkg update` to register packages, and this breaks when packages are re-built (it's ok for a clean build, though). I've attached a couple of patches to implement it, but let's hold these back until the above issues are sorted out. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 13 11:06:40 2009 From: trac at galois.com (GHC) Date: Fri Mar 13 10:54:50 2009 Subject: [GHC] #3060: impossible internal bug while building darcs In-Reply-To: <044.8b050eb370b3a248f628f79a0a5b8c10@localhost> References: <044.8b050eb370b3a248f628f79a0a5b8c10@localhost> Message-ID: <053.faf688f09b95acdc46691138a4ca97e3@localhost> #3060: impossible internal bug while building darcs -------------------------+-------------------------------------------------- Reporter: quick | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: minor | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by simonmar): * status: reopened => closed * resolution: => invalid Comment: Replying to [comment:10 simonpj]: > Simon and I have just discussed this, and agreed that we'll change `ghc- pkg` so that it won't let you update (overwrite) a package on which other installed packages depend. That's the inconsistency that led to this bug. > > I'm leaving this ticket open just to remind us to complete this change. New ticket opened for fixing ghc-pkg: #3090 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 13 11:13:09 2009 From: trac at galois.com (GHC) Date: Fri Mar 13 11:01:18 2009 Subject: [GHC] #3091: With Python 2.5.1c1, validate ends "... runtests.py ... ValueError: invalid literal for int() with base 10: '1c1'" Message-ID: <050.5a9df3553657e07ae53a66b55449ea01@localhost> #3091: With Python 2.5.1c1, validate ends "... runtests.py ... ValueError: invalid literal for int() with base 10: '1c1'" -----------------------------+---------------------------------------------- Reporter: thorkilnaur | Owner: Type: bug | Status: new Priority: normal | Component: Test Suite Version: 6.11 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Running validate on a recent HEAD with {{{ $ uname -a Linux tn14 2.6.20-15-generic #2 SMP Sun Apr 15 07:36:31 UTC 2007 i686 GNU/Linux $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.8.2 $ python --version Python 2.5.1c1 $ }}} results in {{{ python ../../driver/runtests.py -e ghc_with_native_codegen=1 -e ghc_with_profiling=0 -e ghc_with_threaded_rts=1 -e ghc_with_interpreter=1 -e ghc_unregisterised=0 -e ghc_with_smp=1 --threads=2 --rootdir=. --config=../../config/ghc -e config.confdir=\"../../config\" -e config.compiler=\"/home/tn/tn/GHCDarcsRepository/ghc-HEAD-complete-based- on-ghc-HEAD-2009-01-09-ghc-corelibs-testsuite/ghc/ghc/stage2-inplace/ghc\" -e config.compiler_always_flags.append"(\"\")" -e config.ghc_pkg=\"/home/tn/tn/GHCDarcsRepository/ghc-HEAD-complete-based- on-ghc-HEAD-2009-01-09-ghc-corelibs-testsuite/ghc/utils/ghc-pkg/install- inplace/bin/ghc-pkg\" -e config.hp2ps=\"/home/tn/tn/GHCDarcsRepository /ghc-HEAD-complete-based-on-ghc-HEAD-2009-01-09-ghc-corelibs- testsuite/ghc/utils/hp2ps/hp2ps\" -e config.gs=\"gs\" -e config.platform=\"i386-unknown-linux\" -e config.os=\"linux\" -e config.wordsize=\"32\" -e default_testopts.cleanup=\"1\" -e config.timeout="int() or config.timeout" -e config.timeout_prog=\"../../timeout/install-inplace/bin/timeout\" -e config.exeext=\"\" -e config.top=\"/home/tn/tn/GHCDarcsRepository/ghc- HEAD-complete-based-on-ghc-HEAD-2009-01-09-ghc-corelibs- testsuite/ghc/testsuite\" --rootdir=../../../libraries/containers/tests --rootdir=../../../libraries/hpc/tests --rootdir=../../../libraries/bytestring/tests --rootdir=../../../libraries/random/tests --rootdir=../../../libraries/directory/tests --rootdir=../../../libraries/process/tests --rootdir=../../../libraries/Cabal/tests --rootdir=../../../libraries/unix/tests \ \ \ \ \ -e config.fast=1 \ Traceback (most recent call last): File "../../driver/runtests.py", line 89, in pat = int(pat) ValueError: invalid literal for int() with base 10: '1c1' make[1]: *** [test] Error 1 make[1]: Leaving directory `/home/tn/tn/GHCDarcsRepository/ghc-HEAD- complete-based-on-ghc-HEAD-2009-01-09-ghc-corelibs- testsuite/ghc/testsuite/tests/ghc-regress' make: *** [fast] Error 2 make: Leaving directory `/home/tn/tn/GHCDarcsRepository/ghc-HEAD-complete- based-on-ghc-HEAD-2009-01-09-ghc-corelibs-testsuite/ghc/testsuite/tests /ghc-regress' ------------------------------------------------------------------- Oops! Looks like you have some unexpected test results or framework failures. Please fix them before pushing/sending patches. ------------------------------------------------------------------- }}} from code in runtests.py: {{{ Wed Jun 11 17:51:48 CEST 2008 Ian Lynagh * Refuse to use threads unless python version >= 2.5.2 According to trac #1558, 2.5.2 should work. It's possible a lower bound, e.g. 2.5, would suffice. hunk ./driver/runtests.py 13 +import platform> hunk ./driver/runtests.py 83 - config.threads = int(arg) + # Trac #1558 says threads don't work in python 2.4.4, but do + # in 2.5.2. Probably >= 2.5 is sufficient, but let's be + # conservative here. + (maj, min, pat) = platform.python_version_tuple() + maj = int(maj) + min = int(min) + pat = int(pat) + if (maj, min, pat) >= (2, 5, 2): + config.threads = int(arg) + else: + print "Warning: Ignoring request to use threads as python version < 2.5.2" }}} The problem seems to be the non-decimal digit character in the the python patchlevel {{{1c1}}}. I am not sure how to fix this. I seem to recall to have seen non-decimal digit characters also in the minor version string of a python version. And to be sure: This is not a serious problem for me, it is not preventing me from doing anything important. Best regards Thorkil -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 13 11:15:40 2009 From: trac at galois.com (GHC) Date: Fri Mar 13 11:04:00 2009 Subject: [GHC] #3090: ghc-pkg update should fail if dependent packages might break In-Reply-To: <047.bbfd47d98ad2aecd41c60e5c078d3f61@localhost> References: <047.bbfd47d98ad2aecd41c60e5c078d3f61@localhost> Message-ID: <056.a40bd11d44a585abcd99d3fccafd3b8c@localhost> #3090: ghc-pkg update should fail if dependent packages might break ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by duncan): For cabal-install to update a whole bunch of packages correctly we would need more than just ghc-pkg update, if we implement this check. We would need to be able to register/update a whole batch of packages at once. Or we'd have to unregister each package and all its dependencies (in reverse order) and then re-register them all (assuming we did actually update them all). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 13 11:26:27 2009 From: trac at galois.com (GHC) Date: Fri Mar 13 11:15:10 2009 Subject: [GHC] #3092: algebraic data types can be extended by data instance declarations Message-ID: <046.1e381a097b2d57aa86bcae417818322f@localhost> #3092: algebraic data types can be extended by data instance declarations -----------------------------+---------------------------------------------- Reporter: jeltsch | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- The following program is accepted by GHC: {{{ {-# LANGUAGE TypeFamilies #-} data T a = C data instance T Int = CInt data instance T Bool = CBool }}} I think, it shouldn?t. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 13 11:34:33 2009 From: trac at galois.com (GHC) Date: Fri Mar 13 11:22:52 2009 Subject: [GHC] #3090: ghc-pkg update should fail if dependent packages might break In-Reply-To: <047.bbfd47d98ad2aecd41c60e5c078d3f61@localhost> References: <047.bbfd47d98ad2aecd41c60e5c078d3f61@localhost> Message-ID: <056.9ef2260a8c1a080f91d004a9428163aa@localhost> #3090: ghc-pkg update should fail if dependent packages might break ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by malcolm.wallace@cs.york.ac.uk): Or cabal-install could use ghc-pkg register --force on all dependent packages (but not on the root package?) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 13 13:07:40 2009 From: trac at galois.com (GHC) Date: Fri Mar 13 12:55:51 2009 Subject: [GHC] #3093: -osuf and stub files results in incorrect extension Message-ID: <051.590aa254af3583c1e368881472d94175@localhost> #3093: -osuf and stub files results in incorrect extension -----------------------------+---------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Using the example from the manual 9.2.1 on stub files: {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.10.1 $ ghc --make Foo.hs -fffi -osuf foo.bar [1 of 1] Compiling Foo ( Foo.hs, Foo.foo.bar ) }}} This generates the file {{{Foo.foo_stub.bar}}}, which is clearly wrong. I'd have expected {{{Foo_stub.foo.bar}}}. Note that the command works if no . is placed in the suffix. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 13 13:13:18 2009 From: trac at galois.com (GHC) Date: Fri Mar 13 13:01:27 2009 Subject: [GHC] #3094: Some GHC.* module should export word size and heap object header size Message-ID: <045.907bdf02870cf9d7a457cb5fba873bca@localhost> #3094: Some GHC.* module should export word size and heap object header size -----------------------------+---------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Component: libraries (other) Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Some code, like `bytestring`, uses magic constants to help it decide how much memory to allocate. This is not a correctness issue, just an optimisation one. It allows the `bytestring` package to allocate buffers that make optimal use of ghc's pinned allocator strategy which has to use a whole number of 4k pages. The magic is in subtracting the heap object header size: {{{ -- | Currently set to 32k, less the memory management overhead defaultChunkSize :: Int defaultChunkSize = 32 * k - chunkOverhead where k = 1024 -- | Currently set to 4k, less the memory management overhead smallChunkSize :: Int smallChunkSize = 4 * k - chunkOverhead where k = 1024 -- | The memory management overhead. Currently this is tuned for GHC only. chunkOverhead :: Int chunkOverhead = 2 * sizeOf (undefined :: Int) }}} This works for normal builds but for profiling builds it is a couple words off which wastes memory. It would also be be nice if it did not have to use magic constants but if it could import them from `GHC.Exts` or something. We would want: * Heap object header size, in words (currently 2 normally or 4 for profiling) * Word size (4 or 8 bytes) * Heap block size (currently 4k) These should all be actual Haskell constants so that they inline perfectly into calculations with no runtime overhead. The heap object header size is obviously different between profiling and normal, however this works out ok because we have to recompile for profiling anyway. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 13 19:33:19 2009 From: trac at galois.com (GHC) Date: Fri Mar 13 19:21:27 2009 Subject: [GHC] #3095: ghc panic during parsing Message-ID: <046.eadbae504325bd8fb3c2e94084684add@localhost> #3095: ghc panic during parsing --------------------+------------------------------------------------------- Reporter: pweaver | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Parser) Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: MacOS X | Architecture: x86 --------------------+------------------------------------------------------- For the following piece of code {{{ class Bla (forall x . x) where }}} the ghc parser yields the appropriate error {{{ Forall type not allowed as type parameter }}} However, if you change the code to this {{{ class Bla (forall x . x :: *) where }}} Then ghc does this: {{{ ghc: panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-apple-darwin): parser/RdrHsSyn.lhs:(525,4)-(548,64): Non-exhaustive patterns in function collect }}} This is reproducible on ghc-6.8.3 and ghc-6.10.1. I have only tried it on Mac OS X, x86. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 13 21:52:48 2009 From: trac at galois.com (GHC) Date: Fri Mar 13 21:41:09 2009 Subject: [GHC] #3085: warn about language extensions that are not used In-Reply-To: <051.bedfbd02c24cc787d0bf163c67d17d1e@localhost> References: <051.bedfbd02c24cc787d0bf163c67d17d1e@localhost> Message-ID: <060.4c8ee49158faecb2fe4687e5b2fec247@localhost> #3085: warn about language extensions that are not used ---------------------------------------------+------------------------------ Reporter: PVerswyvelen | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: warnings extensions language | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------------------+------------------------------ Changes (by guest): * cc: haskell@henning-thielemann.de (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Mar 14 05:04:39 2009 From: trac at galois.com (GHC) Date: Sat Mar 14 04:52:46 2009 Subject: [GHC] #3096: Dead links in GHC documentation Message-ID: <044.239148f9eee868941b189fd27f48a1d1@localhost> #3096: Dead links in GHC documentation -----------------------------+---------------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Component: Documentation Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- On http://www.haskell.org/ghc/documentation.html the links to the "(Old) Haskell Libraries" and the "FAQ" are both dead. I assume that the former is irrelevant nowadays. Perhaps the latter should point at http://www.haskell.org/haskellwiki/GHC:FAQ ? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Mar 14 08:45:59 2009 From: trac at galois.com (GHC) Date: Sat Mar 14 08:34:17 2009 Subject: [GHC] #3079: LANGUAGE pragma fails if it falls on a 1024-byte boundary In-Reply-To: <047.db20015538347ea9ecfd34557e791f17@localhost> References: <047.db20015538347ea9ecfd34557e791f17@localhost> Message-ID: <056.45b5fd27a1b316e9abbef80bf40a687a@localhost> #3079: LANGUAGE pragma fails if it falls on a 1024-byte boundary ----------------------------------+----------------------------------------- Reporter: Deewiant | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10.2 Component: Compiler (Parser) | Version: 6.10.1 Severity: critical | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: read068 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by igloo): * testcase: => read068 * status: new => closed * resolution: => fixed Comment: Merged, and test `read068` added. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Mar 14 09:08:58 2009 From: trac at galois.com (GHC) Date: Sat Mar 14 08:57:24 2009 Subject: [GHC] #2189: hSetBuffering stdin NoBuffering doesn't work on Windows In-Reply-To: <047.b31f95b84e60784da45a33105d44ed84@localhost> References: <047.b31f95b84e60784da45a33105d44ed84@localhost> Message-ID: <056.1e1789093239ca58ce59a1cccc2416b7@localhost> #2189: hSetBuffering stdin NoBuffering doesn't work on Windows -----------------------------------------------+---------------------------- Reporter: FalconNL | Owner: igloo Type: bug | Status: reopened Priority: high | Milestone: 6.10.2 Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: Keywords: hsetbuffering buffering buffer | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -----------------------------------------------+---------------------------- Changes (by igloo): * status: closed => reopened * type: merge => bug * resolution: fixed => Comment: We rolled back this patch: With it, it is not possible to type in ghci running from a cygwin window or a cmd window (but an msys window or SSHing into cygwin works fine). Sigbjorn, any ideas on what the problem is and how to solve it? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Mar 14 14:28:51 2009 From: trac at galois.com (GHC) Date: Sat Mar 14 14:16:58 2009 Subject: [GHC] #3097: Parser doesn't support doc comments on type aliases Message-ID: <044.6ac53274c77a45d41dec45a1148c8504@localhost> #3097: Parser doesn't support doc comments on type aliases -----------------------------+---------------------------------------------- Reporter: waern | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.11 | Severity: major Keywords: Haddock | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- I want to add comments to type synonyms in order to fix the following Haddock bug, but I need some help. http://trac.haskell.org/haddock/ticket/9 In the parser, the rule for type synonyms is: {{{ 'type' type '=' ctype }}} Types with comments are already defined as `ctypedoc` and used for top- level types. So it is tempting to just change `ctype` in the above line to `ctypedoc`. Indeed, I think originally `ctypedoc` was defined exactly as `ctype`, modulo comments. However, since then `ctype` has changed. The differences are: * `ctype` disallows foralls/contexts after a contex implication (=>). * `ctype` allows implicit parameters outside contexts. Seems to be disallowed by GHC later (after parsing). * `ctype` allows type equalities (~) outside contexts. Seems to be disallowed later also. I haven't seen any further differences (besides comments). Can I just change type synonyms to use `ctypedoc` without any other changes? Or do we need the features of `ctype` there? If so, then changing `ctypedoc` into just a commented version of `ctype` would not work as a solution, since then syntax like this (from base:GHC/Desugar.hs) breaks: {{{ (>>>) :: forall arr. Arrow arr => forall a b c. arr a b -> arr b c -> arr a c }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Mar 14 16:06:47 2009 From: trac at galois.com (GHC) Date: Sat Mar 14 15:54:55 2009 Subject: [GHC] #3086: Exception if temp path has national symbols In-Reply-To: <044.d10bb921365c2c3094ff1b6db5c35fff@localhost> References: <044.d10bb921365c2c3094ff1b6db5c35fff@localhost> Message-ID: <053.fe3616353c13e7859fde19a2cf55601d@localhost> #3086: Exception if temp path has national symbols ------------------------------------+--------------------------------------- Reporter: Tonal | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10.2 Component: libraries/directory | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ------------------------------------+--------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged: {{{ Thu Mar 12 09:14:08 PDT 2009 Simon Marlow * FIX #3086: use System.Win32.getTemporaryDirectory Sat Mar 14 06:13:29 PDT 2009 Ian Lynagh * Define and use c_getTempPath on Windows This means that we don't have to change the interface of Win32 in the 6.10 branch. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Mar 14 19:35:12 2009 From: trac at galois.com (GHC) Date: Sat Mar 14 19:23:17 2009 Subject: [GHC] #3098: undefined bug Message-ID: <047.e5683801e4ce8e212daa73954b5ab839@localhost> #3098: undefined bug ---------------------------------+------------------------------------------ Reporter: rheineke | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: undefined impossible | Testcase: Os: MacOS X | Architecture: x86 ---------------------------------+------------------------------------------ I coded the PrettyStub.hs file as shown in the Real World Haskell, page 119 and loaded it into ghci. I then proceeded to follow the examples on page 120: ghci>:load PrettyStub [2 of 2] Compiling Main ( PrettyStub.hs, interpreted ) Ok, modules loaded: SimpleJSON, Main. ghci>:show modules SimpleJSON ( SimpleJSON.hs, SimpleJSON.o ) Main ( PrettyStub.hs, interpreted ) ghci>:type undefined undefined :: a ghci>undefined *** Exception: Prelude.undefined ghci>double 3.14 ghc: panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-apple-darwin): loadObj: failed Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug And now I'm here. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Mar 14 20:13:03 2009 From: trac at galois.com (GHC) Date: Sat Mar 14 20:01:07 2009 Subject: [GHC] #3099: GHCi eats all my memory, even when loading a blank file Message-ID: <043.f94cd2bc6fe8cf6b842c25f4e551158a@localhost> #3099: GHCi eats all my memory, even when loading a blank file -------------------+-------------------------------------------------------- Reporter: nccb | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86_64 (amd64) -------------------+-------------------------------------------------------- My system is a slightly complicated setup -- I have GHC 6.8.2 installed on my system via my package manager (portage), but I have GHC 6.10.1 installed in my home directory. The system is a x86-64 Gentoo machine, 3GB RAM (plus 2GB swap). I can use this system just fine with the ghc executable, building code, running code, installing packages via cabal and so on. But I went to run ghci earlier, seemingly for the first time. If I run ghci on any file (including a blank .hs file), ghci promptly eats up all my physical RAM and swap (5GB total) and grinds the system to a halt. If I run it with -v5 (or without flags), the last lines are: {{{ Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. }}} I accept this may be an artifact of my odd configuration, but I figure eating 5GB of RAM rather than giving an error message should count as a bug :-) I'm happy to run more tests as necessary. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Mar 14 20:45:02 2009 From: trac at galois.com (GHC) Date: Sat Mar 14 20:33:10 2009 Subject: [GHC] #2846: Impredicativity bug: GHC crash by type signature In-Reply-To: <047.702be30b58ea1c05667f49195863703f@localhost> References: <047.702be30b58ea1c05667f49195863703f@localhost> Message-ID: <056.f5d93f85da551c29828c491e0e334144@localhost> #2846: Impredicativity bug: GHC crash by type signature ---------------------------------+------------------------------------------ Reporter: mm_freak | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: major | Resolution: Keywords: crash, type | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by nccb): Just to add another example, I believe this is the same bug: {{{ forFD :: (forall a. Floating a => a -> IO ()) -> [forall a. Floating a => a] -> IO () forFD f xs = mapM_ f xsf >> mapM_ f xsd where xsf :: [Float] xsf = [x | x <- xs] xsd :: [Double] xsd = [x | x <- xs] forIFD :: (forall a. Num a => a -> IO ()) -> [forall a. Num a => a] -> IO () forIFD f xs = mapM_ f xsi >> forFD f xs' where xsi :: [Int] xsi = [x | x <- xs] xs' :: [Floating a => a] xs' = [x | x <- xs] }}} Then "ghc -XRank2Types -XImpredicativeTypes -XFlexibleContexts tmp.hs" gives: {{{ ghc: panic! (the 'impossible' happened) (GHC version 6.10.1 for x86_64-unknown-linux): TcTyFuns.flattenType: unexpected PredType }}} Adding "forall a." to the type of the list xs' fixes the bug (even if the code cannot type-check in its current form) but I thought I'd post it here in case it helps. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 15 10:17:08 2009 From: trac at galois.com (GHC) Date: Sun Mar 15 10:05:11 2009 Subject: [GHC] #3099: GHCi eats all my memory, even when loading a blank file In-Reply-To: <043.f94cd2bc6fe8cf6b842c25f4e551158a@localhost> References: <043.f94cd2bc6fe8cf6b842c25f4e551158a@localhost> Message-ID: <052.e63f8bc62cbf0966faa6412875d44131@localhost> #3099: GHCi eats all my memory, even when loading a blank file --------------------+------------------------------------------------------- Reporter: nccb | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Linux | Architecture: x86_64 (amd64) --------------------+------------------------------------------------------- Comment (by duncan): It's probably the bug in the gentoo version of libedit-20061103. We patched it in the haskell overlay but it's not in the main portage version of libedit yet I think. If it is indeed this bug then there's not a lot that ghc can do I think. The solution is to use a patched or later version of libedit or not use libedit at all. The Gentoo plan for 6.10.2 is to patch ghc to use readline. Even with the fix for this bug, libedit is just not as usable and most Gentoo users do not need to redistribute closed source GHC binaries so linking against readline is fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 15 11:40:52 2009 From: trac at galois.com (GHC) Date: Sun Mar 15 11:28:56 2009 Subject: [GHC] #3099: GHCi eats all my memory, even when loading a blank file In-Reply-To: <043.f94cd2bc6fe8cf6b842c25f4e551158a@localhost> References: <043.f94cd2bc6fe8cf6b842c25f4e551158a@localhost> Message-ID: <052.956d62fc27bbe50e442210d6b959053c@localhost> #3099: GHCi eats all my memory, even when loading a blank file --------------------+------------------------------------------------------- Reporter: nccb | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Linux | Architecture: x86_64 (amd64) --------------------+------------------------------------------------------- Comment (by nccb): Thanks for your reply. My dev-libs/libedit version is 20050930; does your assessment still stand? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 15 11:43:29 2009 From: trac at galois.com (GHC) Date: Sun Mar 15 11:31:31 2009 Subject: [GHC] #3100: GHC Panic "reifyType PredTy" in HAppS.Data.IxSet.inferIxSet Message-ID: <049.c0071745bb9fd450cac603f8c5f89f94@localhost> #3100: GHC Panic "reifyType PredTy" in HAppS.Data.IxSet.inferIxSet -----------------------+---------------------------------------------------- Reporter: mightybyte | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: critical Keywords: | Testcase: Os: Linux | Architecture: x86_64 (amd64) -----------------------+---------------------------------------------------- Exception when trying to run compile-time code: ghc: panic! (the 'impossible' happened) (GHC version 6.10.1 for x86_64-unknown-linux): reifyType PredTy Code reproducing this bug can be found at: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=2419 Marked as critical because I haven't found a workaround yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 15 12:21:47 2009 From: trac at galois.com (GHC) Date: Sun Mar 15 12:09:49 2009 Subject: [GHC] #3101: GHC crashes on synonym family in a rank-n type Message-ID: <060.de3c2f017546d5a5e7ab0795045c3fa8@localhost> #3101: GHC crashes on synonym family in a rank-n type ----------------------------------+----------------------------------------- Reporter: MartijnVanSteenbergen | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: MacOS X | Architecture: Unknown/Multiple ----------------------------------+----------------------------------------- {{{ {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE RankNTypes #-} module Boom where type family F a :: * data Boom = Boom (forall a. F a) deriving Show }}} When loading the above compilation unit into GHCi, it crashes with: {{{ ghc: panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-apple-darwin): TcTyFuns.flattenType: synonym family in a rank-n type }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 15 12:58:26 2009 From: trac at galois.com (GHC) Date: Sun Mar 15 12:46:28 2009 Subject: [GHC] #3101: GHC crashes on synonym family in a rank-n type In-Reply-To: <060.de3c2f017546d5a5e7ab0795045c3fa8@localhost> References: <060.de3c2f017546d5a5e7ab0795045c3fa8@localhost> Message-ID: <069.e2d28964f822eb06bab1d9d58ace2c9b@localhost> #3101: GHC crashes on synonym family in a rank-n type -----------------------------------+---------------------------------------- Reporter: MartijnVanSteenbergen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: MacOS X | Architecture: Unknown/Multiple -----------------------------------+---------------------------------------- Comment (by MartijnVanSteenbergen): I have to add that while the above snippet makes no sense as a Haskell program, I was in fact doing something along the following lines, which does make sense: {{{ type family F a :: * -> * data Boom a = Boom (forall b. F a b) deriving Show }}} Also note that there is no problem when "deriving Show" is left away. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 15 17:37:16 2009 From: trac at galois.com (GHC) Date: Sun Mar 15 17:25:18 2009 Subject: [GHC] #3099: GHCi eats all my memory, even when loading a blank file In-Reply-To: <043.f94cd2bc6fe8cf6b842c25f4e551158a@localhost> References: <043.f94cd2bc6fe8cf6b842c25f4e551158a@localhost> Message-ID: <052.4c49f2cdf37c034d10cd538d6c85bc2a@localhost> #3099: GHCi eats all my memory, even when loading a blank file --------------------+------------------------------------------------------- Reporter: nccb | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Linux | Architecture: x86_64 (amd64) --------------------+------------------------------------------------------- Comment (by duncan): Replying to [comment:3 nccb]: > Thanks for your reply. My dev-libs/libedit version is 20050930; does your assessment still stand? Yes. It is likely that version has the bug in question. The version we patched was 20061103. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 15 18:04:48 2009 From: trac at galois.com (GHC) Date: Sun Mar 15 17:52:49 2009 Subject: [GHC] #3099: GHCi eats all my memory, even when loading a blank file In-Reply-To: <043.f94cd2bc6fe8cf6b842c25f4e551158a@localhost> References: <043.f94cd2bc6fe8cf6b842c25f4e551158a@localhost> Message-ID: <052.ffef017d9cd0d58c747ef7b87e8e7928@localhost> #3099: GHCi eats all my memory, even when loading a blank file -------------------------------+-------------------------------------------- Reporter: nccb | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: I'll close this ticket then; please reopen it if that turns out not to be the problem after all. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 15 18:30:19 2009 From: trac at galois.com (GHC) Date: Sun Mar 15 18:18:21 2009 Subject: [GHC] #3102: The impossible happened with implicit parameters Message-ID: <053.ebde85ce07c798d9c38e07173af669f0@localhost> #3102: The impossible happened with implicit parameters ---------------------------+------------------------------------------------ Reporter: Ashley Yakeley | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: Unknown/Multiple ---------------------------+------------------------------------------------ {{{ {-# OPTIONS -XImplicitParams -XRankNTypes #-} module Bug where t :: forall a. ((?p :: Int) => a) -> String t _ = "Hello" f :: (forall a. a -> String) -> Int f _ = 3 result :: Int result = f t }}} {{{ $ ghc -c Bug.hs ghc: panic! (the 'impossible' happened) (GHC version 6.10.1 for x86_64-unknown-linux): TcTyFuns.flattenType: unexpected PredType }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 15 18:33:12 2009 From: trac at galois.com (GHC) Date: Sun Mar 15 18:21:13 2009 Subject: [GHC] #3102: The impossible happened with implicit parameters In-Reply-To: <053.ebde85ce07c798d9c38e07173af669f0@localhost> References: <053.ebde85ce07c798d9c38e07173af669f0@localhost> Message-ID: <062.df5f995999243dba31bf62b56404f304@localhost> #3102: The impossible happened with implicit parameters -------------------------------------+-------------------------------------- Reporter: Ashley Yakeley | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Linux | Architecture: Unknown/Multiple -------------------------------------+-------------------------------------- Comment (by Ashley Yakeley): Note that with this, it compiles fine: {{{ result :: Int result = f (\a -> t a) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 15 19:52:24 2009 From: trac at galois.com (GHC) Date: Sun Mar 15 19:40:27 2009 Subject: [GHC] #3103: Compiling base with -fext-core. Message-ID: <045.1ec9768c2c79e83b67fadc73a8306022@localhost> #3103: Compiling base with -fext-core. -----------------------------+---------------------------------------------- Reporter: Lemmih | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Compiling base with -fext-core fails with ghc-6.10.1 and ghc-6.10.1rc. Reproduce with: cd libraries/base/ && cabal build -v --ghc-options="-fext- core" I've attached the output from my machine. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 15 19:59:12 2009 From: trac at galois.com (GHC) Date: Sun Mar 15 19:47:13 2009 Subject: [GHC] #3103: Compiling base. In-Reply-To: <045.1ec9768c2c79e83b67fadc73a8306022@localhost> References: <045.1ec9768c2c79e83b67fadc73a8306022@localhost> Message-ID: <054.6d9b254265e179a250feda0949345c9f@localhost> #3103: Compiling base. ------------------------------+--------------------------------------------- Reporter: Lemmih | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by Lemmih): * summary: Compiling base with -fext-core. => Compiling base. Comment: Turns out the same thing happens without the -fext-core flag. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 15 20:27:59 2009 From: trac at galois.com (GHC) Date: Sun Mar 15 20:16:03 2009 Subject: [GHC] #2867: Make a way to tell GHC that a pragma name should be "recognised" In-Reply-To: <044.b8d409e55bb3523a205a81d0c4d153a4@localhost> References: <044.b8d409e55bb3523a205a81d0c4d153a4@localhost> Message-ID: <053.a60703fa4283f23d7593a186954488f6@localhost> #2867: Make a way to tell GHC that a pragma name should be "recognised" ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by Lemmih): * cc: lemmih@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 16 07:33:53 2009 From: trac at galois.com (GHC) Date: Mon Mar 16 07:21:55 2009 Subject: [GHC] #3082: Unclear warning message: Attempting to re-export hidden constructors In-Reply-To: <042.a5c4cd3afa0abc022930d0824ba94bfa@localhost> References: <042.a5c4cd3afa0abc022930d0824ba94bfa@localhost> Message-ID: <051.dca802a718015a2e656eddd922c35920@localhost> #3082: Unclear warning message: Attempting to re-export hidden constructors ---------------------------------+------------------------------------------ Reporter: ksf | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by ksf): Looks fine... to be honest, I don't care about the wording. Another possibility is discerning between the no-constructors and the reexport case, that is, {{{ Warning: The export item `Foo(..)' suggests that `Foo''s constuctors / class methods are being exported from this package, but they are hidden by the export item `Foo' in Bar.hs:12 }}} in addition to the current warning. I doubt it's worth the bother, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 16 07:53:15 2009 From: trac at galois.com (GHC) Date: Mon Mar 16 07:41:15 2009 Subject: [GHC] #3093: -osuf and stub files results in incorrect extension In-Reply-To: <051.590aa254af3583c1e368881472d94175@localhost> References: <051.590aa254af3583c1e368881472d94175@localhost> Message-ID: <060.cb959136dafe82456cc86d63a7e341da@localhost> #3093: -osuf and stub files results in incorrect extension ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: => simonmar * difficulty: => Unknown * milestone: => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 16 07:59:26 2009 From: trac at galois.com (GHC) Date: Mon Mar 16 07:47:27 2009 Subject: [GHC] #3098: undefined bug In-Reply-To: <047.e5683801e4ce8e212daa73954b5ab839@localhost> References: <047.e5683801e4ce8e212daa73954b5ab839@localhost> Message-ID: <056.23a6012bd771e3d432ec20987a238bc7@localhost> #3098: undefined bug -------------------------------------+-------------------------------------- Reporter: rheineke | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: undefined impossible | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------------------+-------------------------------------- Changes (by simonmar): * difficulty: => Unknown Comment: We had a bug whereby if you use `:cd` and then try to load an object file you could get this error. See: [[TicketQuery(id=2973|0)]] If it isn't the same bug, please let us know. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 16 07:59:57 2009 From: trac at galois.com (GHC) Date: Mon Mar 16 07:47:59 2009 Subject: [GHC] #3098: undefined bug In-Reply-To: <054.78c8c3b9103b955fe0a9f779c77d4345@localhost> References: <054.78c8c3b9103b955fe0a9f779c77d4345@localhost> Message-ID: <063.a6d493f89eafb37c88aea4e73671977b@localhost> #3098: undefined bug -------------------------------------+-------------------------------------- Reporter: loadObj: failed | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: undefined impossible | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------------------+-------------------------------------- Changes (by simonmar): * reporter: rheineke => loadObj: failed -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 16 10:49:31 2009 From: trac at galois.com (GHC) Date: Mon Mar 16 10:37:53 2009 Subject: [GHC] #3097: Parser doesn't support doc comments on type aliases In-Reply-To: <044.6ac53274c77a45d41dec45a1148c8504@localhost> References: <044.6ac53274c77a45d41dec45a1148c8504@localhost> Message-ID: <053.bd52e1573470523f04100d54627541b9@localhost> #3097: Parser doesn't support doc comments on type aliases ---------------------------------+------------------------------------------ Reporter: waern | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: major | Resolution: Keywords: Haddock | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * difficulty: => Unknown Comment: David, This looks accidental to me. In general, our story is: if it makes the parser simpler, then it's fine to make the parser more generous (ie willing to parse more stuff), and reject illegal programs later. So maybe you should replace ''every'' use of ctype with ctypedoc (or rather rename the latter to be the former)? That would go further than you need, and would allow 'docs' to be parsed in more places. But if it doesn't give rise to ambiguities, it'd be fine by me. Make sure you run regression tests of course! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 16 11:24:41 2009 From: trac at galois.com (GHC) Date: Mon Mar 16 11:12:46 2009 Subject: [GHC] #2846: Impredicativity bug: GHC crash by type signature In-Reply-To: <047.702be30b58ea1c05667f49195863703f@localhost> References: <047.702be30b58ea1c05667f49195863703f@localhost> Message-ID: <056.feb760a425a063dbb5f3d8a6198f0751@localhost> #2846: Impredicativity bug: GHC crash by type signature ---------------------------------+------------------------------------------ Reporter: mm_freak | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: major | Resolution: Keywords: crash, type | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonpj): Thanks. FWIW, we did not remove `-XImpredicativeTypes` from `-fglasgow- exts` in 6.10.2, because that's an interface change. But it's gone from `-fglasgow-exts` in the HEAD. Cleaning the impredicative stables is still in the pipeline for 6.12. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 16 11:27:18 2009 From: trac at galois.com (GHC) Date: Mon Mar 16 11:15:18 2009 Subject: [GHC] #3101: GHC crashes on synonym family in a rank-n type In-Reply-To: <060.de3c2f017546d5a5e7ab0795045c3fa8@localhost> References: <060.de3c2f017546d5a5e7ab0795045c3fa8@localhost> Message-ID: <069.809016daef1d64fb332eb259f89268e8@localhost> #3101: GHC crashes on synonym family in a rank-n type --------------------------------------+------------------------------------- Reporter: MartijnVanSteenbergen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: Unknown/Multiple | --------------------------------------+------------------------------------- Changes (by simonpj): * difficulty: => Unknown Comment: I don't think 'deriving' supports rank-N types. (What would you want it to show?) Thanks for he report; I'll add a test so that it's rejected in a more civilised way. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 16 11:51:47 2009 From: trac at galois.com (GHC) Date: Mon Mar 16 11:39:48 2009 Subject: [GHC] #3104: -main-is should be a link time option, not compile time Message-ID: <051.c9e4c40c62127bef2ad48557fef49f93@localhost> #3104: -main-is should be a link time option, not compile time -----------------------------+---------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- The {{{-main-is}}} flag specifies which function name to use as main. However, when doing separate compilation: {{{ ghc -c Foo.hs ghc Foo.o }}} You have to give the {{{-main-is}}} in the first step - the compilation, rather than in the second step, the linking. It feels like this flag should be a link time option, and would give greater flexibility allowing one object file to be used in multiple projects with different main commands. If you compile with {{{ghc --make}}} this issue isn't really a problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 16 11:58:20 2009 From: trac at galois.com (GHC) Date: Mon Mar 16 11:46:19 2009 Subject: [GHC] #3100: GHC Panic "reifyType PredTy" in HAppS.Data.IxSet.inferIxSet In-Reply-To: <049.c0071745bb9fd450cac603f8c5f89f94@localhost> References: <049.c0071745bb9fd450cac603f8c5f89f94@localhost> Message-ID: <058.e17e1650cb49ecd181d6219bece8e9d2@localhost> #3100: GHC Panic "reifyType PredTy" in HAppS.Data.IxSet.inferIxSet -------------------------------+-------------------------------------------- Reporter: mightybyte | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: critical | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by simonpj): * difficulty: => Unknown Old description: > Exception when trying to run compile-time code: > ghc: panic! (the 'impossible' happened) > (GHC version 6.10.1 for x86_64-unknown-linux): > reifyType PredTy > > Code reproducing this bug can be found at: > http://hpaste.org/fastcgi/hpaste.fcgi/view?id=2419 > > Marked as critical because I haven't found a workaround yet. New description: {{{ Exception when trying to run compile-time code: ghc: panic! (the 'impossible' happened) (GHC version 6.10.1 for x86_64-unknown-linux): reifyType PredTy }}} Code reproducing this bug can be found at: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=2419 Marked as critical because I haven't found a workaround yet. Comment: Can you give me a self-contained repro case? I'm much more likely to fix this if I can do it without downloading all of Happs. Usually it's just a case of figuring out what the imports are, and replacing {{{ import Wurble }}} by {{{ f :: (?x:Int) => Int -> Int f = error "urk" }}} For what it's worth, the only way I can see that this crash can arise is if you are reifying the type of an instance declaration. For example, from the decl {{{ class Foo a where op1 :: a -> a op2 :: a -> Int instance Foo a => Foo [a] where ... }}} GHC generates a data type from the class decl, and a function from the instance thus: {{{ data TFoo a = MkTFoo (a->a) (a->Int) dfEqList :: forall a. TFoo a -> TFoo [a] }}} In trying to convert this back into TH syntax in 'reifyType' it can convert the `TFoo` on the left of the arrow to `Foo =>`, but it gets stuck with the `TFoo` on the right. Crashing is unhelpful I grant you. Maybe I should just return `TFoo` (it's actually more like `:TFoo` so as to avoid name clashes with your other data types)? But I'm still a bit unsure how yo managed to provoke this case. More info needed pls, on (a) repro case, (b) desired result. Simon Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ndmitchell at gmail.com Mon Mar 16 12:36:53 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Mar 16 12:24:56 2009 Subject: [GHC] #3081: Double output after Ctrl+C on Windows In-Reply-To: <49B91DC6.8060803@gmail.com> References: <051.84cd0947da97d4cf55fa6f13b11c0732@localhost> <060.6884b6cf1795faf5d384fed7d60a6b83@localhost> <404396ef0903120330w52e3edd6k47a3ca7b867894f2@mail.gmail.com> <49B91DC6.8060803@gmail.com> Message-ID: <404396ef0903160936h5f83afa7oad6f9e4810721f0c@mail.gmail.com> >> system "cp foo foo.bup" >> deleteFile "foo" >> >> If I Ctrl+C during the cp did I just delete my one copy of foo? > > On Windows, Ctrl-C will unblock a blocked system call. ?e.g. read() returns > with zero. ?Apparently system "foo" also returns as soon as you press > Ctrl-C, I'm not entirely sure why. ?Perhaps because the program has been > killed? So, to check my understanding: * Haskell program invokes system * Use presses Ctrl+C * System returns and Haskell program continues executing * Ctrl+C is thrown and Haskell program aborts That sounds really dangerous - like a race condition between the system returning and the Haskell program aborting. Thanks Neil From trac at galois.com Mon Mar 16 13:15:24 2009 From: trac at galois.com (GHC) Date: Mon Mar 16 13:03:57 2009 Subject: [GHC] #3092: algebraic data types can be extended by data instance declarations In-Reply-To: <046.1e381a097b2d57aa86bcae417818322f@localhost> References: <046.1e381a097b2d57aa86bcae417818322f@localhost> Message-ID: <055.87e9cb22e27c9968ced31adf9aaa8c74@localhost> #3092: algebraic data types can be extended by data instance declarations ------------------------------------------------+--------------------------- Reporter: jeltsch | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: indexed-types/should_fail/T3092 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ------------------------------------------------+--------------------------- Changes (by simonpj): * testcase: => indexed-types/should_fail/T3092 * difficulty: => Unknown * type: bug => merge * owner: => igloo Comment: Thank you. Fixed by {{{ Mon Mar 16 09:40:49 PDT 2009 simonpj@microsoft.com * Fix Trac #3092 }}} Merge to 6.10.2 if time. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 16 13:17:49 2009 From: trac at galois.com (GHC) Date: Mon Mar 16 13:05:49 2009 Subject: [GHC] #3101: GHC crashes on synonym family in a rank-n type In-Reply-To: <060.de3c2f017546d5a5e7ab0795045c3fa8@localhost> References: <060.de3c2f017546d5a5e7ab0795045c3fa8@localhost> Message-ID: <069.0abb9bc711a5b5f6af3d7464ab889c15@localhost> #3101: GHC crashes on synonym family in a rank-n type -------------------------------------------+-------------------------------- Reporter: MartijnVanSteenbergen | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: deriving/should_fail/T3101 | Os: MacOS X Architecture: Unknown/Multiple | -------------------------------------------+-------------------------------- Changes (by simonpj): * testcase: => deriving/should_fail/T3101 * owner: => igloo * type: bug => merge Comment: Fixed by {{{ Mon Mar 16 09:45:02 PDT 2009 simonpj@microsoft.com * Reject foralls in constructor args in 'deriving', except for Functor etc }}} There's a bit of refactoring in here to do with deriving `Functor`, so this patch won't merge into 6.10.2 trivially, though it would be easy to smooth over the bumps. It's not a big deal either way. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 16 13:37:14 2009 From: trac at galois.com (GHC) Date: Mon Mar 16 13:25:23 2009 Subject: [GHC] #3102: The impossible happened with implicit parameters In-Reply-To: <053.ebde85ce07c798d9c38e07173af669f0@localhost> References: <053.ebde85ce07c798d9c38e07173af669f0@localhost> Message-ID: <062.d7e1fb41e641715a883121c71a0ace8c@localhost> #3102: The impossible happened with implicit parameters ----------------------------------------+----------------------------------- Reporter: Ashley Yakeley | Owner: chak Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ----------------------------------------+----------------------------------- Changes (by simonpj): * owner: => chak * difficulty: => Unknown Comment: Manuel, could you look into this, pls? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 16 13:51:19 2009 From: trac at galois.com (GHC) Date: Mon Mar 16 13:39:26 2009 Subject: [GHC] #3095: ghc panic during parsing In-Reply-To: <046.eadbae504325bd8fb3c2e94084684add@localhost> References: <046.eadbae504325bd8fb3c2e94084684add@localhost> Message-ID: <055.67df7e2c4504796a09917c12c004979d@localhost> #3095: ghc panic during parsing -----------------------------------------+---------------------------------- Reporter: pweaver | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: parser/should_fail/T3095 | Os: MacOS X Architecture: x86 | -----------------------------------------+---------------------------------- Changes (by simonpj): * testcase: => parser/should_fail/T3095 * difficulty: => Unknown * type: bug => merge * owner: => igloo Comment: Thanks. I've fixed the crash, so it produces a sensible (if not great) error message {{{ T3095.hs:5:10: Kind signature only allowed for type variables }}} It produces this because GHC parses the type thus: {{{ ((forall x.x) :: *) }}} Merge to 6.10.2 if there's time. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 16 13:51:45 2009 From: trac at galois.com (GHC) Date: Mon Mar 16 13:39:55 2009 Subject: [GHC] #3095: ghc panic during parsing In-Reply-To: <046.eadbae504325bd8fb3c2e94084684add@localhost> References: <046.eadbae504325bd8fb3c2e94084684add@localhost> Message-ID: <055.d18122ec63ebaf99526f457bc1647fac@localhost> #3095: ghc panic during parsing -----------------------------------------+---------------------------------- Reporter: pweaver | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: parser/should_fail/T3095 | Os: MacOS X Architecture: x86 | -----------------------------------------+---------------------------------- Comment (by simonpj): Oh, this is the patch {{{ Mon Mar 16 10:47:06 PDT 2009 simonpj@microsoft.com * Fix Trac #3095, and make RdrHsSyn warning-clean }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 16 14:01:44 2009 From: trac at galois.com (GHC) Date: Mon Mar 16 13:49:44 2009 Subject: [GHC] #1969: enormous compile times In-Reply-To: <045.1ab99ac1a52ae6b35a7131dc801608a9@localhost> References: <045.1ab99ac1a52ae6b35a7131dc801608a9@localhost> Message-ID: <054.39c260eff3b54583e8c88b0242b41d61@localhost> #1969: enormous compile times ---------------------------------------------+------------------------------ Reporter: duncan | Owner: igloo Type: compile-time performance bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: performance | Difficulty: Difficult (1 week) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------------------+------------------------------ Comment (by simonpj): Ian diagnosed the problem. Basically we're compiling lots of things like: {{{ data A24 = A24 instance C A24 where c A24 = "A24" }}} where {{{ class C a where c :: a -> String d :: a -> String d x = c x e :: a -> String e x = c x }}} In the ticket 1000 instances are generated, but when I tried that the compiler was using 1.5G of RAM before I killed it. 100 instances is plenty to show a problem: {{{ ... doPassM SimplCore 36599 6 0.0 0.0 simplifyPgmIO SimplCore 36605 12 0.0 0.0 OccAnal SimplCore 37381 10 0.0 0.0 occurAnalysePgm OccurAnal 37399 10 0.0 0.0 occAnalBind OccurAnal 37400 3018 0.0 0.0 occAnalRec OccurAnal 37680 2717 0.0 0.0 reOrderRec OccurAnal 43292 502 0.0 0.0 reOrderCycle OccurAnal 43310 200 1.0 0.3 stronglyConnCompFromEdgedVerticesR Digraph 43342 200 0.0 0.0 graphFromEdgedVertices Digraph 43343 200 32.3 42.0 }}} It looks to me like the problem is: There's a binder {{{ (J.$dmd, \ (@ a_aue) ($dC_azi :: J.C a_aue) (x_auh :: a_aue) -> J.c @ a_aue $dC_azi x_auh) }}} in the (Rec pairs) being passed to `occAnalBind`, which, via its `idRuleVars`, ties everything in a big knot. I assume that what's going on here is that this is the "normal" c, and there are specialisation rules for uses of c at the various A* types? And to make things worse, I guess `J.$dmd` is not allowed to be a loop breaker, as then the interaction of rules and inlining could lead to an infinite loop? So with 100 class instances, we end up with a 500 node SCC being given to `reOrderRec`/`reOrderCycle`. This finds a loop breaker, which presumably removes at most one instance's worth of definitions from the SCC. Then it calls `stronglyConnCompFromEdgedVerticesR` to recompute the scc, and we go round again. `reOrderCycle` gets called 200 times, building a new SCC each time round, with size decreasing roughly linearly from 500 down to 3. I'm not sure why the space usage is so high; I haven't really looked at that. I guess we're probably holding on to the old SCCs or something for some reason. Biographical profiling says that the space is all VOID, but I'm not convinced that's trustworthy. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 16 15:41:32 2009 From: trac at galois.com (GHC) Date: Mon Mar 16 15:29:33 2009 Subject: [GHC] #3105: Panic during profiling build after recompiling a dependency with -auto-all Message-ID: <045.be8296a0a5cf9f747fc39f2ad40de417@localhost> #3105: Panic during profiling build after recompiling a dependency with -auto-all --------------------------------------------------+------------------------- Reporter: FSalad | Owner: Type: bug | Status: new Priority: normal | Component: Profiling Version: 6.10.1 | Severity: normal Keywords: profiler,profiling,panic,cost centres | Testcase: Os: Linux | Architecture: x86 --------------------------------------------------+------------------------- Hi, I recompiled some dependencies of my project like this (to see more cost centres): {{{ cabal install --reinstall --ghc-option=-auto-all OpenGL GLUT ftgl }}} then while trying to recompile my project: {{{ cabal clean cabal install --enable-library-profiling --enable-executable-profiling --disable-documentation --ghc-options="-O2 -ddump-simpl-stats" }}} the first (non-profiling) build succeeds, but then during the profiling build: {{{ ghc: panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-unknown-linux): applyTypeToArgs OpenGL-2.2.1.1:Graphics.Rendering.OpenGL.GL.VertexSpec.$wa2{v rC2} [gid] rb{v a1sB8} [lid] rb1{v a1sB9} [lid] rb2{v a1sBa} [lid] rb3{v a1sBb} [lid] eta{v a1sB4} [lid] forall a{tv a1sB7} [tv]. (base:GHC.Ptr.Ptr{tc 33A} a{tv a1sB7} [tv] -> ghc-prim:GHC.Types.Int{(w) tc 3J} -> base:GHC.IOBase.IO{tc 32I} a{tv a1sB7} [tv]) -> base:GHC.Ptr.Ptr{tc 33A} (OpenGL-2.2.1.1:Graphics.Rendering.OpenGL.GL.VertexSpec.Color3{tc rnw} a{tv a1sB7} [tv]) -> ghc-prim:GHC.Prim.State#{(w) tc 32q} ghc-prim:GHC.Prim.RealWorld{(w) tc 31E} -> (# ghc-prim:GHC.Prim.State#{(w) tc 32q} ghc-prim:GHC.Prim.RealWorld{(w) tc 31E}, OpenGL-2.2.1.1:Graphics.Rendering.OpenGL.GL.VertexSpec.Color3{tc rnw} a{tv a1sB7} [tv] #) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 16 16:25:58 2009 From: trac at galois.com (GHC) Date: Mon Mar 16 16:13:59 2009 Subject: [GHC] #3105: Panic during profiling build after recompiling a dependency with -auto-all In-Reply-To: <045.be8296a0a5cf9f747fc39f2ad40de417@localhost> References: <045.be8296a0a5cf9f747fc39f2ad40de417@localhost> Message-ID: <054.03f7f0991d0e91a1794b85b9eb03ced9@localhost> #3105: Panic during profiling build after recompiling a dependency with -auto-all ---------------------------------------------------+------------------------ Reporter: FSalad | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 6.10.1 Severity: minor | Resolution: Keywords: profiler,profiling,panic,cost centres | Testcase: Os: Linux | Architecture: x86 ---------------------------------------------------+------------------------ Changes (by FSalad): * severity: normal => minor Comment: (resolved by recompiling another dependency, which depended on the ones previously recompiled) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 16 18:38:03 2009 From: trac at galois.com (GHC) Date: Mon Mar 16 18:26:09 2009 Subject: [GHC] #2998: Expose the internals of the network library to make it more extensible In-Reply-To: <044.38e242663cf791489f4226de94cd9e56@localhost> References: <044.38e242663cf791489f4226de94cd9e56@localhost> Message-ID: <053.9dbcd5ba861d149203f4a6f456e37ff3@localhost> #2998: Expose the internals of the network library to make it more extensible ----------------------------------+----------------------------------------- Reporter: tibbe | Owner: igloo Type: proposal | Status: reopened Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by tibbe): * status: closed => reopened * resolution: fixed => Comment: I've attached two more patches (see `move-the-throwsocketerror_-class-of- functions-into-the-internals-module_.dpatch`) that expose the `throwSocketErrorIf*` class of functions. The patch is split in two for easier reviewing. The first patch simply moves the functions to the `Internal` module. The second renames some of them and adds documentation. I've tested this on Mac OS X 10.5 and Windows (using MinGW/MSYS). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 16 18:38:21 2009 From: trac at galois.com (GHC) Date: Mon Mar 16 18:26:22 2009 Subject: [GHC] #2998: Expose the internals of the network library to make it more extensible In-Reply-To: <044.38e242663cf791489f4226de94cd9e56@localhost> References: <044.38e242663cf791489f4226de94cd9e56@localhost> Message-ID: <053.b43ef9635909a91a421de008d3cf3121@localhost> #2998: Expose the internals of the network library to make it more extensible ----------------------------------+----------------------------------------- Reporter: tibbe | Owner: igloo Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by tibbe): * status: reopened => new -- Ticket URL: GHC The Glasgow Haskell Compiler From duncan.coutts at worc.ox.ac.uk Mon Mar 16 20:07:31 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Mar 16 19:55:30 2009 Subject: [GHC] #3081: Double output after Ctrl+C on Windows In-Reply-To: <404396ef0903160936h5f83afa7oad6f9e4810721f0c@mail.gmail.com> References: <051.84cd0947da97d4cf55fa6f13b11c0732@localhost> <060.6884b6cf1795faf5d384fed7d60a6b83@localhost> <404396ef0903120330w52e3edd6k47a3ca7b867894f2@mail.gmail.com> <49B91DC6.8060803@gmail.com> <404396ef0903160936h5f83afa7oad6f9e4810721f0c@mail.gmail.com> Message-ID: <1237248451.22402.553.camel@localhost> On Mon, 2009-03-16 at 16:36 +0000, Neil Mitchell wrote: > >> system "cp foo foo.bup" >> deleteFile "foo" > >> > >> If I Ctrl+C during the cp did I just delete my one copy of foo? > > > > On Windows, Ctrl-C will unblock a blocked system call. e.g. read() returns > > with zero. Apparently system "foo" also returns as soon as you press > > Ctrl-C, I'm not entirely sure why. Perhaps because the program has been > > killed? > > So, to check my understanding: > > * Haskell program invokes system > * Use presses Ctrl+C > * System returns and Haskell program continues executing > * Ctrl+C is thrown and Haskell program aborts > > That sounds really dangerous - like a race condition between the > system returning and the Haskell program aborting. I've no idea how Ctrl-C works on Windows but since it may be relevant and possibly useful let me just walk through how it should(*) work on Unix with the new process library implementation that we've been discussing. (I think it also works fine with the current process implementation on Unix) For system() we "delegate" Ctrl-C handling to the child process. That means that while the child process is running we take no action when we (the parent process) receive the signal corresponding to Ctrl-C. No exception is raised, we do not attempt to kill the child process, nothing. When the child process terminates we check how it terminated. If it terminated due to the Ctrl-C signal then we raise a synchronous Haskell exception. If it terminated with a normal exit code then no exception is raised (we deem the child process to have handled the Ctrl-C, think of programs like ghci which handle Ctrl-C). Duncan (*) "should". The implementation does not do this yet. From trac at galois.com Mon Mar 16 20:31:36 2009 From: trac at galois.com (GHC) Date: Mon Mar 16 20:19:35 2009 Subject: [GHC] #3100: GHC Panic "reifyType PredTy" in HAppS.Data.IxSet.inferIxSet In-Reply-To: <049.c0071745bb9fd450cac603f8c5f89f94@localhost> References: <049.c0071745bb9fd450cac603f8c5f89f94@localhost> Message-ID: <058.611a2e21eabd98533064352f4579fe10@localhost> #3100: GHC Panic "reifyType PredTy" in HAppS.Data.IxSet.inferIxSet -------------------------------+-------------------------------------------- Reporter: mightybyte | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by mightybyte): * severity: critical => minor -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 16 20:45:17 2009 From: trac at galois.com (GHC) Date: Mon Mar 16 20:33:16 2009 Subject: [GHC] #3100: GHC Panic "reifyType PredTy" in HAppS.Data.IxSet.inferIxSet In-Reply-To: <049.c0071745bb9fd450cac603f8c5f89f94@localhost> References: <049.c0071745bb9fd450cac603f8c5f89f94@localhost> Message-ID: <058.86148074b0c4fc692cf20153a15f9f05@localhost> #3100: GHC Panic "reifyType PredTy" in HAppS.Data.IxSet.inferIxSet -------------------------------+-------------------------------------------- Reporter: mightybyte | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Comment (by mightybyte): The new file I attached contains a workaround I found. It seems like Happs(tack) may be at fault here, although GHC still panics, so I think something needs to be fixed in GHC as well. I eliminated the inferIxSet call and substituted the code that I believe it should be generating. This got rid of the panic, so presumably the panic is being induced by something inferIxSet is doing and not it's generated code. I'm not familiar with the details of inferIxSet, so unfortunately I can't give more help here. With the workaround, the bug is no longer blocking my progress, so I downgraded it to minor. Ultimately I think you would at least want to prevent GHC from panicing on this though. -- Ticket URL: GHC The Glasgow Haskell Compiler From marlowsd at gmail.com Tue Mar 17 05:02:36 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Mar 17 04:50:39 2009 Subject: [GHC] #3081: Double output after Ctrl+C on Windows In-Reply-To: <404396ef0903160936h5f83afa7oad6f9e4810721f0c@mail.gmail.com> References: <051.84cd0947da97d4cf55fa6f13b11c0732@localhost> <060.6884b6cf1795faf5d384fed7d60a6b83@localhost> <404396ef0903120330w52e3edd6k47a3ca7b867894f2@mail.gmail.com> <49B91DC6.8060803@gmail.com> <404396ef0903160936h5f83afa7oad6f9e4810721f0c@mail.gmail.com> Message-ID: <49BF672C.5040603@gmail.com> Neil Mitchell wrote: >>> system "cp foo foo.bup" >> deleteFile "foo" >>> >>> If I Ctrl+C during the cp did I just delete my one copy of foo? >> On Windows, Ctrl-C will unblock a blocked system call. e.g. read() returns >> with zero. Apparently system "foo" also returns as soon as you press >> Ctrl-C, I'm not entirely sure why. Perhaps because the program has been >> killed? > > So, to check my understanding: > > * Haskell program invokes system > * Use presses Ctrl+C > * System returns and Haskell program continues executing > * Ctrl+C is thrown and Haskell program aborts Yes. > That sounds really dangerous - like a race condition between the > system returning and the Haskell program aborting. I don't know why system returns, but one valid reason would be if the child process had died due to the same Ctrl-C. As Duncan says, in this case we ought to raise the Ctrl-C exception in the parent, but (a) none of this is implemented in the current process library, and (b) I'm not sure if you can tell whether a child died due to Ctrl-C on Windows. Also since Windows has no process groups, I don't think system is returning as a result of the child dying. It's more likely to be returning because of some silly Win32ism, like the way read() returns 0 on Windows when you press Ctrl-C. The latter also leads to very strange behaviour unless you check for it (which we don't, and we probably should). Consoles are very weird on Windows. Ctrl-C doesn't even work at all in MSYS or (certain types of) Cygwin windows, or xterms - it kills the program, but the program doesn't get a signal. Cheers, Simon From trac at galois.com Tue Mar 17 05:18:16 2009 From: trac at galois.com (GHC) Date: Tue Mar 17 05:06:17 2009 Subject: [GHC] #3105: Panic during profiling build after recompiling a dependency with -auto-all In-Reply-To: <045.be8296a0a5cf9f747fc39f2ad40de417@localhost> References: <045.be8296a0a5cf9f747fc39f2ad40de417@localhost> Message-ID: <054.88e164f49374f2fcacb2cba83964e11c@localhost> #3105: Panic during profiling build after recompiling a dependency with -auto-all ------------------------------------------------------+--------------------- Reporter: FSalad | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Profiling | Version: 6.10.1 Severity: minor | Resolution: invalid Keywords: profiler,profiling,panic,cost centres | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ------------------------------------------------------+--------------------- Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: So this is another instance of an inconsistent set of compiled packages. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 17 05:20:08 2009 From: trac at galois.com (GHC) Date: Tue Mar 17 05:08:06 2009 Subject: [GHC] #3093: -osuf and stub files results in incorrect extension In-Reply-To: <051.590aa254af3583c1e368881472d94175@localhost> References: <051.590aa254af3583c1e368881472d94175@localhost> Message-ID: <060.837518fe4c21aaabef9da88d2739c058@localhost> #3093: -osuf and stub files results in incorrect extension ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: Thanks for the report. Fixed: {{{ Mon Mar 16 20:34:37 GMT 2009 Simon Marlow * FIX #3093: stub filenames when using -osuf Also remove some unused cruft }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 17 05:36:10 2009 From: trac at galois.com (GHC) Date: Tue Mar 17 05:24:08 2009 Subject: [GHC] #3098: loadObj: failed In-Reply-To: <047.e5683801e4ce8e212daa73954b5ab839@localhost> References: <047.e5683801e4ce8e212daa73954b5ab839@localhost> Message-ID: <056.299871b4bf7838c13f13671de564884c@localhost> #3098: loadObj: failed -------------------------------------+-------------------------------------- Reporter: rheineke | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: undefined impossible | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------------------+-------------------------------------- Changes (by simonmar): * summary: undefined bug => loadObj: failed * reporter: loadObj: failed => rheineke -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 17 05:55:26 2009 From: trac at galois.com (GHC) Date: Tue Mar 17 05:43:29 2009 Subject: [GHC] #3106: hundred failures of release candidate ghc-6.10.1.20090314 in testsuite Message-ID: <045.ed77f144615446c295cf993e7e3ad16f@localhost> #3106: hundred failures of release candidate ghc-6.10.1.20090314 in testsuite --------------------+------------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Component: Test Suite Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Solaris | Architecture: x86 --------------------+------------------------------------------------------- I've build a working binary distro of ghc-6.10.1.20090314 http://www.informatik.uni- bremen.de/agbkb/forschung/formal_methods/CoFI/hets/pc- solaris/ghcs/ghc-6.10.1.20090314-i386-unknown-solaris2.tar.bz2 The testsuite results are in http://www.informatik.uni- bremen.de/agbkb/forschung/formal_methods/CoFI/hets/pc- solaris/ghcs/ghc-6.10.1.20090314-tests.log.fast.gz http://www.informatik.uni- bremen.de/agbkb/forschung/formal_methods/CoFI/hets/pc- solaris/ghcs/ghc-6.10.1.20090314-tests.log.stage2.gz The summary for "gmake fast" is: {{{ OVERALL SUMMARY for test run started at Mon Mar 16 17:47:00 CET 2009 2334 total tests, which gave rise to 12483 test cases, of which 0 caused framework failures 10485 were skipped 1826 expected passes 68 expected failures 0 unexpected passes 104 unexpected failures }}} The log contains 439 lines: {{{ /bin/sh: cygpath: not found }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 17 05:59:31 2009 From: trac at galois.com (GHC) Date: Tue Mar 17 05:47:30 2009 Subject: [GHC] #3106: hundred failures of release candidate ghc-6.10.1.20090314 in testsuite In-Reply-To: <045.ed77f144615446c295cf993e7e3ad16f@localhost> References: <045.ed77f144615446c295cf993e7e3ad16f@localhost> Message-ID: <054.c45211ee347ea9cb161a37d0445dc0e0@localhost> #3106: hundred failures of release candidate ghc-6.10.1.20090314 in testsuite ------------------------+--------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Solaris | Architecture: x86 ------------------------+--------------------------------------------------- Comment (by duncan): Yes, we were getting the same thing happening on the sparky buildbot. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 17 06:54:23 2009 From: trac at galois.com (GHC) Date: Tue Mar 17 06:42:21 2009 Subject: [GHC] #3106: hundred failures of release candidate ghc-6.10.1.20090314 in testsuite In-Reply-To: <045.ed77f144615446c295cf993e7e3ad16f@localhost> References: <045.ed77f144615446c295cf993e7e3ad16f@localhost> Message-ID: <054.bd7e53f179dd9da3cc767e79254a74bb@localhost> #3106: hundred failures of release candidate ghc-6.10.1.20090314 in testsuite ------------------------+--------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Solaris | Architecture: x86 ------------------------+--------------------------------------------------- Comment (by thorkilnaur): This also happens when using {{{ $ uname -a FreeBSD tn12.thorkilnaur.dk 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Fri Jan 12 10:40:27 UTC 2007 root@dessler.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 $ make --version GNU Make 3.81 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. This program built for i386-portbld-freebsd6.2 $ }}} On the other hand, it does *not* happen when using {{{ $ uname -a Darwin thorkil-naurs-mac-mini.local 9.6.0 Darwin Kernel Version 9.6.0: Mon Nov 24 17:39:01 PST 2008; root:xnu-1228.9.59~1/RELEASE_PPC Power Macintosh $ make --version GNU Make 3.81 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. This program built for powerpc-apple-darwin9.0 $ }}} Best regards Thorkil -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 17 07:43:33 2009 From: trac at galois.com (GHC) Date: Tue Mar 17 07:38:00 2009 Subject: [GHC] #3106: hundred failures of release candidate ghc-6.10.1.20090314 in testsuite In-Reply-To: <045.ed77f144615446c295cf993e7e3ad16f@localhost> References: <045.ed77f144615446c295cf993e7e3ad16f@localhost> Message-ID: <054.6e514ff3a5cad41088c995ea9d99cf1d@localhost> #3106: hundred failures of release candidate ghc-6.10.1.20090314 in testsuite ------------------------+--------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Solaris | Architecture: x86 ------------------------+--------------------------------------------------- Comment (by kgardas): This affects also kgardas buildbot, not only sparky. I've attached proposed fix for this issue, but I don't have windows/cygwin/mingw platforms installed to test if the workaround does not break them. Please test yourself. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 17 07:47:51 2009 From: trac at galois.com (GHC) Date: Tue Mar 17 07:44:08 2009 Subject: [GHC] #3106: hundred failures of release candidate ghc-6.10.1.20090314 in testsuite In-Reply-To: <045.ed77f144615446c295cf993e7e3ad16f@localhost> References: <045.ed77f144615446c295cf993e7e3ad16f@localhost> Message-ID: <054.9103d34a6f6757efdf2546f11cefd3d5@localhost> #3106: hundred failures of release candidate ghc-6.10.1.20090314 in testsuite ------------------------+--------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Solaris | Architecture: x86 ------------------------+--------------------------------------------------- Comment (by kgardas): Replying to [comment:2 thorkilnaur]: > This also happens when using {{{ > $ uname -a > FreeBSD tn12.thorkilnaur.dk 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Fri Jan 12 10:40:27 UTC 2007 root@dessler.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 > $ make --version > GNU Make 3.81 > Copyright (C) 2006 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. > There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A > PARTICULAR PURPOSE. > > This program built for i386-portbld-freebsd6.2 > $ }}} > On the other hand, it does *not* happen when using {{{ > $ uname -a > Darwin thorkil-naurs-mac-mini.local 9.6.0 Darwin Kernel Version 9.6.0: Mon Nov 24 17:39:01 PST 2008; root:xnu-1228.9.59~1/RELEASE_PPC Power Macintosh > $ make --version > GNU Make 3.81 > Copyright (C) 2006 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. > There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A > PARTICULAR PURPOSE. > > This program built for powerpc-apple-darwin9.0 > $ }}} > Best regards > Thorkil It's probably all about where your shell reports not found application. If to stderr, it's all right (and bash probably does this), but if to stdout then the code in mk/boilerplate.mk is broken. My guess: MacOS X is using bash as /bin/sh and FreeBSD is using ksh as /bin/sh. Right? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 17 08:57:53 2009 From: trac at galois.com (GHC) Date: Tue Mar 17 08:45:57 2009 Subject: [GHC] #3024: Rewrite hp2ps in Haskell In-Reply-To: <043.5e2ae06063a38e8d4403ee8cfc50d869@localhost> References: <043.5e2ae06063a38e8d4403ee8cfc50d869@localhost> Message-ID: <052.cbcf6b8edfdc3d6adfdc1c95e8253e6d@localhost> #3024: Rewrite hp2ps in Haskell ---------------------------------+------------------------------------------ Reporter: SamB | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Profiling | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by igloo): It would also be useful to be able to print some of the results as text, e.g. for a biographical profile it might print: {{{ VOID: 23% DRAG: 16% ... }}} where the percentages are the area of the graph. This would allow us to write better tests for heap profiling. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 17 09:31:03 2009 From: trac at galois.com (GHC) Date: Tue Mar 17 09:25:27 2009 Subject: [GHC] #3106: hundred failures of release candidate ghc-6.10.1.20090314 in testsuite In-Reply-To: <045.ed77f144615446c295cf993e7e3ad16f@localhost> References: <045.ed77f144615446c295cf993e7e3ad16f@localhost> Message-ID: <054.829af8f2ffed1db3ce11fbb27978003a@localhost> #3106: hundred failures of release candidate ghc-6.10.1.20090314 in testsuite ------------------------+--------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Solaris | Architecture: x86 ------------------------+--------------------------------------------------- Comment (by thorkilnaur): Replying to [comment:4 kgardas]: > ... > It's probably all about where your shell reports not found application. If to stderr, it's all right (and bash probably does this), but if to stdout then the code in mk/boilerplate.mk is broken. My guess: MacOS X is using bash as /bin/sh and FreeBSD is using ksh as /bin/sh. Right? I am not sure whether /bin/sh is ksh on FreeBSD, but there is certainly a difference between bash and sh in reporting commands not found: {{{ [tn@tn12 ~/tn/test/GHC/release/GHC-6.10.2-rc1/work]$ uname -a FreeBSD tn12.thorkilnaur.dk 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Fri Jan 12 10:40:27 UTC 2007 root@dessler.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 [tn@tn12 ~/tn/test/GHC/release/GHC-6.10.2-rc1/work]$ bash [tn@tn12 ~/tn/test/GHC/release/GHC-6.10.2-rc1/work]$ cygpath 1>bash.out 2>bash.err [tn@tn12 ~/tn/test/GHC/release/GHC-6.10.2-rc1/work]$ cat bash.out [tn@tn12 ~/tn/test/GHC/release/GHC-6.10.2-rc1/work]$ cat bash.err bash: cygpath: command not found [tn@tn12 ~/tn/test/GHC/release/GHC-6.10.2-rc1/work]$ sh $ cygpath 1>sh.out 2>sh.err cygpath: not found $ cat sh.out cat: sh.out: No such file or directory $ cat sh.err cat: sh.err: No such file or directory $ }}} So it seems that sh on FreeBSD uses neither stdout nor stderr. Interesting. Best regards Thorkil -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 17 10:04:35 2009 From: trac at galois.com (GHC) Date: Tue Mar 17 09:58:56 2009 Subject: [GHC] #3106: hundred failures of release candidate ghc-6.10.1.20090314 in testsuite In-Reply-To: <045.ed77f144615446c295cf993e7e3ad16f@localhost> References: <045.ed77f144615446c295cf993e7e3ad16f@localhost> Message-ID: <054.57eee03d6d9d8be818c19a3b535f8289@localhost> #3106: hundred failures of release candidate ghc-6.10.1.20090314 in testsuite ------------------------+--------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Solaris | Architecture: x86 ------------------------+--------------------------------------------------- Comment (by kgardas): Replying to [comment:5 thorkilnaur]: > So it seems that sh on FreeBSD uses neither stdout nor stderr. Interesting. Indeed! I've just check and exactly the same happens on Solaris/x86 /bin/sh. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 17 11:24:25 2009 From: trac at galois.com (GHC) Date: Tue Mar 17 11:12:23 2009 Subject: [GHC] #3039: strange space usage In-Reply-To: <044.6222a2241621a8a36e8604831e185979@localhost> References: <044.6222a2241621a8a36e8604831e185979@localhost> Message-ID: <053.7d91d0e3cb9d480b0019207224f531a0@localhost> #3039: strange space usage ---------------------------------+------------------------------------------ Reporter: igloo | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: => igloo * type: run-time performance bug => merge * milestone: 6.12 branch => 6.10.2 Comment: I found bugs in the biographical profiler and fixed them: {{{ Tue Mar 17 14:49:39 GMT 2009 Simon Marlow * FIX biographical profiling (#3039, probably #2297) Since we introduced pointer tagging, we no longer always enter a closure to evaluate it. However, the biographical profiler relies on closures being entered in order to mark them as "used", so we were getting spurious amounts of data attributed to VOID. It turns out there are various places that need to be fixed, and I think at least one of them was also wrong before pointer tagging (CgCon.cgReturnDataCon). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 17 11:25:09 2009 From: trac at galois.com (GHC) Date: Tue Mar 17 11:13:06 2009 Subject: [GHC] #2297: Profiler is inconsistent about biography for GHC's heap In-Reply-To: <044.fbea862bca1709c4fb82e649273727f1@localhost> References: <044.fbea862bca1709c4fb82e649273727f1@localhost> Message-ID: <053.43ebccf128da4d6b8edf690a56aaaf80@localhost> #2297: Profiler is inconsistent about biography for GHC's heap ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.2 Component: Profiling | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: optimistically assuming this is fixed by the fix for #3039. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 17 12:47:20 2009 From: trac at galois.com (GHC) Date: Tue Mar 17 12:35:21 2009 Subject: [GHC] #3107: Over-eager GC when blocked on a signal in the non-threaded runtime Message-ID: <044.33d111777101268af6a254823101f5b5@localhost> #3107: Over-eager GC when blocked on a signal in the non-threaded runtime -------------------+-------------------------------------------------------- Reporter: awick | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: Unknown/Multiple -------------------+-------------------------------------------------------- Right now, in the non-threaded runtime, if you have the situation where all the threads are blocked on MVars, the deadlock detection / avoidance code runs a GC. This is fine, generally, but if they're blocked on MVars held by signal handlers, it has a profoundly bad effect on performance. In short, the runtime starts collection (blocking signals?), and we're stuck waiting for it to finish before handling signals. Or, if the signal doesn't come in, we sit waiting in a loop, garbage collecting. It would be nice if the runtime either didn't trigger collection if signal handlers are in place, or, at the very least, held off on doing so for a nontrivial period of time. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 17 12:43:55 2009 From: trac at galois.com (GHC) Date: Tue Mar 17 12:38:20 2009 Subject: [GHC] #3106: hundred failures of release candidate ghc-6.10.1.20090314 in testsuite In-Reply-To: <045.ed77f144615446c295cf993e7e3ad16f@localhost> References: <045.ed77f144615446c295cf993e7e3ad16f@localhost> Message-ID: <054.bef9acd50f0225afdfac6683c14ded5c@localhost> #3106: hundred failures of release candidate ghc-6.10.1.20090314 in testsuite ------------------------+--------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Solaris | Architecture: x86 ------------------------+--------------------------------------------------- Comment (by thorkilnaur): The precise effect of {{{sh unknownCommand}}} on FreeBSD seems to be that the error message is printed to stderr before the redirections on the command line become effective: {{{ > [tn@tn12 ~/tn/test/GHC/release/GHC-6.10.2-rc1/work]$ sh -c cygpath 1>sh.out 2>sh.err > [tn@tn12 ~/tn/test/GHC/release/GHC-6.10.2-rc1/work]$ cat sh.out > [tn@tn12 ~/tn/test/GHC/release/GHC-6.10.2-rc1/work]$ cat sh.err > cygpath: not found > [tn@tn12 ~/tn/test/GHC/release/GHC-6.10.2-rc1/work]$ }}} This suggests an alternative fix of the problem, represented by the attached patch. Note: The changed {{{testsuite/mk/boilerplate.mk}}} has passed stand-alone tests in the FreeBSD, PPC Mac OS X 10.5, and Cygwin (under Windows) environments. But it has not been tried for a complete run of the GHC testsuite. Best regards Thorkil -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 17 21:59:59 2009 From: trac at galois.com (GHC) Date: Tue Mar 17 21:47:59 2009 Subject: [GHC] #3074: Template Haskell does not support type families. In-Reply-To: <054.532c25252b9d3cc0cd067701cce4d187@localhost> References: <054.532c25252b9d3cc0cd067701cce4d187@localhost> Message-ID: <063.ec92daeef35c82e969d993f8d402b541@localhost> #3074: Template Haskell does not support type families. ---------------------------------------------+------------------------------ Reporter: Serguey Zefirov | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: minor | Resolution: duplicate Keywords: template haskell, type families | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ---------------------------------------------+------------------------------ Changes (by chak): * status: new => closed * resolution: => duplicate Comment: See #1673. (I am implementing this, but it won't get into 6.10 as APIs will need change.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 17 22:45:08 2009 From: trac at galois.com (GHC) Date: Tue Mar 17 22:33:03 2009 Subject: [GHC] #3103: Compiling base with cabal fails. In-Reply-To: <045.1ec9768c2c79e83b67fadc73a8306022@localhost> References: <045.1ec9768c2c79e83b67fadc73a8306022@localhost> Message-ID: <054.11510aa6b93fdb3385a2b1df1c4d0673@localhost> #3103: Compiling base with cabal fails. ------------------------------+--------------------------------------------- Reporter: Lemmih | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by Lemmih): * summary: Compiling base. => Compiling base with cabal fails. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 17 22:45:20 2009 From: trac at galois.com (GHC) Date: Tue Mar 17 22:33:16 2009 Subject: [GHC] #3103: Compiling base with cabal fails. In-Reply-To: <045.1ec9768c2c79e83b67fadc73a8306022@localhost> References: <045.1ec9768c2c79e83b67fadc73a8306022@localhost> Message-ID: <054.746e2c8c4cfc172513cf0ecd7abf0f9e@localhost> #3103: Compiling base with cabal fails. ------------------------------+--------------------------------------------- Reporter: Lemmih | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by Lemmih): * cc: lemmih@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 18 04:54:04 2009 From: trac at galois.com (GHC) Date: Wed Mar 18 04:42:00 2009 Subject: [GHC] #3108: Do a better job of solving recursive type-class constraints with functional dependencies Message-ID: <046.b4958716db42be5102822b5e113eaa5b@localhost> #3108: Do a better job of solving recursive type-class constraints with functional dependencies --------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler (Type checker) | Version: 6.10.1 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple --------------------------------------+------------------------------------- This ticket is just to track this interesting thread on the Haskell list, concerning recursive type-class constraints: http://www.haskell.org/pipermail/haskell/2009-March/021115.html. We might want to get back to this when the new constraint solver is in place. The question concerns the interaction of solving recursive type-class constraints, where it is important to aggressively apply functional dependencies. Here's Tom Schrijvers's analysis of Ralf's example: "The cyclic dictionaries approach is a bit fragile. The problem appears to be here that GHC alternates exhaustive phases of constraint reduction and functional dependency improvement. The problem is that in your example you need both for detecting a cycle. This can happen: {{{ C1 Int ==> 3rd C1 inst C2 Int y, C1 (y,Bool) ==> 1st C1 inst C2 Int y, C1 y, C1 Bool ==> 2nd C1 inst C2 Int y, C1 y ==> 3rd C1 inst C2 Int y, C2 y z, C1 (z,Bool) ==> ... }}} where all the constraint are different because fresh variables are introduced. What you want to happen is: {{{ C1 Int ==> 3rd C1 inst C2 Int y, C1 (y,Bool) ==> 1st C1 inst C2 Int y, C1 y, C1 Bool ==> 2nd C1 inst C2 Int y, C1 y ==> C2 FD improvement {Int/y} <<<< C2 Int Int, C1 Int ==> C1 Int cycle detected C2 Int Int ==> C2 1st instance {} }}} It seems that you want improvement to happen at a higher priority than GHC does now." -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 18 05:25:08 2009 From: trac at galois.com (GHC) Date: Wed Mar 18 05:13:02 2009 Subject: [GHC] #3100: GHC Panic "reifyType PredTy" in HAppS.Data.IxSet.inferIxSet In-Reply-To: <049.c0071745bb9fd450cac603f8c5f89f94@localhost> References: <049.c0071745bb9fd450cac603f8c5f89f94@localhost> Message-ID: <058.43f7d95b2f3af650674bce48446797d7@localhost> #3100: GHC Panic "reifyType PredTy" in HAppS.Data.IxSet.inferIxSet -------------------------------+-------------------------------------------- Reporter: mightybyte | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Comment (by simonpj): I absolutely agree that GHC should not panic. I would love a reproducible test case that didn't involve all of `HappS`, if you have a moment to produce one. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 18 07:09:27 2009 From: trac at galois.com (GHC) Date: Wed Mar 18 06:57:22 2009 Subject: [GHC] #3109: GHCi won't start in a x84_64 machine Message-ID: <044.9e69222c5d31eab9169ab40af2f3bce5@localhost> #3109: GHCi won't start in a x84_64 machine -------------------+-------------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86_64 (amd64) -------------------+-------------------------------------------------------- I try 'ghci' in command line and it says: GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help ghc: internal error: mmap() returned memory outside 2Gb (GHC version 6.10.1 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted I'm using it in a "slice" machine, as provided by 'slicehost.com'. It seems to be a virtual server. I can choose my linux distribution, so I choosed 'archlinux' and did 'pacman -Sy' and 'pacman -Su'. Then, 'pacman -Su ghc'. Also: 'ghc --make' works well. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 18 08:09:39 2009 From: trac at galois.com (GHC) Date: Wed Mar 18 07:57:34 2009 Subject: [GHC] #3109: GHCi won't start in a x84_64 machine In-Reply-To: <044.9e69222c5d31eab9169ab40af2f3bce5@localhost> References: <044.9e69222c5d31eab9169ab40af2f3bce5@localhost> Message-ID: <053.b3edb8f9a92e62e6fe9eb3ebb2f6dc6f@localhost> #3109: GHCi won't start in a x84_64 machine -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: duplicate of #2063; please try 6.10.2 RC1 and let us know if that solves the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 18 13:50:36 2009 From: trac at galois.com (GHC) Date: Wed Mar 18 13:38:29 2009 Subject: [GHC] #3110: Setting the hard maximum heap size no longer works Message-ID: <043.e43ee2d00db6482c3a83848bfbddf8d0@localhost> #3110: Setting the hard maximum heap size no longer works -----------------------------+---------------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Take this source: {{{ main = do print (product [1..]) }}} Compile it: {{{ $ ghc -O2 A.hs --make -o A -fforce-recomp [1 of 1] Compiling Main ( A.hs, A.o ) Linking A ... }}} Set a small maximum heap size, run the program, then kill it after a few seconds: {{{ $ time ./A +RTS -M1M -sstderr ./A +RTS -M1M -sstderr ^C 20,177,576 bytes allocated in the heap 32,352 bytes copied during GC 18,840 bytes maximum residency (1 sample(s)) 20,888 bytes maximum slop 682 MB total memory in use (116 MB lost due to fragmentation) Generation 0: 38 collections, 0 parallel, 0.00s, 0.02s elapsed Generation 1: 1 collections, 0 parallel, 0.00s, 0.00s elapsed INIT time 0.00s ( 0.00s elapsed) MUT time 4.62s ( 5.24s elapsed) GC time 0.00s ( 0.02s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 4.62s ( 5.26s elapsed) %GC time 0.1% (0.4% elapsed) Alloc rate 4,370,879 bytes per MUT second Productivity 99.9% of total user, 87.8% of total elapsed ./A +RTS -M1M -sstderr 4.62s user 0.61s system 98% cpu 5.314 total }}} Far more memory has been allocated in the heap than the 1M max limit. GHC 6.10.1 on Linux x86_64. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 18 13:58:48 2009 From: trac at galois.com (GHC) Date: Wed Mar 18 13:46:41 2009 Subject: [GHC] #3110: Setting the hard maximum heap size no longer works In-Reply-To: <043.e43ee2d00db6482c3a83848bfbddf8d0@localhost> References: <043.e43ee2d00db6482c3a83848bfbddf8d0@localhost> Message-ID: <052.0deae51a23312c66a7cfaa3ebbcea9c3@localhost> #3110: Setting the hard maximum heap size no longer works ------------------------------+--------------------------------------------- Reporter: dons | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: invalid Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by dons): * status: new => closed * resolution: => invalid Comment: Looks like this might be the GC bug that's already fixed. Another example: {{{ main = do print (product s) print (sum s) where s = [1..] }}} With GHC 6.10.1 {{{ -bash-3.2$ ./A1 +RTS -sstderr -M4M ./A1 +RTS -sstderr -M4M 16,307,808 bytes allocated in the heap 3,982,800 bytes copied during GC 3,061,660 bytes maximum residency (3 sample(s)) 214,100 bytes maximum slop 2932 MB total memory in use (1204 MB lost due to fragmentation) Generation 0: 29 collections, 0 parallel, 0.02s, 0.03s elapsed Generation 1: 3 collections, 0 parallel, 0.02s, 3.06s elapsed INIT time 0.00s ( 0.00s elapsed) MUT time 10.27s ( 21.53s elapsed) GC time 0.04s ( 3.09s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 10.31s ( 24.62s elapsed) %GC time 0.4% (12.5% elapsed) Alloc rate 1,587,907 bytes per MUT second Productivity 99.6% of total user, 41.7% of total elapsed }}} It uses too much heap. With 6.10.2 it is fixed: {{{ -bash-3.2$ ./A1 +RTS -sstderr -M4M ./A1 +RTS -sstderr -M4M Heap exhausted; Current maximum heap size is 3997696 bytes (3 MB); use `+RTS -M' to increase it. 28,835,361,100 bytes allocated in the heap 8,082,024 bytes copied during GC 3,809,076 bytes maximum residency (5 sample(s)) 385,760 bytes maximum slop 17 MB total memory in use (11 MB lost due to fragmentation) Generation 0: 46743 collections, 0 parallel, 0.21s, 0.26s elapsed Generation 1: 5 collections, 0 parallel, 0.03s, 0.04s elapsed INIT time 0.00s ( 0.00s elapsed) MUT time 14.01s ( 14.10s elapsed) GC time 0.24s ( 0.31s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 14.25s ( 14.41s elapsed) %GC time 1.7% (2.1% elapsed) Alloc rate 2,058,198,508 bytes per MUT second Productivity 98.3% of total user, 97.2% of total elapsed }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 18 14:16:22 2009 From: trac at galois.com (GHC) Date: Wed Mar 18 14:04:37 2009 Subject: [GHC] #3111: Can't find DPH Message-ID: <050.65f6a7da171a14d95bacead6558ace4f@localhost> #3111: Can't find DPH ------------------------+--------------------------------------------------- Reporter: colin-adams | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.11 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86_64 (amd64) ------------------------+--------------------------------------------------- I added the following to the top of my module: {-# LANGUAGE PArr, ParallelListComp #-} {-# OPTIONS -fvectorise #-} But when building I got: GHC error in desugarer lookup in main:Board: Failed to load interface for `Data.Array.Parallel.Lifted.PArray': no package matching `dph-par' was found ghc: panic! (the 'impossible' happened) (GHC version 6.11.20090317 for x86_64-unknown-linux): initDs IOEnv failure Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug I hadn't done anything in particular to try to install DPH, so this is probably a user error, but as the panic occurred, i felt duty-bound to report the bug as requested. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 18 14:17:45 2009 From: trac at galois.com (GHC) Date: Wed Mar 18 14:05:38 2009 Subject: [GHC] #3093: -osuf and stub files results in incorrect extension In-Reply-To: <051.590aa254af3583c1e368881472d94175@localhost> References: <051.590aa254af3583c1e368881472d94175@localhost> Message-ID: <060.1d516fbb90c2796ec636f3c36e888535@localhost> #3093: -osuf and stub files results in incorrect extension ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 18 17:12:05 2009 From: trac at galois.com (GHC) Date: Wed Mar 18 16:59:59 2009 Subject: [GHC] #3039: strange space usage In-Reply-To: <044.6222a2241621a8a36e8604831e185979@localhost> References: <044.6222a2241621a8a36e8604831e185979@localhost> Message-ID: <053.af28149d380e5e6f076bd9758ad08b84@localhost> #3039: strange space usage ---------------------------------+------------------------------------------ Reporter: igloo | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 18 18:40:10 2009 From: trac at galois.com (GHC) Date: Wed Mar 18 18:28:05 2009 Subject: [GHC] #3095: ghc panic during parsing In-Reply-To: <046.eadbae504325bd8fb3c2e94084684add@localhost> References: <046.eadbae504325bd8fb3c2e94084684add@localhost> Message-ID: <055.6ff455f4af34259b777c82fd6c49bc7c@localhost> #3095: ghc panic during parsing -----------------------------------------+---------------------------------- Reporter: pweaver | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: Component: Compiler (Parser) | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: parser/should_fail/T3095 | Os: MacOS X Architecture: x86 | -----------------------------------------+---------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 18 18:39:54 2009 From: trac at galois.com (GHC) Date: Wed Mar 18 18:28:21 2009 Subject: [GHC] #3092: algebraic data types can be extended by data instance declarations In-Reply-To: <046.1e381a097b2d57aa86bcae417818322f@localhost> References: <046.1e381a097b2d57aa86bcae417818322f@localhost> Message-ID: <055.554cb19d26c8d523b706d17eba1edec6@localhost> #3092: algebraic data types can be extended by data instance declarations ------------------------------------------------+--------------------------- Reporter: jeltsch | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: indexed-types/should_fail/T3092 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ------------------------------------------------+--------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 18 18:40:39 2009 From: trac at galois.com (GHC) Date: Wed Mar 18 18:28:32 2009 Subject: [GHC] #3101: GHC crashes on synonym family in a rank-n type In-Reply-To: <060.de3c2f017546d5a5e7ab0795045c3fa8@localhost> References: <060.de3c2f017546d5a5e7ab0795045c3fa8@localhost> Message-ID: <069.c8f4b02041af9bb2dd32bd7b738d4b14@localhost> #3101: GHC crashes on synonym family in a rank-n type -------------------------------------------+-------------------------------- Reporter: MartijnVanSteenbergen | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: deriving/should_fail/T3101 | Os: MacOS X Architecture: Unknown/Multiple | -------------------------------------------+-------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 18 19:42:03 2009 From: trac at galois.com (GHC) Date: Wed Mar 18 19:29:57 2009 Subject: [GHC] #427: Random.StdGen slowness In-Reply-To: <044.910d2f7eb299e5f5b612cc8fccf049ef@localhost> References: <044.910d2f7eb299e5f5b612cc8fccf049ef@localhost> Message-ID: <053.fe07757dfd1f39a5417858bae407f143@localhost> #427: Random.StdGen slowness ---------------------------------+------------------------------------------ Reporter: remit | Owner: Type: bug | Status: new Priority: low | Milestone: _|_ Component: libraries/random | Version: Severity: normal | Resolution: None Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by Remi): Replying to [comment:16 dons]: > http://galois.com/~dons/tmp/seq-strict-random.dpatch > > Needs someone to test it now :-) I haven't done any benchmarking, but it doesn't fix the thunk-bomb: All getStdRandom does is call atomicModifyIORef, and when its result is not forced, that'll just atomically store a thunk... Perhaps it's time for atomicModifyIORef'? (That is, strict but still both atomic and fast.) What does work for the thunk-bomb problem is simply {{{ - getStdRandom f = atomicModifyIORef theStdGen (swap . f) + getStdRandom f = atomicModifyIORef theStdGen (swap . f) >>= (return $!) }}} That won't make it faster though. By the way, is anyone else interested in getting the current Random redesigned? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 19 04:04:22 2009 From: trac at galois.com (GHC) Date: Thu Mar 19 03:52:35 2009 Subject: [GHC] #3111: Can't find DPH In-Reply-To: <050.65f6a7da171a14d95bacead6558ace4f@localhost> References: <050.65f6a7da171a14d95bacead6558ace4f@localhost> Message-ID: <059.c08d00cb7826e445d708eeb7917c3c23@localhost> #3111: Can't find DPH -------------------------------+-------------------------------------------- Reporter: colin-adams | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by simonpj): * difficulty: => Unknown Old description: > I added the following to the top of my module: > > {-# LANGUAGE PArr, ParallelListComp #-} > {-# OPTIONS -fvectorise #-} > > But when building I got: > > GHC error in desugarer lookup in main:Board: > Failed to load interface for `Data.Array.Parallel.Lifted.PArray': > no package matching `dph-par' was found > ghc: panic! (the 'impossible' happened) > (GHC version 6.11.20090317 for x86_64-unknown-linux): > initDs IOEnv failure > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > I hadn't done anything in particular to try to install DPH, so this is > probably a user error, but as the panic occurred, i felt duty-bound to > report the bug as requested. New description: I added the following to the top of my module: {{{ {-# LANGUAGE PArr, ParallelListComp #-} {-# OPTIONS -fvectorise #-} }}} But when building I got: {{{ GHC error in desugarer lookup in main:Board: Failed to load interface for `Data.Array.Parallel.Lifted.PArray': no package matching `dph-par' was found ghc: panic! (the 'impossible' happened) (GHC version 6.11.20090317 for x86_64-unknown-linux): initDs IOEnv failure Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I hadn't done anything in particular to try to install DPH, so this is probably a user error, but as the panic occurred, i felt duty-bound to report the bug as requested. Comment: What's gone wrong is that you need the DPH packages installed, else the DPH extensions won't work at all: http://haskell.org/haskellwiki/GHC/Data_Parallel_Haskell. Right, it's a bug that GHC crashes rather than giving a civilised error message. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 19 04:23:29 2009 From: trac at galois.com (GHC) Date: Thu Mar 19 04:11:44 2009 Subject: [GHC] #3111: Can't find DPH In-Reply-To: <050.65f6a7da171a14d95bacead6558ace4f@localhost> References: <050.65f6a7da171a14d95bacead6558ace4f@localhost> Message-ID: <059.1afcec8d58ac1846f86de4c9f52f8a61@localhost> #3111: Can't find DPH -------------------------------+-------------------------------------------- Reporter: colin-adams | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Comment (by colin-adams): That's what I thought, on both counts. The instructions for installing the DPH packages fail at the first hurdle. Should I open a separate ticket for this, or just write an email on the ghc list? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 19 09:53:34 2009 From: trac at galois.com (GHC) Date: Thu Mar 19 09:41:52 2009 Subject: [GHC] #3111: Can't find DPH In-Reply-To: <050.65f6a7da171a14d95bacead6558ace4f@localhost> References: <050.65f6a7da171a14d95bacead6558ace4f@localhost> Message-ID: <059.a50b54abf132413c42866c26188a35d7@localhost> #3111: Can't find DPH -------------------------------+-------------------------------------------- Reporter: colin-adams | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Comment (by chak): Replying to [comment:2 colin-adams]: > That's what I thought, on both counts. > > The instructions for installing the DPH packages fail at the first hurdle. Should I open a separate ticket for this, or just write an email on the ghc list? Just tell us. What is the first hurdle? As you report the error against 6.11, I am wondering how you obtained the compiler? Did you get it via darcs or as a nightly snapshot? In the latter case, I don't think there is a straight forward way of adding package DPH as I don't think we have snapshots for it. If you get GHC from the darcs repo, getting dph is very easy. Just run {{{ ./darcs-all --dph get }}} in your local ghc repository. Then, build the compiler as usual. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 19 10:02:40 2009 From: trac at galois.com (GHC) Date: Thu Mar 19 09:52:13 2009 Subject: [GHC] #1673: Template Haskell support for type families In-Reply-To: <065.e2dcaba876dc26f94848b54efa34a3d4@localhost> References: <065.e2dcaba876dc26f94848b54efa34a3d4@localhost> Message-ID: <074.e6a9ffcca276c2357eef645f3d668675@localhost> #1673: Template Haskell support for type families -------------------------------------------+-------------------------------- Reporter: g9ks157k@acme.softbase.org | Owner: Type: feature request | Status: closed Priority: high | Milestone: 6.12 branch Component: Template Haskell | Version: 6.7 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -------------------------------------------+-------------------------------- Changes (by chak): * status: new => closed * resolution: => fixed Comment: I just pushed patches adding support for type family declarations (toplevel and associated) and equality constraints to TH. The downside is that it changes the API of `Language.Haskell.TH` in an incompatible way (to distinguish between class constraints and equality constraints). Given that I had to change the API anyways, we agreed to add kinds, too. I'll do that in the next few days, but it'll change the API even a bit more. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 19 10:23:13 2009 From: trac at galois.com (GHC) Date: Thu Mar 19 10:11:04 2009 Subject: [GHC] #3112: GHCI Crashes on self referential local variable Message-ID: <042.ad9462c67a5732d3bc70746ecfbce8d1@localhost> #3112: GHCI Crashes on self referential local variable --------------------+------------------------------------------------------- Reporter: dvs | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Windows | Architecture: x86 --------------------+------------------------------------------------------- {{{ f :: Int -> Int f x = let p = x*x in let p = p*x in p }}} Causes a segfault of GHCI on Windows XP Service Pack 2, and unbounded memory consumption on Linux. There is no output when the crash occurs, after invoking the function (for example f 7) it just immediately drops back to a command prompt in Windows. I would expect some sort of error message to be printed, perhaps , and then return gracefully to the GHCI prompt. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 19 15:12:52 2009 From: trac at galois.com (GHC) Date: Thu Mar 19 15:00:44 2009 Subject: [GHC] #2284: Stack-hack optimization causes much re-computation in GUI callbacks In-Reply-To: <048.962fc54d8c39b16cf1f38c360fbbf18e@localhost> References: <048.962fc54d8c39b16cf1f38c360fbbf18e@localhost> Message-ID: <057.1ca6e8beca1a7f6802e31e929fb5e4fb@localhost> #2284: Stack-hack optimization causes much re-computation in GUI callbacks ---------------------------------+------------------------------------------ Reporter: sedillard | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by JulesBean): * cc: JulesBean (added) Comment: I have a duplicate of this bug. I have code which does something like: {{{ params <- actionToGetParams let structure = veryExpensivePureOperation params displayCallback $= (display structure) }}} and it is easily observed that structure is being recomputed every time the callback is called. In fact, -fno-state-hack speeds up my program from 110fps to 400fps, a substantial improvement. Count this as a vote for a solution to this bug... -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 20 06:37:52 2009 From: trac at galois.com (GHC) Date: Fri Mar 20 06:25:40 2009 Subject: [GHC] #3113: -fdisambiguate-record-fields does not exist anymore Message-ID: <044.5adad4a89cba6b41e77da383c01017ad@localhost> #3113: -fdisambiguate-record-fields does not exist anymore -----------------------------+---------------------------------------------- Reporter: fasta | Owner: Type: bug | Status: new Priority: normal | Component: Documentation Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- ghc: unrecognised flags: -fdisambiguate-record-fields and Haskell 98 regards all four as ambiguous, but with the -fdisambiguate-record-fields flag, GHC will accept the former two. => universe exploded. It seems that either the documentation is wrong or the implementation is wrong. -XDisambiguateRecordFields is the new option. The documentation and man page should just be updated. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 20 06:45:13 2009 From: trac at galois.com (GHC) Date: Fri Mar 20 06:33:02 2009 Subject: [GHC] #1185: can't do I/O in the child of forkProcess with -threaded In-Reply-To: <047.505ed9940eff9ef82094c96c7212dfa3@localhost> References: <047.505ed9940eff9ef82094c96c7212dfa3@localhost> Message-ID: <056.7b7c8456b495ccfa0ff8119b370aed4c@localhost> #1185: can't do I/O in the child of forkProcess with -threaded ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Runtime System | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): Here's the sample code that demonstrates the problem, from [http://www.haskell.org/pipermail/glasgow-haskell- users/2007-March/012062.html], with an extra `threadDelay` inserted to make the hang show up more reliably: {{{ module Main where import Control.Concurrent import System.Posix import System.IO import System.Exit main = do putStrLn "running..." (stdinr, stdinw) <- createPipe (stdoutr, stdoutw) <- createPipe pid <- forkProcess $ do hw <- fdToHandle stdoutw hr <- fdToHandle stdinr closeFd stdinw hGetContents hr >>= hPutStr hw hClose hr hClose hw exitImmediately ExitSuccess threadDelay 100000 closeFd stdoutw closeFd stdinw hr2 <- fdToHandle stdoutr hGetContents hr2 >>= putStr getProcessStatus True False pid >>= print }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 20 11:03:29 2009 From: trac at galois.com (GHC) Date: Fri Mar 20 10:51:17 2009 Subject: [GHC] #3112: GHCI Crashes on self referential local variable In-Reply-To: <042.ad9462c67a5732d3bc70746ecfbce8d1@localhost> References: <042.ad9462c67a5732d3bc70746ecfbce8d1@localhost> Message-ID: <051.0a46dd4505763fd45d233cf89a194b1e@localhost> #3112: GHCI Crashes on self referential local variable -------------------------+-------------------------------------------------- Reporter: dvs | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: same bug as #2783, fixed in 6.10.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 20 12:02:50 2009 From: trac at galois.com (GHC) Date: Fri Mar 20 11:50:39 2009 Subject: [GHC] #2891: threadDelay appears to use excessive CPU in GHCi In-Reply-To: <049.e486b1f0b04e32b03f5954cc3c1db385@localhost> References: <049.e486b1f0b04e32b03f5954cc3c1db385@localhost> Message-ID: <058.2c9d44dd4f2026ec5a8869a6a016408f@localhost> #2891: threadDelay appears to use excessive CPU in GHCi ---------------------------+------------------------------------------------ Reporter: JeremyShaw | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ---------------------------+------------------------------------------------ Comment (by JeremyShaw): ok, I'll have to investigate more. Idle happstack applications under GHCi will sometimes use 20-50% of the CPU, but we don't seem to see the same issue when apps are compiled. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 20 13:55:45 2009 From: trac at galois.com (GHC) Date: Fri Mar 20 13:50:03 2009 Subject: [GHC] #3106: hundred failures of release candidate ghc-6.10.1.20090314 in testsuite In-Reply-To: <045.ed77f144615446c295cf993e7e3ad16f@localhost> References: <045.ed77f144615446c295cf993e7e3ad16f@localhost> Message-ID: <054.e9e05e2305c10199a1a548cb89ae1ae0@localhost> #3106: hundred failures of release candidate ghc-6.10.1.20090314 in testsuite ---------------------------+------------------------------------------------ Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: x86 | ---------------------------+------------------------------------------------ Changes (by igloo): * difficulty: => Unknown Comment: Looking at the fast test log, I think we'll need to look at a log of the testsuite after I've pushed the cygpath fix to get reasonable output. One thing I did notice is in the `cabal01` test: {{{ tar: C: unknown function modifier Usage: tar {c|r|t|u|x}[BDeEFhilmnopPqTvw@[0-7]][bfk][X...] [blocksize] [tarfile] [size] [exclude-file...] {file | -I include-file | -C directory file}... }}} and we're running: {{{ ("/bin/tar",["-C","dist/src","-czf","dist/test-1.0.tar.gz","test-1.0"]) }}} so am I right in thinking that {{{ ("/bin/tar",["-czf","dist/test-1.0.tar.gz","-C","dist/src","test-1.0"]) }}} would work? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 20 14:30:10 2009 From: trac at galois.com (GHC) Date: Fri Mar 20 14:18:24 2009 Subject: [GHC] #3103: Compiling base with cabal fails. In-Reply-To: <045.1ec9768c2c79e83b67fadc73a8306022@localhost> References: <045.1ec9768c2c79e83b67fadc73a8306022@localhost> Message-ID: <054.8786a38a1337fbde07b86b9be983fa5e@localhost> #3103: Compiling base with cabal fails. ---------------------------------+------------------------------------------ Reporter: Lemmih | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12 branch Comment: This is also reproducible with {{{ make rebuild.library.base }}} in `libraries/` in a GHC build tree. (note: `rebuild`, rather than the normal `remake`. It uses Cabal to build, and thus ultimately ends up using `ghc --make`). This did work at one point, but I don't know how long ago it broke. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 20 15:05:13 2009 From: trac at galois.com (GHC) Date: Fri Mar 20 14:59:29 2009 Subject: [GHC] #3106: hundred failures of release candidate ghc-6.10.1.20090314 in testsuite In-Reply-To: <045.ed77f144615446c295cf993e7e3ad16f@localhost> References: <045.ed77f144615446c295cf993e7e3ad16f@localhost> Message-ID: <054.4242e61c72dd02df24ccfb1dd9894c14@localhost> #3106: hundred failures of release candidate ghc-6.10.1.20090314 in testsuite ---------------------------+------------------------------------------------ Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: x86 | ---------------------------+------------------------------------------------ Comment (by kgardas): Probably not, since this is Solaris' tar and it does not support -z option, i.e. tarring directly to .tar.gz file... -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 20 15:16:20 2009 From: trac at galois.com (GHC) Date: Fri Mar 20 15:04:07 2009 Subject: [GHC] #3091: With Python 2.5.1c1, validate ends "... runtests.py ... ValueError: invalid literal for int() with base 10: '1c1'" In-Reply-To: <050.5a9df3553657e07ae53a66b55449ea01@localhost> References: <050.5a9df3553657e07ae53a66b55449ea01@localhost> Message-ID: <059.e9114181cae349d515dd9a6d31cc36a1@localhost> #3091: With Python 2.5.1c1, validate ends "... runtests.py ... ValueError: invalid literal for int() with base 10: '1c1'" ---------------------------------+------------------------------------------ Reporter: thorkilnaur | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * owner: => igloo * difficulty: => Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 20 15:50:06 2009 From: trac at galois.com (GHC) Date: Fri Mar 20 15:44:17 2009 Subject: [GHC] #3106: hundred failures of release candidate ghc-6.10.1.20090314 in testsuite In-Reply-To: <045.ed77f144615446c295cf993e7e3ad16f@localhost> References: <045.ed77f144615446c295cf993e7e3ad16f@localhost> Message-ID: <054.b99d1a056c90a23f5fc1494a4947d07c@localhost> #3106: hundred failures of release candidate ghc-6.10.1.20090314 in testsuite ---------------------------+------------------------------------------------ Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: x86 | ---------------------------+------------------------------------------------ Comment (by igloo): Good point. Currently the code (in Cabal's `Distribution/Simple/SrcDist.hs`) is: {{{ let tarBallFilePath = targetPref tarBallName pkg_descr <.> "tar.gz" rawSystemProgram verbosity tarProg ["-C", tmpDir, "-czf", tarBallFilePath, tarBallName pkg_descr] return tarBallFilePath }}} So I think we want this instead: {{{ let tarFilePath = targetPref tarBallName pkg_descr <.> "tar" tarBallFilePath = tarFilePath <.> "gz" rawSystemProgram verbosity tarProg ["-cf", tarFilePath, "-C", tmpDir, tarBallName pkg_descr] rawSystemProgram verbosity gzipProg [tarFilePath] removeFile tarFilePath return tarBallFilePath }}} A couple of problems: * We don't actually tell gzip where to put the output, but I can't see a way to do so without messing with stdout * We will have to add `gzipProg`, thus changing the API It feels to me like the right thing to do though. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 20 16:03:39 2009 From: trac at galois.com (GHC) Date: Fri Mar 20 15:52:36 2009 Subject: [GHC] #2063: x86_64: RTS linker depends on working MAP_32BIT In-Reply-To: <043.15abf9ca319b437728a2421245ad0407@localhost> References: <043.15abf9ca319b437728a2421245ad0407@localhost> Message-ID: <052.6deb6aec06b35599055982f5b608ebc8@localhost> #2063: x86_64: RTS linker depends on working MAP_32BIT -------------------------------+-------------------------------------------- Reporter: dons | Owner: Type: task | Status: new Priority: high | Milestone: 6.10.2 Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: OpenBSD, Xen | Difficulty: Moderate (1 day) Testcase: | Os: Unknown/Multiple Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by korpios): * cc: korpios@korpios.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 20 16:00:58 2009 From: trac at galois.com (GHC) Date: Fri Mar 20 15:55:09 2009 Subject: [GHC] #3106: hundred failures of release candidate ghc-6.10.1.20090314 in testsuite In-Reply-To: <045.ed77f144615446c295cf993e7e3ad16f@localhost> References: <045.ed77f144615446c295cf993e7e3ad16f@localhost> Message-ID: <054.346f5d2f8f09239bb0a448a7faf97cae@localhost> #3106: hundred failures of release candidate ghc-6.10.1.20090314 in testsuite ---------------------------+------------------------------------------------ Reporter: maeder | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: x86 | ---------------------------+------------------------------------------------ Changes (by igloo): * owner: => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 20 16:22:05 2009 From: trac at galois.com (GHC) Date: Fri Mar 20 16:09:59 2009 Subject: [GHC] #2635: ghc panic In-Reply-To: <044.5ed00131488dc69dfc402e9550007157@localhost> References: <044.5ed00131488dc69dfc402e9550007157@localhost> Message-ID: <053.4dcf6e134e2e23d9d5d68e54686a903b@localhost> #2635: ghc panic -------------------------+-------------------------------------------------- Reporter: jorzo | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: powerpc | -------------------------+-------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => invalid Comment: I'm closing this ticket, as it seems likely the issues the original reporter faced were due to the emulator, and we've heard nothing for several months. mokeefe, if you want to report a different issue then please open a new ticket. However, your problem isn't ringing any bells with me, so I'd recommend upgrading to 6.10.1 (using the installer on the download page) and see if the problem happens again. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 20 17:06:11 2009 From: trac at galois.com (GHC) Date: Fri Mar 20 16:53:58 2009 Subject: [GHC] #3096: Dead links in GHC documentation In-Reply-To: <044.239148f9eee868941b189fd27f48a1d1@localhost> References: <044.239148f9eee868941b189fd27f48a1d1@localhost> Message-ID: <053.977f3150b490f901caf29e78c2b59144@localhost> #3096: Dead links in GHC documentation ---------------------------------+------------------------------------------ Reporter: tibbe | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: Fixed; thanks for the report. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 20 18:46:52 2009 From: trac at galois.com (GHC) Date: Fri Mar 20 18:34:50 2009 Subject: [GHC] #3114: ghc -shared --make Teapot.hs (Failed using OpenGL) Message-ID: <052.079c60d812f2d30299cbb39a250d1778@localhost> #3114: ghc -shared --make Teapot.hs (Failed using OpenGL) --------------------------------+------------------------------------------- Reporter: Mark_Spezzano | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: command line option | Testcase: Os: Windows | Architecture: x86 --------------------------------+------------------------------------------- I was just experimenting with the compiler options and for some reason I decided to stick -shared in there (it's not needed for compilation: ghc --make Teapot.hs does the trick). I got this error message: C:\Users\Mark\workspace2\OpenGLPractice\src>ghc -shared --make Teapot.hs [1 of 1] Compiling Main ( Teapot.hs, Teapot.o ) ghc: panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-unknown-mingw32): link: GHC not built to link this way: LinkDynLib Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Mar 21 07:00:21 2009 From: trac at galois.com (GHC) Date: Sat Mar 21 06:48:17 2009 Subject: [GHC] #1897: Ambiguous types and rejected type signatures In-Reply-To: <044.e733a0c0c6af2d1a744b7039f7ad31a7@localhost> References: <044.e733a0c0c6af2d1a744b7039f7ad31a7@localhost> Message-ID: <053.7a9b96f644f8d430a4dd6e01fb369e7b@localhost> #1897: Ambiguous types and rejected type signatures ----------------------------------------+----------------------------------- Reporter: guest | Owner: chak Type: bug | Status: reopened Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ----------------------------------------+----------------------------------- Comment (by jim.stuttard): I don't know whether there's been a regression but with Andres Loh's example i2 with: >{-# TypeFamilies, EmptyDataDecls, RankNTypes #-} >type family Y (a::*) >i2 :: (forall a. a -> Y a) -> Y Bool >i2 x = x True I got: "ghc panic! .. (GHC version 6.10.1 for i386-unknown-linux TcTyFuns.flattenType: synonym family in a rank-n type" uname -a: Linux eeepc 2.26.28-ARCH ghc -v: ghc-6.10.1 i386-unknown-linux There's a lot to more to forall than meets the eye :) Jim -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Mar 21 07:04:31 2009 From: trac at galois.com (GHC) Date: Sat Mar 21 06:52:22 2009 Subject: [GHC] #1897: Ambiguous types and rejected type signatures In-Reply-To: <044.e733a0c0c6af2d1a744b7039f7ad31a7@localhost> References: <044.e733a0c0c6af2d1a744b7039f7ad31a7@localhost> Message-ID: <053.392b510986f6152a6a89bcc919841751@localhost> #1897: Ambiguous types and rejected type signatures ----------------------------------------+----------------------------------- Reporter: guest | Owner: chak Type: bug | Status: reopened Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ----------------------------------------+----------------------------------- Comment (by jim.stuttard): with >i2 x = x True -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Mar 21 09:24:52 2009 From: trac at galois.com (GHC) Date: Sat Mar 21 09:12:35 2009 Subject: [GHC] #3091: With Python 2.5.1c1, validate ends "... runtests.py ... ValueError: invalid literal for int() with base 10: '1c1'" In-Reply-To: <050.5a9df3553657e07ae53a66b55449ea01@localhost> References: <050.5a9df3553657e07ae53a66b55449ea01@localhost> Message-ID: <059.06c133113f0e8fc11b749164d32dc79c@localhost> #3091: With Python 2.5.1c1, validate ends "... runtests.py ... ValueError: invalid literal for int() with base 10: '1c1'" ---------------------------------+------------------------------------------ Reporter: thorkilnaur | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: Component: Test Suite | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Thanks for the report. I couldn't see a nice way to fix this, so I kludged around it with a regexp: {{{ maj = int(re.sub('[^0-9].*', '', maj)) min = int(re.sub('[^0-9].*', '', min)) pat = int(re.sub('[^0-9].*', '', pat)) }}} Fixed by: {{{ Fri Mar 20 19:16:08 GMT 2009 Ian Lynagh * Fix trac #3091: the driver was choking on python versions containing letters }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Mar 21 10:22:03 2009 From: trac at galois.com (GHC) Date: Sat Mar 21 10:16:16 2009 Subject: [GHC] #3106: hundred failures of release candidate ghc-6.10.1.20090314 in testsuite In-Reply-To: <045.ed77f144615446c295cf993e7e3ad16f@localhost> References: <045.ed77f144615446c295cf993e7e3ad16f@localhost> Message-ID: <054.27a231a601693593a3be25521866408c@localhost> #3106: hundred failures of release candidate ghc-6.10.1.20090314 in testsuite ---------------------------+------------------------------------------------ Reporter: maeder | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: x86 | ---------------------------+------------------------------------------------ Comment (by duncan): Aye, we really shouldn't be relying on the external tar anyway. In cabal- install we do all that in Haskell code which makes it portable to Windows and Solaris. Is this needed to build ghc on Solaris or is it just the Cabal sdist test failure that you're worried about? If it's just the test case we're worried about then I'm not sure there's a great deal of point in making `Setup sdist` work for Solaris when it sill will not work for Windows and we've already got `cabal sdist` which works on both. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Mar 21 14:10:13 2009 From: trac at galois.com (GHC) Date: Sat Mar 21 13:58:09 2009 Subject: [GHC] #1897: Ambiguous types and rejected type signatures In-Reply-To: <044.e733a0c0c6af2d1a744b7039f7ad31a7@localhost> References: <044.e733a0c0c6af2d1a744b7039f7ad31a7@localhost> Message-ID: <053.7dab9c2e86c7596f841c2d310064f42b@localhost> #1897: Ambiguous types and rejected type signatures ----------------------------------------+----------------------------------- Reporter: guest | Owner: chak Type: bug | Status: reopened Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ----------------------------------------+----------------------------------- Comment (by jim.stuttard): what's wrong with this WikiFormatting? 1 blank line = zero blank lines. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Mar 21 15:59:05 2009 From: trac at galois.com (GHC) Date: Sat Mar 21 15:46:53 2009 Subject: [GHC] #2965: GHC on OS X does not compile 64-bit In-Reply-To: <045.2214e7d1fe4dd43486128c197fdb9227@localhost> References: <045.2214e7d1fe4dd43486128c197fdb9227@localhost> Message-ID: <054.e588fb0743ee93699cce57bb4e2ccf72@localhost> #2965: GHC on OS X does not compile 64-bit --------------------------------+------------------------------------------- Reporter: Axman6 | Owner: thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: Severity: normal | Resolution: Keywords: 64bit | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86_64 (amd64) | --------------------------------+------------------------------------------- Changes (by thoughtpolice): * keywords: => 64bit * owner: => thoughtpolice * version: 6.10.1 => * cc: mad.one@gmail.com (added) Comment: There seems to already be support for the `x86_64-apple-darwin` target in configure.ac; running configure like so: {{{./configure --build=x86_64-apple-darwin}}} results in x86_64_HOST_ARCH being defined throughout. The Stage1 compiler seems to mostly build after this; the first failure is in Adjustor.c because as Manuel said the runtime system isn't designed to handle 64bit OS X yet - the code path indeed needs to be split. I'm taking over this ticket because I'm interested in getting it working; 64bit support is already there and it would be nice to have on OS X. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Mar 21 16:33:37 2009 From: trac at galois.com (GHC) Date: Sat Mar 21 16:21:22 2009 Subject: [GHC] #2362: allow full import syntax in GHCi In-Reply-To: <051.a17c861cfc196911194c3abd0e428c4d@localhost> References: <051.a17c861cfc196911194c3abd0e428c4d@localhost> Message-ID: <060.4ab4aff7c32c72c79ce2434dbdf73609@localhost> #2362: allow full import syntax in GHCi ---------------------------------+------------------------------------------ Reporter: Isaac Dupree | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: ghci, import | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by thoughtpolice): Given the example that `:load` can load up qualified names as seen above, I don't think this would be too hard to add; if this is to be done, the GHC API seems like the best place to make the change, so ghc-api clients can use it too (like lambdabot.) Since everything is basically wrapped in a do block, should we just extend that to allow full haskell98-style imports? e.g. {{{ *Prelude> import Data.ByteString.Char8 (pack) *Prelude Data.ByteString.Char8> import qualified Data.ByteString.Char8 as B *Prelude Data.ByteString.Char8 B> let x = pack "hi" *Prelude Data.ByteString.Char8 B> B.length x 2 *Prelude Data.ByteString.Char8 B> }}} Or, should we only allow GHCi to import things this way? Perhaps by just making an `:import` command or extending `:module` to allow full import syntax? Something like, {{{ *Prelude>:m +qualified Data.Text as T *Prelude T>:t T.null T.Text *Prelude T>:m-T *Prelude> }}} Trac #1895 seems to indicate that several people want this feature, so I'm wondering if anybody has any objections/sees any problems, or has a better idea? I'd be willing to try and work on this for 6.12 if we can get an idea of what we want. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Mar 21 16:33:57 2009 From: trac at galois.com (GHC) Date: Sat Mar 21 16:21:41 2009 Subject: [GHC] #2362: allow full import syntax in GHCi In-Reply-To: <051.a17c861cfc196911194c3abd0e428c4d@localhost> References: <051.a17c861cfc196911194c3abd0e428c4d@localhost> Message-ID: <060.37edccbf7ca1245bc9c7b9db1fcaf731@localhost> #2362: allow full import syntax in GHCi ---------------------------------+------------------------------------------ Reporter: Isaac Dupree | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: ghci, import | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by thoughtpolice): * cc: mad.one@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Mar 21 18:55:41 2009 From: trac at galois.com (GHC) Date: Sat Mar 21 18:49:52 2009 Subject: [GHC] #3106: hundred failures of release candidate ghc-6.10.1.20090314 in testsuite In-Reply-To: <045.ed77f144615446c295cf993e7e3ad16f@localhost> References: <045.ed77f144615446c295cf993e7e3ad16f@localhost> Message-ID: <054.399b804c3de8a04f4dfebcb57fc4ad03@localhost> #3106: hundred failures of release candidate ghc-6.10.1.20090314 in testsuite ---------------------------+------------------------------------------------ Reporter: maeder | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: Component: Test Suite | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: x86 | ---------------------------+------------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: OK, I've filed the Cabal sdist problem here: http://hackage.haskell.org/trac/hackage/ticket/529 For 6.10.2 we have a reasonable workaround: Use `cabal sdist` instead. Also, I've uploaded a more up-to-date testsuite tarball as: http://www.haskell.org/ghc/dist/6.10.2-rc1/testsuite-6.10.1.20090321.tar.gz With it, I'm seeing these failures: {{{ 2469(ghci) Simple3a(normal) T3092(normal) T3095(normal) T3101(normal) apirecomp001(normal) driver018a(normal) ghcpkg02(normal) ghcpkg05(normal) openFile008(threaded2) tcfail086(normal) }}} of which only `openFile008(threaded2)` looks like a real problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 22 13:29:12 2009 From: trac at galois.com (GHC) Date: Sun Mar 22 13:16:55 2009 Subject: [GHC] #3115: mark ghc.cabal so that unsuspecting newbies don't try to edit it Message-ID: <041.3492cffcfd5dec50c06af45bac79589d@localhost> #3115: mark ghc.cabal so that unsuspecting newbies don't try to edit it -----------------------------+---------------------------------------------- Reporter: nr | Owner: Type: feature request | Status: new Priority: normal | Component: Build System Version: 6.11 | Severity: minor Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Please change the configure/build system so that (a) ghc.cabal is not writable and (b) it contains a comment at the top saying that people wishing to add source files to the compiler should extend file ghc.cabal.in and re-run ../configure; they should ''not'' edit ghc.cabal directly. I know of two people who have fallen into this pit; let's not have any more. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 22 23:20:18 2009 From: trac at galois.com (GHC) Date: Sun Mar 22 23:08:34 2009 Subject: [GHC] #2812: For ghci, drop editline in favour of haskeline In-Reply-To: <044.83b1cb097467eb96264cb87a3cc1f7c9@localhost> References: <044.83b1cb097467eb96264cb87a3cc1f7c9@localhost> Message-ID: <053.0198d56aff159f0c6f26be5896b0dc77@localhost> #2812: For ghci, drop editline in favour of haskeline ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: task | Status: new Priority: high | Milestone: 6.12 branch Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by korpios): * cc: korpios@korpios.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 22 23:23:25 2009 From: trac at galois.com (GHC) Date: Sun Mar 22 23:11:37 2009 Subject: [GHC] #2812: For ghci, drop editline in favour of haskeline In-Reply-To: <044.83b1cb097467eb96264cb87a3cc1f7c9@localhost> References: <044.83b1cb097467eb96264cb87a3cc1f7c9@localhost> Message-ID: <053.c81ec6c042edae6a43692fcf5ad52f21@localhost> #2812: For ghci, drop editline in favour of haskeline ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: task | Status: new Priority: high | Milestone: 6.12 branch Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by dons): haskellline's flags don't reassure me: {{{ Extensions: ForeignFunctionInterface, RankNTypes, FlexibleInstances, TypeSynonymInstances FlexibleContexts, ExistentialQuantification ScopedTypeVariables, GeneralizedNewtypeDeriving MultiParamTypeClasses, OverlappingInstances PatternSignatures, CPP, DeriveDataTypeable, PatternGuards }}} There's command line history code in yi that's haskell98... -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 23 05:24:01 2009 From: trac at galois.com (GHC) Date: Mon Mar 23 05:18:06 2009 Subject: [GHC] #3106: hundred failures of release candidate ghc-6.10.1.20090314 in testsuite In-Reply-To: <045.ed77f144615446c295cf993e7e3ad16f@localhost> References: <045.ed77f144615446c295cf993e7e3ad16f@localhost> Message-ID: <054.3f355c9a40f1c1962609d9ec199d45cb@localhost> #3106: hundred failures of release candidate ghc-6.10.1.20090314 in testsuite ---------------------------+------------------------------------------------ Reporter: maeder | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: Component: Test Suite | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: x86 | ---------------------------+------------------------------------------------ Comment (by maeder): Replying to [comment:8 igloo]: > One thing I did notice is in the `cabal01` test: > {{{ tar: C: unknown function modifier Usage: tar {c|r|t|u|x}[BDeEFhilmnopPqTvw@[0-7]][bfk][X...] [blocksize] [tarfile] [size] [exclude-file...] {file | -I include-file | -C directory file}... }}} use `gtar` under Solaris! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 23 05:44:00 2009 From: trac at galois.com (GHC) Date: Mon Mar 23 05:31:39 2009 Subject: [GHC] #2362: allow full import syntax in GHCi In-Reply-To: <051.a17c861cfc196911194c3abd0e428c4d@localhost> References: <051.a17c861cfc196911194c3abd0e428c4d@localhost> Message-ID: <060.4c62b9671346f2d5c7675fceb55fcb44@localhost> #2362: allow full import syntax in GHCi ---------------------------------+------------------------------------------ Reporter: Isaac Dupree | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: ghci, import | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): I think it should be part of the GHC API, as a generalisation of API used by `:module` (`setContext`). Perhaps `setContext` should take a `[ImportDecl]`, and we'd also need a way to parse a `String` into an `ImportDecl`. We also need to think about how to handle `import *M`. For the implementation itself, a good place to start seems to be `RnNames.rnImports`, which returns a `GlobalRdrEnv` - exactly what we need to put in the `InteractiveContext`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 23 05:48:01 2009 From: trac at galois.com (GHC) Date: Mon Mar 23 05:36:16 2009 Subject: [GHC] #2812: For ghci, drop editline in favour of haskeline In-Reply-To: <044.83b1cb097467eb96264cb87a3cc1f7c9@localhost> References: <044.83b1cb097467eb96264cb87a3cc1f7c9@localhost> Message-ID: <053.7c9acac9794727f672c5a3915884e7c1@localhost> #2812: For ghci, drop editline in favour of haskeline ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: task | Status: new Priority: high | Milestone: 6.12 branch Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): Replying to [comment:6 dons]: > haskellline's flags don't reassure me: > > {{{ > Extensions: ForeignFunctionInterface, RankNTypes, FlexibleInstances, > TypeSynonymInstances > FlexibleContexts, ExistentialQuantification > ScopedTypeVariables, GeneralizedNewtypeDeriving > MultiParamTypeClasses, OverlappingInstances > PatternSignatures, CPP, DeriveDataTypeable, > PatternGuards > }}} > > There's command line history code in yi that's haskell98... Why does it need to be haskell98? Just wondering. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 23 06:19:21 2009 From: trac at galois.com (GHC) Date: Mon Mar 23 06:07:04 2009 Subject: [GHC] #3115: mark ghc.cabal so that unsuspecting newbies don't try to edit it In-Reply-To: <041.3492cffcfd5dec50c06af45bac79589d@localhost> References: <041.3492cffcfd5dec50c06af45bac79589d@localhost> Message-ID: <050.42964353e983b0f323190cb6c0a49819@localhost> #3115: mark ghc.cabal so that unsuspecting newbies don't try to edit it ---------------------------------+------------------------------------------ Reporter: nr | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Build System | Version: 6.11 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * difficulty: => Unknown * milestone: => 6.12 branch Comment: let's do this in the new build system. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 23 07:38:26 2009 From: trac at galois.com (GHC) Date: Mon Mar 23 07:26:04 2009 Subject: [GHC] #3116: missed optimisation opportunity with lazy ByteStrings Message-ID: <045.11aa093a8bb570bc9aa8e63dfc895a71@localhost> #3116: missed optimisation opportunity with lazy ByteStrings -----------------------------+---------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- With strict `ByteString` an a simple tail recursive iteration pattern we get perfect code. First the definitions: {{{ data ByteString = BS {-# UNPACK #-} !(ForeignPtr Word8) -- payload {-# UNPACK #-} !Int -- offset {-# UNPACK #-} !Int -- length null :: ByteString -> Bool null (BS _ _ l) = l <= 0 tail :: ByteString -> ByteString tail (BS p s l) | l <= 0 = error "ByteString.tail: empty ByteString" | otherwise = BS p (s+1) (l-1) }}} Now a trivial iteration pattern: {{{ length :: ByteString -> Int length = go 0 where go !n bs | null bs = n | otherwise = go (n+1) (tail bs) }}} Perfect core code (edited for clarity): {{{ go :: Int# -> Addr# -> ForeignPtrContents -> Int# -> Int# -> Int# go = \n p fpc o l -> case l <=# 0 of False -> go (n +# 1) p fpc (o +# 1) (l -# 1) True -> n length :: ByteString -> GHC.Base.Int length = \bs -> case bs of BS p fpc 0 l -> case go 0 p fpc 0 l of n -> I# n }}} This worked because strict `ByteString` is a single constructor data type which allows it to be unpacked into separate parameters in the recursive call. Now, lets try the same with lazy `ByteStrings`: {{{ data ByteString = Empty | Chunk {-# UNPACK #-} !StrictBS.ByteString ByteString }}} This of course has two constructors. It's built for call-pattern specialisation. Now the ops: {{{ null :: ByteString -> Bool null Empty = True null _ = False tail :: ByteString -> ByteString tail Empty = error "empty tail" tail (Chunk (S.BS fp s 1) cs) = cs tail (Chunk (S.BS fp s l) cs) = Chunk (S.BS fp (s+1) (l-1)) cs }}} We can use the exact same code for tail, but now for the lazy `ByteString` type: {{{ length :: ByteString -> Int length = go 0 where go !n bs | null bs = n | otherwise = go (n+1) (tail bs) }}} But, oh noes!! The optimisation does not work: {{{ go :: Int# -> ByteString -> Int# go = \n bs -> case bs of Empty -> n Chunk p fpc o l bs' -> go (n +# 1) (case l of 1 -> bs' _ -> Chunk p fpc (o +# 1) (l -# 1) bs') length :: ByteString -> Int length = \bs -> case go 0 bs of n -> I# n }}} However this is not because call pattern specialisation didn't do what we wanted. We know this for several reasons. One, if we remove the case {{{ tail (Chunk (S.BS fp s 1) cs) = cs }}} then call pattern specialisation works and the code ends up as a perfect loop. Of course we need that case for correctness. Also, if we change the definition of lazy `ByteString` to be a single constructor and represent the end by an empty chunk then we still get essentially the same code. Also, if we use `uncons` instead of `null` and `tail` then we effectively perform by hand the missing optimisation transformation and get perfect code (and call-pattern specialisation happens exactly as expected). {{{ length :: ByteString -> Int length = go 0 where go !n bs = case uncons bs of Nothing -> n Just (_, bs') -> go (n+1) bs' uncons :: ByteString -> Maybe (Word8, ByteString) uncons Empty = Nothing uncons (Chunk c cs) | StrictBS.length c == 1 = Just (S.unsafeHead c, cs) | otherwise = Just (S.unsafeHead c, Chunk (S.unsafeTail c) cs) }}} This version with `uncons` gives us perfect code: {{{ go_chunk :: ByteString -> Int# -> Int# -> ForeignPtrContents -> Addr# -> Int# -> Int# go_chunk = \bs' l o fpc p n -> case l of 1 -> go (n +# 1) bs' _ -> go_chunk bs' (l -# 1) (o +# 1) fpc p (n +# 1) go :: Int# -> ByteString -> Int# go = \n bs -> case bs of Empty -> n Chunk p fpc o l bs' -> case l of 1 -> go (n +# 1) bs' _ -> go_chunk bs' (l -# 1) (o +# 1) fpc p (n +# 1) length :: ByteString -> Int length = \bs -> case go 0 bs of n -> I# n }}} and we can see the specialisation rule that ghc invented for us: {{{ forall bs l o fpc p n. go n (Chunk p fpc o l bs) = go_chunk bs l o fpc p n }}} Aside: looks like there's an extra/missing reverse in there somewhere. The problem with the `head` / `tail` version is that the following transformation is never performed and so the opportunity for call pattern specialisation (or even simple worker/wrapper unpacking) is never exposed: {{{ go (n+1) (case l of 1 -> bs' _ -> Chunk p fpc (o+1) (l-1) bs') = case l of 1 -> go (n+1) bs' _ -> go (n+1) (Chunk p fpc (o+1) (l-1) bs') }}} which is the fragment inside the inlined definition of the go worker function: {{{ go !n bs = case bs of Empty -> n Chunk p fpc o l bs' -> go (n+1) (case l of 1 -> bs' _ -> Chunk p fpc (o+1) (l-1) bs') }}} So `go` is tail recursive and strict in both arguments. This situation will arise whenever we have something like {{{ go (tail xs) }}} and `tail` involves a case analysis. Since `go` is just a function call there is no problem in duplicating it into the two branches of `tail`. The fact that it enables the call-pattern specialisation makes this a huge win. This will happen with lazy `ByteString`s or any other chunked representation using trees. We really need the per-chunk inner loop to be good with just a single test in the fast path to see if we're at the end of the chunk. When we get to the end of the chunk we can move into the slow path and do more cunning things with chunks and trees and lazyness. But the overall speed of these kinds of operations is determined by the quality of the inner loop. If that inner loop has to allocate a fresh constructor each time round then we lose. In principle, if we can optimise perfectly then there is no reason for strict `ByteString` to have faster code than lazy `ByteString`, because their inner loops should look exactly the same. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 23 10:52:17 2009 From: trac at galois.com (GHC) Date: Mon Mar 23 10:41:01 2009 Subject: [GHC] #3115: mark ghc.cabal so that unsuspecting newbies don't try to edit it In-Reply-To: <041.3492cffcfd5dec50c06af45bac79589d@localhost> References: <041.3492cffcfd5dec50c06af45bac79589d@localhost> Message-ID: <050.db74202f67bfa8f9e5bcebb3630de97a@localhost> #3115: mark ghc.cabal so that unsuspecting newbies don't try to edit it ---------------------------------+------------------------------------------ Reporter: nr | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Build System | Version: 6.11 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by guest): + to informative comment - to unwritable files, they're just annoying (eg: if you want to use `rm -r` rather than `rm -rf` because it has warning messages. Or if you know (for whatever reason) that you actually do want to edit `ghc.cabal`.) It doesn't seem to be the convention to make all generated files unwritable... But others could have a different opinion from me. -Isaac Dupree -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 23 14:34:54 2009 From: trac at galois.com (GHC) Date: Mon Mar 23 14:22:31 2009 Subject: [GHC] #3117: via C compilation of module importing log1p from fails. Message-ID: <044.8df3c63314ab25b8b264107c8078c0cf@localhost> #3117: via C compilation of module importing log1p from fails. -----------------------------+---------------------------------------------- Reporter: int-e | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- This module fails to compile: {{{ {-# LANGUAGE ForeignFunctionInterface #-} {-# OPTIONS_GHC -fvia-C #-} foreign import ccall unsafe "math.h log1p" log1p :: Double -> Double main = print (log1p 1) }}} With errors like these: {{{ /tmp/ghc25313_0/ghc25313_0.hc: In function 'svD_entry': /tmp/ghc25313_0/ghc25313_0.hc:66:0: error: 'log1p' redeclared as different kind of symbol /usr/include/bits/mathcalls.h:132:0: error: previous declaration of 'log1p' was here }}} This is affecting the {{{logfloat}}} package on hackage. The reason is that {{{ghc}}} doesn't generate proper prototypes for foreign imports, but that's probably ok as long as no conflicting prototypes are defined for the same function. To accomplish this, {{{ghc}}} treats functions from {{{math.h}}} specially, but a number of these functions like {{{log1p}}} are not recognized. See {{{compiler/cmm/CLabel.hs}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 23 15:20:58 2009 From: trac at galois.com (GHC) Date: Mon Mar 23 15:08:35 2009 Subject: [GHC] #3118: ghc: panic! (the 'impossible' happened): Missing alternative Message-ID: <046.01e7ae53f2503ee56ede8d8442a19052@localhost> #3118: ghc: panic! (the 'impossible' happened): Missing alternative --------------------+------------------------------------------------------- Reporter: calvins | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86_64 (amd64) --------------------+------------------------------------------------------- When I include the -auto-all option (in addition to -prof) on the entry for Main in my Cabal file, I get the ghc panic message below. Full compile output attached. {{{ [10 of 10] Compiling Main ( Rdf4hParseMain.hs, dist/build/rdf4h/rdf4h-tmp/Main.o ) ghc: panic! (the 'impossible' happened) (GHC version 6.10.1 for x86_64-unknown-linux): Missing alternative main:Main.OutputFormat{d r16LZ} (main:Main.Help{d r16M9}, [], lvl_s17ar{v} [lid]) (main:Main.Debug{d r16M7}, [], lvl_s17as{v} [lid]) (main:Main.Version{d r16M5}, [], lvl_s17at{v} [lid]) }}} To reproduce the bug, check out a tagged version of the code using: darcs get -t 'ghc bug report' http://protempore.net/rdf4h And then edit the cabal file by adding "-prof -auto-all" to the library and main entries, and you should see what I see above if it's reproducible. It compiles fine if the options are only added to the library block, and it compiles fine if '-prof' but not '-auto-all' is added to the executable block, but fails when '-prof' and '-auto-all' are both added to the executable block. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 23 16:24:55 2009 From: trac at galois.com (GHC) Date: Mon Mar 23 16:12:37 2009 Subject: [GHC] #3119: Make ghc-6.10 use a non-executable stack (by bumping libffi) Message-ID: <047.52c2d20209bcb3a33fa5cded0d11d880@localhost> #3119: Make ghc-6.10 use a non-executable stack (by bumping libffi) ----------------------------+----------------------------------------------- Reporter: kolmodin | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: Unknown/Multiple ----------------------------+----------------------------------------------- Attached patch: {{{ Mon Mar 23 08:08:32 CET 2009 Lennart Kolmodin * Replace libffi 3.0.4 with libffi 3.0.8 Use the latest version of libffi, which compiles with a non-executable stack. libffi 3.0.4 was the single piece of ghc using the executable stack, forcing the whole toolchain to use executable stacks (including all executables it compiled). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 23 16:27:56 2009 From: trac at galois.com (GHC) Date: Mon Mar 23 16:15:35 2009 Subject: [GHC] #3119: Make ghc-6.10 use a non-executable stack (by bumping libffi) In-Reply-To: <047.52c2d20209bcb3a33fa5cded0d11d880@localhost> References: <047.52c2d20209bcb3a33fa5cded0d11d880@localhost> Message-ID: <056.1376c7571a02ee3255b7c95334d8d082@localhost> #3119: Make ghc-6.10 use a non-executable stack (by bumping libffi) -----------------------------+---------------------------------------------- Reporter: kolmodin | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Linux | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Comment (by kolmodin): Due to attachment size limitations, I've put the patch here: http://haskell.org/~kolmodin/replace-libffi-3_0_4-with-libffi-3_0_8.dpatch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 24 03:34:09 2009 From: trac at galois.com (GHC) Date: Tue Mar 24 03:28:09 2009 Subject: [GHC] #3120: openFile003 fails on i386/solaris Message-ID: <046.5d53eda23fa931fb3610eb637b68ea6a@localhost> #3120: openFile003 fails on i386/solaris --------------------+------------------------------------------------------- Reporter: kgardas | Owner: kgardas Type: bug | Status: new Priority: normal | Component: Test Suite Version: 6.11 | Severity: normal Keywords: | Testcase: Os: Solaris | Architecture: Unknown/Multiple --------------------+------------------------------------------------------- It seems that openFile003 fails on i386/solaris platform. The reason seems to be a difference between expected and provided output. It also seems that the difference is expected as sparc/solaris2 provided stdout file makes test run fine on this platform and it looks logical. Provided darcs patch fixes this issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 24 03:36:15 2009 From: trac at galois.com (GHC) Date: Tue Mar 24 03:30:11 2009 Subject: [GHC] #3120: openFile003 fails on i386/solaris In-Reply-To: <046.5d53eda23fa931fb3610eb637b68ea6a@localhost> References: <046.5d53eda23fa931fb3610eb637b68ea6a@localhost> Message-ID: <055.e3cc37daa490bc83aca6994c52f6c7bb@localhost> #3120: openFile003 fails on i386/solaris ------------------------+--------------------------------------------------- Reporter: kgardas | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 6.11 Severity: normal | Resolution: Keywords: | Testcase: Os: Solaris | Architecture: Unknown/Multiple ------------------------+--------------------------------------------------- Changes (by kgardas): * owner: kgardas => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 24 03:36:53 2009 From: trac at galois.com (GHC) Date: Tue Mar 24 03:30:49 2009 Subject: [GHC] #3120: openFile003 fails on i386/solaris In-Reply-To: <046.5d53eda23fa931fb3610eb637b68ea6a@localhost> References: <046.5d53eda23fa931fb3610eb637b68ea6a@localhost> Message-ID: <055.fdc8abaa08da30774460ec5bf15b41cd@localhost> #3120: openFile003 fails on i386/solaris ------------------------+--------------------------------------------------- Reporter: kgardas | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 6.11 Severity: normal | Resolution: Keywords: | Testcase: Os: Solaris | Architecture: x86 ------------------------+--------------------------------------------------- Changes (by kgardas): * architecture: Unknown/Multiple => x86 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 24 06:20:29 2009 From: trac at galois.com (GHC) Date: Tue Mar 24 06:08:06 2009 Subject: [GHC] #3119: Make ghc-6.10 use a non-executable stack (by bumping libffi) In-Reply-To: <047.52c2d20209bcb3a33fa5cded0d11d880@localhost> References: <047.52c2d20209bcb3a33fa5cded0d11d880@localhost> Message-ID: <056.9366015e21a7a5c8c2cdccb9bee3a35c@localhost> #3119: Make ghc-6.10 use a non-executable stack (by bumping libffi) -----------------------------+---------------------------------------------- Reporter: kolmodin | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Linux | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Comment (by duncan): Just to note that several distros (including Gentoo) consider executable stacks an important QA issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 24 07:01:23 2009 From: trac at galois.com (GHC) Date: Tue Mar 24 06:48:58 2009 Subject: [GHC] #3121: readline package does not respect Cabal --extra-{include, lib}-dirs flags Message-ID: <045.65efa1beaca7b94b94b7ae3c87f65f90@localhost> #3121: readline package does not respect Cabal --extra-{include,lib}-dirs flags -----------------------------+---------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Component: libraries (other) Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- The readline package still uses a `./configure` script. It has flags to set extra library and include dirs to search. These are needed by OSX users. The `./configure` script takes the flags: {{{ --with-readline-includes= --with-readline-libraries= }}} However when an end user installs the package via Cabal, (either `runghc Setup` or `cabal`) they use the Cabal flags: {{{ --extra-include-dirs= --extra-lib-dirs= }}} The problem is that the two sets of flags are not connected at all. If the configure script needs to know these directories then the Setup.hs for the package should pass them through. Users are not expected to know the per- package configure flags, especially when we already have suitable generic flags for the same purpose. The end result is that OSX users cannot install readline. Eg, today someone complained: {{{ hm, I have installed libreadline from mac ports and I have told cabal to look for it in --extra-include-dirs --extra-lib-dirs I also have installed the GNU.framework for mac but it still fails...any suggestions? }}} This problem actually applies to most bindings packages that use configure scripts. See also [http://hackage.haskell.org/trac/hackage/ticket/458 this Cabal ticket] about similar mismatches with configure scripts. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 24 10:32:04 2009 From: trac at galois.com (GHC) Date: Tue Mar 24 10:19:46 2009 Subject: [GHC] #3121: readline package does not respect Cabal --extra-{include, lib}-dirs flags In-Reply-To: <045.65efa1beaca7b94b94b7ae3c87f65f90@localhost> References: <045.65efa1beaca7b94b94b7ae3c87f65f90@localhost> Message-ID: <054.eed7f84620de1844e40b4b6445e1d94f@localhost> #3121: readline package does not respect Cabal --extra-{include,lib}-dirs flags -------------------------------+-------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: MacOS X | Architecture: x86 -------------------------------+-------------------------------------------- Changes (by ckeen): * os: Unknown/Multiple => MacOS X * architecture: Unknown/Multiple => x86 Comment: I was the one complaining. I wrote a small (and ugly) patch that seems to work when running Setup.hs in the directory. Running cabal does still not work. Please excuse the bad style I am still a beginner in haskell. I appreciate any suggestions on how to solve this better. Kind regards, Christian -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 24 11:31:02 2009 From: trac at galois.com (GHC) Date: Tue Mar 24 11:18:36 2009 Subject: [GHC] #3122: Enhance --info Message-ID: <044.9e71a36a06ffc4f0a9385ad48ed342a2@localhost> #3122: Enhance --info -------------------------------+-------------------------------------------- Reporter: igloo | Owner: igloo Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- We should: * Add things like C compiler, assembler, linker, libdir into the `--info` output * Generalise `--print-libdir` such that `--print-foo` prints the foo field from the `--info` output. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 24 11:42:59 2009 From: trac at galois.com (GHC) Date: Tue Mar 24 11:30:34 2009 Subject: [GHC] #3122: Enhance --info In-Reply-To: <044.9e71a36a06ffc4f0a9385ad48ed342a2@localhost> References: <044.9e71a36a06ffc4f0a9385ad48ed342a2@localhost> Message-ID: <053.ccdc9611eebdcd48efc96ef4ea61e309@localhost> #3122: Enhance --info ---------------------------------+------------------------------------------ Reporter: igloo | Owner: igloo Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by duncan): We should double-check what Cabal needs to ask ghc and make sure we can get it all in a single call to `ghc --info`. Currently Cabal has to guess which ghc-pkg and gcc to use. We have an algorithm for guessing the ghc-pkg given the name of the ghc program. Eg if ghc is called "ghc-6.10.1" then we look for "ghc-pkg-6.10.1". Then we double check by calling ghc-pkg --version and checking the version numbers are the same. That's pretty good, though it doesn't guarantee they share the same global package db. Perhaps this is enough and perhaps asking ghc to know where ghc-pkg is all the time is too annoying. Strictly speaking we should be using ghc's libexec dir not lib dir for programs like ghc-pkg etc. It is useful to know which gcc ghc is using, but ghc has potentially different programs for C compiler, assembler and linker. Perhaps we need to know all three. If ghc --info tells us this then it had better work when we do: {{{ ghc --info -pgmc=foobar }}} and have it tell us that the C compiler is `foobar` and not gcc. Similarly for the location of the global package db. Things that should not be in there: location of random other programs like haddock and hsc2hs. They are not intimately tied to ghc, don't pretend that it's a monolithic distribution. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 24 13:59:48 2009 From: trac at galois.com (GHC) Date: Tue Mar 24 13:47:23 2009 Subject: [GHC] #3118: ghc: panic! (the 'impossible' happened): Missing alternative In-Reply-To: <046.01e7ae53f2503ee56ede8d8442a19052@localhost> References: <046.01e7ae53f2503ee56ede8d8442a19052@localhost> Message-ID: <055.0f784e323bd0a4554648403fe99b5db5@localhost> #3118: ghc: panic! (the 'impossible' happened): Missing alternative -------------------------------+-------------------------------------------- Reporter: calvins | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by simonpj): * difficulty: => Unknown Comment: Very odd. This happens in the situation where GHC's optimiser encounters {{{ case (OutputFormat ...) of Help -> Debug -> Version -> }}} with no other alternatives, not even a default. That can't happen in source code, since GHC adds an invisible default, but it can happen internally if the optimiser proves that no other alternatives can happen. But here another alternative does! That's a bug. Needs investigation. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 24 14:00:31 2009 From: trac at galois.com (GHC) Date: Tue Mar 24 13:48:08 2009 Subject: [GHC] #1969: enormous compile times In-Reply-To: <045.1ab99ac1a52ae6b35a7131dc801608a9@localhost> References: <045.1ab99ac1a52ae6b35a7131dc801608a9@localhost> Message-ID: <054.bad5e1c4ab55609800dd30d35cbf3813@localhost> #1969: enormous compile times ---------------------------------------------+------------------------------ Reporter: duncan | Owner: simonpj Type: compile-time performance bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: performance | Difficulty: Difficult (1 week) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------------------+------------------------------ Changes (by simonpj): * owner: igloo => simonpj Comment: I'm fixing this. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 25 08:03:55 2009 From: trac at galois.com (GHC) Date: Wed Mar 25 07:51:28 2009 Subject: [GHC] #3118: ghc: panic! (the 'impossible' happened): Missing alternative In-Reply-To: <046.01e7ae53f2503ee56ede8d8442a19052@localhost> References: <046.01e7ae53f2503ee56ede8d8442a19052@localhost> Message-ID: <055.e3fb080064044374899b4b3340bd0dc1@localhost> #3118: ghc: panic! (the 'impossible' happened): Missing alternative -------------------------------+-------------------------------------------- Reporter: calvins | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Comment (by simonpj): I don't know whether this is anything to do with your problem, but I can't get started: {{{ bash-3.2$ cabal install Resolving dependencies... cabal: dependencies conflict: HTTP-4000.0.4 requires parsec ==2.1.0.1 however parsec-2.1.0.1 was excluded because rdf4h-0.7 requires parsec >=3 && >=3 bash-3.2$ }}} Seems that your package dependencies aren't right. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 25 08:37:09 2009 From: trac at galois.com (GHC) Date: Wed Mar 25 08:24:41 2009 Subject: [GHC] #3116: missed opportunity for call-pattern specialisation In-Reply-To: <045.11aa093a8bb570bc9aa8e63dfc895a71@localhost> References: <045.11aa093a8bb570bc9aa8e63dfc895a71@localhost> Message-ID: <054.60254f4d4df3bf7ae93fcd34a421dbf8@localhost> #3116: missed opportunity for call-pattern specialisation --------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple --------------------------------------+------------------------------------- Changes (by duncan): * type: bug => run-time performance bug * summary: missed optimisation opportunity with lazy ByteStrings => missed opportunity for call-pattern specialisation -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 25 09:12:21 2009 From: trac at galois.com (GHC) Date: Wed Mar 25 08:59:52 2009 Subject: [GHC] #3116: missed opportunity for call-pattern specialisation In-Reply-To: <045.11aa093a8bb570bc9aa8e63dfc895a71@localhost> References: <045.11aa093a8bb570bc9aa8e63dfc895a71@localhost> Message-ID: <054.bcf443a0a7080c4b7aefc943704a795a@localhost> #3116: missed opportunity for call-pattern specialisation --------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple --------------------------------------+------------------------------------- Comment (by duncan): It's not directly related to the missing transformation, but we could actually do slightly better in the call-pattern specialisation in the above example, even in the case where it already works. As I understand it, for call-pattern specialisation we start with: {{{ go !n bs = case bs of Empty -> n Chunk p fpc o l bs' -> go (n+1) (case l of 1 -> bs' _ -> Chunk p fpc (o+1) (l-1) bs') }}} And we decide that it's profitable to specialise on the second argument for `Empty` and `Chunk _ _ _ _ _` patterns. We then define: {{{ go_empty n = go n Empty go_chunk n p fpc o l bs' = go n (Chunk p fpc o l bs') }}} But, and this is the point, we leave the original `go` definition as it is. Of course later we apply the specialisation rules in the body of the original `go`. However, here is a potential improvement. We could redefine the original `go` in terms of its specialisations: {{{ go n bs = case bs of Empty -> go_empty n Chunk p fpc o l bs' -> go_chunk b p fpc o l bs' }}} Now we can leave it up to the heuristics of the inliner to decide if it is actually profitable to inline `go_chunk` here or if it is better to leave it as a call. If we decide not to inline it then we would get: {{{ go n bs = case bs of Empty -> n Chunk p fpc o l bs' -> go_chunk b p fpc o l bs' go_chunk n p fpc o l bs' = case l of 1 -> go (n+1) bs' _ -> go_chunk (n+1) p fpc (o+1) (l-1) bs' }}} It seems to me there is little benefit here from inlining `go_chunk` into `go`. I've not benchmarked the two so I can't say for sure but this looks like it is the perfect code given the original definitions (though with the obvious unboxing). Indeed in this simple case it may not even be necessary to export the `go_chunk` specialisation rule because it is implicit in the new definition of `go` (though this would not be true if the inliner decided to inline `go_chunk` into the body of `go`). Anyway, the point is, there may be such cases and by redefining the original body in terms of the specialisation we give the inliner the opportunity to make that choice. I don't see any downsides to giving it the choice. I may be missing something of course. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 25 10:15:19 2009 From: trac at galois.com (GHC) Date: Wed Mar 25 10:02:51 2009 Subject: [GHC] #3116: missed opportunity for call-pattern specialisation In-Reply-To: <045.11aa093a8bb570bc9aa8e63dfc895a71@localhost> References: <045.11aa093a8bb570bc9aa8e63dfc895a71@localhost> Message-ID: <054.0d70b1846c0d2012877a07de36076076@localhost> #3116: missed opportunity for call-pattern specialisation -----------------------------------------+---------------------------------- Reporter: duncan | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Changes (by simonpj): * difficulty: => Unknown Comment: As luck would have it, I had a spare hour and looked at this. I was happy to discover that a few months ago I'd changed the representation of a `StrictArg` continuation (the `SimplCont` type) that made it easy to achieve what you want; previously it was nigh impossible which is why GHC was so wimpy. So a matter of half a dozen lines of code changed gives the result you want. I attach my standalone test case; try compiling it with GHC 6.10 to see the bad behaviour. But with my new patch we get this for `length`: {{{ T3116.$s$wgo = \ (sc_sy6 :: T3116.ByteString) (sc1_sy7 :: GHC.Prim.Int#) (sc2_sy8 :: GHC.Prim.Int#) (sc3_sy9 :: GHC.ForeignPtr.ForeignPtrContents) (sc4_sya :: GHC.Prim.Addr#) (sc5_syb :: GHC.Prim.Int#) -> case sc1_sy7 of ds_XvF { __DEFAULT -> T3116.$s$wgo sc_sy6 (GHC.Prim.-# ds_XvF 1) (GHC.Prim.+# sc2_sy8 1) sc3_sy9 sc4_sya (GHC.Prim.+# sc5_syb 1); 1 -> T3116.$wgo (GHC.Prim.+# sc5_syb 1) sc_sy6 } T3116.$wgo = \ (ww_sxF :: GHC.Prim.Int#) (w_sxH :: T3116.ByteString) -> case w_sxH of _ { T3116.Empty -> ww_sxF; T3116.Chunk ipv_sw9 ipv1_swa ipv2_swb ipv3_swc ipv4_swd -> case ipv3_swc of ds_XvF { __DEFAULT -> T3116.$s$wgo ipv4_swd (GHC.Prim.-# ds_XvF 1) (GHC.Prim.+# ipv2_swb 1) ipv1_swa ipv_sw9 (GHC.Prim.+# ww_sxF 1); 1 -> T3116.$wgo (GHC.Prim.+# ww_sxF 1) ipv4_swd } } end Rec } T3116.length :: T3116.ByteString -> GHC.Types.Int T3116.length = \ (w_sxH :: T3116.ByteString) -> case T3116.$wgo 0 w_sxH of ww_sxK { __DEFAULT -> GHC.Types.I# ww_sxK } }}} Can't do much better than that. Expect a patch shortly. I don't understand your recent comment above, though. The RULES generated from the specialisations are indeed applied in the original function! Can you give a standalone example showing what happens, and what you want to happen instead? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 25 12:20:04 2009 From: trac at galois.com (GHC) Date: Wed Mar 25 12:07:36 2009 Subject: [GHC] #3118: ghc: panic! (the 'impossible' happened): Missing alternative In-Reply-To: <046.01e7ae53f2503ee56ede8d8442a19052@localhost> References: <046.01e7ae53f2503ee56ede8d8442a19052@localhost> Message-ID: <055.5d96398fdecfad5c8c1cf3deb00bb408@localhost> #3118: ghc: panic! (the 'impossible' happened): Missing alternative -------------------------------+-------------------------------------------- Reporter: calvins | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Comment (by calvins): Hmmm, that's odd. The [http://hackage.haskell.org/packages/archive/HTTP/4000.0.4/HTTP.cabal cabal file for HTTP-4004.0.4] doesn't list a version for parsec, and my package manager (on Gentoo) does not list a required version for parsec either. I will try uninstalling things and reinstalling using cabal-install rather than my package manager, and will report back. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 25 12:48:56 2009 From: trac at galois.com (GHC) Date: Wed Mar 25 12:36:28 2009 Subject: [GHC] #3123: make INLINE work for recursive definitions (generalized loop peeling/loop unrolling) Message-ID: <044.a125e44de5957e50d259dfbe1a2d51e0@localhost> #3123: make INLINE work for recursive definitions (generalized loop peeling/loop unrolling) -----------------------------+---------------------------------------------- Reporter: claus | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.11 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Inlining refers to the unfolding of definitions, ie replacing uses of identifiers with the definitions bound to them. Doing this at compile time can expose potential for other optimizations. As described in the User Guide, this is currently limited to non-recursive definitions, to avoid non-terminating recursion in the inliner. Unfolding Recursions Since many definitions in non-trivial programs are either recursive themselves or are built from recursion combinators, leaving recursion out of inlining alltogether is a serious limitation, especially in view of the encoding of loops via tail recursion. In conventional languages, loop transformations such as loop unrolling are at the heart of optimizing high performance code (for a useful overview, see Compiler Transformations for High-Performance Computing, ACM Computing Surveys, 1994). As a consequence, many performance-critical Haskell programs contain hand- unrolled and hand-peeled recursions, which is error-prone and obscures declarative contents. More details, examples, and an informal spec: wiki:Inlining -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 25 12:49:51 2009 From: trac at galois.com (GHC) Date: Wed Mar 25 12:37:23 2009 Subject: [GHC] #3117: via C compilation of module importing log1p from fails. In-Reply-To: <044.8df3c63314ab25b8b264107c8078c0cf@localhost> References: <044.8df3c63314ab25b8b264107c8078c0cf@localhost> Message-ID: <053.6477ba30469329ae6d314d837cddca42@localhost> #3117: via C compilation of module importing log1p from fails. ---------------------------------+------------------------------------------ Reporter: int-e | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: Thanks, applied: {{{ Mon Mar 23 18:36:30 GMT 2009 Bertram Felgenhauer * update list of C math functions Fix via C compilation of modules that import, say, log1p from math.h (#3117) The list is based on preprocessing Stg.h with glibc 2.6.1 headers, and cross-checked with the ISO C 99 standard (draft). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 25 13:59:24 2009 From: trac at galois.com (GHC) Date: Wed Mar 25 13:46:59 2009 Subject: [GHC] #849: Offer control over branch prediction In-Reply-To: <046.9c1a3dec0191543ee72b98b43c5f5f89@localhost> References: <046.9c1a3dec0191543ee72b98b43c5f5f89@localhost> Message-ID: <055.240cbed78f8bd4d7f3b77b0e87d3d97d@localhost> #849: Offer control over branch prediction ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.4.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: N/A | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by claus): * cc: claus (added) Comment: GHC actually ignores any expected-frequency information that programmers might try to encode in the ordering of pattern-match/conditional clauses, sorting them by data type definition order instead. If GHC would respect the source ordering of branches, programmers would have a chance to express expected frequency information without pragmas (assuming that successful match would correspond to fall-through, no jump). See this thread [http://www.haskell.org/pipermail/glasgow-haskell- users/2009-March/016907.html compilation of pattern-matching?] -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 25 16:03:13 2009 From: trac at galois.com (GHC) Date: Wed Mar 25 15:50:46 2009 Subject: [GHC] #3016: Long compile times, large memory use with static data in 6.10 In-Reply-To: <043.860ff3ba501bcb6418e5778e2c5eff65@localhost> References: <043.860ff3ba501bcb6418e5778e2c5eff65@localhost> Message-ID: <052.632932b1c463ad9355904b88bf3f7dbb@localhost> #3016: Long compile times, large memory use with static data in 6.10 ---------------------------------+------------------------------------------ Reporter: dons | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: static data | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * difficulty: => Unknown Comment: I've investigated a bit. The root cause is that GHC is much too keen to inline. The big integers are broken into lots of small ones (since we don't have big-integer literals), thus {{{ blah = plusInteger (mkInteger 3434433) (timesInteger (mkInteger 9343) (mkInteger 33344)) }}} Although `plusInteger` has quite a big unfolding, it also has large "argument discounts" because if you know what constructor the argument is built with, the unfolding would get a lot smaller. The trouble is that in GHC 6.10 ''the discount applies when GHC knows '''anything at all''' about the argument''. In particular, here we know that the argument is a call to `timesInteger`. So each literal gives rise to dozens of `plusInteger` and `timesInteger` calls, and they are all (fruitlessly) inlined. That's the diagnosis. I'm working on a fix, by making inlining a bit less eager. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 25 19:34:55 2009 From: trac at galois.com (GHC) Date: Wed Mar 25 19:22:26 2009 Subject: [GHC] #3118: ghc: panic! (the 'impossible' happened): Missing alternative In-Reply-To: <046.01e7ae53f2503ee56ede8d8442a19052@localhost> References: <046.01e7ae53f2503ee56ede8d8442a19052@localhost> Message-ID: <055.c1595d23272d4810684535ef47f759fb@localhost> #3118: ghc: panic! (the 'impossible' happened): Missing alternative -------------------------------+-------------------------------------------- Reporter: calvins | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Comment (by calvins): I'm unable to install 'cabal install' on a clean Ubuntu install because it doesn't seem to work with Parsec 3, which my library required. Are you able to compile with plain cabal? I checked the cabal conf files for the dependencies and verified that none of them specify Parsec 2.1.0.1. They all compile fine for me against Parsec-3.0.0 as long as I use 'runhaskell Setup ...' to compile and install rather than 'cabal install'. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 25 22:39:12 2009 From: trac at galois.com (GHC) Date: Wed Mar 25 22:26:43 2009 Subject: [GHC] #3117: via C compilation of module importing log1p from fails. In-Reply-To: <044.8df3c63314ab25b8b264107c8078c0cf@localhost> References: <044.8df3c63314ab25b8b264107c8078c0cf@localhost> Message-ID: <053.f29aaa94547067fa64ff5c7e764cb2d8@localhost> #3117: via C compilation of module importing log1p from fails. ---------------------------------+------------------------------------------ Reporter: int-e | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 25 22:43:11 2009 From: trac at galois.com (GHC) Date: Wed Mar 25 22:30:42 2009 Subject: [GHC] #3116: missed opportunity for call-pattern specialisation In-Reply-To: <045.11aa093a8bb570bc9aa8e63dfc895a71@localhost> References: <045.11aa093a8bb570bc9aa8e63dfc895a71@localhost> Message-ID: <054.0341eecbfdc18fb1a8e4cb29a866a8cc@localhost> #3116: missed opportunity for call-pattern specialisation -----------------------------------------+---------------------------------- Reporter: duncan | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Comment (by duncan): Replying to [comment:3 simonpj]: > Can't do much better than that. Expect a patch shortly. Woo hoo! That is indeed perfect. Thanks very much! I will update that example in my thesis accordingly! :-) > I don't understand your recent comment above, though. The RULES generated from the specialisations are indeed applied in the original function! Yes, of course. Sorry, I was not very clear. > Can you give a standalone example showing what happens, and what you want to happen instead? Ok, so with your fix we're getting essentially: {{{ go_chunk n p fpc o l bs' = case l of 1 -> go (n+1) bs' _ -> go_chunk (n+1) p fpc (o+1) (l-1) bs' go !n bs = case bs of Empty -> n Chunk p fpc o l bs' -> case l of 1 -> go (n+1) bs' _ -> go_chunk (n+1) p fpc (o+1) (l-1) bs' }}} The body of `go` contains a full unfolded instance of `go_chunk` (obviously, because that's the way `go` was defined and `go_chunk` was derived from a portion of the body of `go`). But what if it turned out that calling `go_chunk` was better than having `go_chunk` unfolded into the body of `go`? That is, it might be that this turns out to be the faster code: {{{ go_chunk n p fpc o l bs' = case l of 1 -> go (n+1) bs' _ -> go_chunk (n+1) p fpc (o+1) (l-1) bs' go n bs = case bs of Empty -> n Chunk p fpc o l bs' -> go_chunk b p fpc o l bs' }}} Currently, when we do the specialisation we leave the original defintion unmodified. Of course subsequently we apply the rules to it etc, but initially it's just kept in it's original form. The suggestion is that perhaps it is profitable to substitute calls to the specialised versions of the function into the original definition. We can always recover the original definition if the inliner decides it's the right thing to do. So, in this example, we start with the definition: {{{ go !n bs = case bs of Empty -> n Chunk p fpc o l bs' -> case l of 1 -> go (n+1) bs' _ -> go (n+1) (Chunk p fpc (o+1) (l-1) bs') }}} Then we construct the specialised versions: {{{ go_empty n = n go_chunk n p fpc o l bs' = case l of 1 -> go (n+1) bs' _ -> go (n+1) (Chunk p fpc (o+1) (l-1) bs') }}} Of course we also make the rules. In the current system we then just move on to applying the specialisation rules in the body of these functions and the original. But suppose instead that we first redefine the original `go` in terms of it's specialisations: {{{ go !n bs = case bs of Empty -> go_empty n Chunk p fpc o l bs' -> go_chunk n p fpc o l bs' }}} I do not mean doing this by rewrite rules, I mean just doing it directly as part of the procedure of generating specialised versions. Pick a pattern, lift the correspoding portion of the body out to become the specialised function and replace it with a call to the new specialised function. (That's an over-simplification of course but hopefully illustrates the idea). Then we move on as normal to apply rules and do ordinary simplification. This now gives the inliner the choice. It can choose to inline `go_chunk` in the body of `go` or it can choose to keep it as a call. If `go_chunk` is quite large then it might be better to keep it as a call. In the existing scheme it has no choice because the original function definition is never changed, it always contains the full body of each of its specialisations. Does that make any sense? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 26 03:57:36 2009 From: trac at galois.com (GHC) Date: Thu Mar 26 03:45:05 2009 Subject: [GHC] #3116: missed opportunity for call-pattern specialisation In-Reply-To: <045.11aa093a8bb570bc9aa8e63dfc895a71@localhost> References: <045.11aa093a8bb570bc9aa8e63dfc895a71@localhost> Message-ID: <054.8be436c1824473d96a6eb06a188c0aae@localhost> #3116: missed opportunity for call-pattern specialisation -----------------------------------------+---------------------------------- Reporter: duncan | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Comment (by simonpj): Oh, now I see, thanks. But I have no clue how to implement it! Just because 'f' has a profitable call pattern `(f (x:xs))` does NOT mean that `f` starts with case analysis on its first argument. Or to put it another more precise way, what do you propose to replace Section 3.2 of [http://research.microsoft.com/en-us/um/people/simonpj/papers/spec- constr/index.htm the paper] with? I think you may be misled by a special case. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 26 07:43:14 2009 From: trac at galois.com (GHC) Date: Thu Mar 26 07:30:44 2009 Subject: [GHC] #3116: missed opportunity for call-pattern specialisation In-Reply-To: <045.11aa093a8bb570bc9aa8e63dfc895a71@localhost> References: <045.11aa093a8bb570bc9aa8e63dfc895a71@localhost> Message-ID: <054.8398b01703669f97f62d317b96bc77b9@localhost> #3116: missed opportunity for call-pattern specialisation -----------------------------------------+---------------------------------- Reporter: duncan | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Comment (by duncan): Yes perhaps it only works for top level case analysis. It may still be a frequent special case. I'll think about how it generalises and what a full algorithm would look like. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 26 07:51:48 2009 From: trac at galois.com (GHC) Date: Thu Mar 26 07:39:20 2009 Subject: [GHC] #2613: configure should summarize important results at the end of its run In-Reply-To: <044.0889aaee930d9a4ce299cdd9f349c45b@localhost> References: <044.0889aaee930d9a4ce299cdd9f349c45b@localhost> Message-ID: <053.b8ef181be3d2b6bb72f153dc4c1208b3@localhost> #2613: configure should summarize important results at the end of its run ---------------------------------+------------------------------------------ Reporter: claus | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 6.12 branch Component: Build System | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Done in the new build system: {{{ ---------------------------------------------------------------------- Configure completed successfully. Building GHC version : 6.11.20090326 Build platform : x86_64-unknown-linux Host platform : x86_64-unknown-linux Target platform : x86_64-unknown-linux Bootstrapping using : /home/simonmar/fp/bin/x86_64-unknown-linux/ghc which is version : 6.10.1 Using GCC : gcc which is version : 4.3.0 ld : /usr/bin/ld Happy : /home/simonmar/fp/bin/x86_64-unknown-linux/happy Alex : /home/simonmar/fp/bin/x86_64-unknown-linux/alex Python : /usr/bin/python Perl : /usr/bin/perl Building DocBook documentation : yes Building shared libraries : NO ---------------------------------------------------------------------- For a standard build of GHC (fully optimised with profilng), type (g)make. To make changes to the default build configuration, copy the file mk/build.mk.sample to mk/build.mk, and edit the settings in there. For more information on how to configure your GHC build, see http://hackage.haskell.org/trac/ghc/wiki/Building }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 26 09:56:52 2009 From: trac at galois.com (GHC) Date: Thu Mar 26 09:44:22 2009 Subject: [GHC] #2613: configure should summarize important results at the end of its run In-Reply-To: <044.0889aaee930d9a4ce299cdd9f349c45b@localhost> References: <044.0889aaee930d9a4ce299cdd9f349c45b@localhost> Message-ID: <053.33ffdac67ee06051d65cd33ba88a0448@localhost> #2613: configure should summarize important results at the end of its run ---------------------------------+------------------------------------------ Reporter: claus | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 6.12 branch Component: Build System | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by guest): "For a standard build of GHC (fully optimised with profilng)," ... typo -> "profiling" ? -Isaac Dupree -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 26 14:00:40 2009 From: trac at galois.com (GHC) Date: Thu Mar 26 13:48:09 2009 Subject: [GHC] #3124: warning -F: directory name (/Users/me/Library/Frameworks) does not exist Message-ID: <044.91542ec2427008db2e834afd5933f41c@localhost> #3124: warning -F: directory name (/Users/me/Library/Frameworks) does not exist --------------------+------------------------------------------------------- Reporter: 7stud | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Os: MacOS X | Architecture: x86 --------------------+------------------------------------------------------- mac osx 10.4.11(intel), ghc 6.8.2 installed from ghc-6.8.2-i386-apple-darwin.tar.bz2 When I try to compile programs, I get this warning: $ ghc -o simple Main.hs PutJSON.hs SimpleJSON.hs compilation IS NOT required /usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: warning -F: directory name (/Users/autie/Library/Frameworks) does not exist This is how I installed ghc: 1) I downloaded GMP.framework and GNUreadline.framework, which my mac automatically unzipped and placed on my desktop. I then dragged the resulting two folders into /Library/Frameworks as per the instructions at: http://www.haskell.org/ghc/download_ghc_682.html#macosxintel 2) I downloaded ghc-6.8.2-i386-apple-darwin.tar.bz2 3) I unzipped an untared into /Users/me/my_tar_extractions 4) I cd'ed into the newly created ghc-6.8.2 folder. 5) I read the INSTALL document in the ghc-6.8.2 folder. 6) I ran the command: $ ./configure 7) Then I ran the command: $ sudo make install 8) At the end of the install output, I got a message that said: ------------- Installation of ghc-6.8.2 was successful. To use, add /usr/local/bin to your PATH. Warning: this binary distribution does NOT contain documentation! -------------- 9) I appended /usr/local/bin onto the PATH in ~/.bash_profile. This is what INSTALL from step 5 says: This is the INSTALL instructions for a binary distribution of GHC. For more details on what on earth this package is up to, please consult the README and ANNOUNCE. This distribution can be installed in a location of your choosing. To set the ball rolling, run the configure script (as usual, run the script with --help to see what options it supports). eg. to set up the package for installing in directory , use ./configure --prefix= The default installation directory is /usr/local. The configure script will figure out what platform you're running on, and a couple of other interesting pieces of trivia, which it will then fill in the Makefile.in template to give you a real Makefile. If you're of a paranoid persuasion, you might want to take a look at this Makefile to see if the information is correct. Now run: make install (`make show-install-setup' prints the details of where the different pieces of the bundle are heading when -- possibly helpful). For more information, full GHC documentation is available from the main GHC site: http://www.haskell.org/ghc Bug reports/suggestions for improvement to the installation procedure/setup (as well as other GHC related troubles you're experiencing, of course), gratefully received. Bug reporting instructions are here: http://www.haskell.org/ghc/reportabug Enjoy, -- The GHC Team. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 26 14:19:46 2009 From: trac at galois.com (GHC) Date: Thu Mar 26 14:07:45 2009 Subject: [GHC] #2789: GMP update required In-Reply-To: <047.d40b0b4f133d6bc7573ed702970e3886@localhost> References: <047.d40b0b4f133d6bc7573ed702970e3886@localhost> Message-ID: <056.c320c5ac5ddec37c867ef7fd674054b9@localhost> #2789: GMP update required ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: igloo Type: task | Status: new Priority: normal | Milestone: 6.10.2 Component: Build System | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * owner: => igloo Comment: Fixed in the new build system. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 26 15:06:56 2009 From: trac at galois.com (GHC) Date: Thu Mar 26 14:54:26 2009 Subject: [GHC] #3125: TcTyFuns.flattenType: unexpected PredType Message-ID: <044.ff8d4844273ea11da4fb9d9029c05a28@localhost> #3125: TcTyFuns.flattenType: unexpected PredType -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- {{{ type family Garbage y type instance Garbage y = [Num y => y] }}} yields {{{ *Main> undefined :: Garbage Int ghc: panic! (the 'impossible' happened) (GHC version 6.10.1 for x86_64-unknown-linux): TcTyFuns.flattenType: unexpected PredType Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} While its perfectly reasonable to die out on garbage like this, a less apocalyptic error message might be nice. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 27 06:26:13 2009 From: trac at galois.com (GHC) Date: Fri Mar 27 06:13:40 2009 Subject: [GHC] #3126: GHC needs to be more careful about pattern match order Message-ID: <044.905997d1d3bd9039e7f58de24b44ab6b@localhost> #3126: GHC needs to be more careful about pattern match order -----------------------------+---------------------------------------------- Reporter: claus | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.11 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- The [http://haskell.org/onlinereport/exps.html#sect3.17.2 language report] specifies pattern match order to be sequential, left-to-right, out-in, top-down. It explicitly allows for different implementations, as long as the differences are not observable and certain [http://haskell.org/onlinereport/exps.html#sect3.17.3 rules] remain valid. One such rule is: {{{ case e of {p1->e1;p2->e2} = case e of {p1->e1;_->case e of {p2->e2;_->error "No match"}} }}} GHC invalidates this rule: {{{ newtype N = N Int deriving (Show,Eq) instance Num N where fromInteger 0 = error "0" fromInteger 1 = N 0 fromInteger _ = N 1 f x = case x of 1 -> False 0 -> True g x = case x of 1 -> False _ -> case x of 0 -> True _ -> error "No match" main = do print $ g (N 0) print $ f (N 0) -- ghc $ ghc -w -e main PMOrderSpec.hs False : 0 -- hugs Main> main False False }}} The same effect can be achieved via `Data.String.IsString` (see attached test case). See also: - [http://www.haskell.org/pipermail/glasgow-haskell- users/2009-March/016949.html compilation of pattern matching?] - [ticket:246 Wrong pat-match order for records] -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 27 08:13:06 2009 From: trac at galois.com (GHC) Date: Fri Mar 27 08:00:34 2009 Subject: [GHC] #3119: Make ghc-6.10 use a non-executable stack (by bumping libffi) In-Reply-To: <047.52c2d20209bcb3a33fa5cded0d11d880@localhost> References: <047.52c2d20209bcb3a33fa5cded0d11d880@localhost> Message-ID: <056.086c8b37b607ebe49d2892d41fdd61b7@localhost> #3119: Make ghc-6.10 use a non-executable stack (by bumping libffi) ---------------------------------+------------------------------------------ Reporter: kolmodin | Owner: igloo Type: merge | Status: new Priority: high | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * priority: normal => high * difficulty: => Unknown * type: feature request => merge * owner: => igloo * milestone: => 6.12 branch Comment: I pushed this to the 6.10 branch (it wouldn't apply to HEAD for me, made darcs crash). Ian, could you merge to HEAD please? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 27 09:32:57 2009 From: trac at galois.com (GHC) Date: Fri Mar 27 09:20:27 2009 Subject: [GHC] #3119: Make ghc-6.10 use a non-executable stack (by bumping libffi) In-Reply-To: <047.52c2d20209bcb3a33fa5cded0d11d880@localhost> References: <047.52c2d20209bcb3a33fa5cded0d11d880@localhost> Message-ID: <056.5bc670a20718caf1e194cf806d232ceb@localhost> #3119: Make ghc-6.10 use a non-executable stack (by bumping libffi) ---------------------------------+------------------------------------------ Reporter: kolmodin | Owner: igloo Type: task | Status: new Priority: high | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * type: merge => task Comment: Worked fine for me; perhaps your 6.10 repo is partial. But HEAD had already updated to 3.0.6, so this conflicted. Also, HEAD has patches that get applied to libffi, which will need updating. Let's just do this update in the new build system. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 27 10:20:20 2009 From: trac at galois.com (GHC) Date: Fri Mar 27 10:07:45 2009 Subject: [GHC] #2370: num009 fails on OS X 10.5? In-Reply-To: <053.a1cda8d160d47acd1fc4d157514492c8@localhost> References: <053.a1cda8d160d47acd1fc4d157514492c8@localhost> Message-ID: <062.d36e49a6a6220f13cc159e4c648d293f@localhost> #2370: num009 fails on OS X 10.5? -----------------------------------+---------------------------------------- Reporter: batterseapower | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: lib/Numeric/num009 | Os: MacOS X Architecture: x86_64 (amd64) | -----------------------------------+---------------------------------------- Comment (by igloo): Might be related to #2059. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Mar 28 02:29:24 2009 From: trac at galois.com (GHC) Date: Sat Mar 28 02:23:09 2009 Subject: [GHC] #2211: Installing latest GHC-6.8.2 stable: pwd with floating point exception In-Reply-To: <044.6fa473611ed5d150325a47086f85da68@localhost> References: <044.6fa473611ed5d150325a47086f85da68@localhost> Message-ID: <053.8feaaa5f6423726c37bb9070dd36839e@localhost> #2211: Installing latest GHC-6.8.2 stable: pwd with floating point exception -----------------------------------------+---------------------------------- Reporter: guest | Owner: Type: bug | Status: reopened Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: critical | Resolution: Keywords: Floating point exception | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -----------------------------------------+---------------------------------- Changes (by guest): * keywords: => Floating point exception * status: closed => reopened * version: 6.8.2 => 6.10.1 * resolution: invalid => * severity: normal => critical Comment: same problem, amd thunderbird 1100MHz, none of the binaries working, error is: Floating point exception -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Mar 28 06:37:42 2009 From: trac at galois.com (GHC) Date: Sat Mar 28 06:25:12 2009 Subject: [GHC] #3125: TcTyFuns.flattenType: unexpected PredType In-Reply-To: <044.ff8d4844273ea11da4fb9d9029c05a28@localhost> References: <044.ff8d4844273ea11da4fb9d9029c05a28@localhost> Message-ID: <053.6c79de1f46c534101adb22aac6173a2d@localhost> #3125: TcTyFuns.flattenType: unexpected PredType ------------------------------+--------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by chak): * status: new => closed * resolution: => fixed Comment: This has already been fixed in the 6.11, which fails to load the declaration with {{{ /Users/chak/Code/haskell/main.hs:4:0: Illegal polymorphic or qualified type: (Num y) => y In the type synonym instance declaration for `Garbage' }}} Given that we already have an RC for 6.10.2, I think, it's too late to fiddle with the type checker just to get a better error message (and risk breaking something else along the way). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Mar 28 08:26:09 2009 From: trac at galois.com (GHC) Date: Sat Mar 28 08:19:54 2009 Subject: [GHC] #3120: openFile003 fails on i386/solaris In-Reply-To: <046.5d53eda23fa931fb3610eb637b68ea6a@localhost> References: <046.5d53eda23fa931fb3610eb637b68ea6a@localhost> Message-ID: <055.339a46c4a4a86a87ce2301920228d572@localhost> #3120: openFile003 fails on i386/solaris ---------------------------+------------------------------------------------ Reporter: kgardas | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: Component: Test Suite | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: x86 | ---------------------------+------------------------------------------------ Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: Patch applied, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Mar 28 12:37:56 2009 From: trac at galois.com (GHC) Date: Sat Mar 28 12:25:19 2009 Subject: [GHC] #3127: need help to edit the Haskell script in Winhugs and documentation. Message-ID: <049.45b14d05a719f7260552272ee822f531@localhost> #3127: need help to edit the Haskell script in Winhugs and documentation. -----------------------+---------------------------------------------------- Reporter: rjhelpdesk | Owner: Type: task | Status: new Priority: normal | Component: Documentation Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Windows | Architecture: Unknown/Multiple -----------------------+---------------------------------------------------- Both sections relate to the case study: Index for a document of text. SECTION A: Given the attached Haskell code which produces an index of words, make the following alterations by modifying existing functions and including new functions where necessary ? parts 1) to 5): 1) Where a word occurs N times on the same line, ensure that the line number occurs n times in the index entry for that word. 2) Allow words to be hyphenated and treat a hyphenated word as a single word. However, for those words which are split over two lines, treat a split word as a single word without the hyphen. 3) Treat a capitalised word (one or more capitals) as being different from the word in all lower case (but they should still be sorted alphabetically) ? unless it is at the start of a sentence with only the initial letter capitalised. A sentence is terminated by a ?.?, ??? or ?!?. 4) Make the output more readable in the form of an index table in columns with appropriate spacing and without brackets. 5) Include a user-friendly menu, so that the user can choose input/output file names or default files, and choose to rerun or exit. Parts 1) to 5) may be developed in any order. SECTION B: 6) For your version of function, makeIndex (only), show how an alternative ordering of the composed functions would provide a more efficient execution of makeIndex. Justify your answer. 7) For the parts 1) to 5) above that you have attempted, discuss the use you have made of a) higher-order functions, b) list comprehension, c) monadic input/output, d) functional composition, and/or e) partial parameterisation (or Curried functions). Include an evaluation of how useful your use of these concepts has been. import Prelude type Doc = String type Line = String type Word = String makeIndex :: Doc -> [ ([Int], Word) ] makeIndex = shorten . -- [([Int], Word)] -> [([Int], Word)] amalgamate .-- [([Int], Word)] -> [([Int], Word)] makeLists . -- [(Int, Word)] -> [([Int], Word)] sortLs . -- [(Int, Word)] -> [(Int, Word)] allNumWords .-- [(Int, Line)] -> [(Int, Word)] numLines . -- [Line] -> [(Int, Line)] splitUp -- Doc -> [Line] splitUp :: Doc -> [Line] splitUp [] = [] splitUp text = takeWhile (/='\n') text : -- first line (splitUp . -- splitup other lines dropWhile (==?\n?) . -- delete 1st newline(s) dropWhile (/='\n')) text -- other lines numLines :: [Line] -> [(Int, Line)] numLines lines -- list of pairs of = zip [1 .. length lines] lines -- line no. & line -- for each line -- a) split into words -- b) attach line no. to each word splitWords :: Line -> [Word] -- a) splitWords [] = [] splitWords line = takeWhile isLetter line : -- first word in line (splitWords . -- split other words dropWhile (not.isLetter) . -- delete separators dropWhile isLetter) line -- other words where isLetter ch = (?a?<=ch) && (ch<=?z?) || (?A?<=ch) && (ch<=?Z?) numWords :: (Int, Line) -> [(Int, Word)] -- b) numWords (number, line) = map addLineNum ( splitWords line) -- all line pairs where addLineNum word = (number, word) -- a pair allNumWords :: [(Int, Line)] -> [(Int, Word)] allNumWords = concat . map numWords -- doc pairs sortLs :: [(Int, Word)] -> [(Int, Word)] sortLs [ ] = [ ] sortLs (a:x) = sortLs [b | b <- x, compare b a] -- sort 1st half ++ [a] ++ -- 1st in middle sortLs [b | b <- x, compare a b] -- sort 2nd half where compare (n1, w1) (n2, w2) = (w1 < w2) -- 1st word less || (w1 == w2 && n1 < n2) -- check no. makeLists :: [(Int, Word)] -> [([Int], Word)] makeLists = map mk -- all pairs where mk (num, word) = ([num], word) -- list of single no. amalgamate :: [([Int], Word)] -> [([Int], Word)] amalgamate [ ] = [ ] amalgamate [a] = [a] amalgamate ((n1, w1) : (n2, w2) : rest)-- pairs of pairs | w1 /= w2 = (n1, w1) : amalgamate ((n2, w2) : rest) | otherwise = amalgamate ((n1 ++ n2, w1) : rest) -- if words are same grow list of numbers shorten :: [([Int], Word)] -> [([Int], Word)] shorten = filter long -- keep pairs >4 where long (num, word) = length word > 4 -- check word >4 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Mar 28 12:53:46 2009 From: trac at galois.com (GHC) Date: Sat Mar 28 12:41:08 2009 Subject: [GHC] #3127: need help to edit the Haskell script in Winhugs and documentation. In-Reply-To: <049.45b14d05a719f7260552272ee822f531@localhost> References: <049.45b14d05a719f7260552272ee822f531@localhost> Message-ID: <058.574f1fcec4afcf9791e272a9771e4a56@localhost> #3127: need help to edit the Haskell script in Winhugs and documentation. ---------------------------------+------------------------------------------ Reporter: rjhelpdesk | Owner: Type: task | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 6.10.1 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: If you need help with Haskell programming, please ask on the haskell-cafe mailing list: http://www.haskell.org/mailman/listinfo/haskell-cafe -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Mar 28 15:33:19 2009 From: trac at galois.com (GHC) Date: Sat Mar 28 15:20:41 2009 Subject: [GHC] #3128: hClose leaves file descriptor open if it fails Message-ID: <045.f474a379b598a39e20f417ce0f4de22b@localhost> #3128: hClose leaves file descriptor open if it fails -----------------------------+---------------------------------------------- Reporter: Baughn | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- In libraries/base/GHC/Handle.hs, function hClose_help, we attempt to flush the write buffer before closing a handle's underlying FD. If flushing the write buffer fails, for example if this is a network socket that has been closed by the remote host, hClose throws an exception inside flushWriteBufferOnly and the socket is not closed. As a result, the program leaks sockets. The solution is to always close the FD (that is, call hClose_handle_) regardless of errors, but I am not confident of writing correct exception- handling code without the usual abstractions available. Also, inside hClose_handle_, an error is thrown if c_close ever returns -1. It may be practically impossible for this to be caused by EINTR, but is it theoretically impossible? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Mar 28 15:33:37 2009 From: trac at galois.com (GHC) Date: Sat Mar 28 15:20:58 2009 Subject: [GHC] #3128: hClose leaves file descriptor open if it fails In-Reply-To: <045.f474a379b598a39e20f417ce0f4de22b@localhost> References: <045.f474a379b598a39e20f417ce0f4de22b@localhost> Message-ID: <054.1df00403ea3485e1d6f91891eaba00c2@localhost> #3128: hClose leaves file descriptor open if it fails ------------------------------+--------------------------------------------- Reporter: Baughn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by Baughn): * cc: sveina@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 29 04:31:40 2009 From: trac at galois.com (GHC) Date: Sun Mar 29 04:19:04 2009 Subject: [GHC] #3129: Crypto-4.1.0 compilation failure Message-ID: <044.ee639a27d43ce2fb6761c14259432bcf@localhost> #3129: Crypto-4.1.0 compilation failure -------------------------+-------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: Crypto-4.1.0 | Testcase: Os: MacOS X | Architecture: x86 -------------------------+-------------------------------------------------- GHC panic: {{{ [11 of 11] Compiling Main ( SymmetricTest.hs, dist/build/SymmetricTest/SymmetricTest-tmp/Main.o ) Linking dist/build/SymmetricTest/SymmetricTest ... [1 of 4] Compiling Codec.Utils ( Codec/Utils.hs, dist/build/SHA1Test /SHA1Test-tmp/Codec/Utils.o ) [2 of 4] Compiling Data.Digest.SHA1 ( Data/Digest/SHA1.hs, dist/build/SHA1Test/SHA1Test-tmp/Data/Digest/SHA1.o ) [3 of 4] Compiling Codec.Text.Raw ( Codec/Text/Raw.hs, dist/build/SHA1Test/SHA1Test-tmp/Codec/Text/Raw.o ) [4 of 4] Compiling Main ( SHA1Test.hs, dist/build/SHA1Test /SHA1Test-tmp/Main.o ) ghc: panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-apple-darwin): RegAllocLinear.getStackSlotFor: out of stack slots, try -fregs- graph Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug cabal: Error: some packages failed to install: Crypto-4.1.0 failed during the building phase. The exception was: exit: ExitFailure 1 hS3-0.4 depends on Crypto-4.1.0 which failed to install. }}} -------------- Software: {{{ System Version: Mac OS X 10.5.6 (9G55) Kernel Version: Darwin 9.6.0 }}} Hardware: {{{ Model Name: MacBook Model Identifier: MacBook2,1 Processor Name: Intel Core 2 Duo Processor Speed: 2.16 GHz Number Of Processors: 1 Total Number Of Cores: 2 L2 Cache: 4 MB Memory: 4 GB Bus Speed: 667 MHz Boot ROM Version: MB21.00A5.B07 SMC Version: 1.17f0 Sudden Motion Sensor: State: Enabled }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 29 05:10:50 2009 From: trac at galois.com (GHC) Date: Sun Mar 29 04:58:12 2009 Subject: [GHC] #3130: copyFile and findExecutable don't work correctly if filename has national symbols Message-ID: <047.da94d19c1a8d4f7956abff60dc99c03d@localhost> #3130: copyFile and findExecutable don't work correctly if filename has national symbols ---------------------+------------------------------------------------------ Reporter: shelarcy | Owner: Type: bug | Status: new Priority: normal | Component: libraries/directory Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Windows | Architecture: x86 ---------------------+------------------------------------------------------ copyFile works doesn't work if first argument's filename has national symbols. {{{ import System.Directory main = do copyFile "test.txt" "???.txt" -- works print "copyFile works if second argument has national path." copyFile "???.txt" "test2.txt" -- doesn't work print "copyFile doesn't work if second argument has national path." copyFile "???.txt" "???2.txt" -- doesn't work print "copyFile doesn't work if first argument has national path." }}} {{{ C:\home>runghc.exe Test.hs "copyFile works if second argument has national path." Test.hs: ???.txt: copyFile: does not exist (No such file or directory) }}} System.Win32.copyFile doesn't cause this problem. {{{ import System.Win32 main = do copyFile "test.txt" "???.txt" False -- works print "copyFile works if second argument has national path." copyFile "???.txt" "test2.txt" False -- doesn't work print "copyFile doesn't work if second argument has national path." copyFile "???.txt" "???2.txt" False -- doesn't work print "copyFile doesn't work if first argument has national path." }}} {{{ C:\home>runghc.exe Test.hs "copyFile works if second argument has national path." "copyFile doesn't work if second argument has national path." "copyFile doesn't work if first argument has national path." }}} And findExecutable return Nothing if executable file name has national symbols. {{{ import System.Directory -- hiding (getDirectoryContents) main = findExecutable "???" >>= print }}} {{{ C:\home>runghc.exe Test.hs Nothing }}} So, I made patch for these two problems. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 29 05:16:22 2009 From: trac at galois.com (GHC) Date: Sun Mar 29 05:03:45 2009 Subject: [GHC] #3130: copyFile and findExecutable don't work correctly if filename has national symbols In-Reply-To: <047.da94d19c1a8d4f7956abff60dc99c03d@localhost> References: <047.da94d19c1a8d4f7956abff60dc99c03d@localhost> Message-ID: <056.d10dad0eaf231ffca237290d31109264@localhost> #3130: copyFile and findExecutable don't work correctly if filename has national symbols ---------------------------------+------------------------------------------ Reporter: shelarcy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/directory | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Windows | Architecture: x86 ---------------------------------+------------------------------------------ Comment (by shelarcy): System.Win32.copyFile works fine. So, second examples' comment and printed messages are incorrect. I'm sorry about that. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 29 10:26:00 2009 From: trac at galois.com (GHC) Date: Sun Mar 29 10:13:21 2009 Subject: [GHC] #3130: copyFile and findExecutable don't work correctly if filename has national symbols In-Reply-To: <047.da94d19c1a8d4f7956abff60dc99c03d@localhost> References: <047.da94d19c1a8d4f7956abff60dc99c03d@localhost> Message-ID: <056.0baecae7359746264c26fe3770869830@localhost> #3130: copyFile and findExecutable don't work correctly if filename has national symbols ---------------------------------+------------------------------------------ Reporter: shelarcy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/directory | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Windows | Architecture: x86 ---------------------------------+------------------------------------------ Comment (by duncan): I don't think switching to `System.Win32.copyFile` is the right solution. Switching `SearchPathA` for `SearchPathW` is sensible though. We should really be using the W variants everywhere now since we do not support Windows 9x anymore and we do want proper support for Unicode file names in Windows. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 29 17:11:10 2009 From: trac at galois.com (GHC) Date: Sun Mar 29 16:58:40 2009 Subject: [GHC] #2996: Network.Socket.sClose should change socket status In-Reply-To: <046.41f89e25a108f554724958983d75e152@localhost> References: <046.41f89e25a108f554724958983d75e152@localhost> Message-ID: <055.44cd89e732e877d4be84a5df61d6b3bc@localhost> #2996: Network.Socket.sClose should change socket status ----------------------------------+----------------------------------------- Reporter: amthrax | Owner: tibbe Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: libraries/network | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Comment (by tibbe): Sorry for the late reply. `closed-state.patch` looks fine to me. As for the second patch I think we need to figure out the performance consequences of checking an MVar for every op before we make the change. Perhaps it would be worthwhile to write down which guarantees the API currently gives and could give when used in multi-threaded code. I'm not even entirely sure what guarantees we give at the moment, without your patches. If nothing else that would serve as good documentation. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 29 21:06:23 2009 From: trac at galois.com (GHC) Date: Sun Mar 29 20:53:45 2009 Subject: [GHC] #3131: GHC stops after a single 'defined but not used' warning Message-ID: <041.cbb217fb4ffa21824da5fcede2622adb@localhost> #3131: GHC stops after a single 'defined but not used' warning -------------------+-------------------------------------------------------- Reporter: nr | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: minor Keywords: | Testcase: Os: Linux | Architecture: x86 -------------------+-------------------------------------------------------- Using {{{-Wall -Werror}}}, GHC stops after finding a single "defined but not used" warning: {{{ cmm/ZDF3.hs:795:10: Warning: Defined but not used: `rew_CO' }}} I'm sweeping away old code and would much prefer that GHC find ''all'' the defined-but-not-used identifiers on a single run. The transitive closure would be ideal, but I would settle for just all the ones that are defined but not used. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 29 23:54:58 2009 From: trac at galois.com (GHC) Date: Sun Mar 29 23:42:17 2009 Subject: [GHC] #3129: Crypto-4.1.0 compilation failure In-Reply-To: <044.ee639a27d43ce2fb6761c14259432bcf@localhost> References: <044.ee639a27d43ce2fb6761c14259432bcf@localhost> Message-ID: <053.39cc2a596350ad5a202534339ea3cb94@localhost> #3129: Crypto-4.1.0 compilation failure --------------------------+------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: Crypto-4.1.0 | Testcase: Os: MacOS X | Architecture: x86 --------------------------+------------------------------------------------- Comment (by guest): Works after 'cabal upgrade', though the fact that it panicked in the first place might still be worrying. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 30 01:38:25 2009 From: trac at galois.com (GHC) Date: Mon Mar 30 01:25:46 2009 Subject: [GHC] #2981: ".space" directive not recognised by solaris assembler In-Reply-To: <045.06c53c97857dc8d5e429d261e87cfc23@localhost> References: <045.06c53c97857dc8d5e429d261e87cfc23@localhost> Message-ID: <054.828dd91bda22896307d83b722ab50ce8@localhost> #2981: ".space" directive not recognised by solaris assembler -------------------------------+-------------------------------------------- Reporter: duncan | Owner: benl Type: bug | Status: closed Priority: normal | Milestone: 6.12 branch Component: Compiler (NCG) | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: sparc | -------------------------------+-------------------------------------------- Changes (by benl): * status: assigned => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 30 04:01:10 2009 From: trac at galois.com (GHC) Date: Mon Mar 30 03:48:29 2009 Subject: [GHC] #3131: GHC stops after a single 'defined but not used' warning In-Reply-To: <041.cbb217fb4ffa21824da5fcede2622adb@localhost> References: <041.cbb217fb4ffa21824da5fcede2622adb@localhost> Message-ID: <050.bc79a13d65880efe4b98ffe2b36ba67f@localhost> #3131: GHC stops after a single 'defined but not used' warning -------------------------+-------------------------------------------------- Reporter: nr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by simonpj): * difficulty: => Unknown Comment: And so it does, including the transitive closure. Try {{{ module Foo( f) where f x = x g x = x h x = g x }}} Can you give a small test case please? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 30 04:45:26 2009 From: trac at galois.com (GHC) Date: Mon Mar 30 04:32:53 2009 Subject: [GHC] #1779: unknown symbol `hs_hpc_module' In-Reply-To: <044.e238a8559ffe0a21198f4a819a87e869@localhost> References: <044.e238a8559ffe0a21198f4a819a87e869@localhost> Message-ID: <053.2133fba9b9738ece910a126a3e1e60b2@localhost> #1779: unknown symbol `hs_hpc_module' ---------------------------------+------------------------------------------ Reporter: guest | Owner: simonmar Type: bug | Status: new Priority: low | Milestone: 6.10.2 Component: GHCi | Version: 6.10.1 Severity: minor | Resolution: Keywords: hpc | Difficulty: Unknown Testcase: hpc_ghc_ghci | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: reopened => new * owner: AndyGill => simonmar Comment: I'm validating the fix for this. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 30 04:58:04 2009 From: trac at galois.com (GHC) Date: Mon Mar 30 04:45:23 2009 Subject: [GHC] #246: Wrong pat-match order for records In-Reply-To: <046.53a6e2ac6025e28545b59cc15cc5e7b8@localhost> References: <046.53a6e2ac6025e28545b59cc15cc5e7b8@localhost> Message-ID: <055.4f7c04285c31ca38186a753c59e6cb2f@localhost> #246: Wrong pat-match order for records ----------------------------------------+----------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: closed Priority: low | Milestone: _|_ Component: Compiler | Version: 6.4.1 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: deSugar/should_run/T246 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------+----------------------------------- Changes (by simonpj): * testcase: => deSugar/should_run/T246 * status: assigned => closed * resolution: None => fixed Comment: Finally fixed! {{{ Mon Mar 30 09:37:36 BST 2009 simonpj@microsoft.com * Fix Trac #246: order of matching in record patterns While I was looking at the desugaring of pattern matching (fixing Trac #3126) I finally got around to fixing another long-standing bug: when matching in a record pattern, GHC should match left-to-right in the programmer-specfied order, *not* left-to-right positionally in the original record declaration. Needless to say, that requires a little more code. See Note [Record patterns] in MatchCon.lhs }}} Changing the pattern-match order tickled a bug in GHC itself, so you must take this patch too {{{ Mon Mar 30 09:49:12 BST 2009 simonpj@microsoft.com * Fix an nasty black hole, concerning computation of isRecursiveTyCon Fixing #246 (pattern-match order in record patterns) made GHC go into a black hole, by changing the order of patterm matching in TyCon.isProductTyCon! It turned out that GHC had been avoiding the black hole only by the narrowest of margins up to now! The black hole concerned the computation of which type constructors are recursive, in TcTyDecls.calcRecFlags. We now refrain from using isProductTyCon there, since it triggers the black hole (very indirectly). See the "YUK YUK" comment in the body of calcRecFlags. As it turns out, the fact that TyCon.isProductTyCon matched on the algTcRec field was quite redundant, so I removed that too. However, without the fix to calcRecFlags, this wouldn't fix the black hole because of the use of isRecursiveTyCon in BuildTyCl.mkNewTyConRhs. Anyway, it's fine now. }}} Probably don't merge to 6.10. It's a change in semantics (albeit fixing wrong semantics). If it broke GHC, it might break someone else's code. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 30 04:58:30 2009 From: trac at galois.com (GHC) Date: Mon Mar 30 04:45:47 2009 Subject: [GHC] #3126: GHC needs to be more careful about pattern match order In-Reply-To: <044.905997d1d3bd9039e7f58de24b44ab6b@localhost> References: <044.905997d1d3bd9039e7f58de24b44ab6b@localhost> Message-ID: <053.b7ea056521c1ce6ac1cdc07970b1ead0@localhost> #3126: GHC needs to be more careful about pattern match order -----------------------------------------+---------------------------------- Reporter: claus | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: deSugar/should_run/T3126 | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Changes (by simonpj): * testcase: => deSugar/should_run/T3126 * difficulty: => Unknown * type: bug => merge * owner: => igloo Comment: Excellent report, thank you. Fixed by {{{ Mon Mar 30 09:34:35 BST 2009 simonpj@microsoft.com * Fix Trac #3126: matching overloaded literals Claus Reinke uncovered a long-standing bug in GHC, whereby we were combining the pattern-match on overloaded literals, missing the fact that an intervening pattern (for a different literal) might also match. (If someone had a very odd implementation of fromInteger!) See Note [Grouping overloaded literal patterns] in Match.lhs If this merges smoothly to 6.10, go for it, but it's very much a corner case. Thank you Claus! }}} Merge to 6.10 if there's time. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 30 06:21:03 2009 From: trac at galois.com (GHC) Date: Mon Mar 30 06:08:41 2009 Subject: [GHC] #1779: unknown symbol `hs_hpc_module' In-Reply-To: <044.e238a8559ffe0a21198f4a819a87e869@localhost> References: <044.e238a8559ffe0a21198f4a819a87e869@localhost> Message-ID: <053.74f68485dc621108b8788c21720ad27d@localhost> #1779: unknown symbol `hs_hpc_module' ---------------------------------+------------------------------------------ Reporter: guest | Owner: igloo Type: merge | Status: new Priority: low | Milestone: 6.10.2 Component: GHCi | Version: 6.10.1 Severity: minor | Resolution: Keywords: hpc | Difficulty: Unknown Testcase: hpc_ghc_ghci | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: Fixed: {{{ Mon Mar 30 01:44:14 PDT 2009 Simon Marlow * FIX #1779 and qq005: export hs_hpc_module }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 30 09:36:22 2009 From: trac at galois.com (GHC) Date: Mon Mar 30 09:23:41 2009 Subject: [GHC] #1969: enormous compile times In-Reply-To: <045.1ab99ac1a52ae6b35a7131dc801608a9@localhost> References: <045.1ab99ac1a52ae6b35a7131dc801608a9@localhost> Message-ID: <054.91b10e78858438c00a0f797bce660933@localhost> #1969: enormous compile times ---------------------------------+------------------------------------------ Reporter: duncan | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: performance | Difficulty: Difficult (1 week) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * owner: simonpj => igloo * type: compile-time performance bug => merge Comment: OK the patch is this {{{ Mon Mar 23 10:38:26 GMT 2009 simonpj@microsoft.com * Avoid quadratic complexity in occurrence analysis (fix Trac #1969) The occurrence analyser could go out to lunch in bad cases, because of its clever loop-breaking algorithm. This patch makes it bale out in bad cases. Somewhat ad-hoc: a nicer solution would be welcome. See Note [Complexity of loop breaking] for the details. M ./compiler/simplCore/OccurAnal.lhs -22 +71 }}} The fix is still not perfect, because it simply bales out in the tricky case. My feeling is that there is probably a good algorithm somewhere for "find the minimal set of nodes whose removal will make the graph acyclic", but I don't know of it. Furthermore, the problem is made tricker by the presence of RULES etc; see extensive comments in `OccurAnal`. Anyway, baling out certainly fixes the bad complexity. I think this could merge into 6.10. Ian: what about a test-suite example? Maybe just a big enough instance to trip the timeout? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 30 09:52:25 2009 From: trac at galois.com (GHC) Date: Mon Mar 30 09:39:48 2009 Subject: [GHC] #1969: enormous compile times In-Reply-To: <045.1ab99ac1a52ae6b35a7131dc801608a9@localhost> References: <045.1ab99ac1a52ae6b35a7131dc801608a9@localhost> Message-ID: <054.b6be68b15c7f53d4cbc7df59a56f7a74@localhost> #1969: enormous compile times ---------------------------------+------------------------------------------ Reporter: duncan | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: performance | Difficulty: Difficult (1 week) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by augustss): It's the Minimum Feedback Vertex Set problem; I think it's NP-hard. But there are good approximations that are cheap. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 30 12:20:43 2009 From: trac at galois.com (GHC) Date: Mon Mar 30 12:08:10 2009 Subject: [GHC] #1969: enormous compile times In-Reply-To: <045.1ab99ac1a52ae6b35a7131dc801608a9@localhost> References: <045.1ab99ac1a52ae6b35a7131dc801608a9@localhost> Message-ID: <054.33aca2bfe1e50a2d212e7b0f24d37978@localhost> #1969: enormous compile times ---------------------------------+------------------------------------------ Reporter: duncan | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: performance | Difficulty: Difficult (1 week) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonpj): Do you know any such approximations? A quick google search shows lots of special cases, but nothing that jumped out at me. Relevant points: * The vertices each have a "score", and I want to minimise the ''total score'' of zapped vertices, not just their ''number''. * It's a ''directed'' graph. I suppose it's possible that dualising the problem (so the vertices become edges and vice versa) might lead to other relevant material. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 30 15:04:49 2009 From: trac at galois.com (GHC) Date: Mon Mar 30 14:52:04 2009 Subject: [GHC] #3132: x86 code generator generates bad FPU register names Message-ID: <044.486f0fa3ddd7b77dad74344aee019e46@localhost> #3132: x86 code generator generates bad FPU register names -----------------------------+---------------------------------------------- Reporter: int-e | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (NCG) Version: 6.11 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: x86 -----------------------------+---------------------------------------------- The following code, {{{ module Spring where import Data.Array.Unboxed type Arr = UArray Int Double data Spring = Spring !Double !Int !Arr deriving Show step :: Double -> Spring -> Spring step h (Spring k sz y) = let f arr = listArray (0, 2*sz-1) (velocity ++ accel) where velocity = [arr ! i | i <- [sz .. 2*sz-1]] k' = k * fromIntegral sz^2 accel = [0] ++ [k' * (arr!(i-1) - 2 * arr!i + arr!(i+1)) | i <- [1 .. sz-2]] ++ [k' * (arr!(sz-2) - arr!(sz-1))] (.*) :: Double -> Arr -> Arr a .* b = listArray (0, 2*sz-1) $ map (a*) (elems b) (<+>) :: Arr -> Arr -> Arr a <+> b = listArray (0, 2*sz-1) $ zipWith (+) (elems a) (elems b) -- order 4 Runge-Kutta k1 = h .* f y k2 = h .* f (y <+> (0.5 .* k1)) k3 = h .* f (y <+> (0.5 .* k2)) k4 = h .* f (y <+> k3) y' = y <+> ((1/6) .* (k1 <+> (2 .* (k2 <+> k3)) <+> k4)) in Spring k sz y' }}} doesn't compile with optimization in ghc-6.11: {{{ # ghc -O -c Bug.hs /tmp/ghc12296_0/ghc12296_0.s: Assembler messages: /tmp/ghc12296_0/ghc12296_0.s:2355:0: Error: bad register name `%st(-8)' /tmp/ghc12296_0/ghc12296_0.s:2384:0: Error: bad register name `%st(-8)' /tmp/ghc12296_0/ghc12296_0.s:2563:0: Error: bad register name `%st(-8)' /tmp/ghc12296_0/ghc12296_0.s:2602:0: Error: bad register name `%st(-8)' /tmp/ghc12296_0/ghc12296_0.s:3006:0: Error: bad register name `%fake0' /tmp/ghc12296_0/ghc12296_0.s:3023:0: Error: bad register name `%fake0' }}} It's odd, first it tries to assign a closure pointer to an FPU register: {{{ movl $r1sa_closure,%fake0 }}} and later it uses register 0 (%eax) as an operand to an FPU operation: {{{ # gsubl %fake1,%eax,%fake1 #GSUB-xxxcase1 ffree %st(7) ; fld %st(-8) ; fsubrp %st(0),%st(2) }}} Using {{{-fregs-graph}}} didn't help. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 30 19:25:56 2009 From: trac at galois.com (GHC) Date: Mon Mar 30 19:13:13 2009 Subject: [GHC] #3097: Parser doesn't support doc comments on type aliases In-Reply-To: <044.6ac53274c77a45d41dec45a1148c8504@localhost> References: <044.6ac53274c77a45d41dec45a1148c8504@localhost> Message-ID: <053.fe09bb704ffab99aae7a057d20271f92@localhost> #3097: Parser doesn't support doc comments on type aliases ---------------------------------+------------------------------------------ Reporter: waern | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: major | Resolution: Keywords: Haddock | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by waern): Replying to [comment:1 simonpj]: > David, > > This looks accidental to me. In general, our story is: if it makes the parser simpler, then it's fine to make the parser more generous (ie willing to parse more stuff), and reject illegal programs later. Thanks! It is very useful to know this principle. > So maybe you should replace ''every'' use of ctype with ctypedoc (or rather rename the latter to be the former)? That would go further than you need, and would allow 'docs' to be parsed in more places. But if it doesn't give rise to ambiguities, it'd be fine by me. I originally tried to replace each `ctype` with `ctypedoc` but it gave rise to an ambiguity when parsing record fields. Comments on fields clashes with comments in field type signatures. So we really need two different productions. So what I want to do now is to just change type synonyms to use `ctypedoc`. To do that, I'd like to extend `ctypedoc` so it allows everything allowed by `ctype`. That seems to work fine. But remember that `ctypedoc` supports syntax not supported by `ctype`. It allows foralls/contexts after a contex implication (=>). So this is the remaining problem. By changing type synonyms to use `ctypedoc` we allow more things in type synonyms than we did before. Here is an example: {{{ {-# LANGUAGE Rank2Types #-} import Control.Arrow (Arrow(..)) (>>>) :: forall arr. Arrow arr => forall a b c. arr a b -> arr b c -> arr a c (>>>) = undefined type Foo = forall arr. Arrow arr => forall a b c. arr a b -> arr b c -> arr a c }}} The type signature for (>>>) is accepted since it uses `ctypedoc` which allows this syntax. But we have not accepted the declaration `Foo` before. With `ctypedoc` in type synonyms, it will now be accepted. Is that OK? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 30 23:16:07 2009 From: trac at galois.com (GHC) Date: Mon Mar 30 23:03:33 2009 Subject: [GHC] #1293: building via gcc 4.2.x on SPARC/Solaris is very slow In-Reply-To: <041.4743f2c5e5b193bbb97979ddc2558baa@localhost> References: <041.4743f2c5e5b193bbb97979ddc2558baa@localhost> Message-ID: <050.5145dd69c659a463355fe1317911277d@localhost> #1293: building via gcc 4.2.x on SPARC/Solaris is very slow ----------------------------------+----------------------------------------- Reporter: mm | Owner: benl Type: bug | Status: closed Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: wontfix Keywords: hangs compilation | Difficulty: Unknown Testcase: | Os: Solaris Architecture: sparc | ----------------------------------+----------------------------------------- Changes (by benl): * status: assigned => closed * resolution: => wontfix * summary: building ghc 6.8.3 hangs on sparc solaris at Language/Haskell/Syntax.hs => building via gcc 4.2.x on SPARC/Solaris is very slow -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 31 03:42:56 2009 From: trac at galois.com (GHC) Date: Tue Mar 31 03:30:11 2009 Subject: [GHC] #3097: Parser doesn't support doc comments on type aliases In-Reply-To: <044.6ac53274c77a45d41dec45a1148c8504@localhost> References: <044.6ac53274c77a45d41dec45a1148c8504@localhost> Message-ID: <053.f6b6735f931243228a15a044e7d62f8b@localhost> #3097: Parser doesn't support doc comments on type aliases ---------------------------------+------------------------------------------ Reporter: waern | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: major | Resolution: Keywords: Haddock | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonpj): I think it'd be fine to accept the examples you give. Doing so is in line with the principle I mentioned above. Indeed, rejecting them is probably accidental! Please write comments in your patch to explain why ctype and ctypedoc are distinct, notably the ambiguity in records. Give an example of an ambiguous piece of program text! Just to explain why (x::ty) and (ty1~ty2) are accepted in ctype, when the parser sees {{{ (C a, D a, a~b, x::Int) => blah }}} it can't tell that is is parsing a context, rather than a tuple, until very late. So we pretend that it is parsing a tuple, and sort it out later. To make that work, the parser has to recognise `(C a, D a, a~b, x::Int)` as a tuple type. And that in turn means recognising `(a~b)` and `(x::Int)` as a type. Lastly, you'll see that `(a~b)` and `(x::Int)` are treated differently (the former is in `context` while the latter is only in `type`). The reason for this is, I think, that we want to allow `f` and `g2` but not `g1`: {{{ f :: a~F b => blah -- Yes g1 :: x::Int => blah -- No g2 :: (x::Int) => blah -- Yes }}} I'm not quite sure why! While I was looking at the code, I noticed the following: * I don't think it's deliberate that `ctype` doesn't allow nested foralls, just like `ctypedoc`. That is, it should probably say {{{ | context '=>' ctype { LL $ mkImplicitHsForAllTy $1 $3 } }}} * We should probably use `gentype` rather than `type` in the LHS of type declarations * That would leave the only use of `type` in `ctype`; and only one of its occurrences makes sense there too! * So it might make sense to inline `type` there: {{{ ctype :: { LHsType RdrName } : 'forall' tv_bndrs '.' ctype { LL $ mkExplicitHsForAllTy $2 (noLoc []) $4 } | context '=>' ctype { LL $ mkImplicitHsForAllTy $1 $3 } | ipvar '::' gentype | gentype { $1 } }}} * Which in turn would let us rename `gentype` to `type` I don't know if you feel like doing this, but I thought I'd record it here so I don't forget. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 31 04:38:51 2009 From: trac at galois.com (GHC) Date: Tue Mar 31 04:26:08 2009 Subject: [GHC] #3133: Biographical profiling segfaults Message-ID: <049.2562dcb0848b6fb1ebd7a3e46a5b2e40@localhost> #3133: Biographical profiling segfaults -----------------------+---------------------------------------------------- Reporter: basvandijk | Owner: Type: bug | Status: new Priority: normal | Component: Profiling Version: 6.10.1 | Severity: blocker Keywords: | Testcase: Os: Linux | Architecture: Unknown/Multiple -----------------------+---------------------------------------------------- When I try to make a biographical profile of my program I get a segmentation fault: {{{ $ ghc --make .hs -prof -auto-all $ ./ +RTS -hb Segmentation fault }}} Note that I don't get a segmentation fault when I run the program without -hb or generate other memory usage profiles. Also note that the program itself probably doesn't matter: I tried two different programs and got a segmentation fault each time. For what it's worth, here are they: {{{ module Main where import System.Environment (getArgs) main :: IO () main = print . sum . enumFromTo (0::Int) . read . head =<< getArgs }}} {{{ module Main where import Prelude hiding (foldl) import System.Environment (getArgs) foldl :: (b -> a -> b) -> b -> [a] -> b foldl f z [] = z foldl f z (x:xs) = let z' = f z x in foldl f z' xs sum2 :: [Int] -> Int sum2 = foldl (+) 0 main :: IO() main = print . sum2 . enumFromTo 1 . read . head =<< getArgs }}} Info: {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.10.1 $ uname -a Linux bassbox 2.6.27-gentoo-r8 #4 PREEMPT Mon Mar 23 10:33:24 CET 2009 i686 AMD Athlon(tm) 64 Processor 3200+ AuthenticAMD GNU/Linux }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 31 07:18:18 2009 From: trac at galois.com (GHC) Date: Tue Mar 31 07:05:38 2009 Subject: [GHC] #2211: Installing latest GHC-6.8.2 stable: pwd with floating point exception In-Reply-To: <044.6fa473611ed5d150325a47086f85da68@localhost> References: <044.6fa473611ed5d150325a47086f85da68@localhost> Message-ID: <053.1e9572e8481923718b9f31415184b3bd@localhost> #2211: Installing latest GHC-6.8.2 stable: pwd with floating point exception -----------------------------------------+---------------------------------- Reporter: guest | Owner: Type: bug | Status: reopened Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: critical | Resolution: Keywords: Floating point exception | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -----------------------------------------+---------------------------------- Comment (by simonmar): This error is caused by an incompatibility between the libc on your system and the one on the system we used to build GHC. Update to a more recent version of the OS and you'll be fine. Igloo: do we know which version(s) of glibc are ok, so we can document it on the download page? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 31 07:21:22 2009 From: trac at galois.com (GHC) Date: Tue Mar 31 07:08:37 2009 Subject: [GHC] #3128: hClose leaves file descriptor open if it fails In-Reply-To: <045.f474a379b598a39e20f417ce0f4de22b@localhost> References: <045.f474a379b598a39e20f417ce0f4de22b@localhost> Message-ID: <054.397622c128fdadc199cf3e71a547f165@localhost> #3128: hClose leaves file descriptor open if it fails ---------------------------------+------------------------------------------ Reporter: Baughn | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: libraries/base | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: => simonmar * difficulty: => Unknown * milestone: => 6.12 branch Comment: I'll do this in the Unicode rewrite of the IO library. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 31 07:29:36 2009 From: trac at galois.com (GHC) Date: Tue Mar 31 07:16:51 2009 Subject: [GHC] #2996: Network.Socket.sClose should change socket status In-Reply-To: <046.41f89e25a108f554724958983d75e152@localhost> References: <046.41f89e25a108f554724958983d75e152@localhost> Message-ID: <055.e06b17a3c8dc42f58458e02e10ca3813@localhost> #2996: Network.Socket.sClose should change socket status ----------------------------------+----------------------------------------- Reporter: amthrax | Owner: tibbe Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: libraries/network | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Comment (by simonmar): I pushed the closed-state.patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 31 07:31:08 2009 From: trac at galois.com (GHC) Date: Tue Mar 31 07:18:23 2009 Subject: [GHC] #3129: Crypto-4.1.0 compilation failure In-Reply-To: <044.ee639a27d43ce2fb6761c14259432bcf@localhost> References: <044.ee639a27d43ce2fb6761c14259432bcf@localhost> Message-ID: <053.9c5e0e8b8f23ec6978c263ddbe707596@localhost> #3129: Crypto-4.1.0 compilation failure -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: duplicate Keywords: Crypto-4.1.0 | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -----------------------------+---------------------------------------------- Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: I think the canonical ticket for this bug is #2753. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 31 07:33:56 2009 From: trac at galois.com (GHC) Date: Tue Mar 31 07:21:49 2009 Subject: [GHC] #3132: x86 code generator generates bad FPU register names In-Reply-To: <044.486f0fa3ddd7b77dad74344aee019e46@localhost> References: <044.486f0fa3ddd7b77dad74344aee019e46@localhost> Message-ID: <053.d11a43a29fcb057f2096bd24f40a4c77@localhost> #3132: x86 code generator generates bad FPU register names -------------------------------+-------------------------------------------- Reporter: int-e | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12 branch Component: Compiler (NCG) | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by simonmar): * priority: normal => high * difficulty: => Unknown * milestone: => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 31 07:35:44 2009 From: trac at galois.com (GHC) Date: Tue Mar 31 07:22:59 2009 Subject: [GHC] #3133: Biographical profiling segfaults In-Reply-To: <049.2562dcb0848b6fb1ebd7a3e46a5b2e40@localhost> References: <049.2562dcb0848b6fb1ebd7a3e46a5b2e40@localhost> Message-ID: <058.42f200fa216b1db8f28a6ff2a6b4a6ae@localhost> #3133: Biographical profiling segfaults ---------------------------------+------------------------------------------ Reporter: basvandijk | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Profiling | Version: 6.10.1 Severity: blocker | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: Thanks for the report. This should be fixed in the (forthcoming) 6.10.2. See #3001. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 31 08:06:45 2009 From: trac at galois.com (GHC) Date: Tue Mar 31 08:00:34 2009 Subject: [GHC] #2211: Installing latest GHC-6.8.2 stable: pwd with floating point exception In-Reply-To: <044.6fa473611ed5d150325a47086f85da68@localhost> References: <044.6fa473611ed5d150325a47086f85da68@localhost> Message-ID: <053.82f9afeacc1e2850b4044544d8387091@localhost> #2211: Installing latest GHC-6.8.2 stable: pwd with floating point exception -----------------------------------------+---------------------------------- Reporter: guest | Owner: Type: bug | Status: reopened Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: critical | Resolution: Keywords: Floating point exception | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -----------------------------------------+---------------------------------- Comment (by igloo): I don't know which versions are OK. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 31 15:56:05 2009 From: trac at galois.com (GHC) Date: Tue Mar 31 15:43:19 2009 Subject: [GHC] #3134: encodeFloat . decodeFloat Message-ID: <045.24712bc58e93c54f33f4f129effc8533@localhost> #3134: encodeFloat . decodeFloat -----------------------------+---------------------------------------------- Reporter: roland | Owner: Type: bug | Status: new Priority: normal | Component: Prelude Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- > (0.0/0.0) NaN > (uncurry encodeFloat . decodeFloat) (0.0/0.0) -Infinity It seems reasonable to expect NaN here. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 31 17:58:44 2009 From: trac at galois.com (GHC) Date: Tue Mar 31 17:45:58 2009 Subject: [GHC] #3097: Parser doesn't support doc comments on type aliases In-Reply-To: <044.6ac53274c77a45d41dec45a1148c8504@localhost> References: <044.6ac53274c77a45d41dec45a1148c8504@localhost> Message-ID: <053.ba15902aa0c6d4b694d2ecdf7b714423@localhost> #3097: Parser doesn't support doc comments on type aliases ---------------------------------+------------------------------------------ Reporter: waern | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: major | Resolution: Keywords: Haddock | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by waern): Replying to [comment:3 simonpj]: > I think it'd be fine to accept the examples you give. Doing so is in line with the principle I mentioned above. Indeed, rejecting them is probably accidental! > Just to be clear, since you say "them": It's actually only `Foo` which was rejected before. The type of (>>>) has been allowed before since it uses `ctypedoc`. (This was not so clear in my last note). > Please write comments in your patch to explain why ctype and ctypedoc are distinct, notably the ambiguity in records. Give an example of an ambiguous piece of program text! Here is my patch, which I've validated and pushed to HEAD: {{{ Tue Mar 31 23:23:06 CEST 2009 David Waern * Allow Haddock comments in type synonyms We now use `ctypedoc` instead of `ctype` for type synonyms. `ctypedoc` was previously only used for top-level type signatures. This change means that type synonyms now can contain comments, just like top-level type signatures. Note: * I've modified `ctypedoc` so it allows implicit parameters and equational constraints, just like ctype. * Since `ctypedoc` allows nested foralls, we now allow that in type synonyms. * I have inlined some productions into gentypedoc so that there is now a non-doc version of every production with a 'doc' suffix. (Stylistic change only, which should make the code easier to follow). * It would have been nice to simplify the grammar by unifying `ctype` and ctypedoc` into one production, allowing comments on types everywhere (and rejecting them after parsing, where necessary). This is however not possible since it leads to ambiguity. The reason is the support for comments on record fields: > data R = R { field :: Int -- ^ comment on the field } If we allow comments on types here, it's not clear if the comment applies to 'field' or to 'Int'. So we must use `ctype` to describe the type. }}} > Just to explain why (x::ty) and (ty1~ty2) are accepted in ctype, when the parser sees > {{{ > (C a, D a, a~b, x::Int) => blah > }}} > it can't tell that is is parsing a context, rather than a tuple, until very late. So we pretend that it is parsing a tuple, and sort it out later. To make that work, the parser has to recognise `(C a, D a, a~b, x::Int)` as a tuple type. And that in turn means recognising `(a~b)` and `(x::Int)` as a type. > Thanks for this explanation! It makes sense. > Lastly, you'll see that `(a~b)` and `(x::Int)` are treated differently (the former is in `context` while the latter is only in `type`). The reason for this is, I think, that we want to allow `f` and `g2` but not `g1`: > {{{ > f :: a~F b => blah -- Yes > g1 :: x::Int => blah -- No > g2 :: (x::Int) => blah -- Yes > }}} > I'm not quite sure why! I think I remember wondering why parenthesis was needed around IPs when I used them, long ago. I just thought it was to avoid multiple `::` on the same level. I noticed that you seem to require kind signatures to be in parenthesis, also. > While I was looking at the code, I noticed the following: > * I don't think it's deliberate that `ctype` doesn't allow nested foralls, just like `ctypedoc`. That is, it should probably say > {{{ > | context '=>' ctype { LL $ mkImplicitHsForAllTy $1 $3 } > }}} > * We should probably use `gentype` rather than `type` in the LHS of type declarations > * That would leave the only use of `type` in `ctype`; and only one of its occurrences makes sense there too! > * So it might make sense to inline `type` there: > {{{ > ctype :: { LHsType RdrName } > : 'forall' tv_bndrs '.' ctype { LL $ mkExplicitHsForAllTy $2 (noLoc []) $4 } > | context '=>' ctype { LL $ mkImplicitHsForAllTy $1 $3 } > | ipvar '::' gentype > | gentype { $1 } > }}} > * Which in turn would let us rename `gentype` to `type` I don't have time to do this right now (already validated). But I'll get to it later, hopefully. Btw, is there a change my patch could be merged to the stable branch (i.e get into 6.10.2)? It's a pretty important Haddock bug, so it would be nice to get it fixed in 6.10.2, now that it will become part of the first Haskell Platform and all. :-) If you don't dare to merge it, that's fine, of course. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 31 21:46:28 2009 From: trac at galois.com (GHC) Date: Tue Mar 31 21:34:17 2009 Subject: [GHC] #186: Bad sparc Int64 code via NCG with -O In-Reply-To: <045.00b040dbc11af02e0fa7455a84a2a38a@localhost> References: <045.00b040dbc11af02e0fa7455a84a2a38a@localhost> Message-ID: <054.37bf7cf15b5e60bf0951533fa885bd7d@localhost> #186: Bad sparc Int64 code via NCG with -O -------------------------------+-------------------------------------------- Reporter: nobody | Owner: benl Type: bug | Status: closed Priority: low | Milestone: _|_ Component: Compiler (NCG) | Version: 6.0.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: enum02 | Os: Unknown/Multiple Architecture: sparc | -------------------------------+-------------------------------------------- Changes (by benl): * status: new => closed * resolution: None => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 31 21:51:01 2009 From: trac at galois.com (GHC) Date: Tue Mar 31 21:38:17 2009 Subject: [GHC] #1501: Panic in RegisterAlloc In-Reply-To: <044.f7c3918326114c19463f5f9e9eea6707@localhost> References: <044.f7c3918326114c19463f5f9e9eea6707@localhost> Message-ID: <053.fb8e831b81bce46d7550903ae7db32c8@localhost> #1501: Panic in RegisterAlloc -------------------------------+-------------------------------------------- Reporter: guest | Owner: benl Type: bug | Status: closed Priority: high | Milestone: 6.12 branch Component: Compiler (NCG) | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: cmm002 | Os: Unknown/Multiple Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by benl): * status: assigned => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 31 21:57:58 2009 From: trac at galois.com (GHC) Date: Tue Mar 31 21:45:13 2009 Subject: [GHC] #2906: .hc code generated for Parser.hs is 2MB big In-Reply-To: <043.64c088340779512ef40025c8e0908a45@localhost> References: <043.64c088340779512ef40025c8e0908a45@localhost> Message-ID: <052.e11347ad09980bc882e68e2246511a9d@localhost> #2906: .hc code generated for Parser.hs is 2MB big -------------------------+-------------------------------------------------- Reporter: benl | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: sparc | -------------------------+-------------------------------------------------- Changes (by benl): * status: new => closed * resolution: => duplicate Comment: dup of #1293 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 31 22:01:31 2009 From: trac at galois.com (GHC) Date: Tue Mar 31 21:48:49 2009 Subject: [GHC] #951: stage2 on sparc dies with "schedule: re-entered unsafely" In-Reply-To: <045.a567b71646e7cba6dde8632a9b13b02f@localhost> References: <045.a567b71646e7cba6dde8632a9b13b02f@localhost> Message-ID: <054.c1527c22a1fae2de5033aa170c662ca5@localhost> #951: stage2 on sparc dies with "schedule: re-entered unsafely" -----------------------------+---------------------------------------------- Reporter: duncan | Owner: benl Type: bug | Status: closed Priority: normal | Milestone: 6.10.2 Component: Build System | Version: 6.6 Severity: major | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: N/A | Os: Unknown/Multiple Architecture: sparc | -----------------------------+---------------------------------------------- Changes (by benl): * status: assigned => closed * resolution: => wontfix Comment: See Solaris building guide at [wiki:Building/Solaris] -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 31 22:07:45 2009 From: trac at galois.com (GHC) Date: Tue Mar 31 21:55:01 2009 Subject: [GHC] #606: Sparc native code generator In-Reply-To: <047.b8e3bb2205a0b318b3e126905836b895@localhost> References: <047.b8e3bb2205a0b318b3e126905836b895@localhost> Message-ID: <056.feeefb1d79d22b8be1888df0debde21d@localhost> #606: Sparc native code generator -------------------------+-------------------------------------------------- Reporter: simonmar | Owner: Type: task | Status: closed Priority: normal | Milestone: _|_ Component: Compiler | Version: None Severity: normal | Resolution: fixed Keywords: | Difficulty: Difficult (1 week) Testcase: N/A | Os: Unknown/Multiple Architecture: sparc | -------------------------+-------------------------------------------------- Changes (by benl): * status: new => closed * resolution: None => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 31 22:41:13 2009 From: trac at galois.com (GHC) Date: Tue Mar 31 22:28:29 2009 Subject: [GHC] #2272: internal error: getMBlock: mmap: Bad file number In-Reply-To: <044.485296ba49fdd540ac589cc1c46011fb@localhost> References: <044.485296ba49fdd540ac589cc1c46011fb@localhost> Message-ID: <053.5fb184a84a21f299a7c672862111b84e@localhost> #2272: internal error: getMBlock: mmap: Bad file number -------------------------------+-------------------------------------------- Reporter: hpwei | Owner: benl Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: worksforme Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: sparc | -------------------------------+-------------------------------------------- Changes (by benl): * status: new => closed * resolution: => worksforme Comment: It worked for me on SPARC/Solaris 5.10 with 6.8.3 and the head. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 31 23:28:09 2009 From: trac at galois.com (GHC) Date: Tue Mar 31 23:15:26 2009 Subject: [GHC] #2413: Segmentation fault in ghc --interactive when run with +RTS -Da In-Reply-To: <053.7a18e92eaea058983613232db722e65d@localhost> References: <053.7a18e92eaea058983613232db722e65d@localhost> Message-ID: <062.feab311114b191b8a360d98eb7c573c5@localhost> #2413: Segmentation fault in ghc --interactive when run with +RTS -Da ---------------------------------+------------------------------------------ Reporter: batterseapower | Owner: Type: bug | Status: closed Priority: low | Milestone: _|_ Component: Runtime System | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by benl): * status: new => closed * resolution: => fixed Comment: This would have been fixed in: Mon Jan 12 16:34:21 EST 2009 Ben.Lippmeier@anu.edu.au * Untag closure pointers before trying to print them. In RTS tracing code, need to untag the pointer before trying to load the info table in printClosure() Mon Jan 12 11:56:25 EST 2009 Ben.Lippmeier@anu.edu.au * Add missing documention of -Da DEBUG: apply flag to RTS help. M ./rts/RtsFlags.c +2 -- Ticket URL: GHC The Glasgow Haskell Compiler