From trac at galois.com Tue Jul 1 02:11:04 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 02:02:17 2008 Subject: [GHC] #2399: Template Haskell: support for view patterns In-Reply-To: <043.ea0fa95d3ba4304244b4038504ec46d3@localhost> References: <043.ea0fa95d3ba4304244b4038504ec46d3@localhost> Message-ID: <052.92ff29a41683f9e94e29c8283b077aac@localhost> #2399: Template Haskell: support for view patterns ------------------------------+--------------------------------------------- Reporter: fons | Owner: Type: feature request | Status: new Priority: low | Milestone: _|_ Component: Template Haskell | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ------------------------------+--------------------------------------------- Comment (by AudreyTang): Simon, it's difficult to add a guard there, because a QuasiQuoter accepts the pattern-generation function of the form: {{{ quoteExprPat :: String -> TH.PatQ }}} But in TH, Guard is part of Body, so a quasiquoter designated to the PatQ side cannot affect the BodyQ side. As there seems to be no other Pat constructors that's useful for a [$rx|...|] at the pattern side, would you consider accepting a patch that adds ViewP for 6.10? Cheers, Audrey (The context for [$rx|...|] is http://hackage.haskell.org/cgi-bin/hackage- scripts/package/regexqq btw.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 02:11:17 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 02:02:29 2008 Subject: [GHC] #2399: Template Haskell: support for view patterns In-Reply-To: <043.ea0fa95d3ba4304244b4038504ec46d3@localhost> References: <043.ea0fa95d3ba4304244b4038504ec46d3@localhost> Message-ID: <052.0edc688b89c97652c0c0c0aa781ae7d0@localhost> #2399: Template Haskell: support for view patterns ------------------------------+--------------------------------------------- Reporter: fons | Owner: Type: feature request | Status: new Priority: low | Milestone: _|_ Component: Template Haskell | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ------------------------------+--------------------------------------------- Changes (by AudreyTang): * cc: audreyt@audreyt.org (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 04:10:34 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 04:01:52 2008 Subject: [GHC] #2355: Building NDP fails with GHC panic on x86_64 In-Reply-To: <045.b11d6fc22a2344e33956c4877e3aa5f7@localhost> References: <045.b11d6fc22a2344e33956c4877e3aa5f7@localhost> Message-ID: <054.5e0719adca76c08a41b34ac9fef3718a@localhost> #2355: Building NDP fails with GHC panic on x86_64 ---------------------------+------------------------------------------------ Reporter: Nolari | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: major | Resolution: fixed Keywords: ndp ghc panic | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ---------------------------+------------------------------------------------ Changes (by rl): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 04:54:15 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 04:45:39 2008 Subject: [GHC] #955: more object-code blow-up in ghc-6.8.3 vs. ghc-6.4.2 (both with optimization) In-Reply-To: <052.784670e095eb0d591995e903dae303b2@localhost> References: <052.784670e095eb0d591995e903dae303b2@localhost> Message-ID: <061.9d20c783abc86fb542847971e1b7336c@localhost> #955: more object-code blow-up in ghc-6.8.3 vs. ghc-6.4.2 (both with optimization) --------------------------------------+------------------------------------- Reporter: maeder@tzi.de | Owner: Type: run-time performance bug | Status: reopened Priority: high | Milestone: 6.8.3 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: object-code blow-up | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | --------------------------------------+------------------------------------- Changes (by maeder): * status: closed => reopened * version: 6.6 => 6.8.3 * resolution: fixed => * summary: more object-code blow-up in ghc-6.6 vs. ghc-6.4.2 (both with optimization) => more object-code blow-up in ghc-6.8.3 vs. ghc-6.4.2 (both with optimization) Comment: Rerunning the above example using ghc-6.8.3 the object file ATC2.o has now 3.5 MB instead of 1.3 MB for ghc-6.8.2 {{{ maeder@leibniz:/local/maeder/atc> ls -sh1 total 13M 308K ATC.hi 88K ATC.hs 1.3M ATC.o 144K ATC2.hi 16K ATC2.hs 16K ATC2.hs~ 3.5M ATC2.o 7.1M ATC3 8.0K ATC3.hi 4.0K ATC3.hs 4.0K ATC3.o 4.0K Common 4.0K Makefile 4.0K Makefile~ 12K atc.2.tgz 4.0K programatica }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 06:52:52 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 06:44:06 2008 Subject: [GHC] #2399: Template Haskell: support for view patterns In-Reply-To: <043.ea0fa95d3ba4304244b4038504ec46d3@localhost> References: <043.ea0fa95d3ba4304244b4038504ec46d3@localhost> Message-ID: <052.c760e469ab6f97b5a69a5bb726dcc86c@localhost> #2399: Template Haskell: support for view patterns ------------------------------+--------------------------------------------- Reporter: fons | Owner: Type: feature request | Status: new Priority: low | Milestone: _|_ Component: Template Haskell | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ------------------------------+--------------------------------------------- Comment (by simonpj): Ah I see. I'd missed the quasiquoter connnection. One way to fix this would be to add view patterns to TH. But it made me wonder: why aren't pattern guards compositional? At the moment they are resolutely top-level. And, as you say, not part of patterns. But syntax aside it would make perfect sense to make them part of a pattern: {{{ pat ::= var | C pat1 ... patn | pat|quals }}} where `qual` is a pattern-guard "qualifier". So (again, syntax aside) you could write {{{ f (x | x>3) = ... g ([y] | Just z <- lookup y) = ... }}} That would push pattern guards into the syntax of patterns. Now view patterns are syntactic sugar: {{{ (exp -> pat) means (x | pat <- exp x) where x is fresh }}} The reverse encoding is also possible {{{ (pat | quals) means (f -> Just (v1,...,vn)) where (v1,...,vn) are the variables bound by pat f pat | quals = Just vs }}} I'm not sure I'm advocating this (yet!), but I hadn't thought of it before so I thought I'd jot it down. If TH users agree about just how to beef up patterns, I'm not against adding it. I'm just a bit conscious that view patterns are experimental and the more concrete we pour the harder it becomes to change. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 07:55:16 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 07:46:38 2008 Subject: [GHC] #955: more object-code blow-up in ghc-6.8.3 vs. ghc-6.4.2 (both with optimization) In-Reply-To: <052.784670e095eb0d591995e903dae303b2@localhost> References: <052.784670e095eb0d591995e903dae303b2@localhost> Message-ID: <061.c78d18e882b8ede3b637aba214894720@localhost> #955: more object-code blow-up in ghc-6.8.3 vs. ghc-6.4.2 (both with optimization) --------------------------------------+------------------------------------- Reporter: maeder@tzi.de | Owner: Type: run-time performance bug | Status: reopened Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: object-code blow-up | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | --------------------------------------+------------------------------------- Changes (by igloo): * milestone: 6.8.3 => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 08:27:35 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 08:18:46 2008 Subject: [GHC] #2378: panic: lookupVers1, when standalone deriving Typeable and Data In-Reply-To: <044.817cb3c6a4bf0ec145ce20c20c5af470@localhost> References: <044.817cb3c6a4bf0ec145ce20c20c5af470@localhost> Message-ID: <053.032f661232b1c24763c698eeba4b00d2@localhost> #2378: panic: lookupVers1, when standalone deriving Typeable and Data ----------------------+----------------------------------------------------- Reporter: guest | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Comment (by simonpj): Nice program. You revealed at least three bugs in the implementation of standalone deriving, and that's without counting the `lookupVers1` problem, which doesn't show up in HEAD. So I've fixed all of them in the HEAD. Since we've pushed 6.8.3 out now, we've missed the boat on that. If we ever release 6.8.4 we should put the patch in: {{{ Tue Jul 1 13:09:08 BST 2008 simonpj@microsoft.com * Several fixes to 'deriving' including Trac #2378 }}} There's no good workaround for 6.8.3 except not to use standalone deriving. Also doing this: {{{ newtype T f = ... deriving( Typeable1 ) }}} seems unfixably broken in 6.8.3 I'm afraid. I think you may have to use a data type instead. Thanks for bringing all this to light. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 08:36:19 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 08:27:29 2008 Subject: [GHC] #2378: panic: lookupVers1, when standalone deriving Typeable and Data In-Reply-To: <044.817cb3c6a4bf0ec145ce20c20c5af470@localhost> References: <044.817cb3c6a4bf0ec145ce20c20c5af470@localhost> Message-ID: <053.0563ecd14850e899882db6c0b7247091@localhost> #2378: panic: lookupVers1, when standalone deriving Typeable and Data -------------------------------------------+-------------------------------- Reporter: guest | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: deriving/should_compile/T2378 | Architecture: x86 Os: MacOS X | -------------------------------------------+-------------------------------- Changes (by simonpj): * testcase: => deriving/should_compile/T2378 * owner: simonpj => igloo * type: bug => merge Comment: Added a test for the newtype deriving thing. I was wrong above: the thing that is broken is standalone deriving for `Typeable1` of newtype: {{{ newtype T a = ... deriving instance Typeable1 T }}} Also reclassifying as 'merge' so that Ian can keep it on his merge list for 6.8.4 Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 09:52:08 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 09:43:21 2008 Subject: [GHC] #2307: Poor warning for conflicting functional dependencies In-Reply-To: <051.74da8f65a0dfd1e30516012444a9f297@localhost> References: <051.74da8f65a0dfd1e30516012444a9f297@localhost> Message-ID: <060.c79495b005ec4735516c2f46c577fac6@localhost> #2307: Poor warning for conflicting functional dependencies --------------------------+------------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------+------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch Comment: Thanks for the report! Here is a minimal testcase: {{{ {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies, OverlappingInstances, UndecidableInstances, IncoherentInstances, FlexibleInstances #-} module Foo where class C a b c | a -> b, a -> c instance C Int (Maybe String) Float instance C Int (Maybe Bool) Double }}} With the HEAD: {{{ Proof_default.hs:8:0: Functional dependencies conflict between instance declarations: instance [incoherent] C Int (Maybe String) Float -- Defined at Proof_default.hs:8:0-34 instance [incoherent] C Int (Maybe Bool) Double -- Defined at Proof_default.hs:9:0-35 instance [incoherent] C Int (Maybe Bool) Double -- Defined at Proof_default.hs:9:0-35 }}} Before just nubbing the instances, we should make sure that it's not a bug that it is finding the same one multiple times in the first place. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 11:27:57 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 11:19:06 2008 Subject: [GHC] #2409: Error: symbol `ghczmprim_GHCziUnit_Z0T_closure' is already defined Message-ID: <044.7dae041a5daf9b581d3da7c20ea58977@localhost> #2409: Error: symbol `ghczmprim_GHCziUnit_Z0T_closure' is already defined -------------------------+-------------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- This module: {{{ module Foo where f :: Int -> Int f _ | () `seq` False = undefined | otherwise = error "XXX" g :: Int -> Int g _ | () `seq` False = undefined | otherwise = error "XXX" }}} doesn't compile with 6.8.3 or the HEAD; here's what happens with the HEAD (compiled with -DDEBUG, but I'm pretty sure it wouldn't work anyway): {{{ $ ghc -fforce-recomp -c Foo.hs ghc-6.9.20080701: panic! (the 'impossible' happened) (GHC version 6.9.20080701 for x86_64-unknown-linux): ASSERT failed! file stgSyn/CoreToStg.lhs line 922 (){v 71} [lid] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug $ ghc -fforce-recomp -c Foo.hs -O /tmp/ghc4665_0/ghc4665_0.s: Assembler messages: /tmp/ghc4665_0/ghc4665_0.s:95:0: Error: symbol `ghczmprim_GHCziUnit_Z0T_closure' is already defined }}} The original problem report, using Takusen, is here: http://www.haskell.org/pipermail/glasgow-haskell- users/2008-June/015037.html -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 12:27:58 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 12:19:13 2008 Subject: [GHC] #2410: HEAD build fails when building way=p with WAY_p_OPTS='-prof -caf-all -auto-all' Message-ID: <045.6d20356736e6fa3c22e35dd97141b722@localhost> #2410: HEAD build fails when building way=p with WAY_p_OPTS='-prof -caf-all -auto- all' -----------------------+---------------------------------------------------- Reporter: pgavin | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: MacOS X -----------------------+---------------------------------------------------- Specifically, the failure happens while compiling libraries/base/Data/Complex.hs: ------ compiler output -------- /Users/pgavin/local/ghc-6.9/src/ghc-6.9/compiler/stage1/ghc-inplace -package-name base-3.0 -hide-all-packages -split-objs -i -idist/build -i. -idist/build/autogen -Idist/build -Iinclude -#include "HsBase.h" -odir dist/build -hidir dist/build -stubdir dist/build -package ghc-prim-0.1 -package integer-0.1 -package rts-1.0 -O -package-name base -XMagicHash -XExistentialQuantification -XRank2Types -XScopedTypeVariables -XUnboxedTuples -XForeignFunctionInterface -XUnliftedFFITypes -XDeriveDataTypeable -XGeneralizedNewtypeDeriving -XFlexibleInstances -XPatternSignatures -XStandaloneDeriving -XPatternGuards -XCPP -idist/build -prof -caf-all -auto-all -hisuf p_hi -hcsuf p_hc -osuf p_o -H32m -O -H32m -O2 -O2 -Rghc-timing -XGenerics -O2 -Wall -fno-warn- deprecated-flags -w -c Data/Complex.hs -o dist/build/Data/Complex.p_o -ohi dist/build/Data/Complex.p_hi /var/folders/o2/o2fca1ekG9SKEu61XaHsjE+++TI/-Tmp-/ghc51695_0/ghc51695_0.split__108.s:1256:0: FATAL:Symbol _base_DataziComplex_zeze_CAF_cc_ccs already defined. ------------------------------- Compilation succeeds if the SPECIALIZE pragmas are removed from the instance declarations for Num, Fractional, and Floating. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 12:36:14 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 12:27:24 2008 Subject: [GHC] #2366: ASSERT failed! file typecheck/TcMType.lhs line 517 In-Reply-To: <053.ab23f29da9729b185efbfb211d6ff539@localhost> References: <053.ab23f29da9729b185efbfb211d6ff539@localhost> Message-ID: <062.ffdbcf99f88f656d3ae17cc42989f40c@localhost> #2366: ASSERT failed! file typecheck/TcMType.lhs line 517 ----------------------------+----------------------------------------------- Reporter: batterseapower | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: gadt/equal | Architecture: Unknown Os: Multiple | ----------------------------+----------------------------------------------- Changes (by igloo): * difficulty: => Unknown * os: MacOS X => Multiple * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 12:37:02 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 12:28:11 2008 Subject: [GHC] #2366: ASSERT failed! file typecheck/TcMType.lhs line 517 In-Reply-To: <053.ab23f29da9729b185efbfb211d6ff539@localhost> References: <053.ab23f29da9729b185efbfb211d6ff539@localhost> Message-ID: <062.f880df31e9df46e7cae2e43cf1f9eabf@localhost> #2366: ASSERT failed! file typecheck/TcMType.lhs line 517 ----------------------------+----------------------------------------------- Reporter: batterseapower | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: gadt/equal | Architecture: Unknown Os: Multiple | ----------------------------+----------------------------------------------- Comment (by igloo): This is reproducible with `./validate --slow`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 12:37:05 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 12:28:15 2008 Subject: [GHC] #2368: ASSERT failed! file coreSyn/CorePrep.lhs line 669 In-Reply-To: <053.ce70667c924b83874db7013d3e3aa9b8@localhost> References: <053.ce70667c924b83874db7013d3e3aa9b8@localhost> Message-ID: <062.ff01fc93c752926d6e3131002d13b8b2@localhost> #2368: ASSERT failed! file coreSyn/CorePrep.lhs line 669 -----------------------------------------------+---------------------------- Reporter: batterseapower | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: simplCore/should_compile/simpl014 | Architecture: Unknown Os: MacOS X | -----------------------------------------------+---------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.1 Comment: This is reproducible with `./validate --slow`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 12:37:48 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 12:28:57 2008 Subject: [GHC] #2367: ASSERT failed! file basicTypes/MkId.lhs line 643 In-Reply-To: <053.3399b2ac3a6fdeb953db1e5f9a9f109a@localhost> References: <053.3399b2ac3a6fdeb953db1e5f9a9f109a@localhost> Message-ID: <062.d43d0b623ccdddfa7597d81d16fe9412@localhost> #2367: ASSERT failed! file basicTypes/MkId.lhs line 643 ----------------------------+----------------------------------------------- Reporter: batterseapower | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: gadt/records | Architecture: Unknown Os: MacOS X | ----------------------------+----------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.1 Comment: I can't reproduce this with `./validate --slow`; did someone fix it? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 12:42:12 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 12:33:21 2008 Subject: [GHC] #2409: Error: symbol `ghczmprim_GHCziUnit_Z0T_closure' is already defined In-Reply-To: <044.7dae041a5daf9b581d3da7c20ea58977@localhost> References: <044.7dae041a5daf9b581d3da7c20ea58977@localhost> Message-ID: <053.d5593285190a1d46806cdca1fbad813c@localhost> #2409: Error: symbol `ghczmprim_GHCziUnit_Z0T_closure' is already defined ------------------------------------------+--------------------------------- Reporter: igloo | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: deSugar/should_compile/T2409 | Architecture: Unknown Os: Unknown | ------------------------------------------+--------------------------------- Changes (by simonpj): * testcase: => deSugar/should_compile/T2409 * status: new => closed * resolution: => fixed Comment: Urgle. That's my fault. Fixed by {{{ Tue Jul 1 17:37:22 BST 2008 simonpj@microsoft.com * Easy fix for Trac #2409 }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 13:00:09 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 12:51:24 2008 Subject: [GHC] #2307: Poor warning for conflicting functional dependencies In-Reply-To: <051.74da8f65a0dfd1e30516012444a9f297@localhost> References: <051.74da8f65a0dfd1e30516012444a9f297@localhost> Message-ID: <060.1050106d655fd650acef08d023c10b77@localhost> #2307: Poor warning for conflicting functional dependencies -----------------------------------------+---------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: typecheck/should_fail/T2307 | Architecture: Unknown Os: Unknown | -----------------------------------------+---------------------------------- Changes (by simonpj): * testcase: => typecheck/should_fail/T2307 * status: new => closed * resolution: => fixed Comment: Excellent, thanks for refining the test case. That made it easy. In fact, nubbing is the right thing, because `FunDeps.badFunDeps` looks through the fundeps one by one; in this case there are two, and the same instance conflicts with both. Fixed by {{{ Tue Jul 1 17:58:30 BST 2008 simonpj@microsoft.com * Fix Trac #2307: need to nub bad fundep reports }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 13:51:35 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 13:42:44 2008 Subject: [GHC] #2376: GHC.Word: shiftR and shiftL are not marked as inline. In-Reply-To: <044.1d775a18fce526f6afc014f2bd5a4272@localhost> References: <044.1d775a18fce526f6afc014f2bd5a4272@localhost> Message-ID: <053.59cf79a7196dd7d98bce89f421e50c1a@localhost> #2376: GHC.Word: shiftR and shiftL are not marked as inline. ----------------------------------+----------------------------------------- Reporter: mjark | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: Keywords: inline shiftR shiftL | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------------+----------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.1 Comment: Thanks for the report -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 13:53:23 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 13:44:34 2008 Subject: [GHC] #2373: Build fails to pass locations of external tools to libraries In-Reply-To: <042.251f9ace7edb49f0e772cf590973862b@localhost> References: <042.251f9ace7edb49f0e772cf590973862b@localhost> Message-ID: <051.f137deb63afc37e75e2324a22350118f@localhost> #2373: Build fails to pass locations of external tools to libraries ----------------------+----------------------------------------------------- Reporter: bos | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * owner: => igloo * difficulty: => Unknown * milestone: => 6.10.1 Comment: Agreed; thanks for the report -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 14:05:20 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 13:56:29 2008 Subject: [GHC] #2369: tcrun007: Can't find interface-file declaration for variable .... In-Reply-To: <053.4d3797d81d5c149bb343005d923746dd@localhost> References: <053.4d3797d81d5c149bb343005d923746dd@localhost> Message-ID: <062.6db05407f34e49017a80aea689e535dd@localhost> #2369: tcrun007: Can't find interface-file declaration for variable .... ---------------------------------------------+------------------------------ Reporter: batterseapower | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: typechecker/should_run/tcrun007 | Architecture: Unknown Os: Unknown | ---------------------------------------------+------------------------------ Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: That's expected; the devel2 build settings don't build the libraries with `-XGenerics`, which this test relies upon. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 15:04:18 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 14:55:30 2008 Subject: [GHC] #2307: Poor warning for conflicting functional dependencies In-Reply-To: <051.74da8f65a0dfd1e30516012444a9f297@localhost> References: <051.74da8f65a0dfd1e30516012444a9f297@localhost> Message-ID: <060.bf39eed87f001e8268a40cb4ff6ebb4a@localhost> #2307: Poor warning for conflicting functional dependencies -----------------------------------------+---------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: reopened Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: typecheck/should_fail/T2307 | Architecture: Unknown Os: Unknown | -----------------------------------------+---------------------------------- Changes (by igloo): * status: closed => reopened * resolution: fixed => * milestone: 6.10 branch => 6.10.1 Comment: The behaviour when the types in the instances were changed felt a little odd to me, so I had a quick look at the code, and I think it's broken; e.g. this module: {{{ {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies, OverlappingInstances, UndecidableInstances, IncoherentInstances, FlexibleInstances #-} module Foo where class C a b c | b -> c instance C Bool Int Float instance C Char Int Double }}} is accepted by GHC, but violates `b -> c`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 15:25:59 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 15:17:28 2008 Subject: [GHC] #2411: RaiseAsync and STM segfault with stop_at_atomically in some circumstances. Message-ID: <043.63306a2cc0e922a8f292cc5cebf4f918@localhost> #2411: RaiseAsync and STM segfault with stop_at_atomically in some circumstances. ------------------------+--------------------------------------------------- Reporter: sclv | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- x86_64 6.9 build from June 15. I can't distill it down to a single simple testcase, but the backtrace is very informative: ASSERTION FAILED: file RaiseAsync.c, line 1015 The assertion in question is "ASSERT(stmGetEnclosingTRec(tso->trec) == NO_TREC)". This assertion is only called when we hit an ATOMICALLY_FRAME with stop_at_atomically activated. We only do that when Schedule.c is running the garbage collector and raises an exception to retry an invalid stm transaction. I don't follow enough here to offer a real patch, but obviously there is a false assumption that the transaction we're trying to retry does not have an enclosing trec. Why this may be the case is somewhat beyond me. I'm doing various things with unsafeIOToSTM, so I think the answer may be that there is some sort of forking going on with threaded IO which means that threads may have enclosing trecs. {{{ #0 0x00002b134fdb9b45 in raise () from /lib64/libc.so.6 #1 0x00002b134fdbb0e0 in abort () from /lib64/libc.so.6 #2 0x00000000009b40e0 in rtsFatalInternalErrorFn (s=0xa2c670 "ASSERTION FAILED: file %s, line %u\n", ap=0x41000e50) at RtsMessages.c:164 #3 0x00000000009b3ca4 in barf (s=0xa2c670 "ASSERTION FAILED: file %s, line %u\n") at RtsMessages.c:40 #4 0x00000000009b3cfe in _assertFail (filename=0xa3200c "RaiseAsync.c", linenum=1015) at RtsMessages.c:55 #5 0x00000000009e4675 in raiseAsync (cap=0xd734a0, tso=0x2b1351bdb000, exception=0x0, stop_at_atomically=rtsTrue, stop_here=0x0) at RaiseAsync.c:1015 #6 0x00000000009e365b in throwToSingleThreaded_ (cap=0xd734a0, tso=0x2b1351bdb000, exception=0x0, ---Type to continue, or q to quit--- stop_at_atomically=rtsTrue, stop_here=0x0) at RaiseAsync.c:73 #7 0x00000000009b6b51 in scheduleDoGC (cap=0xd734a0, task=0xd8e750, force_major=rtsFalse) at Schedule.c:2046 #8 0x00000000009b5a9d in schedule (initialCapability=0xd734a0, task=0xd8e750) at Schedule.c:718 #9 0x00000000009b77db in workerStart (task=0xd8e750) at Schedule.c:2537 #10 0x00002b134fb73020 in start_thread () from /lib64/libpthread.so.0 #11 0x00002b134fe4df8d in clone () from /lib64/libc.so.6 #12 0x0000000000000000 in ?? () }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 15:48:04 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 15:39:15 2008 Subject: [GHC] #2379: ghc-6.9.20080614: panic! (the 'impossible' happened) In-Reply-To: <045.86b9b930b3ded50e36018e43dce2d355@localhost> References: <045.86b9b930b3ded50e36018e43dce2d355@localhost> Message-ID: <054.b106f09132f33302f1783a5136e7f61d@localhost> #2379: ghc-6.9.20080614: panic! (the 'impossible' happened) ----------------------+----------------------------------------------------- Reporter: megacz | Owner: Type: bug | Status: new Priority: low | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by igloo): * priority: normal => low * milestone: => 6.10.1 Old description: > [ 7 of 78] Compiling Data.Array.Parallel.Base.Rebox ( > Data/Array/Parallel/Base/Rebox.hs, > dist/build/Data/Array/Parallel/Base/Rebox.o ) > ghc-6.9.20080614: panic! (the 'impossible' happened) > (GHC version 6.9.20080614 for i386-apple-darwin): > initC: srt_lbl > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > < samples), 11M in use, 0.00 INIT (0.00 elapsed), 0.17 MUT (1.05 elapsed), > 0.08 GC (0.09 elapsed) :ghc>> New description: {{{ [ 7 of 78] Compiling Data.Array.Parallel.Base.Rebox ( Data/Array/Parallel/Base/Rebox.hs, dist/build/Data/Array/Parallel/Base/Rebox.o ) ghc-6.9.20080614: panic! (the 'impossible' happened) (GHC version 6.9.20080614 for i386-apple-darwin): initC: srt_lbl Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug <> }}} Comment: And if it is still broken for you, can you please attach the source code you were trying to compile and tell us what the commandline was? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 15:49:29 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 15:40:45 2008 Subject: [GHC] #2380: Adjustor.o crash compiling ghc 6.8.3 on iBook G4 10.4.11 In-Reply-To: <045.f144b092f23e8db9c081050578f2b103@localhost> References: <045.f144b092f23e8db9c081050578f2b103@localhost> Message-ID: <054.67ae7513de97f367e976fb1b0cb6606e@localhost> #2380: Adjustor.o crash compiling ghc 6.8.3 on iBook G4 10.4.11 --------------------------+------------------------------------------------- Reporter: povman | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Build System | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | --------------------------+------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 15:50:43 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 15:42:04 2008 Subject: [GHC] #2383: hsc2hs puts -F on call to ghc In-Reply-To: <045.232f26bacbe72f9746a671f222e80879@localhost> References: <045.232f26bacbe72f9746a671f222e80879@localhost> Message-ID: <054.ea2ab8613d8689f75b1c644a967c2212@localhost> #2383: hsc2hs puts -F on call to ghc ---------------------+------------------------------------------------------ Reporter: povman | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: hsc2hs | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: MacOS X | ---------------------+------------------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 15:54:30 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 15:45:39 2008 Subject: [GHC] #2386: Splicing in constructors that are abstract from the point of view of the splice point is unreliable In-Reply-To: <053.8442170ef9b4829325987986f707598b@localhost> References: <053.8442170ef9b4829325987986f707598b@localhost> Message-ID: <062.6292f1ce06dec8ae136d74bfab59f3eb@localhost> #2386: Splicing in constructors that are abstract from the point of view of the splice point is unreliable ------------------------------+--------------------------------------------- Reporter: batterseapower | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Template Haskell | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: MacOS X | ------------------------------+--------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 15:57:31 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 15:48:41 2008 Subject: [GHC] #2349: SIZET_FMT in includes/mkDerivedConstants.c needs to be "d" under older Solaris version In-Reply-To: <045.bc3bbec7f28e57f84d533f6eb759f26c@localhost> References: <045.bc3bbec7f28e57f84d533f6eb759f26c@localhost> Message-ID: <054.376500dd3d6f41acf24dd84542032a80@localhost> #2349: SIZET_FMT in includes/mkDerivedConstants.c needs to be "d" under older Solaris version ----------------------+----------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: sparc Os: Solaris | ----------------------+----------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 15:58:10 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 15:49:23 2008 Subject: [GHC] #2383: hsc2hs puts -F on call to ghc In-Reply-To: <045.232f26bacbe72f9746a671f222e80879@localhost> References: <045.232f26bacbe72f9746a671f222e80879@localhost> Message-ID: <054.5d32eec9537201c97dba4fd3514baa03@localhost> #2383: hsc2hs puts -F on call to ghc ---------------------+------------------------------------------------------ Reporter: povman | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: hsc2hs | Version: 6.8.2 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: MacOS X | ---------------------+------------------------------------------------------ Changes (by ross): * status: new => closed * resolution: => invalid Comment: As Christian has said, this was never in the mainline. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 16:13:59 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 16:05:30 2008 Subject: [GHC] #2352: POSIX.1 unsetenv returns int In-Reply-To: <043.9a1a67d0fcfde818f197866387595049@localhost> References: <043.9a1a67d0fcfde818f197866387595049@localhost> Message-ID: <052.7008a86509e98fb780eb71e19c7bb0a7@localhost> #2352: POSIX.1 unsetenv returns int ----------------------------+----------------------------------------------- Reporter: donn | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: libraries/unix | Version: 6.8.2 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: NetBSD | ----------------------------+----------------------------------------------- Changes (by igloo): * owner: => igloo * difficulty: => Unknown * milestone: => 6.10.1 Old description: > While plenty of C libraries declare void unsetenv(), the POSIX.1003.1 > standard is int unsetenv(), with return values 0 or -1. In the latter > case, errno is set to EINVAL, for causes including the present of "=" in > the value. Of course this is not of earthshaking importance. > > The following is the autoconf test (just a copy of the same test for > usleep().) > > --- libraries/unix/configure.ac.dist 2008-06-03 10:39:45.000000000 > -0700 > +++ libraries/unix/configure.ac 2008-06-06 21:43:19.000000000 -0700 > @@ -75,6 +75,19 @@ > ;; > esac > > +### POSIX.1003.1 unsetenv returns 0 or -1 (EINVAL), but older > implementations > +### in common use return void. > +AC_CACHE_CHECK([return type of unsetenv], cv_func_unsetenv_return_type, > + [AC_EGREP_HEADER(changequote(<, >) ]+unsetenv>changequote([, ]), > + /usr/include/stdlib.h, > + [cv_func_unsetenv_return_type=void], > + [cv_func_unsetenv_return_type=int])]) > +case "$cv_func_unsetenv_return_type" in > + "void" ) > + AC_DEFINE([UNSETENV_RETURNS_VOID], [1], [Define if stdlib.h declares > unsetenv to return void.]) > + ;; > +esac > + > dnl ** sometimes RTLD_NEXT is hidden in #ifdefs we really don't wan to > set > AC_MSG_CHECKING(for RTLD_NEXT from dlfcn.h) > AC_EGREP_CPP(yes, New description: While plenty of C libraries declare void unsetenv(), the POSIX.1003.1 standard is int unsetenv(), with return values 0 or -1. In the latter case, errno is set to EINVAL, for causes including the present of "=" in the value. Of course this is not of earthshaking importance. The following is the autoconf test (just a copy of the same test for usleep().) {{{ --- libraries/unix/configure.ac.dist 2008-06-03 10:39:45.000000000 -0700 +++ libraries/unix/configure.ac 2008-06-06 21:43:19.000000000 -0700 @@ -75,6 +75,19 @@ ;; esac +### POSIX.1003.1 unsetenv returns 0 or -1 (EINVAL), but older implementations +### in common use return void. +AC_CACHE_CHECK([return type of unsetenv], cv_func_unsetenv_return_type, + [AC_EGREP_HEADER(changequote(<, >)changequote([, ]), + /usr/include/stdlib.h, + [cv_func_unsetenv_return_type=void], + [cv_func_unsetenv_return_type=int])]) +case "$cv_func_unsetenv_return_type" in + "void" ) + AC_DEFINE([UNSETENV_RETURNS_VOID], [1], [Define if stdlib.h declares unsetenv to return void.]) + ;; +esac + dnl ** sometimes RTLD_NEXT is hidden in #ifdefs we really don't wan to set AC_MSG_CHECKING(for RTLD_NEXT from dlfcn.h) AC_EGREP_CPP(yes, }}} Comment: Thanks for the patch, we'll take a look -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 16:14:38 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 16:05:56 2008 Subject: [GHC] #2353: GHC inliner doesn't In-Reply-To: <044.0a130fadcfff13182791f64ebade3181@localhost> References: <044.0a130fadcfff13182791f64ebade3181@localhost> Message-ID: <053.50c46d8ccae6195b38747c2392e3b48a@localhost> #2353: GHC inliner doesn't ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * milestone: => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 16:18:28 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 16:09:44 2008 Subject: [GHC] #2354: NOINLINE pragma ignored In-Reply-To: <044.82d464aa2a8db887c5d15527893ee9e8@localhost> References: <044.82d464aa2a8db887c5d15527893ee9e8@localhost> Message-ID: <053.a6d8c91b562065fed22ae8688e8a6c23@localhost> #2354: NOINLINE pragma ignored ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 16:19:39 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 16:10:56 2008 Subject: [GHC] #2356: GHC accepts multiple instances for the same type in different modules In-Reply-To: <044.2ec6e38cc1bfc912f22d361e9492d9f9@localhost> References: <044.2ec6e38cc1bfc912f22d361e9492d9f9@localhost> Message-ID: <053.6c0b058e853b2e1e9bc987a5009fb999@localhost> #2356: GHC accepts multiple instances for the same type in different modules ----------------------+----------------------------------------------------- Reporter: claus | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * priority: normal => high * difficulty: => Unknown * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From dons at galois.com Tue Jul 1 17:09:04 2008 From: dons at galois.com (Don Stewart) Date: Tue Jul 1 17:00:14 2008 Subject: Missing symbol when loading cbits in ghci Message-ID: <20080701210904.GF8817@liouville.galois.com> Anyone seen this? $ ghci A.hs Prelude Main> main : /home/dons/.cabal/lib/download-0.3/ghc-6.8.2/HSdownload-0.3.o: unknown symbol `stat64' ghc-6.8.2: unable to load package `download-0.3' I can compile and link code against HSdownload just fine, but loading in ghci fails with state64 undefined (a kernel symbol). To reproduce: $ cabal update $ cabal install download $ ghci Prelude> :m + Network.Download Prelude Network.Download> openURI "http://haskell.org" : /home/dons/.cabal/lib/download-0.3/ghc-6.8.2/HSdownload-0.3.o: unknown symbol `stat64' ghc-6.8.2: unable to load package `download-0.3' Is this something that ghci should know about on linux? Or can anyone think of another reason why ghci can't see stat64? -- Don From trac at galois.com Tue Jul 1 20:05:22 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 19:56:32 2008 Subject: [GHC] #2402: ghc fails sans error message. In-Reply-To: <046.ec9278b09c51ceec22610f63a11d7929@localhost> References: <046.ec9278b09c51ceec22610f63a11d7929@localhost> Message-ID: <055.02251f8935f193ed579f9c079728e429@localhost> #2402: ghc fails sans error message. ----------------------+----------------------------------------------------- Reporter: lpsmith | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by igloo): * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 20:19:23 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 20:10:42 2008 Subject: [GHC] #2401: unsafeIOToSTM hangs with 64 bit multicore. In-Reply-To: <043.102536ca2a3e567cb6677ad0a9004c1b@localhost> References: <043.102536ca2a3e567cb6677ad0a9004c1b@localhost> Message-ID: <052.8a93a93e36c5648fa298d3e087a1dc94@localhost> #2401: unsafeIOToSTM hangs with 64 bit multicore. ----------------------------+----------------------------------------------- Reporter: sclv | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Runtime System | Version: 6.8.3 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.1 Comment: Thanks for the report; I don't /think/ that the `unsafeIOToSTM` should be to blame, although I'm not too familiar with STM. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 20:33:08 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 20:24:21 2008 Subject: [GHC] #2398: segfault in cmpLocks on 64 bit multicore In-Reply-To: <043.83483373a348f7384863a195a6f7e5cf@localhost> References: <043.83483373a348f7384863a195a6f7e5cf@localhost> Message-ID: <052.9c955f9d368937452bb244a9680221e1@localhost> #2398: segfault in cmpLocks on 64 bit multicore ----------------------------+----------------------------------------------- Reporter: sclv | Owner: Type: bug | Status: new Priority: low | Milestone: 6.10.1 Component: Runtime System | Version: 6.8.3 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Linux | ----------------------------+----------------------------------------------- Changes (by igloo): * priority: normal => low * difficulty: => Unknown * milestone: => 6.10.1 Comment: I can't reproduce this using the first 351k of my exim `spec.txt` as the file contents, compiling with GHC 6.8.3: {{{ ghc -fforce-recomp --make q -O -threaded }}} and running with just {{{ ./q }}} or {{{ ./q +RTS -N3 }}} on an amd64/Linux machine. I do get a load of {{{ q: foo/984: openFile: resource exhausted (Too many open files) }}} but that is to be expected. It would be useful if you could attach a text file that triggers the problem for you, and give details of how you are compiling and running the program. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 21:21:18 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 21:12:35 2008 Subject: [GHC] #2358: Template Haskell's TupleT considers unary tuples as a valid types. In-Reply-To: <043.f22163bf02ff2ecbb2b6874f8a72bacc@localhost> References: <043.f22163bf02ff2ecbb2b6874f8a72bacc@localhost> Message-ID: <052.2ce4ca1ba97292420a62f17dbf30fa63@localhost> #2358: Template Haskell's TupleT considers unary tuples as a valid types. ------------------------------+--------------------------------------------- Reporter: fons | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.8 branch Component: Template Haskell | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: TH_1tuple | Architecture: Unknown Os: Unknown | ------------------------------+--------------------------------------------- Changes (by igloo): * milestone: => 6.8 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 21:21:37 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 21:12:49 2008 Subject: [GHC] #2378: panic: lookupVers1, when standalone deriving Typeable and Data In-Reply-To: <044.817cb3c6a4bf0ec145ce20c20c5af470@localhost> References: <044.817cb3c6a4bf0ec145ce20c20c5af470@localhost> Message-ID: <053.891c8f974d5a39813575b6ca52093ee9@localhost> #2378: panic: lookupVers1, when standalone deriving Typeable and Data -------------------------------------------+-------------------------------- Reporter: guest | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.8 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: deriving/should_compile/T2378 | Architecture: x86 Os: MacOS X | -------------------------------------------+-------------------------------- Changes (by igloo): * milestone: => 6.8 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 2 01:06:35 2008 From: trac at galois.com (GHC) Date: Wed Jul 2 00:57:46 2008 Subject: [GHC] #2398: segfault in cmpLocks on 64 bit multicore In-Reply-To: <043.83483373a348f7384863a195a6f7e5cf@localhost> References: <043.83483373a348f7384863a195a6f7e5cf@localhost> Message-ID: <052.936e9cd04727a71537d79363fb26b5a5@localhost> #2398: segfault in cmpLocks on 64 bit multicore ----------------------------+----------------------------------------------- Reporter: sclv | Owner: Type: bug | Status: new Priority: low | Milestone: 6.10.1 Component: Runtime System | Version: 6.8.3 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Linux | ----------------------------+----------------------------------------------- Comment (by sclv): {{{ > ghc --make -threaded -O2 -debug testfi.hs > gdb --args ./testfi +RTS -N4 (gdb) run [Lots of text removed] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x43806950 (LWP 1248)] 0x000000000043990c in cmpLocks (w1=531, w2=1132470304) at posix/FileLock.c:35 35 return (l1->device == l2->device && l1->inode == l2->inode); (gdb) bt #0 0x000000000043990c in cmpLocks (w1=531, w2=1132470304) at posix/FileLock.c:35 #1 0x0000000000458166 in lookupHashTable (table=0x6ae110, key=1132470304) at Hash.c:197 #2 0x0000000000439a1d in lockFile (fd=533, dev=2055, ino=10584501, for_writing=0) at posix/FileLock.c:73 #3 0x000000000040597a in s7AW_info () #4 0x0000000600000012 in ?? () #5 0x0000000000405e28 in scJ1_info () #6 0x0000000000405e10 in scJ1_info () #7 0x0000000000444a00 in ?? () #8 0x00002aaaaab15c50 in ?? () #9 0x0000000000405e40 in scJ1_info () #10 0x00002aaaaab15c50 in ?? () #11 0x0000000000000000 in ?? () }}} Again this is on an Intel Core 2 Quad. I'm now running it on a 6.9 snapshot from June 15, by the way, and getting the same result. Note that it seems to happen 75% of the time at least at -N4. At -N3 I'm getting it 25% of the time or so. I'll attach the file I'm using as well, although I doubt that should have much impact on the results. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 2 01:48:39 2008 From: trac at galois.com (GHC) Date: Wed Jul 2 01:39:47 2008 Subject: [GHC] #2398: segfault in cmpLocks on 64 bit multicore In-Reply-To: <043.83483373a348f7384863a195a6f7e5cf@localhost> References: <043.83483373a348f7384863a195a6f7e5cf@localhost> Message-ID: <052.62782d8226048a10df2fe57feb0a5fb9@localhost> #2398: segfault in cmpLocks on 64 bit multicore ----------------------------+----------------------------------------------- Reporter: sclv | Owner: Type: bug | Status: new Priority: low | Milestone: 6.10.1 Component: Runtime System | Version: 6.8.3 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Linux | ----------------------------+----------------------------------------------- Comment (by sclv): Looking through the code, it seems to me that the HashTable used by FileLock.c isn't concurrent/threadsafe, and neither FileLock.c nor the foreign call to it from GHC.Handle serialize access. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 2 07:34:00 2008 From: trac at galois.com (GHC) Date: Wed Jul 2 07:25:13 2008 Subject: [GHC] #2313: libHSrts_thr_debug linked against non-existing bfd library In-Reply-To: <046.369fe8828ff5a3c111568f185c25c8f0@localhost> References: <046.369fe8828ff5a3c111568f185c25c8f0@localhost> Message-ID: <055.c39ac447c0aa589c2bb856f4ab39415e@localhost> #2313: libHSrts_thr_debug linked against non-existing bfd library ----------------------------+----------------------------------------------- Reporter: kgardas | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Runtime System | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Solaris | ----------------------------+----------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => fixed * milestone: => 6.10.1 Old description: > It seems there is a bug in RTS somewhere which makes libHSrts_thr_debug > in a way it's including some symbols from the bfd library. The bug shows > itself as a lot of testsuite tests failing with undefined symbols which > originates in the BFD library. Example: > > =====> cg013(threaded1) > cd ./codeGen/should_run && '/buildbot/ghc/kgardas/build/compiler/stage2 > /ghc-inplace' -no-recomp -dcore-lint -dcmm-lint -Di386_unknown_solaris2 > -o cg013 cg013.hs -threaded -debug >cg013.comp.stderr 2>&1 > Compile failed (status 256) errors were: > Undefined first referenced > symbol in file > bfd_openr > /buildbot/ghc/kgardas/build/rts/libHSrts_thr_debug.a(Printer.thr_debug_o) > bfd_init > /buildbot/ghc/kgardas/build/rts/libHSrts_thr_debug.a(Printer.thr_debug_o) > bfd_check_format_matches > /buildbot/ghc/kgardas/build/rts/libHSrts_thr_debug.a(Printer.thr_debug_o) > ld: fatal: Symbol referencing errors. No output written to cg013 > collect2: ld returned 1 exit status New description: It seems there is a bug in RTS somewhere which makes libHSrts_thr_debug in a way it's including some symbols from the bfd library. The bug shows itself as a lot of testsuite tests failing with undefined symbols which originates in the BFD library. Example: {{{ =====> cg013(threaded1) cd ./codeGen/should_run && '/buildbot/ghc/kgardas/build/compiler/stage2 /ghc-inplace' -no-recomp -dcore-lint -dcmm-lint -Di386_unknown_solaris2 -o cg013 cg013.hs -threaded -debug >cg013.comp.stderr 2>&1 Compile failed (status 256) errors were: Undefined first referenced symbol in file bfd_openr /buildbot/ghc/kgardas/build/rts/libHSrts_thr_debug.a(Printer.thr_debug_o) bfd_init /buildbot/ghc/kgardas/build/rts/libHSrts_thr_debug.a(Printer.thr_debug_o) bfd_check_format_matches /buildbot/ghc/kgardas/build/rts/libHSrts_thr_debug.a(Printer.thr_debug_o) ld: fatal: Symbol referencing errors. No output written to cg013 collect2: ld returned 1 exit status }}} Comment: Patch applied, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 2 07:55:26 2008 From: trac at galois.com (GHC) Date: Wed Jul 2 07:46:47 2008 Subject: [GHC] #955: more object-code blow-up in ghc-6.8.3 vs. ghc-6.4.2 (both with optimization) In-Reply-To: <052.784670e095eb0d591995e903dae303b2@localhost> References: <052.784670e095eb0d591995e903dae303b2@localhost> Message-ID: <061.402b9090b6e72832f55031b2a2efd028@localhost> #955: more object-code blow-up in ghc-6.8.3 vs. ghc-6.4.2 (both with optimization) --------------------------------------+------------------------------------- Reporter: maeder@tzi.de | Owner: Type: run-time performance bug | Status: reopened Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: object-code blow-up | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | --------------------------------------+------------------------------------- Comment (by maeder): changing all instances like the following from {{{ instance (ShATermConvertible c, ShATermConvertible t) => ShATermConvertible (Q c t) where toShATermAux att0 ((:=>) a b) = do (att1, a') <- toShATerm' att0 a (att2, b') <- toShATerm' att1 b return $ addATerm (ShAAppl "(:=>)" [a',b'] []) att2 fromShATermAux ix att0 = case getShATerm ix att0 of ShAAppl "(:=>)" [a,b] _ -> case fromShATerm' a att0 of { (att1, a') -> case fromShATerm' b att1 of { (att2, b') -> (att2, (:=>) a' b') }} u -> fromShATermError "Q" u }}} to {{{ _toShATermAux_Q att0 ((:=>) a b) = do (att1, a') <- toShATerm' att0 a (att2, b') <- toShATerm' att1 b return $ addATerm (ShAAppl "(:=>)" [a',b'] []) att2 _fromShATermAux_Q ix att0 = case getShATerm ix att0 of ShAAppl "(:=>)" [a,b] _ -> case fromShATerm' a att0 of { (att1, a') -> case fromShATerm' b att1 of { (att2, b') -> (att2, (:=>) a' b') }} u -> fromShATermError "Q" u instance (ShATermConvertible c, ShATermConvertible t) => ShATermConvertible (Q c t) where toShATermAux = _toShATermAux_Q fromShATermAux = _fromShATermAux_Q }}} avoids the blow up -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 2 08:37:54 2008 From: trac at galois.com (GHC) Date: Wed Jul 2 08:29:01 2008 Subject: [GHC] #2330: ghc-pkg should not report duplicate depends In-Reply-To: <045.a0d888b36f9d7b158756f697bfe898a1@localhost> References: <045.a0d888b36f9d7b158756f697bfe898a1@localhost> Message-ID: <054.2bcb4a651d2c692c9f9d818a9b59c89e@localhost> #2330: ghc-pkg should not report duplicate depends ----------------------+----------------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by duncan): My guess is to make a ghc-pkg registration file with a duplicate value in the 'depends' field and then register that package. Really it'd be better if it were rejected at registration time. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 2 11:08:16 2008 From: trac at galois.com (GHC) Date: Wed Jul 2 10:59:23 2008 Subject: [GHC] #2412: Interaction between type synonyms and .hs-boot causes panic "tcIfaceGlobal (local): not found" Message-ID: <053.250fd8f3285636d4b0e7d255649c2b44@localhost> #2412: Interaction between type synonyms and .hs-boot causes panic "tcIfaceGlobal (local): not found" -------------------------------+-------------------------------------------- Reporter: batterseapower | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown -------------------------------+-------------------------------------------- To reproduce, create the files: Main.hs: {{{ module Main ( main, Baz ) where import Foo ( Bar ) type Spqr = Bar data Baz = Baz Spqr main = putStrLn "Hello" }}} Main.hs-boot: {{{ module Main where data Baz }}} Foo.hs: {{{ module Foo where import {-# SOURCE #-} Main ( Baz ) type Bar = Baz }}} Then run this command sequence: {{{ $ ghc Main.hs-boot ... $ ghc Foo.hs ... $ ghc Main.hs ghc-6.8.2: panic! (the 'impossible' happened) (GHC version 6.8.2 for i386-apple-darwin): tcIfaceGlobal (local): not found: main:Main.Baz{tc r2T} [] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Note the problem does not seem to manifest itself outside of one-shot mode. The full trace is: {{{ $ ghc Main.hs -ddump-if-trace -ddump-tc-trace FYI: cannot read old interface file: Main.hi: openBinaryFile: does not exist (No such file or directory) Considering whether to load base:Prelude Reading interface for base:Prelude; reason: Prelude is directly imported readIFace /usr/local/lib/ghc-6.8.2/lib/base-3.0.1.0/Prelude.hi updating EPS_ Considering whether to load main:Foo Reading interface for main:Foo; reason: Foo is directly imported readIFace Foo.hi updating EPS_ updating EPS_ Loading orphan modules: base:GHC.Base Considering whether to load base:GHC.Base {- SYSTEM -} Reading interface for base:GHC.Base; reason: base:GHC.Base is a orphan-instance module readIFace /usr/local/lib/ghc-6.8.2/lib/base-3.0.1.0/GHC/Base.hi updating EPS_ loadHiBootInterface main:Main Reading [boot] interface for main:Main; reason: Need the hi-boot interface for main:Main to compare against the Real Thing readIFace Main.hi-boot Finished typechecking interface for main:MainStarting fork { Declaration for Baz Loading decl for Main.Baz updating EPS_ tcIfaceDecl4 Main.Baz } ending fork Declaration for Baz Type envt: [(r2T, Type constructor `Main.Baz')] Main.hs:1:0: Tc2 Main.hs:1:0: tcTyAndCl Main Main.hs:1:0: kcd1 Spqr [[]] [[]] In the type synonym declaration for `Spqr' Main.hs:5:12: lk1 Bar In the type synonym declaration for `Spqr' Main.hs:5:12:Starting fork { Declaration for Bar Loading decl for Foo.Bar updating EPS_ ghc-6.8.2: panic! (the 'impossible' happened) (GHC version 6.8.2 for i386-apple-darwin): tcIfaceGlobal (local): not found: main:Main.Baz{tc r2T} [] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} This happens because when typechecking the type synonym Main.Spqr, kcTyVar calls tcLookup. This causes GHC to pull on the declaration for Foo.Bar. However, this declaration makes use of Main.Baz via a SOURCE import and we haven't yet got around to type checking Main.Baz! Hence tcIfaceGlobal dies, unable to find Baz in the type environment. Note that reversing the order of the declarations of Main.Baz and Main.Spqr doesn't seem to make a difference. I think this is because Baz in turn uses Spqr. I only have limited knowledge of the type checker, but I think a possible fix to this would be to type check the right hand sides of type synonym declarations lazily so we put Main.Baz into the environment before we go off exploring Foo.Bar. We seem to use a trick to deal with a similar type checking interface data constructors? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 2 11:20:26 2008 From: trac at galois.com (GHC) Date: Wed Jul 2 11:11:32 2008 Subject: [GHC] #2412: Interaction between type synonyms and .hs-boot causes panic "tcIfaceGlobal (local): not found" In-Reply-To: <053.250fd8f3285636d4b0e7d255649c2b44@localhost> References: <053.250fd8f3285636d4b0e7d255649c2b44@localhost> Message-ID: <062.a2af27f16229fb6b8360b01c3abdeb23@localhost> #2412: Interaction between type synonyms and .hs-boot causes panic "tcIfaceGlobal (local): not found" -------------------------------+-------------------------------------------- Reporter: batterseapower | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown -------------------------------+-------------------------------------------- Comment (by batterseapower): Actually, I've just confirmed that the synonym Main.Spqr is irrelevant: you can replace the use of it in Main.Baz with Foo.Bar itself and get the same behaviour. A workaround for this bug is to use a newtype rather than a type synonym in Foo. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 2 15:11:37 2008 From: trac at galois.com (GHC) Date: Wed Jul 2 15:02:44 2008 Subject: [GHC] #2413: Segmentation fault in ghc --interactive when run with +RTS -Da Message-ID: <053.7a18e92eaea058983613232db722e65d@localhost> #2413: Segmentation fault in ghc --interactive when run with +RTS -Da -------------------------------+-------------------------------------------- Reporter: batterseapower | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown -------------------------------+-------------------------------------------- This was observed in HEAD as of 02/07/2008. 1. Compile a stage2 GHC with the -debug option on. 2. Run stage2/ghc-inplace --interactive RTS -Da Expected result: GHCi comes up, maybe showing some extra debugging information Actual result: {{{ stg_ap_0_ret... Segmentation fault }}} This has been observed on amd64/Linux and amd64/OSX 10.5. Interestingly, -Da is omitted from the RTS help text. Maybe DebugFlags.apply is known to be broken? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 2 15:43:05 2008 From: trac at galois.com (GHC) Date: Wed Jul 2 15:34:12 2008 Subject: [GHC] #2379: ghc-6.9.20080614: panic! (the 'impossible' happened) In-Reply-To: <045.86b9b930b3ded50e36018e43dce2d355@localhost> References: <045.86b9b930b3ded50e36018e43dce2d355@localhost> Message-ID: <054.dc0d8dbc18490aab799084d663dae58c@localhost> #2379: ghc-6.9.20080614: panic! (the 'impossible' happened) ----------------------+----------------------------------------------------- Reporter: megacz | Owner: Type: bug | Status: closed Priority: low | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by megacz): * status: new => closed * resolution: => wontfix Comment: Sorry about the slow reply. I've tried updating GHC to latest darcs, but now the NDP build fails at an earlier point ("cabal-bin: cabal: Don't know what to do!... Warning: Package is unbuildable"), so I can't tell if it helped or not. So, I guess, close this bug since it can no longer be reproduced. Thanks for your time! - a -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 2 16:16:19 2008 From: trac at galois.com (GHC) Date: Wed Jul 2 16:07:25 2008 Subject: [GHC] #2346: Compilation of large source files requires a lot of RAM In-Reply-To: <046.285595109907aedbac69f385749bac00@localhost> References: <046.285595109907aedbac69f385749bac00@localhost> Message-ID: <055.2e74d3ac507de2d76b8e4ac105c19402@localhost> #2346: Compilation of large source files requires a lot of RAM ------------------------------------------+--------------------------------- Reporter: choener | Owner: Type: compile-time performance bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.8.2 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ------------------------------------------+--------------------------------- Changes (by igloo): * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 2 16:19:04 2008 From: trac at galois.com (GHC) Date: Wed Jul 2 16:10:10 2008 Subject: [GHC] #2406: Data.List.sortFun In-Reply-To: <046.08859d63266a4054020b2d26eaa3a7a5@localhost> References: <046.08859d63266a4054020b2d26eaa3a7a5@localhost> Message-ID: <055.30911e305451a6916afc66a2bee7ee03@localhost> #2406: Data.List.sortFun -----------------------------+---------------------------------------------- Reporter: lpsmith | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 6.8.3 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => wontfix Comment: If you want to propose for the base library, please see http://www.haskell.org/haskellwiki/Library_submissions -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 2 16:23:12 2008 From: trac at galois.com (GHC) Date: Wed Jul 2 16:14:18 2008 Subject: [GHC] #2360: More information in occurs check message In-Reply-To: <042.d2d1b5c4c3c7a52b18a6186683534f09@localhost> References: <042.d2d1b5c4c3c7a52b18a6186683534f09@localhost> Message-ID: <051.ac3adeaf7d4cf578d3ca2f3f35fe30ed@localhost> #2360: More information in occurs check message -----------------------------+---------------------------------------------- Reporter: ajd | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 2 17:23:39 2008 From: trac at galois.com (GHC) Date: Wed Jul 2 17:14:46 2008 Subject: [GHC] #2379: ghc-6.9.20080614: panic! (the 'impossible' happened) In-Reply-To: <045.86b9b930b3ded50e36018e43dce2d355@localhost> References: <045.86b9b930b3ded50e36018e43dce2d355@localhost> Message-ID: <054.35c1463bc95ba82b7ce1cf2356358026@localhost> #2379: ghc-6.9.20080614: panic! (the 'impossible' happened) ----------------------+----------------------------------------------------- Reporter: megacz | Owner: Type: bug | Status: closed Priority: low | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: MacOS X | ----------------------+----------------------------------------------------- Comment (by simonpj): Ian and Roman are working on fixing the build-system problem. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 2 17:28:15 2008 From: trac at galois.com (GHC) Date: Wed Jul 2 17:19:35 2008 Subject: [GHC] #955: more object-code blow-up in ghc-6.8.3 vs. ghc-6.4.2 (both with optimization) In-Reply-To: <052.784670e095eb0d591995e903dae303b2@localhost> References: <052.784670e095eb0d591995e903dae303b2@localhost> Message-ID: <061.63140c5d936076c0b25037fa3e737b67@localhost> #955: more object-code blow-up in ghc-6.8.3 vs. ghc-6.4.2 (both with optimization) --------------------------------------+------------------------------------- Reporter: maeder@tzi.de | Owner: Type: run-time performance bug | Status: reopened Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: object-code blow-up | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | --------------------------------------+------------------------------------- Comment (by simonpj): Adding data from Christian: * For ghc-6.8.2 our compressed binary hets.bz2 shrunk from 7.2 MB to 6.6 MB * For ghc-6.8.3 from 13 MB to 6.8 MB (some manual instance are left in our code) http://www.informatik.uni- bremen.de/agbkb/forschung/formal_methods/CoFI/hets/linux/daily/ http://www.informatik.uni- bremen.de/agbkb/forschung/formal_methods/CoFI/hets/linux/versions/ -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 2 18:10:27 2008 From: trac at galois.com (GHC) Date: Wed Jul 2 18:01:36 2008 Subject: [GHC] #2307: Poor warning for conflicting functional dependencies In-Reply-To: <051.74da8f65a0dfd1e30516012444a9f297@localhost> References: <051.74da8f65a0dfd1e30516012444a9f297@localhost> Message-ID: <060.a8f58e4d371a3253d05e1184b8794ae3@localhost> #2307: Poor warning for conflicting functional dependencies -----------------------------------------+---------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: reopened Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: typecheck/should_fail/T2307 | Architecture: Unknown Os: Unknown | -----------------------------------------+---------------------------------- Comment (by simonpj): crumbs, good catch Ian. You are referring to `FunDeps.trimRoughMatchTcs`? Indeed that looks wrong: it should match on the `ls` rather than everything except `rs`. Is that what you meant, or did you have something else in mind? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 2 18:59:58 2008 From: trac at galois.com (GHC) Date: Wed Jul 2 18:51:03 2008 Subject: [GHC] #2390: RPM spec file not present in source distribution tarball In-Reply-To: <046.dbf14f1bcd9b3aa5d69835f4914e4112@localhost> References: <046.dbf14f1bcd9b3aa5d69835f4914e4112@localhost> Message-ID: <055.1e50f3d0034c9ba465c5a4c53c8de13a@localhost> #2390: RPM spec file not present in source distribution tarball --------------------------+------------------------------------------------- Reporter: mikedlr | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Build System | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Linux | --------------------------+------------------------------------------------- Changes (by igloo): * owner: => igloo * difficulty: => Unknown * milestone: => 6.10.1 Comment: Thanks for the patch. The difference between the `.in` and non-`.in` versions is just: {{{ -%define version @ProjectVersion@ -%define release @release@ +%define version 6.9.20080702 +%define release 1 }}} so this change looks like it makes sense, for released versions at least. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 2 20:48:48 2008 From: trac at galois.com (GHC) Date: Wed Jul 2 20:39:53 2008 Subject: [GHC] #2307: Poor warning for conflicting functional dependencies In-Reply-To: <051.74da8f65a0dfd1e30516012444a9f297@localhost> References: <051.74da8f65a0dfd1e30516012444a9f297@localhost> Message-ID: <060.411b8a5e5df3cfa1d122936f6b4205f3@localhost> #2307: Poor warning for conflicting functional dependencies -----------------------------------------+---------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: reopened Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: typecheck/should_fail/T2307 | Architecture: Unknown Os: Unknown | -----------------------------------------+---------------------------------- Comment (by igloo): I can't think of a case where just-ls won't work, so that sounds right to me! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 2 23:47:35 2008 From: trac at galois.com (GHC) Date: Wed Jul 2 23:38:48 2008 Subject: [GHC] #2397: inclusion of Network.Curl causes compiler issues and coredumps In-Reply-To: <044.71a03c5613ebce7a7a5b57faf13a6e22@localhost> References: <044.71a03c5613ebce7a7a5b57faf13a6e22@localhost> Message-ID: <053.42f2b1127c8efb6db6dbda00772e9ab1@localhost> #2397: inclusion of Network.Curl causes compiler issues and coredumps ----------------------------------+----------------------------------------- Reporter: b7j0c | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown ----------------------------------+----------------------------------------- Comment (by b7j0c): ignore above comments regarding hxt and text.xml.light, it is doubtful they are the issue -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 3 01:23:31 2008 From: trac at galois.com (GHC) Date: Thu Jul 3 01:14:36 2008 Subject: [GHC] #2414: GHCi segfault Message-ID: <043.07db70092bd8811bd5934348939d4781@localhost> #2414: GHCi segfault ------------------------+--------------------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- {{{ Prelude> Data.List.unfoldr Just (1,1) [1,zsh: segmentation fault ghci -v0 }}} Spotted in #haskell, ghc-6.8.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 3 01:34:18 2008 From: trac at galois.com (GHC) Date: Thu Jul 3 01:25:23 2008 Subject: [GHC] #2415: unfoldr segfaults Message-ID: <046.a7585c7af4f9fc06bd8cc9b64ada6c12@localhost> #2415: unfoldr segfaults ------------------------+--------------------------------------------------- Reporter: vininim | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: major Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- > unfoldr Just (1,1) Results [1, Segmentation fault Seems to be a typechecking bug since Just doesn't really match unfoldr signature for a generator. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 3 01:37:52 2008 From: trac at galois.com (GHC) Date: Thu Jul 3 01:28:58 2008 Subject: [GHC] #2415: unfoldr segfaults In-Reply-To: <046.a7585c7af4f9fc06bd8cc9b64ada6c12@localhost> References: <046.a7585c7af4f9fc06bd8cc9b64ada6c12@localhost> Message-ID: <055.de4e206deda2ca86fbab15902a5915f6@localhost> #2415: unfoldr segfaults -------------------------+-------------------------------------------------- Reporter: vininim | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: major | Resolution: duplicate Keywords: | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- Changes (by vininim): * status: new => closed * resolution: => duplicate Comment: Duplicate of http://hackage.haskell.org/trac/ghc/ticket/2414. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 3 01:52:57 2008 From: trac at galois.com (GHC) Date: Thu Jul 3 01:44:00 2008 Subject: [GHC] #2414: GHCi / GHC segfault : type checker problem In-Reply-To: <043.07db70092bd8811bd5934348939d4781@localhost> References: <043.07db70092bd8811bd5934348939d4781@localhost> Message-ID: <052.65350a168cac01321697be35ce2ccdfd@localhost> #2414: GHCi / GHC segfault : type checker problem ----------------------------------------+----------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown ----------------------------------------+----------------------------------- Comment (by AudreyTang): More data points: {{{ unfoldr Just ((),()) -- crash unfoldr (id Just) ((),()) -- fine unfoldr (id . Just) ((),()) -- fine unfoldr (Just . id) ((),()) -- fine }}} Also GHC 6.4.3 is fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 3 12:16:55 2008 From: trac at galois.com (GHC) Date: Thu Jul 3 12:08:02 2008 Subject: [GHC] #1687: A faster (^)-function. In-Reply-To: <064.1e051c3fce5c2da263cdc0424cf20634@localhost> References: <064.1e051c3fce5c2da263cdc0424cf20634@localhost> Message-ID: <073.8640ab8d7a35b5d1c1b41d3405f64f77@localhost> #1687: A faster (^)-function. ---------------------------------------+------------------------------------ Reporter: moonlite@dtek.chalmers.se | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Prelude | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ---------------------------------------+------------------------------------ Changes (by igloo): * owner: igloo => -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 3 12:18:02 2008 From: trac at galois.com (GHC) Date: Thu Jul 3 12:09:09 2008 Subject: [GHC] #2310: Panic in ghci 6.8.2 with -fglasgow-exts In-Reply-To: <044.6adffbe80c29ff86b9900afa24eb80ad@localhost> References: <044.6adffbe80c29ff86b9900afa24eb80ad@localhost> Message-ID: <053.49d96ba60eed1ab4d4d85626e8521d65@localhost> #2310: Panic in ghci 6.8.2 with -fglasgow-exts --------------------+------------------------------------------------------- Reporter: guest | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: T2310 | Architecture: x86 Os: Linux | --------------------+------------------------------------------------------- Changes (by igloo): * status: new => closed * type: merge => bug * resolution: => fixed * milestone: 6.10 branch => 6.10.1 Comment: Wasn't merged in time for 6.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 3 12:19:22 2008 From: trac at galois.com (GHC) Date: Thu Jul 3 12:10:56 2008 Subject: [GHC] #2175: stableptr003 fails In-Reply-To: <044.d06ef41a33cee91ab166dec272f5c106@localhost> References: <044.d06ef41a33cee91ab166dec272f5c106@localhost> Message-ID: <053.3d5059a5ac6e5c40585b87ef29be85c0@localhost> #2175: stableptr003 fails ----------------------+----------------------------------------------------- Reporter: igloo | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * type: merge => bug * resolution: => fixed Comment: Wasn't merged in time for 6.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 3 12:21:14 2008 From: trac at galois.com (GHC) Date: Thu Jul 3 12:12:50 2008 Subject: [GHC] #2378: panic: lookupVers1, when standalone deriving Typeable and Data In-Reply-To: <044.817cb3c6a4bf0ec145ce20c20c5af470@localhost> References: <044.817cb3c6a4bf0ec145ce20c20c5af470@localhost> Message-ID: <053.0f070ae316362385bd3f787095d8df91@localhost> #2378: panic: lookupVers1, when standalone deriving Typeable and Data -------------------------------------------+-------------------------------- Reporter: guest | Owner: Type: merge | Status: new Priority: normal | Milestone: 6.8 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: deriving/should_compile/T2378 | Architecture: x86 Os: MacOS X | -------------------------------------------+-------------------------------- Changes (by igloo): * owner: igloo => -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 3 12:21:21 2008 From: trac at galois.com (GHC) Date: Thu Jul 3 12:12:56 2008 Subject: [GHC] #2358: Template Haskell's TupleT considers unary tuples as a valid types. In-Reply-To: <043.f22163bf02ff2ecbb2b6874f8a72bacc@localhost> References: <043.f22163bf02ff2ecbb2b6874f8a72bacc@localhost> Message-ID: <052.3edd79f99538d786a492aff3efce67e4@localhost> #2358: Template Haskell's TupleT considers unary tuples as a valid types. ------------------------------+--------------------------------------------- Reporter: fons | Owner: Type: merge | Status: new Priority: normal | Milestone: 6.8 branch Component: Template Haskell | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: TH_1tuple | Architecture: Unknown Os: Unknown | ------------------------------+--------------------------------------------- Changes (by igloo): * owner: igloo => -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 3 14:31:06 2008 From: trac at galois.com (GHC) Date: Thu Jul 3 14:22:11 2008 Subject: [GHC] #2390: RPM spec file not present in source distribution tarball In-Reply-To: <046.dbf14f1bcd9b3aa5d69835f4914e4112@localhost> References: <046.dbf14f1bcd9b3aa5d69835f4914e4112@localhost> Message-ID: <055.b36c5bcea80523b4cb83ec7e98f7e8fb@localhost> #2390: RPM spec file not present in source distribution tarball --------------------------+------------------------------------------------- Reporter: mikedlr | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Build System | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Linux | --------------------------+------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Patch applied, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 3 20:40:19 2008 From: trac at galois.com (GHC) Date: Thu Jul 3 20:31:21 2008 Subject: [GHC] #2373: Build fails to pass locations of external tools to libraries In-Reply-To: <042.251f9ace7edb49f0e772cf590973862b@localhost> References: <042.251f9ace7edb49f0e772cf590973862b@localhost> Message-ID: <051.17e4629e3ea24dcbbcc8c85880a2edf6@localhost> #2373: Build fails to pass locations of external tools to libraries ----------------------+----------------------------------------------------- Reporter: bos | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Thanks, I've fixed this. We now pass the flags, provided the values were not empty. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 3 20:40:11 2008 From: trac at galois.com (GHC) Date: Thu Jul 3 20:31:35 2008 Subject: [GHC] #2352: POSIX.1 unsetenv returns int In-Reply-To: <043.9a1a67d0fcfde818f197866387595049@localhost> References: <043.9a1a67d0fcfde818f197866387595049@localhost> Message-ID: <052.c7cd6d244e81c4300a9843009319fd57@localhost> #2352: POSIX.1 unsetenv returns int ----------------------------+----------------------------------------------- Reporter: donn | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: libraries/unix | Version: 6.8.2 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: NetBSD | ----------------------------+----------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: http://osdir.com/ml/lib.gnulib.bugs/2004-11/msg00009.html says that it returns `void` on NetBSD, and FreeBSD and Redhat 7.3 GNU/Linux, while my man page and http://www.opengroup.org/onlinepubs/009695399/functions/unsetenv.html agree that it should return `int`, so both cases really do exist. I've applied the patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 3 20:40:15 2008 From: trac at galois.com (GHC) Date: Thu Jul 3 20:31:47 2008 Subject: [GHC] #2307: Poor warning for conflicting functional dependencies In-Reply-To: <051.74da8f65a0dfd1e30516012444a9f297@localhost> References: <051.74da8f65a0dfd1e30516012444a9f297@localhost> Message-ID: <060.1b820c7009077938a5aa564a3f302bc5@localhost> #2307: Poor warning for conflicting functional dependencies ----------------------------------------------------+----------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: typecheck/should_fail/T2307, tcfail202 | Architecture: Unknown Os: Unknown | ----------------------------------------------------+----------------------- Changes (by igloo): * testcase: typecheck/should_fail/T2307 => typecheck/should_fail/T2307, tcfail202 * status: reopened => closed * resolution: => fixed Comment: I've made the change and added a test: tcfail202 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 3 22:09:49 2008 From: trac at galois.com (GHC) Date: Thu Jul 3 22:01:04 2008 Subject: [GHC] #2356: GHC accepts multiple instances for the same type in different modules In-Reply-To: <044.2ec6e38cc1bfc912f22d361e9492d9f9@localhost> References: <044.2ec6e38cc1bfc912f22d361e9492d9f9@localhost> Message-ID: <053.f41fed6ede79300a59a3ccb6d60934fe@localhost> #2356: GHC accepts multiple instances for the same type in different modules ----------------------+----------------------------------------------------- Reporter: claus | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by chak): * cc: chak@cse.unsw.edu.au (added) Comment: Replying to [comment:1 guest]: > This really surprises me. Why doesn't think produce a link error? > Each instance declaration should give rise to a global symbol uniquely determined by the class and the type, I'd presume. And when they meet there will be a clash. > Obviously I'm wrong, as this (scary) example shows. I believe, toplevel symbols binding dictionaries include the module (and package name) like all other toplevel symbols. The example -although violating the current language definition- is less scary than one might think. You cannot abuse it (even if you chuck FDs into the mix) to coerce types unsafely (or circumvent strong typing in any other way). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 4 00:52:27 2008 From: trac at galois.com (GHC) Date: Fri Jul 4 00:43:59 2008 Subject: [GHC] #2416: Optimization defeated by merging module into main Message-ID: <048.56959a6c70911c633555f1458314494a@localhost> #2416: Optimization defeated by merging module into main -------------------------------+-------------------------------------------- Reporter: sedillard | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Linux -------------------------------+-------------------------------------------- I have a library, `TheModule`, and an application that uses `TheModule`, called `Main`. When `TheModule` lives in `TheModule.hs` and `Main` lives in `Main.hs`, optimization works as expected. When I copy all of `TheModule`'s definitions and all of `Main`'s definitions into `Both.hs`, much less optimization occurs, as can be seen from -ddump-simpl, as well as the drastic difference in running times. The program performs a lot of small matrix-vector multiplications. The single command line argument tells how many to do. {{{ time ./Main 1000000 20.0 :. (59.0 :. (100.0 :. (137.0 :. ()))) real 0m0.389s user 0m0.152s sys 0m0.232s time ./Both 100000 20.0 :. (59.0 :. (100.0 :. (137.0 :. ()))) real 0m3.462s user 0m3.368s sys 0m0.068s }}} So that makes Both about 100 times slower. Compiled with -O2 and -fexcess- precision -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 4 00:58:39 2008 From: trac at galois.com (GHC) Date: Fri Jul 4 00:50:11 2008 Subject: [GHC] #2416: Optimization defeated by merging module into main In-Reply-To: <048.56959a6c70911c633555f1458314494a@localhost> References: <048.56959a6c70911c633555f1458314494a@localhost> Message-ID: <057.d40b6c7376d6063bddb95b8a917b555d@localhost> #2416: Optimization defeated by merging module into main -------------------------------+-------------------------------------------- Reporter: sedillard | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Linux -------------------------------+-------------------------------------------- Comment (by sedillard): The main reason Main.hs is so much faster is this: {{{ ghc --make Main.hs -O2 -fexcess-precision -ddump-simpl | grep D# [1 of 2] Compiling TheModule ( TheModule.hs, TheModule.o ) [2 of 2] Compiling Main ( Main.hs, Main.o ) Linking Main ... (no hits) }}} There are no calls D# in the compiled Main.hs, whereas Both.hs ends up with many D# constructors in the main loop. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 4 01:07:22 2008 From: trac at galois.com (GHC) Date: Fri Jul 4 00:58:54 2008 Subject: [GHC] #2416: Optimization defeated by merging module into main In-Reply-To: <048.56959a6c70911c633555f1458314494a@localhost> References: <048.56959a6c70911c633555f1458314494a@localhost> Message-ID: <057.29591290745a87aa0e60cfc903e63869@localhost> #2416: Optimization defeated by merging module into main -------------------------------+-------------------------------------------- Reporter: sedillard | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Linux -------------------------------+-------------------------------------------- Comment (by dolio): What happens if you put: {{{ module Main (main) where }}} at the top of Both.hs? The obvious difference between the two setups is that Main.hs exports only main, m4 and v4, whereas Both exports all the functions in TheModule as well. When things are exported like that, GHC is more conservative about optimizations. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 4 01:11:00 2008 From: trac at galois.com (GHC) Date: Fri Jul 4 01:02:33 2008 Subject: [GHC] #2416: Optimization defeated by merging module into main In-Reply-To: <048.56959a6c70911c633555f1458314494a@localhost> References: <048.56959a6c70911c633555f1458314494a@localhost> Message-ID: <057.bff246b043059d149a7f9132b7b6fa7e@localhost> #2416: Optimization defeated by merging module into main -------------------------------+-------------------------------------------- Reporter: sedillard | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Linux -------------------------------+-------------------------------------------- Comment (by sedillard): Adding `module Main (main) where` does not change the behavior. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 4 01:50:17 2008 From: trac at galois.com (GHC) Date: Fri Jul 4 01:41:50 2008 Subject: [GHC] #2359: Data.IntMap update{Min, Max}WithKey corrupts data structure In-Reply-To: <042.245aba7cabc38180cbe3d307aebd0f3e@localhost> References: <042.245aba7cabc38180cbe3d307aebd0f3e@localhost> Message-ID: <051.992c7ca32e29ce3a3c7e6664b5732850@localhost> #2359: Data.IntMap update{Min,Max}WithKey corrupts data structure ----------------------------+----------------------------------------------- Reporter: nwf | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------------+----------------------------------------------- Comment (by sedillard): The problem was a typo, probably from cutting and pasting. I don't think more illuminating comments would have helped. A proper test, on the other hand... -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 4 03:41:21 2008 From: trac at galois.com (GHC) Date: Fri Jul 4 03:32:22 2008 Subject: [GHC] #2417: using GADT syntax for an associated datatype causes GHC to panic Message-ID: <044.b2b50269f86bb871052f27e2bada0368@localhost> #2417: using GADT syntax for an associated datatype causes GHC to panic ------------------------+--------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: minor Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- I am aware that this is probably not supposed to be supported. But even if using a GADT as an associated datatype instance does not directly work, it would be nice if * the GADT syntax was supported for "normal" associated datatypes, * the error message was more informative. Example program: {{{ {-# LANGUAGE TypeFamilies, GADTs #-} class X a where data T a instance X Int where data T Int where C :: T Int }}} Error message: {{{ ghc-6.9.20080615: panic! (the 'impossible' happened) (GHC version 6.9.20080615 for x86_64-unknown-linux): Maybe.fromJust: Nothing }}} Occurs with recent snapshot, but also with 6.8.2 and 6.8.3. Andres -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 4 04:55:41 2008 From: trac at galois.com (GHC) Date: Fri Jul 4 04:46:48 2008 Subject: [GHC] #2366: ASSERT failed! file typecheck/TcMType.lhs line 517 In-Reply-To: <053.ab23f29da9729b185efbfb211d6ff539@localhost> References: <053.ab23f29da9729b185efbfb211d6ff539@localhost> Message-ID: <062.0d782f51fa1cd115044a0ccce8399094@localhost> #2366: ASSERT failed! file typecheck/TcMType.lhs line 517 ----------------------------+----------------------------------------------- Reporter: batterseapower | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: gadt/equal | Architecture: Unknown Os: Multiple | ----------------------------+----------------------------------------------- Changes (by chak): * status: new => closed * resolution: => duplicate Comment: Duplicate of #2212. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 4 05:26:23 2008 From: trac at galois.com (GHC) Date: Fri Jul 4 05:17:27 2008 Subject: [GHC] #2212: Double assignment to coercion variable In-Reply-To: <046.ad4e8af6cf182013c618bfd8fa17eb5c@localhost> References: <046.ad4e8af6cf182013c618bfd8fa17eb5c@localhost> Message-ID: <055.347c4263a28fbbed8caa94e6c6cd721e@localhost> #2212: Double assignment to coercion variable ----------------------+----------------------------------------------------- Reporter: simonpj | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: equal | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by simonpj): See also #2366, which gives a list of other tests that trigger this failure. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 4 05:28:55 2008 From: trac at galois.com (GHC) Date: Fri Jul 4 05:19:58 2008 Subject: [GHC] #2416: Optimization defeated by merging module into main In-Reply-To: <048.56959a6c70911c633555f1458314494a@localhost> References: <048.56959a6c70911c633555f1458314494a@localhost> Message-ID: <057.05876514e66033183164577204ef59d8@localhost> #2416: Optimization defeated by merging module into main -----------------------+---------------------------------------------------- Reporter: sedillard | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | -----------------------+---------------------------------------------------- Changes (by simonpj): * difficulty: => Unknown Comment: Thank you very much for a nice test case. Usually splitting things across modules makes things worse, not better, so it's an interesting case. I'll look into it. But probably not immediately -- POPL deadline then trip. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 4 05:38:23 2008 From: trac at galois.com (GHC) Date: Fri Jul 4 05:29:40 2008 Subject: [GHC] #2356: GHC accepts multiple instances for the same type in different modules In-Reply-To: <044.2ec6e38cc1bfc912f22d361e9492d9f9@localhost> References: <044.2ec6e38cc1bfc912f22d361e9492d9f9@localhost> Message-ID: <053.dba2d83b1cafb53a9aab8a4d3c4c8a2d@localhost> #2356: GHC accepts multiple instances for the same type in different modules ----------------------+----------------------------------------------------- Reporter: claus | Owner: Type: bug | Status: new Priority: low | Milestone: _|_ Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonpj): * priority: high => low * milestone: 6.10.1 => _|_ Comment: Currently this is by design. What would the unique global symbol be for {{{ instance C (T a) [Maybe b] }}} Oh, and `T` might be a type synonym. We could encode the type as a string, I suppose, but the error message (from the linker) would still be execrable. For indexed-type instances, overlap is unsound, so there's an eager check. On reflection, if you don't use `-fallow-overlapping-instances` GHC should arguably do the same eager check for class instances; that would more faithfully implement the Report. Even doing that is not trivial, because GHC goes to some lengths to avoid looking at (literally) thousands of interface files on every compilation, just on the off-chance that there'll be an instance declaration lurking there. With overlap allowed, it's clear that you can make different choices in different parts of the program. So I'm not sure what to do; and the only thing that comes to mind isn't cheap. For now I'll put it as low-prio, unless people start yelling that it's ruining their day. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 4 05:49:48 2008 From: trac at galois.com (GHC) Date: Fri Jul 4 05:40:49 2008 Subject: [GHC] #2414: GHCi / GHC segfault : type checker problem In-Reply-To: <043.07db70092bd8811bd5934348939d4781@localhost> References: <043.07db70092bd8811bd5934348939d4781@localhost> Message-ID: <052.8e3583f5a329b3159aa9a002e52c9595@localhost> #2414: GHCi / GHC segfault : type checker problem -------------------------------------+-------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler (Type checker) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Changes (by simonpj): * priority: normal => high * difficulty: => Unknown * milestone: => 6.10.1 Comment: Excellent report! Happily `-dcore-lint` nails the problem, as usual. As you speculated, it's in the type checker. A missing occurs check is allows through a bogus program. I wonder how long this has been lurking! I have not yet found the bug -- but I know where to look now. Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 4 07:51:25 2008 From: trac at galois.com (GHC) Date: Fri Jul 4 07:42:26 2008 Subject: [GHC] #2418: desugaring type function application to constraint makes bug disappear Message-ID: <044.eaa9c0a2eea9fd2435e9f9d1b5497f42@localhost> #2418: desugaring type function application to constraint makes bug disappear ------------------------------+--------------------------------------------- Reporter: claus | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 6.9 | Severity: normal Keywords: type families | Testcase: Architecture: Unknown | Os: Unknown ------------------------------+--------------------------------------------- When considering type functions, I find it helpful to desugar their applications into additional constraints (`tf a` becomes `tf a~tfa=>tfa`). But consider this example from a recent [http://www.haskell.org/pipermail /haskell-cafe/2008-July/044911.html haskell-cafe thread]: {{{ {-# OPTIONS_GHC -fglasgow-exts #-} class Blah f a where blah :: a -> T f f a class A f where type T f :: (* -> *) -> * -> * -- wrapper :: forall a f tf . (Blah f a,T f~tf) => a -> tf f a wrapper :: forall a f . (Blah f a) => a -> T f f a wrapper x = blah x }}} for which `GHCi, version 6.9.20080514` yields: {{{ C:\Documents and Settings\cr3\Desktop\TF.hs:8:12: Could not deduce (Blah f a) from the context (Blah f1 a) arising from a use of `blah' at C:\Documents and Settings\cr3\Desktop\TF.hs:8:12-17 Possible fix: add (Blah f a) to the context of the type signature for `wrapper' In the expression: blah x In the definition of `wrapper': wrapper x = blah x C:\Documents and Settings\cr3\Desktop\TF.hs:8:12: Couldn't match expected ty