From trac at galois.com Tue Dec 1 04:17:11 2009 From: trac at galois.com (GHC) Date: Tue Dec 1 03:52:12 2009 Subject: [GHC] #3683: could not build ghc-6.12.0.20091121 under solaris In-Reply-To: <045.e5089cca43f6d0feea222b47017c2de3@localhost> References: <045.e5089cca43f6d0feea222b47017c2de3@localhost> Message-ID: <054.787105e51196f95ebfae50e95cedf364@localhost> #3683: could not build ghc-6.12.0.20091121 under solaris ----------------------------------+----------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: | Os: Solaris Testcase: | Architecture: Unknown/Multiple Failure: Building GHC failed | ----------------------------------+----------------------------------------- Comment (by maeder): Replying to [comment:7 simonmar]: > My guess is that this has something to do with the `$$(shell ...)` commands in `rules/distdir-way-opts.mk`. You could try replacing, e.g. > > {{{ > $1_$2_$3_HSC2HS_CC_OPTS:=$$(shell for i in $$($1_$2_DIST_CC_OPTS); do echo \'--cflag=$$$$i\'; done) > }}} The problem lies in an empty do-loop. `$$($1_$2_DIST_CC_OPTS)` within `$$(shell ...)` is expanded to nothing. I've changed SHELL in mk/config.mk to my own shell that also shows the arguments. The arguments are as follows: {{{ -c gmake -r --no-print-directory -f ghc.mk phase=0 just-makefiles -c for i in ; do echo -isystem\"$i\"; done -c for i in ; do echo \"-L$i\"; done -c for i in ; do echo \'--cflag=$i\'; done -c for i in ; do echo \'--lflag=$i\'; done }}} Checking bash versus sh shows: {{{ -bash-3.00$ for i in ; do echo $i ; done -bash-3.00$ sh $ for i in ; do echo $i ; done syntax error: `;' unexpected }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 1 04:23:09 2009 From: trac at galois.com (GHC) Date: Tue Dec 1 03:58:00 2009 Subject: [GHC] #3683: could not build ghc-6.12.0.20091121 under solaris In-Reply-To: <045.e5089cca43f6d0feea222b47017c2de3@localhost> References: <045.e5089cca43f6d0feea222b47017c2de3@localhost> Message-ID: <054.3cbe4fa9a06c63a54ec729d9786f4dad@localhost> #3683: could not build ghc-6.12.0.20091121 under solaris ----------------------------------+----------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: | Os: Solaris Testcase: | Architecture: Unknown/Multiple Failure: Building GHC failed | ----------------------------------+----------------------------------------- Comment (by maeder): P.S. I wish you would validate under solaris to avoid such re-occurring problems. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 1 07:58:43 2009 From: trac at galois.com (GHC) Date: Tue Dec 1 07:33:30 2009 Subject: [GHC] #3681: hsc2hs wrapper script throws away $HSC2HS_EXTRA's value when specified C compiler to use In-Reply-To: <042.c4b5030684625e3b4acbf7f52bd1fe70@localhost> References: <042.c4b5030684625e3b4acbf7f52bd1fe70@localhost> Message-ID: <051.f42cb59b0b608f31bf3b761a44ae503d@localhost> #3681: hsc2hs wrapper script throws away $HSC2HS_EXTRA's value when specified C compiler to use ---------------------+------------------------------------------------------ Reporter: nwn | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: hsc2hs | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: | Os: MacOS X Testcase: | Architecture: x86 Failure: Other | ---------------------+------------------------------------------------------ Changes (by igloo): * owner: => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 1 08:00:22 2009 From: trac at galois.com (GHC) Date: Tue Dec 1 07:35:21 2009 Subject: [GHC] #3683: could not build ghc-6.12.0.20091121 under solaris In-Reply-To: <045.e5089cca43f6d0feea222b47017c2de3@localhost> References: <045.e5089cca43f6d0feea222b47017c2de3@localhost> Message-ID: <054.0da93ba804664aabd72b6efd285ed970@localhost> #3683: could not build ghc-6.12.0.20091121 under solaris ----------------------------------+----------------------------------------- Reporter: maeder | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: | Os: Solaris Testcase: | Architecture: Unknown/Multiple Failure: Building GHC failed | ----------------------------------+----------------------------------------- Changes (by igloo): * owner: => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 1 09:23:50 2009 From: trac at galois.com (GHC) Date: Tue Dec 1 08:58:39 2009 Subject: [GHC] #3708: more build errors for ghc-6.12.0.20091121 under solaris Message-ID: <045.fc42158022ad9a4d149857752418b436@localhost> #3708: more build errors for ghc-6.12.0.20091121 under solaris ---------------------------------+------------------------------------------ Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.12.1 RC1 | Keywords: Os: Solaris | Testcase: Architecture: Unknown/Multiple | Failure: Building GHC failed ---------------------------------+------------------------------------------ getting beyond the bin/sh and sed errors (#3683) I get {{{ ===--- updating makefiles phase 2 gmake -r --no-print-directory -f ghc.mk phase=2 just-makefiles compiler/ghc.mk:443: compiler/stage1/build/.depend-v: No such file or directory "inplace/bin/mkdirhier" compiler/stage1/build/ "inplace/bin/hsc2hs" --cc=/opt/csw/gcc4/bin/gcc --ld=/opt/csw/gcc4/bin/gcc --cflag=-D__GLASGOW_HASKELL__=612 compiler/utils/Fingerprint.hsc -o compiler/stage1/build/Fingerprint.hs Fingerprint.hsc: In function 'main': Fingerprint.hsc:65: error: invalid application of 'sizeof' to incomplete type 'structMD5Context' Fingerprint.hsc:65: error: invalid application of 'sizeof' to incomplete type 'structMD5Context' Fingerprint.hsc:65: error: invalid application of 'sizeof' to incomplete type 'structMD5Context' compiling compiler/stage1/build/Fingerprint_hsc_make.c failed command was: /opt/csw/gcc4/bin/gcc -c -D__GLASGOW_HASKELL__=612 -I/export/local1/home/maeder/haskell/ghc-6.12.0.20091121/inplace/lib/include/ compiler/stage1/build/Fingerprint_hsc_make.c -o compiler/stage1/build/Fingerprint_hsc_make.o gmake[1]: *** [compiler/stage1/build/Fingerprint.hs] Error 1 gmake: *** [all] Error 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 1 09:45:09 2009 From: trac at galois.com (GHC) Date: Tue Dec 1 09:19:59 2009 Subject: [GHC] #3708: more build errors for ghc-6.12.0.20091121 under solaris In-Reply-To: <045.fc42158022ad9a4d149857752418b436@localhost> References: <045.fc42158022ad9a4d149857752418b436@localhost> Message-ID: <054.27eb3c45551472fcccdfac8041d06e81@localhost> #3708: more build errors for ghc-6.12.0.20091121 under solaris ---------------------------------+------------------------------------------ Reporter: maeder | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 6.12.1 RC1 Resolution: duplicate | Keywords: Os: Solaris | Testcase: Architecture: Unknown/Multiple | Failure: Building GHC failed ---------------------------------+------------------------------------------ Changes (by maeder): * status: new => closed * resolution: => duplicate Comment: It seems this error is due to the still wrong file `distdir-way-opts.mk` from #3683 that does not produce further options, i. e.`'-- cflag=-Icompiler/stage1'` -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 1 09:45:37 2009 From: trac at galois.com (GHC) Date: Tue Dec 1 09:20:30 2009 Subject: [GHC] #3706: "GHC Commentary" link in HACKING is broken In-Reply-To: <042.882b10c3a39d4efd239db36fcdf2edfc@localhost> References: <042.882b10c3a39d4efd239db36fcdf2edfc@localhost> Message-ID: <051.ed26bae1fa6e700028f82f895b84084f@localhost> #3706: "GHC Commentary" link in HACKING is broken --------------------------------+------------------------------------------- Reporter: jli | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 6.10.4 Resolution: | Keywords: broken link Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Documentation bug | --------------------------------+------------------------------------------- Changes (by igloo): * owner: => igloo * difficulty: => -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 1 09:54:40 2009 From: trac at galois.com (GHC) Date: Tue Dec 1 09:29:34 2009 Subject: [GHC] #3682: shared libraries not installed executable In-Reply-To: <050.74da172fa23f1ae1ddea30f8c8576c12@localhost> References: <050.74da172fa23f1ae1ddea30f8c8576c12@localhost> Message-ID: <059.e3f4178c0d9778ceb524ae7f2b26e00e@localhost> #3682: shared libraries not installed executable -----------------------------+---------------------------------------------- Reporter: juhpetersen | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: Component: Package system | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * owner: => igloo Comment: Thanks for the patch! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 1 10:19:45 2009 From: trac at galois.com (GHC) Date: Tue Dec 1 09:54:37 2009 Subject: [GHC] #3683: could not build ghc-6.12.0.20091121 under solaris In-Reply-To: <045.e5089cca43f6d0feea222b47017c2de3@localhost> References: <045.e5089cca43f6d0feea222b47017c2de3@localhost> Message-ID: <054.ad5808ff48b04be41bff92d9e993916f@localhost> #3683: could not build ghc-6.12.0.20091121 under solaris ----------------------------------+----------------------------------------- Reporter: maeder | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: | Os: Solaris Testcase: | Architecture: Unknown/Multiple Failure: Building GHC failed | ----------------------------------+----------------------------------------- Comment (by maeder): The attached file `distdir-way-opts.mk` does not work (see #3708) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 1 11:13:45 2009 From: trac at galois.com (GHC) Date: Tue Dec 1 10:48:31 2009 Subject: [GHC] #3693: Show stack traces In-Reply-To: <043.7c288f8e774d3806292d73b1513892ec@localhost> References: <043.7c288f8e774d3806292d73b1513892ec@localhost> Message-ID: <052.8dfb9c0aefce94513c2b8d4cb6bc994c@localhost> #3693: Show stack traces ------------------------------+--------------------------------------------- Reporter: jpet | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Runtime System | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ------------------------------+--------------------------------------------- Comment (by simonmar): Right, yes, we could do that. I didn't consider that kind of thing because I have a feeling it would bloat binaries too much (there are a lot more case expressions than constructors), but someone could do the experiment and find out. Putting the info in a debug section as I mentioned before would be a good way to avoid the binary bloat, but it makes it more complicated to extract again. If you're going to do that you might as well use the symbol table too, rather than duplicate the info in the debug section. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 1 11:38:02 2009 From: trac at galois.com (GHC) Date: Tue Dec 1 11:13:00 2009 Subject: [GHC] #3683: could not build ghc-6.12.0.20091121 under solaris In-Reply-To: <045.e5089cca43f6d0feea222b47017c2de3@localhost> References: <045.e5089cca43f6d0feea222b47017c2de3@localhost> Message-ID: <054.b9223c6f22b9792791c793203fa8fb29@localhost> #3683: could not build ghc-6.12.0.20091121 under solaris ----------------------------------+----------------------------------------- Reporter: maeder | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: | Os: Solaris Testcase: | Architecture: Unknown/Multiple Failure: Building GHC failed | ----------------------------------+----------------------------------------- Comment (by simonmar): Replying to [comment:11 maeder]: > P.S. I wish you would validate under solaris to avoid such re-occurring problems. I wish we were able to do that too, but sadly it isn't practical at the moment. We're currently thinking about replacing the buildbot infrastructure and hopefully making it possible to remotely validate on multiple platforms at the same time. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 1 13:32:23 2009 From: trac at galois.com (GHC) Date: Tue Dec 1 13:07:26 2009 Subject: [GHC] #3683: could not build ghc-6.12.0.20091121 under solaris In-Reply-To: <045.e5089cca43f6d0feea222b47017c2de3@localhost> References: <045.e5089cca43f6d0feea222b47017c2de3@localhost> Message-ID: <054.ce3813b4e1371ce8b78f6453a83a42b5@localhost> #3683: could not build ghc-6.12.0.20091121 under solaris ----------------------------------+----------------------------------------- Reporter: maeder | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 6.12.1 RC1 Resolution: fixed | Keywords: Difficulty: | Os: Solaris Testcase: | Architecture: Unknown/Multiple Failure: Building GHC failed | ----------------------------------+----------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed in HEAD and 6.12 by: {{{ Tue Dec 1 04:59:27 PST 2009 Ian Lynagh * Avoid running empty for loops; fixes trac #3683 Solaris's sh gives /bin/sh: syntax error at line 1: `;' unexpected when faced with something like for x in ; do ...; done Patch from Christian Maeder. }}} {{{ Tue Dec 1 05:36:09 PST 2009 Ian Lynagh * Delay expansion of some makefile variables until they are available }}} The second patch should fix the #3708 problem too. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 1 13:34:34 2009 From: trac at galois.com (GHC) Date: Tue Dec 1 13:09:28 2009 Subject: [GHC] #3683: could not build ghc-6.12.0.20091121 under solaris In-Reply-To: <045.e5089cca43f6d0feea222b47017c2de3@localhost> References: <045.e5089cca43f6d0feea222b47017c2de3@localhost> Message-ID: <054.aa2a06ba629b97902f18c77de7114c94@localhost> #3683: could not build ghc-6.12.0.20091121 under solaris ----------------------------------+----------------------------------------- Reporter: maeder | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 6.12.1 RC1 Resolution: fixed | Keywords: Difficulty: | Os: Solaris Testcase: | Architecture: Unknown/Multiple Failure: Building GHC failed | ----------------------------------+----------------------------------------- Comment (by igloo): Also, for the `[:space:]` problem I've made the build system use gsed if it exists: {{{ Tue Dec 1 05:07:41 PST 2009 Ian Lynagh * Look for sed as gsed first Solaris's sed apparently doesn't understand [:space:] Tue Dec 1 05:10:31 PST 2009 Ian Lynagh * Call $(SED) rather than sed }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 1 13:37:41 2009 From: trac at galois.com (GHC) Date: Tue Dec 1 13:12:30 2009 Subject: [GHC] #3681: hsc2hs wrapper script throws away $HSC2HS_EXTRA's value when specified C compiler to use In-Reply-To: <042.c4b5030684625e3b4acbf7f52bd1fe70@localhost> References: <042.c4b5030684625e3b4acbf7f52bd1fe70@localhost> Message-ID: <051.da9f278c5d7712dab99587a26e7af730@localhost> #3681: hsc2hs wrapper script throws away $HSC2HS_EXTRA's value when specified C compiler to use ---------------------+------------------------------------------------------ Reporter: nwn | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: hsc2hs | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: | Os: MacOS X Testcase: | Architecture: x86 Failure: Other | ---------------------+------------------------------------------------------ Changes (by igloo): * priority: high => normal * milestone: 6.12.1 => 6.14.1 Comment: Fixed, for now, in HEAD and 6.12 by: {{{ Tue Dec 1 04:47:16 PST 2009 Ian Lynagh * Don't set HSC2HS_EXTRA= when we get a --cc= flag; fixes trac #3681 On OS X, we need to specify -m32 or -m64 in order to get gcc to build binaries for the right target. We do that by putting it in HSC2HS_EXTRA. When cabal runs hsc2hs, it passes a flag saying which gcc to use, so if we set HSC2HS_EXTRA= then we don't get binaries for the right platform. So for now we just don't set HSC2HS_EXTRA= but we probably want to revisit how this works in the future. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 1 14:00:37 2009 From: trac at galois.com (GHC) Date: Tue Dec 1 13:35:26 2009 Subject: [GHC] #3694: Image link in User's Guide is broken In-Reply-To: <042.4dce51a64fcceef53092b64072938194@localhost> References: <042.4dce51a64fcceef53092b64072938194@localhost> Message-ID: <051.b6d1d6ee90c180c926141b15824fa8f8@localhost> #3694: Image link in User's Guide is broken --------------------------------+------------------------------------------- Reporter: jli | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.12.1 Component: Documentation | Version: 6.10.4 Resolution: fixed | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Documentation bug | --------------------------------+------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 1 14:02:31 2009 From: trac at galois.com (GHC) Date: Tue Dec 1 13:37:18 2009 Subject: [GHC] #3684: Missing ghc-pkg options in --help In-Reply-To: <047.1024f8df520bd9d4665f757c76edb0a3@localhost> References: <047.1024f8df520bd9d4665f757c76edb0a3@localhost> Message-ID: <056.3c606afd5b8ac9a81b50f2b6627ea360@localhost> #3684: Missing ghc-pkg options in --help --------------------------------+------------------------------------------- Reporter: kolmodin | Owner: igloo Type: merge | Status: closed Priority: high | Milestone: 6.12.2 Component: ghc-pkg | Version: 6.12.1 RC1 Resolution: fixed | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Documentation bug | --------------------------------+------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 1 15:16:49 2009 From: trac at galois.com (GHC) Date: Tue Dec 1 14:51:34 2009 Subject: [GHC] #3682: shared libraries not installed executable In-Reply-To: <050.74da172fa23f1ae1ddea30f8c8576c12@localhost> References: <050.74da172fa23f1ae1ddea30f8c8576c12@localhost> Message-ID: <059.374c9f446e9ae15b8bb8653681d4ba3d@localhost> #3682: shared libraries not installed executable -----------------------------+---------------------------------------------- Reporter: juhpetersen | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: Component: Package system | Version: 6.12.1 RC1 Resolution: fixed | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed in 6.12, HEAD and the respective Cabal upstreams: {{{ Tue Dec 1 06:53:49 PST 2009 Ian Lynagh * Install shared libraries as executable files Fixes GHC trac #3682. Patch from juhpetersen. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 1 15:17:21 2009 From: trac at galois.com (GHC) Date: Tue Dec 1 14:52:11 2009 Subject: [GHC] #3706: "GHC Commentary" link in HACKING is broken In-Reply-To: <042.882b10c3a39d4efd239db36fcdf2edfc@localhost> References: <042.882b10c3a39d4efd239db36fcdf2edfc@localhost> Message-ID: <051.75b82369bb66f8c61b5cc6b30bb15e1b@localhost> #3706: "GHC Commentary" link in HACKING is broken --------------------------------+------------------------------------------- Reporter: jli | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 6.10.4 Resolution: fixed | Keywords: broken link Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Documentation bug | --------------------------------+------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Thanks for the report! Fixed in HEAD and 6.12: {{{ Tue Dec 1 07:01:49 PST 2009 Ian Lynagh * Fix Commentary link in the HACKING file; trac #3706 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 1 15:26:00 2009 From: trac at galois.com (GHC) Date: Tue Dec 1 15:00:50 2009 Subject: [GHC] #3709: Data.Either.partitionEithers is not lazy enough Message-ID: <056.ddd6dbef542c6ca3bde6bd36bb5cb4f0@localhost> #3709: Data.Either.partitionEithers is not lazy enough ----------------------------------+----------------------------------------- Reporter: daniel.is.fischer | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 6.10.4 | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ----------------------------------+----------------------------------------- Data.Either.partitionEithers gives a stack overflow for long or infinite lists. Change {{{ partitionEithers :: [Either a b] -> ([a],[b]) partitionEithers = foldr (either left right) ([],[]) where left a (l, r) = (a:l, r) right a (l, r) = (l, a:r) }}} to {{{ partitionEithers :: [Either a b] -> ([a],[b]) partitionEithers = foldr (either left right) ([],[]) where left a ~(l, r) = (a:l, r) right a ~(l, r) = (l, a:r) }}} to make it lazy enough. Example: {{{ Data.Either> let fun k = case gcd k 15 of { 3 -> Left "Fizz"; 5 -> Left "Buzz"; 15 -> Left "FizzBuzz"; _ -> Right k } Data.Either> take 10 . snd . partitionEithers $ map fun [1 .. 2*10^6 :: Integer] *** Exception: stack overflow Data.Either> take 10 . snd . lpartitionEithers $ map fun [1 :: Integer .. ] [1,2,4,7,8,11,13,14,16,17] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 1 15:54:23 2009 From: trac at galois.com (GHC) Date: Tue Dec 1 15:29:11 2009 Subject: [GHC] #3472: Porting through .hc files broken In-Reply-To: <046.fbcd146ac7544c3ae31be3ef2ccbd0d8@localhost> References: <046.fbcd146ac7544c3ae31be3ef2ccbd0d8@localhost> Message-ID: <055.ccc847c1d09b6140c8cac15dd9d5abad@localhost> #3472: Porting through .hc files broken ---------------------------+------------------------------------------------ Reporter: pumpkin | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Build System | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by donn): * failure: => None/Unknown Comment: I just built and installed 6.12.0.20091121 on Haiku, using vaguely similar NetBSD-i386 as a donor. ksf already discussed the principle issues with the .hc build. Also: package-depend.mk are infected with external library references from the donor host - e.g., if on NetBSD, openpty needs -lutil, then this library will be required on the target host. Target host build directory must conform to absolute paths from the donor host. compiler/main/Config.hs uses the donor host's absolute path for cGCC. I dealt with the main issues by swapping in HsBaseConfig.h from the target host, before stage2 ghc was built on the donor, and hacked in my own stat struct with the target's layout. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 1 18:19:34 2009 From: trac at galois.com (GHC) Date: Tue Dec 1 17:54:23 2009 Subject: [GHC] #3668: PIE-enabled hardened gcc might broke GHC. In-Reply-To: <051.fc2bc37dc406e40bf1e5b1d4649c850b@localhost> References: <051.fc2bc37dc406e40bf1e5b1d4649c850b@localhost> Message-ID: <060.bfe649522b23f89cf1f32b2ca551f8fd@localhost> #3668: PIE-enabled hardened gcc might broke GHC. ---------------------------+------------------------------------------------ Reporter: secludedsage | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: fixed | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86 Failure: None/Unknown | ---------------------------+------------------------------------------------ Comment (by kolmodin): We've had similar patches like this in previous ghc versions for Gentoo, but with ghc 6.10.4 it somehow slipped away. I don't know if it can be solved in the build system in another way. The flags we put into {{{${GHC_CFLAGS}}}} is currently parts the users' {{{${CFLAGS}}}}, mostly to do with the arch and ABI flags. Then for hardend we add {{{-nopie}}}, for gccs with stack protectors we turn that off. For ppc64 we need {{{-mminimal-toc}}}, and for earlier ghc versions we've passed the {{{-Wa,--noexecstack}}} flag due to QA in Gentoo. These are flags we always want in place, thus it's natural to put it in the ghc wrapper. To see more details on how all this funny business comes together, see the ghc-6.12rc2 ebuild: http://code.haskell.org/gentoo/gentoo-haskell/dev- lang/ghc/ghc-6.12.0.20091121.ebuild -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 1 18:20:11 2009 From: trac at galois.com (GHC) Date: Tue Dec 1 17:54:58 2009 Subject: [GHC] #3668: PIE-enabled hardened gcc might broke GHC. In-Reply-To: <051.fc2bc37dc406e40bf1e5b1d4649c850b@localhost> References: <051.fc2bc37dc406e40bf1e5b1d4649c850b@localhost> Message-ID: <060.71232d63753558a571df750206bfe532@localhost> #3668: PIE-enabled hardened gcc might broke GHC. ---------------------------+------------------------------------------------ Reporter: secludedsage | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: fixed | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86 Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by kolmodin): * cc: kolmodin@gentoo.org (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 1 23:05:30 2009 From: trac at galois.com (GHC) Date: Tue Dec 1 22:40:22 2009 Subject: [GHC] #3709: Data.Either.partitionEithers is not lazy enough In-Reply-To: <056.ddd6dbef542c6ca3bde6bd36bb5cb4f0@localhost> References: <056.ddd6dbef542c6ca3bde6bd36bb5cb4f0@localhost> Message-ID: <065.524845c0d86a87631846ebf4559341a5@localhost> #3709: Data.Either.partitionEithers is not lazy enough --------------------------------------+------------------------------------- Reporter: daniel.is.fischer | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 6.10.4 Resolution: fixed | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Runtime performance bug | --------------------------------------+------------------------------------- Changes (by malcolm.wallace@cs.york.ac.uk): * status: new => closed * difficulty: => * resolution: => fixed * failure: None/Unknown => Runtime performance bug Comment: Fixed by {{{ * Data.Either.partitionEithers was insufficiently lazy. Ignore-this: 77e1b3288f66608c71458d8a91bcbe12 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 1 23:21:52 2009 From: trac at galois.com (GHC) Date: Tue Dec 1 22:56:36 2009 Subject: [GHC] #3710: WriteFile: invalid argument (The handle is invalid.) Message-ID: <049.64f91bfcc534a4ca7b7a2b4fe6766e23@localhost> #3710: WriteFile: invalid argument (The handle is invalid.) ---------------------------+------------------------------------------------ Reporter: dherington | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 6.10.4 | Keywords: garbage collector Os: Windows | Testcase: Architecture: x86 | Failure: Incorrect result at runtime ---------------------------+------------------------------------------------ I defined an interface to the Windows WriteFile routine to allow specification of the starting address for the write. It generally works, but when called repeatedly it reproducibly generates an unexpected error at runtime: WriteFile: invalid argument (The handle is invalid.) I suspect that garbage collection is involved because Bug1 2 fum 1000 fails, but Bug1 +RTS -H1g -RTS 2 fum 1000 (which serves, I think, to disable garbage collection for my test) succeeds. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 2 04:34:14 2009 From: trac at galois.com (GHC) Date: Wed Dec 2 04:10:21 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.b6fb54414ab16ad483780562331ca5ae@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: Resolution: | Keywords: 64bit Difficulty: Unknown | Os: MacOS X Testcase: | Architecture: x86_64 (amd64) Failure: None/Unknown | ------------------------------+--------------------------------------------- Changes (by mxc): * cc: mxcantor@gmail.com (added) * failure: => None/Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 2 05:08:47 2009 From: trac at galois.com (GHC) Date: Wed Dec 2 04:43:31 2009 Subject: [GHC] #3707: deriving Data, Typeable for empty data decls In-Reply-To: <046.c30e37289f0c475ce8f5491c63ad50b1@localhost> References: <046.c30e37289f0c475ce8f5491c63ad50b1@localhost> Message-ID: <055.81ea96f11be42201593329920157b4cc@localhost> #3707: deriving Data, Typeable for empty data decls ------------------------------+--------------------------------------------- Reporter: seanmcl | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: invalid | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ------------------------------+--------------------------------------------- Changes (by simonpj): * status: new => closed * difficulty: => * resolution: => invalid Old description: > Empty data decls are useful for things like phantom types. However, > deriving (Data, Typeable) does not work with them, so if you want to use > them with generics you must do something like the following: > > data PredTag > > instance Typeable PredTag where > typeOf _ = G.mkTyConApp (G.mkTyCon "PredTag") [] > > Surely GHC could derive this for us! New description: Empty data decls are useful for things like phantom types. However, deriving (Data, Typeable) does not work with them, so if you want to use them with generics you must do something like the following: {{{ data PredTag instance Typeable PredTag where typeOf _ = G.mkTyConApp (G.mkTyCon "PredTag") [] }}} Surely GHC could derive this for us! Comment: When you say it "does not work" can you supply a test case? I tried this: {{{ {-# LANGUAGE EmptyDataDecls, DeriveDataTypeable #-} module T3707 where import Data.Typeable data PredType deriving( Typeable ) }}} That works fine in GHC 6.10 and the HEAD. You do get a complaint if you derive 'Data' for such a type, but I'm not sure that makes sense. I'll close this ticket, but please re-open if I have missed something. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 2 05:30:23 2009 From: trac at galois.com (GHC) Date: Wed Dec 2 05:05:07 2009 Subject: [GHC] #3711: Bad error reporting when calling a function in a module which depends on a DLL on Windows Message-ID: <044.70cf7493cde2b6d5c034e6655b6cb8a7@localhost> #3711: Bad error reporting when calling a function in a module which depends on a DLL on Windows ---------------------------------+------------------------------------------ Reporter: fasta | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.10.4 | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ When you try to call a function which depends on a DLL, after the module has been loaded in ghci, you get: Loading package Codec-Image-DevIL-0.1 ... can't load .so/.DLL for: ILU (addDLL: could not load DLL) This error message is almost completely useless. It should call GetLastError() and present this information to the user. I don't know whether the error message for GetLastError is actually useful, but otherwise it should derive a real problem with the library, e.g. "we searched for it in the PATH, but we couldn't find it, or the library format is wrong(use Dependency walker to verify that this is a valid Windows DLL), etc.". In general every error message should state what it tried and why it failed. In the same sense that type-error messages do (assuming no bugs in the type-inferencer ;) ). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 2 05:50:25 2009 From: trac at galois.com (GHC) Date: Wed Dec 2 05:25:08 2009 Subject: [GHC] #3711: Bad error reporting when calling a function in a module which depends on a DLL on Windows In-Reply-To: <044.70cf7493cde2b6d5c034e6655b6cb8a7@localhost> References: <044.70cf7493cde2b6d5c034e6655b6cb8a7@localhost> Message-ID: <053.8510b7f8c1c2142d958bfe8a63eb2b6a@localhost> #3711: Bad error reporting when calling a function in a module which depends on a DLL on Windows ---------------------------+------------------------------------------------ Reporter: fasta | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by simonmar): * difficulty: => Comment: submitter reported that there was an additional error message {{{ Loading package Codec-Image-DevIL-0.1 ... : ILU: %1 is not a valid Win32 application. }}} and indeed the problem was that the DLL was compiled for 64-bit Windows. The error reporting here could still be a lot better (e.g. fixing the `%1` for a start), so leaving the bug open. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 2 06:20:48 2009 From: trac at galois.com (GHC) Date: Wed Dec 2 05:55:32 2009 Subject: [GHC] #3712: Implement -dynamic-lib option Message-ID: <047.0ba626c454f1d59815233fb1be60c8e4@localhost> #3712: Implement -dynamic-lib option ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler | Version: 6.12.1 RC1 Keywords: | Difficulty: Easy (less than 1 hour) Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ The proposal is to add a new option `-dynamic-lib`, to be used when building a shared library. It would be both a compile-time and a link- time option, and could be used with `--make` to build a complete shared library in one go. It would avoid the pitfalls caused by there being combinations of `-dynamic` and `-fPIC` don't do what the user expects. Specifically, `-dynanmic-lib` would imply `-dyanamic`, `-fPIC` where necessary, and `-shared` when linking. See #3705 for more discussion. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 2 06:25:19 2009 From: trac at galois.com (GHC) Date: Wed Dec 2 06:00:03 2009 Subject: [GHC] #3713: Track -dynamic/-fPIC to avoid obscure linker errors Message-ID: <047.d92ae3d0696eeed98ccca2fecc965354@localhost> #3713: Track -dynamic/-fPIC to avoid obscure linker errors ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler | Version: 6.10.4 Keywords: | Difficulty: Moderate (less than a day) Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Using the wrong combination of `-dynamic` and/or `-fPIC` can lead to obscure linker errors, see e.g. #3705. We should track whether an object file was compiled with `-dynamic` and `-fPIC` so that we can give better error messages before running the linker. '''See also''' [[TicketQuery(id=3712|)]] -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 2 06:26:39 2009 From: trac at galois.com (GHC) Date: Wed Dec 2 06:01:24 2009 Subject: [GHC] #3705: -fPIC without -dynamic silently ignored In-Reply-To: <048.79f60db856b7d267ec487bb7bef2f0d4@localhost> References: <048.79f60db856b7d267ec487bb7bef2f0d4@localhost> Message-ID: <057.c6fb3fd09df6afaff5c76587dc7ecfe2@localhost> #3705: -fPIC without -dynamic silently ignored ---------------------------+------------------------------------------------ Reporter: asuffield | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: Resolution: wontfix | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86_64 (amd64) Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => wontfix Comment: Two new tickets created to replace this one: [[TicketQuery(id=3712|)]] [[TicketQuery(id=3713|)]] -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 2 08:44:48 2009 From: trac at galois.com (GHC) Date: Wed Dec 2 08:19:32 2009 Subject: [GHC] #3713: Track -dynamic/-fPIC to avoid obscure linker errors In-Reply-To: <047.d92ae3d0696eeed98ccca2fecc965354@localhost> References: <047.d92ae3d0696eeed98ccca2fecc965354@localhost> Message-ID: <056.1c9c6226a32d66afe22dfcccd3745817@localhost> #3713: Track -dynamic/-fPIC to avoid obscure linker errors -----------------------------------------+---------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: Moderate (less than a day) | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | -----------------------------------------+---------------------------------- Comment (by duncan): Doing this on a per-object file basis will require adding extra custom sections to the object files. This is something we want to do anyway so that we can add other info such as: * .hi file content * stack trace debug info The ability to insert and read custom sections will have to be implemented separately on each of ELF, Mach-O and PE. It should be possible to have a consistent interface on each platform however. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 2 09:01:35 2009 From: trac at galois.com (GHC) Date: Wed Dec 2 08:36:17 2009 Subject: [GHC] #3701: allow existential wrapper newtypes In-Reply-To: <045.840f456f2d890bcf682319446631153e@localhost> References: <045.840f456f2d890bcf682319446631153e@localhost> Message-ID: <054.2840cb867ff6e337dc598cf45c958555@localhost> #3701: allow existential wrapper newtypes ------------------------------+--------------------------------------------- Reporter: duncan | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ------------------------------+--------------------------------------------- Comment (by simonpj): Yes, something like this would be good. Here's a very relevant paper that Kim Bruce wrote for ECOOP'97: http://www.ifs.uni- linz.ac.at/~ecoop/cd/papers/1241/12410104.pdf. Just as you propose a type and a class with the same name, so does he, but he calls them T and #T. But it's not that easy to just "derive the instance". In your case: {{{ data MkCompiler where MkCompiler :: Compiler c => c -> MkCompiler instance Compiler MkCompiler where getInstalledPackages (MkCompiler c) = getInstalledPackages c }}} Notice that this instance of `getInstalledPackages` is necessarily strict. And I think it ''requires'' a OO-style type for `getInstalledPackages`: that is, the first argument has type 'c'. So classes that are amenable are of form {{{ class C a b c where op1 :: c -> op2 :: c -> etc }}} For classes of that form, we could regard `(C t1 t2)` as a data type, with a single existential constructor, declared (implicitly) thus {{{ data C a b where C :: forall a b c. C a b c => c -> C a b instance C (C a b) where op1 (C x) = op1 x op2 (C x) = op2 x }}} It's a little uncomfortable that this stuff only works when the class has the right shaped signature. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 2 09:43:00 2009 From: trac at galois.com (GHC) Date: Wed Dec 2 09:17:48 2009 Subject: [GHC] #3714: Associated types missing useful functionality Message-ID: <046.1269d7611bd6a1dfa394e0799eb1571c@localhost> #3714: Associated types missing useful functionality ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: chak Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Martijn van Steenbergen pointed out this program: {{{ {-# LANGUAGE TypeFamilies #-} module M where -- Accepted type family T1 f e :: * class C1 f where op1 :: T1 f e -> Either e a -- Rejected class C2 f where type T2 f e :: * op2 :: T2 f e -> Either e a }}} At the moment (HEAD) the C1/T1 version is accepted but the C2/T2 declarations are rejected: {{{ TF.hs:12:3: Not in scope: type variable `e' }}} I think this is just a bug. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 2 10:15:31 2009 From: trac at galois.com (GHC) Date: Wed Dec 2 09:50:14 2009 Subject: [GHC] #3699: Wildcards in type functions In-Reply-To: <060.b01af1dc1c462193a392550aa45e1d6c@localhost> References: <060.b01af1dc1c462193a392550aa45e1d6c@localhost> Message-ID: <069.f8521014d3188141959508212acf01ee@localhost> #3699: Wildcards in type functions ------------------------------------+--------------------------------------- Reporter: MartijnVanSteenbergen | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.14 branch Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ------------------------------------+--------------------------------------- Changes (by simonpj): * difficulty: => * milestone: => 6.14 branch Comment: Very reasonable idea. I've added it to our list of type-function feature requests at http://hackage.haskell.org/trac/ghc/wiki/TypeFunctionsStatus Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 2 10:56:38 2009 From: trac at galois.com (GHC) Date: Wed Dec 2 10:31:30 2009 Subject: [GHC] #3709: Data.Either.partitionEithers is not lazy enough In-Reply-To: <056.ddd6dbef542c6ca3bde6bd36bb5cb4f0@localhost> References: <056.ddd6dbef542c6ca3bde6bd36bb5cb4f0@localhost> Message-ID: <065.b13add13be386db792cfdd3e2a478791@localhost> #3709: Data.Either.partitionEithers is not lazy enough --------------------------------------+------------------------------------- Reporter: daniel.is.fischer | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 6.10.4 Resolution: fixed | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Runtime performance bug | --------------------------------------+------------------------------------- Comment (by igloo): This is a behavioural change, e.g.: {{{ Main> case partitionEithers1 [Left 'a', error "Not me"] of (x : _, _) -> x Program error: Not me Main> case partitionEithers2 [Left 'a', error "Not me"] of (x : _, _) -> x 'a' }}} Shouldn't it be discussed on the libraries list first? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 2 11:09:18 2009 From: trac at galois.com (GHC) Date: Wed Dec 2 10:44:02 2009 Subject: [GHC] #3715: GHC API no longer exports location information for error/warning messages Message-ID: <046.4e83f78284330dedbf9948985e29216e@localhost> #3715: GHC API no longer exports location information for error/warning messages ---------------------------------+------------------------------------------ Reporter: greenrd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 6.12.1 RC1 Keywords: | Difficulty: Easy (less than 1 hour) Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Other ---------------------------------+------------------------------------------ scion uses the location information in error/warning Messages for background typechecking (for some reason). It can now (with the 6.12.1 RC2 API) no longer do anything to a Message other than show it, so it would have to re-parse the output of "show" to extract the location information. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 2 11:14:08 2009 From: trac at galois.com (GHC) Date: Wed Dec 2 10:48:51 2009 Subject: [GHC] #3715: GHC API no longer exports location information for error/warning messages In-Reply-To: <046.4e83f78284330dedbf9948985e29216e@localhost> References: <046.4e83f78284330dedbf9948985e29216e@localhost> Message-ID: <055.809a2f6a7389384a21ec4f4c48d233d0@localhost> #3715: GHC API no longer exports location information for error/warning messages --------------------------------------+------------------------------------- Reporter: greenrd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: Easy (less than 1 hour) | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Other | --------------------------------------+------------------------------------- Comment (by greenrd): In addition, it can no longer show the message in "unqualified" style, because "show" ignores the errMsgContext. So maybe all the fields of ErrMsg should be exported, to get us back to where we were in 6.10? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 2 12:00:22 2009 From: trac at galois.com (GHC) Date: Wed Dec 2 11:35:05 2009 Subject: [GHC] #2401: unsafeIOToSTM discards exception handlers. In-Reply-To: <043.102536ca2a3e567cb6677ad0a9004c1b@localhost> References: <043.102536ca2a3e567cb6677ad0a9004c1b@localhost> Message-ID: <052.ba75541a4578e059c1370ec2b08482fb@localhost> #2401: unsafeIOToSTM discards exception handlers. -----------------------------+---------------------------------------------- Reporter: sclv | Owner: Type: bug | Status: reopened Priority: normal | Milestone: 6.10.1 Component: Runtime System | Version: 6.8.3 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | -----------------------------+---------------------------------------------- Changes (by sclv): * status: closed => reopened * failure: => None/Unknown * resolution: wontfix => Comment: As per this discussion (http://www.haskell.org/pipermail/glasgow-haskell- users/2008-September/015412.html) I believe this ticket should have been reopened. Getting it right is, however, contingent on this ticket as well: http://hackage.haskell.org/trac/ghc/ticket/2558 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 2 12:06:35 2009 From: trac at galois.com (GHC) Date: Wed Dec 2 11:41:22 2009 Subject: [GHC] #3715: GHC API no longer exports location information for error/warning messages In-Reply-To: <046.4e83f78284330dedbf9948985e29216e@localhost> References: <046.4e83f78284330dedbf9948985e29216e@localhost> Message-ID: <055.40bcf788251686814b23557350219087@localhost> #3715: GHC API no longer exports location information for error/warning messages --------------------------------------+------------------------------------- Reporter: greenrd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: Easy (less than 1 hour) | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Other | --------------------------------------+------------------------------------- Comment (by simonpj): Can you be 100% concrete? * What ''exactly'' is the API change that you've encountered? (E.g. there used to be a function `getMsgLoc :: Message -> SrcLoc` but it disappered in 6.12. Or whatever.) * What exactly is the change (or reversion) that would help you? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 2 13:15:36 2009 From: trac at galois.com (GHC) Date: Wed Dec 2 12:50:27 2009 Subject: [GHC] #3716: building ghc-6.12.0.20091121 ends with internal Haddock or GHC error Message-ID: <045.e5c85a6d9c01c90f88c47b3f6ae70039@localhost> #3716: building ghc-6.12.0.20091121 ends with internal Haddock or GHC error ---------------------------+------------------------------------------------ Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.12.1 RC1 | Keywords: Os: Solaris | Testcase: Architecture: x86 | Failure: Building GHC failed ---------------------------+------------------------------------------------ After overcoming #3683 my build ends with: {{{ cd libraries && sh gen_contents_index --inplace haddock: internal Haddock or GHC error: array-version:: openBinaryFile: does not exist (No such file or directory) gmake[1]: *** [libraries/index.html] Fehler 1 gmake: *** [all] Fehler 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 2 13:23:06 2009 From: trac at galois.com (GHC) Date: Wed Dec 2 12:57:53 2009 Subject: [GHC] #650: Improve interaction between mutable arrays and GC In-Reply-To: <047.44b951cd4b5aa8536d862412c8d86597@localhost> References: <047.44b951cd4b5aa8536d862412c8d86597@localhost> Message-ID: <056.20c645ab856752760c0a96cc71ae2e69@localhost> #650: Improve interaction between mutable arrays and GC -----------------------------------------+---------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Runtime System | Version: 6.4.1 Resolution: | Keywords: Difficulty: Moderate (less than a day) | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Runtime performance bug | -----------------------------------------+---------------------------------- Changes (by sclv): * cc: sclv (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 2 13:29:49 2009 From: trac at galois.com (GHC) Date: Wed Dec 2 13:04:34 2009 Subject: [GHC] #2558: re-throwing an asynchronous exception throws it synchronously In-Reply-To: <047.339350d6751eeb20e19b24c52175ed9b@localhost> References: <047.339350d6751eeb20e19b24c52175ed9b@localhost> Message-ID: <056.8f60f0dbd6bd0ddb831ef9cfa6a08e3c@localhost> #2558: re-throwing an asynchronous exception throws it synchronously ---------------------------+------------------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler | Version: 6.8.3 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by sclv): * cc: sclv (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 2 14:07:19 2009 From: trac at galois.com (GHC) Date: Wed Dec 2 13:42:09 2009 Subject: [GHC] #3715: GHC API no longer exports location information for error/warning messages In-Reply-To: <046.4e83f78284330dedbf9948985e29216e@localhost> References: <046.4e83f78284330dedbf9948985e29216e@localhost> Message-ID: <055.55ee7b93faec3a1c0a4a11a86babc338@localhost> #3715: GHC API no longer exports location information for error/warning messages --------------------------------------+------------------------------------- Reporter: greenrd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: Easy (less than 1 hour) | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Other | --------------------------------------+------------------------------------- Comment (by greenrd): Replying to [comment:2 simonpj]: > Can you be 100% concrete? Yes, sorry. > * What ''exactly'' is the API change that you've encountered? The fields `errMsgSpans`, `errMsgShortDoc`, and `errMsgContext` of the `ErrMsg` record in `compiler/main/ErrUtils.lhs`, used to be exported; now they are not. They are still there (in RC2), just not exported. The first one was used by scion for determining the location associated with a message; the other two were used to display it nicely (see [comment:1 comment 1]). > * What exactly is the change (or reversion) that would help you? Exporting those fields from `ErrUtils.lhs` again. I could not find any other way of getting hold of the same information. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 2 14:15:59 2009 From: trac at galois.com (GHC) Date: Wed Dec 2 13:50:47 2009 Subject: [GHC] #3715: GHC API no longer exports location information for error/warning messages In-Reply-To: <046.4e83f78284330dedbf9948985e29216e@localhost> References: <046.4e83f78284330dedbf9948985e29216e@localhost> Message-ID: <055.9913491f62412c005b259e1371e3c894@localhost> #3715: GHC API no longer exports location information for error/warning messages --------------------------------------+------------------------------------- Reporter: greenrd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: Easy (less than 1 hour) | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Other | --------------------------------------+------------------------------------- Comment (by igloo): These exports were removed by: {{{ Thu Jul 23 14:01:08 BST 2009 simonpj@microsoft.com * Use the ErrMsg record type }}} Simon, was that deliberate? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 2 15:05:23 2009 From: trac at galois.com (GHC) Date: Wed Dec 2 14:40:06 2009 Subject: [GHC] #3715: GHC API no longer exports location information for error/warning messages In-Reply-To: <046.4e83f78284330dedbf9948985e29216e@localhost> References: <046.4e83f78284330dedbf9948985e29216e@localhost> Message-ID: <055.b05f83f00a5618787d10e2f847b50d73@localhost> #3715: GHC API no longer exports location information for error/warning messages --------------------------------------+------------------------------------- Reporter: greenrd | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: Easy (less than 1 hour) | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Other | --------------------------------------+------------------------------------- Changes (by simonpj): * owner: => igloo Comment: Crumbs, its my fault then?! Ah, hmm. I think I must have noted that these functions were unused in GHC itself, and removed them. Ian: can you please re-add the exports I removed? I think we can slip this into 6.12.1. It's clearly a glitch. We should think about how to avoid this in future. That is, a way to answer the question "does this function form part of the advertised GHC API?". Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 2 15:06:25 2009 From: trac at galois.com (GHC) Date: Wed Dec 2 14:41:14 2009 Subject: [GHC] #3715: GHC API no longer exports location information for error/warning messages In-Reply-To: <046.4e83f78284330dedbf9948985e29216e@localhost> References: <046.4e83f78284330dedbf9948985e29216e@localhost> Message-ID: <055.6c44d008a550c4a1e82bf76646ea426a@localhost> #3715: GHC API no longer exports location information for error/warning messages --------------------------------------+------------------------------------- Reporter: greenrd | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: Easy (less than 1 hour) | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Other | --------------------------------------+------------------------------------- Comment (by simonpj): PS thank you for reporting this. Much better to catch this stuff before the release. And apologies for the glitch. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 2 17:46:20 2009 From: trac at galois.com (GHC) Date: Wed Dec 2 17:21:47 2009 Subject: [GHC] #3658: Dynamically link GHCi on platforms that support it In-Reply-To: <047.129d39e2608fc274aa7ba90c094c6a82@localhost> References: <047.129d39e2608fc274aa7ba90c094c6a82@localhost> Message-ID: <056.c80d2dd334dd63bfb8e79e068ce728aa@localhost> #3658: Dynamically link GHCi on platforms that support it ---------------------------+------------------------------------------------ Reporter: simonmar | Owner: Type: task | Status: new Priority: high | Milestone: 6.14.1 Component: GHCi | Version: 6.10.4 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by morrow): * cc: morrow@moonpatio.com (added) * failure: => None/Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 2 17:47:05 2009 From: trac at galois.com (GHC) Date: Wed Dec 2 17:22:21 2009 Subject: [GHC] #3672: Let Linker.c know about stg_arg_bitmaps In-Reply-To: <044.9478d419ceaff4352f148c46bb1abb99@localhost> References: <044.9478d419ceaff4352f148c46bb1abb99@localhost> Message-ID: <053.8955e634182b9465e1ff98e31a62990e@localhost> #3672: Let Linker.c know about stg_arg_bitmaps ------------------------------+--------------------------------------------- Reporter: int-e | Owner: Type: feature request | Status: new Priority: high | Milestone: 6.14.1 Component: Runtime System | Version: 6.13 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ------------------------------+--------------------------------------------- Changes (by morrow): * cc: morrow@moonpatio.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 2 17:48:28 2009 From: trac at galois.com (GHC) Date: Wed Dec 2 17:23:11 2009 Subject: [GHC] #3699: Wildcards in type functions In-Reply-To: <060.b01af1dc1c462193a392550aa45e1d6c@localhost> References: <060.b01af1dc1c462193a392550aa45e1d6c@localhost> Message-ID: <069.c7092eddcf744d4926bce8bff77c26e1@localhost> #3699: Wildcards in type functions ------------------------------------+--------------------------------------- Reporter: MartijnVanSteenbergen | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.14 branch Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ------------------------------------+--------------------------------------- Comment (by MartijnVanSteenbergen): Continuing this line of thought, instances for this family go hand in hand with instances for this type class: {{{ class MkErrorAlgebra f where mkErrorAlgebra :: ErrorAlg f e a -> ErrorAlgPF f e a }}} Would it then also make sense to write: {{{ instance MkErrorAlgebra f => MkErrorAlgebra (f :>: _) where mkErrorAlgebra alg (Tag f) = mkErrorAlgebra alg f }}} ? Just a wild idea which I'm not sure yet I like or dislike. It does fit in with the idea of not making up names if you don't have to. For that reason I also prefer writing {{{data D :: where}}} for GADTs rather than making up arbitrary names for the type arguments. Going even further, this idea can be extended to e.g. {{{data Const a _ = Const a}}} for normal ADTs. Okay, enough wild ideas for now. :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 2 17:55:53 2009 From: trac at galois.com (GHC) Date: Wed Dec 2 17:31:44 2009 Subject: [GHC] #3654: Mach-O GHCi linker lacks support for a range of relocation entries In-Reply-To: <043.db5a4c9ebf484eb57b87a6d38bef8362@localhost> References: <043.db5a4c9ebf484eb57b87a6d38bef8362@localhost> Message-ID: <052.a1d7814c35ee769714c803d9e446267b@localhost> #3654: Mach-O GHCi linker lacks support for a range of relocation entries -----------------------------+---------------------------------------------- Reporter: chak | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Runtime System | Version: 6.13 Resolution: | Keywords: Difficulty: Unknown | Os: MacOS X Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | -----------------------------+---------------------------------------------- Changes (by morrow): * cc: morrow@moonpatio.com (added) * failure: => None/Unknown Comment: What are the things that would need changing or doing to move ghci to exclusively use the system dynamic linker? What are the really problematic things (given the current implementation) that would need sorting out with respect to this? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 2 18:00:43 2009 From: trac at galois.com (GHC) Date: Wed Dec 2 17:36:54 2009 Subject: [GHC] #3654: Mach-O GHCi linker lacks support for a range of relocation entries In-Reply-To: <043.db5a4c9ebf484eb57b87a6d38bef8362@localhost> References: <043.db5a4c9ebf484eb57b87a6d38bef8362@localhost> Message-ID: <052.d92a5eaa0c99ba9edd664ec97571c6c6@localhost> #3654: Mach-O GHCi linker lacks support for a range of relocation entries -----------------------------+---------------------------------------------- Reporter: chak | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Runtime System | Version: 6.13 Resolution: | Keywords: Difficulty: Unknown | Os: MacOS X Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | -----------------------------+---------------------------------------------- Comment (by morrow): To clarify, I mean s/Linker.c/dlfcn.h/, in addition to [http://hackage.haskell.org/trac/ghc/ticket/3658 3658] -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 2 19:05:34 2009 From: trac at galois.com (GHC) Date: Wed Dec 2 18:40:18 2009 Subject: [GHC] #3717: Superfluous seq no eliminated Message-ID: <041.b3c6d5cd79733a6a42f08376dcf76349@localhost> #3717: Superfluous seq no eliminated ---------------------------------+------------------------------------------ Reporter: rl | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.13 | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Runtime performance bug ---------------------------------+------------------------------------------ Program: {{{ foo :: Int -> Int foo 0 = 0 foo n = (if n < 5 then 1 else 2) `seq` foo (n-1) }}} GHC generates this code: {{{ T.$wfoo = \ (ww_slm :: GHC.Prim.Int#) -> case ww_slm of ds_XkE { __DEFAULT -> case case GHC.Prim.<# ds_XkE 5 of _ { GHC.Bool.False -> lvl1_rlG; GHC.Bool.True -> lvl_rlE } of _ { __DEFAULT -> T.$wfoo (GHC.Prim.-# ds_XkE 1) }; 0 -> 0 } }}} Note that the seq is still there although it is a nop. This actually occurs in stream fusion code. -- Ticket URL: GHC The Glasgow Haskell Compiler From malcolm.wallace at cs.york.ac.uk Wed Dec 2 20:50:29 2009 From: malcolm.wallace at cs.york.ac.uk (Malcolm Wallace) Date: Wed Dec 2 20:25:24 2009 Subject: [GHC] #3709: Data.Either.partitionEithers is not lazy enough In-Reply-To: <065.b13add13be386db792cfdd3e2a478791@localhost> References: <056.ddd6dbef542c6ca3bde6bd36bb5cb4f0@localhost> <065.b13add13be386db792cfdd3e2a478791@localhost> Message-ID: <948C28A4-E060-46D1-BDB7-9C24D19D927E@cs.york.ac.uk> > #3709: Data.Either.partitionEithers is not lazy enough > > This is a behavioural change, e.g.: > Main> case partitionEithers1 [Left 'a', error "Not me"] of (x : _, > _) -> x > Program error: Not me > Main> case partitionEithers2 [Left 'a', error "Not me"] of (x : _, > _) -> x > 'a' Yes, and isn't that the point of the bugfix? No non-bottoming program has changed, but fewer programs fail now. I find it hard to imagine that anyone could have been relying on getting a crash here. > Shouldn't it be discussed on the libraries list first? Possibly, although I believe we have never treated a change towards being more lazy as an API change before. Making something more strict usually provokes discussion, because it causes more programs to crash, but making things lazier is usually considered a bugfix. Copying to libraries@, to see if there are any objections. If there are, feel free to back out the patch. -> See http://hackage.haskell.org/trac/ghc/ticket/3709 Regards, Malcolm From trac at galois.com Thu Dec 3 00:15:51 2009 From: trac at galois.com (GHC) Date: Wed Dec 2 23:50:31 2009 Subject: [GHC] #3718: Can not bootstrap using 6.12.1-rc2 Message-ID: <044.e3fbd58d8bc98f8a8a505dad8aa3453a@localhost> #3718: Can not bootstrap using 6.12.1-rc2 ---------------------------------+------------------------------------------ Reporter: masao | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.12.1 RC1 | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Building GHC failed ---------------------------------+------------------------------------------ Hi, Can not bootstrap using 6.12.1-rc2. I tested bootstrap 6.12.1-rc2 on i386. I read the following and tested bootstrap. http://hackage.haskell.org/trac/ghc/wiki/Building/Porting At first I tested boot strap to the i386 from i386. # I think it not to have any problem even from the same architecture, because it is the test of bootstrap. I became the following errors when I execute "$ ./configure --target=plat ". # mean HOST. {{{ ghc-6.12.0.20091121$ ./configure --target=i386-unknown-linux checking for gfind... no checking for find... /usr/bin/find checking for sort... /usr/bin/sort checking for GHC version date... given 6.12.0.20091121 checking for ghc... no configure: error: GHC is required unless bootstrapping from .hc files. }}} Could you have any comment? # I am using Debian GNU/Linux sid. {{{ $ uname -a Linux test 2.6.30-2-686-bigmem #1 SMP Sat Sep 26 02:30:18 UTC 2009 i686 GNU/Linux $ gcc -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.4-6' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable- languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program- suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-targets=all --with-tune=generic --enable- checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.3.4 (Debian 4.3.4-6) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 3 06:49:38 2009 From: trac at galois.com (GHC) Date: Thu Dec 3 06:24:18 2009 Subject: [GHC] #3719: Literate code with # Message-ID: <046.119383e131eabeee5d5ffb7da02e279e@localhost> #3719: Literate code with # ---------------------------------+------------------------------------------ Reporter: zenzike | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Parser) Version: 6.10.4 | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: GHC rejects valid program ---------------------------------+------------------------------------------ Any literate script where the hash symbol # is in the first column of a file does not compile in ghc. For example, {{{ > foo = 1 + 2 # }}} will give rise to the following error: {{{ lexical error at character '\n' }}} This is rather annoying, since # is used in markup languages as a heading delimiter. The example compiles fine using hugs. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 3 07:30:26 2009 From: trac at galois.com (GHC) Date: Thu Dec 3 07:05:07 2009 Subject: [GHC] #3719: Literate code with # In-Reply-To: <046.119383e131eabeee5d5ffb7da02e279e@localhost> References: <046.119383e131eabeee5d5ffb7da02e279e@localhost> Message-ID: <055.8a43d6b744f990b9be3a29ff67ea7c7c@localhost> #3719: Literate code with # ----------------------------------------+----------------------------------- Reporter: zenzike | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: GHC rejects valid program | ----------------------------------------+----------------------------------- Changes (by duncan): * difficulty: => Comment: Note that the `#` makes it though the unlit into the .hspp code. Then of course it's not valid Haskell. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 3 08:04:50 2009 From: trac at galois.com (GHC) Date: Thu Dec 3 07:39:30 2009 Subject: [GHC] #2401: aborting an STM transaction should throw an exception In-Reply-To: <043.102536ca2a3e567cb6677ad0a9004c1b@localhost> References: <043.102536ca2a3e567cb6677ad0a9004c1b@localhost> Message-ID: <052.58cb9bfb16f41099b5dd561f8a0dd81b@localhost> #2401: aborting an STM transaction should throw an exception ------------------------------------------+--------------------------------- Reporter: sclv | Owner: Type: bug | Status: reopened Priority: normal | Milestone: 6.14.1 Component: Runtime System | Version: 6.8.3 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Incorrect result at runtime | ------------------------------------------+--------------------------------- Changes (by simonmar): * failure: None/Unknown => Incorrect result at runtime * summary: unsafeIOToSTM discards exception handlers. => aborting an STM transaction should throw an exception * milestone: 6.10.1 => 6.14.1 Comment: (changing the bug title to reflect the underlying problem) Summary: * the STM transaction might be in the middle of an `unsafePerformIO` when it is aborted. The user has no control over this, since transactions can be aborted by the RTS, and the use of `unsafePerformIO` might be in a library somewhere. * The IO in the library expects to be able to catch exceptions and clean up if it is interrupted, otherwise it might leave locks in place. Imagine pulling on some lazy I/O during an STM transaction, for example. As @sclv pointed out, we also need to fix [[TicketQuery(id=2558|)]] otherwise when the IO operation re-throws the abort exception, it will throw it synchronously. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 3 08:12:06 2009 From: trac at galois.com (GHC) Date: Thu Dec 3 07:46:50 2009 Subject: [GHC] #3715: GHC API no longer exports location information for error/warning messages In-Reply-To: <046.4e83f78284330dedbf9948985e29216e@localhost> References: <046.4e83f78284330dedbf9948985e29216e@localhost> Message-ID: <055.c5144f0a0f2b3e67d26ad55403695e63@localhost> #3715: GHC API no longer exports location information for error/warning messages --------------------------------------+------------------------------------- Reporter: greenrd | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: Easy (less than 1 hour) | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Other | --------------------------------------+------------------------------------- Comment (by simonmar): Replying to [comment:5 simonpj]: > We should think about how to avoid this in future. That is, a way to answer the question "does this function form part of the advertised GHC API?". If this stuff is used by a client, then we should export it from GHC. Roughly speaking, we should look at clients from time to time to see what they're using that isn't exported from GHC, and decide whether (a) we want to put it there, or (b) we want to expose something else nicer. Eventually the GHC module will be useful enough on its own that we can start hiding the other modules in the GHC package. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 3 09:46:02 2009 From: trac at galois.com (GHC) Date: Thu Dec 3 09:20:46 2009 Subject: [GHC] #2797: ghci stack overflows when ghc does not In-Reply-To: <053.b5bed6c883dfb7d157e5092dcf2242ee@localhost> References: <053.b5bed6c883dfb7d157e5092dcf2242ee@localhost> Message-ID: <062.2b7e783a30ee2ea71f7a90322054d324@localhost> #2797: ghci stack overflows when ghc does not --------------------------------------+------------------------------------- Reporter: TristanAllwood | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: GHCi | Version: 6.11 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Runtime performance bug | --------------------------------------+------------------------------------- Changes (by fasta): * cc: fasta (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 3 09:46:57 2009 From: trac at galois.com (GHC) Date: Thu Dec 3 09:21:36 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.338830c298a889f70abe9bb46736d7c8@localhost> #3100: GHC Panic "reifyType PredTy" in HAppS.Data.IxSet.inferIxSet ---------------------------+------------------------------------------------ Reporter: mightybyte | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: th/T3100 | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by simonpj): * testcase: => th/T3100 * owner: => igloo * type: bug => merge Comment: Fixed I think {{{ Mon Nov 30 09:52:04 PST 2009 simonpj@microsoft.com * Fix Trac #3100: reifyType A type without any leading foralls may still have constraints eg: ?x::Int => Int -> Int But reifyType was failing in this case. Merge to 6.12. M ./compiler/typecheck/TcSplice.lhs -7 +12 }}} Ian please merge -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 3 09:48:56 2009 From: trac at galois.com (GHC) Date: Thu Dec 3 09:23:36 2009 Subject: [GHC] #3102: The impossible happened with implicit parameters In-Reply-To: <053.ebde85ce07c798d9c38e07173af669f0@localhost> References: <053.ebde85ce07c798d9c38e07173af669f0@localhost> Message-ID: <062.bc4382a37e3c9c513e68577c89de6a91@localhost> #3102: The impossible happened with implicit parameters ------------------------------------------+--------------------------------- Reporter: Ashley Yakeley | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler (Type checker) | Version: 6.10.1 Resolution: | Keywords: Difficulty: Unknown | Os: Linux Testcase: tyepcheck/should_fail/T3102 | Architecture: Unknown/Multiple Failure: None/Unknown | ------------------------------------------+--------------------------------- Changes (by simonpj): * testcase: => tyepcheck/should_fail/T3102 * status: reopened => new * type: bug => merge * owner: chak => igloo Comment: You're right. There was another bug lurking. {{{ Mon Nov 30 09:44:41 PST 2009 simonpj@microsoft.com * Fix Trac #3102: pre-matching polytypes When *pre-matching* two types forall a. C1 => t1 ~ forall a. C2 => t2 we were matching t1~t2, but totally ignoring C1,C2 That's utterly wrong when pre-matching (?p::Int) => String ~ a because we emerge with a:=String! All this is part of the impredicative story, which is about to go away, but still. Worth merging this to 6.12 M ./compiler/typecheck/TcUnify.lhs -2 +3 }}} Merge if possible to 6.12. Thanks for being persistent. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 3 10:33:38 2009 From: trac at galois.com (GHC) Date: Thu Dec 3 10:08:40 2009 Subject: [GHC] #3654: Mach-O GHCi linker lacks support for a range of relocation entries In-Reply-To: <043.db5a4c9ebf484eb57b87a6d38bef8362@localhost> References: <043.db5a4c9ebf484eb57b87a6d38bef8362@localhost> Message-ID: <052.0388425913a3a01b67bdc8d8e70adafb@localhost> #3654: Mach-O GHCi linker lacks support for a range of relocation entries -----------------------------+---------------------------------------------- Reporter: chak | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Runtime System | Version: 6.13 Resolution: | Keywords: Difficulty: Unknown | Os: MacOS X Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | -----------------------------+---------------------------------------------- Comment (by simonmar): Replying to [comment:6 morrow]: > What are the things that would need changing or doing to move ghci to exclusively use the system dynamic linker? What are the really problematic things (given the current implementation) that would need sorting out with respect to this? See [http://www.haskell.org/pipermail/cvs-ghc/2009-November/051196.html] and Manuel's reply. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 3 10:37:16 2009 From: trac at galois.com (GHC) Date: Thu Dec 3 10:12:03 2009 Subject: [GHC] #3718: Can not bootstrap using 6.12.1-rc2 In-Reply-To: <044.e3fbd58d8bc98f8a8a505dad8aa3453a@localhost> References: <044.e3fbd58d8bc98f8a8a505dad8aa3453a@localhost> Message-ID: <053.0aa14e3ffbfd98a617d7ed8616778e51@localhost> #3718: Can not bootstrap using 6.12.1-rc2 ---------------------------------+------------------------------------------ Reporter: masao | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.12.1 RC1 Resolution: | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Building GHC failed ---------------------------------+------------------------------------------ Comment (by maeder): You need a working ghc to build a new ghc from sources. You may try to install http://www.haskell.org/ghc/dist/6.12.1-rc2/ghc-6.12.0.20091121-i386 -unknown-linux-n.tar.bz2 first (or an older ghc version). With this ghc (or an older ghc) you should be able compile the sources http://www.haskell.org/ghc/dist/6.12.1-rc2/ghc-6.12.0.20091121-src.tar.bz2 No porting should be necessary for your platform (and .hc are not available). -- Ticket URL: GHC The Glasgow Haskell Compiler From marlowsd at gmail.com Thu Dec 3 10:37:11 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Dec 3 10:12:09 2009 Subject: [GHC] #3709: Data.Either.partitionEithers is not lazy enough In-Reply-To: References: <056.ddd6dbef542c6ca3bde6bd36bb5cb4f0@localhost> <065.b13add13be386db792cfdd3e2a478791@localhost> <948C28A4-E060-46D1-BDB7-9C24D19D927E@cs.york.ac.uk> Message-ID: <4B17DB27.9020306@gmail.com> On 03/12/2009 14:12, Henning Thielemann wrote: > > On Thu, 3 Dec 2009, Malcolm Wallace wrote: > >>> #3709: Data.Either.partitionEithers is not lazy enough >>> >>> This is a behavioural change, e.g.: >>> Main> case partitionEithers1 [Left 'a', error "Not me"] of (x : _, _) >>> -> x >>> Program error: Not me >>> Main> case partitionEithers2 [Left 'a', error "Not me"] of (x : _, _) >>> -> x >>> 'a' >> >> Yes, and isn't that the point of the bugfix? No non-bottoming program >> has changed, but fewer programs fail now. I find it hard to imagine >> that anyone could have been relying on getting a crash here. > > Making something more lazy can cause a memory leak. and a time leak, or a stack overflow. People might complain if we made foldl' more lazy :-) Cheers, Simon From trac at galois.com Thu Dec 3 11:15:56 2009 From: trac at galois.com (GHC) Date: Thu Dec 3 10:50:36 2009 Subject: [GHC] #414: GHC does not eforce that Main exports main In-Reply-To: <046.38fe8da23abfc42f9ad2cb0e14b8afda@localhost> References: <046.38fe8da23abfc42f9ad2cb0e14b8afda@localhost> Message-ID: <055.94df7ffa9edf1d456c6462a170ea81f7@localhost> #414: GHC does not eforce that Main exports main ---------------------------+------------------------------------------------ Reporter: simonpj | Owner: igloo Type: merge | Status: new Priority: lowest | Milestone: 6.12.2 Component: Compiler | Version: 6.10.4 Resolution: None | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: mod174 | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Comment (by igloo): {{{ Mon Nov 30 04:04:04 PST 2009 Simon Marlow * add a test for #414 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 3 11:16:30 2009 From: trac at galois.com (GHC) Date: Thu Dec 3 10:51:08 2009 Subject: [GHC] #3677: Optimizer creates stack overflow on filtered CAF In-Reply-To: <043.bc40a075329f7b63a53340629e65db0f@localhost> References: <043.bc40a075329f7b63a53340629e65db0f@localhost> Message-ID: <052.fb190db2d03ecb64fbdad0536746c1aa@localhost> #3677: Optimizer creates stack overflow on filtered CAF ----------------------------+----------------------------------------------- Reporter: jpet | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Windows Testcase: | Architecture: x86 Failure: Runtime crash | ----------------------------+----------------------------------------------- Comment (by igloo): {{{ Mon Nov 30 03:25:08 PST 2009 Simon Marlow * add a test for #3677 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 3 12:20:40 2009 From: trac at galois.com (GHC) Date: Thu Dec 3 11:55:20 2009 Subject: [GHC] #3720: unknown symbol `_GLOBAL_OFFSET_TABLE_' when loading module Message-ID: <044.c8fe00d0df86676aef8470e80da77abf@localhost> #3720: unknown symbol `_GLOBAL_OFFSET_TABLE_' when loading module ---------------------------------+------------------------------------------ Reporter: fasta | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.10.4 | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Other ---------------------------------+------------------------------------------ I get the following, which is caused by a bug in ghci, which probably results from ghci reusing .o files when it should not. Util.hs is a user-defined file on which the module which is currently being loaded (Main.hs) depends. {{{: ./Util.o: unknown symbol `_GLOBAL_OFFSET_TABLE_'}}} If I remove all the .o files, the module happily loads in ghci. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 3 17:13:02 2009 From: trac at galois.com (GHC) Date: Thu Dec 3 16:47:40 2009 Subject: [GHC] #3721: Can't install base-4.0.0.0 !! Message-ID: <044.ce5a38d30c19ad72f7315d28514e5c11@localhost> #3721: Can't install base-4.0.0.0 !! ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ mozhgan@Mozhgan-Kch:~/Desktop/base-4.0.0.0$ runhaskell Setup.hs configure --ghc :1:22: attempting to use module `System.IO' (System/IO.hs) which is not loaded :1:22: Not in scope: `System.IO.stderr' :1:22: Not in scope: `System.IO.stdin' ghc-6.8.2: panic! (the 'impossible' happened) (GHC version 6.8.2 for i386-unknown-linux): interactiveUI:setBuffering -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 3 17:21:33 2009 From: trac at galois.com (GHC) Date: Thu Dec 3 16:56:27 2009 Subject: [GHC] #3658: Dynamically link GHCi on platforms that support it In-Reply-To: <047.129d39e2608fc274aa7ba90c094c6a82@localhost> References: <047.129d39e2608fc274aa7ba90c094c6a82@localhost> Message-ID: <056.875d470aaac16c43666a7bd0240e555c@localhost> #3658: Dynamically link GHCi on platforms that support it ---------------------------+------------------------------------------------ Reporter: simonmar | Owner: Type: task | Status: new Priority: high | Milestone: 6.14.1 Component: GHCi | Version: 6.10.4 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by hgolden): * cc: howard_b_golden@yahoo.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 3 17:39:09 2009 From: trac at galois.com (GHC) Date: Thu Dec 3 17:14:00 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.3b0be318073eb9272b1e66a2fd890bd7@localhost> #2615: ghci doesn't play nice with linker scripts ------------------------------------------+--------------------------------- Reporter: AlecBerryman | Owner: hgolden Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: GHCi | Version: 6.10.1 Resolution: | Keywords: dlopen, dynamic linking Difficulty: Unknown | Os: Linux Testcase: | Architecture: Unknown/Multiple Failure: Incorrect result at runtime | ------------------------------------------+--------------------------------- Changes (by hgolden): * keywords: => dlopen, dynamic linking * failure: None/Unknown => Incorrect result at runtime * owner: => hgolden Comment: I have been testing a patch which has been reviewed by Simon M. and Duncan C. I am now incorporating the changes they requested and preparing a test case. I expect to have this completed by December 14, 2009. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 3 20:45:02 2009 From: trac at galois.com (GHC) Date: Thu Dec 3 20:19:40 2009 Subject: [GHC] #3722: Haskeline Iconv needs HAVE_LANGINFO_H Message-ID: <043.b0b3ab959578ffb5ff45ff74152ccd8c@localhost> #3722: Haskeline Iconv needs HAVE_LANGINFO_H ---------------------------+------------------------------------------------ Reporter: donn | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.12.1 RC1 | Keywords: Os: Other | Testcase: Architecture: x86 | Failure: None/Unknown ---------------------------+------------------------------------------------ per libraries/base/GHC/IO/Encoding/Iconv.hs, libraries/haskeline/System/Console/Haskeline/Backend/Iconv.hsc should test for HAVE_LANGINFO_H, and default codeset to "" in its absence. (No langinfo.h on Haiku.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 3 20:45:17 2009 From: trac at galois.com (GHC) Date: Thu Dec 3 20:19:58 2009 Subject: [GHC] #3722: Haskeline Iconv needs HAVE_LANGINFO_H In-Reply-To: <043.b0b3ab959578ffb5ff45ff74152ccd8c@localhost> References: <043.b0b3ab959578ffb5ff45ff74152ccd8c@localhost> Message-ID: <052.2869fc9e45ccea18090f6fb8a7afe131@localhost> #3722: Haskeline Iconv needs HAVE_LANGINFO_H -------------------------+-------------------------------------------------- Reporter: donn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.12.1 RC1 Resolution: | Keywords: Os: Other | Testcase: Architecture: x86 | Failure: Building GHC failed -------------------------+-------------------------------------------------- Changes (by donn): * failure: None/Unknown => Building GHC failed -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 3 20:48:47 2009 From: trac at galois.com (GHC) Date: Thu Dec 3 20:23:25 2009 Subject: [GHC] #3723: SharedMem.hsc should include , not Message-ID: <043.3ccfd43c4f25a82e84eff1b44d03ad03@localhost> #3723: SharedMem.hsc should include , not ---------------------------+------------------------------------------------ Reporter: donn | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.12.1 RC1 | Keywords: Os: Other | Testcase: Architecture: x86 | Failure: Building GHC failed ---------------------------+------------------------------------------------ libraries/unix/System/Posix/SharedMem.hsc should include , per POSIX 1003.1 I believe, not -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 3 20:51:50 2009 From: trac at galois.com (GHC) Date: Thu Dec 3 20:26:28 2009 Subject: [GHC] #3724: rts/package.conf.d specifies -lm for all platforms Message-ID: <043.58505aaf8b324d493ddba3cfafc80288@localhost> #3724: rts/package.conf.d specifies -lm for all platforms ---------------------------+------------------------------------------------ Reporter: donn | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.12.1 RC1 | Keywords: Os: Other | Testcase: Architecture: x86 | Failure: Building GHC failed ---------------------------+------------------------------------------------ rts/package.conf.d: extra-libraries "m" ... requires -lm on all platforms, but Haiku and presumably others don't need it or support it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 3 20:57:11 2009 From: trac at galois.com (GHC) Date: Thu Dec 3 20:31:48 2009 Subject: [GHC] #3725: Annotations not written to interface files Message-ID: <041.dfa4280aa188470f7b07eff4da2beab3@localhost> #3725: Annotations not written to interface files ---------------------------------+------------------------------------------ Reporter: rl | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.13 | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Other ---------------------------------+------------------------------------------ Small example: {{{ module C where data T a = T a }}} Compile it: {{{ newbie:tests rl$ ~/projects/ndp/ghc/inplace/bin/ghc-stage2 -O2 -c C.hs newbie:tests rl$ ls -l C.hi -rw-r--r-- 1 rl rl 485 4 Dec 12:53 C.hi }}} Add an annotation: `{-# ANN type T () #-}`. Compile: {{{ newbie:tests rl$ ~/projects/ndp/ghc/inplace/bin/ghc-stage2 -O2 -c C.hs Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package ffi-1.0 ... linking ... done. newbie:tests rl$ ls -l C.hi -rw-r--r-- 1 rl rl 485 4 Dec 12:53 C.hi }}} Note that the interface file hasn't been updated. Remove `C.hi` and recompile: {{{ newbie:tests rl$ rm C.hi newbie:tests rl$ ~/projects/ndp/ghc/inplace/bin/ghc-stage2 -O2 -c C.hs Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package ffi-1.0 ... linking ... done. newbie:tests rl$ ls -l C.hi -rw-r--r-- 1 rl rl 507 4 Dec 12:54 C.hi }}} Only now has the annotation been written to `C.hi`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 3 22:23:14 2009 From: trac at galois.com (GHC) Date: Thu Dec 3 21:57:52 2009 Subject: [GHC] #3710: WriteFile: invalid argument (The handle is invalid.) In-Reply-To: <049.64f91bfcc534a4ca7b7a2b4fe6766e23@localhost> References: <049.64f91bfcc534a4ca7b7a2b4fe6766e23@localhost> Message-ID: <058.a8a6783af8afd2676162156f2757ce95@localhost> #3710: WriteFile: invalid argument (The handle is invalid.) -------------------------------+-------------------------------------------- Reporter: dherington | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 6.10.4 Resolution: invalid | Keywords: garbage collector Os: Windows | Testcase: Architecture: x86 | Failure: Incorrect result at runtime -------------------------------+-------------------------------------------- Changes (by dherington): * status: new => closed * resolution: => invalid Comment: I have discovered that my failure to zero the hEvent member of the OVERLAPPED structure was causing the reported failures in writeFile. So I'm invalidating this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 3 23:18:32 2009 From: trac at galois.com (GHC) Date: Thu Dec 3 22:53:09 2009 Subject: [GHC] #3726: Internal error compiling ghc-syb-0.1.2.1 Message-ID: <052.a180cd251b9bcdf1661af16494dfc00b@localhost> #3726: Internal error compiling ghc-syb-0.1.2.1 ---------------------------------+------------------------------------------ Reporter: DavidHalperin | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Compile-time crash ---------------------------------+------------------------------------------ On Ubuntu Karmic x86_64 (installed from the apt repo), when I try to compile the ghc-syb-0.1.2.1 package I get the following output: Building ghc-syb-0.1.2.1...[[BR]] [1 of 2] Compiling GHC.SYB.Instances ( src/GHC/SYB/Instances.hs, dist/build/GHC/SYB/Instances.o )[[BR]] ghc: internal error: evacuate: strange closure type 13771848 (GHC version 6.10.4 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 3 23:42:06 2009 From: trac at galois.com (GHC) Date: Thu Dec 3 23:16:43 2009 Subject: [GHC] #3727: several Haiku platform defs Message-ID: <043.0c45c6547023fdad014a8678dc73ea96@localhost> #3727: several Haiku platform defs ---------------------------+------------------------------------------------ Reporter: donn | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.12.1 RC1 | Keywords: Os: Other | Testcase: Architecture: x86 | Failure: Building GHC failed ---------------------------+------------------------------------------------ Attached diffs support the Haiku OS in several places where there are already platform tests. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 4 01:05:58 2009 From: trac at galois.com (GHC) Date: Fri Dec 4 00:40:35 2009 Subject: [GHC] #3728: configure should omit full path in unistd.h, stdlib.h return type tests Message-ID: <043.d33bce572e64777410efea0050887938@localhost> #3728: configure should omit full path in unistd.h, stdlib.h return type tests ---------------------------+------------------------------------------------ Reporter: donn | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.12.1 RC1 | Keywords: Os: Other | Testcase: Architecture: x86 | Failure: Building GHC failed ---------------------------+------------------------------------------------ autoconf AC_EGREP_HEADER actually uses the C preprocessor, so include file names will be resolved properly and should not specify full (potentially wrong) path. (Wrong path on Haiku.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 4 06:14:42 2009 From: trac at galois.com (GHC) Date: Fri Dec 4 05:49:20 2009 Subject: [GHC] #3729: Allow modification of capabilities at runtime Message-ID: <047.1fc6c652629dc9260c76c16a8c0a5af6@localhost> #3729: Allow modification of capabilities at runtime ---------------------------------+------------------------------------------ Reporter: mlesniak | Owner: Type: task | Status: new Priority: normal | Component: Runtime System Version: 6.13 | Keywords: capabilities Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Currently the number of capabilities can only be set at the start of a program using -N. At least for benchmarking and playing with semi- implicit code (any other real-world scenarious?) if would be nice to change the number of capabilities at runtime. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 4 06:17:24 2009 From: trac at galois.com (GHC) Date: Fri Dec 4 05:52:02 2009 Subject: [GHC] #3719: Literate code with # In-Reply-To: <046.119383e131eabeee5d5ffb7da02e279e@localhost> References: <046.119383e131eabeee5d5ffb7da02e279e@localhost> Message-ID: <055.664656cf4adb2fad41d61f31c984182c@localhost> #3719: Literate code with # ----------------------------------------+----------------------------------- Reporter: zenzike | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Parser) | Version: 6.10.4 Resolution: wontfix | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: GHC rejects valid program | ----------------------------------------+----------------------------------- Changes (by simonmar): * status: new => closed * resolution: => wontfix Comment: This is as intended, so that you can put CPP directives in the literate comments. e.g. {{{ #ifdef ENBABLE_FOO > .... foo .... #endif }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 4 08:52:50 2009 From: trac at galois.com (GHC) Date: Fri Dec 4 08:27:27 2009 Subject: [GHC] #3719: Literate code with # In-Reply-To: <046.119383e131eabeee5d5ffb7da02e279e@localhost> References: <046.119383e131eabeee5d5ffb7da02e279e@localhost> Message-ID: <055.1faa16f93f938466f703149ac08990ca@localhost> #3719: Literate code with # ----------------------------------------+----------------------------------- Reporter: zenzike | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Parser) | Version: 6.10.4 Resolution: wontfix | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: GHC rejects valid program | ----------------------------------------+----------------------------------- Comment (by zenzike): Wouldn't it be better if these were written as {{{ > #ifdef ENABLE_FOO > ... foo ... > #endif }}} instead? It seems counter productive that in a literate file that there is no allowance for # at the beginning of a line, without some special meaning to ghc; since literate files should be, well, literate! If a CPP directive should be fed through into ghc, wouldn't it be better on the end of a Bird track? In the meantime, is there a way of turning off the # as CPP directive functionality? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 4 10:21:46 2009 From: trac at galois.com (GHC) Date: Fri Dec 4 09:56:23 2009 Subject: [GHC] #3719: Literate code with # In-Reply-To: <046.119383e131eabeee5d5ffb7da02e279e@localhost> References: <046.119383e131eabeee5d5ffb7da02e279e@localhost> Message-ID: <055.6f5fe77e0084efb951e2910f20d6aaae@localhost> #3719: Literate code with # ----------------------------------------+----------------------------------- Reporter: zenzike | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Parser) | Version: 6.10.4 Resolution: wontfix | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: GHC rejects valid program | ----------------------------------------+----------------------------------- Comment (by duncan): Replying to [comment:2 simonmar]: > This is as intended, so that you can put CPP directives in the literate comments. Shouldn't we be running CPP before unlit? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 4 11:11:34 2009 From: trac at galois.com (GHC) Date: Fri Dec 4 10:46:11 2009 Subject: [GHC] #650: Improve interaction between mutable arrays and GC In-Reply-To: <047.44b951cd4b5aa8536d862412c8d86597@localhost> References: <047.44b951cd4b5aa8536d862412c8d86597@localhost> Message-ID: <056.0fb27a52d7c35ceef99ade64d4996897@localhost> #650: Improve interaction between mutable arrays and GC -----------------------------------------+---------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Runtime System | Version: 6.4.1 Resolution: | Keywords: Difficulty: Moderate (less than a day) | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Runtime performance bug | -----------------------------------------+---------------------------------- Comment (by simonmar): See [wiki:Commentary/Rts/Storage/GC/RememberedSets] for more background on this. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 4 14:35:36 2009 From: trac at galois.com (GHC) Date: Fri Dec 4 14:10:12 2009 Subject: [GHC] #3730: hp2ps: Deviation.c:(.text+0x42b): undefined reference to `sqrt' Message-ID: <045.ec140461375c1820e8f386032560a656@localhost> #3730: hp2ps: Deviation.c:(.text+0x42b): undefined reference to `sqrt' -------------------------------+-------------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.10.4 | Keywords: autoconf, libm Os: Linux | Testcase: Architecture: x86_64 (amd64) | Failure: Building GHC failed -------------------------------+-------------------------------------------- Start of story is here: http://bugs.gentoo.org/show_bug.cgi?id=293208 In short: LIBM variable is wrongly fulfilled by test: {{{ configure:8389: checking for atan configure:8389: x86_64-pc-linux-gnu-gcc -o conftest -march=nocona -O2 -pipe -Wl,-O1 conftest.c -lbfd -liberty >&5 conftest.c:109: warning: conflicting types for built-in function 'atan' configure:8389: $? = 0 }}} thus test leads to {{{ LIBM='' }}} , then that sole LIBM passed to hp2ps and hp2ps fails, as no -lbfd -liberty were passed: {{{ gcc -o hp2ps -O -march=native -O2 -pipe -Wa,--noexecstack -I../../includes -Wall AreaBelow.o AuxFile.o Axes.o Curves.o Deviation.o Dimensions.o Error.o HpFile.o Key.o Main.o Marks.o PsFile.o Reorder.o Scale.o Shade.o TopTwenty.o TraceElement.o Utilities.o Deviation.o: In function `Deviation': Deviation.c:(.text+0x42b): undefined reference to `sqrt' }}} AFAIU, before testing for atan presence in -lm ghc should hide his previously found $LIBS, as LIBM is planned to be used separately. And separate issue: hp2ps (and other utils/) does not seem to respect external LDFLAGS some spam on #ghc (nothing new): {{{ 21:02:36 < trofi> hi, i seem to have found small bunch of bugs in ghc-6.10.4/ghc-6.12 21:03:32 < trofi> I don't like how LIBM variable is detected. It leads to bugs like http://bugs.gentoo.org/show_bug.cgi?id=293208 21:04:41 < trofi> first test finds atan in absolutely unrelated libs: configure:17837: /usr/bin/gcc -o conftest -g -O2 conftest.c -lbfd -liberty >&5 21:04:49 < trofi> and decides LIBM='' 21:06:13 < trofi> is it standard autotools practice to grind libraries together? 21:06:36 < trofi> i thought they should be tested separately 21:09:21 < pejo> trofi, so in what library is atan on your OS? 21:10:19 < trofi> libm 21:10:53 < trofi> the problem is autoconf tests not only libm, but libs he found before: -lbfd and -liberty 21:13:04 < trofi> (at a time) 21:13:12 < pejo> What autoconf tests depends on how you've written your tests. If it finds atan in either libiberty or libbdf, then it doesn't need libm, does it? 21:13:32 < trofi> yes it doesn't 21:13:49 < trofi> but ghc build system does not pass those libraries to build some utils 21:13:55 < trofi> it passes only LIBM 21:14:11 < trofi> which is "obviously" empty 21:14:55 < trofi> it's another bug - when some utils are built there is no respect of user's LDFLAGS variable }}} Sorry for describing bug in reverse order. Seems like ghc-6.12 is affected too. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 4 14:59:50 2009 From: trac at galois.com (GHC) Date: Fri Dec 4 14:34:27 2009 Subject: [GHC] #3730: hp2ps: Deviation.c:(.text+0x42b): undefined reference to `sqrt' In-Reply-To: <045.ec140461375c1820e8f386032560a656@localhost> References: <045.ec140461375c1820e8f386032560a656@localhost> Message-ID: <054.11072b8fbf7c238e036cf958e1cf2fc1@localhost> #3730: hp2ps: Deviation.c:(.text+0x42b): undefined reference to `sqrt' -------------------------------+-------------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.10.4 Resolution: | Keywords: autoconf, libm Os: Linux | Testcase: Architecture: x86_64 (amd64) | Failure: Building GHC failed -------------------------------+-------------------------------------------- Comment (by asuffield): Why on earth is ghc linking libiberty anyway? That can't be right. (Why does gentoo have a libiberty installed? That is not right) All of this bug report is completely misleading. This has got nothing to do with libbfd or libiberty, neither of which defines atan. The correct diagnostic line was this one: {{{ conftest.c:109: warning: conflicting types for built-in function 'atan' }}} Somebody added a builtin atan function to gcc. Hence, you no longer need to link libm in order to use atan. The test in configure.ac needs changing to check for sqrt. That's all. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 4 15:39:57 2009 From: trac at galois.com (GHC) Date: Fri Dec 4 15:14:36 2009 Subject: [GHC] #3730: hp2ps: Deviation.c:(.text+0x42b): undefined reference to `sqrt' In-Reply-To: <045.ec140461375c1820e8f386032560a656@localhost> References: <045.ec140461375c1820e8f386032560a656@localhost> Message-ID: <054.f92070853e2b06276037fd8b7cf63cb7@localhost> #3730: hp2ps: Deviation.c:(.text+0x42b): undefined reference to `sqrt' -------------------------------+-------------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.10.4 Resolution: | Keywords: autoconf, libm Os: Linux | Testcase: Architecture: x86_64 (amd64) | Failure: Building GHC failed -------------------------------+-------------------------------------------- Comment (by slyfox): Sigh, i tried so hard. Replying to [comment:1 asuffield]: > All of this bug report is completely misleading. This has got nothing to do with libbfd or libiberty, neither of which defines atan. The correct diagnostic line was this one: > > {{{ > conftest.c:109: warning: conflicting types for built-in function 'atan' > }}} > > > Somebody added a builtin atan function to gcc. Hence, you no longer need to link libm in order to use atan. > > The test in configure.ac needs changing to check for sqrt. That's all. Nope, autoconf's atan intentionally has nonbuiltin prototype, different from gcc's to test _linkage_. No matter what builting gcc has - it will not link w/o libm, and it does not link on my system (with the same warning), so your point is incorrect. Builtin does not affect process of libm needness resolution. Look at my system: {{{ configure:18619: gcc -o conftest -g -O2 conftest.c -lbfd -liberty >&5 conftest.c:108: warning: conflicting types for built-in function 'atan' /tmp/ccSFmqh0.o: In function `main': /tmp/z/ghc-6.10.4/conftest.c:119: undefined reference to `atan' collect2: ld returned 1 exit status configure:18625: $? = 1 }}} The second - sqrt will be found in libbfd as well, as original bug reporter has libm in depends on libbfd (don't ask me why, being silly it's absolutely legal). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 4 15:45:07 2009 From: trac at galois.com (GHC) Date: Fri Dec 4 15:19:41 2009 Subject: [GHC] #3730: hp2ps: Deviation.c:(.text+0x42b): undefined reference to `sqrt' In-Reply-To: <045.ec140461375c1820e8f386032560a656@localhost> References: <045.ec140461375c1820e8f386032560a656@localhost> Message-ID: <054.bd69767e03c3a52cadf9967178744f51@localhost> #3730: hp2ps: Deviation.c:(.text+0x42b): undefined reference to `sqrt' -------------------------------+-------------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.10.4 Resolution: | Keywords: autoconf, libm Os: Linux | Testcase: Architecture: x86_64 (amd64) | Failure: Building GHC failed -------------------------------+-------------------------------------------- Comment (by slyfox): BTW, sqrt has builtin primitive on that gcc too. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 4 15:54:46 2009 From: trac at galois.com (GHC) Date: Fri Dec 4 15:29:20 2009 Subject: [GHC] #3730: hp2ps: Deviation.c:(.text+0x42b): undefined reference to `sqrt' In-Reply-To: <045.ec140461375c1820e8f386032560a656@localhost> References: <045.ec140461375c1820e8f386032560a656@localhost> Message-ID: <054.eca77890206af06a40fb56d2c7a423a8@localhost> #3730: hp2ps: Deviation.c:(.text+0x42b): undefined reference to `sqrt' -------------------------------+-------------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.10.4 Resolution: | Keywords: autoconf, libm Os: Linux | Testcase: Architecture: x86_64 (amd64) | Failure: Building GHC failed -------------------------------+-------------------------------------------- Comment (by asuffield): Ah, now it makes sense. Easy fix then: move the libm test above the libbfd test. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 4 16:08:35 2009 From: trac at galois.com (GHC) Date: Fri Dec 4 15:43:09 2009 Subject: [GHC] #3731: SYB gone wild - mysterious <> in code derived from an syb-with-class example Message-ID: <042.4958fc1cdd70e26a14593e01de97e65e@localhost> #3731: SYB gone wild - mysterious <> in code derived from an syb-with-class example ---------------------------------+------------------------------------------ Reporter: dsf | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.12.1 RC1 | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Incorrect result at runtime ---------------------------------+------------------------------------------ (From http://www.haskell.org/pipermail/haskell- cafe/2009-December/070193.html) In the attached code, 1. if you load the code into ghci and evaluate e it will hang, but (defaultValueD dict) :: Expression returns fine 2. if you change the gunfold instance for Proposition to, error "gunfold" it stops hanging -- even though this code is never called. 3. if you change, ( Data ctx [Expression], Sat (ctx Expression) => Data ctx Expression, to (Data ctx Expression, ....) => ... it stops hanging. If someone could explain why each of these cases perform as they do, that would be awesome! Right now it is a big mystery to me.. e calls dict .. and there is only one instance of dict available, which should call error right away. I can't see how something could get in the way there... -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 4 16:12:26 2009 From: trac at galois.com (GHC) Date: Fri Dec 4 15:47:03 2009 Subject: [GHC] #3731: SYB gone wild - mysterious <> in code derived from an syb-with-class example In-Reply-To: <042.4958fc1cdd70e26a14593e01de97e65e@localhost> References: <042.4958fc1cdd70e26a14593e01de97e65e@localhost> Message-ID: <051.1d4c2d570f364c951cfb134f1690e510@localhost> #3731: SYB gone wild - mysterious <> in code derived from an syb-with-class example ---------------------------------+------------------------------------------ Reporter: dsf | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.12.1 RC1 Resolution: | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Incorrect result at runtime ---------------------------------+------------------------------------------ Comment (by dsf): Also affects 6.10.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 4 16:25:31 2009 From: trac at galois.com (GHC) Date: Fri Dec 4 16:00:07 2009 Subject: [GHC] #3730: hp2ps: Deviation.c:(.text+0x42b): undefined reference to `sqrt' In-Reply-To: <045.ec140461375c1820e8f386032560a656@localhost> References: <045.ec140461375c1820e8f386032560a656@localhost> Message-ID: <054.e59e3e6838beb6544f2aa9f6610693fa@localhost> #3730: hp2ps: Deviation.c:(.text+0x42b): undefined reference to `sqrt' -------------------------------+-------------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.10.4 Resolution: | Keywords: autoconf, libm Os: Linux | Testcase: Architecture: x86_64 (amd64) | Failure: Building GHC failed -------------------------------+-------------------------------------------- Changes (by kolmodin): * cc: kolmodin@gentoo.org (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 4 18:12:19 2009 From: trac at galois.com (GHC) Date: Fri Dec 4 17:46:54 2009 Subject: [GHC] #3664: Ghc eats tremendous heaps of RAM in -prof build (highlighting-kate) In-Reply-To: <045.0f6b0943402daeb82291512e1fe74507@localhost> References: <045.0f6b0943402daeb82291512e1fe74507@localhost> Message-ID: <054.bda5398b3e804ca3df58c39a412b636e@localhost> #3664: Ghc eats tremendous heaps of RAM in -prof build (highlighting-kate) -------------------------------------------+-------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86_64 (amd64) Failure: Compile-time performance bug | -------------------------------------------+-------------------------------- Comment (by slyfox): Replying to [comment:2 igloo]: > Thanks for the report. Is this a regression since 6.10? Yes, it is. > That PHP module includes a couple of 50000 character lines, mostly composed of a list of strings. I suspect that's the problem, but haven't profiled at all. > > It would be useful if someone could make a standalone, minimal testcase. What is minimal? Will be enough to strip this package to 3 almost unmodified .hs files but leave all external deps, like parsec and pcre- light, or you would like it fully buildable with ghc --make ? -- Ticket URL: GHC The Glasgow Haskell Compiler From conal at conal.net Sat Dec 5 01:48:12 2009 From: conal at conal.net (Conal Elliott) Date: Sat Dec 5 01:23:05 2009 Subject: Associated data types + GADTs: known bug? Message-ID: Combining associated data types + GADTs proves fatal to GHCi 6.10.3 and 6.10.4. Is this bug known? If so, is it fixed in a later ghc? There's a stand-alone example at http://hpaste.org/fastcgi/hpaste.fcgi/view?id=13629 - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-bugs/attachments/20091205/f082fbcc/attachment.html From trac at galois.com Sat Dec 5 08:42:25 2009 From: trac at galois.com (GHC) Date: Sat Dec 5 08:17:09 2009 Subject: [GHC] #3550: Dynamic libraries don't work on Mac OS/X In-Reply-To: <056.c6f0034a4d5f342c60f11476270241e0@localhost> References: <056.c6f0034a4d5f342c60f11476270241e0@localhost> Message-ID: <065.9fb63f70fa2c1d765c0c0d951a20f8ae@localhost> #3550: Dynamic libraries don't work on Mac OS/X --------------------------------------------------------------+------------- Reporter: StephenBlackheath | Owner: StephenBlackheath Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: Compiler | Version: 6.11 Resolution: | Keywords: dynamic mac osx Difficulty: Unknown | Os: MacOS X Testcase: http://upcycle.it/~blackh/ghc/test-case.tar.bz2 | Architecture: Unknown/Multiple Failure: None/Unknown | --------------------------------------------------------------+------------- Comment (by igloo): I've applied the patches to the HEAD; thanks! Would it be possible for you to change the testcase so that it uses a tiny Cabal package - if possible, containing just 1 module containing 1 simple function - so that we can add it to the testsuite, please? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Dec 5 09:21:19 2009 From: trac at galois.com (GHC) Date: Sat Dec 5 08:56:03 2009 Subject: [GHC] #3550: Dynamic libraries don't work on Mac OS/X In-Reply-To: <056.c6f0034a4d5f342c60f11476270241e0@localhost> References: <056.c6f0034a4d5f342c60f11476270241e0@localhost> Message-ID: <065.00f53e1ff4005e68c01551615c57c85d@localhost> #3550: Dynamic libraries don't work on Mac OS/X --------------------------------------------------------------+------------- Reporter: StephenBlackheath | Owner: StephenBlackheath Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: Compiler | Version: 6.11 Resolution: | Keywords: dynamic mac osx Difficulty: Unknown | Os: MacOS X Testcase: http://upcycle.it/~blackh/ghc/test-case.tar.bz2 | Architecture: Unknown/Multiple Failure: None/Unknown | --------------------------------------------------------------+------------- Comment (by mwotton): Yep, I can do that. test-case-2.tar.bz2 is attached - it's using the primes package, which has two visible functions and compiles in less than a second on my machine. let me know if you'd prefer me to upload a dummy cabal package just for testing. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Dec 5 10:33:35 2009 From: trac at galois.com (GHC) Date: Sat Dec 5 10:08:08 2009 Subject: [GHC] #3725: Annotations not written to interface files In-Reply-To: <041.dfa4280aa188470f7b07eff4da2beab3@localhost> References: <041.dfa4280aa188470f7b07eff4da2beab3@localhost> Message-ID: <050.3a50ab3972a49094d399bfe7ce0f6799@localhost> #3725: Annotations not written to interface files -----------------------+---------------------------------------------------- Reporter: rl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.13 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Other | -----------------------+---------------------------------------------------- Changes (by simonpj): * difficulty: => Comment: Roman, Quite right. The relevant code is in `MkIface.lhs`. Look at the declaration of `IfaceDeclExtras`: {{{ data IfaceDeclExtras = IfaceIdExtras Fixity [IfaceRule] | IfaceDataExtras Fixity [IfaceInstABI] [(Fixity,[IfaceRule])] | IfaceClassExtras Fixity [IfaceInstABI] [(Fixity,[IfaceRule])] | IfaceSynExtras Fixity | IfaceOtherDeclExtras }}} This collects information that forms part of an Id's fingerprint, even though the information is not serialised along with the Id itself; instead it occurs elsewhere in the interface file. For example, fixity forms part of an Id's fingerprint, but appears in the `mi_fixities` field of the `ModIface`. What we'd forgotten is that the annotations for an Id should form part of its "extras". So the `IfaceIdExtras` constructor should look like {{{ IfaceIdExtras Fixity [IfaceRule] [Serialized] }}} If you make that change, then I think the knock-on changes (notably filling in that field) will be obvious. Could you have a go at doing this? Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From simonpj at microsoft.com Sat Dec 5 10:47:22 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Sat Dec 5 10:20:39 2009 Subject: Associated data types + GADTs: known bug? In-Reply-To: References: Message-ID: <59543203684B2244980D7E4057D5FBC1085071CC@DB3EX14MBXC310.europe.corp.microsoft.com> Conal It compiles OK in the HEAD, and therefore I expect 6.12. So that's good In general associated types and GADTs should work just fine together. In practice, I'm amazed they work as well as they do, because the current infrastructure is creaking. I'm working with Tom and Dimitrios on a new type-constraint-solving engine, which should be much more robust and predictable. Simon From: glasgow-haskell-bugs-bounces@haskell.org [mailto:glasgow-haskell-bugs-bounces@haskell.org] On Behalf Of Conal Elliott Sent: 05 December 2009 06:48 To: glasgow-haskell-bugs@haskell.org Subject: Associated data types + GADTs: known bug? Combining associated data types + GADTs proves fatal to GHCi 6.10.3 and 6.10.4. Is this bug known? If so, is it fixed in a later ghc? There's a stand-alone example at http://hpaste.org/fastcgi/hpaste.fcgi/view?id=13629 - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-bugs/attachments/20091205/d9104225/attachment.html From trac at galois.com Sat Dec 5 12:51:36 2009 From: trac at galois.com (GHC) Date: Sat Dec 5 12:26:13 2009 Subject: [GHC] #3715: GHC API no longer exports location information for error/warning messages In-Reply-To: <046.4e83f78284330dedbf9948985e29216e@localhost> References: <046.4e83f78284330dedbf9948985e29216e@localhost> Message-ID: <055.bc50e0a615487d3faed9374dad2cd0dc@localhost> #3715: GHC API no longer exports location information for error/warning messages --------------------------------------+------------------------------------- Reporter: greenrd | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: GHC API | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: Easy (less than 1 hour) | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Other | --------------------------------------+------------------------------------- Changes (by igloo): * milestone: => 6.14.1 Comment: The actual regression is fixed in HEAD and 6.12 by: {{{ Sat Dec 5 15:35:32 GMT 2009 Ian Lynagh * Add some missing exports back for GHC package users; fixes trac #3715 }}} I'll leave the ticket open so we can decide what we want to expose in the `GHC` module. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Dec 5 12:52:14 2009 From: trac at galois.com (GHC) Date: Sat Dec 5 12:26:46 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.6e3cd949347c09d71ed60102c657f030@localhost> #3100: GHC Panic "reifyType PredTy" in HAppS.Data.IxSet.inferIxSet ---------------------------+------------------------------------------------ Reporter: mightybyte | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Resolution: fixed | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: th/T3100 | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Dec 5 12:53:36 2009 From: trac at galois.com (GHC) Date: Sat Dec 5 12:28:09 2009 Subject: [GHC] #3102: The impossible happened with implicit parameters In-Reply-To: <053.ebde85ce07c798d9c38e07173af669f0@localhost> References: <053.ebde85ce07c798d9c38e07173af669f0@localhost> Message-ID: <062.2ccc88610b58f648562512185bd7006d@localhost> #3102: The impossible happened with implicit parameters ------------------------------------------+--------------------------------- Reporter: Ashley Yakeley | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.12.1 Component: Compiler (Type checker) | Version: 6.10.1 Resolution: fixed | Keywords: Difficulty: Unknown | Os: Linux Testcase: tyepcheck/should_fail/T3102 | Architecture: Unknown/Multiple Failure: None/Unknown | ------------------------------------------+--------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Dec 5 12:54:16 2009 From: trac at galois.com (GHC) Date: Sat Dec 5 12:28:49 2009 Subject: [GHC] #3677: Optimizer creates stack overflow on filtered CAF In-Reply-To: <043.bc40a075329f7b63a53340629e65db0f@localhost> References: <043.bc40a075329f7b63a53340629e65db0f@localhost> Message-ID: <052.2c9007e988527476ad5448765524e151@localhost> #3677: Optimizer creates stack overflow on filtered CAF ----------------------------+----------------------------------------------- Reporter: jpet | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 6.12.2 Component: Compiler | Version: 6.10.4 Resolution: fixed | Keywords: Difficulty: | Os: Windows Testcase: | Architecture: x86 Failure: Runtime crash | ----------------------------+----------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Dec 5 12:54:54 2009 From: trac at galois.com (GHC) Date: Sat Dec 5 12:29:27 2009 Subject: [GHC] #3677: Optimizer creates stack overflow on filtered CAF In-Reply-To: <043.bc40a075329f7b63a53340629e65db0f@localhost> References: <043.bc40a075329f7b63a53340629e65db0f@localhost> Message-ID: <052.87cd96973906e0da650533ebbed2ae61@localhost> #3677: Optimizer creates stack overflow on filtered CAF ----------------------------+----------------------------------------------- Reporter: jpet | Owner: simonpj Type: bug | Status: reopened Priority: normal | Milestone: 6.12.2 Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Windows Testcase: | Architecture: x86 Failure: Runtime crash | ----------------------------+----------------------------------------------- Changes (by igloo): * status: closed => reopened * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Dec 5 12:55:17 2009 From: trac at galois.com (GHC) Date: Sat Dec 5 12:29:51 2009 Subject: [GHC] #3677: Optimizer creates stack overflow on filtered CAF In-Reply-To: <043.bc40a075329f7b63a53340629e65db0f@localhost> References: <043.bc40a075329f7b63a53340629e65db0f@localhost> Message-ID: <052.ddf02b87c9b02612856153dbd2f527a8@localhost> #3677: Optimizer creates stack overflow on filtered CAF ----------------------------+----------------------------------------------- Reporter: jpet | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Windows Testcase: | Architecture: x86 Failure: Runtime crash | ----------------------------+----------------------------------------------- Changes (by igloo): * status: reopened => new -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Dec 5 13:35:15 2009 From: trac at galois.com (GHC) Date: Sat Dec 5 13:09:47 2009 Subject: [GHC] #3677: Optimizer creates stack overflow on filtered CAF In-Reply-To: <043.bc40a075329f7b63a53340629e65db0f@localhost> References: <043.bc40a075329f7b63a53340629e65db0f@localhost> Message-ID: <052.d8c28301469de1a7350c159b3005980d@localhost> #3677: Optimizer creates stack overflow on filtered CAF ----------------------------+----------------------------------------------- Reporter: jpet | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 6.12.2 Component: Compiler | Version: 6.10.4 Resolution: fixed | Keywords: Difficulty: | Os: Windows Testcase: | Architecture: x86 Failure: Runtime crash | ----------------------------+----------------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: I think I checked and found that the optimiser was doing the right thing. It was only without -O that it didn't. So I'll close this. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Dec 5 13:49:34 2009 From: trac at galois.com (GHC) Date: Sat Dec 5 13:24:07 2009 Subject: [GHC] #3664: Ghc eats tremendous heaps of RAM in -prof build (highlighting-kate) In-Reply-To: <045.0f6b0943402daeb82291512e1fe74507@localhost> References: <045.0f6b0943402daeb82291512e1fe74507@localhost> Message-ID: <054.446556f18517545c095399f239197f0f@localhost> #3664: Ghc eats tremendous heaps of RAM in -prof build (highlighting-kate) -------------------------------------------+-------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86_64 (amd64) Failure: Compile-time performance bug | -------------------------------------------+-------------------------------- Comment (by slyfox): Results: {{{ [("Project name","The Glorious Glasgow Haskell Compilation System") ,("Project version","6.10.4") ,("Booter version","6.10.4") ... $ /usr/bin/time ./build.sh ... <> 56.29user 1.31system 1:00.03elapsed 95%CPU (0avgtext+0avgdata 1530144maxresident)k 17376inputs+0outputs (64major+134666minor)pagefaults 0swaps }}} Compiled successfully. Ate ~400MB {{{ [("Project name","The Glorious Glasgow Haskell Compilation System") ,("Project version","6.12.0.20091121") ,("Booter version","6.10.4") ... $ /usr/bin/time ./build.sh ... Heap exhausted; Current maximum heap size is 768000000 bytes (732 MB); use `+RTS -M' to increase it. <> Command exited with non-zero status 251 187.83user 1.69system 3:12.25elapsed 98%CPU (0avgtext+0avgdata 3192560maxresident)k 9488inputs+0outputs (39major+216475minor)pagefaults 0swaps }}} Failed: Heap exhausted (I limited heap in '''build.sh''' by 768M) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Dec 5 14:23:09 2009 From: trac at galois.com (GHC) Date: Sat Dec 5 13:57:42 2009 Subject: [GHC] #3732: GHC 6.10.4 compilation failure: libffi failed to compile Message-ID: <044.58f5b1bdc9b31199f5dc0a9924975019@localhost> #3732: GHC 6.10.4 compilation failure: libffi failed to compile -----------------------+---------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Keywords: Os: Linux | Testcase: Architecture: ia64 | Failure: Building GHC failed -----------------------+---------------------------------------------------- The libffi failed to compile with the error: "configure: error: source directory already configured; run "make distclean" there first" To solve this one must specify the full path when invoking the configure script. To do this the part of the "ghc-xxx/libffi/Makefile" should be changed to: from CC=$(WhatGccIsCalled) $(SHELL) configure \ to CC=$(WhatGccIsCalled) $(SHELL) `pwd`/configure \ -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Dec 5 14:49:51 2009 From: trac at galois.com (GHC) Date: Sat Dec 5 14:24:27 2009 Subject: [GHC] #3730: hp2ps: Deviation.c:(.text+0x42b): undefined reference to `sqrt' In-Reply-To: <045.ec140461375c1820e8f386032560a656@localhost> References: <045.ec140461375c1820e8f386032560a656@localhost> Message-ID: <054.9533f0f868dde83348272b8696ad31d3@localhost> #3730: hp2ps: Deviation.c:(.text+0x42b): undefined reference to `sqrt' -------------------------------+-------------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.10.4 Resolution: | Keywords: autoconf, libm, patch Os: Linux | Testcase: Architecture: x86_64 (amd64) | Failure: Building GHC failed -------------------------------+-------------------------------------------- Changes (by slyfox): * keywords: autoconf, libm => autoconf, libm, patch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Dec 6 06:42:08 2009 From: trac at galois.com (GHC) Date: Sun Dec 6 06:16:43 2009 Subject: [GHC] #3693: Show stack traces In-Reply-To: <043.7c288f8e774d3806292d73b1513892ec@localhost> References: <043.7c288f8e774d3806292d73b1513892ec@localhost> Message-ID: <052.c4b3f142c3cc5e534c77ae9ac3b6c093@localhost> #3693: Show stack traces ------------------------------+--------------------------------------------- Reporter: jpet | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Runtime System | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ------------------------------+--------------------------------------------- Comment (by asuffield): For memory and disk space concerns, this is why we use .debug sections (and sometimes place them in second files). For the difficulty of accessing and dumping it, how about not duplicating the effort? Emit the debugging information in DWARF format as if it was any other language, and either borrow the code from gdb, or (perhaps easier) teach gdb the few extra bits it needs to decipher ghc call stacks. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Dec 6 07:11:46 2009 From: trac at galois.com (GHC) Date: Sun Dec 6 06:46:20 2009 Subject: [GHC] #3664: Ghc eats tremendous heaps of RAM in -prof build (highlighting-kate) In-Reply-To: <045.0f6b0943402daeb82291512e1fe74507@localhost> References: <045.0f6b0943402daeb82291512e1fe74507@localhost> Message-ID: <054.77c7de53c9fd578909efaa4e8c79a99d@localhost> #3664: Ghc eats tremendous heaps of RAM in -prof build (highlighting-kate) -------------------------------------------+-------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86_64 (amd64) Failure: Compile-time performance bug | -------------------------------------------+-------------------------------- Comment (by igloo): Replying to [comment:3 slyfox]: > Replying to [comment:2 igloo]: > > > That PHP module includes a couple of 50000 character lines, mostly composed of a list of strings. I suspect that's the problem, but haven't profiled at all. > > > > It would be useful if someone could make a standalone, minimal testcase. > What is minimal? Will be enough to strip this package to 3 almost unmodified .hs files but leave all external deps, like parsec and pcre- light, or you would like it fully buildable with ghc --make ? Eliminating external deps is the most important thing, as that makes it much easier to try in a development compiler, or to compare 2 compilers. Apart from that, just making it as small as possible means that it is quicker to build, easier to see what is going on (in terms of both the source code, and the compiler debugging output), and makes it easy to add a regression test to the testsuite. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Dec 6 07:13:42 2009 From: trac at galois.com (GHC) Date: Sun Dec 6 06:48:12 2009 Subject: [GHC] #3732: GHC 6.10.4 compilation failure: libffi failed to compile In-Reply-To: <044.58f5b1bdc9b31199f5dc0a9924975019@localhost> References: <044.58f5b1bdc9b31199f5dc0a9924975019@localhost> Message-ID: <053.085e5ab66c27cb4d78499b7da544cbd2@localhost> #3732: GHC 6.10.4 compilation failure: libffi failed to compile ----------------------------------+----------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: ia64 Failure: Building GHC failed | ----------------------------------+----------------------------------------- Changes (by igloo): * difficulty: => Old description: > The libffi failed to compile with the error: > "configure: error: source directory already configured; run "make > distclean" there first" > > To solve this one must specify the full path when invoking the configure > script. > To do this the part of the "ghc-xxx/libffi/Makefile" should be changed > to: > > from > CC=$(WhatGccIsCalled) $(SHELL) configure \ > to > CC=$(WhatGccIsCalled) $(SHELL) `pwd`/configure \ New description: The libffi failed to compile with the error: "configure: error: source directory already configured; run "make distclean" there first" To solve this one must specify the full path when invoking the configure script. To do this the part of the "ghc-xxx/libffi/Makefile" should be changed to: from {{{ CC=$(WhatGccIsCalled) $(SHELL) configure \ }}} to {{{ CC=$(WhatGccIsCalled) $(SHELL) `pwd`/configure \ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Dec 6 07:19:53 2009 From: trac at galois.com (GHC) Date: Sun Dec 6 06:54:23 2009 Subject: [GHC] #3732: GHC 6.10.4 compilation failure: libffi failed to compile In-Reply-To: <044.58f5b1bdc9b31199f5dc0a9924975019@localhost> References: <044.58f5b1bdc9b31199f5dc0a9924975019@localhost> Message-ID: <053.1ec95995133a7011ab036581191ff5af@localhost> #3732: GHC 6.10.4 compilation failure: libffi failed to compile ----------------------------------+----------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: fixed | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: ia64 Failure: Building GHC failed | ----------------------------------+----------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: This shouldn't be necessary, as the command should expand to something like: {{{ CC=gcc sh configure }}} which will run the configure script in the current directory. I'm not sure what's gone wrong, but as the build system has been rewritten for 6.12 I'm going to assume it's been fixed. If you still have problems with 6.12, please reopen, and include the part of the `make` output where the command gets run, and the output of {{{ make show VALUE=SHELL }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Dec 6 07:33:28 2009 From: trac at galois.com (GHC) Date: Sun Dec 6 07:07:57 2009 Subject: [GHC] #3664: Ghc eats tremendous heaps of RAM in -prof build (highlighting-kate) In-Reply-To: <045.0f6b0943402daeb82291512e1fe74507@localhost> References: <045.0f6b0943402daeb82291512e1fe74507@localhost> Message-ID: <054.0f27b0510b8495023d6ecd0d37510995@localhost> #3664: Ghc eats tremendous heaps of RAM in -prof build (highlighting-kate) -------------------------------------------+-------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86_64 (amd64) Failure: Compile-time performance bug | -------------------------------------------+-------------------------------- Comment (by slyfox): > Eliminating external deps is the most important thing, as that makes it much easier to try in a development compiler, or to compare 2 compilers. > > Apart from that, just making it as small as possible means that it is quicker to build, easier to see what is going on (in terms of both the source code, and the compiler debugging output), and makes it easy to add a regression test to the testsuite. OK, attached sample does not depend on external stuff (12 .hs files, 9 of them are parsec-2 ones). Seems to need only compiler. I'm afraid I can't trim it down to 1 small file, it's very fragile and seems to depend on external inlining stuff. If I would know the nature of memory consumption - I might try to make syntetic test by hands. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Dec 6 10:41:39 2009 From: trac at galois.com (GHC) Date: Sun Dec 6 10:16:16 2009 Subject: [GHC] #2467: orphan instance warnings are badly behaved In-Reply-To: <045.75a28e8407597d8ed7d594d8f7eb5b3c@localhost> References: <045.75a28e8407597d8ed7d594d8f7eb5b3c@localhost> Message-ID: <054.c9e8d728b253dc4b9c19d2dca4163d5b@localhost> #2467: orphan instance warnings are badly behaved ---------------------------+------------------------------------------------ Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.8.2 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * milestone: 6.14.1 => _|_ Comment: The instances are now either removed, or their reason for existing is given in a comment, so 1. is done. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Dec 6 15:03:52 2009 From: trac at galois.com (GHC) Date: Sun Dec 6 14:38:30 2009 Subject: [GHC] #3330: Type checker hangs In-Reply-To: <060.111b0979bdfa1b272261462ee3c542d4@localhost> References: <060.111b0979bdfa1b272261462ee3c542d4@localhost> Message-ID: <069.1a508ace7a31791418f2ac7bb9058fa5@localhost> #3330: Type checker hangs --------------------------------------+------------------------------------- Reporter: MartijnVanSteenbergen | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler (Type checker) | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: x86_64 (amd64) Failure: Compile-time crash | --------------------------------------+------------------------------------- Changes (by byorgey): * failure: => Compile-time crash * version: 6.10.3 => 6.12.1 RC1 * os: MacOS X => Unknown/Multiple Comment: I think I've also tickled this bug, which appears to still exist in 6.12.1rc2. Here's a stripped-down version of the code that causes GHC to diverge for me: {{{ {-# LANGUAGE EmptyDataDecls, TypeFamilies, TypeOperators, GADTs, KindSignatures #-} data (f :+: g) x = Inl (f x) | Inr (g x) data R :: (* -> *) -> * where RSum :: R f -> R g -> R (f :+: g) class Rep f where rep :: R f instance (Rep f, Rep g) => Rep (f :+: g) where rep = RSum rep rep type family Der (f :: * -> *) :: * -> * type instance Der (f :+: g) = Der f :+: Der g plug :: Rep f => Der f x -> x -> f x plug = plug' rep where plug' :: R f -> Der f x -> x -> f x plug' (RSum rf rg) (Inl df) x = Inl (plug rf df x) }}} Note that this code has a bug; the call to plug in the last line ought to be plug' (and it works properly when fixed), but I would expect a type error instead of a diverging compiler. I'm classifying this as a "compile-time crash" since one bottom is as good as another. ;) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Dec 6 19:44:16 2009 From: trac at galois.com (GHC) Date: Sun Dec 6 19:18:51 2009 Subject: [GHC] #3714: Improve error message if an associated family declaration has excess parameters In-Reply-To: <046.1269d7611bd6a1dfa394e0799eb1571c@localhost> References: <046.1269d7611bd6a1dfa394e0799eb1571c@localhost> Message-ID: <055.9d1aafdddf88e79dedbb3cbab7456e4a@localhost> #3714: Improve error message if an associated family declaration has excess parameters ---------------------------+------------------------------------------------ Reporter: simonpj | Owner: chak Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by chak): * summary: Associated types missing useful functionality => Improve error message if an associated family declaration has excess parameters Comment: No, it's not a bug. The second example ought to be written: {{{ class C2 f where type T2 f :: * -> * op2 :: T2 f e -> Either e a }}} The parameters of an associated family declaration must be a subset of the class parameters as documented at [http://haskell.org/haskellwiki/GHC/Type_families#Associated_family_declarations_2]. However, remember that {{{ type family S1 a :: * -> * }}} and {{{ type family S2 a b :: * }}} are '''not''' the same thing. `S1` has one type index (and in each occurrence must be applied to at least one argument), whereas `S2` has two type indices (and in each occurrence must be applied to at least two type arguments). (BTW, I'm not saying that this is the only design that's possible, but it is what we decided to be most useful at the time.) However, the error message can certainly be improved! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Dec 6 21:25:07 2009 From: trac at galois.com (GHC) Date: Sun Dec 6 20:59:37 2009 Subject: [GHC] #3733: When I loaded a file and ran it, it gave a message asking me to submit a bug Message-ID: <046.6eb3b07bda483d4af283b08f7d4cde7a@localhost> #3733: When I loaded a file and ran it, it gave a message asking me to submit a bug ------------------------+--------------------------------------------------- Reporter: vtrajan | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Keywords: Os: Windows | Testcase: Architecture: x86 | Failure: None/Unknown ------------------------+--------------------------------------------------- I wrote the program evaluator1.hs from "Scheme Interpreter in 48 hours" tutorial. I loaded it into GHCi and ran Number 1. It gave a message: :panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-unknow-mingw32): loadObj: failed please report this as a GHC bug: http:... -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 7 03:47:17 2009 From: trac at galois.com (GHC) Date: Mon Dec 7 03:21:52 2009 Subject: [GHC] #3714: Improve error message if an associated family declaration has excess parameters In-Reply-To: <046.1269d7611bd6a1dfa394e0799eb1571c@localhost> References: <046.1269d7611bd6a1dfa394e0799eb1571c@localhost> Message-ID: <055.aed59041a2657d9de80199022b4c5430@localhost> #3714: Improve error message if an associated family declaration has excess parameters ---------------------------+------------------------------------------------ Reporter: simonpj | Owner: chak Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Comment (by simonpj): Oh yes, silly me. The point is that in a class instance declaration you only get to write ''one'' associated type instance declaration, so there is no point in having a type index that is not also a class index. The syntax for distinguishing type ''indices'' from ''type parameters'' is horrible, but it's hard to think of something better. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 7 03:52:33 2009 From: trac at galois.com (GHC) Date: Mon Dec 7 03:27:11 2009 Subject: [GHC] #3330: Type checker hangs In-Reply-To: <060.111b0979bdfa1b272261462ee3c542d4@localhost> References: <060.111b0979bdfa1b272261462ee3c542d4@localhost> Message-ID: <069.8389f13627a90ab557b7b248d4d28df5@localhost> #3330: Type checker hangs --------------------------------------+------------------------------------- Reporter: MartijnVanSteenbergen | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler (Type checker) | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: x86_64 (amd64) Failure: Compile-time crash | --------------------------------------+------------------------------------- Comment (by simonpj): Thanks for another very useful test case. I think it's going to have to wait for the glorious new constraint checker that Dimitrios and I are slowly (but actively) working on. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 7 07:08:39 2009 From: trac at galois.com (GHC) Date: Mon Dec 7 06:43:07 2009 Subject: [GHC] #3734: overlapping orphan instances behave like incoherent without warning/error Message-ID: <048.6b18fa394333a9e5056664f68dd78402@localhost> #3734: overlapping orphan instances behave like incoherent without warning/error ---------------------------------+------------------------------------------ Reporter: Liskni_si | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 6.10.4 | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Incorrect result at runtime ---------------------------------+------------------------------------------ Consider these three modules: {{{ module A where class (Show a) => A a data A' = A' deriving (Show) instance A A' data A'' = A'' deriving (Show) instance A A'' print_a :: (A a) => a -> IO () print_a a = print a }}} {{{ {-# LANGUAGE FlexibleInstances, OverlappingInstances #-} module B where import A data B a = B a deriving (Show) instance (A a) => A (B a) }}} {{{ {-# LANGUAGE FlexibleInstances, OverlappingInstances #-} module Main where import A import B instance Show (B A') where show _ = "kokodak" instance Show (B A'') where show _ = "brekeke" instance A (B A'') main :: IO () main = do print (B A') print_a (B A') putStrLn "" print (B A'') print_a (B A'') }}} Without understanding a thing about dictionaries, I would expect that if this actually compiles (which I now understand it should not), I'd get `"kokodak kokodak brekeke brekeke"` as output, but I got `"kokodak B A' brekeke brekeke"` instead. I figured that even though I redefined `Show (B A')`, the `A (B a)` instance was defined in module `B` and consisted of the original `Show` dictionary. If I move the `Show (B A')` instance to module B, ghc complains that the definition of `A (B a)` depends on the instatiation of `a` and refuses to compile it, unless I enable `IncoherentInstances`. The problem here is that if the `Show (B A')` instance is orphan, I get the `IncoherentInstances` behaviour for free without any warning or error, giving me the false feeling that the code is actually OK. Is it possible that ghc gives an error in this case, and may the documentation mention that Overlapping + Orphan => Incoherent? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 7 07:23:34 2009 From: trac at galois.com (GHC) Date: Mon Dec 7 06:58:02 2009 Subject: [GHC] #3735: GHC specialising instead of inlining Message-ID: <044.c1db61c13e480ce31d41efb4dfa50a9a@localhost> #3735: GHC specialising instead of inlining -----------------------+---------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Keywords: Os: Linux | Testcase: Architecture: x86 | Failure: Runtime performance bug -----------------------+---------------------------------------------------- In the attached module I demonstrate the following: mainMonolithic1Generator performs the same computation as mainMonolithic1Compose but the former is more than two times slower than latter. This is serious since in more complex signal processing programs this factor seems to multiply. I assume that the problem is that mixGen is not inlined. Instead GHC seems to have decided to specialise mixGen. In contrast to mainMonolithic1Compose, mainMonolithic1Generator uses a data type with existential quantification. But this alone is not the problem, since mainMonolithic0 and mainMonolithic0Generator run with the same speed. http://code.haskell.org/storablevector/speedtest/SpeedTestChorus.hs How can I tell GHC to prefer inlining to specialisation? How about a pragma like {-# INLINE FORCE #-} or so? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 7 07:23:57 2009 From: trac at galois.com (GHC) Date: Mon Dec 7 06:58:24 2009 Subject: [GHC] #3736: GHC specialising instead of inlining Message-ID: <044.6187e75fed543439fb0c0aaede8523f0@localhost> #3736: GHC specialising instead of inlining -----------------------+---------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Keywords: Os: Linux | Testcase: Architecture: x86 | Failure: Runtime performance bug -----------------------+---------------------------------------------------- In the attached module I demonstrate the following: mainMonolithic1Generator performs the same computation as mainMonolithic1Compose but the former is more than two times slower than latter. This is serious since in more complex signal processing programs this factor seems to multiply. I assume that the problem is that mixGen is not inlined. Instead GHC seems to have decided to specialise mixGen. In contrast to mainMonolithic1Compose, mainMonolithic1Generator uses a data type with existential quantification. But this alone is not the problem, since mainMonolithic0 and mainMonolithic0Generator run with the same speed. http://code.haskell.org/storablevector/speedtest/SpeedTestChorus.hs How can I tell GHC to prefer inlining to specialisation? How about a pragma like {-# INLINE FORCE #-} or so? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 7 08:18:34 2009 From: trac at galois.com (GHC) Date: Mon Dec 7 07:53:01 2009 Subject: [GHC] #3664: Ghc eats tremendous heaps of RAM in -prof build (highlighting-kate) In-Reply-To: <045.0f6b0943402daeb82291512e1fe74507@localhost> References: <045.0f6b0943402daeb82291512e1fe74507@localhost> Message-ID: <054.126b7e9aa185c8e763027466156a4b8f@localhost> #3664: Ghc eats tremendous heaps of RAM in -prof build (highlighting-kate) -------------------------------------------+-------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86_64 (amd64) Failure: Compile-time performance bug | -------------------------------------------+-------------------------------- Comment (by simonpj): Thanks for the nice test case. Happily the performance hole is fixed in the HEAD, I believe by my recent patch to `FloatOut`: {{{ Mon Dec 7 08:32:46 GMT 2009 simonpj@microsoft.com * Fix a nasty (and long-standing) FloatOut performance bug The effect was that, in deeply-nested applications, FloatOut would take quadratic time. A good example was compiling programs/barton-mangler-bug/Expected.hs in which FloatOut had a visible pause of a couple of seconds! Profiling showed that 40% of the entire compile time was being consumbed by the single function partitionByMajorLevel. The bug was that the floating bindings (type FloatBinds) was kept as a list, which was partitioned at each binding site. In programs with deeply nested lists, such as e1 : e2 : e3 : .... : e5000 : [] this led to quadratic behaviour. The solution is to use a proper finite-map representation; see the new definition of FloatBinds near the bottom of FloatOut. M ./compiler/simplCore/FloatOut.lhs -76 +126 }}} Here are the stats for your run: {{{ 15,066,832,088 bytes allocated in the heap 2,907,321,496 bytes copied during GC 188,073,960 bytes maximum residency (28 sample(s)) 6,128,376 bytes maximum slop 412 MB total memory in use (7 MB lost due to fragmentation) }}} Note the residency is 188M, still large but more manageable. Because 6.12.1 is otherwise ready to go we were planning to put this patch 6.12.2, rather than risk destabilising 6.12.1 (the patch has not been tested nearly as thoroughly as the rest of 6.12.1). Can you use the HEAD meanwhile? I'm leaving the bug open just for this question to be resolved. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 7 08:20:01 2009 From: trac at galois.com (GHC) Date: Mon Dec 7 07:54:31 2009 Subject: [GHC] #3655: Performance regression relative to 6.10 In-Reply-To: <047.de41e91ed6bceb6d2068db2adb01f317@localhost> References: <047.de41e91ed6bceb6d2068db2adb01f317@localhost> Message-ID: <056.916581a899aff533856df0dcd62df675@localhost> #3655: Performance regression relative to 6.10 --------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 6.12.2 Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Runtime performance bug | --------------------------------------+------------------------------------- Changes (by simonpj): * owner: => simonpj -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 7 10:09:06 2009 From: trac at galois.com (GHC) Date: Mon Dec 7 09:43:34 2009 Subject: [GHC] #3664: Ghc eats tremendous heaps of RAM in -prof build (highlighting-kate) In-Reply-To: <045.0f6b0943402daeb82291512e1fe74507@localhost> References: <045.0f6b0943402daeb82291512e1fe74507@localhost> Message-ID: <054.928f96ef4e7a6599b56ca3cdaf7bbcb8@localhost> #3664: Ghc eats tremendous heaps of RAM in -prof build (highlighting-kate) -------------------------------------------+-------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86_64 (amd64) Failure: Compile-time performance bug | -------------------------------------------+-------------------------------- Comment (by slyfox): Replying to [comment:7 simonpj]: > Note the residency is 188M, still large but more manageable. > > Because 6.12.1 is otherwise ready to go we were planning to put this patch 6.12.2, rather than risk destabilising 6.12.1 (the patch has not been tested nearly as thoroughly as the rest of 6.12.1). Can you use the HEAD meanwhile? > > I'm leaving the bug open just for this question to be resolved. Sure. I'll wait 6.12.2. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 7 10:11:31 2009 From: trac at galois.com (GHC) Date: Mon Dec 7 09:45:59 2009 Subject: [GHC] #3735: GHC specialising instead of inlining In-Reply-To: <044.c1db61c13e480ce31d41efb4dfa50a9a@localhost> References: <044.c1db61c13e480ce31d41efb4dfa50a9a@localhost> Message-ID: <053.7b4be83b22be6ab20c91a4bf71c81379@localhost> #3735: GHC specialising instead of inlining --------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: duplicate | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86 Failure: Runtime performance bug | --------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * difficulty: => * resolution: => duplicate Comment: Dup of #3736 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 7 10:13:34 2009 From: trac at galois.com (GHC) Date: Mon Dec 7 09:48:02 2009 Subject: [GHC] #3736: GHC specialising instead of inlining In-Reply-To: <044.6187e75fed543439fb0c0aaede8523f0@localhost> References: <044.6187e75fed543439fb0c0aaede8523f0@localhost> Message-ID: <053.fa6c52fed5181c573f8d6627da6a61c7@localhost> #3736: GHC specialising instead of inlining --------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86 Failure: Runtime performance bug | --------------------------------------+------------------------------------- Changes (by simonpj): * difficulty: => Comment: I think agree that this should just work. I can't reproduce this because I can't find `Data.StorableVector.Lazy.Builder`. Can you make the test case more self-contained? It's not the end of the world if it depends on a Hackage package, but if so say which version. And I think in this case it depends on something you have not supplied. Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 7 10:19:04 2009 From: trac at galois.com (GHC) Date: Mon Dec 7 09:53:41 2009 Subject: [GHC] #3718: Can not bootstrap using 6.12.1-rc2 In-Reply-To: <044.e3fbd58d8bc98f8a8a505dad8aa3453a@localhost> References: <044.e3fbd58d8bc98f8a8a505dad8aa3453a@localhost> Message-ID: <053.0860d4a738201d902866e7f0f2c1be4a@localhost> #3718: Can not bootstrap using 6.12.1-rc2 ----------------------------------+----------------------------------------- Reporter: masao | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 6.12.1 RC1 Resolution: invalid | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Building GHC failed | ----------------------------------+----------------------------------------- Changes (by simonmar): * status: new => closed * difficulty: => * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 7 10:20:14 2009 From: trac at galois.com (GHC) Date: Mon Dec 7 09:54:41 2009 Subject: [GHC] #3720: unknown symbol `_GLOBAL_OFFSET_TABLE_' when loading module In-Reply-To: <044.c8fe00d0df86676aef8470e80da77abf@localhost> References: <044.c8fe00d0df86676aef8470e80da77abf@localhost> Message-ID: <053.c4a8fbe7519a5ba5d2c26691158555fb@localhost> #3720: unknown symbol `_GLOBAL_OFFSET_TABLE_' when loading module ---------------------+------------------------------------------------------ Reporter: fasta | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Other | ---------------------+------------------------------------------------------ Changes (by simonmar): * difficulty: => Comment: Could you provide a list of instructions for reproducing the error please? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 7 10:26:25 2009 From: trac at galois.com (GHC) Date: Mon Dec 7 10:00:53 2009 Subject: [GHC] #3721: Can't install base-4.0.0.0 !! In-Reply-To: <044.ce5a38d30c19ad72f7315d28514e5c11@localhost> References: <044.ce5a38d30c19ad72f7315d28514e5c11@localhost> Message-ID: <053.eb7efec872d02a51ecf49eb8ba1b8768@localhost> #3721: Can't install base-4.0.0.0 !! ---------------------------+------------------------------------------------ Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: wontfix | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by simonmar): * status: new => closed * difficulty: => * resolution: => wontfix Comment: If you need base-4, then install a newer version of GHC. With a recent GHC you get: {{{ > runhaskell -f ghc-6.12.0.20091011 Setup.hs install Setup.hs:1:0: attempting to use module `Prelude' (./Prelude.hs) which is not loaded }}} still quite obscure, but at least not a panic. If you really want to build the base package, you need to either use cabal-install, or compile `Setup.hs` separately. But then you'll probably run into #3496. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 7 10:45:19 2009 From: trac at galois.com (GHC) Date: Mon Dec 7 10:19:46 2009 Subject: [GHC] #3702: deriving for GADTs In-Reply-To: <047.6f0e8d7da833492fd6dde2b2297e185b@localhost> References: <047.6f0e8d7da833492fd6dde2b2297e185b@localhost> Message-ID: <056.ab76a2dd6d1430404ec7b9958ea57545@localhost> #3702: deriving for GADTs ----------------------------+----------------------------------------------- Reporter: rwbarton | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: Component: Documentation | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ----------------------------+----------------------------------------------- Changes (by simonpj): * owner: => igloo * difficulty: => * type: feature request => merge Comment: Good idea. I improved the error message {{{ Mon Dec 7 13:08:50 GMT 2009 simonpj@microsoft.com * Tidy up deriving error messages I did this in response to a suggestion in Trac #3702 M ./compiler/typecheck/TcDeriv.lhs -36 +48 }}} Ian: pls add to release notes. Maybe merge this patch, if (but only if) convenient. Then close Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 7 10:48:17 2009 From: trac at galois.com (GHC) Date: Mon Dec 7 10:22:46 2009 Subject: [GHC] #3734: overlapping orphan instances behave like incoherent without warning/error In-Reply-To: <048.6b18fa394333a9e5056664f68dd78402@localhost> References: <048.6b18fa394333a9e5056664f68dd78402@localhost> Message-ID: <057.872f6f5f0ca93c83e47478f19ca28282@localhost> #3734: overlapping orphan instances behave like incoherent without warning/error ------------------------------------------+--------------------------------- Reporter: Liskni_si | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.10.4 Resolution: fixed | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Incorrect result at runtime | ------------------------------------------+--------------------------------- Changes (by simonpj): * status: new => closed * difficulty: => * resolution: => fixed Comment: Good point. But it's worse than that. You can get incoherence from overlap without even orphans. I've added an explanation to the user guide, reproduced below: {{{ Warning: overlapping instances must be used with care. They can give rise to incoherence (ie different instance choices are made in different parts of the program) even without . Consider: {-# LANGUAGE OverlappingInstances #-} module Help where class MyShow a where myshow :: a -> String instance MyShow a => MyShow [a] where myshow xs = concatMap myshow xs showHelp :: MyShow a => [a] -> String showHelp xs = myshow xs {-# LANGUAGE FlexibleInstances, OverlappingInstances #-} module Main where import Help data T = MkT instance MyShow T where myshow x = "Used generic instance" instance MyShow [T] where myshow xs = "Used more specific instance" main = do { print (myshow [MkT]); print (showHelp [MkT]) } In function showHelp GHC sees no overlapping instances, and so uses the MyShow [a] instance without complaint. In the call to myshow in main, GHC resolves the MyShow [T] constraint using the overlapping instance declaration in module Main. As a result, the program prints "Used more specific instance" "Used generic instance" (An alternative possible behaviour, not currently implemented, would be to reject module Help on the grounds that a later instance declaration might overlap the local one.) }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 7 10:59:06 2009 From: trac at galois.com (GHC) Date: Mon Dec 7 10:33:31 2009 Subject: [GHC] #3734: overlapping orphan instances behave like incoherent without warning/error In-Reply-To: <048.6b18fa394333a9e5056664f68dd78402@localhost> References: <048.6b18fa394333a9e5056664f68dd78402@localhost> Message-ID: <057.7851ab8c63e64fe23f192f51f163d55d@localhost> #3734: overlapping orphan instances behave like incoherent without warning/error ------------------------------------------+--------------------------------- Reporter: Liskni_si | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.10.4 Resolution: fixed | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Incorrect result at runtime | ------------------------------------------+--------------------------------- Comment (by Liskni_si): Awesome, thank you for the quick fix. :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 7 13:03:24 2009 From: trac at galois.com (GHC) Date: Mon Dec 7 12:37:49 2009 Subject: [GHC] #3736: GHC specialising instead of inlining In-Reply-To: <044.6187e75fed543439fb0c0aaede8523f0@localhost> References: <044.6187e75fed543439fb0c0aaede8523f0@localhost> Message-ID: <053.a5bccf9b51a026fdc2cacae910219da2@localhost> #3736: GHC specialising instead of inlining --------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86 Failure: Runtime performance bug | --------------------------------------+------------------------------------- Comment (by guest): Thank you for looking into this issue! The example works with Darcs-HEAD of http://code.haskell.org/storablevector/ This version is named 0.2.5. I may also tag and upload this version to Hackage in order to make the problem reproducable in future. The StorableVector construction using mainChunky0Builder is also three times slower than its counterpart mainChunky0 and I have no idea why. Maybe I should file a separate ticket for that, but I'm uncertain whether this is my fault or GHC's. Btw. don't miss to listen to the 40 MB of cool sound that those functions generate using play -r 44100 speed.f32 (play is part of the SoX project) :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 7 13:05:26 2009 From: trac at galois.com (GHC) Date: Mon Dec 7 12:39:53 2009 Subject: [GHC] #3736: GHC specialising instead of inlining In-Reply-To: <044.6187e75fed543439fb0c0aaede8523f0@localhost> References: <044.6187e75fed543439fb0c0aaede8523f0@localhost> Message-ID: <053.80096c8e49e1b6522a19c637427f18db@localhost> #3736: GHC specialising instead of inlining --------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86 Failure: Runtime performance bug | --------------------------------------+------------------------------------- Comment (by guest): I assume that JHC's SUPERINLINE pragma means the same as my suggested INLINE FORCE: http://repetae.net/computer/jhc/manual.html#pragmas -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 7 13:24:42 2009 From: trac at galois.com (GHC) Date: Mon Dec 7 12:59:11 2009 Subject: [GHC] #3678: Build fails when adding -fexpose-all-unfoldings to GhcStage2HcOpts In-Reply-To: <043.e2ab445e857a0d9778b3347a024af8d1@localhost> References: <043.e2ab445e857a0d9778b3347a024af8d1@localhost> Message-ID: <052.b9abf2d9689bb6c39657c9bf3c0196e2@localhost> #3678: Build fails when adding -fexpose-all-unfoldings to GhcStage2HcOpts ----------------------------------+----------------------------------------- Reporter: pejo | Owner: Type: bug | Status: new Priority: high | Milestone: 6.14.1 Component: Build System | Version: 6.13 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Building GHC failed | ----------------------------------+----------------------------------------- Changes (by batterseapower): * cc: batterseapower@hotmail.com (added) Comment: When might this be fixed? I'm eager to use -fexpose-all-unfoldings, and my build-system fu probably isn't strong enough to do the untangling you refer to... -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 7 16:10:26 2009 From: trac at galois.com (GHC) Date: Mon Dec 7 15:44:52 2009 Subject: [GHC] #3737: inlining happens on foldl1 and does not happen on direct application of combinator Message-ID: <044.fddf7c34bfc36e2b8667f9dd59d27ab6@localhost> #3737: inlining happens on foldl1 and does not happen on direct application of combinator -----------------------+---------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Keywords: Os: Linux | Testcase: Architecture: x86 | Failure: Runtime performance bug -----------------------+---------------------------------------------------- This is certainly related to #3736. The code can be found at: http://code.haskell.org/storablevector/speedtest/SpeedTestChorus.hs Look into functions mainChunky1MixFold and mainChunky1MixFlat. The first one does {{{ foldl1 mixVec $ map (uncurry tone0) $ [(f0,p0), (f1,p1), (f2,p2)] }}} and generator0Freq gets inlined and is fast. (1.4 seconds) The second one does {{{ tone0 f0 p0 `mixVec` tone0 f1 p1 `mixVec` tone0 f2 p2 }}} and generator0Freq is not inlined and this is slower (2.0 seconds). (Inlining or specialising mixVec doesn't change the numbers. I tried that because I first thought, mixVec would be the problem.) But we cannot derive from it, that using 'foldl1' is better in general. Since if you compare mainMonolithic1GeneratorFold with mainMonolithic1Generator, you find that the fold version is slower (2.8 seconds vs. 2.0 seconds). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 7 20:03:05 2009 From: trac at galois.com (GHC) Date: Mon Dec 7 19:37:32 2009 Subject: [GHC] #3738: INLINE function loses unfolding Message-ID: <041.d227e4e2f98d3171cf4e574a410067a1@localhost> #3738: INLINE function loses unfolding ---------------------------------+------------------------------------------ Reporter: rl | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.13 | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Runtime performance bug ---------------------------------+------------------------------------------ Small program: {{{ foo :: Num a => [a] -> a {-# INLINE foo #-} foo = go 0 where go m (n:ns) = m `seq` go (m+n) ns go m [] = m bar :: [Int] -> Int {-# INLINE bar #-} bar = foo }}} Here is what `bar` looks like in the interface file: {{{ a6de4c46e53e565ed25ab5a38910e9cb $wgo :: GHC.Prim.Int# -> [GHC.Types.Int] -> GHC.Prim.Int# {- Arity: 2, HasNoCafRefs, Strictness: LS -} 6838e3faa095285614477ebc92f54987 bar :: [GHC.Types.Int] -> GHC.Types.Int {- Arity: 1, HasNoCafRefs, Strictness: Sm, Inline: INLINE, Unfolding: InlineRule: (arity 0 False) (Foo.bar_foo) -} 5d06906ae99b9aefa1c6d251c3f2fc46 bar_foo :: [GHC.Types.Int] -> GHC.Types.Int {- Arity: 1, HasNoCafRefs, Strictness: Sm, Unfolding: InlineRule: (arity 0 True) (\ w :: [GHC.Types.Int] -> case @ GHC.Types.Int Foo.$wgo 0 w of ww { DEFAULT -> GHC.Types.I# ww }) -} }}} Note that the loop has disappeared from `bar`'s unfolding. Also, `bar_foo` doesn't have an INLINE pragma. Incidentally, GHC specialises `foo` here and the specialisation doesn't get an INLINE pragma, either: {{{ foo :: forall a. GHC.Num.Num a => [a] -> a {- Arity: 1, HasNoCafRefs, Strictness: L, Inline: INLINE, Unfolding: InlineRule: (arity 1 False) ... -} foo_$sfoo :: [GHC.Types.Int] -> GHC.Types.Int {- Arity: 1, HasNoCafRefs, Strictness: Sm, Unfolding: InlineRule: (arity 0 False) ... -} "SPEC Foo.foo [GHC.Types.Int]" ALWAYS forall $dNum :: GHC.Num.Num GHC.Types.Int Foo.foo @ GHC.Types.Int $dNum = Foo.foo_$sfoo }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 8 01:08:40 2009 From: trac at galois.com (GHC) Date: Tue Dec 8 00:43:07 2009 Subject: [GHC] #3065: Reorder tests in quot to improve code In-Reply-To: <046.819ea32d4c70bd7d14e7ef168534bbea@localhost> References: <046.819ea32d4c70bd7d14e7ef168534bbea@localhost> Message-ID: <055.9baec836492d848c19b9845ddf9fc0c4@localhost> #3065: Reorder tests in quot to improve code --------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: libraries/base | Version: 6.10.1 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Runtime performance bug | --------------------------------------+------------------------------------- Comment (by rl): Bumping this ticket as using any kind of integer division in an inner loop tends to create unnecessary join points and thus interferes with array fusion. I don't understand why there is an overflow test at all. I certainly wouldn't expect there to be one as `Int` arithmetic is usually unchecked. The report says in 6.4.2: The quot, rem, div, and mod class methods satisfy these laws if y is non-zero: {{{ (x `quot` y)*y + (x `rem` y) == x (x `div` y)*y + (x `mod` y) == x }}} This seems to imply that {{{minBound `quot` (-1)}}} should overflow instead of raising an exception. Doesn't the current behaviour violate the language definition? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 8 03:34:21 2009 From: trac at galois.com (GHC) Date: Tue Dec 8 03:08:47 2009 Subject: [GHC] #3065: Reorder tests in quot to improve code In-Reply-To: <046.819ea32d4c70bd7d14e7ef168534bbea@localhost> References: <046.819ea32d4c70bd7d14e7ef168534bbea@localhost> Message-ID: <055.959a48ecbee551dd9861009b20a6744f@localhost> #3065: Reorder tests in quot to improve code --------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: libraries/base | Version: 6.10.1 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Runtime performance bug | --------------------------------------+------------------------------------- Comment (by simonpj): This ticket badly needs someone to "own" it, propose what to do, and measure it. Any volunteers? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 8 03:52:45 2009 From: trac at galois.com (GHC) Date: Tue Dec 8 03:27:10 2009 Subject: [GHC] #3678: Build fails when adding -fexpose-all-unfoldings to GhcStage2HcOpts In-Reply-To: <043.e2ab445e857a0d9778b3347a024af8d1@localhost> References: <043.e2ab445e857a0d9778b3347a024af8d1@localhost> Message-ID: <052.e38764e0a0305cbb03963b8fc3b2dcdd@localhost> #3678: Build fails when adding -fexpose-all-unfoldings to GhcStage2HcOpts ----------------------------------+----------------------------------------- Reporter: pejo | Owner: Type: bug | Status: new Priority: high | Milestone: 6.14.1 Component: Build System | Version: 6.13 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Building GHC failed | ----------------------------------+----------------------------------------- Comment (by simonpj): I bet Ian can suggest some hack to get you going. But I'm still unclear why you need compile GHC itself with `-fexpose-all-unfoldings`. The libraries, yes. But GHC? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 8 05:49:13 2009 From: trac at galois.com (GHC) Date: Tue Dec 8 05:23:40 2009 Subject: [GHC] #3703: -ddump-rules does not list all rules in effect In-Reply-To: <046.cbef6970fc7549dd0b91f6f53e79c1c1@localhost> References: <046.cbef6970fc7549dd0b91f6f53e79c1c1@localhost> Message-ID: <055.6732214fe967feafe5f83a5dc6193f07@localhost> #3703: -ddump-rules does not list all rules in effect ---------------------------+------------------------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86_64 (amd64) Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by simonpj): * difficulty: => Comment: Right. `-ddump-rules` shows precisely the rules defined ''in this module'', not rules imported from elsewhere. I've changed the displayed headings to: {{{ Local rules for local Ids Local rules for imported Ids }}} The user manual already mentions `-ddump-simpl-stats` here: http://www.haskell.org/ghc/docs/latest/html/users_guide/rewrite- rules.html#id540463. I've clarified the explanation for `ddump-rules`, and added a cross reference to this section from the flag section http://www.haskell.org/ghc/docs/latest/html/users_guide/options- debugging.html. I hope that'll help anyway. Patch coming. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 8 06:01:30 2009 From: trac at galois.com (GHC) Date: Tue Dec 8 05:35:54 2009 Subject: [GHC] #3065: Reorder tests in quot to improve code In-Reply-To: <046.819ea32d4c70bd7d14e7ef168534bbea@localhost> References: <046.819ea32d4c70bd7d14e7ef168534bbea@localhost> Message-ID: <055.2131e3532eb8b03afd4633c60d5d7dae@localhost> #3065: Reorder tests in quot to improve code --------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: libraries/base | Version: 6.10.1 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Runtime performance bug | --------------------------------------+------------------------------------- Comment (by igloo): See #1042 for why we need a test, and why we decided to raise an exception rather than returning a value. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 8 06:36:43 2009 From: trac at galois.com (GHC) Date: Tue Dec 8 06:11:10 2009 Subject: [GHC] #3065: Reorder tests in quot to improve code In-Reply-To: <046.819ea32d4c70bd7d14e7ef168534bbea@localhost> References: <046.819ea32d4c70bd7d14e7ef168534bbea@localhost> Message-ID: <055.48537cb75954f709466cb53b3c7c0d49@localhost> #3065: Reorder tests in quot to improve code --------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: libraries/base | Version: 6.10.1 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Runtime performance bug | --------------------------------------+------------------------------------- Comment (by rl): I see. I guess the problem with #1042 was that x86 raises an exception on int division overflow. IMO the right thing to do here is to use more bits for division in the generated code. This is what gcc does, for instance. I really don't like the overflow checks. They are inconsistent with the rest of `Int` arithmetic and can have a big impact on the performance of tight loops. I propose to get rid of them. This would require a patch to base which is easy to do (I can do that) and a change to the NCG which is probably a bit harder (I have no idea how to do this). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 8 07:41:29 2009 From: trac at galois.com (GHC) Date: Tue Dec 8 07:15:53 2009 Subject: [GHC] #3702: deriving for GADTs In-Reply-To: <047.6f0e8d7da833492fd6dde2b2297e185b@localhost> References: <047.6f0e8d7da833492fd6dde2b2297e185b@localhost> Message-ID: <056.ceffe00939bfad975c521f0e55317723@localhost> #3702: deriving for GADTs ----------------------------+----------------------------------------------- Reporter: rwbarton | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 6.12.1 RC1 Resolution: fixed | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ----------------------------+----------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Release note added. Patch not merged as it didn't go cleanly. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 8 07:41:48 2009 From: trac at galois.com (GHC) Date: Tue Dec 8 07:16:16 2009 Subject: [GHC] #2978: Add support for more characters to UnicodeSyntax In-Reply-To: <045.01e065f460d6968a8d3a0a8de34723f0@localhost> References: <045.01e065f460d6968a8d3a0a8de34723f0@localhost> Message-ID: <054.754fd5eeb1de7c0161c1e34987119643@localhost> #2978: Add support for more characters to UnicodeSyntax ---------------------------+------------------------------------------------ Reporter: porges | Owner: igloo Type: merge | Status: closed Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.10.1 Resolution: fixed | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Too late for 6.12.1, so will wait for 6.14.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 8 08:01:17 2009 From: trac at galois.com (GHC) Date: Tue Dec 8 07:35:47 2009 Subject: [GHC] #3714: Improve error message if an associated family declaration has excess parameters In-Reply-To: <046.1269d7611bd6a1dfa394e0799eb1571c@localhost> References: <046.1269d7611bd6a1dfa394e0799eb1571c@localhost> Message-ID: <055.1b86bd6aed5e90e452d51e7cf92eee50@localhost> #3714: Improve error message if an associated family declaration has excess parameters ---------------------------+------------------------------------------------ Reporter: simonpj | Owner: chak Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Comment (by MartijnVanSteenbergen): Moving the type index {{{e}}} to the right of the {{{::}}}?turning it into a type parameter, like Manuel suggests?complicates writing certain instances. Before I could write: {{{ type instance T2 () e = e -> Bool }}} But now I have to write: {{{ instance C2 () where type T2 () = T2Unit newtype T2Unit e = T2Unit (e -> Bool) }}} introducing a newtype whenever the type is not directly eta-reducible. In my case this defeats the purpose of writing these instances, as the goal is to derive a ''simpler'' type from a generic representation of a datatype (instances for generic building blocks), not a more complicated one (with newtypes that weren't necessary before). Just to be clear, there isn't really a problem, because I can just leave the type family outside the class. So the actual question here is: why are [type family inside type class] and [multiple family indices for writing type lambdas] sometimes mutually exclusive? Thanks, Martijn. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 8 08:12:43 2009 From: trac at galois.com (GHC) Date: Tue Dec 8 07:47:06 2009 Subject: [GHC] #3065: Reorder tests in quot to improve code In-Reply-To: <046.819ea32d4c70bd7d14e7ef168534bbea@localhost> References: <046.819ea32d4c70bd7d14e7ef168534bbea@localhost> Message-ID: <055.fba1fd422c21590d9ad248fe62f505ac@localhost> #3065: Reorder tests in quot to improve code --------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: libraries/base | Version: 6.10.1 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Runtime performance bug | --------------------------------------+------------------------------------- Comment (by simonmar): Replying to [comment:6 rl]: > I see. I guess the problem with #1042 was that x86 raises an exception on int division overflow. IMO the right thing to do here is to use more bits for division in the generated code. This is what gcc does, for instance. Are you sure gcc does this? Trying the example from #1042, it generates a floating point exception: {{{ $ cat 1042.c #include main () { int i = -2147483648; int j = -1; int k = i / j; printf("%d\n", k); } $ gcc 1042.c --std=c99 1042.c:3: warning: return type defaults to ?int? $ ./a.out [1] 18136 floating point exception (core dumped) ./a.out }}} I'm not sure if its possible to do a division with a 64-bit result on 32-bit x86: the `idivl` instruction takes a 64-bit divident, but gives you a 32-bit quotient and remainder. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 8 08:14:36 2009 From: trac at galois.com (GHC) Date: Tue Dec 8 07:49:01 2009 Subject: [GHC] #3710: WriteFile: invalid argument (The handle is invalid.) In-Reply-To: <049.64f91bfcc534a4ca7b7a2b4fe6766e23@localhost> References: <049.64f91bfcc534a4ca7b7a2b4fe6766e23@localhost> Message-ID: <058.3dc6903bb6870dcc40759ff159a5d0d4@localhost> #3710: WriteFile: invalid argument (The handle is invalid.) ------------------------------------------+--------------------------------- Reporter: dherington | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 6.10.4 Resolution: invalid | Keywords: garbage collector Difficulty: | Os: Windows Testcase: | Architecture: x86 Failure: Incorrect result at runtime | ------------------------------------------+--------------------------------- Changes (by simonmar): * difficulty: => Comment: Thanks for closing the ticket! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 8 08:19:28 2009 From: trac at galois.com (GHC) Date: Tue Dec 8 07:53:53 2009 Subject: [GHC] #3719: Literate code with # In-Reply-To: <046.119383e131eabeee5d5ffb7da02e279e@localhost> References: <046.119383e131eabeee5d5ffb7da02e279e@localhost> Message-ID: <055.ec163ab41d866d77f6fad818e94f3dca@localhost> #3719: Literate code with # ----------------------------------------+----------------------------------- Reporter: zenzike | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Parser) | Version: 6.10.4 Resolution: wontfix | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: GHC rejects valid program | ----------------------------------------+----------------------------------- Comment (by simonmar): Replying to [comment:4 duncan]: > Shouldn't we be running CPP before unlit? It's always been done this way around, and I imagine the reason for it has been lost in the mists of time. Maybe we'd discover why if we tried to switch them around... -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 8 09:22:40 2009 From: trac at galois.com (GHC) Date: Tue Dec 8 08:57:11 2009 Subject: [GHC] #3065: Reorder tests in quot to improve code In-Reply-To: <046.819ea32d4c70bd7d14e7ef168534bbea@localhost> References: <046.819ea32d4c70bd7d14e7ef168534bbea@localhost> Message-ID: <055.d40352cc4b42c95515ca7bd1756ef583@localhost> #3065: Reorder tests in quot to improve code --------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: libraries/base | Version: 6.10.1 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Runtime performance bug | --------------------------------------+------------------------------------- Comment (by rl): Doh. Your program prints -2147483648 with -O2 (which is what I tried) but that's only because of gcc's constant folding. You are right that it traps if it doesn't see the constants. I thought it handled this differently, sorry for the confusion. However, that doesn't really change my opinion. If x86 doesn't have a 64-bit div instruction, then I think that having the NCG insert the necessary test when generating code for `quotInt#` or a calling a 64-bit div subroutine would result in much better code in the vast majority of cases. Exposing the test to GHC really tends to break loop performance. It also imposes a performance penalty on signed types smaller than `Int` which would work just fine without the test. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 8 09:50:16 2009 From: trac at galois.com (GHC) Date: Tue Dec 8 09:24:39 2009 Subject: [GHC] #3678: Build fails when adding -fexpose-all-unfoldings to GhcStage2HcOpts In-Reply-To: <043.e2ab445e857a0d9778b3347a024af8d1@localhost> References: <043.e2ab445e857a0d9778b3347a024af8d1@localhost> Message-ID: <052.e7bb2ffcc94ccc85e4f129421a5fd218@localhost> #3678: Build fails when adding -fexpose-all-unfoldings to GhcStage2HcOpts ----------------------------------+----------------------------------------- Reporter: pejo | Owner: Type: bug | Status: new Priority: high | Milestone: 6.14.1 Component: Build System | Version: 6.13 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Building GHC failed | ----------------------------------+----------------------------------------- Changes (by batterseapower): * cc: batterseapower@hotmail.com (removed) Comment: Er, yes - you're right. That should be GhcLibHcOpts = -fexpose-all- unfoldings, NOT GhcStage2HcOpts - that will do it for me. Sorry for the noise! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 8 14:22:24 2009 From: trac at galois.com (GHC) Date: Tue Dec 8 13:56:48 2009 Subject: [GHC] #3678: Build fails when adding -fexpose-all-unfoldings to GhcStage2HcOpts In-Reply-To: <043.e2ab445e857a0d9778b3347a024af8d1@localhost> References: <043.e2ab445e857a0d9778b3347a024af8d1@localhost> Message-ID: <052.405470206e4c2664b1754c5c50ec9936@localhost> #3678: Build fails when adding -fexpose-all-unfoldings to GhcStage2HcOpts ----------------------------------+----------------------------------------- Reporter: pejo | Owner: Type: bug | Status: new Priority: high | Milestone: 6.14.1 Component: Build System | Version: 6.13 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Building GHC failed | ----------------------------------+----------------------------------------- Comment (by pejo): Building with GhcLibHcOpts works for me as well now, I'm not sure what I did for that to fail the first time, sorry. The priority could be lowered since this thing should mainly be useful to someone doing whole-program analysis/optimization on ghc itself. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 9 03:35:07 2009 From: trac at galois.com (GHC) Date: Wed Dec 9 03:09:35 2009 Subject: [GHC] #3714: Improve error message if an associated family declaration has excess parameters In-Reply-To: <046.1269d7611bd6a1dfa394e0799eb1571c@localhost> References: <046.1269d7611bd6a1dfa394e0799eb1571c@localhost> Message-ID: <055.9039e3a4de5cf59e4ba2a49371ec1ad5@localhost> #3714: Improve error message if an associated family declaration has excess parameters ---------------------------+------------------------------------------------ Reporter: simonpj | Owner: chak Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Comment (by simonpj): I'm getting there slowly. If you write {{{ type family T1 f :: * -> * -- T1 has one type index parameter type instance T1 [f] e = e }}} you get the error {{{ Tf.hs:7:0: Number of parameters must match family declaration; expected 1 In the type synonym instance declaration for `T1' }}} Now I think Martijn is actually doing this {{{ type family T2 f e :: * -- T2 has two type indices, f and e type instance T2 [f] e = e }}} This means that `T2` gets arity 2, and has two type indices. In principle you could give another `type instance` that dispatches on the second parameter: {{{ type instance T2 f Char = [f] }}} although I don't think Martijn intends that. Returning to `T1`, could we reasonably expect to declare a `type instance` with two parameters like this? {{{ type instance T1 [f] e = e }}} No, we could not. T1 is declared to have arity 1, so GHC ensures that it is saturated (appears applied to one argument). So it'd be fine to write the type `Monad (T [f])` for exmaple. But with the above instance, `T [f]` is in effect a type synonym; or if you like `T [f]` is `\e.e`. So it should not appear un-saturated. So T1's arity depends on its argument. This is not good. That's the reason for the rule. However, if we had a way to distinguish type indices from type parameters, we could say {{{ type family T3 f !e :: * -- The ! indicates a type parameter (not an index) type instance T3 [f] e = e }}} This would say * `T3` has arity 2 and must always appear applied to two arguments * Only `f` is an index, so only `f` can be instantiated in a `type instance` Note that the indices would not necessarily be the first parameters, although they usually will be. This would extend naturally to associated types, so you could write this, just as Martijn wishes: {{{ class C f where type T4 f !e :: * }}} Interesting. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From stefan at cs.uu.nl Wed Dec 9 03:42:04 2009 From: stefan at cs.uu.nl (Stefan Holdermans) Date: Wed Dec 9 03:16:25 2009 Subject: [GHC] #3714: Improve error message if an associated family declaration has excess parameters In-Reply-To: <055.9039e3a4de5cf59e4ba2a49371ec1ad5@localhost> References: <046.1269d7611bd6a1dfa394e0799eb1571c@localhost> <055.9039e3a4de5cf59e4ba2a49371ec1ad5@localhost> Message-ID: <72FCCB49-8A15-4D46-9D3D-87DDA17A7B3D@cs.uu.nl> Simon, Regarding distinguishing between type indices and parameters, you suggested: > type family T3 f !e :: * -- The ! indicates a type parameter > (not > an index) I'd rather have indices, rather than parameters, explicated by mean of syntax. This seems more consistent with ordinary type declarations. On paper, I often find myself writing type family T3 {|f|} e :: * . (A remnant of overexposure to generic programming, I guess.) Cheers, Stefan From simonpj at microsoft.com Wed Dec 9 03:45:24 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Dec 9 03:18:44 2009 Subject: [GHC] #3714: Improve error message if an associated family declaration has excess parameters In-Reply-To: <72FCCB49-8A15-4D46-9D3D-87DDA17A7B3D@cs.uu.nl> References: <046.1269d7611bd6a1dfa394e0799eb1571c@localhost> <055.9039e3a4de5cf59e4ba2a49371ec1ad5@localhost> <72FCCB49-8A15-4D46-9D3D-87DDA17A7B3D@cs.uu.nl> Message-ID: <59543203684B2244980D7E4057D5FBC1085175E3@DB3EX14MBXC308.europe.corp.microsoft.com> Indeed. But do you want to use that syntax for class parameters too? That would be a big change class C {|a|} where .... S | -----Original Message----- | From: Stefan Holdermans [mailto:stefan@cs.uu.nl] | Sent: 09 December 2009 08:42 | To: glasgow-haskell-bugs@haskell.org | Cc: Simon Peyton-Jones | Subject: Re: [GHC] #3714: Improve error message if an associated family | declaration has excess parameters | | Simon, | | Regarding distinguishing between type indices and parameters, you | suggested: | | > type family T3 f !e :: * -- The ! indicates a type parameter | > (not | > an index) | | I'd rather have indices, rather than parameters, explicated by mean of | syntax. This seems more consistent with ordinary type declarations. | | On paper, I often find myself writing | | type family T3 {|f|} e :: * . | | (A remnant of overexposure to generic programming, I guess.) | | Cheers, | | Stefan From stefan at cs.uu.nl Wed Dec 9 03:52:05 2009 From: stefan at cs.uu.nl (Stefan Holdermans) Date: Wed Dec 9 03:26:25 2009 Subject: [GHC] #3714: Improve error message if an associated family declaration has excess parameters In-Reply-To: <59543203684B2244980D7E4057D5FBC1085175E3@DB3EX14MBXC308.europe.corp.microsoft.com> References: <046.1269d7611bd6a1dfa394e0799eb1571c@localhost> <055.9039e3a4de5cf59e4ba2a49371ec1ad5@localhost> <72FCCB49-8A15-4D46-9D3D-87DDA17A7B3D@cs.uu.nl> <59543203684B2244980D7E4057D5FBC1085175E3@DB3EX14MBXC308.europe.corp.microsoft.com> Message-ID: <53308F9E-C0D7-4A27-9B06-4738358E31A4@cs.uu.nl> Simon, >> type family T3 {|f|} e :: * > Indeed. But do you want to use that syntax for class parameters > too? That would be a big change > > class C {|a|} where .... Well... That would be the most consistent then. But... it looks weird. And it breaks code, of course. One could argue of course that visual markers are not needed for classes because all arguments introduce indices rather than parameters, but I see that you can argue the same for algebraic data-type declarations then. Cheers, Stefan From trac at galois.com Wed Dec 9 06:57:23 2009 From: trac at galois.com (GHC) Date: Wed Dec 9 06:31:49 2009 Subject: [GHC] #3714: Improve error message if an associated family declaration has excess parameters In-Reply-To: <046.1269d7611bd6a1dfa394e0799eb1571c@localhost> References: <046.1269d7611bd6a1dfa394e0799eb1571c@localhost> Message-ID: <055.b2da2133cc2676351c5e56aeeb4ae755@localhost> #3714: Improve error message if an associated family declaration has excess parameters ---------------------------+------------------------------------------------ Reporter: simonpj | Owner: chak Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Comment (by MartijnVanSteenbergen): Yes, I do intend to never use specific types for {{{e}}} when writing instances. In every instance it will be a 'polymorphic' {{{e}}} (if polymorphic is the right word here), so it behaves like argument, not an index (using Simon's terms). I'm sorry I haven't been able to make myself clear sooner. :-) The idea behind the bang solution is exactly what I have in mind. Part of the confusion I think is that I was already expecting this to work: the problem only occurs inside type classes and instances, and the compiler knows exactly where the bangs should go, namely those indices/parameters on the left of the {{{::}}} that do not appear in the type class header. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 9 07:18:06 2009 From: trac at galois.com (GHC) Date: Wed Dec 9 06:52:29 2009 Subject: [GHC] #3733: When I loaded a file and ran it, it gave a message asking me to submit a bug In-Reply-To: <046.6eb3b07bda483d4af283b08f7d4cde7a@localhost> References: <046.6eb3b07bda483d4af283b08f7d4cde7a@localhost> Message-ID: <055.3b476d8f75a2b7e3ae0ce7300459120f@localhost> #3733: When I loaded a file and ran it, it gave a message asking me to submit a bug ---------------------------+------------------------------------------------ Reporter: vtrajan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Windows Testcase: | Architecture: x86 Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by simonmar): * difficulty: => Comment: Thanks for the report. We need more details to reproduce it: please include the exact code you tried to run, the commands you typed, and the entire output that GHC produced. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 9 07:21:24 2009 From: trac at galois.com (GHC) Date: Wed Dec 9 06:55:46 2009 Subject: [GHC] #427: Random.StdGen slowness In-Reply-To: <044.910d2f7eb299e5f5b612cc8fccf049ef@localhost> References: <044.910d2f7eb299e5f5b612cc8fccf049ef@localhost> Message-ID: <053.caf93001bf34a1364ee7adda76dc3ebb@localhost> #427: Random.StdGen slowness --------------------------------------+------------------------------------- Reporter: remit | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: libraries/random | Version: Resolution: None | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Runtime performance bug | --------------------------------------+------------------------------------- Changes (by simonmar): * priority: low => normal * failure: => Runtime performance bug Comment: See also bos's [http://hackage.haskell.org/package/statistics statistics package] which includes a fast random number generator. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 9 08:49:24 2009 From: trac at galois.com (GHC) Date: Wed Dec 9 08:23:57 2009 Subject: [GHC] #3586: Initialisation of unboxed arrays is too slow In-Reply-To: <046.d37b803347b32ce78018550b0e0c0244@localhost> References: <046.d37b803347b32ce78018550b0e0c0244@localhost> Message-ID: <055.0addaaac0c10db1500dd4c9f56954c7d@localhost> #3586: Initialisation of unboxed arrays is too slow --------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 6.12.2 Component: libraries (other) | Version: 6.10.4 Resolution: fixed | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Runtime performance bug | --------------------------------------+------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Workaround applied in 6.12.1: {{{ Thu Nov 12 05:38:07 PST 2009 Simon Marlow * Apply a workaround for #3586 This is a pretty severe performance bug in newArray and newArray_, fixed in HEAD, but needs a workaround in STABLE. The workaround from the ticket didn't work, but a slight modification of it did: I had to disable the INLINE pragma on the newArray default method. M ./libraries/tarballs/array-0.3.0.0.tar.gz }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 9 11:53:07 2009 From: trac at galois.com (GHC) Date: Wed Dec 9 11:27:42 2009 Subject: [GHC] #3637: ./configure doesn't understand Gentoo's build/host/target In-Reply-To: <047.fcebd5e462086e021124f01f2c19fc8c@localhost> References: <047.fcebd5e462086e021124f01f2c19fc8c@localhost> Message-ID: <056.f0f98764d6d49a342cbde80c19db1ec9@localhost> #3637: ./configure doesn't understand Gentoo's build/host/target ----------------------------------+----------------------------------------- Reporter: kolmodin | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Build System | Version: 6.12.1 RC1 Resolution: | Keywords: regression Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Building GHC failed | ----------------------------------+----------------------------------------- Comment (by simonmar): See also [[TicketQuery(id=2951|)]] [[TicketQuery(id=1717|)]] -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 9 13:50:31 2009 From: trac at galois.com (GHC) Date: Wed Dec 9 13:24:54 2009 Subject: [GHC] #3739: ghc-cabal mishandles relative paths in arguments Message-ID: <048.33ad0d7b937dcb44ba82750481db301b@localhost> #3739: ghc-cabal mishandles relative paths in arguments ---------------------------------+------------------------------------------ Reporter: asuffield | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Just making a record of this one, don't expect it to get fixed in a hurry ghc-cabal chdirs into the source directory when it runs, because cabal wants to run there. Unfortunately this means relative paths in the arguments are treated as relative to the cabal file, rather than the directory where ghc-cabal was invoked. This is notably an issue for --package-db, which currently requires an absolute path in order to avoid this issue. (This appears to be the last thing in ghc which needs an absolute path; when it's gone, a lot of things become simpler) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 9 14:35:11 2009 From: trac at galois.com (GHC) Date: Wed Dec 9 14:09:32 2009 Subject: [GHC] #3740: 6.8.2: Cannot configure under Cygwin Message-ID: <045.0be451a094667acb3b5993bf51c85496@localhost> #3740: 6.8.2: Cannot configure under Cygwin -----------------------+---------------------------------------------------- Reporter: jaalto | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.8.2 | Keywords: Os: Linux | Testcase: Architecture: x86 | Failure: Building GHC failed -----------------------+---------------------------------------------------- There is no GHC compiler available for Cygwin (Linux like environment). The following attempt failed. ENVIRONMENT {{{ $ echo $SHELL /bin/sh $ /bin/sh --version GNU bash, version 3.2.49(23)-release (i686-pc-cygwin) $ type pwd pwd is a shell builtin $ ld --version GNU ld (GNU Binutils) 2.19.51.20090704 $ gcc --version gcc (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) }}} CONFIGURE {{{ ~/cygwin/7/ghc6/ghc-6.8.2/$ '''./configure --build i686-pc-cygwin --host i686-pc-cygwin --prefix=/usr --without-ghc''' checking build system type... i686-pc-cygwin checking host system type... i686-pc-cygwin checking target system type... i686-pc-cygwin Canonicalised to: i386-unknown-cygwin32 checking version of ghc... unknown ./configure: line 2209: test: unknownunknown: integer expression expected ./configure: line 2210: test: unknownunknown: integer expression expected ./configure: line 2211: test: unknownunknown: integer expression expected ./configure: line 2212: test: unknownunknown: integer expression expected ./configure: line 2213: test: unknownunknown: integer expression expected checking for ghc-pkg matching no... no checking for ghc-pkg... no checking whether ghc has readline package... no checking for nhc... no checking for nhc98... no checking for hbc... no checking for ld... /usr/bin/ld checking for path to top of build tree... ./configure: line 2651: no: command not found ./configure: line 2655: utils/pwd/pwd: No such file or directory configure: error: cannot determine current directory }}} The error line 2651-55 are: {{{ 2644 2645 if test ! -f utils/pwd/pwd && test ! -f utils/pwd/pwd.exe; then 2646 cd utils/pwd 2647 rm -f *.o 2648 rm -f *.hi 2649 rm -f pwd 2650 rm -f pwd.exe 2651 $WithGhc -v0 --make pwd -o pwd 2652 cd ../.. 2653 fi 2654 2655 hardtop=`utils/pwd/pwd forwardslash` }}} I used following '''mk/build.mk''' file: {{{ XMLDocWays := html HADDOCK_DOCS := YES GhcRTSWays += debug_p thr_debug thr_debug_p XSLTPROC_OPTS += --nonet GhcUnregisterised=YES GhcWithNativeCodeGen=NO GhcWithInterpreter=NO SplitObjs=NO GhcRTSWays := $(shell echo $(GhcRTSWays) | sed "s/\<[a-z_]*thr[a-z_]*\>//g") GhcNotThreaded=YES bindir := ${libdir}/bin docdir := $(datarootdir)/doc/ghc6-doc htmldir := $(docdir) dvidir := $(docdir) pdfdir := $(docdir) psdir := $(docdir) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 9 15:05:41 2009 From: trac at galois.com (GHC) Date: Wed Dec 9 14:40:02 2009 Subject: [GHC] #3740: 6.8.2: Cannot configure under Cygwin In-Reply-To: <045.0be451a094667acb3b5993bf51c85496@localhost> References: <045.0be451a094667acb3b5993bf51c85496@localhost> Message-ID: <054.6d7c0b3df7c9ff4be8526e82e90cffda@localhost> #3740: 6.8.2: Cannot configure under Cygwin ----------------------------------+----------------------------------------- Reporter: jaalto | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 6.8.2 Resolution: duplicate | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86 Failure: Building GHC failed | ----------------------------------+----------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => * resolution: => duplicate Comment: You can use the Windows build under cygwin, but you are right that there is not a native cygwin port. We have no plans to create the port, but if someone else were to create and maintain it then that would be great. Closing this ticket as a duplicate of #110. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 9 15:55:08 2009 From: trac at galois.com (GHC) Date: Wed Dec 9 15:29:28 2009 Subject: [GHC] #3736: GHC specialising instead of inlining In-Reply-To: <044.6187e75fed543439fb0c0aaede8523f0@localhost> References: <044.6187e75fed543439fb0c0aaede8523f0@localhost> Message-ID: <053.10b5698d1759d5f699df6cf2a8a1847e@localhost> #3736: GHC specialising instead of inlining --------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86 Failure: Runtime performance bug | --------------------------------------+------------------------------------- Changes (by kfrdbs): * cc: kfrdbs@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 9 15:55:54 2009 From: trac at galois.com (GHC) Date: Wed Dec 9 15:30:15 2009 Subject: [GHC] #3664: Ghc eats tremendous heaps of RAM in -prof build (highlighting-kate) In-Reply-To: <045.0f6b0943402daeb82291512e1fe74507@localhost> References: <045.0f6b0943402daeb82291512e1fe74507@localhost> Message-ID: <054.910440dfd724d0664ac3a7f6bfdf78ca@localhost> #3664: Ghc eats tremendous heaps of RAM in -prof build (highlighting-kate) -------------------------------------------+-------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86_64 (amd64) Failure: Compile-time performance bug | -------------------------------------------+-------------------------------- Changes (by kfrdbs): * cc: kfrdbs@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 9 15:55:47 2009 From: trac at galois.com (GHC) Date: Wed Dec 9 15:30:16 2009 Subject: [GHC] #3330: Type checker hangs In-Reply-To: <060.111b0979bdfa1b272261462ee3c542d4@localhost> References: <060.111b0979bdfa1b272261462ee3c542d4@localhost> Message-ID: <069.780995af6d3b15757ee22fb3ef348fbc@localhost> #3330: Type checker hangs --------------------------------------+------------------------------------- Reporter: MartijnVanSteenbergen | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler (Type checker) | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: x86_64 (amd64) Failure: Compile-time crash | --------------------------------------+------------------------------------- Changes (by kfrdbs): * cc: kfrdbs@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 9 15:57:41 2009 From: trac at galois.com (GHC) Date: Wed Dec 9 15:32:01 2009 Subject: [GHC] #3677: Optimizer creates stack overflow on filtered CAF In-Reply-To: <043.bc40a075329f7b63a53340629e65db0f@localhost> References: <043.bc40a075329f7b63a53340629e65db0f@localhost> Message-ID: <052.553e5a1c575c7c4df2ebac3be6885170@localhost> #3677: Optimizer creates stack overflow on filtered CAF ----------------------------+----------------------------------------------- Reporter: jpet | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 6.12.2 Component: Compiler | Version: 6.10.4 Resolution: fixed | Keywords: Difficulty: | Os: Windows Testcase: | Architecture: x86 Failure: Runtime crash | ----------------------------+----------------------------------------------- Changes (by kfrdbs): * cc: kfrdbs@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 9 17:00:41 2009 From: trac at galois.com (GHC) Date: Wed Dec 9 16:35:05 2009 Subject: [GHC] #110: Cygwin binaries In-Reply-To: <046.e27078d66dc3ce56ae08f6163d6a3403@localhost> References: <046.e27078d66dc3ce56ae08f6163d6a3403@localhost> Message-ID: <055.0e9ab23e4a43796449828625fedb0efb@localhost> #110: Cygwin binaries ------------------------------+--------------------------------------------- Reporter: fizzgig | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: None | Version: None Resolution: None | Keywords: Difficulty: Unknown | Os: Windows Testcase: N/A | Architecture: Unknown/Multiple Failure: None/Unknown | ------------------------------+--------------------------------------------- Comment (by jaalto): For more information about the Cygwin compilation can be found at bug http://hackage.haskell.org/trac/ghc/ticket/3740 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 9 17:02:47 2009 From: trac at galois.com (GHC) Date: Wed Dec 9 16:37:08 2009 Subject: [GHC] #3740: 6.8.2: Cannot configure under Cygwin In-Reply-To: <045.0be451a094667acb3b5993bf51c85496@localhost> References: <045.0be451a094667acb3b5993bf51c85496@localhost> Message-ID: <054.af80e42f237ef8f06e4268331c46fa42@localhost> #3740: 6.8.2: Cannot configure under Cygwin ----------------------------------+----------------------------------------- Reporter: jaalto | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 6.8.2 Resolution: duplicate | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86 Failure: Building GHC failed | ----------------------------------+----------------------------------------- Comment (by jaalto): The "windows" version cannot be used under Cygwin, because it does not behave like the "Linux" version and it does not recognize /cygdrive/ etc. The proper Cygwin port will behave exactly like Linux one, so closing this bug report as a duplicate of "Windows" is not warreanted. These two are different platforms. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 9 19:24:00 2009 From: trac at galois.com (GHC) Date: Wed Dec 9 18:58:21 2009 Subject: [GHC] #3740: 6.8.2: Cannot configure under Cygwin In-Reply-To: <045.0be451a094667acb3b5993bf51c85496@localhost> References: <045.0be451a094667acb3b5993bf51c85496@localhost> Message-ID: <054.eabec0e4840df3d1a52322bbf8a2441a@localhost> #3740: 6.8.2: Cannot configure under Cygwin ----------------------------------+----------------------------------------- Reporter: jaalto | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 6.8.2 Resolution: duplicate | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86 Failure: Building GHC failed | ----------------------------------+----------------------------------------- Comment (by duncan): Replying to [comment:2 jaalto]: > The proper Cygwin port will behave exactly like Linux one, so closing this bug report as a duplicate of "Windows" is not warreanted. You misunderstand. Igloo is saying this feature request is a duplicate of ticket #110. That ticket is a previous feature request for cygwin binaries. He's not saying the current native win32 port is the same as a cygwin one would be. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 10 03:26:44 2009 From: trac at galois.com (GHC) Date: Thu Dec 10 03:01:03 2009 Subject: [GHC] #3741: ghci misinterprets "early" unicode characters Message-ID: <044.258de514f09730ca65d032a50db6d67d@localhost> #3741: ghci misinterprets "early" unicode characters ---------------------------------+------------------------------------------ Reporter: brian | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.10.4 | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ It seems as if ghci misinterprets unicode characters if they occur too early in a source file. {{{ $ cat test.hs --data A = A -- example will not work if this line is commented ? :: [a] -> Int ? = length }}} {{{ $ ghci test.hs GHCi, version 6.10.4: 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 ( test.hs, interpreted ) test.hs:2:0: Illegal signature in pattern: [a] -> Int ? Use -XScopedTypeVariables to permit it Failed, modules loaded: none. Prelude> }}} Uncommenting the first line makes the problem go away. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 10 05:50:57 2009 From: trac at galois.com (GHC) Date: Thu Dec 10 05:25:17 2009 Subject: [GHC] #3741: ghci misinterprets "early" unicode characters In-Reply-To: <044.258de514f09730ca65d032a50db6d67d@localhost> References: <044.258de514f09730ca65d032a50db6d67d@localhost> Message-ID: <053.204f75442ff0df6035e9ec297aac245b@localhost> #3741: ghci misinterprets "early" unicode characters ----------------------------------------+----------------------------------- Reporter: brian | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: Compiler (Parser) | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: GHC rejects valid program | ----------------------------------------+----------------------------------- Changes (by simonmar): * owner: => simonmar * difficulty: => * component: GHCi => Compiler (Parser) * failure: None/Unknown => GHC rejects valid program * milestone: => 6.12.2 Comment: Fascinating... I'll take a look. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 10 06:33:10 2009 From: trac at galois.com (GHC) Date: Thu Dec 10 06:07:28 2009 Subject: [GHC] #3742: redundant space in FFI imports rejected by 6.12 Message-ID: <045.5c4f82a5466765e359b1173caa6982ac@localhost> #3742: redundant space in FFI imports rejected by 6.12 ----------------------------------+----------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 6.12.1 RC1 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: GHC rejects valid program ----------------------------------+----------------------------------------- GHC 6.10 and older accepted this code: {{{ foreign import ccall unsafe " g_get_application_name" g_get_application_name :: (IO (Ptr CChar)) }}} GHC 6.12 now rejects it with {{{ glib/System/Glib/Utils.chs:81:28: Malformed entity string }}} The problem is the leading space in the C entity string. This code is generated by c2hs which is doing `header ++ " " ++ ident` however the header may be empty. We should probably allow this code, though possibly with a warning. In parallel, c2hs could be fixed so it doesn't do that. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 10 07:43:16 2009 From: trac at galois.com (GHC) Date: Thu Dec 10 07:17:35 2009 Subject: [GHC] #3742: redundant space in FFI imports rejected by 6.12 In-Reply-To: <045.5c4f82a5466765e359b1173caa6982ac@localhost> References: <045.5c4f82a5466765e359b1173caa6982ac@localhost> Message-ID: <054.a148c7dabd8aa163a82950a5aa32d2a0@localhost> #3742: redundant space in FFI imports rejected by 6.12 ----------------------------------------+----------------------------------- Reporter: duncan | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler (Parser) | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: GHC rejects valid program | ----------------------------------------+----------------------------------- Changes (by simonmar): * owner: => simonmar * milestone: => 6.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 10 11:39:53 2009 From: trac at galois.com (GHC) Date: Thu Dec 10 11:14:15 2009 Subject: [GHC] #3741: ghci misinterprets "early" unicode characters In-Reply-To: <044.258de514f09730ca65d032a50db6d67d@localhost> References: <044.258de514f09730ca65d032a50db6d67d@localhost> Message-ID: <053.2307ad7bfa6416bf204634cadcd34580@localhost> #3741: ghci misinterprets "early" unicode characters ----------------------------------------+----------------------------------- Reporter: brian | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.12.2 Component: Compiler (Parser) | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: GHC rejects valid program | ----------------------------------------+----------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: Fixed: {{{ Thu Dec 10 16:09:09 GMT 2009 Simon Marlow * Fix #3741, simplifying things in the process The problem in #3741 was that we had confused column numbers with byte offsets, which fails in the case of UTF-8 (amongst other things). Fortunately we're tracking correct column offsets now, so we didn't have to make a calculation based on a byte offset. I got rid of two fields from the PState (last_line_len and last_offs).and one field from the AI (alex input) constructor. }}} This relies on Igloo's column number changes, which are apparently not in the 6.12 branch though. It might be possible to merge this by just modifying advanceSrcLoc, without merging in the rest of the column number changes. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 10 11:41:49 2009 From: trac at galois.com (GHC) Date: Thu Dec 10 11:16:08 2009 Subject: [GHC] #3742: redundant space in FFI imports rejected by 6.12 In-Reply-To: <045.5c4f82a5466765e359b1173caa6982ac@localhost> References: <045.5c4f82a5466765e359b1173caa6982ac@localhost> Message-ID: <054.4aad02d4b2de5cf7144f06c5742ccf3f@localhost> #3742: redundant space in FFI imports rejected by 6.12 ----------------------------------------+----------------------------------- Reporter: duncan | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler (Parser) | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: GHC rejects valid program | ----------------------------------------+----------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: Fixed: {{{ Thu Dec 10 12:45:37 GMT 2009 Simon Marlow * Allow spaces at either end of the C import spec (#3742) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 10 12:16:11 2009 From: trac at galois.com (GHC) Date: Thu Dec 10 11:50:29 2009 Subject: [GHC] #3664: Ghc eats tremendous heaps of RAM in -prof build (highlighting-kate) In-Reply-To: <045.0f6b0943402daeb82291512e1fe74507@localhost> References: <045.0f6b0943402daeb82291512e1fe74507@localhost> Message-ID: <054.883b6d0284d760bc3fed0a128d89575b@localhost> #3664: Ghc eats tremendous heaps of RAM in -prof build (highlighting-kate) -------------------------------------------+-------------------------------- Reporter: slyfox | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86_64 (amd64) Failure: Compile-time performance bug | -------------------------------------------+-------------------------------- Changes (by simonpj): * owner: => igloo * type: bug => merge Comment: OK so I'll assign the ticket to Ian, to merge into 6.12.2, when 6.12.1 is out. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 10 14:17:52 2009 From: trac at galois.com (GHC) Date: Thu Dec 10 13:52:10 2009 Subject: [GHC] #3743: type checker fails to infer an implicit parameter constraint in the presence of existential types. Message-ID: <044.3ae86540a9a2f370a09cfac1cd97e512@localhost> #3743: type checker fails to infer an implicit parameter constraint in the presence of existential types. ---------------------------------+------------------------------------------ Reporter: int-e | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.13 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ In this code, {{{ {-# LANGUAGE ImplicitParams, GADTs #-} class Foo a data M where M :: Foo a => a -> M x :: (?x :: ()) => () x = undefined -- foo :: (?x :: ()) => M -> () foo y = case y of M _ -> x }}} I'd expect ghc to infer the commented out type for {{{foo}}}. However, it fails to do that: {{{ foo.hs:12:12: Unbound implicit parameter (?x::()) arising from a use of `x' at foo.hs:12:12 In the expression: x In a case alternative: M _ -> x In the expression: case y of { M _ -> x } }}} Is this a bug or an expected shortcoming of the type checker? The program compiles fine with the explicit type signature. (In the original program the type signature was big and completely unenlightening, so I'd rather not have to write it.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 10 22:26:01 2009 From: trac at galois.com (GHC) Date: Thu Dec 10 22:00:17 2009 Subject: [GHC] #3744: Comparisons against minBound/maxBound not optimised Message-ID: <041.2169b48b8108c3b700385a622d1921fe@localhost> #3744: Comparisons against minBound/maxBound not optimised ---------------------------------+------------------------------------------ Reporter: rl | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.13 | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Runtime performance bug ---------------------------------+------------------------------------------ {{{ foo :: Int -> Bool foo n = n < minBound || n > maxBound }}} GHC retains both comparisons even though they are guaranteed to be False. This also happens for other integral types. The optimisation is fairly easy to implement for `Int` and `Word` (only requires some plumbing in !PrelRules) but it's not clear what to do about smaller integral types. For `Int64` and `Word64`, GHC doesn't even inline `minBound` and `maxBound`: {{{ T.$wfoo :: GHC.Prim.Int64# -> GHC.Bool.Bool T.$wfoo = \ (ww_ss5 :: GHC.Prim.Int64#) -> case GHC.Int.$fBoundedInt64_$cminBound of _ { GHC.Int.I64# y#_are -> case {__ccall hs_ltInt64 GHC.Prim.Int64# -> GHC.Prim.Int64# -> GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, GHC.Prim.Int# #)}_arD ww_ss5 y#_are GHC.Prim.realWorld# of _ { (# _, ds3_arH #) -> case ds3_arH of _ { __DEFAULT -> GHC.Bool.True; 0 -> case GHC.Int.$fBoundedInt64_$cmaxBound of _ { GHC.Int.I64# y#1_ar4 -> GHC.IntWord64.gtInt64# ww_ss5 y#1_ar4 } } } } T.foo :: GHC.Int.Int64 -> GHC.Bool.Bool T.foo = \ (w_ss3 :: GHC.Int.Int64) -> case w_ss3 of _ { GHC.Int.I64# ww_ss5 -> T.$wfoo ww_ss5 } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 11 04:00:08 2009 From: trac at galois.com (GHC) Date: Fri Dec 11 03:34:24 2009 Subject: [GHC] #3539: internal error: ASSERTION FAILED: file sm/Evac.c, line 368 In-Reply-To: <047.ce838bf90bf0705c86e1a5b8acf0114d@localhost> References: <047.ce838bf90bf0705c86e1a5b8acf0114d@localhost> Message-ID: <056.303d08526aca6e76d497fbbae4b7dd74@localhost> #3539: internal error: ASSERTION FAILED: file sm/Evac.c, line 368 -----------------------------+---------------------------------------------- Reporter: elaforge | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 6.12.1 Component: Runtime System | Version: 6.10.4 Resolution: invalid | Keywords: Difficulty: Unknown | Os: MacOS X Testcase: | Architecture: x86 Failure: None/Unknown | -----------------------------+---------------------------------------------- Changes (by elaforge): * status: new => closed * failure: => None/Unknown * resolution: => invalid Comment: I'm going to go ahead and close this. I was never able to reproduce it reliably, but a couple weeks ago I found a fishy bad array read in c++ and since I fixed that I haven't seen it again. So chances are good that was the problem. Sorry about the false alarm! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 11 04:37:11 2009 From: trac at galois.com (GHC) Date: Fri Dec 11 04:11:28 2009 Subject: [GHC] #3539: internal error: ASSERTION FAILED: file sm/Evac.c, line 368 In-Reply-To: <047.ce838bf90bf0705c86e1a5b8acf0114d@localhost> References: <047.ce838bf90bf0705c86e1a5b8acf0114d@localhost> Message-ID: <056.b9bc58152cb1222e2e35640791890b18@localhost> #3539: internal error: ASSERTION FAILED: file sm/Evac.c, line 368 -----------------------------+---------------------------------------------- Reporter: elaforge | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 6.12.1 Component: Runtime System | Version: 6.10.4 Resolution: invalid | Keywords: Difficulty: Unknown | Os: MacOS X Testcase: | Architecture: x86 Failure: None/Unknown | -----------------------------+---------------------------------------------- Comment (by simonmar): That's good news, thanks for closing the bug! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 11 04:49:41 2009 From: trac at galois.com (GHC) Date: Fri Dec 11 04:24:00 2009 Subject: [GHC] #437: Recompilation check should include flags In-Reply-To: <046.9be6e1c5effc47bf45f5c9a62716ae81@localhost> References: <046.9be6e1c5effc47bf45f5c9a62716ae81@localhost> Message-ID: <055.ff7821aaf552edca2ce6b7bb75d60b5d@localhost> #437: Recompilation check should include flags -----------------------+---------------------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.4.1 Resolution: None | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: mod175 | Architecture: Unknown/Multiple Failure: Other | -----------------------+---------------------------------------------------- Changes (by simonmar): * priority: low => normal * failure: => Other -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 11 05:08:52 2009 From: trac at galois.com (GHC) Date: Fri Dec 11 04:43:10 2009 Subject: [GHC] #431: runInteractiveProcess and closed stdin. In-Reply-To: <045.572dbbd9b6b46d3f7b1e78158be38aba@localhost> References: <045.572dbbd9b6b46d3f7b1e78158be38aba@localhost> Message-ID: <054.b99652f42d4e8187debeb444280d79ce@localhost> #431: runInteractiveProcess and closed stdin. ------------------------------------------+--------------------------------- Reporter: nobody | Owner: Type: bug | Status: closed Priority: low | Milestone: _|_ Component: libraries/process | Version: 6.4 Resolution: fixed | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Incorrect result at runtime | ------------------------------------------+--------------------------------- Changes (by simonmar): * status: new => closed * failure: => Incorrect result at runtime * resolution: None => fixed Comment: The test program above (comment 2) now works. It works because of the ordering of pipes and dup2s in `runProcess()`, so I've added some comments to the code to ensure that we don't break that property in the future. Unfortunately the test case is too platform-specific to add to the test suite. The other test programs added to this ticket appear to be nothing to do with the original bug, so I'm closing it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 11 05:28:39 2009 From: trac at galois.com (GHC) Date: Fri Dec 11 05:02:55 2009 Subject: [GHC] #3065: Reorder tests in quot to improve code In-Reply-To: <046.819ea32d4c70bd7d14e7ef168534bbea@localhost> References: <046.819ea32d4c70bd7d14e7ef168534bbea@localhost> Message-ID: <055.20a719258eae595f97d7729750e8ce5e@localhost> #3065: Reorder tests in quot to improve code --------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: libraries/base | Version: 6.10.1 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Runtime performance bug | --------------------------------------+------------------------------------- Comment (by simonmar): All things being equal, we should expose the test to GHC because that enables more intelligent decisions to be made in the simplifier and the code generator. If it results in bad loop code, we should fix that, rather than work around it by making the test part of the primitive. The narrower Int types have their own implementations of `quot`, which currently include an overflow test. It might be possible in those cases to just omit the test, although that would make the behaviour of `Int32` on a 64-bit platform different from on a 32-bit platform in this particular case. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 11 05:39:52 2009 From: trac at galois.com (GHC) Date: Fri Dec 11 05:14:44 2009 Subject: [GHC] #635: Replace use of select() in the I/O manager with epoll/kqueue/etc. In-Reply-To: <047.158ac52b7977b3e9f47680935a918275@localhost> References: <047.158ac52b7977b3e9f47680935a918275@localhost> Message-ID: <056.9df53d5614ab8303bff772ba996dc934@localhost> #635: Replace use of select() in the I/O manager with epoll/kqueue/etc. -----------------------------------------+---------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: _|_ Component: libraries/base | Version: 6.4.1 Resolution: | Keywords: Difficulty: Project (more than a week) | Os: Unknown/Multiple Testcase: N/A | Architecture: Unknown/Multiple Failure: None/Unknown | -----------------------------------------+---------------------------------- Changes (by simonmar): * difficulty: Difficult (2-5 days) => Project (more than a week) * failure: => None/Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 11 05:44:27 2009 From: trac at galois.com (GHC) Date: Fri Dec 11 05:18:45 2009 Subject: [GHC] #3745: Non-deterministic behavior with FFI Message-ID: <048.13932c70c5ac7d2182ef99747868ffe2@localhost> #3745: Non-deterministic behavior with FFI ---------------------------------+------------------------------------------ Reporter: gchrupala | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (FFI) Version: 6.10.4 | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Incorrect result at runtime ---------------------------------+------------------------------------------ I have a simple perceptron learning algorithm in C++ which I am calling from Haskell via FFI. Most of the time it works perfectly, but occasionally the results it produces are not the expected. It seems to happen more often if there is another memory/cpu intensive process running on the machine. The same never happens when I call the same function from C++, which seems to indicate the problem is related to GHC. I attach a simplified extract of the code which will show the problem. I included: * c_perceptronmodel.cpp, c_perceptronmodel.h : C++ implementation * test.hs : Haskell program which calls the C++ function via FFI * test.cpp : Equivalent C++ program which calls the same C++ function * run.sh : shell script which will repeatedly run a program and check if any consecutive two runs produce different results * train : data file which the programs process I compiled using GHC 6.10.4 like this: {{{ ghc-6.10.4 --make -O2 -o test-ghc-6.10.4 test.hs c_perceptronmodel.cpp -lstdc++ }}} To see the problem execute: {{{ ./run.sh ./test-ghc-6.10.4 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 11 06:30:36 2009 From: trac at galois.com (GHC) Date: Fri Dec 11 06:04:52 2009 Subject: [GHC] #3746: Poor parse error Message-ID: <051.30594b4d5bf93a82dda06cabe9760a79@localhost> #3746: Poor parse error ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Given the fragment: {{{ f x = do case x of Just foo -> do stmt1 stmt2 stmt3 stmt4 stmt5 stmt6 Nothing -> a <- var stmt1 stmt2 stmt3 }}} There is a parse error after the {{{Nothing}}}, I should have included a {{{do}}}. GHC says: {{{ bug.hs:1:9: Parse error in pattern }}} This error message can be made to be arbitrarily far away from the point at which the error actually occurs. Haskell-src-exts does far better with: {{{ bug.hs:10:19: Parse error in pattern }}} Reporting {{{<-}}} binding errors against the arrow, rather than the (assumed) start of the pattern seems to be a better choice. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 11 06:35:42 2009 From: trac at galois.com (GHC) Date: Fri Dec 11 06:10:00 2009 Subject: [GHC] #3065: Reorder tests in quot to improve code In-Reply-To: <046.819ea32d4c70bd7d14e7ef168534bbea@localhost> References: <046.819ea32d4c70bd7d14e7ef168534bbea@localhost> Message-ID: <055.f3eb4fcda741e0e59c004bf2914e5b1c@localhost> #3065: Reorder tests in quot to improve code --------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: libraries/base | Version: 6.10.1 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Runtime performance bug | --------------------------------------+------------------------------------- Comment (by rl): In general, I agree with you but IMO things are far from equal here. The test is only there because of one particular quirk of one particular processor architecture. It isn't needed on the Sparc, for instance. There, we pay a performance penalty for no reason at all. Even on x86, it isn't needed for small integer types and I suspect it isn't needed for Int64 on x86-32. IMO, things like that are best handled by the processor-specific backend. The code generator should still be able to see the test. The simplifier isn't doing anything clever with it anyway and I don't see that changing in the near future (see, for instance #2132). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 11 07:27:33 2009 From: trac at galois.com (GHC) Date: Fri Dec 11 07:01:47 2009 Subject: [GHC] #3703: -ddump-rules does not list all rules in effect In-Reply-To: <046.cbef6970fc7549dd0b91f6f53e79c1c1@localhost> References: <046.cbef6970fc7549dd0b91f6f53e79c1c1@localhost> Message-ID: <055.e17b7a2a7062e81a123c45bc19c316fb@localhost> #3703: -ddump-rules does not list all rules in effect ---------------------------+------------------------------------------------ Reporter: nomeata | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: fixed | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86_64 (amd64) Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: Here's the patch {{{ Tue Dec 8 02:55:56 PST 2009 simonpj@microsoft.com * Improve dumping for rules, and documentation of same Ignore-this: 4b09e56f953d130d5cb2807cf9da7303 Inspired by Trac #3703 M ./compiler/simplCore/SimplCore.lhs -2 +2 M ./docs/users_guide/debugging.xml -2 +3 M ./docs/users_guide/glasgow_exts.xml -3 +6 }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 11 09:06:01 2009 From: trac at galois.com (GHC) Date: Fri Dec 11 08:40:25 2009 Subject: [GHC] #2458: Unknown symbol `_environ' on MacOS X In-Reply-To: <048.8d22aecac33c2afb7c79a5628eb01872@localhost> References: <048.8d22aecac33c2afb7c79a5628eb01872@localhost> Message-ID: <057.9c0e9b432a51075ab3d6a98189293636@localhost> #2458: Unknown symbol `_environ' on MacOS X -----------------------------+---------------------------------------------- Reporter: IgorBoehm | Owner: igloo Type: bug | Status: reopened Priority: normal | Milestone: 6.10.1 Component: libraries/base | Version: 6.10.1 Resolution: | Keywords: environ Difficulty: Unknown | Os: MacOS X Testcase: | Architecture: x86 Failure: None/Unknown | -----------------------------+---------------------------------------------- Changes (by mafo): * status: closed => reopened * cc: fontaine@cs.uni-duesseldorf.de (added) * summary: GHC MacOS X Leopard build succeeds, but ghci complains about: unknown symbol `_environ' => Unknown symbol `_environ' on MacOS X * failure: => None/Unknown * version: 6.9 => 6.10.1 * resolution: fixed => Comment: This bug also shows up with Haskell-created libraries. If the executable which uses the library has been stripped the error occurs. If the executable has not been stripped the library can be loaded. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 11 11:19:51 2009 From: trac at galois.com (GHC) Date: Fri Dec 11 10:54:06 2009 Subject: [GHC] #3747: getDirectoryContents yields wrong results Message-ID: <045.150fa620f12a57939f825d5ce3665862@localhost> #3747: getDirectoryContents yields wrong results ------------------------+--------------------------------------------------- Reporter: Meddix | Owner: Type: bug | Status: new Priority: normal | Component: libraries/directory Version: 6.10.4 | Keywords: Os: Windows | Testcase: getDirectoryContents "c:" Architecture: x86 | Failure: Incorrect result at runtime ------------------------+--------------------------------------------------- Executing getDirectoryContents on "c:" gives the contents of the current directory.[[BR]] The following program prints always True: {{{ module Main (main) where import System.Directory main :: IO () main = do rootContents <- getDirectoryContents "c:" currContents <- getCurrentDirectory >>= getDirectoryContents putStrLn . show $ currContents == rootContents }}} Thanks -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 11 11:41:33 2009 From: trac at galois.com (GHC) Date: Fri Dec 11 11:15:57 2009 Subject: [GHC] #3747: getDirectoryContents yields wrong results In-Reply-To: <045.150fa620f12a57939f825d5ce3665862@localhost> References: <045.150fa620f12a57939f825d5ce3665862@localhost> Message-ID: <054.6a4709d472b61494a13c18c2d2ffff54@localhost> #3747: getDirectoryContents yields wrong results ------------------------------------------+--------------------------------- Reporter: Meddix | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/directory | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Windows Testcase: getDirectoryContents "c:" | Architecture: x86 Failure: Incorrect result at runtime | ------------------------------------------+--------------------------------- Changes (by malcolm.wallace@cs.york.ac.uk): * difficulty: => Comment: I believe, if you invoke that program from any directory on the C: drive, that is the correct behaviour. The filepath specification "C:" means exactly the "current directory on drive C". Every drive has its own separate "current" directory. If you want the root of the drive, you need to specify "C:\". -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 11 12:37:06 2009 From: trac at galois.com (GHC) Date: Fri Dec 11 12:11:22 2009 Subject: [GHC] #2555: Template Haskell does not respect -package and -hide constraints In-Reply-To: <044.7c1849c0092957cb6d9dc4fd3b20e42f@localhost> References: <044.7c1849c0092957cb6d9dc4fd3b20e42f@localhost> Message-ID: <053.da3ded9b668ca89461d8cdef8af646a2@localhost> #2555: Template Haskell does not respect -package and -hide constraints -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Template Haskell | Version: 6.8.2 Resolution: | Keywords: Difficulty: Unknown | Os: Linux Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | -------------------------------+-------------------------------------------- Changes (by duncan): * failure: => None/Unknown Comment: Replying to [comment:6 simonmar]: > We don't dispute there's a bug here, but it can't be as simple as just "TH ignores the package flags". My current guess is that stale .hi files refer to another version of a package, so despite what the -package flags say we pull in two versions of a package when TH runs. That said, this should only happen if there are multiple versions of a package in the package graph. So perhaps this doesn't explain what gwern reported. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 11 20:03:21 2009 From: trac at galois.com (GHC) Date: Fri Dec 11 19:37:48 2009 Subject: [GHC] #3747: getDirectoryContents yields wrong results In-Reply-To: <045.150fa620f12a57939f825d5ce3665862@localhost> References: <045.150fa620f12a57939f825d5ce3665862@localhost> Message-ID: <054.cdeaf3fdb5d349451c6b874556a5476d@localhost> #3747: getDirectoryContents yields wrong results ------------------------------------------+--------------------------------- Reporter: Meddix | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/directory | Version: 6.10.4 Resolution: invalid | Keywords: Difficulty: | Os: Windows Testcase: getDirectoryContents "c:" | Architecture: x86 Failure: Incorrect result at runtime | ------------------------------------------+--------------------------------- Changes (by duncan): * status: new => closed * resolution: => invalid Comment: As Malcolm says, this is the correct behaviour on Windows. We may think that Windows file path behaviour is bonkers, but that's what it is and we can't change it (we would not want to be inconsistent with it). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Dec 12 09:02:57 2009 From: trac at galois.com (GHC) Date: Sat Dec 12 08:37:23 2009 Subject: [GHC] #3748: Bug in rts/Win32/Ticker.c can cause process hang on exit in Win32 Message-ID: <042.ebc1303ba4ba1bb01245ae57d2b8c614@localhost> #3748: Bug in rts/Win32/Ticker.c can cause process hang on exit in Win32 ---------------------------------+------------------------------------------ Reporter: sgf | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 6.10.4 | Keywords: Os: Windows | Testcase: Architecture: Unknown/Multiple | Failure: Runtime crash ---------------------------------+------------------------------------------ On Win32, the ticker thread is shut down by signalling for it to close, waiting 20ms, and then calling !TerminateThread if it hasn't already terminated. On a heavily-loaded system, the 20ms timeout can be exceeded, and !TerminateThread is called. There is then a race condition. According to our tests, in about 1 in 100 calls to !TerminateThread, the ticker thread is holding the Windows loader lock (which is held during parts of thread shutdown). It is killed holding the lock, and no other thread can acquire the lock. Therefore, no other thread can die, and the whole process hangs on exit. Isn't the Win32 API lovely? Given the timeout occurs about 1 in 100 times on a heavily-loaded box (more runnable threads than cores), and then the hang occurs on 1 in 100 timeouts, it's a slightly tedious bug to reproduce. My test case was 4 shell windows in infinite loops running a small GHC executable that forces the ticker thread to be started by using System.Timeout.timeout. My suggestions: As the code suggests, if the ticker is compiled into a DLL, the thread must die before the DLL can be safely unloaded - otherwise an unhandled exception will wreak havoc in the process. The best suggestion I can think of is to increase the timeout, to 200ms say. After all, the timeout should rarely be reached except on heavily loaded systems, few people need a guaranteed quick response time on DLL unload, and any time the timeout is hit we introduce the possibility of basically breaking the process when we call !TerminateThread. For the runtime compiled into an executable, there is no need to call !TerminateThread. The executable will remain mapped until after the ticker thread is forcibly terminated by the Windows system. Instead, we can simply attempt to signal the thread to close, wait for a timeout, and then shrug our shoulders and return, giving the least-unclean program shutdown possible in that case. If people are happy with my proposed changes, I can make a patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Dec 13 08:20:00 2009 From: trac at galois.com (GHC) Date: Sun Dec 13 07:54:11 2009 Subject: [GHC] #1216: indexing 2d arrays is slow and leaky. why? In-Reply-To: <044.7a2c34fb5e14ee065cc1b66e35e75915@localhost> References: <044.7a2c34fb5e14ee065cc1b66e35e75915@localhost> Message-ID: <053.8a1f2cd4758f7f3b2db3409e5cb96843@localhost> #1216: indexing 2d arrays is slow and leaky. why? --------------------------------------+------------------------------------- Reporter: claus | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.6 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Runtime performance bug | --------------------------------------+------------------------------------- Changes (by guest): * cc: sveina@gmail.com (added) Comment: Problem still exists on 6.12-rc2 The memory leak appears to have gone away again, but there's a factor of two difference in speed between the two versions of the code. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 14 00:52:04 2009 From: trac at galois.com (GHC) Date: Mon Dec 14 00:26:10 2009 Subject: [GHC] #3749: unexpected parse errors with `do` and `let` Message-ID: <049.d2a0e47bc50eb214cb0f82d8928bca57@localhost> #3749: unexpected parse errors with `do` and `let` ---------------------------+------------------------------------------------ Reporter: dherington | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Keywords: do, let, parse error Os: Windows | Testcase: Architecture: x86 | Failure: GHC rejects valid program ---------------------------+------------------------------------------------ Unless I misunderstand, all three of the following definitions are syntactically correct. However, f2 and f3 elicit parse errors. {{{ f1 = do let x = 3 return x f2 = do let x = 3; return x f3 = do { let x = 3; return x } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 14 04:19:56 2009 From: trac at galois.com (GHC) Date: Mon Dec 14 03:54:03 2009 Subject: [GHC] #3750: nameModule $wlookup_nm Message-ID: <047.4ee4e029b449041cfea8d5742bb324d0@localhost> #3750: nameModule $wlookup_nm ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 6.14.1 Component: Compiler | Version: 6.13 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Compile-time crash ---------------------------------+------------------------------------------ This recently started happening in HEAD. The last build in which it did not happen was on 1 Dec 2009. The program is `nofib/real/veritas`: {{{ ==nofib== veritas: time to compile Parse follows... /64playpen/simonmar/nightly/HEAD-cam-04-unx/x86_64-unknown- linux/inplace/bin/ghc-stage2 -H32m -O -O -Rghc-timing -H32m -hisuf hi -c Parse.lhs -o Parse.o ghc-stage2: panic! (the 'impossible' happened) (GHC version 6.13.20091213 for x86_64-unknown-linux): nameModule $wlookup_nm{v r2Mh} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 14 04:26:29 2009 From: trac at galois.com (GHC) Date: Mon Dec 14 04:00:35 2009 Subject: [GHC] #3745: Non-deterministic behavior with FFI In-Reply-To: <048.13932c70c5ac7d2182ef99747868ffe2@localhost> References: <048.13932c70c5ac7d2182ef99747868ffe2@localhost> Message-ID: <057.da9571b07a1963a7b09e457578e4f3af@localhost> #3745: Non-deterministic behavior with FFI ------------------------------------------+--------------------------------- Reporter: gchrupala | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.2 Component: Compiler (FFI) | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Incorrect result at runtime | ------------------------------------------+--------------------------------- Changes (by simonmar): * priority: normal => high * difficulty: => * milestone: => 6.12.2 Comment: Thanks for the report, we'll look into it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 14 04:36:05 2009 From: trac at galois.com (GHC) Date: Mon Dec 14 04:10:20 2009 Subject: [GHC] #3747: getDirectoryContents yields wrong results In-Reply-To: <045.150fa620f12a57939f825d5ce3665862@localhost> References: <045.150fa620f12a57939f825d5ce3665862@localhost> Message-ID: <054.a7c1a3df694f08b32eaa154d5d137976@localhost> #3747: getDirectoryContents yields wrong results ------------------------------------------+--------------------------------- Reporter: Meddix | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/directory | Version: 6.10.4 Resolution: invalid | Keywords: Difficulty: | Os: Windows Testcase: getDirectoryContents "c:" | Architecture: x86 Failure: Incorrect result at runtime | ------------------------------------------+--------------------------------- Comment (by Meddix): Of course. I should have investigated myself this strange behaviour. Sorry for the misunderstanding. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 14 04:36:27 2009 From: trac at galois.com (GHC) Date: Mon Dec 14 04:10:35 2009 Subject: [GHC] #3065: Reorder tests in quot to improve code In-Reply-To: <046.819ea32d4c70bd7d14e7ef168534bbea@localhost> References: <046.819ea32d4c70bd7d14e7ef168534bbea@localhost> Message-ID: <055.f3d4e298bc14feae58dab3b4e49df500@localhost> #3065: Reorder tests in quot to improve code --------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: libraries/base | Version: 6.10.1 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Runtime performance bug | --------------------------------------+------------------------------------- Comment (by simonmar): Currently the meaning of overflow in division is to throw a (software) exception at runtime. If we were to change the meaning of overflow in division to be truncation instead, and to apply that consistently, then yes I agree with you that the test in quot is only necessary on some processors, and therefore arguably should be in the NCG. I'd be happy to make that change, although I did suggest it before (in the comments on #1042) and Ian argued for an exception instead, hence the current behaviour. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 14 04:57:31 2009 From: trac at galois.com (GHC) Date: Mon Dec 14 04:31:38 2009 Subject: [GHC] #3065: Reorder tests in quot to improve code In-Reply-To: <046.819ea32d4c70bd7d14e7ef168534bbea@localhost> References: <046.819ea32d4c70bd7d14e7ef168534bbea@localhost> Message-ID: <055.6372eaabb24264a0d33fc3ad7f430331@localhost> #3065: Reorder tests in quot to improve code --------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: libraries/base | Version: 6.10.1 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Runtime performance bug | --------------------------------------+------------------------------------- Comment (by igloo): I don't feel strongly about the behaviour. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 14 06:03:36 2009 From: trac at galois.com (GHC) Date: Mon Dec 14 05:37:44 2009 Subject: [GHC] #3749: unexpected parse errors with `do` and `let` In-Reply-To: <049.d2a0e47bc50eb214cb0f82d8928bca57@localhost> References: <049.d2a0e47bc50eb214cb0f82d8928bca57@localhost> Message-ID: <058.49d1503c3c43a120d765bc5b10072c23@localhost> #3749: unexpected parse errors with `do` and `let` ----------------------------------------+----------------------------------- Reporter: dherington | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: invalid | Keywords: do, let, parse error Difficulty: | Os: Windows Testcase: | Architecture: x86 Failure: GHC rejects valid program | ----------------------------------------+----------------------------------- Changes (by simonmar): * status: new => closed * difficulty: => * resolution: => invalid Comment: On what grounds do you think `f2` and `f3` should be syntactically correct? In both cases, the semi-colon and `return x` are part of the `let`, not part of the `do`. The layout rule would need multi-token lookahead in order to determine the alternative parse (inserting a close brace before the `;`), and it doesn't do that. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 14 06:12:07 2009 From: trac at galois.com (GHC) Date: Mon Dec 14 05:46:12 2009 Subject: [GHC] #3751: Panic! the 'impossible' happened: charType: '\167' Message-ID: <053.09139966f34278370b63f1b3d0e8a13b@localhost> #3751: Panic! the 'impossible' happened: charType: '\167' -------------------------------+-------------------------------------------- Reporter: moleculeColony | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Keywords: lexical error Os: Linux | Testcase: Architecture: x86_64 (amd64) | Failure: GHCi crash -------------------------------+-------------------------------------------- Reproduces each time: Prelude> "\?" ghc: panic! (the 'impossible' happened) (GHC version 6.10.4 for x86_64-unknown-linux): charType: '\167' 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 Dec 14 06:13:38 2009 From: trac at galois.com (GHC) Date: Mon Dec 14 05:47:43 2009 Subject: [GHC] #3751: Panic! the 'impossible' happened: charType: '\167' In-Reply-To: <053.09139966f34278370b63f1b3d0e8a13b@localhost> References: <053.09139966f34278370b63f1b3d0e8a13b@localhost> Message-ID: <062.9a464d2e08b0b9e1fc553cd1eca4affa@localhost> #3751: Panic! the 'impossible' happened: charType: '\167' -------------------------------+-------------------------------------------- Reporter: moleculeColony | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: lexical error Os: Linux | Testcase: Architecture: x86_64 (amd64) | Failure: GHCi crash -------------------------------+-------------------------------------------- Comment (by moleculeColony): For some reason the line break after "\?" is gone here. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 14 06:15:19 2009 From: trac at galois.com (GHC) Date: Mon Dec 14 05:49:24 2009 Subject: [GHC] #3751: Panic! the 'impossible' happened: charType: '\167' In-Reply-To: <053.09139966f34278370b63f1b3d0e8a13b@localhost> References: <053.09139966f34278370b63f1b3d0e8a13b@localhost> Message-ID: <062.1770f087a3a6e1770c9ece05d4b41c5b@localhost> #3751: Panic! the 'impossible' happened: charType: '\167' -------------------------------+-------------------------------------------- Reporter: moleculeColony | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: lexical error Os: Linux | Testcase: Architecture: x86_64 (amd64) | Failure: GHCi crash -------------------------------+-------------------------------------------- Comment (by moleculeColony): Test: Leaving GHCi. erich@Computer:~$ "\?" \?: command not found erich@Computer:~$ -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 14 06:17:13 2009 From: trac at galois.com (GHC) Date: Mon Dec 14 05:51:18 2009 Subject: [GHC] #3751: Panic! the 'impossible' happened: charType: '\167' In-Reply-To: <053.09139966f34278370b63f1b3d0e8a13b@localhost> References: <053.09139966f34278370b63f1b3d0e8a13b@localhost> Message-ID: <062.0f1a134aad56f4fd265b744f5a2094cc@localhost> #3751: Panic! the 'impossible' happened: charType: '\167' -------------------------------+-------------------------------------------- Reporter: moleculeColony | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: lexical error Os: Linux | Testcase: Architecture: x86_64 (amd64) | Failure: GHCi crash -------------------------------+-------------------------------------------- Comment (by moleculeColony): One more: Prelude> "\?" ghc: panic! (the 'impossible' happened) (GHC version 6.10.4 for x86_64-unknown-linux): charType: '\167' Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Prelude> -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 14 06:18:19 2009 From: trac at galois.com (GHC) Date: Mon Dec 14 05:52:24 2009 Subject: [GHC] #3751: Panic! the 'impossible' happened: charType: '\167' In-Reply-To: <053.09139966f34278370b63f1b3d0e8a13b@localhost> References: <053.09139966f34278370b63f1b3d0e8a13b@localhost> Message-ID: <062.7cdbe60177ea9df9680caa9bfa8a94d0@localhost> #3751: Panic! the 'impossible' happened: charType: '\167' -------------------------------+-------------------------------------------- Reporter: moleculeColony | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: lexical error Os: Linux | Testcase: Architecture: x86_64 (amd64) | Failure: GHCi crash -------------------------------+-------------------------------------------- Comment (by moleculeColony): Funny. Prelude> :q Leaving GHCi. erich@Computer:~$ ghci GHCi, version 6.10.4: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Prelude> -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 14 06:19:34 2009 From: trac at galois.com (GHC) Date: Mon Dec 14 05:53:41 2009 Subject: [GHC] #3751: Panic! the 'impossible' happened: charType: '\167' In-Reply-To: <053.09139966f34278370b63f1b3d0e8a13b@localhost> References: <053.09139966f34278370b63f1b3d0e8a13b@localhost> Message-ID: <062.b4402e933af61752049673014c00cff9@localhost> #3751: Panic! the 'impossible' happened: charType: '\167' -------------------------------+-------------------------------------------- Reporter: moleculeColony | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: lexical error Os: Linux | Testcase: Architecture: x86_64 (amd64) | Failure: GHCi crash -------------------------------+-------------------------------------------- Comment (by moleculeColony): The last one. Prelude> :cd Haskell Prelude> :l Colony [1 of 1] Compiling Colony ( Colony.hs, interpreted ) Ok, modules loaded: Colony. *Colony> -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 14 06:38:26 2009 From: trac at galois.com (GHC) Date: Mon Dec 14 06:12:47 2009 Subject: [GHC] #3748: Bug in rts/Win32/Ticker.c can cause process hang on exit in Win32 In-Reply-To: <042.ebc1303ba4ba1bb01245ae57d2b8c614@localhost> References: <042.ebc1303ba4ba1bb01245ae57d2b8c614@localhost> Message-ID: <051.524281be23e4fc4ee98f48ff79de35a7@localhost> #3748: Bug in rts/Win32/Ticker.c can cause process hang on exit in Win32 -----------------------------+---------------------------------------------- Reporter: sgf | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Windows Testcase: | Architecture: Unknown/Multiple Failure: Runtime crash | -----------------------------+---------------------------------------------- Changes (by simonmar): * difficulty: => Comment: Urgh, that's horrible :) Your proposed solution seems reasonable. The only way I know of to tell whether this is a DLL or an executable is the argument to `hs_exit_`, which is true if it was called via `hs_exit()`, and false if it was called as a result of a standalone program exiting. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 14 06:40:49 2009 From: trac at galois.com (GHC) Date: Mon Dec 14 06:14:55 2009 Subject: [GHC] #3751: Panic! the 'impossible' happened: charType: '\167' In-Reply-To: <053.09139966f34278370b63f1b3d0e8a13b@localhost> References: <053.09139966f34278370b63f1b3d0e8a13b@localhost> Message-ID: <062.4c1f9f7d000fa87bc5c89aaf724f0ca0@localhost> #3751: Panic! the 'impossible' happened: charType: '\167' -----------------------------+---------------------------------------------- Reporter: moleculeColony | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: lexical error Difficulty: | Os: Linux Testcase: | Architecture: x86_64 (amd64) Failure: GHCi crash | -----------------------------+---------------------------------------------- Changes (by igloo): * difficulty: => Comment: If you're trying to work out what's happening with the layout, the answer is that you need to wrap things like ghci sessions in `{{{` and `}}}`. See [wiki:WikiFormatting] for more info. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 14 06:41:04 2009 From: trac at galois.com (GHC) Date: Mon Dec 14 06:15:09 2009 Subject: [GHC] #3751: Panic! the 'impossible' happened: charType: '\167' In-Reply-To: <053.09139966f34278370b63f1b3d0e8a13b@localhost> References: <053.09139966f34278370b63f1b3d0e8a13b@localhost> Message-ID: <062.80a672c5035fbcdf816d5f5dadad2279@localhost> #3751: Panic! the 'impossible' happened: charType: '\167' -----------------------------+---------------------------------------------- Reporter: moleculeColony | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: lexical error Difficulty: | Os: Linux Testcase: | Architecture: x86_64 (amd64) Failure: GHCi crash | -----------------------------+---------------------------------------------- Old description: > Reproduces each time: > > Prelude> "\?" > ghc: panic! (the 'impossible' happened) > (GHC version 6.10.4 for x86_64-unknown-linux): > charType: '\167' > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug New description: Reproduces each time: {{{ Prelude> "\?" ghc: panic! (the 'impossible' happened) (GHC version 6.10.4 for x86_64-unknown-linux): charType: '\167' 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 Dec 14 12:47:17 2009 From: trac at galois.com (GHC) Date: Mon Dec 14 12:21:32 2009 Subject: [GHC] #3472: Porting through .hc files broken In-Reply-To: <046.fbcd146ac7544c3ae31be3ef2ccbd0d8@localhost> References: <046.fbcd146ac7544c3ae31be3ef2ccbd0d8@localhost> Message-ID: <055.43940de80a47bfeec477494d305176d3@localhost> #3472: Porting through .hc files broken ---------------------------+------------------------------------------------ Reporter: pumpkin | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Build System | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by PHO): * cc: pho@cielonegro.org (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 14 14:23:28 2009 From: trac at galois.com (GHC) Date: Mon Dec 14 13:57:32 2009 Subject: [GHC] #3752: 6.12.1 release notes have bad url for Haskell Platrofm Message-ID: <042.9b41845335d01edddf1d93fe361a05ea@localhost> #3752: 6.12.1 release notes have bad url for Haskell Platrofm ---------------------------------+------------------------------------------ Reporter: jgd | Owner: Type: bug | Status: new Priority: normal | Component: Documentation Version: 6.12.1 RC1 | Keywords: release notes, bad url Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Documentation bug ---------------------------------+------------------------------------------ As the Haskell Platform is suddenly critical to ghc, it would be good to fix this bug right away. On the page http://haskell.org/ghc/docs/6.12.1/html/users_guide/release-6-12-1.html is the url http://hackage.haskell.org/platformi/ which produces a 404 error. For the future, I suggest running a link checker against the web pages after changing them - I've learned that the hard way! _Greg P.S. The correct "Version" 6.12.1 is not yet available for this ticket so I'm using 6.12.1RC1 - I'm guessing this will get fixed soon! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 14 14:30:22 2009 From: trac at galois.com (GHC) Date: Mon Dec 14 14:04:26 2009 Subject: [GHC] #3752: 6.12.1 release notes have bad url for Haskell Platrofm In-Reply-To: <042.9b41845335d01edddf1d93fe361a05ea@localhost> References: <042.9b41845335d01edddf1d93fe361a05ea@localhost> Message-ID: <051.54c992db6a8144bce605029e4b2333ee@localhost> #3752: 6.12.1 release notes have bad url for Haskell Platrofm --------------------------------+------------------------------------------- Reporter: jgd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 6.12.1 Resolution: | Keywords: release notes, bad url Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Documentation bug | --------------------------------+------------------------------------------- Changes (by igloo): * difficulty: => * version: 6.12.1 RC1 => 6.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 14 14:33:46 2009 From: trac at galois.com (GHC) Date: Mon Dec 14 14:07:50 2009 Subject: [GHC] #3752: 6.12.1 release notes have bad url for Haskell Platrofm In-Reply-To: <042.9b41845335d01edddf1d93fe361a05ea@localhost> References: <042.9b41845335d01edddf1d93fe361a05ea@localhost> Message-ID: <051.a59a7540232eccab60013a7efaf56b4f@localhost> #3752: 6.12.1 release notes have bad url for Haskell Platrofm --------------------------------+------------------------------------------- Reporter: jgd | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 6.12.1 Resolution: fixed | Keywords: release notes, bad url Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Documentation bug | --------------------------------+------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Thanks for the report; I've added a redirect (as the release notes are also in the binary downloads etc). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 14 14:43:37 2009 From: trac at galois.com (GHC) Date: Mon Dec 14 14:17:44 2009 Subject: [GHC] #650: Improve interaction between mutable arrays and GC In-Reply-To: <047.44b951cd4b5aa8536d862412c8d86597@localhost> References: <047.44b951cd4b5aa8536d862412c8d86597@localhost> Message-ID: <056.995577fb84770d3db04de0e3a83fa79f@localhost> #650: Improve interaction between mutable arrays and GC -----------------------------------------+---------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Runtime System | Version: 6.4.1 Resolution: | Keywords: Difficulty: Moderate (less than a day) | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Runtime performance bug | -----------------------------------------+---------------------------------- Changes (by blarsen): * cc: blarsen (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 15 01:40:07 2009 From: trac at galois.com (GHC) Date: Tue Dec 15 01:14:13 2009 Subject: [GHC] #3749: unexpected parse errors with `do` and `let` In-Reply-To: <049.d2a0e47bc50eb214cb0f82d8928bca57@localhost> References: <049.d2a0e47bc50eb214cb0f82d8928bca57@localhost> Message-ID: <058.716bd9c67e896287d2fdaf53b2f0655e@localhost> #3749: unexpected parse errors with `do` and `let` ----------------------------------------+----------------------------------- Reporter: dherington | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: invalid | Keywords: do, let, parse error Difficulty: | Os: Windows Testcase: | Architecture: x86 Failure: GHC rejects valid program | ----------------------------------------+----------------------------------- Comment (by dherington): Ah, yes, of course! Thanks for setting me straight, and apologies for the noise. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 15 01:47:07 2009 From: trac at galois.com (GHC) Date: Tue Dec 15 01:21:12 2009 Subject: [GHC] #3720: unknown symbol `_GLOBAL_OFFSET_TABLE_' when loading module In-Reply-To: <044.c8fe00d0df86676aef8470e80da77abf@localhost> References: <044.c8fe00d0df86676aef8470e80da77abf@localhost> Message-ID: <053.a93aa5e817cb74ccd37cae41c0563842@localhost> #3720: unknown symbol `_GLOBAL_OFFSET_TABLE_' when loading module ---------------------+------------------------------------------------------ Reporter: fasta | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Other | ---------------------+------------------------------------------------------ Comment (by secludedsage): Are you using PIE? I mean something like hardened toolchain? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 15 02:41:55 2009 From: trac at galois.com (GHC) Date: Tue Dec 15 02:16:17 2009 Subject: [GHC] #2031: relocation overflow In-Reply-To: <045.02b5c8981d759aa3391df46bf05998bf@localhost> References: <045.02b5c8981d759aa3391df46bf05998bf@localhost> Message-ID: <054.b44c071e7b854336a4e20752b49bfd20@localhost> #2031: relocation overflow ---------------------------+------------------------------------------------ Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.8.2 Resolution: | Keywords: Difficulty: Unknown | Os: MacOS X Testcase: | Architecture: powerpc Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by PHO): * cc: pho@cielonegro.org (added) * failure: => None/Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 15 04:50:28 2009 From: trac at galois.com (GHC) Date: Tue Dec 15 04:24:31 2009 Subject: [GHC] #3753: Make ghci's -l option consistent with GNU ld's -l option Message-ID: <046.21a3b8e0ae623770f7106f301bc229f6@localhost> #3753: Make ghci's -l option consistent with GNU ld's -l option ---------------------------------+------------------------------------------ Reporter: hgolden | Owner: Type: feature request | Status: new Priority: normal | Component: GHCi Version: 6.12.1 | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Currently, ghci accepts -l options of the format -lxyz. On Linux, this is treated as a request for libxyz.so. The GNU ld -l option is more flexible. It accepts either -lxyz or -l xyz. Also, it accepts -l:filename or -l :filename. When this form is used, the filename is not modified by prepending "lib" and appending ".so". I request that GNU ld's -l forms be accepted by ghci. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 15 05:00:58 2009 From: trac at galois.com (GHC) Date: Tue Dec 15 04:35:09 2009 Subject: [GHC] #3754: broken link in documentation Message-ID: <068.11e88f7687fde0a8343b6e97dc1731e1@localhost> #3754: broken link in documentation ----------------------------------------------+----------------------------- Reporter: malcolm.wallace@cs.york.ac.uk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 6.12.1 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Documentation bug ----------------------------------------------+----------------------------- The page http://www.haskell.org/ghc/docs/latest/html/users_guide/pragmas.html #language-pragma contains a broken link to http://www.haskell.org/ghc/docs/latest/html/libraries/Cabal/Language- Haskell-Extension.html which does not exist. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 15 05:57:03 2009 From: trac at galois.com (GHC) Date: Tue Dec 15 05:31:06 2009 Subject: [GHC] #3755: Improve join point inlining Message-ID: <046.29f65772931b3d82df31cb86d07a2ef5@localhost> #3755: Improve join point inlining ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.12.1 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Runtime performance bug ---------------------------------+------------------------------------------ This ticket relates to the paper "Optimising generics is easy" http://www.dreixel.net/research/pdf/ogie.pdf. Jose writes (about a case where inlining doesn't work well): I put a minimal source code for this test and resulting Core (with GHC 6.13.20091115) in https://subversion.cs.uu.nl/repos/staff.jpm.public/Inline/. `UpdateInt` behaves great: in `UpdateInt.core.O1.hs`, there are no traces of generic representations in testOne, testTwo, testThree and testFour. `UpdateString`, however, does not behave so well. In `UpdateString.core.O1.hs`, `Test.testLogic_updateString` still has loads of generic representations. It's easy to see what is happening. Compile `UpdateString` (which I've attached to this ticket) with `-ddump-simpl`, and look at the core. You see stuff like {{{ Rec { $j1_rx32 = \x. ; f = \y. ....($j1_rx32 ) ---($j1_rx32 e1; ... Ck xk1 ... xkm -> ek } }}} maybe we should worker-wrapper it to {{{ f1 x1 .. x1n = e1 ... fn xk1 .. xkm = en f = \x of pi -> fi xi }}} and now inline f. The net effect is very similar to the way join points work right now, but it would make it multi-level. In fact, doing this might simplify and generalise the way that join points are currently done, where (rather arbitrarily) we duplicate the outer layer of a single case. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 15 06:50:53 2009 From: trac at galois.com (GHC) Date: Tue Dec 15 06:24:55 2009 Subject: [GHC] #3756: Missing -lz option in testsuite Message-ID: <056.ed7c6d1c92de3c6183484ea552e08336@localhost> #3756: Missing -lz option in testsuite ----------------------------------+----------------------------------------- Reporter: daniel.is.fischer | Owner: Type: bug | Status: new Priority: normal | Component: Test Suite Version: 6.12.1 | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Other ----------------------------------+----------------------------------------- Running the testsuite with a newly built 6.12.1, I got {{{ OVERALL SUMMARY for test run started at Mo 14. Dez 18:06:00 CET 2009 ? ? 2352 total tests, which gave rise to ? ?13034 test cases, of which ? ? ? ?0 caused framework failures ? ? 2760 were skipped ? ? 9471 expected passes ? ? ?328 expected failures ? ? ? ?0 unexpected passes ? ? ?475 unexpected failures }}} All but 8 (unless I miscounted) of the unexpected failures were in way threaded1, the overwhelming majority due to {{{ /usr/src/packages/BUILD/binutils-2.19/build- dir/bfd/../../bfd/compress.c:96:0: ? ? ?undefined reference to `inflateInit_' /usr/src/packages/BUILD/binutils-2.19/build- dir/bfd/../../bfd/compress.c:103:0: ? ? ?undefined reference to `inflate' /usr/src/packages/BUILD/binutils-2.19/build- dir/bfd/../../bfd/compress.c:106:0: ? ? ?undefined reference to `inflateReset' /usr/src/packages/BUILD/binutils-2.19/build- dir/bfd/../../bfd/compress.c:108:0: ? ? ?undefined reference to `inflateEnd' collect2: ld returned 1 exit status *** unexpected failure for fileStatus(threaded1) }}} That looks like a missing -lz option in the testsuite. Adding "EXTRA_HC_OPTS += -optl-lz" to test.mk and running "make stage=2 WAY=threaded1" produced {{{ OVERALL SUMMARY for test run started at Di 15. Dez 12:18:20 CET 2009 2352 total tests, which gave rise to 13034 test cases, of which 0 caused framework failures 12545 were skipped 467 expected passes 19 expected failures 0 unexpected passes 3 unexpected failures Unexpected failures: 2317(threaded1) galois_raytrace(threaded1) qq005(threaded1) }}} which seems to confirm the suspicion. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 15 08:45:17 2009 From: trac at galois.com (GHC) Date: Tue Dec 15 08:19:20 2009 Subject: [GHC] #3756: Missing -lz option in testsuite In-Reply-To: <056.ed7c6d1c92de3c6183484ea552e08336@localhost> References: <056.ed7c6d1c92de3c6183484ea552e08336@localhost> Message-ID: <065.7381a2fd84a80b4eec66d503584261cf@localhost> #3756: Missing -lz option in testsuite ----------------------------------+----------------------------------------- Reporter: daniel.is.fischer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 6.12.1 Resolution: | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Other ----------------------------------+----------------------------------------- Comment (by daniel.is.fischer): Also: galois_raytrace fails with {{{ Compile failed (status 256) errors were: : cannot satisfy -package parsec (use -v for more information) *** unexpected failure for galois_raytrace(normal) }}} What's best to do about tests needing packages no longer included? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 15 11:16:08 2009 From: trac at galois.com (GHC) Date: Tue Dec 15 10:50:10 2009 Subject: [GHC] #3756: Missing -lz option in testsuite In-Reply-To: <056.ed7c6d1c92de3c6183484ea552e08336@localhost> References: <056.ed7c6d1c92de3c6183484ea552e08336@localhost> Message-ID: <065.061f3cc739ecb87640f20dd18430c04b@localhost> #3756: Missing -lz option in testsuite ----------------------------------+----------------------------------------- Reporter: daniel.is.fischer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 6.12.1 Resolution: | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Other ----------------------------------+----------------------------------------- Comment (by daniel.is.fischer): Further unexpected failures due to packages no longer included: {{{ =====> 2317(normal) cd ./concurrent/2317 && '/home/dafis/GHC121/ghc-6.12.1/inplace/bin/ghc- stage2' -fforce-recomp -dcore-lint -dcmm-lint -no-user-package-conf -optl-lz -dno-debug-output --make -o 2317 2317 >2317.comp.stderr 2>&1 Compile failed (status 256) errors were: 2317.hs:4:7: Could not find module `Control.Parallel': Use -v to see a list of the files searched for. *** unexpected failure for 2317(normal) =====> pkg02(normal) cd ./cabal/pkg02 && '/home/dafis/GHC121/ghc-6.12.1/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -no-user-package-conf -optl-lz -dno-debug-output --make -o pkg02 A -v0 >pkg02.comp.stderr 2>&1 Compile failed (status 256) errors were: A.hs:3:7: Could not find module `Network.Socket': Use -v to see a list of the files searched for. *** unexpected failure for pkg02(normal) =====> qq005(normal) cd ./quasiquotation/qq005 && '/home/dafis/GHC121/ghc-6.12.1/inplace/bin /ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -no-user-package-conf -optl-lz -dno- debug-output --make -o qq005 Main >qq005.comp.stderr 2>&1 Compile failed (status 256) errors were: Expr.hs:9:7: Could not find module `Text.ParserCombinators.Parsec.Char': Use -v to see a list of the files searched for. *** unexpected failure for qq005(normal) =====> qq006(normal) cd ./quasiquotation/qq006 && '/home/dafis/GHC121/ghc-6.12.1/inplace/bin /ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -no-user-package-conf -optl-lz -dno- debug-output --make -o qq006 Main -v0 >qq006.comp.stderr 2>&1 Actual stderr output differs from expected: --- ./quasiquotation/qq006/qq006.stderr.normalised 2009-12-15 13:47:10.000000000 +0100 +++ ./quasiquotation/qq006/qq006.comp.stderr.normalised 2009-12-15 13:47:10.000000000 +0100 @@ -1,4 +1,4 @@ -Main.hs:8:20: - Conflicting definitions for `x' - In a case alternative +Expr.hs:9:7: + Could not find module `Text.ParserCombinators.Parsec.Char': + Use -v to see a list of the files searched for. *** unexpected failure for qq006(normal) }}} Expected (?) failures due to packages not present: {{{ okeefe_neural: lang galois_raytrace: parsec cg025: regex-compat SampleVar001, Chan001, MVar001, QSemN001, QSem001, ghci014, maessen_hashtab: QuickCheck regex001, regex002, regex003: regex-posix dynamic002, packedstring001: packedstring 2185: parallel }}} Probably they should have failed for other reasons. More interesting unexpected failures: {{{ =====> T1969(normal) cd ./perf/compiler && '/home/dafis/GHC121/ghc-6.12.1/inplace/bin/ghc- stage2' -fforce-recomp -dcore-lint -dcmm-lint -no-user-package-conf -optl-lz -dno-debug-output -c T1969.hs +RTS -V0 -tT1969.comp.stats --machine-readable -RTS >T1969.comp.stderr 2>&1 bytes allocated 209182332 is less than minimum allowed 210000000 If this is because you have improved GHC, please update the test so that GHC doesn't regress again *** unexpected failure for T1969(normal) =====> annrun01(dyn) cd ./annotations/should_run && '/home/dafis/GHC121/ghc-6.12.1/inplace/bin /ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -no-user-package-conf -optl-lz -dno- debug-output --make -o annrun01 annrun01 -O -dynamic -package ghc >annrun01.comp.stderr 2>&1 Compile failed (status 256) errors were: [1 of 3] Compiling Annrun01_Help ( Annrun01_Help.hs, Annrun01_Help.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package array-0.3.0.0 ... linking ... done. Loading package containers-0.3.0.0 ... linking ... done. Loading package filepath-1.1.0.3 ... linking ... done. Loading package old-locale-1.0.0.2 ... linking ... done. Loading package old-time-1.0.0.3 ... linking ... done. Loading package unix-2.4.0.0 ... linking ... done. Loading package directory-1.0.1.0 ... linking ... done. Loading package pretty-1.0.1.1 ... linking ... done. Loading package process-1.0.1.2 ... linking ... done. Loading package Cabal-1.8.0.2 ... linking ... done. Loading package bytestring-0.9.1.5 ... linking ... done. Loading package ghc-binary-0.5.0.2 ... linking ... done. Loading package bin-package-db-0.0.0.0 ... linking ... done. Loading package hpc-0.5.0.4 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package ghc-6.12.1 ... linking ... done. Loading package ffi-1.0 ... linking ... done. Loading object (dynamic) z ... done final link ... done Annrun01_Help.hs:26:0: Dynamic linking required, but this is a non-standard build (eg. prof). You need to build the program twice: once the normal way, and then in the desired way using -osuf to set the object file suffix. *** unexpected failure for annrun01(dyn) =====> barton-mangler-bug(profc) cd ./programs/barton-mangler-bug && '/home/dafis/GHC121/ghc-6.12.1/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -no-user-package-conf -optl-lz -dno- debug-output --make -o barton-mangler-bug Main -O -prof -auto-all -fvia-C >barton-mangler- bug.comp.stderr 2>&1 Compile failed (status 25344) errors were: [1 of 7] Compiling Plot ( Plot.lhs, Plot.o ) [2 of 7] Compiling Expected ( Expected.hs, Expected.o ) *** unexpected failure for barton-mangler-bug(profc) =====> break024(ghci) cd ./ghci.debugger/scripts && HC='/home/dafis/GHC121/ghc-6.12.1/inplace/bin/ghc-stage2' HC_OPTS='-dcore-lint -dcmm-lint -no-user-package-conf -optl-lz -dno-debug- output ' '/home/dafis/GHC121/ghc-6.12.1/inplace/bin/ghc-stage2' --interactive -v0 -ignore-dot-ghci -dcore-lint -dcmm-lint -no-user-package-conf -optl-lz -dno-debug-output -ignore-dot-ghci break024.run.stdout 2>break024.run.stderr Actual stdout output differs from expected: --- ./ghci.debugger/scripts/break024.stdout.normalised 2009-12-15 15:05:51.000000000 +0100 +++ ./ghci.debugger/scripts/break024.run.stdout.normalised 2009-12-15 15:05:51.000000000 +0100 @@ -1,20 +1,26 @@ Left user error (error) Stopped at -_exception :: e = _ +_exception :: e = SomeException (GHC.Exception.D:Exception _ + (GHC.Show.D:Show ...) ....) + (GHC.IO.Exception.IOError Nothing GHC.IO.Exception.UserError ....) _exception = SomeException (GHC.Exception.D:Exception _ (GHC.Show.D:Show _ _ _) _ _) (GHC.IO.Exception.IOError Nothing GHC.IO.Exception.UserError [] ['e','r','r','o','r'] Nothing Nothing) *** Exception: user error (error) Stopped at -_exception :: e = _ +_exception :: e = SomeException (GHC.Exception.D:Exception _ + (GHC.Show.D:Show ...) ....) + (GHC.IO.Exception.IOError Nothing GHC.IO.Exception.UserError ....) _exception = SomeException (GHC.Exception.D:Exception _ (GHC.Show.D:Show _ _ _) _ _) (GHC.IO.Exception.IOError Nothing GHC.IO.Exception.UserError [] ['e','r','r','o','r'] Nothing Nothing) *** Exception: user error (error) Stopped at -_exception :: e = _ +_exception :: e = SomeException (GHC.Exception.D:Exception _ + (GHC.Show.D:Show ...) ....) + (GHC.IO.Exception.IOError Nothing GHC.IO.Exception.UserError ....) _exception = SomeException (GHC.Exception.D:Exception _ (GHC.Show.D:Show _ _ _) _ _) (GHC.IO.Exception.IOError Nothing GHC.IO.Exception.UserError [] *** unexpected failure for break024(ghci) =====> conc012(ghci) cd ./concurrent/should_run && '/home/dafis/GHC121/ghc-6.12.1/inplace/bin /ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -no-user-package-conf -optl-lz -dno- debug-output conc012.hs --interactive -v0 -ignore-dot-ghci +RTS -I0.1 -RTS conc012.interp.stdout 2>conc012.interp.stderr Wrong exit code (expected 0 , actual 99 ) Stdout: Stderr: *** unexpected failure for conc012(ghci) =====> rtsflags001(normal) cd ./rts && '/home/dafis/GHC121/ghc-6.12.1/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -no-user-package-conf -optl-lz -dno-debug-output -o rtsflags001 rtsflags001.hs >rtsflags001.comp.stderr 2>&1 cd ./rts && ./rtsflags001 +RTS -H0m -RTS rtsflags001.run.stdout 2>rtsflags001.run.stderr Wrong exit code (expected 1 , actual 0 ) Stdout: Stderr: *** unexpected failure for rtsflags001(normal) }}} The overall result with -optl-lz is {{{ OVERALL SUMMARY for test run started at Di 15. Dez 12:50:40 CET 2009 2352 total tests, which gave rise to 13034 test cases, of which 0 caused framework failures 2760 were skipped 9940 expected passes 296 expected failures 0 unexpected passes 38 unexpected failures Unexpected failures: 2317(normal,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,dyn,profthreaded) T1969(normal) annrun01(dyn) barton-mangler-bug(profc) break024(ghci) conc012(ghci) galois_raytrace(normal,optc,profc,ghci,threaded1,dyn) pkg02(normal,optc,hpc,optasm,profc,profasm) qq005(normal,optc,hpc,optasm,ghci,threaded1,threaded2,dyn) qq006(normal) rtsflags001(normal) }}} Only six of the unexpected failures are not due to an absent package. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 15 11:50:02 2009 From: trac at galois.com (GHC) Date: Tue Dec 15 11:24:06 2009 Subject: [GHC] #3757: panic: Kinds don't match in type application Message-ID: <056.3b3a9a6f534f222e1dcea97530deadf0@localhost> #3757: panic: Kinds don't match in type application ----------------------------------+----------------------------------------- Reporter: daniel.is.fischer | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.12.1 | Keywords: Os: Linux | Testcase: Architecture: x86 | Failure: None/Unknown ----------------------------------+----------------------------------------- In the test !CoTest3(normal) from the testsuite, I get {{{ Compile failed (status 256) errors were: *** Core Lint Errors: in result of Simplifier mode 0 [final], iteration 1 out of 4 *** : In the expression: (a_sfH `cast` ((trans (trans s1_aeP GHC.Types.Int) Kinds don't match in type application: Type variable: co_wild_Xe :: trans (trans s1_aeP s2_aeQ ~ GHC.Types.Int Arg type:ghc-stage2: panic! (the 'impossible' happened) (GHC version 6.12.1 for i386-unknown-linux): No match in record selector tyConKind Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} It seems to be the same expression as in http://darcs.haskell.org/buildbot/all/builders/x86%20Windows%20stable%20fast/builds/4253/steps/runtestsuite/logs/unexpected -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 15 11:57:48 2009 From: trac at galois.com (GHC) Date: Tue Dec 15 11:31:49 2009 Subject: [GHC] #3757: panic: Kinds don't match in type application In-Reply-To: <056.3b3a9a6f534f222e1dcea97530deadf0@localhost> References: <056.3b3a9a6f534f222e1dcea97530deadf0@localhost> Message-ID: <065.81340d3bd87d361cf6f2176deeb90fdb@localhost> #3757: panic: Kinds don't match in type application --------------------------------+------------------------------------------- Reporter: daniel.is.fischer | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.12.1 Resolution: | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86 Failure: None/Unknown | --------------------------------+------------------------------------------- Changes (by simonpj): * owner: => igloo * difficulty: => Comment: Good point. This is a test I added when stressing the HEAD harder with type equality coercions. I'm not precisely sure which patches are involved, and I propose not to fix it on the branch. (If it starts cropping up for real in the branch we can address it.) Ian: maybe turn this test into expect-fail for 6.12. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 15 12:04:36 2009 From: trac at galois.com (GHC) Date: Tue Dec 15 11:38:40 2009 Subject: [GHC] #3750: nameModule $wlookup_nm In-Reply-To: <047.4ee4e029b449041cfea8d5742bb324d0@localhost> References: <047.4ee4e029b449041cfea8d5742bb324d0@localhost> Message-ID: <056.843bf5f8e6623ccf5ea150e5ce3e7372@localhost> #3750: nameModule $wlookup_nm ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: closed Priority: high | Milestone: 6.14.1 Component: Compiler | Version: 6.13 Resolution: fixed | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Compile-time crash | ---------------------------------+------------------------------------------ Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: I believe this is OK now. The problem was something to do with a worker was getting substituted into a wrapper. But it seems to have gone away, and I'm not 100% sure why it ever happened. So keep an eye out! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 15 15:17:30 2009 From: trac at galois.com (GHC) Date: Tue Dec 15 14:51:50 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.84483b7ecccc114ad5a892ea2076e4cc@localhost> #2615: ghci doesn't play nice with linker scripts ------------------------------------------+--------------------------------- Reporter: AlecBerryman | Owner: hgolden Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: GHCi | Version: 6.10.1 Resolution: | Keywords: dlopen, dynamic linking Difficulty: Unknown | Os: Linux Testcase: | Architecture: Unknown/Multiple Failure: Incorrect result at runtime | ------------------------------------------+--------------------------------- Changes (by guest): * cc: ghc@henning-thielemann.de (added) Comment: I want to use the llvm package in GHCi. To this end I converted all of the libLLVM*.a files to local libLLVM*.so. When I start the main function of a Haskell program using LLVM functions then I get the known: {{{ Loading package llvm-0.6.7.0 ... can't load .so/.DLL for: pthread (/usr/lib/libpthread.so: invalid ELF header) }}} My libpthread.so is also a script like that shown by Christian Maeder. However, pthread is not mentioned in llvm wrapper source files. It only appears in the files generated by configuration. {{{ $ grep -r pthread . Match in binary file ./dist/setup/setup. ./config.status:S["llvm_ldflags"]="-L/usr/lib/llvm -lpthread -ldl -lm " ./config.status:S["LDFLAGS"]="-L/usr/lib/llvm -lpthread -ldl -lm " ./config.log:configure:3698: gcc -o conftest -g -O2 -I/usr/include -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -L/usr/lib/llvm -lpthread -ldl -lm conftest.c >&5 ./config.log:configure:4010: g++ -o conftest -g -O2 -I/usr/include -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -L/usr/lib/llvm -lpthread -ldl -lm conftest.c -lLLVMCore -lLLVMSupport -lLLVMSystem >&5 ./config.log:LDFLAGS='-L/usr/lib/llvm -lpthread -ldl -lm ' ./config.log:llvm_ldflags='-L/usr/lib/llvm -lpthread -ldl -lm ' ./llvm.buildinfo:ld-options: -L/usr/lib/llvm -lpthread -ldl -lm /usr/lib/llvm/LLVMX86AsmPrinter.o /usr/lib/llvm/LLVMX86CodeGen.o -lLLVMSelectionDAG -lLLVMAsmPrinter /usr/lib/llvm/LLVMExecutionEngine.o /usr/lib/llvm/LLVMJIT.o -lLLVMCodeGen -lLLVMScalarOpts -lLLVMTransformUtils -lLLVMipa -lLLVMAnalysis -lLLVMTarget -lLLVMCore -lLLVMSupport -lLLVMSystem -lstdc++ }}} Where do I have to remove pthread? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 15 15:20:23 2009 From: trac at galois.com (GHC) Date: Tue Dec 15 14:54:24 2009 Subject: [GHC] #3758: Huge regression in concurrent app performance and reliability under threaded runtime Message-ID: <042.942d2a7fe8a29f75a39eae02838820a0@localhost> #3758: Huge regression in concurrent app performance and reliability under threaded runtime -------------------------------+-------------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 6.12.1 | Keywords: Os: Linux | Testcase: Architecture: x86_64 (amd64) | Failure: Runtime crash -------------------------------+-------------------------------------------- I have a trivial HTTP server that I wrote to do some performance measurements with, and it behaves quite poorly for me under 6.12.1 if I try to use multiple cores. The symptoms are very low throughput and frequent hangs. I'm on a dual core 64-bit Linux system (Fedora 12). I have attached the server code that you can use to reproduce the problem. It requires the {{{network}}} and {{{network-bytestring}}} packages to function, but is otherwise standalone. Running it is easy: {{{ ghc -fforce-recomp -O --make Netbench ./Netbench localhost 8080 }}} I've been using the standard apachebench tool, {{{ab}}}, to stress the server: {{{ ab -c 10 -n 30000 http://localhost:8080/ }}} This hits the server with 10 concurrent requests for a total of 30,000 requests. Here are some throughput measurements: * 6.10.4, unthreaded RTS: 5539 req/sec * 6.10.4, threaded RTS, {{{-N1}}}: 7758 req/sec * 6.10.4, threaded RTS, {{{-N2}}}: 5856 req/sec * 6.12.1, unthreaded RTS: 5612 req/sec * 6.12.1, threaded RTS, {{{-N1}}}: 7437 req/sec * 6.12.1, threaded RTS, {{{-N2}}}: 1978 req/sec With {{{-N2}}} under 6.12.1, there is a high probability (> 50%) that the server will deadlock mid-run. When a multi-CPU run completes successfully under 6.12.1, {{{ab}}} reports that quite often a single request will get stuck for several seconds before the server responds. This does not seem to happen in other scenarios. If you would like any more details, please let me know. Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 15 15:26:11 2009 From: trac at galois.com (GHC) Date: Tue Dec 15 15:00:15 2009 Subject: [GHC] #3758: Huge regression in concurrent app performance and reliability under threaded runtime In-Reply-To: <042.942d2a7fe8a29f75a39eae02838820a0@localhost> References: <042.942d2a7fe8a29f75a39eae02838820a0@localhost> Message-ID: <051.87ed0c65746a0071d588588e478f5545@localhost> #3758: Huge regression in concurrent app performance and reliability under threaded runtime -------------------------------+-------------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.12.1 Resolution: | Keywords: Os: Linux | Testcase: Architecture: x86_64 (amd64) | Failure: Runtime crash -------------------------------+-------------------------------------------- Comment (by bos): Oops, sorry for the messy formatting of the allegedly bulleted lists. I tried! I can't figure out how to go back and tidy them up. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 15 15:29:22 2009 From: trac at galois.com (GHC) Date: Tue Dec 15 15:03:36 2009 Subject: [GHC] #3758: Huge regression in concurrent app performance and reliability under threaded runtime In-Reply-To: <042.942d2a7fe8a29f75a39eae02838820a0@localhost> References: <042.942d2a7fe8a29f75a39eae02838820a0@localhost> Message-ID: <051.1386cb4f8ebf3ee9eb600449e7a31b8f@localhost> #3758: Huge regression in concurrent app performance and reliability under threaded runtime -------------------------------+-------------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.12.1 Resolution: | Keywords: Os: Linux | Testcase: Architecture: x86_64 (amd64) | Failure: Runtime crash -------------------------------+-------------------------------------------- Changes (by bsdemon): * cc: 8mayday@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 15 15:36:10 2009 From: trac at galois.com (GHC) Date: Tue Dec 15 15:10:31 2009 Subject: [GHC] #3758: Huge regression in concurrent app performance and reliability under threaded runtime In-Reply-To: <042.942d2a7fe8a29f75a39eae02838820a0@localhost> References: <042.942d2a7fe8a29f75a39eae02838820a0@localhost> Message-ID: <051.f89a3fa7f1f9f4c0e44dc01e7250868b@localhost> #3758: Huge regression in concurrent app performance and reliability under threaded runtime -----------------------------+---------------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: Runtime System | Version: 6.12.1 Resolution: | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86_64 (amd64) Failure: Runtime crash | -----------------------------+---------------------------------------------- Changes (by igloo): * difficulty: => * milestone: => 6.12.2 Old description: > I have a trivial HTTP server that I wrote to do some performance > measurements with, and it behaves quite poorly for me under 6.12.1 if I > try to use multiple cores. The symptoms are very low throughput and > frequent hangs. > > I'm on a dual core 64-bit Linux system (Fedora 12). > > I have attached the server code that you can use to reproduce the > problem. It requires the {{{network}}} and {{{network-bytestring}}} > packages to function, but is otherwise standalone. > > Running it is easy: > > {{{ > ghc -fforce-recomp -O --make Netbench > ./Netbench localhost 8080 > }}} > > I've been using the standard apachebench tool, {{{ab}}}, to stress the > server: > > {{{ > ab -c 10 -n 30000 http://localhost:8080/ > }}} > > This hits the server with 10 concurrent requests for a total of 30,000 > requests. Here are some throughput measurements: > > * 6.10.4, unthreaded RTS: 5539 req/sec > * 6.10.4, threaded RTS, {{{-N1}}}: 7758 req/sec > * 6.10.4, threaded RTS, {{{-N2}}}: 5856 req/sec > > * 6.12.1, unthreaded RTS: 5612 req/sec > * 6.12.1, threaded RTS, {{{-N1}}}: 7437 req/sec > * 6.12.1, threaded RTS, {{{-N2}}}: 1978 req/sec > > With {{{-N2}}} under 6.12.1, there is a high probability (> 50%) that the > server will deadlock mid-run. > > When a multi-CPU run completes successfully under 6.12.1, {{{ab}}} > reports that quite often a single request will get stuck for several > seconds before the server responds. This does not seem to happen in other > scenarios. > > If you would like any more details, please let me know. Thanks. New description: I have a trivial HTTP server that I wrote to do some performance measurements with, and it behaves quite poorly for me under 6.12.1 if I try to use multiple cores. The symptoms are very low throughput and frequent hangs. I'm on a dual core 64-bit Linux system (Fedora 12). I have attached the server code that you can use to reproduce the problem. It requires the {{{network}}} and {{{network-bytestring}}} packages to function, but is otherwise standalone. Running it is easy: {{{ ghc -fforce-recomp -O --make Netbench ./Netbench localhost 8080 }}} I've been using the standard apachebench tool, {{{ab}}}, to stress the server: {{{ ab -c 10 -n 30000 http://localhost:8080/ }}} This hits the server with 10 concurrent requests for a total of 30,000 requests. Here are some throughput measurements: * 6.10.4, unthreaded RTS: 5539 req/sec * 6.10.4, threaded RTS, {{{-N1}}}: 7758 req/sec * 6.10.4, threaded RTS, {{{-N2}}}: 5856 req/sec * 6.12.1, unthreaded RTS: 5612 req/sec * 6.12.1, threaded RTS, {{{-N1}}}: 7437 req/sec * 6.12.1, threaded RTS, {{{-N2}}}: 1978 req/sec With {{{-N2}}} under 6.12.1, there is a high probability (> 50%) that the server will deadlock mid-run. When a multi-CPU run completes successfully under 6.12.1, {{{ab}}} reports that quite often a single request will get stuck for several seconds before the server responds. This does not seem to happen in other scenarios. If you would like any more details, please let me know. Thanks. Comment: Thanks for the report. I've fixed the formatting. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 15 16:10:17 2009 From: trac at galois.com (GHC) Date: Tue Dec 15 15:44:33 2009 Subject: [GHC] #3748: Bug in rts/Win32/Ticker.c can cause process hang on exit in Win32 In-Reply-To: <042.ebc1303ba4ba1bb01245ae57d2b8c614@localhost> References: <042.ebc1303ba4ba1bb01245ae57d2b8c614@localhost> Message-ID: <051.01af0b5847da82ffe6f8c5f9c1a67d7a@localhost> #3748: Bug in rts/Win32/Ticker.c can cause process hang on exit in Win32 -----------------------------+---------------------------------------------- Reporter: sgf | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Windows Testcase: | Architecture: Unknown/Multiple Failure: Runtime crash | -----------------------------+---------------------------------------------- Comment (by sgf): Ah. I assumed there would be a preprocessor flag for compiled-into-DLL vs compiled-as-EXE. No matter, I think I should be able to propagate the hs_exit_ flag through as you describe. I'm a bit busy at the moment, so creating the patch may take a while. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 15 16:33:55 2009 From: trac at galois.com (GHC) Date: Tue Dec 15 16:08:40 2009 Subject: [GHC] #3637: ./configure doesn't understand Gentoo's build/host/target In-Reply-To: <047.fcebd5e462086e021124f01f2c19fc8c@localhost> References: <047.fcebd5e462086e021124f01f2c19fc8c@localhost> Message-ID: <056.efba9f654afa4c8c728a6951528076bc@localhost> #3637: ./configure doesn't understand Gentoo's build/host/target ----------------------------------+----------------------------------------- Reporter: kolmodin | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.2 Component: Build System | Version: 6.12.1 RC1 Resolution: | Keywords: regression Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Building GHC failed | ----------------------------------+----------------------------------------- Changes (by igloo): * milestone: 6.12.1 => 6.12.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 15 16:33:44 2009 From: trac at galois.com (GHC) Date: Tue Dec 15 16:08:43 2009 Subject: [GHC] #3605: Dll's freeze with -threaded In-Reply-To: <051.1aad4f74c417c7c8dcc312c4764dd078@localhost> References: <051.1aad4f74c417c7c8dcc312c4764dd078@localhost> Message-ID: <060.583d9b0564abc98fd87dc80d6356d395@localhost> #3605: Dll's freeze with -threaded ----------------------------+----------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.2 Component: Documentation | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ----------------------------+----------------------------------------------- Changes (by igloo): * milestone: 6.12.1 => 6.12.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 15 16:34:26 2009 From: trac at galois.com (GHC) Date: Tue Dec 15 16:08:57 2009 Subject: [GHC] #3330: Type checker hangs In-Reply-To: <060.111b0979bdfa1b272261462ee3c542d4@localhost> References: <060.111b0979bdfa1b272261462ee3c542d4@localhost> Message-ID: <069.5491423c7262687f86ac696d5c9e2f65@localhost> #3330: Type checker hangs --------------------------------------+------------------------------------- Reporter: MartijnVanSteenbergen | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler (Type checker) | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: x86_64 (amd64) Failure: Compile-time crash | --------------------------------------+------------------------------------- Changes (by igloo): * milestone: 6.12.1 => 6.14.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 15 16:34:56 2009 From: trac at galois.com (GHC) Date: Tue Dec 15 16:09:15 2009 Subject: [GHC] #3376: hpc and CPP don't mix on Windows In-Reply-To: <044.6ac0df9e14fafd4394d0f7a94cb2ccc6@localhost> References: <044.6ac0df9e14fafd4394d0f7a94cb2ccc6@localhost> Message-ID: <053.3cda2ee23a5fdd58356d2cfcbe3f77a7@localhost> #3376: hpc and CPP don't mix on Windows ----------------------------+----------------------------------------------- Reporter: igloo | Owner: andy@galois.com Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Code Coverage | Version: 6.10.4 Resolution: | Keywords: Difficulty: Unknown | Os: Windows Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ----------------------------+----------------------------------------------- Changes (by igloo): * failure: => None/Unknown * milestone: 6.12.1 => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 15 16:35:43 2009 From: trac at galois.com (GHC) Date: Tue Dec 15 16:09:58 2009 Subject: [GHC] #3441: readProcess ... (exit 11): failed In-Reply-To: <045.8b36c40db2200ba55ce3ac655baf5782@localhost> References: <045.8b36c40db2200ba55ce3ac655baf5782@localhost> Message-ID: <054.72def6617786bf3eca8565b0da229034@localhost> #3441: readProcess ... (exit 11): failed --------------------------------+------------------------------------------- Reporter: Andriy | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: libraries/process | Version: 6.10.3 Resolution: | Keywords: readProcess exit 11 Difficulty: Unknown | Os: Linux Testcase: | Architecture: x86 Failure: None/Unknown | --------------------------------+------------------------------------------- Changes (by igloo): * milestone: 6.12.1 => 6.12.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 15 16:36:37 2009 From: trac at galois.com (GHC) Date: Tue Dec 15 16:10:39 2009 Subject: [GHC] #3742: redundant space in FFI imports rejected by 6.12 In-Reply-To: <045.5c4f82a5466765e359b1173caa6982ac@localhost> References: <045.5c4f82a5466765e359b1173caa6982ac@localhost> Message-ID: <054.d829d3d429d79b3b19f46b942b36b2d5@localhost> #3742: redundant space in FFI imports rejected by 6.12 ----------------------------------------+----------------------------------- Reporter: duncan | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.12.2 Component: Compiler (Parser) | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: GHC rejects valid program | ----------------------------------------+----------------------------------- Changes (by igloo): * milestone: 6.12.1 => 6.12.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 15 16:38:43 2009 From: trac at galois.com (GHC) Date: Tue Dec 15 16:12:55 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.9c7541426f06974a98a9584d2e118cbe@localhost> #2615: ghci doesn't play nice with linker scripts ------------------------------------------+--------------------------------- Reporter: AlecBerryman | Owner: hgolden Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: GHCi | Version: 6.10.1 Resolution: | Keywords: dlopen, dynamic linking Difficulty: Unknown | Os: Linux Testcase: | Architecture: Unknown/Multiple Failure: Incorrect result at runtime | ------------------------------------------+--------------------------------- Comment (by hgolden): Replying to [comment:16 guest]: > Where do I have to remove pthread? I think you can compile your LLVM modules using the -normal way instead of the -threaded way. My patch fixes this problem. I'm still working on a test, but the patch works. I could send it to you immediately if you are willing to rebuild your ghc. (Try the above suggestion first!) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 15 17:18:27 2009 From: trac at galois.com (GHC) Date: Tue Dec 15 16:52:33 2009 Subject: [GHC] #3759: -no-auto-link-packages flag isn't documented in User Guide Message-ID: <046.f54a1b5f9a827c433057d50cad782105@localhost> #3759: -no-auto-link-packages flag isn't documented in User Guide ---------------------------------+------------------------------------------ Reporter: hgolden | Owner: Type: bug | Status: new Priority: normal | Component: Documentation Version: 6.12.1 | Keywords: flag Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Documentation bug ---------------------------------+------------------------------------------ The -no-auto-link-packages flag (see compiler/main/DynFlags.hs) isn't documented in the User Guide. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 15 17:30:52 2009 From: trac at galois.com (GHC) Date: Tue Dec 15 17:05:03 2009 Subject: [GHC] #3758: Huge regression in concurrent app performance and reliability under threaded runtime In-Reply-To: <042.942d2a7fe8a29f75a39eae02838820a0@localhost> References: <042.942d2a7fe8a29f75a39eae02838820a0@localhost> Message-ID: <051.d45a50616b44b3e84a7f05976dd3570c@localhost> #3758: Huge regression in concurrent app performance and reliability under threaded runtime -----------------------------+---------------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: Runtime System | Version: 6.12.1 Resolution: | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86_64 (amd64) Failure: Runtime crash | -----------------------------+---------------------------------------------- Changes (by tibbe): * cc: johan.tibell@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 15 19:18:31 2009 From: trac at galois.com (GHC) Date: Tue Dec 15 18:52:34 2009 Subject: [GHC] #3731: SYB gone wild - mysterious <> in code derived from an syb-with-class example In-Reply-To: <042.4958fc1cdd70e26a14593e01de97e65e@localhost> References: <042.4958fc1cdd70e26a14593e01de97e65e@localhost> Message-ID: <051.4f1ffafce150962ca3c9d38342bf1f81@localhost> #3731: SYB gone wild - mysterious <> in code derived from an syb-with-class example ---------------------------------+------------------------------------------ Reporter: dsf | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.12.1 Resolution: | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Incorrect result at runtime ---------------------------------+------------------------------------------ Changes (by dsf): * cc: dsf@seereason.com (added) * version: 6.12.1 RC1 => 6.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 15 21:23:10 2009 From: trac at galois.com (GHC) Date: Tue Dec 15 20:57:42 2009 Subject: [GHC] #635: Replace use of select() in the I/O manager with epoll/kqueue/etc. In-Reply-To: <047.158ac52b7977b3e9f47680935a918275@localhost> References: <047.158ac52b7977b3e9f47680935a918275@localhost> Message-ID: <056.3ef98782892e4eb31b03880e87d1450e@localhost> #635: Replace use of select() in the I/O manager with epoll/kqueue/etc. -----------------------------------------+---------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: _|_ Component: libraries/base | Version: 6.4.1 Resolution: | Keywords: Difficulty: Project (more than a week) | Os: Unknown/Multiple Testcase: N/A | Architecture: Unknown/Multiple Failure: None/Unknown | -----------------------------------------+---------------------------------- Changes (by nwn): * cc: nonowarn@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 15 21:32:12 2009 From: trac at galois.com (GHC) Date: Tue Dec 15 21:06:21 2009 Subject: [GHC] #650: Improve interaction between mutable arrays and GC In-Reply-To: <047.44b951cd4b5aa8536d862412c8d86597@localhost> References: <047.44b951cd4b5aa8536d862412c8d86597@localhost> Message-ID: <056.42fd46bcf75d38a4d43f22f8ebcc8744@localhost> #650: Improve interaction between mutable arrays and GC -----------------------------------------+---------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Runtime System | Version: 6.4.1 Resolution: | Keywords: Difficulty: Moderate (less than a day) | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Runtime performance bug | -----------------------------------------+---------------------------------- Comment (by morrow): One other possible method to deal with this is to make old-generation pages containing mutable array data read-only via mprotect (or equivalent). Any later write will then cause a SIGSEGV, which is caught by an installed signal handler which then unprotects that page and marks it as dirty (however this needs to be done). A benefit of this is that any future writes to that page need no write barrier. Some limitations of this are that this reserves the SIGSEGV handler for the RTS, and this can only provide PAGE_SIZE granularity (which for large arrays is nevertheless a large improvement). What are people's thoughts on this? Is this (or some variation on this) an option given GHC's RTS? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 15 22:41:43 2009 From: trac at galois.com (GHC) Date: Tue Dec 15 22:15:45 2009 Subject: [GHC] #3760: 6.12.1 Build failure on FreeBSD Message-ID: <042.1a92c93a3edbe9458a808b65c3b82152@localhost> #3760: 6.12.1 Build failure on FreeBSD ---------------------------------+------------------------------------------ Reporter: PHO | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.12.1 | Keywords: Os: FreeBSD | Testcase: Architecture: Unknown/Multiple | Failure: Building GHC failed ---------------------------------+------------------------------------------ I found 6.12.1's rts/posix/Select.c doesn't compile on FreeBSD 7.0. It uses "fd_set" which is defined by sys/select.h, but Select.c doesn't #include it. So I put "#include " at the beginning of Select.c, then the problem went away. (Sorry for not pasting any build log. I forgot to capture it.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 15 23:04:53 2009 From: trac at galois.com (GHC) Date: Tue Dec 15 22:38:55 2009 Subject: [GHC] #3761: 6.12.1 HC bootstrap failes due to suspicious static library ordering Message-ID: <042.d80ddfbea544695de9a61d32ac79b9bd@localhost> #3761: 6.12.1 HC bootstrap failes due to suspicious static library ordering ---------------------------------+------------------------------------------ Reporter: PHO | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.12.1 | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Building GHC failed ---------------------------------+------------------------------------------ I found ghc-stage2 doesn't link because of the order of static libraries passed to gcc. The problem occurs on FreeBSD but I believe it's platform- independent. The build system puts rts/dist/build/libHSrts.a followed by rts/dist/build/libHSrtsmain.a. The latter has an undefined symbol to "hs_main" which is defined in libHSrts.a, so the linker complains about the absence of hs_main. The following patch to rts/ghc.mk solves the problem: {{{ --- ghc.mk.orig 2009-12-11 03:11:33.000000000 +0900 +++ ghc.mk @@ -19,8 +19,9 @@ rts_dist_HC = $(GHC_STAGE1) # merge GhcLibWays and GhcRTSWays but strip out duplicates rts_WAYS = $(GhcLibWays) $(filter-out $(GhcLibWays),$(GhcRTSWays)) -ALL_RTS_LIBS = $(foreach way,$(rts_WAYS),rts/dist/build/libHSrts$($(way)_libsuf)) \ - rts/dist/build/libHSrtsmain.a +ALL_RTS_LIBS = rts/dist/build/libHSrtsmain.a \ + $(foreach way,$(rts_WAYS),rts/dist/build/libHSrts$($(way)_libsuf)) + all_rts : $(ALL_RTS_LIBS) # ----------------------------------------------------------------------------- }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 16 01:23:00 2009 From: trac at galois.com (GHC) Date: Wed Dec 16 00:57:04 2009 Subject: [GHC] #3762: filepath.cabal has an extraneous apostrophe Message-ID: <048.0e334d3f10da19941e936444bdd1074c@localhost> #3762: filepath.cabal has an extraneous apostrophe ---------------------------------+------------------------------------------ Reporter: ohnobinki | Owner: Type: bug | Status: new Priority: normal | Component: libraries (other) Version: | Keywords: filepath Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Documentation bug ---------------------------------+------------------------------------------ https://bugs.gentoo.org/296699 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 16 02:52:31 2009 From: trac at galois.com (GHC) Date: Wed Dec 16 02:26:32 2009 Subject: [GHC] #3763: make -j8 fails for ghc-6.12.1-pre Message-ID: <050.b26e3f92f1a36f0cfca8f8ddeac68929@localhost> #3763: make -j8 fails for ghc-6.12.1-pre ----------------------------+----------------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.12.1 | Keywords: Os: Linux | Testcase: Architecture: x86 | Failure: None/Unknown ----------------------------+----------------------------------------------- I can provide more details I think but parallel make with 8 jobs failed for me with ghc-6.12.1-pre. make -j4 seems worked ok. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 16 02:57:31 2009 From: trac at galois.com (GHC) Date: Wed Dec 16 02:31:30 2009 Subject: [GHC] #3764: need --htmldir conifiguration Message-ID: <050.747b1712677f28ce0bf9a45c7d03b30b@localhost> #3764: need --htmldir conifiguration ---------------------------------+------------------------------------------ Reporter: juhpetersen | Owner: Type: feature request | Status: new Priority: normal | Component: Build System Version: 6.12.1 | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ ghc's makefiles currently ignore --htmldir overriding it to $(docdir)/html: this is also noted in comments for autoconf .backward compatibility. Since only html is generated by default distro packagers probably prefer to drop the html/ subdir and just install the html docs straight to docdir. Having a working --htmldir configure options would allow this without fragile build hacks. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 16 03:34:19 2009 From: trac at galois.com (GHC) Date: Wed Dec 16 03:08:19 2009 Subject: [GHC] #3717: Superfluous seq no eliminated In-Reply-To: <041.b3c6d5cd79733a6a42f08376dcf76349@localhost> References: <041.b3c6d5cd79733a6a42f08376dcf76349@localhost> Message-ID: <050.5eae2e43dbfb4cc397de66bc659dae5b@localhost> #3717: Superfluous seq no eliminated ---------------------------------------------+------------------------------ Reporter: rl | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.13 Resolution: fixed | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: simplCore/should_compile/T3717 | Architecture: Unknown/Multiple Failure: Runtime performance bug | ---------------------------------------------+------------------------------ Changes (by simonpj): * testcase: => simplCore/should_compile/T3717 * difficulty: => * status: new => closed * resolution: => fixed Comment: Fixed by {{{ Tue Dec 15 08:01:24 PST 2009 simonpj@microsoft.com * Fix Trac #3717: exprOkForSpeculation should look through case expressions See Note [exprOkForSpeculation: case expressions] in CoreUtils M ./compiler/coreSyn/CoreUtils.lhs +35 }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 16 04:53:23 2009 From: trac at galois.com (GHC) Date: Wed Dec 16 04:27:27 2009 Subject: [GHC] #3760: 6.12.1 Build failure on FreeBSD In-Reply-To: <042.1a92c93a3edbe9458a808b65c3b82152@localhost> References: <042.1a92c93a3edbe9458a808b65c3b82152@localhost> Message-ID: <051.0dad5af38413999567b0437845f6b9a3@localhost> #3760: 6.12.1 Build failure on FreeBSD ----------------------------------+----------------------------------------- Reporter: PHO | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: Runtime System | Version: 6.12.1 Resolution: | Keywords: Difficulty: | Os: FreeBSD Testcase: | Architecture: Unknown/Multiple Failure: Building GHC failed | ----------------------------------+----------------------------------------- Changes (by simonmar): * owner: => simonmar * difficulty: => * component: Compiler => Runtime System * milestone: => 6.12.2 Comment: I'll fix, thanks for the report. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 16 04:59:50 2009 From: trac at galois.com (GHC) Date: Wed Dec 16 04:33:55 2009 Subject: [GHC] #3762: filepath.cabal has an extraneous apostrophe In-Reply-To: <048.0e334d3f10da19941e936444bdd1074c@localhost> References: <048.0e334d3f10da19941e936444bdd1074c@localhost> Message-ID: <057.6fda534718ba0f72c1857a1d6de389db@localhost> #3762: filepath.cabal has an extraneous apostrophe --------------------------------+------------------------------------------- Reporter: ohnobinki | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: libraries (other) | Version: Resolution: | Keywords: filepath Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Documentation bug | --------------------------------+------------------------------------------- Changes (by simonmar): * owner: => simonmar * difficulty: => * milestone: => 6.12.2 Comment: Amazing how many bits have been shoveled around on account of a 1-character punctuation fix. Oh well, thanks for the report anyway! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 16 05:09:14 2009 From: trac at galois.com (GHC) Date: Wed Dec 16 04:45:53 2009 Subject: [GHC] #650: Improve interaction between mutable arrays and GC In-Reply-To: <047.44b951cd4b5aa8536d862412c8d86597@localhost> References: <047.44b951cd4b5aa8536d862412c8d86597@localhost> Message-ID: <056.176de69c92d98f5674cceabbf934dc79@localhost> #650: Improve interaction between mutable arrays and GC --------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: Runtime System | Version: 6.4.1 Resolution: | Keywords: Difficulty: Difficult (2-5 days) | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Runtime performance bug | --------------------------------------+------------------------------------- Changes (by simonmar): * owner: => simonmar * difficulty: Moderate (less than a day) => Difficult (2-5 days) * milestone: _|_ => 6.14.1 Comment: I worked on this problem yesterday. So far I have a `Data.HashTable` benchmark that goes from 50s before the fix to 10s afterward with the default heap settings. It's a simple card-marking strategy where the card bits (actually bytes, for atomicity) are stored after the array data. I want to do some more measurements and testing before I commit. Roman also pointed out to me that this doesn't really fix the problem, it only reduces the constant factor (albeit by a lot), since we still have to traverse the mark bits on every GC, but I can't think of a workable strategy that doesn't suffer from this problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 16 05:12:41 2009 From: trac at galois.com (GHC) Date: Wed Dec 16 04:46:41 2009 Subject: [GHC] #3758: Huge regression in concurrent app performance and reliability under threaded runtime In-Reply-To: <042.942d2a7fe8a29f75a39eae02838820a0@localhost> References: <042.942d2a7fe8a29f75a39eae02838820a0@localhost> Message-ID: <051.48635ddd26c8e06e8da7dee715c38999@localhost> #3758: Huge regression in concurrent app performance and reliability under threaded runtime -----------------------------+---------------------------------------------- Reporter: bos | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.12.2 Component: Runtime System | Version: 6.12.1 Resolution: | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86_64 (amd64) Failure: Runtime crash | -----------------------------+---------------------------------------------- Changes (by simonmar): * priority: normal => high * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 16 05:30:25 2009 From: trac at galois.com (GHC) Date: Wed Dec 16 05:04:25 2009 Subject: [GHC] #3756: Missing -lz option in testsuite In-Reply-To: <056.ed7c6d1c92de3c6183484ea552e08336@localhost> References: <056.ed7c6d1c92de3c6183484ea552e08336@localhost> Message-ID: <065.57a8b234acad863e1a439a406d245ca1@localhost> #3756: Missing -lz option in testsuite --------------------------------+------------------------------------------- Reporter: daniel.is.fischer | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: Build System | Version: 6.12.1 Resolution: | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86 Failure: Other | --------------------------------+------------------------------------------- Changes (by daniel.is.fischer): * os: Unknown/Multiple => Linux * architecture: Unknown/Multiple => x86 Comment: Sure, done. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 16 05:42:43 2009 From: trac at galois.com (GHC) Date: Wed Dec 16 05:16:45 2009 Subject: [GHC] #3723: SharedMem.hsc should include , not In-Reply-To: <043.3ccfd43c4f25a82e84eff1b44d03ad03@localhost> References: <043.3ccfd43c4f25a82e84eff1b44d03ad03@localhost> Message-ID: <052.1466ae41b7153f5e4f20fbfe0fb387c4@localhost> #3723: SharedMem.hsc should include , not ----------------------------------+----------------------------------------- Reporter: donn | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: libraries/unix | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Building GHC failed | ----------------------------------+----------------------------------------- Changes (by simonmar): * component: Compiler => libraries/unix * difficulty: => * architecture: x86 => Unknown/Multiple * milestone: => 6.12.2 * owner: => simonmar * os: Other => Unknown/Multiple Comment: Agreed, I'll fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 16 06:18:51 2009 From: trac at galois.com (GHC) Date: Wed Dec 16 05:52:54 2009 Subject: [GHC] #3730: hp2ps: Deviation.c:(.text+0x42b): undefined reference to `sqrt' In-Reply-To: <045.ec140461375c1820e8f386032560a656@localhost> References: <045.ec140461375c1820e8f386032560a656@localhost> Message-ID: <054.ea7028371828c6d719597d8321165df2@localhost> #3730: hp2ps: Deviation.c:(.text+0x42b): undefined reference to `sqrt' ----------------------------------+----------------------------------------- Reporter: slyfox | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: Build System | Version: 6.10.4 Resolution: | Keywords: autoconf, libm, patch Difficulty: | Os: Linux Testcase: | Architecture: x86_64 (amd64) Failure: Building GHC failed | ----------------------------------+----------------------------------------- Changes (by simonmar): * owner: => simonmar * difficulty: => * milestone: => 6.12.2 Comment: See also #3724 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 16 06:41:48 2009 From: trac at galois.com (GHC) Date: Wed Dec 16 06:15:47 2009 Subject: [GHC] #3738: Typechecker floats stuff out of INLINE right hand sides In-Reply-To: <041.d227e4e2f98d3171cf4e574a410067a1@localhost> References: <041.d227e4e2f98d3171cf4e574a410067a1@localhost> Message-ID: <050.7a73d9767c2754751a96eb3ea02de784@localhost> #3738: Typechecker floats stuff out of INLINE right hand sides --------------------------------------+------------------------------------- Reporter: rl | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14 branch Component: Compiler | Version: 6.13 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Runtime performance bug | --------------------------------------+------------------------------------- Changes (by simonpj): * difficulty: => * summary: INLINE function loses unfolding => Typechecker floats stuff out of INLINE right hand sides * milestone: => 6.14 branch Comment: I'm not too bothered about this: * It's true that `bar` doesn't get the loop in its unfolding. But it does if you use `-fno-method-sharing`. Reason: the typechecker floats `(foo Int)` out of the RHS of `bar`. I will fix this when doing the new constraint simplifier. But meanwhile it doesn't matter, does it. The top- level `$wgo` loop works just fine. * The specialised version of `foo` doesn't seem to get an inline pragma, but what matters is that it has an `InlineRule` unfolding. So that part is ok. Same for `bar_foo`. I'm going to leave this open with a new title, for the new constraint simplifier. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 16 06:46:09 2009 From: trac at galois.com (GHC) Date: Wed Dec 16 06:20:14 2009 Subject: [GHC] #3724: rts/package.conf.d specifies -lm for all platforms In-Reply-To: <043.58505aaf8b324d493ddba3cfafc80288@localhost> References: <043.58505aaf8b324d493ddba3cfafc80288@localhost> Message-ID: <052.da07effd878fc865805c0c5ba1543810@localhost> #3724: rts/package.conf.d specifies -lm for all platforms ----------------------------------+----------------------------------------- Reporter: donn | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: Build System | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: | Os: Other Testcase: | Architecture: x86 Failure: Building GHC failed | ----------------------------------+----------------------------------------- Changes (by simonmar): * owner: => simonmar * difficulty: => * component: Compiler => Build System * milestone: => 6.12.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 16 06:51:59 2009 From: trac at galois.com (GHC) Date: Wed Dec 16 06:25:59 2009 Subject: [GHC] #3765: Rules should "look through" case binders too Message-ID: <046.ad386b06466c9a5e784b413a9038b207@localhost> #3765: Rules should "look through" case binders too ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.12.1 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Here's a program suggested by Roman {{{ inc :: Int -> Int {-# INLINE CONLIKE [1] inc #-} inc n = n+1 dec :: Int -> Int {-# INLINE [1] dec #-} dec n = n-1 {-# RULES "dec/inc" forall n. dec (inc n) = n #-} data T = T !Int -- The bang here prevents the rule firing foo :: T -> Int {-# INLINE foo #-} foo (T n) = dec n + n bar :: Int -> Int bar n = foo (T (inc n)) }}} The rule doesn't fire with the bang in the definition of T. If I remove the bang, it fires. It should fire in both cases. The trouble is that, with the bang, we see something like this (in the output of phase 2 of the simplifier): {{{ Roman.bar = \ (n_aat :: GHC.Types.Int) -> case Roman.inc n_aat of tpl_X3 { GHC.Types.I# ipv_skx -> case Roman.dec tpl_X3 of _ { GHC.Types.I# x_ak2 -> GHC.Types.I# (GHC.Prim.+# x_ak2 ipv_skx) } }}} but `tpl_X3` is bound to `(I# ipv_skx)`, not to `(inc n_aat)`. Somehow we need ''both'' unfoldings for `tpl_X3`. That seems like a big step, so I'm just capturing the ticket but not actually doing anything about it yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 16 07:17:58 2009 From: trac at galois.com (GHC) Date: Wed Dec 16 06:51:59 2009 Subject: [GHC] #3736: GHC specialising instead of inlining In-Reply-To: <044.6187e75fed543439fb0c0aaede8523f0@localhost> References: <044.6187e75fed543439fb0c0aaede8523f0@localhost> Message-ID: <053.8839695dab428931ce7d351ccedc5e22@localhost> #3736: GHC specialising instead of inlining --------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86 Failure: Runtime performance bug | --------------------------------------+------------------------------------- Comment (by simonpj): Can you make a standalone case? At the moment I just get stuck. * The `storablevector` package you point to depends on `utility-ht` and `transformers`. * In turn `transformers` depends on `special-functors` * `special-functors` requires `base` < 2, and I don't have that, since base is now up to version 4. I'm sure that most of this clutter is irrelevant to the problem you have. The easy way to remove unnecessary dependencies is to make stub modules with definitions like {{{ thingy :: Int -> Int thingy = error "urk" }}} and than you don't need a separate package to define `thingy`. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 16 07:18:33 2009 From: trac at galois.com (GHC) Date: Wed Dec 16 06:52:32 2009 Subject: [GHC] #3737: inlining happens on foldl1 and does not happen on direct application of combinator In-Reply-To: <044.fddf7c34bfc36e2b8667f9dd59d27ab6@localhost> References: <044.fddf7c34bfc36e2b8667f9dd59d27ab6@localhost> Message-ID: <053.98afb552c69a8d828482071f4fa52fa7@localhost> #3737: inlining happens on foldl1 and does not happen on direct application of combinator --------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86 Failure: Runtime performance bug | --------------------------------------+------------------------------------- Changes (by simonpj): * difficulty: => Comment: Same difficulty as with #3736; can't reproduce. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 16 07:20:11 2009 From: trac at galois.com (GHC) Date: Wed Dec 16 06:54:20 2009 Subject: [GHC] #650: Improve interaction between mutable arrays and GC In-Reply-To: <047.44b951cd4b5aa8536d862412c8d86597@localhost> References: <047.44b951cd4b5aa8536d862412c8d86597@localhost> Message-ID: <056.8bbf160cc30d49b28afea50fdba16c38@localhost> #650: Improve interaction between mutable arrays and GC --------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: Runtime System | Version: 6.4.1 Resolution: | Keywords: Difficulty: Difficult (2-5 days) | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Runtime performance bug | --------------------------------------+------------------------------------- Comment (by simonmar): Replying to [comment:16 morrow]: > One other possible method to deal with this is to make old-generation pages containing mutable array data read-only via mprotect (or equivalent). Any later write will then cause a SIGSEGV, Not keen on this for a few reasons: * non-portability * too coarse-grained * only works for large arrays * GC needs to fiddle around with mprotecting pages * taking the signal is expensive * recovering from a SIGSEGV is very tricky I must be getting old, but my feeling is that tricks like this sound quite cool but end up being a pain in the neck in the long run. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 16 07:37:09 2009 From: trac at galois.com (GHC) Date: Wed Dec 16 07:11:14 2009 Subject: [GHC] #3762: filepath.cabal has an extraneous apostrophe In-Reply-To: <048.0e334d3f10da19941e936444bdd1074c@localhost> References: <048.0e334d3f10da19941e936444bdd1074c@localhost> Message-ID: <057.151c205c68a015984c7ad0a5f27f4365@localhost> #3762: filepath.cabal has an extraneous apostrophe --------------------------------+------------------------------------------- Reporter: ohnobinki | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: libraries (other) | Version: Resolution: | Keywords: filepath Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Documentation bug | --------------------------------+------------------------------------------- Comment (by igloo): This isn't necessarily a bug; I think `FilePath's` is generally permitted, especially in technical documentation, to be clear that you are talking about the plural of `FilePath` rather than something called `FilePaths`. (yes, you could have a thing called `FilePath's` in Haskell, but that's another story...) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 16 07:41:22 2009 From: trac at galois.com (GHC) Date: Wed Dec 16 07:15:22 2009 Subject: [GHC] #3763: make -j8 fails for ghc-6.12.1-pre In-Reply-To: <050.b26e3f92f1a36f0cfca8f8ddeac68929@localhost> References: <050.b26e3f92f1a36f0cfca8f8ddeac68929@localhost> Message-ID: <059.0c55b1046337caba36efa27004578515@localhost> #3763: make -j8 fails for ghc-6.12.1-pre ---------------------------+------------------------------------------------ Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: Build System | Version: 6.12.1 Resolution: | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86 Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * difficulty: => * milestone: => 6.12.2 Comment: Can you tell us what went wrong please? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 16 08:02:18 2009 From: trac at galois.com (GHC) Date: Wed Dec 16 07:36:18 2009 Subject: [GHC] #3738: Typechecker floats stuff out of INLINE right hand sides In-Reply-To: <041.d227e4e2f98d3171cf4e574a410067a1@localhost> References: <041.d227e4e2f98d3171cf4e574a410067a1@localhost> Message-ID: <050.011f6fb19b79f410019f15656fe451ab@localhost> #3738: Typechecker floats stuff out of INLINE right hand sides --------------------------------------+------------------------------------- Reporter: rl | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14 branch Component: Compiler | Version: 6.13 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Runtime performance bug | --------------------------------------+------------------------------------- Comment (by rl): I have no problems with waiting for the new constraint simplifier but would like to point out that this does matter quite a bit. Change the pragma on `foo` to `INLINE [1]` and add a rewrite rule for `foo`. We'd expect the rule to fire when we inline `bar` but this doesn't happen since `foo` doesn't appear in the unfolding. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 16 08:08:02 2009 From: trac at galois.com (GHC) Date: Wed Dec 16 07:42:04 2009 Subject: [GHC] #3331: control-monad-queue performance regression In-Reply-To: <046.199bea4da34b828d923df9304139778a@localhost> References: <046.199bea4da34b828d923df9304139778a@localhost> Message-ID: <055.26078ee09e6e942e7c26df6569162d89@localhost> #3331: control-monad-queue performance regression --------------------------------------+------------------------------------- Reporter: lpsmith | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.3 Resolution: fixed | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Runtime performance bug | --------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: Happily the HEAD is better than 6.08. Here are the 6.08 timings for 'allison': {{{ bash-3.2$ ./Time allison 34 20 +RTS -sstderr allison Timings: [84,77,77,78,77,76,78,77,76,76,78,76,76,77,77,77,77,76,76,77] Sum: 1543 Minimum: 76 Maximum: 84 Mean: 77.15 Stddev: 1.7109938632268673 7,698,631,424 bytes allocated in the heap 5,371,953,432 bytes copied during GC (scavenged) 293,760 bytes copied during GC (not scavenged) 25,944,064 bytes maximum residency (241 sample(s)) 14685 collections in generation 0 ( 6.06s) 241 collections in generation 1 ( 5.46s) 74 Mb total memory in use INIT time 0.00s ( 0.00s elapsed) MUT time 3.92s ( 3.89s elapsed) GC time 11.52s ( 11.64s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 15.44s ( 15.53s elapsed) %GC time 74.6% (74.9% elapsed) Alloc rate 1,964,733,507 bytes per MUT second Productivity 25.4% of total user, 25.2% of total elapsed real 0m15.545s user 0m15.437s sys 0m0.107s }}} And with the HEAD: {{{ bash-3.2$ ./Time allison 34 20 +RTS -sstderr allison Timings: [80,73,72,72,71,72,72,72,73,72,72,72,71,72,71,71,71,71,71,71] Sum: 1442 Minimum: 71 Maximum: 80 Mean: 72.1 Stddev: 1.9209372712298545 7,698,487,056 bytes allocated in the heap 5,357,441,720 bytes copied during GC 25,815,200 bytes maximum residency (238 sample(s)) 848,400 bytes maximum slop 74 MB total memory in use (1 MB lost due to fragmentation) Generation 0: 14447 collections, 0 parallel, 5.50s, 5.55s elapsed Generation 1: 238 collections, 0 parallel, 4.85s, 4.91s elapsed INIT time 0.00s ( 0.00s elapsed) MUT time 4.07s ( 4.06s elapsed) GC time 10.36s ( 10.47s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 14.42s ( 14.53s elapsed) %GC time 71.8% (72.0% elapsed) Alloc rate 1,891,795,331 bytes per MUT second Productivity 28.2% of total user, 28.0% of total elapsed real 0m14.550s user 0m14.426s sys 0m0.121s }}} Notice that allocation is essentially unchanged, but elapsed time seems a bit better. I don't know why. When I tried this initially with HEAD I got: {{{ bash-3.2$ time ./Time allison 34 20 +RTS -sstderr ./Time allison 34 20 +RTS -sstderr allison Timings: [79,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0] Sum: 79 Minimum: 0 Maximum: 79 Mean: 3.95 Stddev: 17.21765082698566 385,451,912 bytes allocated in the heap 267,303,984 bytes copied during GC 24,657,920 bytes maximum residency (13 sample(s)) 805,320 bytes maximum slop 73 MB total memory in use (1 MB lost due to fragmentation) Generation 0: 723 collections, 0 parallel, 0.28s, 0.28s elapsed Generation 1: 13 collections, 0 parallel, 0.24s, 0.31s elapsed INIT time 0.00s ( 0.00s elapsed) MUT time 0.21s ( 0.21s elapsed) GC time 0.52s ( 0.59s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 0.73s ( 0.80s elapsed) %GC time 71.4% (73.5% elapsed) Alloc rate 1,853,428,245 bytes per MUT second Productivity 28.5% of total user, 25.9% of total elapsed real 0m0.818s user 0m0.726s sys 0m0.088s }}} So the HEAD is better at some kind of inlining or fusion or full laziness: it's combining all the test runs into one! So to get the fair comparision I had to change Time.hs. The two changes are: {{{ test' string f i n = do ts <- mapM (test string . f) [(k,i) | k <- [1..n]] ... blah... }}} and {{{ fromQueue f (_,n) = length (f (T.fib n)) == fib n - 1 fromUnit f (_,n) = (f (T.fib n)) == () }}} That is, the test functions take a parameter they don't use. Otherwise full laziness makes `test'` too efficient. '''You may want to make this change in the package itself'''. I have not tried with GHC 6.12, because even if it's slower, I doubt we'll go back to fix it. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 16 08:41:43 2009 From: trac at galois.com (GHC) Date: Wed Dec 16 08:15:46 2009 Subject: [GHC] #3760: 6.12.1 Build failure on FreeBSD In-Reply-To: <042.1a92c93a3edbe9458a808b65c3b82152@localhost> References: <042.1a92c93a3edbe9458a808b65c3b82152@localhost> Message-ID: <051.3f7a5f440d9c65b4fc7b14a69af9cba4@localhost> #3760: 6.12.1 Build failure on FreeBSD ----------------------------------+----------------------------------------- Reporter: PHO | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.12.2 Component: Runtime System | Version: 6.12.1 Resolution: | Keywords: Difficulty: | Os: FreeBSD Testcase: | Architecture: Unknown/Multiple Failure: Building GHC failed | ----------------------------------+----------------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: {{{ Wed Dec 16 09:55:01 GMT 2009 Simon Marlow * #include if we have it (#3760) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 16 08:42:18 2009 From: trac at galois.com (GHC) Date: Wed Dec 16 08:16:19 2009 Subject: [GHC] #3730: hp2ps: Deviation.c:(.text+0x42b): undefined reference to `sqrt' In-Reply-To: <045.ec140461375c1820e8f386032560a656@localhost> References: <045.ec140461375c1820e8f386032560a656@localhost> Message-ID: <054.ff291b4837b5967c57e5097171f7ab78@localhost> #3730: hp2ps: Deviation.c:(.text+0x42b): undefined reference to `sqrt' ----------------------------------+----------------------------------------- Reporter: slyfox | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.12.2 Component: Build System | Version: 6.10.4 Resolution: | Keywords: autoconf, libm, patch Difficulty: | Os: Linux Testcase: | Architecture: x86_64 (amd64) Failure: Building GHC failed | ----------------------------------+----------------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: Pushed: {{{ Fri Dec 4 21:40:12 GMT 2009 Sergei Trofimovich * configure.ac: fix libm checks (Trac #3730) libbfd pulled libm as dependency and broke LIBM= detection. Patch moves libm in library tests as early as possible. Thanks to asuffield for suggesting such a simple fix. Thanks to Roie Kerstein and Renato Gallo for finding and tracking down the issue. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 16 08:43:11 2009 From: trac at galois.com (GHC) Date: Wed Dec 16 08:17:13 2009 Subject: [GHC] #3724: rts/package.conf.d specifies -lm for all platforms In-Reply-To: <043.58505aaf8b324d493ddba3cfafc80288@localhost> References: <043.58505aaf8b324d493ddba3cfafc80288@localhost> Message-ID: <052.8fbb24b176e7f0379745fbef6d39fbc9@localhost> #3724: rts/package.conf.d specifies -lm for all platforms ----------------------------------+----------------------------------------- Reporter: donn | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.12.2 Component: Build System | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: | Os: Other Testcase: | Architecture: x86 Failure: Building GHC failed | ----------------------------------+----------------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: Fixed: {{{ Wed Dec 16 11:36:52 GMT 2009 Simon Marlow * fix up libm detection and use (#3724) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 16 08:52:53 2009 From: trac at galois.com (GHC) Date: Wed Dec 16 08:26:57 2009 Subject: [GHC] #3762: filepath.cabal has an extraneous apostrophe In-Reply-To: <048.0e334d3f10da19941e936444bdd1074c@localhost> References: <048.0e334d3f10da19941e936444bdd1074c@localhost> Message-ID: <057.f02386c8d6b5f8ef75fe0f25bda0eae8@localhost> #3762: filepath.cabal has an extraneous apostrophe --------------------------------+------------------------------------------- Reporter: ohnobinki | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.12.2 Component: libraries (other) | Version: Resolution: | Keywords: filepath Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Documentation bug | --------------------------------+------------------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: Replying to [comment:2 igloo]: > This isn't necessarily a bug; I think `FilePath's` is generally permitted, especially in technical documentation, to be clear that you are talking about the plural of `FilePath` rather than something called `FilePaths`. Really? I've never come across that. Do you have a reference? Anyway: {{{ Wed Dec 16 09:58:18 GMT 2009 Simon Marlow * correct punctuation in Synopsis (#3762) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 16 09:00:05 2009 From: trac at galois.com (GHC) Date: Wed Dec 16 08:34: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.0a42e3271a67acd9263a0dc0fad88204@localhost> #3065: Reorder tests in quot to improve code --------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: libraries/base | Version: 6.10.1 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Runtime performance bug | --------------------------------------+------------------------------------- Comment (by rl): I don't feel strongly about the behaviour, either. But that's precisely the point: since the semantics doesn't really matter in this particular case, we should pick whatever has the best performance. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 16 09:23:46 2009 From: trac at galois.com (GHC) Date: Wed Dec 16 08:57:45 2009 Subject: [GHC] #3723: SharedMem.hsc should include , not In-Reply-To: <043.3ccfd43c4f25a82e84eff1b44d03ad03@localhost> References: <043.3ccfd43c4f25a82e84eff1b44d03ad03@localhost> Message-ID: <052.20a7ccb38c3cf240ff9ecfbeaa79da19@localhost> #3723: SharedMem.hsc should include , not ----------------------------------+----------------------------------------- Reporter: donn | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.12.2 Component: libraries/unix | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Building GHC failed | ----------------------------------+----------------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: Fixed: {{{ Wed Dec 16 10:41:54 GMT 2009 Simon Marlow * #include , not (#3723) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 16 09:38:47 2009 From: trac at galois.com (GHC) Date: Wed Dec 16 09:12:50 2009 Subject: [GHC] #3065: Reorder tests in quot to improve code In-Reply-To: <046.819ea32d4c70bd7d14e7ef168534bbea@localhost> References: <046.819ea32d4c70bd7d14e7ef168534bbea@localhost> Message-ID: <055.98ae1469524d3fbcac14dd4581480514@localhost> #3065: Reorder tests in quot to improve code --------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: libraries/base | Version: 6.10.1 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Runtime performance bug | --------------------------------------+------------------------------------- Comment (by simonmar): Ok, so we should go ahead then. It can be done in two steps: * change the behaviour of overflow in quot to mean truncation, not an exception. Remove the tests from the smaller Int types. * move the test from `quotInt` into the NCG, or perhaps `CgPrimOp`? volunteers? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 16 11:05:09 2009 From: trac at galois.com (GHC) Date: Wed Dec 16 10:39:09 2009 Subject: [GHC] #3766: Parsing of lambdas is not consistent with Haskell'98 report. Message-ID: <044.9158723b04d24d385ae3535f0b133db9@localhost> #3766: Parsing of lambdas is not consistent with Haskell'98 report. ---------------------------------+------------------------------------------ Reporter: lilac | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Parser) Version: 6.10.4 | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: GHC rejects valid program ---------------------------------+------------------------------------------ Consider the following expression: {{{ (\x -> x :: Int . id)}}} GHC (without any -X flags) currently reports a parse error: Illegal operator `.' in type `Int . id'[[br]] Use -XTypeOperators to allow operators in types However, I think this expression is legal in Haskell'98 (and indeed still legal in Haskell 2010). The report gives an (ambiguous) expression grammar, which (unambiguously) parses the above as (\x -> (x :: Int)) . id. The report further says that lambdas extend as far as possible to the right, but the parse which GHC is using is not a possible parse according to the grammar, since infix operators (other than "->") are not allowed in the construction 'type'. That said, I'd much rather see this fixed in the Haskell 2011 report than in GHC :) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 16 11:14:00 2009 From: trac at galois.com (GHC) Date: Wed Dec 16 10:47:59 2009 Subject: [GHC] #3767: SpecConstr for join points Message-ID: <046.4ab0a63e59360e2986f5c0a1b503004f@localhost> #3767: SpecConstr for join points ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14 branch Component: Compiler | Version: 6.12.1 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ The attached file `Spec.hs` has a case (from Roman's fusion code) where `SpecConstr` is not doing the right thing. Let's look at one of the mutually recursive loops that `SpecConstr` generates for foo: {{{ lvl_rzY :: GHC.Types.Int lvl_rzY = GHC.Types.I# 2147483647 lvl1_rA0 :: Data.Either.Either GHC.Types.Int GHC.Types.Int lvl1_rA0 = Data.Either.Left @ GHC.Types.Int @ GHC.Types.Int lvl_rzY $s$wgo_szT :: GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.Int# $s$wgo_szT = \ (sc_sz6 :: GHC.Prim.Int#) (sc1_sz7 :: GHC.Prim.Int#) -> let { $w$j_syG :: GHC.Prim.Int# -> Data.Either.Either GHC.Types.Int GHC.Types.Int -> GHC.Prim.Int# [LclId, Arity=2, Str=DmdType LS] $w$j_syG = \ (ww_sy6 :: GHC.Prim.Int#) (w2_sy8 :: Data.Either.Either GHC.Types.Int GHC.Types.Int) -> case GHC.Prim.<=# ww_sy6 0 of _ { GHC.Bool.False -> $wgo_syE (GHC.Prim.+# sc_sz6 ww_sy6) w2_sy8; GHC.Bool.True -> $wgo_syE sc_sz6 w2_sy8 } } in case GHC.Prim.># sc1_sz7 0 of _ { GHC.Bool.False -> $s$wgo1_szS sc_sz6 ipv_swo; GHC.Bool.True -> case sc1_sz7 of wild1_awb { __DEFAULT -> case GHC.Prim.remInt# wild1_awb 2 of _ { __DEFAULT -> $s$wgo_szT sc_sz6 (GHC.Prim.-# wild1_awb 1); 0 -> case w1_syr of _ { GHC.Types.I# ww_sy6 -> $w$j_syG ww_sy6 (Data.Either.Left @ GHC.Types.Int @ GHC.Types.Int (GHC.Types.I# (GHC.Prim.-# wild1_awb 1))) } }; (-2147483648) -> case w1_syr of _ { GHC.Types.I# ww_sy6 -> $w$j_syG ww_sy6 lvl1_rA0 } } }; }}} Note that the join point has an argument of type `(Either Int Int)` but it is always called with `(Left (I# ))`. This means that the recursive call in the join point is always of the form `($wgo_syE (Left (I# )))` and we have a specialisation for that. However the join point itself doesn't scrutinse its argument, and that means that GHC ignores the potential specialisation. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 16 11:19:11 2009 From: trac at galois.com (GHC) Date: Wed Dec 16 10:53:10 2009 Subject: [GHC] #3767: SpecConstr for join points In-Reply-To: <046.4ab0a63e59360e2986f5c0a1b503004f@localhost> References: <046.4ab0a63e59360e2986f5c0a1b503004f@localhost> Message-ID: <055.b92367442eec65d663d4c94a8f088f97@localhost> #3767: SpecConstr for join points ---------------------------+------------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14 branch Component: Compiler | Version: 6.12.1 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Comment (by simonpj): See also #2642, which is more or less the same. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 16 11:31:06 2009 From: trac at galois.com (GHC) Date: Wed Dec 16 11:05:11 2009 Subject: [GHC] #3758: ` In-Reply-To: <042.942d2a7fe8a29f75a39eae02838820a0@localhost> References: <042.942d2a7fe8a29f75a39eae02838820a0@localhost> Message-ID: <051.07b1d70fb1aa42b08df46d7703fd5b0a@localhost> #3758: ` -----------------------------+---------------------------------------------- Reporter: bos | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.12.2 Component: Runtime System | Version: 6.12.1 Resolution: | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86_64 (amd64) Failure: Runtime crash | -----------------------------+---------------------------------------------- Changes (by simonmar): * summary: Huge regression in concurrent app performance and reliability under threaded runtime => ` Comment: Part of the problem at least is this: [[TicketQuery(id=3553|)]] You're on a dual-core machine, running 3 threads (2 for the server and one for the client, plus whatever other processes decide to wake up from time to time). In 6.12.1 we enabled the parallel GC by default for young gen collections. The parallel GC uses spinlocks for synchronisation, which do not cope at all when one of the GC threads gets descheduled, which happens quite a lot in this workload. You can get back to the single-threaded performance by turning off the parallel GC, with `+RTS -qg`. The rule of thumb is that if you use `-N2`, you better be sure you have 2 CPUs available for the whole run of the program, otherwise performance will go down the tubes. The work I'm doing on the GC at the moment will eventually help here. As for the absolute performance, clearly we could do a lot better. I've attached a ThreadScope profile showing one of the gaps you can see if you zoom in. This gap in particular I think is `select()` waking up, but after select has woken a couple of Haskell threads it takes a little while before we start running them. More investigation is needed. I'm not closing the ticket yet because you also reported a deadlock. I haven't been able to reproduce that yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 16 11:32:25 2009 From: trac at galois.com (GHC) Date: Wed Dec 16 11:06:23 2009 Subject: [GHC] #3766: Parsing of lambdas is not consistent with Haskell'98 report. In-Reply-To: <044.9158723b04d24d385ae3535f0b133db9@localhost> References: <044.9158723b04d24d385ae3535f0b133db9@localhost> Message-ID: <053.0c1f6b220af932386e2b87e4e5187abd@localhost> #3766: Parsing of lambdas is not consistent with Haskell'98 report. ----------------------------------+----------------------------------------- Reporter: lilac | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 6.10.4 Resolution: | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: GHC rejects valid program ----------------------------------+----------------------------------------- Comment (by lilac): Correction: the Report's grammar admits two parses: (\x -> (x :: Int)) . id, and ((\x -> x) :: Int) . id; the "as far to the right as possible" rule picks the former. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 16 11:34:41 2009 From: trac at galois.com (GHC) Date: Wed Dec 16 11:08:44 2009 Subject: [GHC] #3758: Huge regression in concurrent app performance and reliability under threaded runtime In-Reply-To: <042.942d2a7fe8a29f75a39eae02838820a0@localhost> References: <042.942d2a7fe8a29f75a39eae02838820a0@localhost> Message-ID: <051.02868778117334dcd1369665647b5025@localhost> #3758: Huge regression in concurrent app performance and reliability under threaded runtime -----------------------------+---------------------------------------------- Reporter: bos | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.12.2 Component: Runtime System | Version: 6.12.1 Resolution: | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86_64 (amd64) Failure: Runtime crash | -----------------------------+---------------------------------------------- Changes (by simonmar): * summary: ` => Huge regression in concurrent app performance and reliability under threaded runtime Comment: oops, revert accidentally spammed ticket summary. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 16 11:35:11 2009 From: trac at galois.com (GHC) Date: Wed Dec 16 11:09:10 2009 Subject: [GHC] #3766: Parsing of lambdas is not consistent with Haskell'98 report. In-Reply-To: <044.9158723b04d24d385ae3535f0b133db9@localhost> References: <044.9158723b04d24d385ae3535f0b133db9@localhost> Message-ID: <053.7034ac8a7d5f0396184a35819aa19603@localhost> #3766: Parsing of lambdas is not consistent with Haskell'98 report. ----------------------------------+----------------------------------------- Reporter: lilac | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 6.10.4 Resolution: | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: GHC rejects valid program ----------------------------------+----------------------------------------- Comment (by lilac): Amusingly, with any extension which adds the 'forall x . y' syntax to types (such as -XExistentialQuantification) enabled, the expression is accepted! Cases with other operators, such as (\x -> x :: Int $ 4) still fail, however. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 16 11:39:32 2009 From: trac at galois.com (GHC) Date: Wed Dec 16 11:13:30 2009 Subject: [GHC] #3766: Parsing of lambdas is not consistent with Haskell'98 report. In-Reply-To: <044.9158723b04d24d385ae3535f0b133db9@localhost> References: <044.9158723b04d24d385ae3535f0b133db9@localhost> Message-ID: <053.484326d9d5bd5cad0c240e554c325f50@localhost> #3766: Parsing of lambdas is not consistent with Haskell'98 report. ----------------------------------+----------------------------------------- Reporter: lilac | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 6.10.4 Resolution: | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: GHC rejects valid program ----------------------------------+----------------------------------------- Comment (by lilac): The same issue also affects the other two "as far to the right as possible" cases; these are both incorrectly rejected: {{{ let in id :: Int -> Int $ 4 if False then id else id :: Int -> Int $ 4 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 16 11:40:45 2009 From: trac at galois.com (GHC) Date: Wed Dec 16 11:15:54 2009 Subject: [GHC] #650: Improve interaction between mutable arrays and GC In-Reply-To: <047.44b951cd4b5aa8536d862412c8d86597@localhost> References: <047.44b951cd4b5aa8536d862412c8d86597@localhost> Message-ID: <056.b4295fad004d653c9a1cde77f3a2439e@localhost> #650: Improve interaction between mutable arrays and GC --------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: Runtime System | Version: 6.4.1 Resolution: | Keywords: Difficulty: Difficult (2-5 days) | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Runtime performance bug | --------------------------------------+------------------------------------- Comment (by GregoryCollins): It's a simple card-marking strategy where the card bits (actually bytes, for atomicity) Can you use a BTS instruction to do bitwise marking atomically? It'd be nice to see if there was a performance improvement, in theory you trade some bookkeeping complexity for 8x fewer cache line loads. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 16 11:49:55 2009 From: trac at galois.com (GHC) Date: Wed Dec 16 11:25:05 2009 Subject: [GHC] #650: Improve interaction between mutable arrays and GC In-Reply-To: <047.44b951cd4b5aa8536d862412c8d86597@localhost> References: <047.44b951cd4b5aa8536d862412c8d86597@localhost> Message-ID: <056.c8f80a62bdd698d5e8ee33e71896a838@localhost> #650: Improve interaction between mutable arrays and GC --------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: Runtime System | Version: 6.4.1 Resolution: | Keywords: Difficulty: Difficult (2-5 days) | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Runtime performance bug | --------------------------------------+------------------------------------- Comment (by simonmar): Replying to [comment:19 GregoryCollins]: > Can you use a BTS instruction to do bitwise marking atomically? It'd be nice to see if there was a performance improvement, in theory you trade some bookkeeping complexity for 8x fewer cache line loads. BTS is only atomic with a LOCK prefix, and that would make it a lot more expensive than doing byte operations. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 16 12:18:32 2009 From: trac at galois.com (GHC) Date: Wed Dec 16 11:52:33 2009 Subject: [GHC] #1216: Missed opportunity for let-no-esape In-Reply-To: <044.7a2c34fb5e14ee065cc1b66e35e75915@localhost> References: <044.7a2c34fb5e14ee065cc1b66e35e75915@localhost> Message-ID: <053.ac6d080adb0d2b2a1b4b4046ccf9d1df@localhost> #1216: Missed opportunity for let-no-esape --------------------------------------+------------------------------------- Reporter: claus | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.6 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Runtime performance bug | --------------------------------------+------------------------------------- Changes (by simonpj): * summary: indexing 2d arrays is slow and leaky. why? => Missed opportunity for let-no-esape Comment: I've finally gotten around to this, but only in HEAD. It's all to do with inlining array indexing, and doing so without causing grotesque code bloat from copied error messages. The key things are * Adding INLINE pragmas to `index` in `GHC.Arr`. * Floating out error message code (the bottom-extraction patch) Results. {{{ index is Allocation Elapsed time -------------------------------------------------------- GHC 6.10 local 19M 1.68s library 14,000M 8.73s HEAD local 16M 1.78s library 18M 1.52s }}} By "index is local" I mean that we use the locally-defined `myIndex`. By "library" I mean that `myIndex` is set equal to `index` so we use the overloaded `index` from `GHC.Arr`. (I think the allocation is higher than in the figures above because I'm measuring on a 64-bit machine.) So now the naive code is fastest. I'm not quite sure why the 'local' version in HEAD is slower than the 'library' version, but I've spent enough time on this. Wed Dec 16 17:04:41 GMT 2009 simonpj@microsoft.com The library patch is this: {{{ * Mark 'index' as INLINE in GHC.Arr This makes indexing much faster. See Trac #1216 }}} However I'm leaving the ticket open because I see that the inner loop shows the same phenomenon as #3458: we could greatly reduce allocation by pushing the binding for a local function to nearer its call site (in the scrutinee of a case). I'll re-title the ticket though. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 16 12:19:02 2009 From: trac at galois.com (GHC) Date: Wed Dec 16 11:53:01 2009 Subject: [GHC] #3458: Allocation where none should happen In-Reply-To: <044.0be4f1c62ed65da810608cbf23db2085@localhost> References: <044.0be4f1c62ed65da810608cbf23db2085@localhost> Message-ID: <053.c7c86cb417a74e044f1c084d70640504@localhost> #3458: Allocation where none should happen ---------------------------+------------------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: Unknown | Os: Linux Testcase: | Architecture: x86_64 (amd64) Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by simonpj): * failure: => None/Unknown Comment: I found that #1216 is another example of the same phenomenon. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 16 12:34:13 2009 From: trac at galois.com (GHC) Date: Wed Dec 16 12:08:13 2009 Subject: [GHC] #3655: Performance regression relative to 6.10 In-Reply-To: <047.de41e91ed6bceb6d2068db2adb01f317@localhost> References: <047.de41e91ed6bceb6d2068db2adb01f317@localhost> Message-ID: <056.e5273e9b1d4e25ce398bd190192d96be@localhost> #3655: Performance regression relative to 6.10 --------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonpj Type: bug | Status: closed Priority: high | Milestone: 6.12.2 Component: Compiler | Version: 6.10.4 Resolution: fixed | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Runtime performance bug | --------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: OK, it seems ok in the HEAD, and I'm disinclined to follow it up further: {{{ Time Allocation 6.10.2 9.27s 6.5G HEAD 8.56 3.8G }}} So HEAD allocates a lot less! Both spend 30% of time in GC. For HEAD I had to add `+RTS -K9m`, whereas 6.10.2 worked with `-K8m` (but not `-K7m`), so stack space seem to have increased a bit. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 16 12:59:02 2009 From: trac at galois.com (GHC) Date: Wed Dec 16 12:33:02 2009 Subject: [GHC] #2966: build system does not respect --with-gcc= In-Reply-To: <045.38910ced362f70db06ad52953362394b@localhost> References: <045.38910ced362f70db06ad52953362394b@localhost> Message-ID: <054.2f60c950461f5fb857c56d26910e6661@localhost> #2966: build system does not respect --with-gcc= ---------------------------+------------------------------------------------ Reporter: duncan | Owner: igloo Type: bug | Status: reopened Priority: normal | Milestone: 6.12.1 Component: Build System | Version: 6.11 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by duncan): * status: closed => reopened * failure: => None/Unknown * resolution: fixed => Comment: Regression. {{{ $ gcc || echo fail fail $ ./configure --with-gcc=/opt/gcc-vanilla/4.1.2/bin/gcc $ gmake }}} leads to {{{ Configuring unix-2.4.0.0... ... checking for gcc... gcc checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. gmake[1]: *** [libraries/unix/dist-install/package-data.mk] Error 77 }}} We should set up one of the buildbots with gcc -> /bin/false -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 16 12:59:45 2009 From: trac at galois.com (GHC) Date: Wed Dec 16 12:33:45 2009 Subject: [GHC] #2966: build system does not respect --with-gcc= In-Reply-To: <045.38910ced362f70db06ad52953362394b@localhost> References: <045.38910ced362f70db06ad52953362394b@localhost> Message-ID: <054.8eedfa9d7ff8d292e27bb53fbf73674e@localhost> #2966: build system does not respect --with-gcc= ----------------------------------+----------------------------------------- Reporter: duncan | Owner: igloo Type: bug | Status: reopened Priority: normal | Milestone: 6.12 branch Component: Build System | Version: 6.12.1 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Building GHC failed | ----------------------------------+----------------------------------------- Changes (by duncan): * failure: None/Unknown => Building GHC failed * version: 6.11 => 6.12.1 * milestone: 6.12.1 => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 16 13:03:06 2009 From: trac at galois.com (GHC) Date: Wed Dec 16 12:38:18 2009 Subject: [GHC] #650: Improve interaction between mutable arrays and GC In-Reply-To: <047.44b951cd4b5aa8536d862412c8d86597@localhost> References: <047.44b951cd4b5aa8536d862412c8d86597@localhost> Message-ID: <056.54d189e25b6b000465bcb091028f8a22@localhost> #650: Improve interaction between mutable arrays and GC --------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: Runtime System | Version: 6.4.1 Resolution: | Keywords: Difficulty: Difficult (2-5 days) | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Runtime performance bug | --------------------------------------+------------------------------------- Comment (by guest): Most of the time there won't be contention. How about using cmpxchg, and falling back to bts if there happened to be contention? Or would that also be much more expensive than byte operations? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 16 14:23:08 2009 From: trac at galois.com (GHC) Date: Wed Dec 16 14:00:43 2009 Subject: [GHC] #650: Improve interaction between mutable arrays and GC In-Reply-To: <047.44b951cd4b5aa8536d862412c8d86597@localhost> References: <047.44b951cd4b5aa8536d862412c8d86597@localhost> Message-ID: <056.7d1e1a188e5f75d59012abdafaef346a@localhost> #650: Improve interaction between mutable arrays and GC --------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: Runtime System | Version: 6.4.1 Resolution: | Keywords: Difficulty: Difficult (2-5 days) | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Runtime performance bug | --------------------------------------+------------------------------------- Comment (by simonmar): cmpxchg is also only atomic with a LOCK prefix. Typically a LOCK prefix adds on the order of 100 cycles, even without contention. Apprently it's better on Nehalem CPUs, but still we need something that works well across a variety of hardware. I don't think using byte writes are a big problem in practice. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 16 15:47:32 2009 From: trac at galois.com (GHC) Date: Wed Dec 16 15:21:32 2009 Subject: [GHC] #3751: Panic! the 'impossible' happened: charType: '\167' In-Reply-To: <053.09139966f34278370b63f1b3d0e8a13b@localhost> References: <053.09139966f34278370b63f1b3d0e8a13b@localhost> Message-ID: <062.97582db8d32089a9f5af7111bfa9f6cd@localhost> #3751: Panic! the 'impossible' happened: charType: '\167' -----------------------------+---------------------------------------------- Reporter: moleculeColony | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: lexical error Difficulty: | Os: Linux Testcase: | Architecture: x86_64 (amd64) Failure: GHCi crash | -----------------------------+---------------------------------------------- Comment (by moleculeColony): Replying to [comment:6 igloo]: > If you're trying to work out what's happening with the layout, the answer is that you need to wrap things like ghci sessions in `{{{` and `}}}`. See [wiki:WikiFormatting] for more info. Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 16 16:21:35 2009 From: trac at galois.com (GHC) Date: Wed Dec 16 15:55: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.38d3d9e4e2fb8a9e920c143877b07617@localhost> #2615: ghci doesn't play nice with linker scripts ------------------------------------------+--------------------------------- Reporter: AlecBerryman | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: GHCi | Version: 6.10.1 Resolution: | Keywords: dlopen, dynamic linking Difficulty: Unknown | Os: Linux Testcase: | Architecture: Unknown/Multiple Failure: Incorrect result at runtime | ------------------------------------------+--------------------------------- Changes (by hgolden): * owner: hgolden => igloo Comment: My patches above pass validation. Please let me know if I need to do anything else. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 16 17:07:40 2009 From: trac at galois.com (GHC) Date: Wed Dec 16 16:41:38 2009 Subject: [GHC] #3768: 6.12.1 Mac OS X installer lacks all HTML documentation Message-ID: <052.9cb08ea2ad1c2eaf3d32d7297cdfbef7@localhost> #3768: 6.12.1 Mac OS X installer lacks all HTML documentation ------------------------------+--------------------------------------------- Reporter: Minimiscience | Owner: Type: bug | Status: new Priority: normal | Component: Documentation Version: 6.12.1 | Keywords: Os: MacOS X | Testcase: Architecture: x86 | Failure: Documentation bug ------------------------------+--------------------------------------------- After upgrading GHC from 6.10.4 to 6.12.1 using the installer package for Mac OS X Leopard, I found that the local HTML documentation (aside from moving from `/usr/share/doc/ghc/index.html` to `/usr/share/doc/ghc/html/index.html`) was lacking a few parts. Specifically, the links to the user's guide, GHC API, and Cabal no longer lead to extant documents, and I was unable to find the documents that they should link to anywhere in the `/Library/Frameworks/GHC.framework/Versions` directory. The only local link that still works is the link to the library documentation, and its index page still lists some modules that are no longer distributed with the current version of GHC (specifically, the mtl package, though there may be others that I haven't come across). This was observed on Mac OS X 10.5.8 with gcc 4.0.1, though it may or may not also apply to other systems. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 16 17:42:56 2009 From: trac at galois.com (GHC) Date: Wed Dec 16 17:18:07 2009 Subject: [GHC] #650: Improve interaction between mutable arrays and GC In-Reply-To: <047.44b951cd4b5aa8536d862412c8d86597@localhost> References: <047.44b951cd4b5aa8536d862412c8d86597@localhost> Message-ID: <056.4261d85a32514ebdab1cc44d3fff65d6@localhost> #650: Improve interaction between mutable arrays and GC --------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: Runtime System | Version: 6.4.1 Resolution: | Keywords: Difficulty: Difficult (2-5 days) | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Runtime performance bug | --------------------------------------+------------------------------------- Comment (by morrow): > I must be getting old, but my feeling is that tricks like this sound quite cool but end up being a pain in the neck in the long run. To be honest, the thought of dealing with that scares the crap out of me. :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 16 17:48:45 2009 From: trac at galois.com (GHC) Date: Wed Dec 16 17:22:43 2009 Subject: [GHC] #3769: Add manpages for programs installed alongside ghc Message-ID: <052.9d14df9a6a2c1546285803fde0bb736d@localhost> #3769: Add manpages for programs installed alongside ghc ---------------------------------+------------------------------------------ Reporter: Minimiscience | Owner: Type: feature request | Status: new Priority: normal | Component: Documentation Version: 6.12.1 | Keywords: manpage documentation manpages Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Documentation bug ---------------------------------+------------------------------------------ The following programs installed with GHC (specifically, using the Mac OS X installer, though I suspect this applies to all platforms) do not have manpages: * `ghc-pkg` * `ghci` (Technically, its manpage is the same as `ghc`'s, but there's no `ghci.1` symlink to `ghc.1`, so `man ghci` fails to find anything.) * `haddock` * `hp2ps` * `hpc` * `hsc2hs` * `runghc` * `runhaskell` I think that's all of them. I realize that not all of these programs (e.g., `haddock`) are truly part of GHC, but the ones that are still need manpages. If the problem is that writing *roff is hard, and you don't mind mooching off other languages, might I refer you to [http://perldoc.perl.org/perlpod.html POD]/[http://perldoc.perl.org/pod2man.html pod2man]? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 16 18:37:39 2009 From: trac at galois.com (GHC) Date: Wed Dec 16 18:11:37 2009 Subject: [GHC] #3065: Reorder tests in quot to improve code In-Reply-To: <046.819ea32d4c70bd7d14e7ef168534bbea@localhost> References: <046.819ea32d4c70bd7d14e7ef168534bbea@localhost> Message-ID: <055.97eea4c38180a545223ee24bb2060966@localhost> #3065: Reorder tests in quot to improve code --------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: libraries/base | Version: 6.10.1 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Runtime performance bug | --------------------------------------+------------------------------------- Comment (by isaacdupree): Replying to [comment:13 rl]: > I don't feel strongly about the behaviour, either. But that's precisely the point: since the semantics doesn't really matter in this particular case, we should pick whatever has the best performance. We need to pick the same semantics for all CPUs. I worry about whether the best-performing semantic differs... at least it might differ on 32-bit vs. 64-bit for us -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 17 00:16:04 2009 From: trac at galois.com (GHC) Date: Wed Dec 16 23:50:32 2009 Subject: [GHC] #635: Replace use of select() in the I/O manager with epoll/kqueue/etc. In-Reply-To: <047.158ac52b7977b3e9f47680935a918275@localhost> References: <047.158ac52b7977b3e9f47680935a918275@localhost> Message-ID: <056.57a3864f233182c81dd654a25a7c59e9@localhost> #635: Replace use of select() in the I/O manager with epoll/kqueue/etc. -----------------------------------------+---------------------------------- Reporter: simonmar | Owner: bos Type: task | Status: new Priority: normal | Milestone: _|_ Component: libraries/base | Version: 6.4.1 Resolution: | Keywords: Difficulty: Project (more than a week) | Os: Unknown/Multiple Testcase: N/A | Architecture: Unknown/Multiple Failure: Runtime performance bug | -----------------------------------------+---------------------------------- Changes (by bos): * owner: => bos * failure: None/Unknown => Runtime performance bug Comment: I've started work on this, and have the threaded RTS's IO manager thread successfully using either poll or select, depending on the system. This step alone is a big deal, because select has a low fixed limit on the number of file descriptors it can manage, usually 1,024. Using poll instead removes that limit. There is a lot more work to do, but this seems like a good start. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 17 00:20:59 2009 From: trac at galois.com (GHC) Date: Wed Dec 16 23:55:21 2009 Subject: [GHC] #635: Replace use of select() in the I/O manager with epoll/kqueue/etc. In-Reply-To: <047.158ac52b7977b3e9f47680935a918275@localhost> References: <047.158ac52b7977b3e9f47680935a918275@localhost> Message-ID: <056.90af0c814d3be4fb1b0895e0b1e3e79b@localhost> #635: Replace use of select() in the I/O manager with epoll/kqueue/etc. -----------------------------------------+---------------------------------- Reporter: simonmar | Owner: bos Type: task | Status: new Priority: normal | Milestone: _|_ Component: libraries/base | Version: 6.4.1 Resolution: | Keywords: Difficulty: Project (more than a week) | Os: Unknown/Multiple Testcase: N/A | Architecture: Unknown/Multiple Failure: Runtime performance bug | -----------------------------------------+---------------------------------- Comment (by bos): I've attached the current working patch to this ticket. It applies cleanly against both base 4.2.0.0 (as used in GHC 6.12.1) and the version used by HEAD. Simon, I think this patch is worth applying on top of base-4.2.0.0 as is, since it removes that pesky dependency on select. This would be a nice fix to have in GHC 6.12.2. For more substantial changes (use of epoll or kqueue), the amount of work involved is much higher. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 17 01:01:10 2009 From: trac at galois.com (GHC) Date: Thu Dec 17 00:35:08 2009 Subject: [GHC] #3758: Huge regression in concurrent app performance and reliability under threaded runtime In-Reply-To: <042.942d2a7fe8a29f75a39eae02838820a0@localhost> References: <042.942d2a7fe8a29f75a39eae02838820a0@localhost> Message-ID: <051.6cf98c09c4e300142a7717f03c0bbfef@localhost> #3758: Huge regression in concurrent app performance and reliability under threaded runtime -----------------------------+---------------------------------------------- Reporter: bos | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.12.2 Component: Runtime System | Version: 6.12.1 Resolution: | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86_64 (amd64) Failure: Runtime crash | -----------------------------+---------------------------------------------- Comment (by bos): Simon, thanks for looking into this. I tried the same benchmarks, only this time using a Mac running ab as the client over a gigabit ethernet connection. With 6.12.1, {{{-N2 -qg}}}, I get good numbers: just below 15,000 requests per second. With plain {{{-N2}}} (hence using parallel GC), the numbers don't take as big a dive as when I was running client and server on a single box, but they still drop to about 7,500 requests per second, a 50% reduction in throughput. Since the server has nothing else running on it in this case, I really do have 2 CPUs available. I think :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 17 03:05:32 2009 From: trac at galois.com (GHC) Date: Thu Dec 17 02:39:29 2009 Subject: [GHC] #3309: getArgs should return Unicode on Unix In-Reply-To: <047.aeeed4251d6d88157f87d6d7a9cbe6b7@localhost> References: <047.aeeed4251d6d88157f87d6d7a9cbe6b7@localhost> Message-ID: <056.c065821d51690ab5483099908d62ecbb@localhost> #3309: getArgs should return Unicode on Unix -----------------------------+---------------------------------------------- Reporter: YitzGale | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: libraries/base | Version: 6.11 Resolution: | Keywords: unicode Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | -----------------------------+---------------------------------------------- Changes (by slyfox): * failure: => None/Unknown Comment: Replying to [ticket:3309 YitzGale]: > The raw bytes of args should be decoded according to the current locale. > > An additional function should be added: > {{{ > getArgsBytes :: IO [Word8] > }}} s/\[Word8\]/\[\[Word\]\]/ :] > to provide access to the raw bytes. > > This change needs to be coordinated with #3007 so that it will still > work to read a file name from the command line args and use it > to access a file. > > This change should also be made on Windows: #3008 > > See the discussion at http://www.haskell.org/pipermail/haskell- cafe/2009-June/062795.html Or, maybe, make '''getArgs'''/'''readFile''' and friends polymorphic like '''Text.Printf printf''' does? {{{ Text.Printf printf :: PrintfType r => String -> r instance (IsChar c) => PrintfType [c] -- Defined in Text.Printf instance PrintfType (IO a) -- Defined in Text.Printf instance (PrintfArg a, PrintfType r) => PrintfType (a -> r) }}} In our case it would be something like {{{ getArgs :: StringAlike s => IO [s] and usage would look like: foo = getArgs :: [[Word8]] -- raw bytes foo = getArgs :: [ByteString] -- raw bytes in fast bytestring foo = getArgs :: [String] -- locale encoded -- maybe, anothers? }}} Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 17 03:06:10 2009 From: trac at galois.com (GHC) Date: Thu Dec 17 02:40:14 2009 Subject: [GHC] #3309: getArgs should return Unicode on Unix In-Reply-To: <047.aeeed4251d6d88157f87d6d7a9cbe6b7@localhost> References: <047.aeeed4251d6d88157f87d6d7a9cbe6b7@localhost> Message-ID: <056.c3378130014deb9e1b1042d2c69864d6@localhost> #3309: getArgs should return Unicode on Unix -----------------------------+---------------------------------------------- Reporter: YitzGale | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: libraries/base | Version: 6.11 Resolution: | Keywords: unicode Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | -----------------------------+---------------------------------------------- Changes (by slyfox): * cc: slyfox@community.haskell.org (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 17 04:07:46 2009 From: trac at galois.com (GHC) Date: Thu Dec 17 03:41:43 2009 Subject: [GHC] #3770: getting docs out of windows distro Message-ID: <044.fa6a25b99b7d2e9e215f49ac6f3aab06@localhost> #3770: getting docs out of windows distro ---------------------------------+------------------------------------------ Reporter: denis | Owner: Type: feature request | Status: new Priority: normal | Component: None Version: 6.12.1 | Keywords: ditribution Os: Windows | Testcase: Architecture: Unknown/Multiple | Failure: Other ---------------------------------+------------------------------------------ Would you be so kind as to split the _windows_ distribution into binary, mingw, and doc packages? The doc distribution is bloated intolerably. You see, if one wants to upgrade the binary, one also has to reinstall 370 MiB of tiny html stuff that could be found online, for example... -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 17 04:24:21 2009 From: trac at galois.com (GHC) Date: Thu Dec 17 03:59:01 2009 Subject: [GHC] #2933: LDFLAGS ignored by build system In-Reply-To: <045.854117476da424db3736910ffba011f0@localhost> References: <045.854117476da424db3736910ffba011f0@localhost> Message-ID: <054.d3a2d5f42259a0d435b49669f5371d3d@localhost> #2933: LDFLAGS ignored by build system ---------------------------+------------------------------------------------ Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Build System | Version: 6.10.1 Resolution: | Keywords: Difficulty: Unknown | Os: Solaris Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by PHO): * cc: pho@cielonegro.org (added) * failure: => None/Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 17 04:29:57 2009 From: trac at galois.com (GHC) Date: Thu Dec 17 04:04:24 2009 Subject: [GHC] #635: Replace use of select() in the I/O manager with epoll/kqueue/etc. In-Reply-To: <047.158ac52b7977b3e9f47680935a918275@localhost> References: <047.158ac52b7977b3e9f47680935a918275@localhost> Message-ID: <056.d9455e75bd5c0d4052db6cf4cb1b55b2@localhost> #635: Replace use of select() in the I/O manager with epoll/kqueue/etc. -----------------------------------------+---------------------------------- Reporter: simonmar | Owner: bos Type: task | Status: new Priority: normal | Milestone: _|_ Component: libraries/base | Version: 6.4.1 Resolution: | Keywords: Difficulty: Project (more than a week) | Os: Unknown/Multiple Testcase: N/A | Architecture: Unknown/Multiple Failure: Runtime performance bug | -----------------------------------------+---------------------------------- Comment (by simonmar): This does look like a step in the right direction. How does this compare in performance to the select version? Glancing at the patch it looks like building the fdset will be more expensive than before. There's one withForeignPtr per FD. The INLINEs on the C functions don't have any effect (unfortunately), even with `-fvia-C`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 17 05:56:57 2009 From: trac at galois.com (GHC) Date: Thu Dec 17 05:30:55 2009 Subject: [GHC] #3751: Panic! the 'impossible' happened: charType: '\167' In-Reply-To: <053.09139966f34278370b63f1b3d0e8a13b@localhost> References: <053.09139966f34278370b63f1b3d0e8a13b@localhost> Message-ID: <062.6fca6c3a5149ae9caf7a79bb9d28d7ea@localhost> #3751: Panic! the 'impossible' happened: charType: '\167' ---------------------------------+------------------------------------------ Reporter: moleculeColony | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: Compiler (Parser) | Version: 6.10.4 Resolution: | Keywords: lexical error Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Compile-time crash | ---------------------------------+------------------------------------------ Changes (by simonmar): * component: Compiler => Compiler (Parser) * failure: GHCi crash => Compile-time crash * architecture: x86_64 (amd64) => Unknown/Multiple * milestone: => 6.12.2 * owner: => simonmar * os: Linux => Unknown/Multiple Comment: I have a fix for this awaiting validation. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 17 05:59:21 2009 From: trac at galois.com (GHC) Date: Thu Dec 17 05:33:19 2009 Subject: [GHC] #3065: Reorder tests in quot to improve code In-Reply-To: <046.819ea32d4c70bd7d14e7ef168534bbea@localhost> References: <046.819ea32d4c70bd7d14e7ef168534bbea@localhost> Message-ID: <055.708963b959385b2bb9733331b4ac7194@localhost> #3065: Reorder tests in quot to improve code --------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: libraries/base | Version: 6.10.1 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Runtime performance bug | --------------------------------------+------------------------------------- Comment (by simonmar): Replying to [comment:15 isaacdupree]: > We need to pick the same semantics for all CPUs. I worry about whether the best-performing semantic differs... at least it might differ on 32-bit vs. 64-bit for us The semantics will be the same for all CPUs. The proposed change can't make performance any ''worse'', but it can improve performance on some CPUs where the native division semantics matches what we expose in Haskell. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 17 06:05:15 2009 From: trac at galois.com (GHC) Date: Thu Dec 17 05:39:17 2009 Subject: [GHC] #3758: Huge regression in concurrent app performance and reliability under threaded runtime In-Reply-To: <042.942d2a7fe8a29f75a39eae02838820a0@localhost> References: <042.942d2a7fe8a29f75a39eae02838820a0@localhost> Message-ID: <051.3666de132d938f7753c8cc736ed04137@localhost> #3758: Huge regression in concurrent app performance and reliability under threaded runtime -----------------------------+---------------------------------------------- Reporter: bos | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.12.2 Component: Runtime System | Version: 6.12.1 Resolution: | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86_64 (amd64) Failure: Runtime crash | -----------------------------+---------------------------------------------- Comment (by simonmar): I'll investigate some more, but what I think is happening is that we're only really using one core at a time, and the other core is mostly asleep (the !ThreadScope profile confirms this). Hence, when using the parallel GC we have to keep waking up the second core and waiting for it, when in fact it would be better to just do a single-threaded GC. Now, I don't understand yet why the benchmark isn't keeping both cores busy, but we ought to be able to debug that using !ThreadScope. Are you still seeing the deadlocks, BTW? I couldn't reproduce that on my dual-core laptop running Ubuntu Karmic (32-bit). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 17 07:01:18 2009 From: trac at galois.com (GHC) Date: Thu Dec 17 06:35:20 2009 Subject: [GHC] #3633: Heap size suggestion of > 2145 MB gets ignored In-Reply-To: <042.715300f691a60275dfa2a5a83e344a71@localhost> References: <042.715300f691a60275dfa2a5a83e344a71@localhost> Message-ID: <051.cc775f1c1698ee9e2ebba5a883fdabb0@localhost> #3633: Heap size suggestion of > 2145 MB gets ignored -----------------------------+---------------------------------------------- Reporter: tim | Owner: igloo Type: merge | Status: closed Priority: high | Milestone: 6.12.2 Component: Runtime System | Version: 6.10.4 Resolution: fixed | Keywords: Difficulty: | Os: MacOS X Testcase: | Architecture: x86 Failure: None/Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 17 07:01:59 2009 From: trac at galois.com (GHC) Date: Thu Dec 17 06:36:00 2009 Subject: [GHC] #3760: 6.12.1 Build failure on FreeBSD In-Reply-To: <042.1a92c93a3edbe9458a808b65c3b82152@localhost> References: <042.1a92c93a3edbe9458a808b65c3b82152@localhost> Message-ID: <051.690dcf20b8c591dfe5fb9fc91fc99274@localhost> #3760: 6.12.1 Build failure on FreeBSD ----------------------------------+----------------------------------------- Reporter: PHO | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.12.2 Component: Runtime System | Version: 6.12.1 Resolution: fixed | Keywords: Difficulty: | Os: FreeBSD Testcase: | Architecture: Unknown/Multiple Failure: Building GHC failed | ----------------------------------+----------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 17 07:02:30 2009 From: trac at galois.com (GHC) Date: Thu Dec 17 06:36:29 2009 Subject: [GHC] #3730: hp2ps: Deviation.c:(.text+0x42b): undefined reference to `sqrt' In-Reply-To: <045.ec140461375c1820e8f386032560a656@localhost> References: <045.ec140461375c1820e8f386032560a656@localhost> Message-ID: <054.5b63afa8f95b4d701016395c722c6f08@localhost> #3730: hp2ps: Deviation.c:(.text+0x42b): undefined reference to `sqrt' ----------------------------------+----------------------------------------- Reporter: slyfox | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.12.2 Component: Build System | Version: 6.10.4 Resolution: fixed | Keywords: autoconf, libm, patch Difficulty: | Os: Linux Testcase: | Architecture: x86_64 (amd64) Failure: Building GHC failed | ----------------------------------+----------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 17 07:03:06 2009 From: trac at galois.com (GHC) Date: Thu Dec 17 06:37:03 2009 Subject: [GHC] #414: GHC does not eforce that Main exports main In-Reply-To: <046.38fe8da23abfc42f9ad2cb0e14b8afda@localhost> References: <046.38fe8da23abfc42f9ad2cb0e14b8afda@localhost> Message-ID: <055.b661c48d96fa6b591638e860b8c3b0f2@localhost> #414: GHC does not eforce that Main exports main ---------------------------+------------------------------------------------ Reporter: simonpj | Owner: igloo Type: merge | Status: closed Priority: lowest | Milestone: 6.12.2 Component: Compiler | Version: 6.10.4 Resolution: fixed | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: mod174 | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * status: new => closed * resolution: None => fixed Comment: Both merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 17 07:04:21 2009 From: trac at galois.com (GHC) Date: Thu Dec 17 06:38:18 2009 Subject: [GHC] #3724: rts/package.conf.d specifies -lm for all platforms In-Reply-To: <043.58505aaf8b324d493ddba3cfafc80288@localhost> References: <043.58505aaf8b324d493ddba3cfafc80288@localhost> Message-ID: <052.f96e67035634303c95569ad9770cb469@localhost> #3724: rts/package.conf.d specifies -lm for all platforms ----------------------------------+----------------------------------------- Reporter: donn | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.12.2 Component: Build System | Version: 6.12.1 RC1 Resolution: fixed | Keywords: Difficulty: | Os: Other Testcase: | Architecture: x86 Failure: Building GHC failed | ----------------------------------+----------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 17 07:05:05 2009 From: trac at galois.com (GHC) Date: Thu Dec 17 06:39:03 2009 Subject: [GHC] #3514: mallocPlainForeignPtrBytes -1000 gives runtime internal error: allocGroup: requested zero blocks In-Reply-To: <052.f949c738ea0d9d2b66116addc98fdaed@localhost> References: <052.f949c738ea0d9d2b66116addc98fdaed@localhost> Message-ID: <061.45e2021e21371afb3c1ff517ae67b01c@localhost> #3514: mallocPlainForeignPtrBytes -1000 gives runtime internal error: allocGroup: requested zero blocks -----------------------------+---------------------------------------------- Reporter: andrewbirkett | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.12.2 Component: Runtime System | Version: 6.10.4 Resolution: fixed | Keywords: Difficulty: Unknown | Os: Linux Testcase: | Architecture: x86 Failure: None/Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 17 07:05:25 2009 From: trac at galois.com (GHC) Date: Thu Dec 17 06:39:26 2009 Subject: [GHC] #3723: SharedMem.hsc should include , not In-Reply-To: <043.3ccfd43c4f25a82e84eff1b44d03ad03@localhost> References: <043.3ccfd43c4f25a82e84eff1b44d03ad03@localhost> Message-ID: <052.6a238b2c210f789ec39e8b470d198193@localhost> #3723: SharedMem.hsc should include , not ----------------------------------+----------------------------------------- Reporter: donn | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.12.2 Component: libraries/unix | Version: 6.12.1 RC1 Resolution: fixed | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Building GHC failed | ----------------------------------+----------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 17 07:34:19 2009 From: trac at galois.com (GHC) Date: Thu Dec 17 07:08:17 2009 Subject: [GHC] #3738: Typechecker floats stuff out of INLINE right hand sides In-Reply-To: <041.d227e4e2f98d3171cf4e574a410067a1@localhost> References: <041.d227e4e2f98d3171cf4e574a410067a1@localhost> Message-ID: <050.cac6fb10c4f80e778bcde647554b82d7@localhost> #3738: Typechecker floats stuff out of INLINE right hand sides --------------------------------------+------------------------------------- Reporter: rl | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14 branch Component: Compiler | Version: 6.13 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Runtime performance bug | --------------------------------------+------------------------------------- Comment (by simonpj): Not a problem. See `Note [Simplifying inside InlineRules]` in `SimplUtils`. Since the `InlineRule` for `bar` is active in the initial phase we will not inline `foo` since the inlining only becomes active in phase 1. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 17 07:47:11 2009 From: trac at galois.com (GHC) Date: Thu Dec 17 07:21:07 2009 Subject: [GHC] #3738: Typechecker floats stuff out of INLINE right hand sides In-Reply-To: <041.d227e4e2f98d3171cf4e574a410067a1@localhost> References: <041.d227e4e2f98d3171cf4e574a410067a1@localhost> Message-ID: <050.0871c65afb0eb4bf9ea11f7d69d402d4@localhost> #3738: Typechecker floats stuff out of INLINE right hand sides --------------------------------------+------------------------------------- Reporter: rl | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14 branch Component: Compiler | Version: 6.13 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Runtime performance bug | --------------------------------------+------------------------------------- Comment (by rl): Are you saying that it's not a problem now or won't be a problem with the new constraint simplifier? At the moment, `foo` won't appear in `bar`'s unfolding even with `{-# INLINE [1] foo #-}`. This has nothing to do with the simplifier; as you point out, it is floated out by the typechecker which doesn't care about phasing. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 17 08:44:45 2009 From: trac at galois.com (GHC) Date: Thu Dec 17 08:18:42 2009 Subject: [GHC] #3065: Reorder tests in quot to improve code In-Reply-To: <046.819ea32d4c70bd7d14e7ef168534bbea@localhost> References: <046.819ea32d4c70bd7d14e7ef168534bbea@localhost> Message-ID: <055.412488f379fa13ed06c060760cefb709@localhost> #3065: Reorder tests in quot to improve code --------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: libraries/base | Version: 6.10.1 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Runtime performance bug | --------------------------------------+------------------------------------- Comment (by rl): Replying to [comment:14 simonmar]: > volunteers? I'd be happy to do it but I don't really know enough about the NCG so I'd need to be pointed in the right direction. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 17 09:35:58 2009 From: trac at galois.com (GHC) Date: Thu Dec 17 09:09:57 2009 Subject: [GHC] #3771: haddock: internal error: evacuate: strange closure type 19269 Message-ID: <045.5a5990fc01611a666ea323a5f0afc325@localhost> #3771: haddock: internal error: evacuate: strange closure type 19269 --------------------------+------------------------------------------------- Reporter: dbueno | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.12.1 | Keywords: Os: MacOS X | Testcase: Architecture: powerpc64 | Failure: Building GHC failed --------------------------+------------------------------------------------- Here are the last few lines of `make` output {{{ "rm" -f libraries/unix/dist-install/build/libHSunix-2.4.0.0_p.a (echo libraries/unix/dist-install/build/cbits/HsUnix.p_o libraries/unix /dist-install/build/cbits/execvpe.p_o libraries/unix/dist- install/build/cbits/dirUtils.p_o `/usr/bin/find libraries/unix/dist- install/build -name "*_stub.p_o" -print`; /usr/bin/find libraries/unix /dist-install/build/System/Posix_p_o_split libraries/unix/dist- install/build/System/Posix/DynamicLinker/Module_p_o_split libraries/unix /dist-install/build/System/Posix/DynamicLinker/Prim_p_o_split libraries/unix/dist-install/build/System/Posix/Directory_p_o_split libraries/unix/dist-install/build/System/Posix/DynamicLinker_p_o_split libraries/unix/dist-install/build/System/Posix/Env_p_o_split libraries/unix/dist-install/build/System/Posix/Error_p_o_split libraries/unix/dist-install/build/System/Posix/Files_p_o_split libraries/unix/dist-install/build/System/Posix/IO_p_o_split libraries/unix /dist-install/build/System/Posix/Process_p_o_split libraries/unix/dist- install/build/System/Posix/Process/Internals_p_o_split libraries/unix /dist-install/build/System/Posix/Resource_p_o_split libraries/unix/dist- install/build/System/Posix/Temp_p_o_split libraries/unix/dist- install/build/System/Posix/Terminal_p_o_split libraries/unix/dist- install/build/System/Posix/Time_p_o_split libraries/unix/dist- install/build/System/Posix/Unistd_p_o_split libraries/unix/dist- install/build/System/Posix/User_p_o_split libraries/unix/dist- install/build/System/Posix/Signals_p_o_split libraries/unix/dist- install/build/System/Posix/Signals/Exts_p_o_split libraries/unix/dist- install/build/System/Posix/Semaphore_p_o_split libraries/unix/dist- install/build/System/Posix/SharedMem_p_o_split -name '*.p_o' -print) | "xargs" "/usr/bin/ar" clqs libraries/unix/dist- install/build/libHSunix-2.4.0.0_p.a "inplace/bin/mkdirhier" libraries/unix/dist-install/doc/html/unix/ "inplace/bin/ghc-cabal" haddock dist-install libraries/unix --with- haddock=/Users/dbueno/Downloads/ghc-6.12.1/inplace/bin/haddock --with- ghc=/Users/dbueno/Downloads/ghc-6.12.1/inplace/bin/ghc-stage2 Running Haddock for unix-2.4.0.0... Preprocessing library unix-2.4.0.0... Warning: The documentation for the following packages are not installed. No links will be generated to these packages: ffi-1.0, rts-1.0 haddock: internal error: evacuate: strange closure type 19269 (GHC version 6.12.1 for powerpc_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[1]: *** [libraries/unix/dist-install/doc/html/unix/unix.haddock] Error 6 make: *** [all] Error 2 }}} I did the following to build: {{{ ./configure --prefix=/usr/local/ghc-6.12.4 make }}} I'm on `Darwin power-mac-g5.local 9.7.0 Darwin Kernel Version 9.7.0: Tue Mar 31 22:54:29 PDT 2009; root:xnu-1228.12.14~1/RELEASE_PPC Power Macintosh`. What other information do you need? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 17 10:03:31 2009 From: trac at galois.com (GHC) Date: Thu Dec 17 09:37:29 2009 Subject: [GHC] #3771: haddock: internal error: evacuate: strange closure type 19269 In-Reply-To: <045.5a5990fc01611a666ea323a5f0afc325@localhost> References: <045.5a5990fc01611a666ea323a5f0afc325@localhost> Message-ID: <054.8b3c48abbf379838f37f4daef757261d@localhost> #3771: haddock: internal error: evacuate: strange closure type 19269 --------------------------+------------------------------------------------- Reporter: dbueno | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.12.1 Resolution: | Keywords: Os: MacOS X | Testcase: Architecture: powerpc64 | Failure: Building GHC failed --------------------------+------------------------------------------------- Comment (by dbueno): Sorry, that build process isn't exactly what I did. I did that, but first I did `sh boot`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 17 10:46:25 2009 From: trac at galois.com (GHC) Date: Thu Dec 17 10:20:22 2009 Subject: [GHC] #3772: Methods not inlined Message-ID: <041.149838f1167826da5472d3fc400a3e07@localhost> #3772: Methods not inlined ---------------------------------+------------------------------------------ Reporter: rl | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.12.1 | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Runtime performance bug ---------------------------------+------------------------------------------ This affects both 6.12 and the HEAD (albeit differently) but works fine with 6.10. It also works if everything is in one module. We are interested in the function `U.foo`; in particular, we want the call to `deepSeq` (resulting from inlining `T.apply`) to be inlined. This is what we get with 6.10 (compiling with `-O2`): {{{ go_riA :: [GHC.Types.Double] -> () go_riA = \ (ds_agP :: [GHC.Types.Double]) -> case ds_agP of wild_agQ { [] -> GHC.Unit.(); : y_agU ys_agV -> case y_agU of tpl2_ah1 { GHC.Types.D# ipv_ah3 -> go_riA ys_agV } } U.foo :: GHC.Types.Int -> () U.foo = \ (n_afR :: GHC.Types.Int) -> case n_afR of w_Xhn { GHC.Types.I# ww_ahi -> go_riA (T.$wgen @ GHC.Types.Double T.$f2 ww_ahi) } }}} Everything has been nicely inlined. With 6.12, we get this: {{{ U.foo [NEVER Nothing] :: GHC.Types.Int -> () U.foo = \ (n_adD :: GHC.Types.Int) -> case n_adD of _ { GHC.Types.I# ww_afv -> let { eta_sgc :: [GHC.Types.Double] eta_sgc = T.$wgen @ GHC.Types.Double T.$fCDouble ww_afv } in __inline_me (GHC.Base.foldr @ GHC.Types.Double @ () (T.$fCDouble1 @ ()) GHC.Unit.() eta_sgc) } }}} The `deepSeq` call has been inlined but hasn't been optimised, I guess because GHC retained the `__inline_me` for some reason. Things are even worse with the HEAD: {{{ U.foo :: GHC.Types.Int -> () U.foo = \ (n_aaO :: GHC.Types.Int) -> case n_aaO of _ { GHC.Types.I# ww_abR -> T.$fC[]1 @ GHC.Types.Double T.$fCDouble @ () (T.$w$cgen @ GHC.Types.Double T.$fCDouble ww_abR) GHC.Unit.() } }}} Here, `deepSeq` hasn't even been inlined. But let's add a dummy method to `DeepSeq`: {{{ class DeepSeq a where deepSeq :: a -> b -> b dummy :: a dummy = undefined }}} Now, the HEAD actually inlines the call: {{{ go_rcM :: [GHC.Types.Double] -> () go_rcM = \ (ds_acl :: [GHC.Types.Double]) -> case ds_acl of _ { [] -> GHC.Unit.(); : y_acq ys_acr -> case y_acq of _ { GHC.Types.D# _ -> go_rcM ys_acr } } U.foo :: GHC.Types.Int -> () U.foo = \ (n_aaQ :: GHC.Types.Int) -> case n_aaQ of _ { GHC.Types.I# ww_abI -> go_rcM (T.$w$cgen @ GHC.Types.Double T.$fCDouble ww_abI) } }}} Unfortunately, 6.12 still doesn't. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 17 10:48:41 2009 From: trac at galois.com (GHC) Date: Thu Dec 17 10:22:38 2009 Subject: [GHC] #3738: Typechecker floats stuff out of INLINE right hand sides In-Reply-To: <041.d227e4e2f98d3171cf4e574a410067a1@localhost> References: <041.d227e4e2f98d3171cf4e574a410067a1@localhost> Message-ID: <050.ff96c98f321d9f41fb15af99d13869c3@localhost> #3738: Typechecker floats stuff out of INLINE right hand sides --------------------------------------+------------------------------------- Reporter: rl | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14 branch Component: Compiler | Version: 6.13 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Runtime performance bug | --------------------------------------+------------------------------------- Comment (by simonpj): You are quite right. I was being stupid. The type checker really, really should not float that stuff out. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 17 10:49:06 2009 From: trac at galois.com (GHC) Date: Thu Dec 17 10:23:01 2009 Subject: [GHC] #3772: Methods not inlined In-Reply-To: <041.149838f1167826da5472d3fc400a3e07@localhost> References: <041.149838f1167826da5472d3fc400a3e07@localhost> Message-ID: <050.8f9567fd4acdc7b9e9ddc9cde0114ef5@localhost> #3772: Methods not inlined ---------------------------------+------------------------------------------ Reporter: rl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.12.1 Resolution: | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Runtime performance bug ---------------------------------+------------------------------------------ Comment (by rl): Argh, please ignore `Tst.hs`, uploading files is too hard for me... -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 17 12:01:21 2009 From: trac at galois.com (GHC) Date: Thu Dec 17 11:35:53 2009 Subject: [GHC] #635: Replace use of select() in the I/O manager with epoll/kqueue/etc. In-Reply-To: <047.158ac52b7977b3e9f47680935a918275@localhost> References: <047.158ac52b7977b3e9f47680935a918275@localhost> Message-ID: <056.96e97e0efe7a4058df4615ce1e661149@localhost> #635: Replace use of select() in the I/O manager with epoll/kqueue/etc. -----------------------------------------+---------------------------------- Reporter: simonmar | Owner: bos Type: task | Status: new Priority: normal | Milestone: _|_ Component: libraries/base | Version: 6.4.1 Resolution: | Keywords: Difficulty: Project (more than a week) | Os: Unknown/Multiple Testcase: N/A | Architecture: Unknown/Multiple Failure: Runtime performance bug | -----------------------------------------+---------------------------------- Comment (by bos): There is indeed one `withForeignPtr` per FD. ISTR I'd been told that was effectively free, so I didn't worry about it. Clearly, we could use a plain Ptr instead and just free the pollfd data by hand when shutting down. I'll have benchmark numbers within a couple of days. I seem not to have the flu finally, so I have to do Real Work again. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 17 12:03:10 2009 From: trac at galois.com (GHC) Date: Thu Dec 17 11:37:11 2009 Subject: [GHC] #3758: Huge regression in concurrent app performance and reliability under threaded runtime In-Reply-To: <042.942d2a7fe8a29f75a39eae02838820a0@localhost> References: <042.942d2a7fe8a29f75a39eae02838820a0@localhost> Message-ID: <051.deca25328e9ab76a359f4b35cc0c19dd@localhost> #3758: Huge regression in concurrent app performance and reliability under threaded runtime -----------------------------+---------------------------------------------- Reporter: bos | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.12.2 Component: Runtime System | Version: 6.12.1 Resolution: | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86_64 (amd64) Failure: Runtime crash | -----------------------------+---------------------------------------------- Comment (by bos): I only see the deadlocks when running server and client on the same machine. Everything seems reliable when they're physically separate. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 17 12:05:53 2009 From: trac at galois.com (GHC) Date: Thu Dec 17 11:39:55 2009 Subject: [GHC] #3758: Huge regression in concurrent app performance and reliability under threaded runtime In-Reply-To: <042.942d2a7fe8a29f75a39eae02838820a0@localhost> References: <042.942d2a7fe8a29f75a39eae02838820a0@localhost> Message-ID: <051.a28a56d1ef80681dbfcca69ce9738a97@localhost> #3758: Huge regression in concurrent app performance and reliability under threaded runtime -----------------------------+---------------------------------------------- Reporter: bos | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.12.2 Component: Runtime System | Version: 6.12.1 Resolution: | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86_64 (amd64) Failure: Runtime crash | -----------------------------+---------------------------------------------- Comment (by bos): By the way, as far as only using one core is concerned, it might be related to the I/O manager being a single thread. Since the worker threads ought in principle to be able to do their job by running two system calls, I wouldn't be terribly surprised if the I/O manager was the choke point. Is that something that ThreadScope could show? I'll probably need to add event logging to the I/O manager as I get deeper into reworking it anyway :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 17 13:07:48 2009 From: trac at galois.com (GHC) Date: Thu Dec 17 12:41:46 2009 Subject: [GHC] #3736: GHC specialising instead of inlining In-Reply-To: <044.6187e75fed543439fb0c0aaede8523f0@localhost> References: <044.6187e75fed543439fb0c0aaede8523f0@localhost> Message-ID: <053.5e181fe6417f419fc58a4eea54636293@localhost> #3736: GHC specialising instead of inlining --------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86 Failure: Runtime performance bug | --------------------------------------+------------------------------------- Comment (by guest): Sorry for the inconvenience! I'll prepare a package with minimal dependencies. Only for clarification: special-functors is a compatibility package that provides Control.Applicative and the like for base<2. 'transformers' should only depend on it for base<2, but it may be that Cabal tries 'special-functors' because 'transformers' is not prepared for the current version of 'base'. I assume that extending the version range for base in transformer.cabal would solve this problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 17 13:54:00 2009 From: trac at galois.com (GHC) Date: Thu Dec 17 13:34:29 2009 Subject: [GHC] #3333: GHCi doesn't load weak symbols In-Reply-To: <047.f7df20b3080234226b9f5744151738a8@localhost> References: <047.f7df20b3080234226b9f5744151738a8@localhost> Message-ID: <056.13bba3ec1d038b0f584ca5e4218fa698@localhost> #3333: GHCi doesn't load weak symbols ---------------------------+------------------------------------------------ Reporter: heatsink | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: GHCi | Version: 6.10.4 Resolution: | Keywords: weak, dynamic loading Difficulty: Unknown | Os: Linux Testcase: | Architecture: x86 Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by guest): * cc: ghc@henning-thielemann.de (added) * failure: => None/Unknown * version: 6.10.3 => 6.10.4 Comment: I encountered the same problem with LLVM recently. LLVM is also a C++ library with C interface. I did the following hack, without knowing what I'm really doing. I needed to build shared object files of the LLVM libraries anyway, in order to use them in GHCi. Then I built a big .so file containing all libraries (.a) and object files (.o) of LLVM. There the symbols seems to have been resolved. {{{ # get many small object (.o) files out of the libraries (.a) for src in /usr/lib/llvm/*.a; do ar -x $src ; done # assemble those object files and the other ones of LLVM project to a big shared object file (.so) gcc -shared -Wl,-soname,libLLVM.so.2.5 -o libLLVM.so.2.5 /usr/lib/llvm/LLVM*.o *.o # provide the file with default name ln -s libLLVM.so.2.5 libLLVM.so # remove interim object files rm *.o }}} I also had to replace the linker options -lLLVMSupport -lLLVMCore and so on by -lLLVM (the monolithic so-file) in the fields extraLibraries and ldOptions ~/.ghc/i386-linux-6.10.4/package.conf for the Haskell package 'llvm'. I have no idea whether this hack would work for other libraries. Btw. If you want to use LLVM in GHCi you may also have to respect the linker script problem described in #2615 and remove the pthread dependency in package.conf, too. With all those steps I could use LLVM in GHCi, but after a :reload, running an LLVM function causes GHCi to quit with: {{{ ghci: JITEmitter.cpp:110: ::JITResolver::JITResolver(llvm::JIT&): Assertion `TheJITResolver == 0 && "Multiple JIT resolvers?"' failed. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 17 14:07:37 2009 From: trac at galois.com (GHC) Date: Thu Dec 17 13:41:49 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.6e0b92e942bdf11a4fe131c09b73751f@localhost> #2615: ghci doesn't play nice with linker scripts ------------------------------------------+--------------------------------- Reporter: AlecBerryman | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: GHCi | Version: 6.10.1 Resolution: | Keywords: dlopen, dynamic linking Difficulty: Unknown | Os: Linux Testcase: | Architecture: Unknown/Multiple Failure: Incorrect result at runtime | ------------------------------------------+--------------------------------- Comment (by guest): Replying to [comment:16 guest]: > Where do I have to remove pthread? In the special case of LLVM I could just remove occurences of pthread from ~/.ghc/i386-linux-6.10.4/package.conf for the llvm package in order to solve that problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 17 17:08:26 2009 From: trac at galois.com (GHC) Date: Thu Dec 17 16:42:31 2009 Subject: [GHC] #3771: haddock: internal error: evacuate: strange closure type 19269 In-Reply-To: <045.5a5990fc01611a666ea323a5f0afc325@localhost> References: <045.5a5990fc01611a666ea323a5f0afc325@localhost> Message-ID: <054.c73fa9c776bc9b2e9b989ad38f6da613@localhost> #3771: haddock: internal error: evacuate: strange closure type 19269 --------------------------+------------------------------------------------- Reporter: dbueno | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.12.1 Resolution: | Keywords: Os: MacOS X | Testcase: Architecture: powerpc64 | Failure: Building GHC failed --------------------------+------------------------------------------------- Comment (by danrabin): I've also seen this exact behavior, also on Darwin ppc g5, Mac OS 10.5.8, all config and make parameters defaulted. There is a GHC 6.10.4 build present in the $PATH, installed under /opt/local via MacPorts, but there were no previous GHC builds left under /usr/local. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 17 17:52:58 2009 From: trac at galois.com (GHC) Date: Thu Dec 17 17:26:54 2009 Subject: [GHC] #3065: Reorder tests in quot to improve code In-Reply-To: <046.819ea32d4c70bd7d14e7ef168534bbea@localhost> References: <046.819ea32d4c70bd7d14e7ef168534bbea@localhost> Message-ID: <055.e20fca9c2409b5f4b52038b4be90c731@localhost> #3065: Reorder tests in quot to improve code --------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: libraries/base | Version: 6.10.1 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Runtime performance bug | --------------------------------------+------------------------------------- Comment (by simonmar): I would do it in the translation from STG to Cmm, i.e. in `CgPrimOp`. It can be target-specific if necessary - the Cmm translation is already target-specific in various ways. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 17 18:02:48 2009 From: trac at galois.com (GHC) Date: Thu Dec 17 17:37:26 2009 Subject: [GHC] #635: Replace use of select() in the I/O manager with epoll/kqueue/etc. In-Reply-To: <047.158ac52b7977b3e9f47680935a918275@localhost> References: <047.158ac52b7977b3e9f47680935a918275@localhost> Message-ID: <056.1a8915bb1d9cb816d919a22d43d40777@localhost> #635: Replace use of select() in the I/O manager with epoll/kqueue/etc. -----------------------------------------+---------------------------------- Reporter: simonmar | Owner: bos Type: task | Status: new Priority: normal | Milestone: _|_ Component: libraries/base | Version: 6.4.1 Resolution: | Keywords: Difficulty: Project (more than a week) | Os: Unknown/Multiple Testcase: N/A | Architecture: Unknown/Multiple Failure: Runtime performance bug | -----------------------------------------+---------------------------------- Comment (by simonmar): Replying to [comment:25 bos]: > There is indeed one `withForeignPtr` per FD. ISTR I'd been told that was effectively free, so I didn't worry about it. Clearly, we could use a plain Ptr instead and just free the pollfd data by hand when shutting down. You're right - `withForeignPtr` should be free, as long as the `ForeignPtr` is strict. Probably wouldn't hurt to glance at the Core and check it is being inlined away though. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 17 18:06:30 2009 From: trac at galois.com (GHC) Date: Thu Dec 17 17:40:25 2009 Subject: [GHC] #3758: Huge regression in concurrent app performance and reliability under threaded runtime In-Reply-To: <042.942d2a7fe8a29f75a39eae02838820a0@localhost> References: <042.942d2a7fe8a29f75a39eae02838820a0@localhost> Message-ID: <051.89b65ab664df5d5289619472345a0100@localhost> #3758: Huge regression in concurrent app performance and reliability under threaded runtime -----------------------------+---------------------------------------------- Reporter: bos | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.12.2 Component: Runtime System | Version: 6.12.1 Resolution: | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86_64 (amd64) Failure: Runtime crash | -----------------------------+---------------------------------------------- Comment (by simonmar): Thread 2 is the I/O manager, so you can see what it is up to in !ThreadScope. You can generate events from Haskell code using `GHC.Exts.traceEvent`, although they only show up in the "Events" tab in !ThreadScope currently, not in the timeline view. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 17 20:20:59 2009 From: trac at galois.com (GHC) Date: Thu Dec 17 19:55:23 2009 Subject: [GHC] #635: Replace use of select() in the I/O manager with epoll/kqueue/etc. In-Reply-To: <047.158ac52b7977b3e9f47680935a918275@localhost> References: <047.158ac52b7977b3e9f47680935a918275@localhost> Message-ID: <056.c4e1f1ec00a5df5aadff604c91c81159@localhost> #635: Replace use of select() in the I/O manager with epoll/kqueue/etc. -----------------------------------------+---------------------------------- Reporter: simonmar | Owner: bos Type: task | Status: new Priority: normal | Milestone: _|_ Component: libraries/base | Version: 6.4.1 Resolution: | Keywords: Difficulty: Project (more than a week) | Os: Unknown/Multiple Testcase: N/A | Architecture: Unknown/Multiple Failure: Runtime performance bug | -----------------------------------------+---------------------------------- Changes (by kazu-yamamoto): * cc: kazu@iij.ad.jp (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 17 21:45:19 2009 From: trac at galois.com (GHC) Date: Thu Dec 17 21:19:21 2009 Subject: [GHC] #3771: haddock: internal error: evacuate: strange closure type 19269 In-Reply-To: <045.5a5990fc01611a666ea323a5f0afc325@localhost> References: <045.5a5990fc01611a666ea323a5f0afc325@localhost> Message-ID: <054.8f7fc7c196218137a7946f7d26e35b9f@localhost> #3771: haddock: internal error: evacuate: strange closure type 19269 --------------------------+------------------------------------------------- Reporter: dbueno | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.12.1 Resolution: | Keywords: Os: MacOS X | Testcase: Architecture: powerpc64 | Failure: Building GHC failed --------------------------+------------------------------------------------- Comment (by dbueno): I don't use macports for ghc; I'm bootstrapping with 6.10.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 18 04:18:14 2009 From: trac at galois.com (GHC) Date: Fri Dec 18 03:52:08 2009 Subject: [GHC] #3501: Error thunks not being exposed with "B" strictness In-Reply-To: <046.49531cf39daa16853f84bad209d9cc5b@localhost> References: <046.49531cf39daa16853f84bad209d9cc5b@localhost> Message-ID: <055.0eb8294e1bf73fe3b9f65044614e4116@localhost> #3501: Error thunks not being exposed with "B" strictness --------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.14 branch Component: Compiler | Version: 6.11 Resolution: fixed | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Runtime performance bug | --------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: I believe this is fixed in the HEAD at least. See `Note [Bottoming floats]` in `SetLevels`. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 18 04:48:11 2009 From: trac at galois.com (GHC) Date: Fri Dec 18 04:22:07 2009 Subject: [GHC] #2110: Rules to eliminate casted id's In-Reply-To: <044.f3b76b9e96701f6ebb57092f8cedf6df@localhost> References: <044.f3b76b9e96701f6ebb57092f8cedf6df@localhost> Message-ID: <053.14bc530150bc9b03b93252d6941690c5@localhost> #2110: Rules to eliminate casted id's ------------------------------+--------------------------------------------- Reporter: igloo | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.2 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ------------------------------+--------------------------------------------- Changes (by simonpj): * cc: rl, dimitris@microsoft.com (added) * failure: => None/Unknown Comment: The issue here is how to write the rule in source syntax. The internal form is fine. Here's what it should look like in internal form, I think: {{{ RULE "map/cast" forall (a::*) (b::*) (c::*) (co :: (a->b ~ a->c)) (f::a->b) map a c (f |> co) = map a b f |> [right co] RULE "map/id" forall (a::*) map a a id = id }}} I've split the rule into two. One lifts out the cast, and one spots map- of-identity. I think (but I have not tested) that these rules will work, if only we could ''write'' them in the source program. We can write the second but not the first. This question is related to #2600, where we want to bind type variables in rules. Here we want to bind equality constraints too, and we might want to bind dictionaries too. How about this? {{{ RULE "map/cast" forall type a b c. (a~b) => forall (f :: a->b). map (f :: a->c) = map f :: [b] }}} Two things going on here: * I've used two `forall`s. The first has just the same syntax as a type- level `forall`, apart from the "`type`" keyword. It and binds type variables and constraints. The second is the one we have right now in RULES. Maybe we could omit the "`type`", but that might be hard to parse. * I've used type signatures to force the casts to appear in the "right" place. But this is a bit indirect. Better suggestions on syntax welcome. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 18 04:49:07 2009 From: trac at galois.com (GHC) Date: Fri Dec 18 04:23:03 2009 Subject: [GHC] #2600: Bind type variables in RULES In-Reply-To: <046.60d3c1925e5a0ef8b7d1f9b2b5ebeabc@localhost> References: <046.60d3c1925e5a0ef8b7d1f9b2b5ebeabc@localhost> Message-ID: <055.0889a072622a693476ccc2e9948d4856@localhost> #2600: Bind type variables in RULES ------------------------------+--------------------------------------------- Reporter: simonpj | Owner: simonpj Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.3 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ------------------------------+--------------------------------------------- Changes (by simonpj): * failure: => None/Unknown Comment: See also #2110 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 18 05:38:18 2009 From: trac at galois.com (GHC) Date: Fri Dec 18 05:12:12 2009 Subject: [GHC] #3480: Easily make Typeable keys pure, so that Typeable can be handled efficiently across communications In-Reply-To: <044.e3702794ded3f91904f114f506e31845@localhost> References: <044.e3702794ded3f91904f114f506e31845@localhost> Message-ID: <053.bb911813cb92c719ee39fa4b38919771@localhost> #3480: Easily make Typeable keys pure, so that Typeable can be handled efficiently across communications -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: task | Status: new Priority: normal | Milestone: 6.14.1 Component: libraries/base | Version: Resolution: | Keywords: Typeable, efficiency Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | -----------------------------+---------------------------------------------- Changes (by simonpj): * failure: => None/Unknown Comment: I talked to Simon M about the question of tidying up GHC's `TypeRep` mechanism. A good start would be the following: 1. Generate a fingerprint from the `String` (including the fully- versioned module) of the `TyCon` (eg "`base-4.3.2.2:GHC.Arr.Array`") 2. At each `App` node in the `TypeRep` generate a fingerprint from the fingerprints of the component pieces. We do this all the time when generating fingerprints in interface files. (This would retain constant- time comparison for `TypeRep`.) This would completely deal with the single-program case, because in any one program there is definitely only one type constructor `base-4.3.2.2:GHC.Arr.Array`. If we wanted a stronger, cross-program, story, then we'd need a stronger fingerprint under (1), based on the type structure as outlined in an earlier comment. That is quite doable too, but would probably require us to inject a binding for each `TyCon` fingerprint only ''after'' they'd been computed in `MkIface`. A bit more plumbing, that's all. This would be a straightforward project for someone to do. Since the fingerprinting for `TypeRep` must be done in `Data.Typeable`, which is in the `base` package, we'd need to add fingerprinting technology to `base`. Not hard, since GHC itself already has it, so we can just copy it over. But we don't want to make `base` depend on the `binary` package, so something a bit less general than GHC's fingerprinting interface is wanted. Any volunteers? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 18 05:44:59 2009 From: trac at galois.com (GHC) Date: Fri Dec 18 05:22:14 2009 Subject: [GHC] #650: Improve interaction between mutable arrays and GC In-Reply-To: <047.44b951cd4b5aa8536d862412c8d86597@localhost> References: <047.44b951cd4b5aa8536d862412c8d86597@localhost> Message-ID: <056.67bcb87f0451caddc8dbfbd701166269@localhost> #650: Improve interaction between mutable arrays and GC --------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: Runtime System | Version: 6.4.1 Resolution: | Keywords: Difficulty: Difficult (2-5 days) | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Runtime performance bug | --------------------------------------+------------------------------------- Changes (by simonmar): * milestone: 6.14.1 => 6.12.2 Comment: Fixed: {{{ Thu Dec 17 14:42:28 PST 2009 Simon Marlow * Fix #650: use a card table to mark dirty sections of mutable arrays The card table is an array of bytes, placed directly following the actual array data. This means that array reading is unaffected, but array writing needs to read the array size from the header in order to find the card table. We use a bytemap rather than a bitmap, because updating the card table must be multi-thread safe. Each byte refers to 128 entries of the array, but this is tunable by changing the constant MUT_ARR_PTRS_CARD_BITS in includes/Constants.h. M ./compiler/codeGen/CgPrimOp.hs -2 +14 M ./includes/Cmm.h +3 M ./includes/HaskellConstants.hs +3 M ./includes/mkDerivedConstants.c +1 M ./includes/rts/Constants.h +7 M ./includes/rts/storage/ClosureMacros.h -1 +29 M ./includes/rts/storage/Closures.h +2 M ./rts/PrimOps.cmm -5 +23 M ./rts/Weak.c -2 +9 M ./rts/sm/Scav.c -54 +123 }}} I benchmarked this program, amongst others: {{{ import Control.Monad import qualified Data.HashTable as H import System.Environment main = do [size] <- fmap (fmap read) getArgs m <- H.new (==) H.hashInt forM_ [1..size] $ \n -> H.insert m n n v <- H.lookup m 100 print v }}} for size=1000000, with 6.12.1 it takes around 50s on my x86/Linux laptop, with the HEAD and this patch it takes 9.5s. We could merge this into 6.12.2 after more testing and benchmarking, as the changes are fairly localised. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 18 05:58:48 2009 From: trac at galois.com (GHC) Date: Fri Dec 18 05:32:48 2009 Subject: [GHC] #3771: haddock: internal error: evacuate: strange closure type 19269 In-Reply-To: <045.5a5990fc01611a666ea323a5f0afc325@localhost> References: <045.5a5990fc01611a666ea323a5f0afc325@localhost> Message-ID: <054.3674cc70d777421d7c62318a540fd88b@localhost> #3771: haddock: internal error: evacuate: strange closure type 19269 ----------------------------------+----------------------------------------- Reporter: dbueno | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.12.1 Resolution: | Keywords: Difficulty: | Os: MacOS X Testcase: | Architecture: powerpc64 Failure: Building GHC failed | ----------------------------------+----------------------------------------- Changes (by simonmar): * difficulty: => * milestone: => 6.12 branch Comment: Just so you don't think we're ignoring you: the GHC developers don't have PPC hardware or expertise, so we rely on outside help to support PPC. At the moment we're lucky that it mostly works, although there are [query:?status=new&status=assigned&status=reopened&architecture=powerpc&order=priority a number of worrying tickets open]. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 18 08:49:05 2009 From: trac at galois.com (GHC) Date: Fri Dec 18 08:23:07 2009 Subject: [GHC] #3758: Huge regression in concurrent app performance and reliability under threaded runtime In-Reply-To: <042.942d2a7fe8a29f75a39eae02838820a0@localhost> References: <042.942d2a7fe8a29f75a39eae02838820a0@localhost> Message-ID: <051.2f59c311b0a4e549c7c566a8f809ca68@localhost> #3758: Huge regression in concurrent app performance and reliability under threaded runtime -----------------------------+---------------------------------------------- Reporter: bos | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.12.2 Component: Runtime System | Version: 6.12.1 Resolution: | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86_64 (amd64) Failure: Runtime crash | -----------------------------+---------------------------------------------- Changes (by simonmar): * cc: dons@galois.com (added) Comment: Some more on this: I'm still unable to reproduce any deadlocks, with either 6.12.1 or HEAD. It's not unheard of for there to be bugs in Linux threading, but I haven't seen any for a few years, and we're both running the same kernel (2.6.31). So it could be a race that is tickled on your hardware but not mine, I'll try on different hardware when I'm back in the office. I've cobbled together a patch that should make the parallel GC better behaved when only some of the cores are active: basically it doesn't bother waking up idle cores to do a parallel GC. This avoids most of the slowdown with -N2 here. I need to check that it doesn't hurt any of my other benchmarks before committing. Something else that helps a bit: `+RTS -qa` uses the Linux affinity API to fix threads to CPUs. I've noticed that if I go over 100 threads with `ab`, then a very few requests take >3s, but the rest are under 100ms. That is suspicious, and could indicate something strange in the scheduler. You can also win by doing this: {{{ forM_ [0..numCapabilities-1] $ \n -> forkOnIO n (listenLoop sock) }}} and then run with `+RTS -N2 -qm -qa`, to disable automatic migration and enable affinity. This basically assigns one server thread and its children to each core, and doesn't let them move around. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 18 10:00:25 2009 From: trac at galois.com (GHC) Date: Fri Dec 18 09:34:25 2009 Subject: [GHC] #3762: filepath.cabal has an extraneous apostrophe In-Reply-To: <048.0e334d3f10da19941e936444bdd1074c@localhost> References: <048.0e334d3f10da19941e936444bdd1074c@localhost> Message-ID: <057.5ccae00545bd2d42700354531caa5b08@localhost> #3762: filepath.cabal has an extraneous apostrophe --------------------------------+------------------------------------------- Reporter: ohnobinki | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.12.2 Component: libraries (other) | Version: Resolution: | Keywords: filepath Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Documentation bug | --------------------------------+------------------------------------------- Comment (by igloo): I don't know what a good reference would be for this sort of writing (as "normal" style guides tell you to do things like moving punctuation inside double quotes, which is bad for clarity when dealing with something rigid like programming). The Chicago Manual of Style has a couple of related things: 7.14 (on pluralising noun coinages) "To avoid an awkard appearance, an adjustment in spelling (or sometimes an apostrophe) may be needed", giving "maybe's" as an example. 7.16 "To avoid confusion, lower case letters and abbreviations with two or more interior periods or with both capital and lowercase letters form the plural with an apostrophe and an s", giving "M.A.'s and Ph.D's (or MAs and PhD's)" as examples. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 18 11:37:15 2009 From: trac at galois.com (GHC) Date: Fri Dec 18 11:11:14 2009 Subject: [GHC] #3771: haddock: internal error: evacuate: strange closure type 19269 In-Reply-To: <045.5a5990fc01611a666ea323a5f0afc325@localhost> References: <045.5a5990fc01611a666ea323a5f0afc325@localhost> Message-ID: <054.0cf9503432a825e0bd77bb18b2781de9@localhost> #3771: haddock: internal error: evacuate: strange closure type 19269 ----------------------------------+----------------------------------------- Reporter: dbueno | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.12.1 Resolution: | Keywords: Difficulty: | Os: MacOS X Testcase: | Architecture: powerpc64 Failure: Building GHC failed | ----------------------------------+----------------------------------------- Comment (by igloo): You should have more luck with an [wiki:Building/Unregisterised unregisterised] build, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 18 11:44:36 2009 From: trac at galois.com (GHC) Date: Fri Dec 18 11:18:29 2009 Subject: [GHC] #3757: panic: Kinds don't match in type application In-Reply-To: <056.3b3a9a6f534f222e1dcea97530deadf0@localhost> References: <056.3b3a9a6f534f222e1dcea97530deadf0@localhost> Message-ID: <065.f042d245fd5b0ff3b4be8a560571088c@localhost> #3757: panic: Kinds don't match in type application --------------------------------+------------------------------------------- Reporter: daniel.is.fischer | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.12.1 Resolution: fixed | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86 Failure: None/Unknown | --------------------------------+------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: This was fixed by {{{ Sun Nov 22 16:19:44 GMT 2009 Ian Lynagh * Tweak testsuite results for 6.12 branch }}} That link is to the 21 Nov build, which is why it also has the unexpected failure. I'm closing this ticket on the assumption that Daniel is using an old copy of the testsuite; please re-open if that's not the case. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 18 11:46:22 2009 From: trac at galois.com (GHC) Date: Fri Dec 18 11:20:16 2009 Subject: [GHC] #459: Bad parse error message In-Reply-To: <045.9adecc17314923c33323a1bd4204dfc1@localhost> References: <045.9adecc17314923c33323a1bd4204dfc1@localhost> Message-ID: <054.19507bcda935e6db6b213565a14bc611@localhost> #459: Bad parse error message --------------------------------+------------------------------------------- Reporter: nobody | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler (Parser) | Version: 6.4.1 Resolution: None | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Other | --------------------------------+------------------------------------------- Changes (by simonmar): * failure: => Other -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 18 11:52:09 2009 From: trac at galois.com (GHC) Date: Fri Dec 18 11:26:02 2009 Subject: [GHC] #481: Recompilation check fails for TH In-Reply-To: <046.9f65722c20d1ed8e256febe14e8bd5d1@localhost> References: <046.9f65722c20d1ed8e256febe14e8bd5d1@localhost> Message-ID: <055.ce8b926ff2e19e8f347dbaea89a180b8@localhost> #481: Recompilation check fails for TH ------------------------------------------+--------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: assigned Priority: low | Milestone: _|_ Component: Template Haskell | Version: 6.4.1 Resolution: None | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: TH_recompile | Architecture: Unknown/Multiple Failure: Incorrect result at runtime | ------------------------------------------+--------------------------------- Changes (by simonmar): * failure: => Incorrect result at runtime -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 18 11:54:04 2009 From: trac at galois.com (GHC) Date: Fri Dec 18 11:28:06 2009 Subject: [GHC] #485: AdjustorAsm.S doesn't build on AIX In-Reply-To: <047.348c1b9e6ebc7759d7861925cfd6ccd1@localhost> References: <047.348c1b9e6ebc7759d7861925cfd6ccd1@localhost> Message-ID: <056.7e392478bb28c1f1c071d48d2ae96851@localhost> #485: AdjustorAsm.S doesn't build on AIX ---------------------------+------------------------------------------------ Reporter: jgoerzen | Owner: Type: bug | Status: closed Priority: low | Milestone: _|_ Component: Compiler | Version: 6.4.1 Resolution: wontfix | Keywords: Difficulty: Unknown | Os: AIX Testcase: N/A | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by simonmar): * status: new => closed * failure: => None/Unknown * resolution: None => wontfix Comment: I don't think it's helpful to keep this bug open. `AdjustorAsm.S` doesn't exist any more, and we would probably use `libffi` if we were to port to this OS now. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 18 11:55:33 2009 From: trac at galois.com (GHC) Date: Fri Dec 18 11:29:27 2009 Subject: [GHC] #487: powerpc/linux segfaulting binaries In-Reply-To: <043.e4c96af6f7160fcdea6756f17c3ec89f@localhost> References: <043.e4c96af6f7160fcdea6756f17c3ec89f@localhost> Message-ID: <052.e56bb7ac3224ccad4076cafa745df338@localhost> #487: powerpc/linux segfaulting binaries ----------------------------+----------------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.4.1 Resolution: None | Keywords: Difficulty: Unknown | Os: Linux Testcase: N/A | Architecture: powerpc Failure: Runtime crash | ----------------------------+----------------------------------------------- Changes (by simonmar): * failure: => Runtime crash -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 18 12:10:53 2009 From: trac at galois.com (GHC) Date: Fri Dec 18 11:44:45 2009 Subject: [GHC] #3757: panic: Kinds don't match in type application In-Reply-To: <056.3b3a9a6f534f222e1dcea97530deadf0@localhost> References: <056.3b3a9a6f534f222e1dcea97530deadf0@localhost> Message-ID: <065.21c67df85104273a4ca3363ead60879c@localhost> #3757: panic: Kinds don't match in type application --------------------------------+------------------------------------------- Reporter: daniel.is.fischer | Owner: igloo Type: bug | Status: reopened Priority: normal | Milestone: Component: Compiler | Version: 6.12.1 Resolution: | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86 Failure: None/Unknown | --------------------------------+------------------------------------------- Changes (by daniel.is.fischer): * status: closed => reopened * resolution: fixed => Comment: I was using the testsuite-6.12.1.tar.bz2 linked from the GHC download page directly below the source distribution on Monday (14. Dec). If that was an old version and now the new testsuite is linked from there, re-close the ticket. The link was what google turned up searching for "match+selector+tyConKind" to avoid a duplicate ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 18 12:18:25 2009 From: trac at galois.com (GHC) Date: Fri Dec 18 11:52:18 2009 Subject: [GHC] #3757: panic: Kinds don't match in type application In-Reply-To: <056.3b3a9a6f534f222e1dcea97530deadf0@localhost> References: <056.3b3a9a6f534f222e1dcea97530deadf0@localhost> Message-ID: <065.2001e684a68f8df176eaa43a85519aa7@localhost> #3757: panic: Kinds don't match in type application --------------------------------+------------------------------------------- Reporter: daniel.is.fischer | Owner: igloo Type: bug | Status: reopened Priority: normal | Milestone: Component: Compiler | Version: 6.12.1 Resolution: | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86 Failure: None/Unknown | --------------------------------+------------------------------------------- Comment (by igloo): Hmm, that's odd. That definitely has {{{ test('CoTest3', if_compiler_lt('ghc', '6.13', expect_fail), compile, ['']) }}} in `testsuite/tests/ghc-regress/indexed-types/should_compile/all.T`. Just to check, `CoTest3` is listed in the "Unexpected failures" at the end of the testsuite output, and the test is running the right compiler, right? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 18 13:27:28 2009 From: trac at galois.com (GHC) Date: Fri Dec 18 13:01:22 2009 Subject: [GHC] #3757: panic: Kinds don't match in type application In-Reply-To: <056.3b3a9a6f534f222e1dcea97530deadf0@localhost> References: <056.3b3a9a6f534f222e1dcea97530deadf0@localhost> Message-ID: <065.fbf8a0d2ec062486645f99a039afe4d5@localhost> #3757: panic: Kinds don't match in type application --------------------------------+------------------------------------------- Reporter: daniel.is.fischer | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.12.1 Resolution: fixed | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86 Failure: None/Unknown | --------------------------------+------------------------------------------- Changes (by daniel.is.fischer): * status: reopened => closed * resolution: => fixed Comment: Ah, no, it wasn't listed as an unexpected failure. I was reacting to the "Please report this as a GHC bug" message. Sorry for the confusion. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 18 13:36:53 2009 From: trac at galois.com (GHC) Date: Fri Dec 18 13:12:05 2009 Subject: [GHC] #2253: Native code generator could do better In-Reply-To: <043.862f2d1bf55b0e0d2dddbf6af3659352@localhost> References: <043.862f2d1bf55b0e0d2dddbf6af3659352@localhost> Message-ID: <052.831ca5a53736d238390b8070292347da@localhost> #2253: Native code generator could do better --------------------------------------+------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler (NCG) | Version: 6.8.2 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Runtime performance bug | --------------------------------------+------------------------------------- Changes (by morrow): * cc: morrow@moonpatio.com (added) Comment: Replying to [comment:1 dons]: > == Program 6 == {{{ .. let c = replicateU n (2::Double) .. }}} > Native backend: {{{ .. mulsd .LnZP(%rip),%xmm0 /*.LnZP==2.0*/ addsd %xmm0,%xmm5 .. }}} > C backend: {{{ .. addsd %xmm0, %xmm0 addsd %xmm0, %xmm5 .. }}} Also, gcc is strength-reducing (2.0 * x) to (x + x). {{{ MULSD mem64,xmmreg ==> latency=6 ADDSD xmmreg2,xmmreg1 ==> latency=4 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 18 14:40:53 2009 From: trac at galois.com (GHC) Date: Fri Dec 18 14:14:45 2009 Subject: [GHC] #490: object code blow up by minor source code change In-Reply-To: <047.477f252553dcc2a1cf09c785d2044b2c@localhost> References: <047.477f252553dcc2a1cf09c785d2044b2c@localhost> Message-ID: <056.d3aa9c741c8ed580bca1b89a40b99027@localhost> #490: object code blow up by minor source code change ---------------------------+------------------------------------------------ Reporter: c_maeder | Owner: simonpj Type: bug | Status: closed Priority: low | Milestone: _|_ Component: Compiler | Version: 6.4.1 Resolution: fixed | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by simonmar): * status: new => closed * failure: => None/Unknown * resolution: None => fixed Comment: This bug no longer happens with 6.12.1: {{{ $ ghc --make HasCASL/hacapa.hs -O ... $ size HasCASL/hacapa text data bss dec hex filename 2231135 131492 12928 2375555 243f83 HasCASL/hacapa $ ll HasCASL/hacapa -rwxrwxr-x 1 simonmar simonmar 4051713 2009-12-18 19:34 HasCASL/hacapa* $ patch -p0 Common/Lib/Pretty.hs GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 18 15:39:09 2009 From: trac at galois.com (GHC) Date: Fri Dec 18 15:13:08 2009 Subject: [GHC] #3497: Template Haskell support for GADTs In-Reply-To: <046.5070e39940e96fda263647e7217ed34d@localhost> References: <046.5070e39940e96fda263647e7217ed34d@localhost> Message-ID: <055.bf0f1d8ea80e468ac60076f9174653f1@localhost> #3497: Template Haskell support for GADTs ------------------------------+--------------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.14 branch Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ------------------------------+--------------------------------------------- Changes (by TristanAllwood): * cc: tora@zonetora.co.uk (added) * failure: => None/Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 18 17:57:13 2009 From: trac at galois.com (GHC) Date: Fri Dec 18 17:31:12 2009 Subject: [GHC] #3771: haddock: internal error: evacuate: strange closure type 19269 In-Reply-To: <045.5a5990fc01611a666ea323a5f0afc325@localhost> References: <045.5a5990fc01611a666ea323a5f0afc325@localhost> Message-ID: <054.69a1bc6a0e67dfa4552a7b87c2a403ad@localhost> #3771: haddock: internal error: evacuate: strange closure type 19269 ----------------------------------+----------------------------------------- Reporter: dbueno | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.12.1 Resolution: | Keywords: Difficulty: | Os: MacOS X Testcase: | Architecture: powerpc64 Failure: Building GHC failed | ----------------------------------+----------------------------------------- Comment (by danrabin): For me, building unregisterised yields: ghc-stage1: could not execute: /Users/danrabin/Software/-ProgrammingLanguages/Haskell/GHC/ghc-6.12.1/inplace/lib /ghc-asm make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/Generics.o] Error 1 make: *** [all] Error 2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Dec 19 07:11:57 2009 From: trac at galois.com (GHC) Date: Sat Dec 19 06:45:50 2009 Subject: [GHC] #3664: Ghc eats tremendous heaps of RAM in -prof build (highlighting-kate) In-Reply-To: <045.0f6b0943402daeb82291512e1fe74507@localhost> References: <045.0f6b0943402daeb82291512e1fe74507@localhost> Message-ID: <054.e2eafe7127ee4218ee6b49db2e021c32@localhost> #3664: Ghc eats tremendous heaps of RAM in -prof build (highlighting-kate) -------------------------------------------+-------------------------------- Reporter: slyfox | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.12.1 RC1 Resolution: fixed | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86_64 (amd64) Failure: Compile-time performance bug | -------------------------------------------+-------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Dec 19 07:37:19 2009 From: trac at galois.com (GHC) Date: Sat Dec 19 07:11:09 2009 Subject: [GHC] #3770: getting docs out of windows distro In-Reply-To: <044.fa6a25b99b7d2e9e215f49ac6f3aab06@localhost> References: <044.fa6a25b99b7d2e9e215f49ac6f3aab06@localhost> Message-ID: <053.b725098a96be729d11c7be736ae8c19b@localhost> #3770: getting docs out of windows distro ------------------------------+--------------------------------------------- Reporter: denis | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: None | Version: 6.12.1 Resolution: | Keywords: ditribution Difficulty: | Os: Windows Testcase: | Architecture: Unknown/Multiple Failure: Other | ------------------------------+--------------------------------------------- Changes (by igloo): * difficulty: => Comment: I only see 106M in the doc directory (which uses 113M of disk space). The lib directory is 373M (378M); perhaps you looked at the wrong one? Anyway, I am inclined to not complicate the set of downloads unless there is lots of support for this. Any other opinions? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Dec 19 07:37:36 2009 From: trac at galois.com (GHC) Date: Sat Dec 19 07:11:25 2009 Subject: [GHC] #3770: getting docs out of windows distro In-Reply-To: <044.fa6a25b99b7d2e9e215f49ac6f3aab06@localhost> References: <044.fa6a25b99b7d2e9e215f49ac6f3aab06@localhost> Message-ID: <053.f02de44d4b064ca7157fc3b09cf6bc54@localhost> #3770: getting docs out of windows distro ------------------------------+--------------------------------------------- Reporter: denis | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12.2 Component: None | Version: 6.12.1 Resolution: | Keywords: distribution Difficulty: | Os: Windows Testcase: | Architecture: Unknown/Multiple Failure: Other | ------------------------------+--------------------------------------------- Changes (by igloo): * keywords: ditribution => distribution * milestone: => 6.12.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Dec 19 07:51:57 2009 From: trac at galois.com (GHC) Date: Sat Dec 19 07:25:47 2009 Subject: [GHC] #3770: getting docs out of windows distro In-Reply-To: <044.fa6a25b99b7d2e9e215f49ac6f3aab06@localhost> References: <044.fa6a25b99b7d2e9e215f49ac6f3aab06@localhost> Message-ID: <053.fd9c512675132bcc8f70b33afae8a48d@localhost> #3770: getting docs out of windows distro ------------------------------+--------------------------------------------- Reporter: denis | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12.2 Component: None | Version: 6.12.1 Resolution: | Keywords: distribution Difficulty: | Os: Windows Testcase: | Architecture: Unknown/Multiple Failure: Other | ------------------------------+--------------------------------------------- Comment (by guest): The releases are so far apart that download size is not an issue for me. Including the docs in one installer is helpful as I don't always have an Internet connection to view them online. +0 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Dec 19 11:17:34 2009 From: trac at galois.com (GHC) Date: Sat Dec 19 10:51:23 2009 Subject: [GHC] #3773: Haddoc documentation on wrong function argument Message-ID: <044.635ed03af9d418169b269fce9db0718f@localhost> #3773: Haddoc documentation on wrong function argument ---------------------------------+------------------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Component: Documentation Version: 6.10.4 | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ The catch function's documentation indicates that the first parameter is the exception handler when it in reality is the second. http://www.haskell.org/ghc/docs/latest/html/libraries/base-4.2.0.0 /Control-Exception.html#5 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Dec 19 12:13:14 2009 From: trac at galois.com (GHC) Date: Sat Dec 19 11:47:16 2009 Subject: [GHC] #3774: panic - caused by language pragma closed in first column Message-ID: <051.c14b42c862d0b09c579e21157ed7555b@localhost> #3774: panic - caused by language pragma closed in first column ---------------------------------+------------------------------------------ Reporter: andrewufrank | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Keywords: language pragma Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Compile-time crash ---------------------------------+------------------------------------------ if the language pragma is closed on a new line panic breaks out. adding two spaces before the #-} is sufficient to compile. used 6.10.4 on ubuntu 9.04 here the output and the program: frank@atlantaJ:~/leksahworkspace/spaceTimeDuality$ ghc panic.hs ghc: panic! (the 'impossible' happened) (GHC version 6.10.4 for i386-unknown-linux): getOptions'.parseLanguage(1) went past eof token Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug ---------- the program is: {-# LANGUAGE TypeSynonymInstances #-} module SpaceTimeDuality where main = do return () -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Dec 19 15:46:36 2009 From: trac at galois.com (GHC) Date: Sat Dec 19 15:20:37 2009 Subject: [GHC] #3774: panic - caused by language pragma closed in first column In-Reply-To: <051.c14b42c862d0b09c579e21157ed7555b@localhost> References: <051.c14b42c862d0b09c579e21157ed7555b@localhost> Message-ID: <060.f1f6042593805c2168fee79b2b338da8@localhost> #3774: panic - caused by language pragma closed in first column ---------------------------------+------------------------------------------ Reporter: andrewufrank | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: fixed | Keywords: language pragma Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Compile-time crash | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * difficulty: => * resolution: => fixed Comment: Thanks for the report. This is a duplicate of #3645. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Dec 19 17:11:22 2009 From: trac at galois.com (GHC) Date: Sat Dec 19 16:45:14 2009 Subject: [GHC] #3773: Haddoc documentation on wrong function argument In-Reply-To: <044.635ed03af9d418169b269fce9db0718f@localhost> References: <044.635ed03af9d418169b269fce9db0718f@localhost> Message-ID: <053.054672e24016afc210a4d3ee259034c8@localhost> #3773: Haddoc documentation on wrong function argument ---------------------------------+------------------------------------------ Reporter: tibbe | Owner: waern Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 6.10.4 Resolution: | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Changes (by waern): * owner: => waern Comment: Seems to be a Haddock bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Dec 19 17:24:33 2009 From: trac at galois.com (GHC) Date: Sat Dec 19 16:58:26 2009 Subject: [GHC] #3773: Haddoc documentation on wrong function argument In-Reply-To: <044.635ed03af9d418169b269fce9db0718f@localhost> References: <044.635ed03af9d418169b269fce9db0718f@localhost> Message-ID: <053.5ce03c73b028c38e3881624136d7aa76@localhost> #3773: Haddoc documentation on wrong function argument ---------------------------------+------------------------------------------ Reporter: tibbe | Owner: waern Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 6.10.4 Resolution: | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Comment (by isaacdupree): could the class-context, or the fact that the second argument is a function type, be a problem? no, look at the "finally" documentation in that module, and. Spurious "=>", as well as the first argument doc is missing and the second one is shifted one earlier. Sounds like an off-by-one somehow odd with another bug mixed in. look for bugs in Haddock.Backends.Html probably? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Dec 19 17:26:57 2009 From: trac at galois.com (GHC) Date: Sat Dec 19 17:00:46 2009 Subject: [GHC] #3775: Pattern matching on Word literals in GHCi crashes. Message-ID: <047.1c3778148e2d0e0d9a20a2e14d7a7517@localhost> #3775: Pattern matching on Word literals in GHCi crashes. -------------------------------+-------------------------------------------- Reporter: diatchki | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.10.4 | Keywords: Os: Linux | Testcase: Architecture: x86_64 (amd64) | Failure: GHCi crash -------------------------------+-------------------------------------------- GHCi 6.10.4 seems to be crashing with "impossible happened" when loading the program bellow. The problem seems to be related to pattern matching on Word literals, as it does not seem to happen if I change Word to Int. {{{ module Bug where import Data.Word(Word) bug :: Word -> Bool bug x = case x of 0 -> True _ -> False }}} Output: {{{ GHCi, version 6.10.4: 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 Bug ( Bug.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 6.10.4 for x86_64-unknown-linux): schemeE(AnnCase).my_discr __word 0 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -Iavor -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Dec 19 17:36:50 2009 From: trac at galois.com (GHC) Date: Sat Dec 19 17:10:42 2009 Subject: [GHC] #3773: Haddoc documentation on wrong function argument In-Reply-To: <044.635ed03af9d418169b269fce9db0718f@localhost> References: <044.635ed03af9d418169b269fce9db0718f@localhost> Message-ID: <053.c2ee080a6c565a607ffd1cec425402b6@localhost> #3773: Haddoc documentation on wrong function argument ---------------------------------+------------------------------------------ Reporter: tibbe | Owner: waern Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 6.10.4 Resolution: | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Comment (by isaacdupree): "bracket" also has the bug, so it's definitely not an "infix functions" problem -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Dec 20 15:41:20 2009 From: trac at galois.com (GHC) Date: Sun Dec 20 15:15:09 2009 Subject: [GHC] #3775: Pattern matching on Word literals in GHCi crashes. In-Reply-To: <047.1c3778148e2d0e0d9a20a2e14d7a7517@localhost> References: <047.1c3778148e2d0e0d9a20a2e14d7a7517@localhost> Message-ID: <056.b0993b9249ed62aeb80a57cf55c6fcc3@localhost> #3775: Pattern matching on Word literals in GHCi crashes. -------------------------+-------------------------------------------------- Reporter: diatchki | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.10.4 Resolution: duplicate | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86_64 (amd64) Failure: GHCi crash | -------------------------+-------------------------------------------------- Changes (by simonmar): * status: new => closed * difficulty: => * resolution: => duplicate Comment: Thanks for the report - previously reported as #2881 and fixed in 6.12.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Dec 20 16:25:47 2009 From: trac at galois.com (GHC) Date: Sun Dec 20 15:59:34 2009 Subject: [GHC] #3776: Warning: The import of `B.foo' from module `A' is redundant Message-ID: <045.524d47037f8ce3759915de36370eb1f3@localhost> #3776: Warning: The import of `B.foo' from module `A' is redundant ---------------------------------+------------------------------------------ Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.12.1 | Keywords: import, redundant, Wall Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Let's consider such '''A.hs''': {{{ module A (C(foo)) where class C a where foo :: a foo = bar bar :: a bar = foo }}} and '''B.hs''': {{{ module B (Foo(..)) where import qualified A as B (C(foo)) -- import qualified A as B (C) -- ? erros too data Foo = Foo Int deriving Show instance B.C Foo where foo = Foo 4 }}} Trying to build: {{{ $ ghc --make -Wall -Werror B [1 of 2] Compiling A ( A.hs, A.o ) [2 of 2] Compiling B ( B.hs, B.o ) B.hs:3:0: Warning: The import of `B.foo' from module `A' is redundant : Failing due to -Werror. }}} If I will remove foo somehow - I will get another error. At least message looks misleading, and warning seems to be false positive. Might be related ot #1074 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 21 00:43:49 2009 From: trac at galois.com (GHC) Date: Mon Dec 21 00:17:35 2009 Subject: [GHC] #3777: Split MonaIO class from mtl Message-ID: <052.0f80b9dfa9e67b3e80dc882bcdffe017@localhost> #3777: Split MonaIO class from mtl ---------------------------------+------------------------------------------ Reporter: AntoineLatter | Owner: Type: proposal | Status: new Priority: normal | Component: libraries (other) Version: 6.12.1 | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ I propose that the MonadIO class be split from the mtl package. The class would live in a new package, titled monad-io, in a new module titled Control.Monad.IO. This class would then be re-exported by Control.Monad.Trans. This would add a dependency on the new package to mtl. This would result in no change to the use or haddocks of mtl. A package implementing the new package half of this proposal may be found at http://community.haskell.org/~aslatter/code/mond-io Discussion deadline: 2 weeks (Dec 13 2010) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 21 04:39:27 2009 From: trac at galois.com (GHC) Date: Mon Dec 21 04:13:25 2009 Subject: [GHC] #3333: GHCi doesn't load weak symbols In-Reply-To: <047.f7df20b3080234226b9f5744151738a8@localhost> References: <047.f7df20b3080234226b9f5744151738a8@localhost> Message-ID: <056.2b433fb39d1531609776c40508c93b82@localhost> #3333: GHCi doesn't load weak symbols ---------------------------+------------------------------------------------ Reporter: heatsink | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: GHCi | Version: 6.10.4 Resolution: | Keywords: weak, dynamic loading Difficulty: Unknown | Os: Linux Testcase: | Architecture: x86 Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by hgolden): * cc: hgolden (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 21 06:00:14 2009 From: trac at galois.com (GHC) Date: Mon Dec 21 05:34:00 2009 Subject: [GHC] #3751: Panic! the 'impossible' happened: charType: '\167' In-Reply-To: <053.09139966f34278370b63f1b3d0e8a13b@localhost> References: <053.09139966f34278370b63f1b3d0e8a13b@localhost> Message-ID: <062.483e27190917dcc2aaf09f4136c92abe@localhost> #3751: Panic! the 'impossible' happened: charType: '\167' ---------------------------------+------------------------------------------ Reporter: moleculeColony | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.12.2 Component: Compiler (Parser) | Version: 6.10.4 Resolution: | Keywords: lexical error Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Compile-time crash | ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: Fixed: {{{ Thu Dec 17 13:26:58 GMT 2009 Simon Marlow * Fix #3751, also fix some lexical error SrcLocs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 21 06:03:09 2009 From: trac at galois.com (GHC) Date: Mon Dec 21 05:36:55 2009 Subject: [GHC] #3727: several Haiku platform defs In-Reply-To: <043.0c45c6547023fdad014a8678dc73ea96@localhost> References: <043.0c45c6547023fdad014a8678dc73ea96@localhost> Message-ID: <052.5922851bcef5909ce20b0e4da3fabd75@localhost> #3727: several Haiku platform defs ----------------------------------+----------------------------------------- Reporter: donn | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: | Os: Other Testcase: | Architecture: x86 Failure: Building GHC failed | ----------------------------------+----------------------------------------- Changes (by simonmar): * owner: => simonmar * difficulty: => -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 21 06:07:25 2009 From: trac at galois.com (GHC) Date: Mon Dec 21 05:41:12 2009 Subject: [GHC] #3728: configure should omit full path in unistd.h, stdlib.h return type tests In-Reply-To: <043.d33bce572e64777410efea0050887938@localhost> References: <043.d33bce572e64777410efea0050887938@localhost> Message-ID: <052.cd7dc5e9d8a53931517590e2f2bec6ff@localhost> #3728: configure should omit full path in unistd.h, stdlib.h return type tests ----------------------------------+----------------------------------------- Reporter: donn | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: | Os: Other Testcase: | Architecture: x86 Failure: Building GHC failed | ----------------------------------+----------------------------------------- Changes (by simonmar): * owner: => simonmar * difficulty: => -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 21 07:52:47 2009 From: trac at galois.com (GHC) Date: Mon Dec 21 07:27:41 2009 Subject: [GHC] #650: Improve interaction between mutable arrays and GC In-Reply-To: <047.44b951cd4b5aa8536d862412c8d86597@localhost> References: <047.44b951cd4b5aa8536d862412c8d86597@localhost> Message-ID: <056.898f2293447167ebc415b5e1139037b6@localhost> #650: Improve interaction between mutable arrays and GC --------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: Runtime System | Version: 6.4.1 Resolution: | Keywords: Difficulty: Difficult (2-5 days) | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Runtime performance bug | --------------------------------------+------------------------------------- Comment (by simonmar): NB. this patch is needed too {{{ Mon Dec 21 11:52:49 GMT 2009 Simon Marlow * Fixes to account for the new layout of MUT_ARR_PTRS (see #650) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 21 09:03:45 2009 From: trac at galois.com (GHC) Date: Mon Dec 21 08:37:29 2009 Subject: [GHC] #3776: Warning: The import of `B.foo' from module `A' is redundant In-Reply-To: <045.524d47037f8ce3759915de36370eb1f3@localhost> References: <045.524d47037f8ce3759915de36370eb1f3@localhost> Message-ID: <054.20cd5adb8ca8a5fba433ba1269f360a1@localhost> #3776: Warning: The import of `B.foo' from module `A' is redundant ---------------------------+------------------------------------------------ Reporter: slyfox | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.12.1 Resolution: | Keywords: import, redundant, Wall Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by simonpj): * owner: => simonpj * difficulty: => Comment: Good point, thank you. Am fixing. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 21 11:07:17 2009 From: trac at galois.com (GHC) Date: Mon Dec 21 10:41:07 2009 Subject: [GHC] #2715: Equality constraint in superclass not supported In-Reply-To: <047.797aaec011bad118fea0580e1c0ce283@localhost> References: <047.797aaec011bad118fea0580e1c0ce283@localhost> Message-ID: <056.7c28817a62c77301486143a97b37ce9d@localhost> #2715: Equality constraint in superclass not supported --------------------------------------+------------------------------------- Reporter: rodprice | Owner: chak Type: task | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler (Type checker) | Version: 6.10.1 Resolution: | Keywords: Difficulty: Unknown | Os: Linux Testcase: | Architecture: x86 Failure: None/Unknown | --------------------------------------+------------------------------------- Changes (by Andrey.Sisoyev): * cc: sisoyev.andrey@yandex.ru (added) * failure: => None/Unknown * type: bug => task Comment: Didn't notice it in release info (for GHC 6.12.1). How is the progress? =) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 21 11:11:14 2009 From: trac at galois.com (GHC) Date: Mon Dec 21 10:44:59 2009 Subject: [GHC] #3776: Warning: The import of `B.foo' from module `A' is redundant In-Reply-To: <045.524d47037f8ce3759915de36370eb1f3@localhost> References: <045.524d47037f8ce3759915de36370eb1f3@localhost> Message-ID: <054.31689217e8fb97c2e777987e36e6b39c@localhost> #3776: Warning: The import of `B.foo' from module `A' is redundant ---------------------------+------------------------------------------------ Reporter: slyfox | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.12.1 Resolution: fixed | Keywords: import, redundant, Wall Difficulty: | Os: Unknown/Multiple Testcase: module/T3776 | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by simonpj): * testcase: => module/T3776 * status: new => closed * resolution: => fixed Comment: Fixed by {{{ Mon Dec 21 15:55:09 GMT 2009 simonpj@microsoft.com * Fix Trac #3776 An easy fix. See Note [Usage for sub-bndrs] in RnEnv. M ./compiler/rename/RnEnv.lhs -2 +24 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 21 11:24:30 2009 From: trac at galois.com (GHC) Date: Mon Dec 21 10:58:16 2009 Subject: [GHC] #3245: Quadratic slowdown in Data.Typeable In-Reply-To: <044.8f6ad688a6e54aadf1867244399f152a@localhost> References: <044.8f6ad688a6e54aadf1867244399f152a@localhost> Message-ID: <053.c818d593b9cac664fcb6e7dda8631d0a@localhost> #3245: Quadratic slowdown in Data.Typeable --------------------------------------+------------------------------------- Reporter: guest | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.12 branch Component: libraries (other) | Version: 6.10.1 Resolution: | Keywords: Difficulty: Unknown | Os: Linux Testcase: perf/should_run/T3245 | Architecture: x86 Failure: Runtime performance bug | --------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => perf/should_run/T3245 * owner: => igloo * type: bug => merge Comment: Excellent point. Fixed by {{{ Fri Dec 18 15:51:17 GMT 2009 simonpj@microsoft.com * Fix Trac #3245: memoising typeOf The performance bug in #3245 was caused by computing the typeRep once for each call of typeOf, rather than once for each dictionary contruction. (Computing TypeReps is reasonably expensive, because of the hash-consing machinery.) This is readily fixed by putting the TypeRep construction outside the lambda. (Arguably GHC might have worked that out itself, but it involves floating something between a type lambda and a value lambda, which GHC doesn't currently do. If it happens a lot we could fix that.) M ./Data/Typeable.hs -29 +52 }}} See `Note [Memoising typeOf]` in `Typeable.hs` which explains a bit more. I added a regression test too. I suppose we could merge this to the 6.12 branch, for the next patch release. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 21 12:31:16 2009 From: trac at galois.com (GHC) Date: Mon Dec 21 12:05:01 2009 Subject: [GHC] #3778: "test -e" in testsuite doesn't work with Solaris /bin/sh Message-ID: <045.ba6d721ea8ef7ec8850eec9a0e707e83@localhost> #3778: "test -e" in testsuite doesn't work with Solaris /bin/sh ---------------------------+------------------------------------------------ Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Test Suite | Version: 6.12.1 Keywords: | Difficulty: Easy (less than 1 hour) Os: Solaris | Testcase: Architecture: sparc | Failure: Other ---------------------------+------------------------------------------------ The `testsuite/mk/boilerplate.mk` contains stuff like: {{{ $(eval $(call canonicaliseExecutable,TEST_HC)) ifeq "$(shell test -e '$(TEST_HC)' && echo exists)" "" $(error Cannot find ghc: $(TEST_HC)) endif }}} On Solaris, the `/bin/sh` test builtin does not support the `-e` flag. It does support both `-f` and `-x`, meaning regular and executable file respectively. I think we probably mean `-x` in this case anyway. With that fix the testsuite seems to run ok. Looks like we already use `test -x` elsewhere in `testsuite/mk/boilerplate.mk` so we can assume that it does work with the shell of other platforms. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 22 02:37:50 2009 From: trac at galois.com (GHC) Date: Tue Dec 22 02:11:32 2009 Subject: [GHC] #3779: dodgey warning about redundant class method imports Message-ID: <045.ea992c93dda6711043c8cc42ea2ccf8c@localhost> #3779: dodgey warning about redundant class method imports ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.12.1 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Incorrect warning at compile-time ---------------------------------+------------------------------------------ Consider the code: {{{ import qualified Distribution.Text as Text ( Text(disp, parse) ) instance Text.Text ReportLevel where disp = ... parse = ... }}} (This is from `Distribution/Client/BuildReports/Types.hs` in cabal- install-0.8.0) GHC warns us that: {{{ Distribution/Client/BuildReports/Types.hs:17:0: Warning: The import of `Text.disp, Text.parse' from module `Distribution.Text' is redundant }}} But is it really redundant? If we change the import to: {{{ import qualified Distribution.Text as Text ( Text ) }}} Then the compile fails because `disp` and `parse` are not visible members of the `Text` class. Actually it's a bit odd that they become visible when imported qualified when the instance decl itself must use non-qualified class method names. But I guess that's just a quirk of H98. One can get no warning by switching to: {{{ import qualified Distribution.Text as Text ( Text(..) ) }}} But that's not very satisfying. I did want to say which class methods I'm using. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 22 03:36:42 2009 From: trac at galois.com (GHC) Date: Tue Dec 22 03:10:25 2009 Subject: [GHC] #3776: Warning: The import of `B.foo' from module `A' is redundant In-Reply-To: <045.524d47037f8ce3759915de36370eb1f3@localhost> References: <045.524d47037f8ce3759915de36370eb1f3@localhost> Message-ID: <054.7a23de40cfff08bb63e1a2d391b43e62@localhost> #3776: Warning: The import of `B.foo' from module `A' is redundant ---------------------------+------------------------------------------------ Reporter: slyfox | Owner: simonpj Type: merge | Status: reopened Priority: normal | Milestone: Component: Compiler | Version: 6.12.1 Resolution: | Keywords: import, redundant, Wall Difficulty: | Os: Unknown/Multiple Testcase: module/T3776 | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by simonpj): * status: closed => reopened * type: bug => merge * resolution: fixed => Comment: I think this could merge to the 6.12.2 release Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 22 03:37:04 2009 From: trac at galois.com (GHC) Date: Tue Dec 22 03:10:45 2009 Subject: [GHC] #3776: Warning: The import of `B.foo' from module `A' is redundant In-Reply-To: <045.524d47037f8ce3759915de36370eb1f3@localhost> References: <045.524d47037f8ce3759915de36370eb1f3@localhost> Message-ID: <054.e9f38c51d26175059fc1cdf9cf0ee8d0@localhost> #3776: Warning: The import of `B.foo' from module `A' is redundant ---------------------------+------------------------------------------------ Reporter: slyfox | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.12.2 Component: Compiler | Version: 6.12.1 Resolution: | Keywords: import, redundant, Wall Difficulty: | Os: Unknown/Multiple Testcase: module/T3776 | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by simonpj): * status: reopened => new * owner: simonpj => igloo * milestone: => 6.12.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 22 03:38:21 2009 From: trac at galois.com (GHC) Date: Tue Dec 22 03:12:02 2009 Subject: [GHC] #3779: dodgey warning about redundant class method imports In-Reply-To: <045.ea992c93dda6711043c8cc42ea2ccf8c@localhost> References: <045.ea992c93dda6711043c8cc42ea2ccf8c@localhost> Message-ID: <054.0a4d7333d8766e22cef00480fd6928bd@localhost> #3779: dodgey warning about redundant class method imports ------------------------------------------------+--------------------------- Reporter: duncan | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.12.1 Resolution: duplicate | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Incorrect warning at compile-time | ------------------------------------------------+--------------------------- Changes (by simonpj): * status: new => closed * resolution: => duplicate Comment: Quite right, thanks. As luck would have it, I fixed this yesterday: #3776. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 22 06:12:17 2009 From: trac at galois.com (GHC) Date: Tue Dec 22 05:46:00 2009 Subject: [GHC] #3780: unix-2.4.0.0 fails with base 4.1 Message-ID: <045.da767e73d04d85283e231ed41de5ef94@localhost> #3780: unix-2.4.0.0 fails with base 4.1 ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/unix | Version: 6.12.1 Keywords: | Difficulty: Easy (less than 1 hour) Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Other ---------------------------------+------------------------------------------ The unix package states: {{{ build-depends: base >=4.1 && <4.3 }}} And while it does compile with base 4.1, using ghc-6.10, nothing can successfully link against it. The symptoms are: {{{ /usr/lib64/ghc-6.10.4/base-4.1.0.0/libHSbase-4.1.0.0.a(PrelIOUtils.o): In function `__hscore_d_name': (.text+0x1c0): multiple definition of `__hscore_d_name' /home/duncan/.cabal/lib/unix-2.4.0.0/ghc-6.10.4/libHSunix-2.4.0.0.a(dirUtils.o):dirUtils.c:(.text+0x0): first defined here /usr/lib64/ghc-6.10.4/base-4.1.0.0/libHSbase-4.1.0.0.a(PrelIOUtils.o): In function `__hscore_free_dirent': (.text+0x4f0): multiple definition of `__hscore_free_dirent' /home/duncan/.cabal/lib/unix-2.4.0.0/ghc-6.10.4/libHSunix-2.4.0.0.a(dirUtils.o):dirUtils.c:(.text+0x10): first defined here /home/duncan/.cabal/lib/unix-2.4.0.0/ghc-6.10.4/libHSunix-2.4.0.0.a(IO.o): In function `sk63_info': (.text+0x30c4): undefined reference to `fcntl_read' /home/duncan/.cabal/lib/unix-2.4.0.0/ghc-6.10.4/libHSunix-2.4.0.0.a(IO.o): In function `sk6A_info': (.text+0x31f0): undefined reference to `fcntl_write' /home/duncan/.cabal/lib/unix-2.4.0.0/ghc-6.10.4/libHSunix-2.4.0.0.a(IO.o): In function `sk8h_info': (.text+0x36cc): undefined reference to `fcntl_read' /home/duncan/.cabal/lib/unix-2.4.0.0/ghc-6.10.4/libHSunix-2.4.0.0.a(IO.o): In function `sl4O_info': (.text+0x3a52): undefined reference to `fcntl_lock' /home/duncan/.cabal/lib/unix-2.4.0.0/ghc-6.10.4/libHSunix-2.4.0.0.a(IO.o): In function `sl6S_info': (.text+0x3cc2): undefined reference to `fcntl_lock' /home/duncan/.cabal/lib/unix-2.4.0.0/ghc-6.10.4/libHSunix-2.4.0.0.a(IO.o): In function `sl9I_info': (.text+0x402a): undefined reference to `fcntl_lock' }}} There are two problems here, the duplicate `__hscore_*` symbols and and the missing `fcntl_*` symbols. The `__hscore_d_name` C function really is duplicated. There is one copy in `base/include/HsBase.h` in ghc-6.10, there is another copy in `cbits/dirUtils.c` in unix-2.4.0.0. Clearly what has happened is that the function from base has been moved into the unix package. However that means when building the unix package with the older base then we get both. The solution is to rename the one in the unix package. Ideally we could limit the visibility of symbols somehow. The `fcntl_read` are not defined in the unix package. They are defined in `HsBase.h` in ghc-6.12 but not in 6.10. Hence they are also missing when unix-2.4.0.0 is built against the older base. The solution is to define them locally. Originally filed as Cabal ticket: http://hackage.haskell.org/trac/hackage/ticket/620 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 22 07:29:27 2009 From: trac at galois.com (GHC) Date: Tue Dec 22 07:03:11 2009 Subject: [GHC] #3629: Code compiled WITHOUT profiling many times slower than compiled WITH profiling on In-Reply-To: <048.82a42937ecf77e5d0d0af3b5fdd87592@localhost> References: <048.82a42937ecf77e5d0d0af3b5fdd87592@localhost> Message-ID: <057.36900d2dd88c8ae068b3ff4266964f66@localhost> #3629: Code compiled WITHOUT profiling many times slower than compiled WITH profiling on ---------------------------+------------------------------------------------ Reporter: gchrupala | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.13 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by aruiz): * cc: aruiz (added) * failure: => None/Unknown Comment: I have a similar problem using foreign calls (in the hmatrix library). A program is 10x slower without profiling (and in ghci) than compiled with profiling on. This happens in ghc-6.12.1 (ghc-6.12.1-i386-unknown-linux-n.tar.bz2 on Ubuntu ), but not in ghc-6.10. I include a small test case. We need: $ sudo apt-get install libgsl0-dev liblapack-dev $ cabal install hmatrix -p $ cat slow.hs {{{ import Numeric.LinearAlgebra m = ident 2000 :: Matrix Double main = print $ vectorMax (takeDiag (m <> m)) }}} With ghc-6.12.1 {{{ $ ghc -V The Glorious Glasgow Haskell Compilation System, version 6.12.1 $ ghc --make slow.hs -fforce-recomp [1 of 1] Compiling Main ( slow.hs, slow.o ) Linking slow ... $ time ./slow 1.0 real 1m15.790s user 1m15.489s sys 0m0.228s $ ghc --make slow.hs -prof -fforce-recomp [1 of 1] Compiling Main ( slow.hs, slow.o ) Linking slow ... $ time ./slow 1.0 real 0m7.366s user 0m7.264s sys 0m0.100s }}} With ghc-6.10.3 {{{ $ ghc -V The Glorious Glasgow Haskell Compilation System, version 6.10.3 $ ghc --make slow.hs -fforce-recomp [1 of 1] Compiling Main ( slow.hs, slow.o ) Linking slow ... $ time ./slow 1.0 real 0m7.142s user 0m7.060s sys 0m0.072s $ ghc --make slow.hs -prof -fforce-recomp [1 of 1] Compiling Main ( slow.hs, slow.o ) Linking slow ... $ time ./slow 1.0 real 0m7.242s user 0m7.132s sys 0m0.096s }}} Thanks, Alberto Ruiz -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 22 09:50:01 2009 From: trac at galois.com (GHC) Date: Tue Dec 22 09:23:52 2009 Subject: [GHC] #3184: package.conf should be under /var, not /usr In-Reply-To: <044.f476a4a28c9761f9c30b392c86475e98@localhost> References: <044.f476a4a28c9761f9c30b392c86475e98@localhost> Message-ID: <053.36121ce94a8a16ff9220c7adb75c1dfe@localhost> #3184: package.conf should be under /var, not /usr -----------------------------+---------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: Package system | Version: 6.10.2 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | -----------------------------+---------------------------------------------- Comment (by duncan): See also http://hackage.haskell.org/trac/hackage/ticket/543 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 22 10:25:17 2009 From: trac at galois.com (GHC) Date: Tue Dec 22 09:59:12 2009 Subject: [GHC] #3716: building ghc-6.12.0.20091121 ends with internal Haddock or GHC error In-Reply-To: <045.e5c85a6d9c01c90f88c47b3f6ae70039@localhost> References: <045.e5c85a6d9c01c90f88c47b3f6ae70039@localhost> Message-ID: <054.9e51c16c4a8629ca29161bef1321bca5@localhost> #3716: building ghc-6.12.0.20091121 ends with internal Haddock or GHC error -----------------------------+---------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.12.1 Resolution: | Keywords: Os: Solaris | Testcase: Architecture: x86 | Failure: Building GHC failed -----------------------------+---------------------------------------------- Changes (by maeder): * version: 6.12.1 RC1 => 6.12.1 Comment: This is still a problem with ghc-6.12.1. It goes through if I replace `sed` with `gsed` in the file `libraries/gen_contents_index`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 22 15:14:35 2009 From: trac at galois.com (GHC) Date: Tue Dec 22 14:48:15 2009 Subject: [GHC] #3731: SYB gone wild - mysterious <> in code derived from an syb-with-class example In-Reply-To: <042.4958fc1cdd70e26a14593e01de97e65e@localhost> References: <042.4958fc1cdd70e26a14593e01de97e65e@localhost> Message-ID: <051.0bc7048fbed7a65a6d32c1397c693f1d@localhost> #3731: SYB gone wild - mysterious <> in code derived from an syb-with-class example ---------------------------------+------------------------------------------ Reporter: dsf | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.12.1 Resolution: | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Incorrect result at runtime ---------------------------------+------------------------------------------ Comment (by JeremyShaw): I compiled with: {{{ghc -S Bug.hs -ddump-simpl -dsuppress-uniques -dcore-lint}}} And I get this: {{{ Main.e :: Main.Expression [GlobalId] [] Main.e = case $dSat `cast` ((Main.:Co:TSat) (Main.DefaultD Main.Expression) :: (Main.:TSat) (Main.DefaultD Main.Expression) ~ Main.DefaultD Main.Expression) of tpl { Main.DefaultD ipv -> ipv } Rec { $dSat :: Main.Sat (Main.DefaultD Main.Expression) [GlobalId] [] $dSat = $dSat end Rec } }}} It seems clear that the loop is caused by: {{{$dSat = $dSat}}} The question is whether the simplifier is causing the bug, or if the bug already exists after desugaring/type checking, and the simplifier is doing the right thing. I also tried dumping the output after {{{-ddump-ds}}}. But I have not studied it enough to figure out if it is doing the right thing or not. This bug has popped up several different ways in our code base. :( Is there something we can do to get it looked at by someone who might understand what is going on? thanks! - jeremy -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 22 20:35:22 2009 From: trac at galois.com (GHC) Date: Tue Dec 22 20:09:13 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.9579cdfb09de044a54f6d544329f2bc5@localhost> #2395: "Pattern match(es) are overlapped" warning with a single view pattern (ghc 6.9.20080606) -------------------------------------------+-------------------------------- Reporter: rwbarton | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.9 Resolution: fixed | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: deSugar/should_compile/T2395 | Architecture: Unknown/Multiple Failure: None/Unknown | -------------------------------------------+-------------------------------- Changes (by guest): * cc: kfrdbs@gmail.com (added) * failure: => None/Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 22 20:36:17 2009 From: trac at galois.com (GHC) Date: Tue Dec 22 20:10:34 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.e5f9161013e12ccdd2d86032e9f1837e@localhost> #2395: "Pattern match(es) are overlapped" warning with a single view pattern (ghc 6.9.20080606) ------------------------------------------------+--------------------------- Reporter: rwbarton | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.9 Resolution: fixed | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: deSugar/should_compile/T2395 | Architecture: Unknown/Multiple Failure: Incorrect warning at compile-time | ------------------------------------------------+--------------------------- Changes (by guest): * failure: None/Unknown => Incorrect warning at compile-time -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 22 22:09:37 2009 From: trac at galois.com (GHC) Date: Tue Dec 22 21:43:31 2009 Subject: [GHC] #3654: Mach-O GHCi linker lacks support for a range of relocation entries In-Reply-To: <043.db5a4c9ebf484eb57b87a6d38bef8362@localhost> References: <043.db5a4c9ebf484eb57b87a6d38bef8362@localhost> Message-ID: <052.5d5e0d5b941d135d38b845094e5725a2@localhost> #3654: Mach-O GHCi linker lacks support for a range of relocation entries -----------------------------+---------------------------------------------- Reporter: chak | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Runtime System | Version: 6.13 Resolution: | Keywords: Difficulty: Unknown | Os: MacOS X Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | -----------------------------+---------------------------------------------- Changes (by hgolden): * cc: hgolden (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 23 03:12:57 2009 From: trac at galois.com (GHC) Date: Wed Dec 23 02:46:38 2009 Subject: [GHC] #3731: SYB gone wild - mysterious <> in code derived from an syb-with-class example In-Reply-To: <042.4958fc1cdd70e26a14593e01de97e65e@localhost> References: <042.4958fc1cdd70e26a14593e01de97e65e@localhost> Message-ID: <051.da98495fffcfd6b9e5cb99d11695f78a@localhost> #3731: SYB gone wild - mysterious <> in code derived from an syb-with-class example ------------------------------------------+--------------------------------- Reporter: dsf | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.12.1 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Incorrect result at runtime | ------------------------------------------+--------------------------------- Changes (by simonpj): * difficulty: => Comment: I looked into this again. I know (or at least I think I know) what the problem is. It turns out to be a bug in the guts of the solver (which wasn't originally intended to solve these recursive constraint sets). I believe it works ok in the HEAD, although I am far from confident that the bug is thoroughly squashed even there. I'm not keen on burning cycles to fix this, because I'm in the midst of re-engineering the entire solving apparatus. However, it's bad if you are stuck. As a workaround, can you use the HEAD? (Snapshot builds should be available.) Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 23 04:59:39 2009 From: trac at galois.com (GHC) Date: Wed Dec 23 04:33:17 2009 Subject: [GHC] #3781: Improve inlining for local functions Message-ID: <046.7e7e45262f788675411974bac0244395@localhost> #3781: Improve inlining for local functions ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.12.1 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Runtime performance bug ---------------------------------+------------------------------------------ I found that `boyer2/Rewritefuns.onewayunify1` has a join point that really should be inlined. It should get a big discount from scrutinizing free variables. But the inlining mechanism only take account of arguments, not free variables. There's a small optimisation opportunity here, which this ticket records. Here's the code: {{{ Rewritefns.onewayunify1 = \ (t1_acm :: Lisplikefns.Lisplist) (t2_acn :: Lisplikefns.Lisplist) (u_aco :: Lisplikefns.Lisplist) -> case t2_acn of wild_ao1 { __DEFAULT -> case t1_acm of wild_Xok { __DEFAULT -> let { $j_spS :: GHC.Prim.State# GHC.Prim.RealWorld -> (GHC.Bool.Bool, Lisplikefns.Lisplist) [LclId, Arity=1, Unf=Unf{Src=, TopLvl=False, Arity=1, Value=True, ConLike=True, Cheap=True, Expandable=True, Guidance=IF_ARGS [0] 10 0}] $j_spS = \ _ -> Rewritefns.onewayunify1lst (case wild_Xok of _ { Lisplikefns.Nil -> Lisplikefns.Nil; Lisplikefns.Cons ds1_anT -> case ds1_anT of _ { (_, y_anY) -> y_anY } }) (case wild_ao1 of _ { Lisplikefns.Nil -> Lisplikefns.Nil; Lisplikefns.Cons ds1_anT -> case ds1_anT of _ { (_, y_anY) -> y_anY } }) u_aco } in case wild_Xok of _ { Lisplikefns.Nil -> case wild_ao1 of _ { Lisplikefns.Nil -> case Lisplikefns.$fEqLisplist_$c== Lisplikefns.Nil Lisplikefns.Nil of _ { GHC.Bool.False -> (GHC.Bool.False, u_aco); GHC.Bool.True -> $j_spS GHC.Prim.realWorld# }; Lisplikefns.Cons ds1_anJ -> case ds1_anJ of _ { (x_anN, _) -> case Lisplikefns.$fEqLisplist_$c== Lisplikefns.Nil x_anN of _ { GHC.Bool.False -> (GHC.Bool.False, u_aco); GHC.Bool.True -> $j_spS GHC.Prim.realWorld# } } }; Lisplikefns.Cons ds1_anJ -> case ds1_anJ of _ { (x_anN, _) -> case wild_ao1 of _ { Lisplikefns.Nil -> case Lisplikefns.$fEqLisplist_$c== x_anN Lisplikefns.Nil of _ { GHC.Bool.False -> (GHC.Bool.False, u_aco); GHC.Bool.True -> $j_spS GHC.Prim.realWorld# }; Lisplikefns.Cons ds1_Xof -> case ds1_Xof of _ { (x_Xom, _) -> case Lisplikefns.$fEqLisplist_$c== x_anN x_Xom of _ { GHC.Bool.False -> (GHC.Bool.False, u_aco); GHC.Bool.True -> $j_spS GHC.Prim.realWorld# } } } } }; Lisplikefns.Atom x_ao3 -> (GHC.Bool.False, u_aco) }; }}} You can see that `$j_sps` scrutinises `wild_Xok` and `wild_ao1`, but it currently gets no discount for doing so. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 23 07:50:33 2009 From: trac at galois.com (GHC) Date: Wed Dec 23 07:24:31 2009 Subject: [GHC] #3771: haddock: internal error: evacuate: strange closure type 19269 In-Reply-To: <045.5a5990fc01611a666ea323a5f0afc325@localhost> References: <045.5a5990fc01611a666ea323a5f0afc325@localhost> Message-ID: <054.be96bd9a8e006343d03282eed06ed972@localhost> #3771: haddock: internal error: evacuate: strange closure type 19269 ----------------------------------+----------------------------------------- Reporter: dbueno | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.12.1 Resolution: | Keywords: Difficulty: | Os: MacOS X Testcase: | Architecture: powerpc Failure: Building GHC failed | ----------------------------------+----------------------------------------- Changes (by maeder): * architecture: powerpc64 => powerpc Comment: I get the same error on Power Mac G5 (32bit powerpc) {{{ Kernel Version 9.8.0: Wed Jul 15 16:57:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_PPC Power Macintosh }}} {{{ "inplace/bin/ghc-cabal" haddock dist-install libraries/base --with- haddock=/Users/Shared/maeder/haskell/ghc-6.12.1/inplace/bin/haddock --with-ghc=/Users/Shared/maeder/haskell/ghc-6.12.1/inplace/bin/ghc-stage2 Running Haddock for base-4.2.0.0... Preprocessing library base-4.2.0.0... Warning: The documentation for the following packages are not installed. No links will be generated to these packages: ffi-1.0, rts-1.0 GHC/IO/Handle/Internals.hs:1:15: Warning: -#include is deprecated: No longer has any effect GHC/IO/Handle/Text.hs:1:15: Warning: -#include is deprecated: No longer has any effect GHC/Unicode.hs:2:11: Warning: -#include is deprecated: No longer has any effect Foreign/C/Error.hs:1:15: Warning: -#include is deprecated: No longer has any effect haddock: internal error: evacuate: strange closure type 19269 (GHC version 6.12.1 for powerpc_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[1]: *** [libraries/base/dist-install/doc/html/base/base.haddock] Error 6 make: *** [all] Error 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 23 15:56:41 2009 From: trac at galois.com (GHC) Date: Wed Dec 23 15:30:21 2009 Subject: [GHC] #3687: Merge _stub.o files back in to the .o file In-Reply-To: <051.5329623a4eddfae039053b6416bd32a2@localhost> References: <051.5329623a4eddfae039053b6416bd32a2@localhost> Message-ID: <060.841b28dedfde208c975eecda10fa2152@localhost> #3687: Merge _stub.o files back in to the .o file ------------------------------+--------------------------------------------- Reporter: NeilMitchell | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ------------------------------+--------------------------------------------- Comment (by NeilMitchell): I tracked down the bug. If you pass the same -osuf/-hisuf to GHCi as you do to when compiling the files then it works, so I guess this is a bug in the way I was invoking GHCi. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 23 16:02:35 2009 From: trac at galois.com (GHC) Date: Wed Dec 23 15:36:38 2009 Subject: [GHC] #2143: Yhc's sort is faster than GHC's In-Reply-To: <051.957b307ec22b893e4ac872796076b55a@localhost> References: <051.957b307ec22b893e4ac872796076b55a@localhost> Message-ID: <060.557e217279e448e98979b5649255dae1@localhost> #2143: Yhc's sort is faster than GHC's -----------------------------+---------------------------------------------- Reporter: NeilMitchell | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.8.2 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | -----------------------------+---------------------------------------------- Changes (by guest): * cc: gwern0@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 23 16:41:18 2009 From: trac at galois.com (GHC) Date: Wed Dec 23 16:14:56 2009 Subject: [GHC] #3782: Data Parallel "Impossible happened" compiler error Message-ID: <044.3d41e65d193faf115a9d9aeea6bab909@localhost> #3782: Data Parallel "Impossible happened" compiler error ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.12.1 | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ When I attempted to compile my vectorized code , I got the following message: ghc -c -Odph -fcpr-off -fdph-seq newprop.hs ghc: panic! (the 'impossible' happened) (GHC version 6.12.1 for i386-apple-darwin): sumTyCon 11 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 23 19:04:15 2009 From: trac at galois.com (GHC) Date: Wed Dec 23 18:37:52 2009 Subject: [GHC] #3783: Allow --make and --fno-code Message-ID: <045.a0b0f64377b1a823678cd323636fb6d7@localhost> #3783: Allow --make and --fno-code ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.12.1 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Loading a largish project in ghci is roughly twice as fast as using `ghc --make` (and hugs is roughly 6 times faster than ghci). Presumably the majority of the extra time that `ghc --make` takes compared to `ghci` is down to generating object code, though some will be serialising `.hi` files. So the feature request is to let us use `ghc --make -fno-code`. The purpose is to check the code for errors, it would of course write out `.hi` files so that re-running `ghc --make -fno-code` only recompiles the changed files, like `:reload` in ghci. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 23 19:18:28 2009 From: trac at galois.com (GHC) Date: Wed Dec 23 18:52:15 2009 Subject: [GHC] #1845: unconditional relative branch out of range (GHC version 6.8.1/6.8.2 for powerpc_apple_darwin) In-Reply-To: <044.65389402080b2ab045a1b2fde12245f8@localhost> References: <044.65389402080b2ab045a1b2fde12245f8@localhost> Message-ID: <053.b9cd632964375b6d70d285f3afe4203f@localhost> #1845: unconditional relative branch out of range (GHC version 6.8.1/6.8.2 for powerpc_apple_darwin) ---------------------------+------------------------------------------------ Reporter: guest | Owner: thorkilnaur Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: Unknown | Os: MacOS X Testcase: | Architecture: powerpc Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by weakish): * failure: => None/Unknown * version: 6.8.2 => 6.10.4 Comment: This bug still exist on 6.10.4 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 23 21:36:00 2009 From: trac at galois.com (GHC) Date: Wed Dec 23 21:09:38 2009 Subject: [GHC] #3784: --with-gmp-includes and --with-gmp-libraries don't affect the building process of integer-gmp/cbits/mkGmpDerivedConstants Message-ID: <042.086ff891f8fafb9e8c853a08131127e3@localhost> #3784: --with-gmp-includes and --with-gmp-libraries don't affect the building process of integer-gmp/cbits/mkGmpDerivedConstants ---------------------------------+------------------------------------------ Reporter: PHO | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 6.12.1 | Keywords: integer-gmp Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Building GHC failed ---------------------------------+------------------------------------------ Passing --with-gmp-includes and --with-gmp-libraries to the libraries /integer-gmp/configure doesn't affect the building process of cbits/mkGmpDerivedConstants: {{{ "/usr/bin/gcc" libraries/integer-gmp/cbits/mkGmpDerivedConstants.c -o libraries/integer-gmp/cbits/mkGmpDerivedConstants libraries/integer-gmp/cbits/mkGmpDerivedConstants.c:15:17: error: gmp.h: No such file or directory }}} I could solve this problem by appendding the following line to libraries /integer-gmp/gmp/config.mk.in but I'm not sure this is the best way: {{{ libraries/integer-gmp_CC_OPTS += @CPPFLAGS@ @LDFLAGS@ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 23 21:44:01 2009 From: trac at galois.com (GHC) Date: Wed Dec 23 21:17:58 2009 Subject: [GHC] #2143: Yhc's sort is faster than GHC's In-Reply-To: <051.957b307ec22b893e4ac872796076b55a@localhost> References: <051.957b307ec22b893e4ac872796076b55a@localhost> Message-ID: <060.f30c7481ca364f7b6029c47f606ddec9@localhost> #2143: Yhc's sort is faster than GHC's -----------------------------+---------------------------------------------- Reporter: NeilMitchell | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.8.2 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | -----------------------------+---------------------------------------------- Comment (by guest): I put together a little module tonight which uses Criterion 0.2 (0.4 won't install under 6.10.2) to benchmark GHC & YHC sorts using ascending ints, descending ints, random ints, and the Shakesperean corpus (http://www.gutenberg.org/etext/100). (Besides the attachment, you can see http://hpaste.org/fastcgi/hpaste.fcgi/view?id=14873#a14875 ) YHC, as measured by mean, won on all of them, even random and Shakespeare. The margins were not all 2x, but the narrowest YHC victory was Shakespeare - YHC averaged 25.3s while GHC puffed along at 29.5s. Caveats: this was my first time using Criterion, no doubt there are major inefficiencies and bad style etc. But I doubt any of my errors were sufficient to upend the results. Given the margins in a core function which is used all over the place (I grepped through all the repos I've downloaded; 'sort' is used a *lot*), that the replacement is correct and faster in all cases, I think not making the change as soon as possible is a mistake. This is something that should have been done yesterday, as the expression goes. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 24 05:13:01 2009 From: trac at galois.com (GHC) Date: Thu Dec 24 04:46:36 2009 Subject: [GHC] #3783: Allow --make and --fno-code In-Reply-To: <045.a0b0f64377b1a823678cd323636fb6d7@localhost> References: <045.a0b0f64377b1a823678cd323636fb6d7@localhost> Message-ID: <054.69482b335acba3ba66d4310a5c4fac2e@localhost> #3783: Allow --make and --fno-code ------------------------------+--------------------------------------------- Reporter: duncan | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.12.1 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ------------------------------+--------------------------------------------- Comment (by simonpj): Another reason that this would be a Good Feature is that currently if you use `-dsuppress-uniques` (to get regression-test output that wobbles less), you need `-fno-code` else the assembler bleats about duplicate labels. But since `-fno-code` is currently incompatible with `--make`, that makes `-dsuppress-uniques` incompatible too, which is a pain. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 24 09:11:40 2009 From: trac at galois.com (GHC) Date: Thu Dec 24 08:45:16 2009 Subject: [GHC] #3785: Broken link in library docs Message-ID: <044.21422e3934fe6a6ad246e695b17185dd@localhost> #3785: Broken link in library docs ---------------------------------+------------------------------------------ Reporter: igloo | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.12.2 Component: Documentation | Version: 6.12.1 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ We need to generate `libraries/prologue.txt` with the version number in the link now that packages include their version number. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 24 09:55:06 2009 From: trac at galois.com (GHC) Date: Thu Dec 24 09:28:42 2009 Subject: [GHC] #3778: "test -e" in testsuite doesn't work with Solaris /bin/sh In-Reply-To: <045.ba6d721ea8ef7ec8850eec9a0e707e83@localhost> References: <045.ba6d721ea8ef7ec8850eec9a0e707e83@localhost> Message-ID: <054.36c417703326f74557e452f54868b57b@localhost> #3778: "test -e" in testsuite doesn't work with Solaris /bin/sh --------------------------------------+------------------------------------- Reporter: duncan | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.12.2 Component: Test Suite | Version: 6.12.1 Resolution: | Keywords: Difficulty: Easy (less than 1 hour) | Os: Solaris Testcase: | Architecture: sparc Failure: Other | --------------------------------------+------------------------------------- Changes (by igloo): * priority: normal => high * owner: => igloo * milestone: 6.12 branch => 6.12.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 24 10:03:57 2009 From: trac at galois.com (GHC) Date: Thu Dec 24 09:38:33 2009 Subject: [GHC] #650: Improve interaction between mutable arrays and GC In-Reply-To: <047.44b951cd4b5aa8536d862412c8d86597@localhost> References: <047.44b951cd4b5aa8536d862412c8d86597@localhost> Message-ID: <056.a7452ae9d36002e98866c119b49387e7@localhost> #650: Improve interaction between mutable arrays and GC --------------------------------------+------------------------------------- Reporter: simonmar | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.12.2 Component: Runtime System | Version: 6.4.1 Resolution: | Keywords: Difficulty: Difficult (2-5 days) | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Runtime performance bug | --------------------------------------+------------------------------------- Changes (by igloo): * owner: simonmar => igloo * type: bug => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 24 10:24:07 2009 From: trac at galois.com (GHC) Date: Thu Dec 24 09:57:41 2009 Subject: [GHC] #3785: Broken link in library docs In-Reply-To: <044.21422e3934fe6a6ad246e695b17185dd@localhost> References: <044.21422e3934fe6a6ad246e695b17185dd@localhost> Message-ID: <053.4c3f25fd895e41b9296fd8311b2b32fa@localhost> #3785: Broken link in library docs ----------------------------+----------------------------------------------- Reporter: igloo | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.12.2 Component: Documentation | Version: 6.12.1 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ----------------------------+----------------------------------------------- Comment (by igloo): Also `docs/index.html`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 24 10:25:14 2009 From: trac at galois.com (GHC) Date: Thu Dec 24 09:59:06 2009 Subject: [GHC] #2143: Yhc's sort is faster than GHC's In-Reply-To: <051.957b307ec22b893e4ac872796076b55a@localhost> References: <051.957b307ec22b893e4ac872796076b55a@localhost> Message-ID: <060.38ba1fd1c5b7d750a5febada5918deef@localhost> #2143: Yhc's sort is faster than GHC's -----------------------------+---------------------------------------------- Reporter: NeilMitchell | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.8.2 Resolution: fixed | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | -----------------------------+---------------------------------------------- Changes (by malcolm.wallace@cs.york.ac.uk): * status: new => closed * resolution: => fixed Comment: Pushed the faster version to the base library. It should probably be merged into ghc-6.12.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 25 08:00:02 2009 From: trac at galois.com (GHC) Date: Fri Dec 25 07:33:34 2009 Subject: [GHC] #3786: showing function argumetns when stopped at its definition Message-ID: <046.1f009ea01681f500ec74b93e2a923cd9@localhost> #3786: showing function argumetns when stopped at its definition ---------------------------------+------------------------------------------ Reporter: phercek | Owner: Type: feature request | Status: new Priority: normal | Component: GHCi Version: 6.12.1 | Keywords: debugger Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ It would be cool if GHCi debugger could grab not only the free variables in the selected expression but, in one case, a bit more. The case is when we stop at a function definition the first time (when just entering it). In this case, the debugger should provide the bindings for the function arguments. If a function uses pattern matching or when there are multiple equations with different formal argument names then there may not be any suitable name for the for the actual argument value. Because of this, we introduce the function argument names like: _arg1, _arg2, ... _argN. Numbering starts from 1 for the first formal argument of a function.[[BR]] The special _argN names should be provided always, even when there is a unique name for the argument in the source code. This request was discussed here: http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/17204 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 25 16:23:15 2009 From: trac at galois.com (GHC) Date: Fri Dec 25 15:56:47 2009 Subject: [GHC] #1473: isSpace is too slow In-Reply-To: <044.3c2c0fec916372178c4bf5ce7945c8fa@localhost> References: <044.3c2c0fec916372178c4bf5ce7945c8fa@localhost> Message-ID: <053.6783fee8be61c6a8a25d987bbe663d06@localhost> #1473: isSpace is too slow -----------------------------+---------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: libraries/base | Version: 6.6.1 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | -----------------------------+---------------------------------------------- Changes (by guest): * failure: => None/Unknown Comment: Improving isSpace is going to be difficult. I've done some Criterion benchmarking of the suggested optimizations, and for most of them, the benefit is modest. This may reflect improved optimization in GHC 6.10.2. However, there is a small improvement in `gspace'` and `gspace'''` as compared to `gspace`, so that might be worth doing? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 25 16:25:56 2009 From: trac at galois.com (GHC) Date: Fri Dec 25 15:59:32 2009 Subject: [GHC] #1473: isSpace is too slow In-Reply-To: <044.3c2c0fec916372178c4bf5ce7945c8fa@localhost> References: <044.3c2c0fec916372178c4bf5ce7945c8fa@localhost> Message-ID: <053.6965389138905300df7a6a2f2f2ca706@localhost> #1473: isSpace is too slow -----------------------------+---------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: libraries/base | Version: 6.6.1 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | -----------------------------+---------------------------------------------- Comment (by guest): (As with http://hackage.haskell.org/trac/ghc/ticket/2143, the Shakespeare data file is downloaded from http://www.gutenberg.org/etext/100 ) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Dec 26 00:15:05 2009 From: trac at galois.com (GHC) Date: Fri Dec 25 23:48:35 2009 Subject: [GHC] #3787: GHC 6.12.1 panic Message-ID: <047.0ece8a101cc798eefac149b629f279fa@localhost> #3787: GHC 6.12.1 panic -------------------------------+-------------------------------------------- Reporter: blamario | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.12.1 | Keywords: panic Os: Linux | Testcase: Architecture: x86_64 (amd64) | Failure: Compile-time crash -------------------------------+-------------------------------------------- GHC 6.12.1 reports the following when compiling the attached module: $ ghc --make Trampoline.hs -O[1 of 1] Compiling Control.Concurrent.SCC.Trampoline ( Trampoline.hs, Trampoline.o ) ghc: panic! (the 'impossible' happened) (GHC version 6.12.1 for x86_64-unknown-linux): expectJust chooseExternalIds: ds_d1HQ Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug So I'm dutifully reporting it. The module in question could probably be easily trimmed down, but I'm too sleepy at the moment. Let me know if you need that. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Dec 26 12:15:15 2009 From: trac at galois.com (GHC) Date: Sat Dec 26 11:49:01 2009 Subject: [GHC] #1409: Allow recursively dependent modules transparently (without .hs-boot or anything) In-Reply-To: <051.8a467503f7e6e3ea87602b7d1c1e067f@localhost> References: <051.8a467503f7e6e3ea87602b7d1c1e067f@localhost> Message-ID: <060.947820c1778357f9e12cf1a53b8607bf@localhost> #1409: Allow recursively dependent modules transparently (without .hs-boot or anything) ------------------------------+--------------------------------------------- Reporter: Isaac Dupree | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.10.2 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ------------------------------+--------------------------------------------- Changes (by increpare): * cc: analytic@gmail.com (added) * failure: => None/Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Dec 26 12:49:28 2009 From: trac at galois.com (GHC) Date: Sat Dec 26 12:22:57 2009 Subject: [GHC] #3788: Improved message for GHC "No instance for" Errors Message-ID: <048.485a2dc2f99474a564b523723eb1f48f@localhost> #3788: Improved message for GHC "No instance for" Errors ---------------------------------+------------------------------------------ Reporter: rhapsodyv | Owner: Type: proposal | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Keywords: errors Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Hi, I would like to propose a modification in the ghc message for "no instance for" errors. In the message, the ghc tells that there's no instance for the type you are using and it give you a hint that you can fix it adding a new instance for your type. But it don't tell me any instance alternative that already exists. So, if I don't know the correct type, I need to look at the documentation. At least for me, I get this message when I'm using the function in the wrong way or when I forget to specify the some function signature. It's quite rare the I want to add a new instance. Of course that it's not a problem to look at the documentation, but improving it can save a significant time and help the beginers to guess the error and how fix it. In C++ and Java, when I use g++ or javac and I make a wrong overloading, the compiler show me some alternatives. I think it help more than tell me to add a new overload to the function. It's possible to do it in ghc? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Dec 26 14:26:32 2009 From: trac at galois.com (GHC) Date: Sat Dec 26 14:00:02 2009 Subject: [GHC] #3789: Segfault and -dstg-lint errors using FFI and -XEmptyDataDecls Message-ID: <045.2c0f987a4ddd3ec0b9fa039bca72f39b@localhost> #3789: Segfault and -dstg-lint errors using FFI and -XEmptyDataDecls ------------------------+--------------------------------------------------- Reporter: judahj | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (NCG) Version: 6.12.1 | Keywords: Os: MacOS X | Testcase: Architecture: x86 | Failure: Runtime crash ------------------------+--------------------------------------------------- I encountered a segfault when working with some FFI code. I eventually discovered that this code also makes `-dstg-lint` complain. With the below files, I can reproduce the segfault and `-dstg-lint` issues using ghc-6.12.1 and ghc-6.10.3 on OS X 10.6.2. The segfault goes away if I use -fvia-C, -O, or if I build on OS X 10.5.7. The segfault also goes away if I use a unit type `()` instead of -XEmptyDataDecls. {{{ $ ghc --make test-segfault.hs foreign.c -XForeignFunctionInterface \ -XEmptyDataDecls -fforce-recomp && ./test-segfault [1 of 2] Compiling Types ( Types.hs, Types.o ) [2 of 2] Compiling Main ( test-segfault.hs, test-segfault.o ) Linking test-segfault ... About to create... Segmentation fault }}} foreign.c: {{{ #include #include void * c_createFoo (int x) { fprintf(stderr,"Creating foo...\n"); fflush(stderr); int *p = malloc(sizeof(int)); *p = x; return p; } }}} Types.hs: {{{ module Types where import Foreign.Ptr import Foreign.C.Types -- Replacing this line with the following one prevents the segfault, -- but not the -dstg-lint error. data Foo_ -- type Foo_ = () foreign import ccall safe c_createFoo :: CInt -> IO (Ptr Foo_) createFoo :: Int -> IO (Ptr Foo_) createFoo dtype = c_createFoo (toEnum dtype) }}} test-segfault.hs: {{{ module Main where import Types main = do putStrLn "About to create..." createFoo 1 putStrLn "Created." }}} The `-dstg-lint` error is somewhat long, but I can paste it if you're unable to reproduce it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Dec 27 18:17:43 2009 From: trac at galois.com (GHC) Date: Sun Dec 27 17:51:21 2009 Subject: [GHC] #3716: building ghc-6.12.0.20091121 ends with internal Haddock or GHC error In-Reply-To: <045.e5c85a6d9c01c90f88c47b3f6ae70039@localhost> References: <045.e5c85a6d9c01c90f88c47b3f6ae70039@localhost> Message-ID: <054.7cb04504356ce1f1b76738ba1bd4e6a4@localhost> #3716: building ghc-6.12.0.20091121 ends with internal Haddock or GHC error ----------------------------------+----------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.12.1 Resolution: | Keywords: Difficulty: | Os: Solaris Testcase: | Architecture: x86 Failure: Building GHC failed | ----------------------------------+----------------------------------------- Changes (by duncan): * difficulty: => Comment: This should now be fixed by: {{{ Thu Dec 17 01:04:21 CET 2009 Ian Lynagh * Fix another sed problem on Solaris }}} Confirmation would be appreciated. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Dec 27 18:18:00 2009 From: trac at galois.com (GHC) Date: Sun Dec 27 17:51:41 2009 Subject: [GHC] #3679: ./configure --enable-shared does not work for ghc-6.10 In-Reply-To: <045.a31c5e09104888542891e34602423108@localhost> References: <045.a31c5e09104888542891e34602423108@localhost> Message-ID: <054.fa9abda59573c66016b7650ac9e675bd@localhost> #3679: ./configure --enable-shared does not work for ghc-6.10 ----------------------------------+----------------------------------------- Reporter: elkner | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: wontfix | Keywords: Difficulty: | Os: Solaris Testcase: | Architecture: x86_64 (amd64) Failure: Building GHC failed | ----------------------------------+----------------------------------------- Changes (by duncan): * status: new => closed * resolution: => wontfix * summary: ghc: panic! (the 'impossible' happened) => ./configure --enable-shared does not work for ghc-6.10 Comment: Note that `--enable-shared` is not supported in GHC 6.10. Currently the only platforms where ghc supports shared libs are Linux on x86 and x86-64 and only when using ghc-6.12. Note also that the configure flags `--disable-static` and `--disable- rpath` do not actually exist. In ghc-6.12 the flag `--enable-shared` also does not exist. The way to force the ghc build system to try to make shared libs on platforms where they are not officially supported is to add `GhcLibWays += dyn` to your `mk/build.mk`. Elkner, it's worth having a go and trying this with 6.12. I would not expect it to work first time but it should give us a clue as to what needs fixing. Report your progress to the ghc users list and/or file a new feature-request ticket. I'm closing this ticket because we do not expect 6.10 to support `--enabled-shared`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Dec 27 19:04:37 2009 From: trac at galois.com (GHC) Date: Sun Dec 27 18:38:03 2009 Subject: [GHC] #3790: control-C causes segfault, siginfo_t* can be NULL on Solaris Message-ID: <045.d2557c16e92c7f9e5e2306103fb1f846@localhost> #3790: control-C causes segfault, siginfo_t* can be NULL on Solaris -------------------------------+-------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.12.1 Keywords: | Difficulty: Os: Solaris | Testcase: Architecture: sparc | Failure: Runtime crash -------------------------------+-------------------------------------------- On Sparc Solaris, all ghc-compiled programs (including ghc and ghci) segfault when interrupted with control-C. This happens with ghc-6.10.4 and 6.12.1. It worked OK in ghc-6.8.3. The following is a gdb backtrace generated from a core file produced from running ghc-6.12.1 and hitting ^C. {{{ #0 0xff0b05d4 in memcpy () from /platform/SUNW,SPARC-Enterprise-T5120/lib/libc_psr.so.1 #1 0x01d17040 in generic_handler () #2 #3 0xff1c4a34 in __lwp_park () from /lib/libc.so.1 #4 0xff1be968 in cond_sleep_queue () from /lib/libc.so.1 #5 0xff1bea84 in cond_wait_queue () from /lib/libc.so.1 #6 0xff1bf004 in cond_wait () from /lib/libc.so.1 #7 0xff1bf040 in pthread_cond_wait () from /lib/libc.so.1 #8 0x01d16ab0 in waitCondition () #9 0x01d01058 in yieldCapability () #10 0x01d07c08 in schedule () #11 0x01d055e4 in real_main () #12 0x01d0578c in hs_main () #13 0x00515434 in _start () }}} The backtrace from a trivial ghc-compiled program looks similar. The only interesting thing this tells us is that the problem happens with the single-threaded and multi-threaded RTSs similarly. Looking at `generic_handler` in `./posix/Signals.c`, in the `defined(THREADED_RTS)` case: {{{ StgWord8 buf[sizeof(siginfo_t) + 1]; int r; buf[0] = sig; memcpy(buf+1, info, sizeof(siginfo_t)); }}} and in the `! defined(THREADED_RTS)`: {{{ memcpy(next_pending_handler, info, sizeof(siginfo_t)); }}} So it would appear that the `siginfo_t *info` parameter to `generic_handler` is NULL. The Solaris manpage for `sigaction` indicates that the `siginfo_t` pointer may be NULL. Presumably it is non-NULL for the kind of signals that have extra info, like `SIGCHILD`, but not for `SIGINT`. The manpage for `siginfo.h` lists a number of kinds of signals that do receive a `siginfo_t` but `SIGINT` is not amongst them. So this would explain why it worked in 6.8.3, since we only started using the `siginfo_t *` in 6.10. So I guess we either push a "null"/"empty" `siginfo_t` down the IO manager pipe, or provide a way to indicate that there is no `siginfo_t` supplied. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 28 00:28:56 2009 From: trac at galois.com (GHC) Date: Mon Dec 28 00:02:21 2009 Subject: [GHC] #3791: SplitObjs fails on sparc with GNU ld Message-ID: <045.5e901b18df33895f26639fdfc0d17dcc@localhost> #3791: SplitObjs fails on sparc with GNU ld -----------------------+---------------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Driver | Version: 6.12.1 Keywords: | Difficulty: Easy (less than 1 hour) Os: Linux | Testcase: Architecture: sparc | Failure: Building GHC failed -----------------------+---------------------------------------------------- On Sparc, GNU ld reports the restriction that {{{ ld: --relax and -r may not be used together }}} GHC call gcc with the flags {{{ gcc -Wl,-r -Wl,-x -o Foo.o Foo_o_split/ld.script }}} thus instructing gcc to call ld with the -r flag. It is gcc that supplies the `-relax` flag. According to `gcc -dumpspecs` this is gcc's default if the `-mno-relax` or `-r` flags are not supplied. Since ghc supplies gcc with `-Wl,-r` and not `-r`, then gcc does not omit the `-relax` flag and thus the problem occurs. The problem could be avoided by ghc using `-r` instead of `-Wl,-r`, or by passing `-mno-relax`. The latter is probably preferable since `-mno-relax` is an official gcc flag (which has no effect on arches where `-relax` does nothing) whereas `-r` is a linker flag that gcc will pass through. Note that `-mno-relax` is only needed when we're using `-r`, indeed allowing gcc to use `-relax` for normal final links is an optimisation. As a workaround users can build with `SplitObjs=NO` in `mk/build.mk`. It may also work to set `SRC_HC_OPTS=-optl-mno-relax`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 28 07:24:52 2009 From: trac at galois.com (GHC) Date: Mon Dec 28 06:58:27 2009 Subject: [GHC] #3716: building ghc-6.12.0.20091121 ends with internal Haddock or GHC error In-Reply-To: <045.e5c85a6d9c01c90f88c47b3f6ae70039@localhost> References: <045.e5c85a6d9c01c90f88c47b3f6ae70039@localhost> Message-ID: <054.ae5c33f4b3c9f51018725954e2dd14b8@localhost> #3716: building ghc-6.12.0.20091121 ends with internal Haddock or GHC error ----------------------------------+----------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.12.1 Resolution: | Keywords: Difficulty: | Os: Solaris Testcase: | Architecture: x86 Failure: Building GHC failed | ----------------------------------+----------------------------------------- Comment (by maeder): The generated entries in `index.html` look wrong to me: {{{ -> GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 28 07:24:35 2009 From: trac at galois.com (GHC) Date: Mon Dec 28 07:00:07 2009 Subject: [GHC] #3792: Qualified names in import specifications Message-ID: <044.0afdfc1c49ec255d82e9097f816e7649@localhost> #3792: Qualified names in import specifications ---------------------------------+------------------------------------------ Reporter: nibro | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.12.1 | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Other ---------------------------------+------------------------------------------ GHC accepts qualified names in import specifications, e.g. {{{ module Main where import Foo (Bar.bar) }}} I don't see the point of this, nor is it documented anywhere. I propose that either a) this (mis)feature is removed, or b) this feature is documented and tied to a registered extension that can be enabled or disabled as seen fit. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 28 17:20:35 2009 From: trac at galois.com (GHC) Date: Mon Dec 28 16:53:57 2009 Subject: [GHC] #3793: System.Time.toClockTime does not support all valid timezone offsets. Message-ID: <045.573376566b5efc770151c67d8f432e86@localhost> #3793: System.Time.toClockTime does not support all valid timezone offsets. ---------------------------------+------------------------------------------ Reporter: daniel | Owner: Type: bug | Status: new Priority: normal | Component: libraries/old-time Version: | Keywords: tz timezone toClockTime Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Runtime crash ---------------------------------+------------------------------------------ toClockTime errors when the timezone offset is outside the range of -1200 to +1200. There are valid timezone offsets greater than +1200. Parts of Kiribati are, I believe, +1400. Attached is a patch against the current head. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 28 19:15:39 2009 From: trac at galois.com (GHC) Date: Mon Dec 28 18:49:01 2009 Subject: [GHC] #3793: System.Time.toClockTime does not support all valid timezone offsets. In-Reply-To: <045.573376566b5efc770151c67d8f432e86@localhost> References: <045.573376566b5efc770151c67d8f432e86@localhost> Message-ID: <054.d85b28d31240498c10e1117de7635408@localhost> #3793: System.Time.toClockTime does not support all valid timezone offsets. -----------------------------------+---------------------------------------- Reporter: daniel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/old-time | Version: Resolution: | Keywords: tz timezone toClockTime Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Incorrect result at runtime -----------------------------------+---------------------------------------- Changes (by daniel): * failure: Runtime crash => Incorrect result at runtime -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 28 21:42:39 2009 From: trac at galois.com (GHC) Date: Mon Dec 28 21:16:01 2009 Subject: [GHC] #3794: Compiling a main program yields: /usr/bin/ld: cannot find -lHSrtsmain Message-ID: <044.e1a190f33d758a6bb97e24503af072e1@localhost> #3794: Compiling a main program yields: /usr/bin/ld: cannot find -lHSrtsmain -----------------------+---------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.12.1 | Keywords: Os: Linux | Testcase: Architecture: x86 | Failure: Installing GHC failed -----------------------+---------------------------------------------------- I have installed the generic Linux binary package for GHC-6.12.1 from http://www.haskell.org/ghc/dist/6.12.1/ghc-6.12.1-i386-unknown- linux-n.tar.bz2 on Kubuntu. When I try to compile a simple main program, like {{{ main = putStr "Hello world!\n" }}} I get {{{ /usr/bin/ld: cannot find -lHSrtsmain }}} The reason is, that {{{/usr/local/lib/ghc-6.12.1/libHSrtsmain.a}}} is not readable by users. I could fix the problem for me using {{{ sudo chmod a+r /usr/local/lib/ghc-6.12.1/libHS* }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 29 09:36:39 2009 From: trac at galois.com (GHC) Date: Tue Dec 29 09:10:01 2009 Subject: [GHC] #3795: Haddock executable not versioned Message-ID: <046.6038e00fcfe0d713d23c23af281a15cb@localhost> #3795: Haddock executable not versioned ---------------------------------+------------------------------------------ Reporter: lpsmith | Owner: Type: bug | Status: new Priority: normal | Component: Documentation Version: 6.12.1 | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Other ---------------------------------+------------------------------------------ Now that Haddock uses the GHC api, it's tied to a particular version of GHC. However, the executable itself does not follow the versioned name convention. It's been making it trickier than it should be to have multiple versions of GHC around. Honestly, this might apply to other programs included in the distribution, but it's the one that's been biting me lately. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 29 14:42:15 2009 From: trac at galois.com (GHC) Date: Tue Dec 29 14:15:35 2009 Subject: [GHC] #3787: GHC 6.12.1 panic In-Reply-To: <047.0ece8a101cc798eefac149b629f279fa@localhost> References: <047.0ece8a101cc798eefac149b629f279fa@localhost> Message-ID: <056.e8c729e1184b741e2fdc2fc0a38e99ed@localhost> #3787: GHC 6.12.1 panic -------------------------------+-------------------------------------------- Reporter: blamario | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.12.1 Resolution: | Keywords: panic Os: Linux | Testcase: Architecture: x86_64 (amd64) | Failure: Compile-time crash -------------------------------+-------------------------------------------- Comment (by ajd): This also happens on i686. Note that it only happens with optimizations enabled (-O or -O2). I trimmed down the module as much as I could while preserving the bug; I'll attach the result. Note that removing the type signature or any of the cases of resolveProducerConsumer makes the bug go away: all four must be present to cause the panic. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 30 04:26:19 2009 From: trac at galois.com (GHC) Date: Wed Dec 30 03:59:39 2009 Subject: [GHC] #3727: several Haiku platform defs In-Reply-To: <043.0c45c6547023fdad014a8678dc73ea96@localhost> References: <043.0c45c6547023fdad014a8678dc73ea96@localhost> Message-ID: <052.08bc4affcb90ae5d6f38c405d9b9dd51@localhost> #3727: several Haiku platform defs ----------------------------------+----------------------------------------- Reporter: donn | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.14.1 Component: Compiler | Version: 6.12.1 RC1 Resolution: fixed | Keywords: Difficulty: | Os: Other Testcase: | Architecture: x86 Failure: Building GHC failed | ----------------------------------+----------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed * milestone: => 6.14.1 Comment: Pushed; in ghc: {{{ Mon Dec 21 03:02:50 PST 2009 Simon Marlow * Partial support for Haiku (#3727) }}} in `libraries/unix`: {{{ Mon Dec 21 03:05:54 PST 2009 Simon Marlow * Add Haiku (#3727) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 30 04:40:36 2009 From: trac at galois.com (GHC) Date: Wed Dec 30 04:13:56 2009 Subject: [GHC] #3790: control-C causes segfault, siginfo_t* can be NULL on Solaris In-Reply-To: <045.d2557c16e92c7f9e5e2306103fb1f846@localhost> References: <045.d2557c16e92c7f9e5e2306103fb1f846@localhost> Message-ID: <054.fab6070d4e2ba9176a309febf1a49744@localhost> #3790: control-C causes segfault, siginfo_t* can be NULL on Solaris -----------------------------+---------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: Runtime System | Version: 6.12.1 Resolution: | Keywords: Difficulty: | Os: Solaris Testcase: | Architecture: sparc Failure: Runtime crash | -----------------------------+---------------------------------------------- Changes (by simonmar): * milestone: => 6.12.2 Comment: Your analysis looks reasonable. I think it should be ok to just `memset(buf+1, 0, sizeof(siginfo_t))` in the case that `info == NULL`, because looking at the code in `libraries/unix/System/Posix/Signals.hsc` we use the `si_errno` field of the `siginfo_t`, but we only look at the rest if the signal is `SIGCHLD`. A value of zero for `si_errno` is a reasonable default. Would you like to test and submit a patch? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 30 04:48:49 2009 From: trac at galois.com (GHC) Date: Wed Dec 30 04:22:25 2009 Subject: [GHC] #2143: Yhc's sort is faster than GHC's In-Reply-To: <051.957b307ec22b893e4ac872796076b55a@localhost> References: <051.957b307ec22b893e4ac872796076b55a@localhost> Message-ID: <060.07effcb80d5ae58b4ea22c6c30e0870a@localhost> #2143: Yhc's sort is faster than GHC's -----------------------------+---------------------------------------------- Reporter: NeilMitchell | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.8.2 Resolution: fixed | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | -----------------------------+---------------------------------------------- Comment (by simonmar): Thanks Malcolm. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 30 04:50:53 2009 From: trac at galois.com (GHC) Date: Wed Dec 30 04:24:11 2009 Subject: [GHC] #3787: GHC 6.12.1 panic In-Reply-To: <047.0ece8a101cc798eefac149b629f279fa@localhost> References: <047.0ece8a101cc798eefac149b629f279fa@localhost> Message-ID: <056.1aa41411ab218bb40ff688de34783571@localhost> #3787: GHC 6.12.1 panic ---------------------------------+------------------------------------------ Reporter: blamario | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.12.2 Component: Compiler | Version: 6.12.1 Resolution: | Keywords: panic Difficulty: | Os: Linux Testcase: | Architecture: x86_64 (amd64) Failure: Compile-time crash | ---------------------------------+------------------------------------------ Changes (by simonmar): * priority: normal => high * difficulty: => * owner: => simonmar * milestone: => 6.12.2 Old description: > GHC 6.12.1 reports the following when compiling the attached module: > > $ ghc --make Trampoline.hs -O[1 of 1] Compiling > Control.Concurrent.SCC.Trampoline ( Trampoline.hs, Trampoline.o ) > ghc: panic! (the 'impossible' happened) > (GHC version 6.12.1 for x86_64-unknown-linux): > expectJust chooseExternalIds: ds_d1HQ > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > So I'm dutifully reporting it. The module in question could probably be > easily trimmed down, but I'm too sleepy at the moment. Let me know if you > need that. New description: GHC 6.12.1 reports the following when compiling the attached module: {{{ $ ghc --make Trampoline.hs -O[1 of 1] Compiling Control.Concurrent.SCC.Trampoline ( Trampoline.hs, Trampoline.o ) ghc: panic! (the 'impossible' happened) (GHC version 6.12.1 for x86_64-unknown-linux): expectJust chooseExternalIds: ds_d1HQ Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} So I'm dutifully reporting it. The module in question could probably be easily trimmed down, but I'm too sleepy at the moment. Let me know if you need that. Comment: I'll look at this, probably my fault as I modified `chooseExternalIds` last. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 30 04:58:28 2009 From: trac at galois.com (GHC) Date: Wed Dec 30 04:31:47 2009 Subject: [GHC] #3793: System.Time.toClockTime does not support all valid timezone offsets. In-Reply-To: <045.573376566b5efc770151c67d8f432e86@localhost> References: <045.573376566b5efc770151c67d8f432e86@localhost> Message-ID: <054.477729ec73b356c4f12dc0dd8eed55d0@localhost> #3793: System.Time.toClockTime does not support all valid timezone offsets. ------------------------------------------+--------------------------------- Reporter: daniel | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: libraries/old-time | Version: Resolution: | Keywords: tz timezone toClockTime Difficulty: Easy (less than 1 hour) | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Incorrect result at runtime | ------------------------------------------+--------------------------------- Changes (by simonmar): * difficulty: => Easy (less than 1 hour) * milestone: => 6.12.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 30 04:59:21 2009 From: trac at galois.com (GHC) Date: Wed Dec 30 04:32:39 2009 Subject: [GHC] #3789: Segfault and -dstg-lint errors using FFI and -XEmptyDataDecls In-Reply-To: <045.2c0f987a4ddd3ec0b9fa039bca72f39b@localhost> References: <045.2c0f987a4ddd3ec0b9fa039bca72f39b@localhost> Message-ID: <054.27964533e1eb1b54991c367f54a7e9af@localhost> #3789: Segfault and -dstg-lint errors using FFI and -XEmptyDataDecls -----------------------------+---------------------------------------------- Reporter: judahj | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.2 Component: Compiler (NCG) | Version: 6.12.1 Resolution: | Keywords: Difficulty: | Os: MacOS X Testcase: | Architecture: x86 Failure: Runtime crash | -----------------------------+---------------------------------------------- Changes (by simonmar): * priority: normal => high * difficulty: => * milestone: => 6.12.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 30 05:16:29 2009 From: trac at galois.com (GHC) Date: Wed Dec 30 04:49:47 2009 Subject: [GHC] #3783: Allow --make and --fno-code In-Reply-To: <045.a0b0f64377b1a823678cd323636fb6d7@localhost> References: <045.a0b0f64377b1a823678cd323636fb6d7@localhost> Message-ID: <054.e5701de6137369434448173dc8991832@localhost> #3783: Allow --make and --fno-code ------------------------------+--------------------------------------------- Reporter: duncan | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler | Version: 6.12.1 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ------------------------------+--------------------------------------------- Changes (by simonmar): * milestone: => 6.14.1 Comment: I think it might be just a bug in the front end that the combination is disallowed. The GHC API certainly supports this mode of compilation, and indeed Haddock uses it. However, in this mode we don't currently generate `.hi` files. That is fairly easy to change, but apparently there's a need for both modes, so perhaps we need a flag. The main problem with `-fno-code` is that Template Haskell code cannot be compiled this way, for obvious reasons. Haddock has to go back and compile things to object code if TH is needed (I don't recall how it figures out that it needs to do this, though). Simon: perhaps `-dsuppress-uniques` shouldn't apply when generating code? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 30 05:31:09 2009 From: trac at galois.com (GHC) Date: Wed Dec 30 05:04:26 2009 Subject: [GHC] #3728: configure should omit full path in unistd.h, stdlib.h return type tests In-Reply-To: <043.d33bce572e64777410efea0050887938@localhost> References: <043.d33bce572e64777410efea0050887938@localhost> Message-ID: <052.e9ea0721dcb50a6a600e56a244a3a371@localhost> #3728: configure should omit full path in unistd.h, stdlib.h return type tests ----------------------------------+----------------------------------------- Reporter: donn | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.12.2 Component: Compiler | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: | Os: Other Testcase: | Architecture: x86 Failure: Building GHC failed | ----------------------------------+----------------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge * milestone: => 6.12.2 Comment: Applied, thanks: {{{ Mon Dec 21 03:06:34 PST 2009 Simon Marlow * Don't use absolute paths to headers (#3728) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 30 05:34:29 2009 From: trac at galois.com (GHC) Date: Wed Dec 30 05:07:47 2009 Subject: [GHC] #3780: unix-2.4.0.0 fails with base 4.1 In-Reply-To: <045.da767e73d04d85283e231ed41de5ef94@localhost> References: <045.da767e73d04d85283e231ed41de5ef94@localhost> Message-ID: <054.acb6f88c6d78506edba48ca341a99d2e@localhost> #3780: unix-2.4.0.0 fails with base 4.1 --------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/unix | Version: 6.12.1 Resolution: | Keywords: Difficulty: Easy (less than 1 hour) | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Other | --------------------------------------+------------------------------------- Comment (by simonmar): Isn't the problem here that the dependency on base is wrong, and should really say `>= 4.2`? Does that lead to different problems? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 30 09:08:03 2009 From: trac at galois.com (GHC) Date: Wed Dec 30 08:41:23 2009 Subject: [GHC] #3780: unix-2.4.0.0 fails with base 4.1 In-Reply-To: <045.da767e73d04d85283e231ed41de5ef94@localhost> References: <045.da767e73d04d85283e231ed41de5ef94@localhost> Message-ID: <054.783903ca659508faa4ce37f54ad922d3@localhost> #3780: unix-2.4.0.0 fails with base 4.1 --------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/unix | Version: 6.12.1 Resolution: | Keywords: Difficulty: Easy (less than 1 hour) | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Other | --------------------------------------+------------------------------------- Comment (by duncan): Replying to [comment:1 simonmar]: > Isn't the problem here that the dependency on base is wrong, and should really say `>= 4.2`? Does that lead to different problems? That would be another solution. The only problem there is an inconvenience because cabal-install's current solver does not handle this case well. If someone tries to install unix for ghc 6.10 (or it needs to rebuilt to make something else work) then cabal does not pick unix-2.3.x instead, it picks unix 2.4 and then fails when it finds that could not be configured with ghc 6.10. Obviously, that's not a problem with the unix package, it's a problem that the solver isn't very smart. If there are any actual improvements in the unix 2.4 version then of course it can be nice to let it build with older versions of base. The main thing though is that the declared dependencies be accurate, either by adjusting the deps or by other fixes. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 30 09:10:04 2009 From: trac at galois.com (GHC) Date: Wed Dec 30 08:43:23 2009 Subject: [GHC] #3783: Allow --make and --fno-code In-Reply-To: <045.a0b0f64377b1a823678cd323636fb6d7@localhost> References: <045.a0b0f64377b1a823678cd323636fb6d7@localhost> Message-ID: <054.fdb20ac0fa9d05a3745f58d4ee6500c5@localhost> #3783: Allow --make and --fno-code ------------------------------+--------------------------------------------- Reporter: duncan | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler | Version: 6.12.1 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ------------------------------+--------------------------------------------- Comment (by duncan): Replying to [comment:2 simonmar]: > The main problem with `-fno-code` is that Template Haskell code cannot be compiled this way, for obvious reasons. Haddock has to go back and compile things to object code if TH is needed (I don't recall how it figures out that it needs to do this, though). Does it have to be object code? Could it not compile things to bytecode, either pre-emptively or just in the case of -XTemplateHaskell? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 30 09:48:16 2009 From: trac at galois.com (GHC) Date: Wed Dec 30 09:21: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.1997949f28d660259434bb48f1e3ea7e@localhost> #2615: ghci doesn't play nice with linker scripts ------------------------------------------+--------------------------------- Reporter: AlecBerryman | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: GHCi | Version: 6.10.1 Resolution: | Keywords: dlopen, dynamic linking Difficulty: Unknown | Os: Linux Testcase: | Architecture: Unknown/Multiple Failure: Incorrect result at runtime | ------------------------------------------+--------------------------------- Comment (by simonmar): Looks good to me. It needs validating on OS X though: I think the `#ifdefs` at the top may need to be tweaked, as I don't think the `#include ` is enabled under `OBJFORMAT_MACHO`. Ian, could you validate & push? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 30 10:51:08 2009 From: trac at galois.com (GHC) Date: Wed Dec 30 10:24:26 2009 Subject: [GHC] #3783: Allow --make and --fno-code In-Reply-To: <045.a0b0f64377b1a823678cd323636fb6d7@localhost> References: <045.a0b0f64377b1a823678cd323636fb6d7@localhost> Message-ID: <054.18672ed6b80a190b9a7c50b123804dbe@localhost> #3783: Allow --make and --fno-code ------------------------------+--------------------------------------------- Reporter: duncan | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler | Version: 6.12.1 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ------------------------------+--------------------------------------------- Comment (by simonmar): Replying to [comment:3 duncan]: > Does it have to be object code? Could it not compile things to bytecode, either pre-emptively or just in the case of -XTemplateHaskell? It could, but not everything can be compiled to byte-code: arbitrary unboxed tuples, which I think is why Haddock uses object code. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 31 09:38:37 2009 From: trac at galois.com (GHC) Date: Thu Dec 31 09:11:51 2009 Subject: [GHC] #3796: GHC 6.12 dependency checking many times slower than 6.10 Message-ID: <048.1804574c402b028604cc65b754fd78d4@localhost> #3796: GHC 6.12 dependency checking many times slower than 6.10 --------------------------+------------------------------------------------- Reporter: sunrayser | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.12.1 | Keywords: Os: Linux | Testcase: Architecture: x86 | Failure: Compile-time performance bug --------------------------+------------------------------------------------- Get feldspar-language-0.1 from hackage and build it: http://hackage.haskell.org/packages/archive/feldspar-language/0.1 /feldspar-language-0.1.tar.gz Performance: "cabal configure; cabal cuild; time cabal build" 6.12: real 0m24.316s user 0m24.063s sys 0m0.159s 6.10: real 0m2.252s user 0m2.021s sys 0m0.231s "time cabal build" with 6.10 after "cabal build"-ing it with 6.12 (ie no "rm -rf dist" before building with 6.10) real 0m24.304s user 0m24.094s sys 0m0.139s The last one is especially strange. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 31 09:44:02 2009 From: trac at galois.com (GHC) Date: Thu Dec 31 09:17:15 2009 Subject: [GHC] #3796: GHC 6.12 dependency checking many times slower than 6.10 In-Reply-To: <048.1804574c402b028604cc65b754fd78d4@localhost> References: <048.1804574c402b028604cc65b754fd78d4@localhost> Message-ID: <057.bec25f56e184da7a5a91e14367ef1cb1@localhost> #3796: GHC 6.12 dependency checking many times slower than 6.10 -------------------------------------------+-------------------------------- Reporter: sunrayser | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.12.1 Resolution: | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86 Failure: Compile-time performance bug | -------------------------------------------+-------------------------------- Changes (by igloo): * difficulty: => Old description: > Get feldspar-language-0.1 from hackage and build it: > http://hackage.haskell.org/packages/archive/feldspar-language/0.1 > /feldspar-language-0.1.tar.gz > > Performance: > > "cabal configure; cabal cuild; time cabal build" > > 6.12: > real 0m24.316s > user 0m24.063s > sys 0m0.159s > > 6.10: > real 0m2.252s > user 0m2.021s > sys 0m0.231s > > "time cabal build" with 6.10 after "cabal build"-ing it with 6.12 (ie no > "rm -rf dist" before building with 6.10) > real 0m24.304s > user 0m24.094s > sys 0m0.139s > > The last one is especially strange. New description: Get feldspar-language-0.1 from hackage and build it: http://hackage.haskell.org/package/feldspar-language http://hackage.haskell.org/packages/archive/feldspar-language/0.1 /feldspar-language-0.1.tar.gz Performance: {{{ "cabal configure; cabal cuild; time cabal build" 6.12: real 0m24.316s user 0m24.063s sys 0m0.159s 6.10: real 0m2.252s user 0m2.021s sys 0m0.231s "time cabal build" with 6.10 after "cabal build"-ing it with 6.12 (ie no "rm -rf dist" before building with 6.10) real 0m24.304s user 0m24.094s sys 0m0.139s }}} The last one is especially strange. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 31 11:24:49 2009 From: trac at galois.com (GHC) Date: Thu Dec 31 10:58:04 2009 Subject: [GHC] #3796: GHC 6.12 dependency checking many times slower than 6.10 In-Reply-To: <048.1804574c402b028604cc65b754fd78d4@localhost> References: <048.1804574c402b028604cc65b754fd78d4@localhost> Message-ID: <057.e6780285beff61f11a8798aa98deddf5@localhost> #3796: GHC 6.12 dependency checking many times slower than 6.10 -------------------------------------------+-------------------------------- Reporter: sunrayser | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.12.2 Component: Compiler | Version: 6.12.1 Resolution: | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86 Failure: Compile-time performance bug | -------------------------------------------+-------------------------------- Changes (by simonmar): * priority: normal => high * owner: => simonmar * milestone: => 6.12.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 31 12:23:10 2009 From: trac at galois.com (GHC) Date: Thu Dec 31 11:57:44 2009 Subject: [GHC] #650: Improve interaction between mutable arrays and GC In-Reply-To: <047.44b951cd4b5aa8536d862412c8d86597@localhost> References: <047.44b951cd4b5aa8536d862412c8d86597@localhost> Message-ID: <056.6e6eef64e59d309916003a4cba3124ea@localhost> #650: Improve interaction between mutable arrays and GC --------------------------------------+------------------------------------- Reporter: simonmar | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.12.2 Component: Runtime System | Version: 6.4.1 Resolution: | Keywords: Difficulty: Difficult (2-5 days) | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Runtime performance bug | --------------------------------------+------------------------------------- Comment (by igloo): Is the "more testing and benchmarking" done? Or is someone doing it? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 31 15:25:27 2009 From: trac at galois.com (GHC) Date: Thu Dec 31 14:58:41 2009 Subject: [GHC] #3787: GHC 6.12.1 panic In-Reply-To: <047.0ece8a101cc798eefac149b629f279fa@localhost> References: <047.0ece8a101cc798eefac149b629f279fa@localhost> Message-ID: <056.830fb1d5776401189bdc67d4b4458b61@localhost> #3787: GHC 6.12.1 panic ---------------------------------+------------------------------------------ Reporter: blamario | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.12.2 Component: Compiler | Version: 6.12.1 Resolution: | Keywords: panic Difficulty: | Os: Linux Testcase: | Architecture: x86_64 (amd64) Failure: Compile-time crash | ---------------------------------+------------------------------------------ Comment (by blamario): I found a slightly different way to panic. This one is more bothersome because it occurs when I try compiling (what I hope is) a correct and usable module. Furthermore, the panic happens with or without optimization. Even GHCi panics, though not when it loads the module but later, when I try to run tests. Here's what I get: {{{ $ ghc --make Test.hs -o test -threaded -hidir obj -odir obj [1 of 8] Compiling Control.Concurrent.SCC.Trampoline ( Control/Concurrent/SCC/Trampoline.hs, obj/Control/Concurrent/SCC/Trampoline.o ) ghc: panic! (the 'impossible' happened) (GHC version 6.12.1 for x86_64-unknown-linux): initC: srt_lbl Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug $ $ ghci '*Test' GHCi, version 6.12.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package ffi-1.0 ... linking ... done. [1 of 8] Compiling Control.Concurrent.SCC.Trampoline ( Control/Concurrent/SCC/Trampoline.hs, interpreted ) [2 of 8] Compiling Control.Concurrent.SCC.Types ( Control/Concurrent/SCC/Types.hs, interpreted ) [3 of 8] Compiling Control.Concurrent.SCC.Combinators ( Control/Concurrent/SCC/Combinators.hs, interpreted ) [4 of 8] Compiling Control.Concurrent.SCC.Primitives ( Control/Concurrent/SCC/Primitives.hs, interpreted ) [5 of 8] Compiling Control.Concurrent.SCC.XML ( Control/Concurrent/SCC/XML.hs, interpreted ) [6 of 8] Compiling Control.Concurrent.Configuration ( Control/Concurrent/Configuration.hs, interpreted ) [7 of 8] Compiling Control.Concurrent.SCC.Components ( Control/Concurrent/SCC/Components.hs, interpreted ) [8 of 8] Compiling Main ( Test.hs, interpreted ) Ok, modules loaded: Main, Control.Concurrent.Configuration, Control.Concurrent.SCC.Trampoline, Control.Concurrent.SCC.Types, Control.Concurrent.SCC.Combinators, Control.Concurrent.SCC.Components, Control.Concurrent.SCC.XML, Control.Concurrent.SCC.Primitives. *Main> main Loading package syb-0.1.0.2 ... linking ... done. Loading package base-3.0.3.2 ... linking ... done. Loading package old-locale-1.0.0.2 ... linking ... done. Loading package time-1.1.4 ... linking ... done. Loading package random-1.0.0.2 ... linking ... done. Loading package QuickCheck-1.2.0.0 ... linking ... done. Loading package array-0.3.0.0 ... linking ... done. Loading package containers-0.3.0.0 ... linking ... done. Loading package mtl-1.1.0.2 ... linking ... done. Loading package parallel-1.1.0.1 ... linking ... done. ghc: panic! (the 'impossible' happened) (GHC version 6.12.1 for x86_64-unknown-linux): nameModule ds_d1YX{v} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I'll attach the modified module. It still contains lots of irrelevant code, but it should be easy to trim. To reproduce the GHCi panic, you'll need to get the current code from the Darcs repository at [http://code.haskell.org/SCC/] and then replace the Control.Concurrent.SCC.Trampoline module by the attached one. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 31 15:40:47 2009 From: trac at galois.com (GHC) Date: Thu Dec 31 15:14:01 2009 Subject: [GHC] #3797: ByteString.Char8 damages Unicode Message-ID: <046.181f8c3baab659fe9dc59c0689c9d291@localhost> #3797: ByteString.Char8 damages Unicode ---------------------------------+------------------------------------------ Reporter: Voker57 | Owner: Type: bug | Status: new Priority: normal | Component: libraries (other) Version: | Keywords: bytestring Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Other ---------------------------------+------------------------------------------ {{{ import Data.Bytestring.Char8 unpack (pack "????") == "????" -- False, should be True Data.ByteString.Char8.length $ pack "????" -- 4, should be 8 (UTF-8). Library truncates more-than-8bit chars }}} I'm not sure if this library should assume UTF-8 for {en,de}coding, but imho something has to be done about it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 31 17:10:01 2009 From: trac at galois.com (GHC) Date: Thu Dec 31 16:43:13 2009 Subject: [GHC] #3797: ByteString.Char8 damages Unicode In-Reply-To: <046.181f8c3baab659fe9dc59c0689c9d291@localhost> References: <046.181f8c3baab659fe9dc59c0689c9d291@localhost> Message-ID: <055.ee84136fb188f912e3bf45a296055264@localhost> #3797: ByteString.Char8 damages Unicode --------------------------------+------------------------------------------- Reporter: Voker57 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries (other) | Version: Resolution: invalid | Keywords: bytestring Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Other | --------------------------------+------------------------------------------- Changes (by dons): * status: new => closed * difficulty: => * resolution: => invalid Comment: This is the expected behaviour, and documented. Bytestrings when packing will truncate the input to 8 bits. If you require a specific encoding, pre-process the string first with e.g. utf8-string or else use the unicode bytestring package: Data.Text. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 31 18:41:49 2009 From: trac at galois.com (GHC) Date: Thu Dec 31 18:15:01 2009 Subject: [GHC] #3731: SYB gone wild - mysterious <> in code derived from an syb-with-class example In-Reply-To: <042.4958fc1cdd70e26a14593e01de97e65e@localhost> References: <042.4958fc1cdd70e26a14593e01de97e65e@localhost> Message-ID: <051.92084801c83a996d88f3b4d27a1ef392@localhost> #3731: SYB gone wild - mysterious <> in code derived from an syb-with-class example ------------------------------------------+--------------------------------- Reporter: dsf | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.12.1 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Incorrect result at runtime | ------------------------------------------+--------------------------------- Comment (by dsf): We are looking into the feasability of using HEAD - we need to build about 125 packages with it. We just managed this with 6.12.1 today, so I will try to take the next step. Any idea when that fix went in? An older snapshot may be an easier step than the latest. -- Ticket URL: GHC The Glasgow Haskell Compiler